מעבר אל Google Cloud: אופטימיזציה של הסביבה

Last reviewed 2024-12-07 UTC

המסמך הזה יעזור לכם לתכנן ולעצב את שלב האופטימיזציה של המעבר אל Google Cloud. אחרי שפורסים את עומסי העבודה ב- Google Cloud, אפשר להתחיל לבצע אופטימיזציה של הסביבה.

המסמך הזה הוא חלק מסדרה של כמה מאמרים בנושא מעבר אלGoogle Cloud:

התרשים הבא מדגים את נתיב המיגרציה שלכם.

נתיב העברה עם ארבעה שלבים.

בשלב האופטימיזציה, משפרים את הסביבה כדי שהיא תהיה יעילה יותר מהפריסה הראשונית.

המסמך הזה שימושי אם אתם מתכננים לבצע אופטימיזציה של סביבה קיימת אחרי מעבר ל- Google Cloud, או אם אתם בודקים את האפשרות לבצע אופטימיזציה ורוצים לראות איך זה יכול להיראות.

מבנה שלב האופטימיזציה מבוסס על מסגרת ההעברה שמתוארת בסדרה הזו: הערכה, תכנון, פריסה ואופטימיזציה. אפשר להשתמש במסגרת הרב-תכליתית הזו כדי לתכנן את כל ההעברה ולחלק את הפעולות העצמאיות בכל שלב. אחרי שמסיימים את השלב האחרון של האופטימיזציה, אפשר להתחיל את השלב הזה מחדש ולמצוא יעדים חדשים לאופטימיזציה. שלב האופטימיזציה מוגדר כלולאת אופטימיזציה. ביצוע של הלולאה מוגדר כאיטרציה של אופטימיזציה.

אופטימיזציה היא משימה מתמשכת. אתם מבצעים אופטימיזציה מתמדת של הסביבה שלכם כשהיא מתפתחת. כדי להימנע ממאמצים לא מבוקרים ומכפולים, אפשר להגדיר יעדי אופטימיזציה מדידים ולהפסיק את האופטימיזציה כשמשיגים את היעדים האלה. לאחר מכן, תמיד אפשר להגדיר יעדים חדשים ושאפתניים יותר, אבל חשוב לזכור שלאופטימיזציה יש עלות מבחינת משאבים, זמן, מאמץ ומיומנויות.

התרשים הבא מציג את לולאת האופטימיזציה.

עץ החלטות לאופטימיזציה. כדי לראות תמונה גדולה יותר של התרשים הזה, אפשר לעיין בעץ ההחלטות בנושא אופטימיזציה.

במאמר הזה תבצעו את השלבים הבאים של לולאת האופטימיזציה, שאפשר לחזור עליהם שוב ושוב:

  1. להעריך את הסביבה, הצוותים ולולאת האופטימיזציה שאתם פועלים לפיה.
  2. קובעים את הדרישות והיעדים לאופטימיזציה.
  3. מבצעים אופטימיזציה של הסביבה ומכשירים את הצוותים.
  4. שיפור של לולאת האופטימיזציה.

במסמך הזה נדון בכמה מהעקרונות והמושגים של הנדסת אמינות אתרים (SRE). Google פיתחה את תחום ה-SRE כדי להפעיל ביעילות ובאמינות תשתית גלובלית שמשרתת מיליארדי משתמשים. יכול להיות שאימוץ תחום ה-SRE במלואו בארגון שלכם לא יהיה מעשי אם תצטרכו לשנות הרבה מהתהליכים העסקיים והתהליכים של שיתוף הפעולה. יכול להיות שיהיה פשוט יותר להחיל קבוצת משנה של תחום ה-SRE שמתאימה לארגון שלכם בצורה הטובה ביותר.

הערכה של הסביבה, הצוותים ולולאת האופטימיזציה

