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

Last reviewed 2024-12-07 UTC

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

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

התרשים הבא מדגים את תהליך ההעברה.

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

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

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

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

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

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

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

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

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

במסמך הזה נדון בכמה מהעקרונות והמושגים של Site Reliability Engineering (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 כדי ליצור, לתזמן, לנטר ולנהל את תהליכי העבודה. אפשר גם לתאר את התהליכים באמצעות שפה כמו מודל וסימון של תהליכים עסקיים (BPMN). לאחר מכן, תוכלו להגדיר את התהליכים האלה באמצעות שפה סטנדרטית כמו שפת ביצוע תהליכים עסקיים (BPEL). אחרי שמאמצים IaC, תיאור התהליכים באמצעות קוד מאפשר לכם לנהל אותם כמו את שאר הסביבה.

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

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

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

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

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

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

מחבר: Marco Ferrari | Cloud Solutions Architect