לפני שמתחילים במשימת אופטימיזציה, צריך להעריך את הסביבה. צריך גם להעריך את הכישורים של הצוותים, כי יכול להיות שיידרשו כישורים שאין לצוותים כדי לבצע אופטימיזציה של הסביבה. לבסוף, צריך להעריך את לולאת האופטימיזציה. הלולאה היא משאב שאפשר לבצע בו אופטימיזציה כמו בכל משאב אחר.

הערכת הסביבה

כדי לבצע אופטימיזציה מוצלחת, אתם צריכים להבין לעומק את הסביבה שלכם ולזהות תחומים פוטנציאליים לשיפור. ההערכה הזו יוצרת בסיס להשוואה, כך שתוכלו להשוות את ההערכה שלכם מול שלב האופטימיזציה ומול איטרציות האופטימיזציה הבאות.

העברה אל Google Cloud: הערכה וגילוי של עומסי עבודה כולל הנחיות מפורטות לגבי הערכת עומסי העבודה והסביבות שלכם. אם לאחרונה השלמתם העברה אלGoogle Cloud, כבר יש לכם מידע מפורט על האופן שבו הסביבה שלכם מוגדרת, מנוהלת ומתוחזקת. אחרת, תוכלו להשתמש בהנחיות האלה כדי להעריך את הסביבה שלכם.

הערכת הצוותים

כדי להבין מהן היכולות של הצוותים שלכם, צריך קודם להכיר את הסביבה שלכם. מתחילים ביצירת רשימה של כל היכולות, רמת המומחיות בכל יכולת ומי מחברי הצוות הכי מומחה בכל יכולת. בשלב הבא משתמשים בהערכה הזו כדי לגלות אילו יכולות חסרות לכם כדי להשיג את יעדי האופטימיזציה. לדוגמה, אם אתם מתחילים להשתמש בשירות מנוהל, אתם צריכים את היכולות לספק, להגדיר ולקיים אינטראקציה עם השירות הזה. אם אתם רוצים להוסיף שכבת מטמון לאפליקציה בסביבה שלכם באמצעות Memorystore, אתם צריכים מומחיות כדי להשתמש בשירות הזה.

חשוב לזכור שאופטימיזציה של הסביבה עשויה להשפיע על תהליכים עסקיים ותהליכי שיתוף פעולה. לדוגמה, אם מתחילים להשתמש בשירות שמנוהל במלואו במקום בשירות בניהול עצמי, אפשר לתת למפעילים יותר זמן לצמצם את הטרחה.

הערכה של לולאת האופטימיזציה

גם לולאת האופטימיזציה היא משאב שאפשר לבצע בו אופטימיזציה. השתמשו בנתונים שנאספו בתהליך הבדיקה הזה כדי לקבל תובנות ברורות לגבי הביצועים של הצוותים שלכם במהלך איטרציית האופטימיזציה האחרונה. לדוגמה, אם המטרה שלכם היא לקצר את משך האיטרציה, אתם צריכים נתונים על האיטרציה האחרונה, כולל המורכבות שלה והיעדים שהגדרתם. בנוסף, צריך מידע על כל החסימות שנתקלתם בהן במהלך האיטרציה האחרונה, כדי לוודא שיש לכם אסטרטגיית צמצום סיכונים למקרה שהחסימות האלה יחזרו.

אם זו חזרה ראשונה על האופטימיזציה, יכול להיות שאין לכם מספיק נתונים כדי ליצור בסיס להשוואה של הביצועים. מנסחים קבוצה של השערות לגבי הביצועים הצפויים של הצוותים במהלך האיטרציה הראשונה. אחרי איטרציית האופטימיזציה הראשונה, מעריכים את הלולאה ואת הביצועים של הצוותים ומשווים אותם להשערות.

הגדרת הדרישות והיעדים של האופטימיזציה

לפני שמתחילים במשימת אופטימיזציה, כדאי לנסח קבוצה של יעדים מדידים ברורים לאיטרציה.

בשלב הזה מבצעים את הפעולות הבאות:

  1. מגדירים את דרישות האופטימיזציה.
  2. מגדירים יעדי אופטימיזציה מדידים בהתאם לדרישות האופטימיזציה.

הגדרת דרישות האופטימיזציה

מפרטים את הדרישות לשלב האופטימיזציה. דרישה מבטאת צורך בשיפור, ולא בהכרח צריכה להיות מדידה.

אפשר להתחיל עם קבוצה של מאפייני איכות לעומסי העבודה, לסביבה וללולאת האופטימיזציה שלכם, ולנסח שאלון שיעזור לכם להגדיר את הדרישות. השאלון כולל מאפיינים שחשובים לכם בסביבה, בתהליכים ובעומסי העבודה.

יש מקורות רבים שיכולים לעזור לכם להגדיר את מאפייני האיכות. לדוגמה, בתקן ISO/IEC 25010 מוגדרים מאפייני האיכות של מוצר תוכנה, או שאפשר לעיין בGoogle Cloud רשימת המשימות להגדרה.

לדוגמה, בשאלון אפשר לשאול את השאלות הבאות:

  • האם התשתית והרכיבים שלה יכולים להתרחב אנכית או אופקית?
  • האם התשתית שלכם תומכת בביטול שינויים ללא התערבות ידנית?
  • כבר יש לך מערכת ניטור שמכסה את התשתית ואת עומסי העבודה?
  • האם יש לכם מערכת לניהול אירועי אבטחה בתשתית שלכם?
  • כמה זמן ומאמץ נדרשים כדי להטמיע את האופטימיזציות המתוכננות?
  • האם הצלחתם להשיג את כל היעדים באיטרציות הקודמות?

על סמך התשובות לשאלון, יוצרים טיוטה של רשימת הדרישות לאיטרציה הזו של האופטימיזציה. לדוגמה, יכול להיות שהדרישות שלכם יהיו:

  • שיפור הביצועים של אפליקציה.
  • הגדלת הזמינות של רכיב בסביבה.
  • שיפור המהימנות של רכיב בסביבה.
  • צמצום העלויות התפעוליות של הסביבה.
  • כדאי לקצר את משך חזרת האופטימיזציה כדי להפחית את הסיכונים הטמונים בה.
  • הגברת מהירות הפיתוח וקיצור זמן היציאה לשוק.

אחרי שרואים את רשימת התחומים לשיפור, בודקים את הדרישות שמופיעות ברשימה. במהלך ההערכה הזו, תנתחו את דרישות האופטימיזציה, תחפשו התנגשויות ותקבעו את סדר העדיפויות של הדרישות ברשימה. לדוגמה, שיפור הביצועים של אפליקציה מסוימת עלול להתנגש עם צמצום העלויות התפעוליות.

הגדרת יעדים מדידים

אחרי שמסיימים את רשימת הדרישות, מגדירים מטרות מדידות לכל דרישה. יכול להיות שמטרה מסוימת תתרום ליותר מדרישה אחת. אם יש לכם תחום לא ברור או שאתם לא מצליחים להגדיר את כל המטרות שנדרשות כדי לעמוד בדרישות, אתם צריכים לחזור לשלב ההערכה של האיטרציה הזו כדי לאסוף את כל המידע החסר, ואז לשפר את הדרישות.

כדי להגדיר את היעדים האלה, אפשר לפעול לפי אחת מהשיטות של SRE, הגדרת מדדים לרמת השירות (SLI) ויעדים לרמת השירות (SLO):

  • ‫SLI הם מדדים כמותיים של רמת השירות שאתם מספקים. לדוגמה, מדד SLI מרכזי יכול להיות חביון ממוצע של בקשות, שיעור שגיאות או תפוקת המערכת.
  • יעדים למדידת רמת השירות (SLOs) הם ערכי יעד או טווחי ערכים לרמת שירות שנמדדת על ידי אינדיקטורים ברמת השרת (SLIs). לדוגמה, יעד רמת שירות יכול להיות שהחביון הממוצע של הבקשות יהיה נמוך מ-100 אלפיות השנייה.

אחרי שמגדירים את מדדי ה-SLI ואת יעדי ה-SLO, יכול להיות שמבינים שלא אוספים את כל המדדים שצריך כדי למדוד את מדדי ה-SLI. היעד הראשון לאופטימיזציה שאתם יכולים לטפל בו הוא איסוף המדדים האלה. אתם מגדירים את היעדים שקשורים להרחבת מערכת המעקב כדי לאסוף את כל המדדים שאתם צריכים בשביל מחווני רמת השירות (SLI).

אופטימיזציה של הסביבה והצוותים

אחרי שמעריכים את הסביבה, הצוותים ולולאת האופטימיזציה, וקובעים את הדרישות והיעדים של האיטרציה הזו, אפשר לבצע את שלב האופטימיזציה.

בשלב הזה מבצעים את הפעולות הבאות:

  1. מדידה של הסביבה, הצוותים ולולאת האופטימיזציה.
  2. ניתוח הנתונים שמגיעים מהמדידות האלה.
  3. מבצעים את פעולות האופטימיזציה.
  4. מבצעים מדידה וניתוח מחדש.

מדידה של הסביבה, הצוותים ולולאת האופטימיזציה

מרחיבים את מערכת המעקב כדי לאסוף נתונים על ההתנהגות של הסביבה, הצוותים ולולאת האופטימיזציה, כדי ליצור בסיס להשוואה אחרי האופטימיזציה.

הפעילות הזו מתבססת על מה שעשיתם בשלב ההערכה ומרחיבה אותו. אחרי שמגדירים את הדרישות והיעדים, יודעים אילו מדדים צריך לאסוף כדי שהמדידות יהיו רלוונטיות ליעדי האופטימיזציה. לדוגמה, אם הגדרתם יעדי רמת שירות (SLO) ומדדי רמת שירות (SLI) תואמים כדי להפחית את זמן האחזור של התגובה לאחד מעומסי העבודה בסביבה שלכם, אתם צריכים לאסוף נתונים כדי למדוד את המדד הזה.

הבנת המדדים האלה רלוונטית גם לצוותים שלכם וללולאת האופטימיזציה. אתם יכולים להרחיב את מערכת המעקב כדי לאסוף נתונים ולמדוד את המדדים שרלוונטיים לצוותים שלכם וללולאת האופטימיזציה. לדוגמה, אם יש לכם יעדי רמת שירות (SLO) ומדדי רמת שירות (SLI) כדי לקצר את משך חזרת האופטימיזציה, אתם צריכים לאסוף נתונים כדי למדוד את המדד הזה.

כשמתכננים את המדדים שצריך כדי להרחיב את מערכת המעקב, צריך לקחת בחשבון שאיסוף נתונים עלול להשפיע על הביצועים של הסביבה והתהליכים. כדאי להעריך את המדדים שצריך להטמיע לצורך המדידות, ואת מרווחי הדגימה שלהם, כדי להבין אם הם עלולים להשפיע על הביצועים. לדוגמה, מדד עם תדירות דגימה גבוהה עלול לפגוע בביצועים, ולכן צריך לבצע אופטימיזציה נוספת.

ב- Google Cloud, אפשר להשתמש ב-Cloud Monitoring כדי להטמיע את המדדים שנדרשים לאיסוף נתונים. כדי להטמיע מדדים מותאמים אישית בעומסי העבודה שלכם באופן ישיר, אתם יכולים להשתמש בספריות הלקוח של Cloud Monitoring או ב-OpenTelemetry. אם אתם משתמשים ב-Google Kubernetes Engine‏ (GKE), אתם יכולים להשתמש במדידת השימוש ב-GKE כדי לאסוף מידע על השימוש במשאבים, כמו שימוש ב-CPU, ב-GPU וב-TPU, ואז לחלק את השימוש במשאבים לפי מרחב שמות או תווית.

לבסוף, אפשר להשתמש במרכז הארכיטקטורה של Cloud ובGoogle Cloud מסמכים טכניים כנקודות התחלה לזיהוי מיומנויות חדשות שהצוותים שלכם עשויים להזדקק להן כדי לבצע אופטימיזציה של הסביבה שלכם.

ניתוח נתונים

אחרי איסוף הנתונים, מנתחים ומעריכים אותם כדי להבין את רמת הביצועים של הסביבה, הצוותים ולולאת האופטימיזציה ביחס לדרישות וליעדים של האופטימיזציה.

בפרט, עליך להעריך את הסביבה שלך לפי הנקודות הבאות:

  • יעדי SLO.
  • שיטות מומלצות בתחום.
  • סביבה ללא השתרכות מאחור מבחינה טכנית.

הסכמי רמת השירות (SLO) שהגדרתם בהתאם ליעדי האופטימיזציה יכולים לעזור לכם להבין אם אתם עומדים בציפיות שלכם. אם אתם לא עומדים ביעדי ה-SLO, אתם צריכים לשפר את הצוותים או את לולאת האופטימיזציה. לדוגמה, אם הגדרתם SLO לזמן האחזור של התגובה לעומס עבודה כדי שיהיה באחוזון מסוים, ועומס העבודה לא עומד בדרישה הזו, זה סימן שאתם צריכים לבצע אופטימיזציה לחלק הזה של עומס העבודה.

בנוסף, תוכלו להשוות את המצב שלכם לשיטות המומלצות המקובלות בתחום. לדוגמה, Google Cloud רשימת המשימות להגדרה עוזרת להגדיר סביבה שמוכנה לייצור לעומסי עבודה ארגוניים.

אחרי איסוף הנתונים, אפשר לחשוב איך לשפר את הסביבה כדי להפוך אותה לחסכונית יותר. אתם יכולים לייצא את נתוני החיוב ב-Cloud ל-BigQuery ולנתח את הנתונים באמצעות Data Studio כדי להבין כמה משאבים אתם צורכים ולזהות דפוסי הוצאות.

לבסוף, משווים את הסביבה שלכם לסביבה שבה אין חוב טכני, כדי לראות אם אתם עומדים ביעדים לטווח הארוך, וכדי לבדוק אם החוב הטכני גדל. לדוגמה, אפשר להגדיר SLO למספר המשאבים בסביבה שאתם עוקבים אחריהם לעומת מספר המשאבים שהקציתם מאז האיטרציה האחרונה. אם לא הרחבתם את מערכת המעקב כך שתכלול את המשאבים החדשים האלה, החוב הטכני שלכם גדל. כשמנתחים את השינויים בחוב הטכני, חשוב לקחת בחשבון גם את הגורמים שהובילו לשינויים האלה. לדוגמה, יכול להיות שצורך עסקי יחייב הגדלה של החוב הטכני, או שזה יקרה באופן לא צפוי. הכרת הגורמים שגרמו לשינוי בחוב הטכני מאפשרת לכם לקבל תובנות לגבי יעדי אופטימיזציה עתידיים.

כדי לעקוב אחרי הסביבה שלכם ב- Google Cloud, אתם יכולים להשתמש ב-Monitoring כדי לעצב תרשימים, מרכזי בקרה והתראות. לאחר מכן תוכלו לנתב את הנתונים של Cloud Logging כדי לבצע ניתוח מעמיק יותר ולהאריך את תקופת השמירה. לדוגמה, אתם יכולים ליצור מאגרי נתונים מצטברים ולהשתמש ב-Cloud Storage, ב-Pub/Sub או ב-BigQuery כיעדים. אם מייצאים נתונים ל-BigQuery, אפשר להשתמש ב-Data Studio כדי ליצור גרפים ותרשימים של הנתונים, לזהות מגמות ולבצע תחזיות. אתם יכולים גם להשתמש בכלים להערכה כמו Recommender ו-Security Command Center כדי לנתח באופן אוטומטי את הסביבה והתהליכים שלכם ולחפש יעדים לאופטימיזציה.

אחרי ניתוח כל נתוני המדידה, צריך לענות על שתי שאלות:

  1. האם אתם עומדים ביעדי האופטימיזציה שלכם?

    אם התשובה היא כן, סימן שסיימתם את איטרציית האופטימיזציה הזו ואפשר להתחיל איטרציה חדשה. אם התשובה היא לא, אפשר לעבור לשאלה השנייה.

  2. בהתחשב במשאבים שהקציתם בתקציב, האם תוכלו להשיג את יעדי האופטימיזציה שהגדרתם לאיטרציה הזו?

כדי לענות על השאלה הזו, צריך לחשוב על כל המשאבים שדרושים לכם, כמו זמן, כסף ומומחיות. אם התשובה היא כן, אפשר לעבור לקטע הבא. אם התשובה היא לא, צריך לשפר את יעדי האופטימיזציה, תוך התחשבות במשאבים שבהם אפשר להשתמש באיטרציה הזו. לדוגמה, אם אתם מוגבלים על ידי לוח זמנים קבוע, יכול להיות שתצטרכו לתזמן חלק מיעדי האופטימיזציה לאיטרציה הבאה.

אופטימיזציה של הצוותים

אופטימיזציה של הסביבה היא אתגר מתמשך, ועשויות להידרש מיומנויות שחסרות לצוותים שלכם, כפי שגיליתם במהלך ההערכה והניתוח. לכן, כדי שהפעולות שלכם לשיפור הביצועים יניבו תוצאות טובות, חשוב לרכוש מיומנויות חדשות ולשפר את היעילות של התהליכים.

כדי לבצע אופטימיזציה של הצוותים, צריך לבצע את הפעולות הבאות:

  • תכנון והטמעה של תוכנית הדרכה.
  • אופטימיזציה של מבנה הצוות והתרבות הארגונית.

כדי שהצוותים שלכם ירכשו את הכישורים שחסרים להם, אתם צריכים לתכנן וליישם תוכנית הדרכה, או לבחור תוכנית שהוכנה על ידי מדריכים מקצועיים. למידע נוסף, אפשר לעיין במאמר מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה.Google Cloud

במהלך האופטימיזציה של הצוותים, יכול להיות שתגלו שיש מקום לשיפור המבנה והתרבות. קשה להגדיר מראש מצב אידיאלי, כי לכל חברה יש היסטוריה ומאפיינים ייחודיים משלה, שהשפיעו על האופן שבו המבנה והתרבות של הצוותים התפתחו.

מנהיגות טרנספורמטיבית היא נקודת התחלה טובה ללמידת מסגרות כלליות לביצוע שינויים ארגוניים ולמדידתם, במטרה לאמץ שיטות עבודה של DevOps. לקבלת הנחיות מעשיות להטמעת תרבות DevOps יעילה בארגון, אפשר לעיין במאמר Site Reliability Engineering, שבו מפורט תיאור מקיף של מתודולוגיית SRE. חוברת העבודה Site Reliability Workbook, שמלווה את הספר, כוללת דוגמאות קונקרטיות שממחישות איך ליישם את העקרונות והשיטות של SRE.

אופטימיזציה של הסביבה

אחרי שמודדים ומנתחים את נתוני המדדים, יודעים באילו תחומים צריך לבצע אופטימיזציה.

בקטע הזה מפורטות טכניקות כלליות לאופטימיזציה שלGoogle Cloud הסביבה שלכם. אתם יכולים גם לבצע פעולות אופטימיזציה שספציפיות לתשתית ולשירותים שבהם אתם משתמשים.

קידוד של הכול

אחד היתרונות הגדולים של מעבר לסביבת ענן ציבורית כמוGoogle Cloudהוא שאתם יכולים להשתמש בממשקים מוגדרים היטב כמו ממשקי Cloud API כדי להקצות, להגדיר ולנהל משאבים. אתם יכולים להשתמש בכלים לבחירתכם כדי להגדיר את תהליך התשתית כקוד (IaC), ובמערכות לבקרת גרסאות לבחירתכם.

אתם יכולים להשתמש בכלים כמו Terraform כדי להקצות את המשאבים שלכם ב- Google Cloud , ואז להשתמש בכלים כמו Ansible,‏ Chef או Puppet כדי להגדיר את המשאבים האלה. תהליך IaC עוזר לכם להטמיע אסטרטגיית חזרה יעילה למשימות האופטימיזציה. אפשר לבטל כל שינוי שביצעתם בקוד שמתאר את התשתית. בנוסף, כדי להימנע מכשלים לא צפויים במהלך עדכון התשתית, מומלץ לבדוק את השינויים.

בנוסף, אפשר להשתמש בתהליכים דומים כדי לקודד היבטים אחרים של הסביבה, כמו מדיניות כקוד, באמצעות כלים כמו Open Policy Agent, ופעולות כקוד, כמו GitOps.

לכן, אם תטמיעו תהליך IaC בשלבי האופטימיזציה הראשונים, תוכלו להגדיר פעולות אופטימיזציה נוספות כקוד. אפשר גם להטמיע את התהליך בהדרגה, כדי להעריך אם הוא מתאים לסביבה שלכם.

אוטומציה של הכול

כדי לבצע אופטימיזציה מלאה של כל הסביבה, צריך להשתמש במשאבים בצורה יעילה. כלומר, צריך לצמצם את הטרחה כדי לחסוך במשאבים ולהשקיע מחדש במשימות חשובות יותר שמניבות ערך, כמו פעולות אופטימיזציה.

לפי ההמלצה של SRE, הדרך להפחית את העבודה המיותרת היא להגדיל את האוטומציה. לא כל משימות האוטומציה דורשות מיומנויות הנדסה מתקדמות או מאמצים גדולים. לפעמים סקריפט קצר שניתן להפעלה ומופעל באופן תקופתי יכול לחסוך כמה שעות ביום. Google Cloud מספקת כלים כמו Google Cloud CLI ושירותים מנוהלים כמו Cloud APIs,‏ Cloud Scheduler,‏ Managed Service for Apache Airflow ו-Cloud Run, שצוותים יכולים להשתמש בהם כדי לבצע אוטומציה של משימות חוזרות.

מעקב אחרי כל הפעילות

אם לא תוכלו לאסוף נתונים מפורטים על הסביבה שלכם, לא תוכלו לשפר אותה כי לא יהיו לכם נתונים שיאשרו את ההנחות שלכם. המשמעות היא שאתם לא יודעים מה צריך לעשות כדי להשיג את יעדי האופטימיזציה.

מערכת מקיפה למעקב היא רכיב חיוני בסביבה שלכם. המערכת עוקבת אחרי כל המדדים החיוניים שאתם צריכים להעריך כדי להשיג את יעדי האופטימיזציה. כשאתם מתכננים את מערכת המעקב, כדאי לתכנן מעקב אחרי ארבעת האותות החשובים לפחות.

אתם יכולים להשתמש בשירותים מנוהלים כמו Monitoring ו-Logging כדי לעקוב אחרי הסביבה שלכם בלי שתצטרכו להגדיר פתרון מורכב למעקב.

יכול להיות שתצטרכו להטמיע מערכת מעקב שיכולה לעקוב אחרי סביבות היברידיות וסביבות מרובות עננים כדי לעמוד בדרישות של מדיניות הגבלת נתונים שמחייבת אתכם לאחסן נתונים רק במיקומים פיזיים מסוימים, או בשירותים שמשתמשים בכמה סביבות ענן בו-זמנית.

אימוץ גישה שמתאימה לענן

Cloud-ready היא פרדיגמה שמתארת דרך יעילה לעיצוב ולהרצה של אפליקציה בענן. ‫Cloud Native Computing Foundation (CNCF) מגדירה אפליקציה מבוססת-ענן כאפליקציה שניתן להרחיב אותה, שהיא עמידה, ניתנת לניהול וניתנת לצפייה באמצעות טכנולוגיות כמו קונטיינרים, Service mesh, מיקרו-שירותים, תשתית בלתי משתנה וממשקי API הצהרתיים. Google Cloud מספקת שירותים מנוהלים כמו GKE,‏ Cloud Run,‏ Cloud Service Mesh,‏ Logging ו-Monitoring כדי לאפשר למשתמשים לתכנן ולהפעיל אפליקציות שמוכנות לענן.

מידע נוסף על טכנולוגיות שמוכנות לענן זמין במפת הדרך של CNCF ובסביבה האינטראקטיבית של CNCF Cloud Native.

ניהול עלויות

בגלל מודלים שונים של חיוב ועלויות, אופטימיזציה של עלויות בסביבת ענן ציבורי כמו Google Cloud שונה מאופטימיזציה של סביבה מקומית.

מידע נוסף מופיע במאמר מעבר אל Google Cloud: צמצום עלויות.

מדידה וניתוח חוזרים

אחרי שמשלימים את פעולות האופטימיזציה של האיטרציה הזו, חוזרים על המדידות והניתוח כדי לבדוק אם הגעתם ליעדים. עליכם לענות על השאלה הבאה:

שיפור של לולאת האופטימיזציה

בקטע הזה, מעדכנים ומשנים את לולאת האופטימיזציה שפעלתם לפיה באיטרציה הזו, כדי שתתאים יותר למבנה ולסביבה של הצוות.

הגדרת לולאת האופטימיזציה

כדי לבצע אופטימיזציה יעילה של לולאת האופטימיזציה, צריך לתעד ולהגדיר את הלולאה בפורמט סטנדרטי, פשוט וקל לניהול, שמאפשר לבצע שינויים. אפשר להשתמש בשירות שמנוהל במלואו כמו Managed Airflow כדי ליצור, לתזמן, לעקוב אחרי תהליכי העבודה ולנהל אותם. אפשר גם לייצג קודם את התהליכים באמצעות שפה כמו business process model and notation (BPMN). לאחר מכן, אפשר לקודד את התהליכים האלה באמצעות שפה סטנדרטית כמו business process execution language (BPEL). אחרי שמאמצים IaC, תיאור התהליכים באמצעות קוד מאפשר לכם לנהל אותם כמו את שאר הסביבה.

אוטומציה של לולאת האופטימיזציה

אחרי שמגדירים את לולאת האופטימיזציה, אפשר להפוך משימות חוזרות לאוטומטיות כדי למנוע עבודה מייגעת, לחסוך זמן ולשפר את היעילות של לולאת האופטימיזציה. אפשר להתחיל להפוך לאוטומטיות את כל המשימות שלא דורשות החלטה אנושית, כמו מדידת נתונים והפקת דוחות מצטברים לצוותים שלכם לצורך ניתוח. לדוגמה, אפשר להפוך את ניתוח הנתונים לאוטומטי באמצעות Cloud Monitoring כדי לבדוק אם הסביבה שלכם עומדת ביעדי רמת השירות (SLO) שהגדרתם. מכיוון שאופטימיזציה היא משימה שלא נגמרת, וצריך לחזור על לולאת האופטימיזציה, אפילו אוטומציות קטנות יכולות לשפר משמעותית את היעילות.

מעקב אחרי לולאת האופטימיזציה

כמו שעשיתם לכל המשאבים בסביבה שלכם, אתם צריכים לעקוב אחרי לולאת האופטימיזציה כדי לוודא שהיא פועלת כמצופה, וגם לחפש צווארי בקבוק ויעדי אופטימיזציה עתידיים. כדי להתחיל לעקוב אחרי הלולאה, אתם יכולים לעקוב אחרי הזמן והמשאבים שהצוותים שלכם השקיעו בכל שלב אופטימיזציה. לדוגמה, אפשר להשתמש במערכת למעקב אחרי בעיות ובכלי לניהול פרויקטים כדי לעקוב אחרי התהליכים ולהפיק נתונים סטטיסטיים רלוונטיים לגבי מדדים כמו זמן פתרון הבעיה והזמן עד לסיום.

המאמרים הבאים

שותפים ביצירת התוכן

מחבר: Marco Ferrari | Cloud Solutions Architect