המסמך הזה יעזור לכם לתכנן ולעצב את שלב האופטימיזציה של המעבר אל Google Cloud. אחרי שפורסים את עומסי העבודה ב- Google Cloud, אפשר להתחיל לבצע אופטימיזציה של הסביבה.
המסמך הזה הוא חלק מסדרה של כמה מאמרים בנושא מעבר אלGoogle Cloud:
- מעבר אל Google Cloud: תחילת העבודה
- מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה
- מעבר אל Google Cloud: תכנון ובניית הבסיס
- מעבר אל Google Cloud: העברת מערכי נתונים גדולים
- העברה אל Google Cloud: פריסת עומסי העבודה
- העברה אל Google Cloud: מעבר מפריסות ידניות לפריסות אוטומטיות מבוססות קונטיינרים
- מעבר אל Google Cloud: אופטימיזציה של הסביבה (המסמך הזה)
- מעבר אל Google Cloud: שיטות מומלצות לאימות של תוכנית העברה
- העברה אל Google Cloud: צמצום עלויות
התרשים הבא מדגים את התהליך של המעבר.
בשלב האופטימיזציה, משפרים את הסביבה כדי שהיא תהיה יעילה יותר מהפריסה הראשונית.
המסמך הזה שימושי אם אתם מתכננים לבצע אופטימיזציה של סביבה קיימת אחרי מעבר ל- Google Cloud, או אם אתם בודקים את האפשרות לבצע אופטימיזציה ורוצים לראות איך זה יכול להיראות.
המבנה של שלב האופטימיזציה מבוסס על מסגרת ההעברה שמתוארת בסדרה הזו: הערכה, תכנון, פריסה ואופטימיזציה. אתם יכולים להשתמש במסגרת הגמישה הזו כדי לתכנן את כל תהליך ההעברה ולפרק את הפעולות העצמאיות בכל שלב. אחרי שמסיימים את השלב האחרון של האופטימיזציה, אפשר להתחיל את השלב הזה מחדש ולמצוא יעדים חדשים לאופטימיזציה. שלב האופטימיזציה מוגדר כלולאת אופטימיזציה. ביצוע של הלולאה מוגדר כאיטרציה של אופטימיזציה.
אופטימיזציה היא משימה מתמשכת. אתם מבצעים אופטימיזציה מתמדת של הסביבה שלכם כשהיא מתפתחת. כדי להימנע ממאמצים לא מבוקרים ומכפולים, אפשר להגדיר יעדי אופטימיזציה מדידים ולהפסיק כשמשיגים את היעדים האלה. לאחר מכן, תמיד אפשר להגדיר יעדים חדשים ושאיפות יותר, אבל חשוב לזכור שלאופטימיזציה יש עלות, מבחינת משאבים, זמן, מאמץ ומיומנויות.
התרשים הבא מציג את לולאת האופטימיזציה.
כדי לראות גרסה גדולה יותר של התרשים הזה, אפשר לעיין בעץ ההחלטות בנושא אופטימיזציה.
במאמר הזה תבצעו את השלבים הבאים של לולאת האופטימיזציה, שאפשר לחזור עליהם שוב ושוב:
- להעריך את הסביבה, הצוותים ולולאת האופטימיזציה שאתם פועלים לפיה.
- קובעים את הדרישות והיעדים לאופטימיזציה.
- מבצעים אופטימיזציה של הסביבה ומכשירים את הצוותים.
- שיפור של לולאת האופטימיזציה.
במסמך הזה נדון בכמה מהעקרונות והמושגים של Site Reliability Engineering (SRE). Google פיתחה את תחום ה-SRE כדי להפעיל ביעילות ובאמינות תשתית גלובלית שמשרתת מיליארדי משתמשים. יכול להיות שיהיה לא מעשי לאמץ את כללי ה-SRE בארגון אם תצטרכו לשנות הרבה מהתהליכים העסקיים ותהליכי שיתוף הפעולה שלכם. יכול להיות שיהיה פשוט יותר ליישם קבוצת משנה של עקרונות SRE שמתאימים לארגון שלכם.
הערכה של הסביבה, הצוותים ולולאת האופטימיזציה
לפני שמתחילים במשימת אופטימיזציה, צריך להעריך את הסביבה. צריך גם להעריך את הכישורים של הצוותים, כי יכול להיות שיידרשו כישורים שחסרים להם כדי לבצע אופטימיזציה של הסביבה. לבסוף, צריך להעריך את לולאת האופטימיזציה. הלולאה היא משאב שאפשר לבצע בו אופטימיזציה כמו בכל משאב אחר.
הערכת הסביבה
אתם צריכים להבין לעומק את הסביבה שלכם. כדי לבצע אופטימיזציה מוצלחת, אתם צריכים להבין איך הסביבה שלכם פועלת ולזהות תחומים פוטנציאליים לשיפור. ההערכה הזו קובעת נקודת התייחסות כדי שתוכלו להשוות את ההערכה שלכם לשלב האופטימיזציה ולחזרות האופטימיזציה הבאות.
העברה אל Google Cloud: הערכה וגילוי של עומסי עבודה כולל הנחיות מפורטות לגבי הערכת עומסי העבודה והסביבות שלכם. אם לאחרונה השלמתם העברה אל Google Cloud, כבר יש לכם מידע מפורט על האופן שבו הסביבה שלכם מוגדרת, מנוהלת ומתוחזקת. אחרת, תוכלו להשתמש בהנחיות האלה כדי להעריך את הסביבה שלכם.
הערכת הצוותים
אחרי שמבינים את הסביבה, צריך להעריך את הצוותים כדי להבין את הכישורים שלהם. מתחילים ברשימה של כל הכישורים, רמת המומחיות בכל כישור, ומי מחברי הצוות הכי מומחה בכל כישור. אפשר להשתמש בהערכה הזו בשלב הבא כדי לגלות אילו מיומנויות חסרות לכם כדי להשיג את יעדי האופטימיזציה. לדוגמה, אם אתם מתחילים להשתמש בשירות מנוהל, אתם צריכים את המיומנויות הדרושות כדי להקצות משאבים, להגדיר את השירות ולקיים איתו אינטראקציה. אם רוצים להוסיף שכבת אחסון במטמון לאפליקציה בסביבה באמצעות Memorystore, צריך מומחיות כדי להשתמש בשירות הזה.
חשוב לזכור שאופטימיזציה של הסביבה עשויה להשפיע על התהליכים העסקיים ועל שיתוף הפעולה. לדוגמה, אם מתחילים להשתמש בשירות שמנוהל במלואו במקום בשירות בניהול עצמי, אפשר לתת למפעילים יותר זמן לצמצם את הטרחה.
הערכת לולאת האופטימיזציה
גם את לולאת האופטימיזציה אפשר לשפר. השתמשו בנתונים שנאספו בתהליך הבדיקה הזה כדי לקבל תובנות ברורות לגבי הביצועים של הצוותים שלכם במהלך איטרציית האופטימיזציה האחרונה. לדוגמה, אם המטרה היא לקצר את משך האיטרציה, צריך נתונים על האיטרציה האחרונה, כולל המורכבות שלה והיעדים שהוגדרו. בנוסף, צריך מידע על כל החסימות שנתקלתם בהן במהלך האיטרציה האחרונה, כדי לוודא שיש לכם אסטרטגיית צמצום סיכונים למקרה שהחסימות האלה יחזרו.
אם זהו תהליך האופטימיזציה הראשון, יכול להיות שלא יהיו לכם מספיק נתונים כדי ליצור בסיס להשוואה של הביצועים. מנסחים קבוצה של השערות לגבי הביצועים הצפויים של הצוותים במהלך האיטרציה הראשונה. אחרי איטרציית האופטימיזציה הראשונה, כדאי להעריך את הלולאה ואת הביצועים של הצוותים שלכם, ולהשוות אותם להשערות.
הגדרת הדרישות והיעדים של האופטימיזציה
לפני שמתחילים במשימת אופטימיזציה, כדאי לנסח קבוצה של יעדים מדידים ברורים לאיטרציה.
בשלב הזה מבצעים את הפעולות הבאות:
- מגדירים את דרישות האופטימיזציה.
- מגדירים יעדי אופטימיזציה מדידים בהתאם לדרישות האופטימיזציה.
הגדרת דרישות האופטימיזציה
אתם מפרטים את הדרישות שלכם לשלב האופטימיזציה. דרישה מבטאת צורך בשיפור, ולא בהכרח צריכה להיות מדידה.
אפשר להתחיל עם קבוצה של מאפייני איכות לעומסי העבודה, לסביבה וללולאת האופטימיזציה שלכם, ולנסח שאלון שיעזור לכם להגדיר את הדרישות. השאלון כולל מאפיינים שחשובים לכם בסביבה, בתהליכים ובעומסי העבודה.
יש הרבה מקורות שיכולים לעזור לכם להגדיר את מאפייני האיכות. לדוגמה, בתקן ISO/IEC 25010 מוגדרים מאפייני האיכות של מוצר תוכנה, או שאפשר לעיין בGoogle Cloud רשימת המשימות להגדרה.
לדוגמה, בשאלון אפשר לשאול את השאלות הבאות:
- האם התשתית והרכיבים שלה יכולים להתרחב אנכית או אופקית?
- האם התשתית שלכם תומכת בביטול שינויים ללא התערבות ידנית?
- האם כבר יש לך מערכת ניטור שמכסה את התשתית ואת עומסי העבודה שלך?
- האם יש לכם מערכת לניהול אירועי אבטחה בתשתית שלכם?
- כמה זמן ומאמץ נדרשים כדי להטמיע את האופטימיזציות המתוכננות?
- האם הצלחת להשיג את כל היעדים באיטרציות הקודמות?
על סמך התשובות לשאלון, יוצרים טיוטה של רשימת הדרישות לאיטרציה הזו של האופטימיזציה. לדוגמה, יכול להיות שהדרישות שלכם יהיו:
- שיפור הביצועים של אפליקציה.
- הגדלת הזמינות של רכיב בסביבה.
- שיפור המהימנות של רכיב בסביבה.
- להפחית את העלויות התפעוליות של הסביבה.
- לקצר את משך האיטרציה של האופטימיזציה כדי להפחית את הסיכונים הטמונים בה.
- הגברת מהירות הפיתוח וקיצור זמן היציאה לשוק.
אחרי שרואים את רשימת התחומים לשיפור, בודקים את הדרישות שמופיעות ברשימה. במהלך ההערכה הזו, מנתחים את דרישות האופטימיזציה, מחפשים התנגשויות ונותנים עדיפות לדרישות ברשימה. לדוגמה, שיפור הביצועים של אפליקציה מסוימת עלול להתנגש עם צמצום העלויות התפעוליות.
הגדרת יעדים מדידים
אחרי שמסיימים את רשימת הדרישות, מגדירים יעדים מדידים לכל דרישה. יעד יכול לתרום ליותר מדרישה אחת. אם יש לכם תחום לא ברור או שאתם לא מצליחים להגדיר את כל המטרות שאתם צריכים כדי לעמוד בדרישות, אתם צריכים לחזור לשלב ההערכה של האיטרציה הזו כדי לאסוף את כל המידע שחסר, ואז לשפר את הדרישות.
כדי להגדיר את היעדים האלה, אפשר לפעול לפי אחד מהעקרונות של SRE, הגדרת אינדיקטורים ברמת השרת (SLIs) ויעדים למדידת רמת השירות (SLOs):
- אינדיקטורים ברמת השירות (SLIs) הם מדדים כמותיים של רמת השירות שאתם מספקים. לדוגמה, מדד SLI מרכזי יכול להיות חביון ממוצע של בקשות, שיעור שגיאות או תפוקת המערכת.
- יעדים למדידת רמת השירות (SLOs) הם ערכי יעד או טווחי ערכים לרמת שירות שנמדדת על ידי אינדיקטור למדידת רמת השירות (SLI). לדוגמה, יעד רמת שירות יכול להיות שהחביון הממוצע של הבקשות יהיה נמוך מ-100 אלפיות השנייה.
אחרי שמגדירים את מדדי ה-SLI ואת יעדי ה-SLO, יכול להיות שמבינים שלא אוספים את כל המדדים שצריך כדי למדוד את מדדי ה-SLI. היעד הראשון לאופטימיזציה שאתם יכולים לטפל בו הוא איסוף המדדים האלה. אתם מגדירים את היעדים שקשורים להרחבת מערכת המעקב כדי לאסוף את כל המדדים שאתם צריכים עבור מחווני רמת השירות (SLI).
אופטימיזציה של הסביבה והצוותים
אחרי שמעריכים את הסביבה, הצוותים ולולאת האופטימיזציה, וקובעים את הדרישות והיעדים של האיטרציה הזו, אפשר לבצע את שלב האופטימיזציה.
בשלב הזה מבצעים את הפעולות הבאות:
- מדידה של הסביבה, הצוותים ולולאת האופטימיזציה.
- ניתוח הנתונים שמגיעים מהמדידות האלה.
- מבצעים את פעולות האופטימיזציה.
- מבצעים מדידה וניתוח מחדש.
מדידה של הסביבה, הצוותים ולולאת האופטימיזציה
מרחיבים את מערכת המעקב כדי לאסוף נתונים על ההתנהגות של הסביבה, הצוותים ולולאת האופטימיזציה, כדי ליצור בסיס להשוואה אחרי האופטימיזציה.
הפעילות הזו מתבססת על מה שעשיתם בשלב ההערכה ומרחיבה אותו. אחרי שמגדירים את הדרישות והיעדים, יודעים אילו מדדים צריך לאסוף כדי שהמדידות יהיו רלוונטיות ליעדי האופטימיזציה. לדוגמה, אם הגדרתם יעדי רמת שירות (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 ולנתח את הנתונים באמצעות Looker Studio כדי להבין כמה משאבים אתם צורכים ולזהות דפוסי הוצאות.
לבסוף, משווים את הסביבה שלכם לסביבה שבה אין חוב טכני, כדי לראות אם אתם עומדים ביעדים לטווח הארוך, וכדי לבדוק אם החוב הטכני גדל. לדוגמה, אפשר להגדיר SLO למספר המשאבים בסביבה שאתם עוקבים אחריהם לעומת מספר המשאבים שהקציתם מאז האיטרציה האחרונה. אם לא הרחבתם את מערכת המעקב כך שתכלול את המשאבים החדשים האלה, החוב הטכני שלכם גדל. כשמנתחים את השינויים בחוב הטכני, חשוב לקחת בחשבון גם את הגורמים שהובילו לשינויים האלה. לדוגמה, צורך עסקי עשוי לדרוש הגדלה של החוב הטכני, או שהוא עשוי להיות בלתי צפוי. הכרת הגורמים שגרמו לשינוי בחוב הטכני מאפשרת לכם לקבל תובנות לגבי יעדי אופטימיזציה עתידיים.
כדי לעקוב אחרי הסביבה שלכם ב- Google Cloud, אתם יכולים להשתמש ב-Monitoring כדי לעצב תרשימים, מרכזי בקרה והתראות. לאחר מכן תוכלו לנתב את הנתונים של Cloud Logging כדי לבצע ניתוח מעמיק יותר ולהאריך את תקופת השמירה. לדוגמה, אתם יכולים ליצור מאגרי נתונים מצטברים ולהשתמש ב-Cloud Storage, ב-Pub/Sub או ב-BigQuery כיעדים. אם מייצאים נתונים ל-BigQuery, אפשר להשתמש ב-Looker Studio כדי ליצור תרשימים וגרפים של הנתונים, לזהות מגמות ולבצע תחזיות. אתם יכולים גם להשתמש בכלי הערכה כמו Recommender ו-Security Command Center כדי לנתח באופן אוטומטי את הסביבה והתהליכים שלכם ולחפש יעדי אופטימיזציה.
אחרי ניתוח כל נתוני המדידה, צריך לענות על שתי שאלות:
האם אתם עומדים ביעדי האופטימיזציה?
אם התשובה היא כן, סימן שסיימתם את איטרציית האופטימיזציה הזו ואפשר להתחיל חדשה. אם עניתם לא, אפשר לעבור לשאלה השנייה.
בהתחשב במשאבים שהקציתם בתקציב, האם תוכלו להשיג את יעדי האופטימיזציה שהגדרתם לאיטרציה הזו?
כדי לענות על השאלה הזו, צריך לקחת בחשבון את כל המשאבים שנדרשים, כמו זמן, כסף ומומחיות. אם עניתם כן, אתם יכולים לעבור לקטע הבא. אחרת, כדאי לשפר את יעדי האופטימיזציה שלכם, תוך התחשבות במשאבים שבהם אתם יכולים להשתמש באיטרציה הזו. לדוגמה, אם אתם מוגבלים על ידי לוח זמנים קבוע, יכול להיות שתצטרכו לתזמן כמה יעדי אופטימיזציה לאיטרציה הבאה.
אופטימיזציה של הצוותים
אופטימיזציה של הסביבה היא אתגר מתמשך, ועשוי להיות שחסרים לצוותים שלכם כישורים מסוימים שגיליתם במהלך ההערכה והניתוח. לכן, כדי שהפעולות שלכם לשיפור הביצועים יצליחו, חשוב לרכוש מיומנויות חדשות ולשפר את היעילות של התהליכים.
כדי לבצע אופטימיזציה של הצוותים, צריך לבצע את הפעולות הבאות:
- עיצוב והטמעה של תוכנית הדרכה.
- אופטימיזציה של מבנה הצוות והתרבות הארגונית.
כדי שהצוותים שלכם ירכשו את הכישורים שחסרים להם, אתם צריכים לתכנן וליישם תוכנית הדרכה, או לבחור תוכנית שהוכנה על ידי מאמנים מקצועיים של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, Cloud Composer ו-Cloud Run, שצוותי הפיתוח יכולים להשתמש בהם כדי לבצע אוטומציה של משימות חוזרות.
מעקב אחרי הכול
אם לא תוכלו לאסוף מדדים מפורטים לגבי הסביבה שלכם, לא תוכלו לשפר אותה כי לא יהיו לכם נתונים שיאשרו את ההנחות שלכם. המשמעות היא שאתם לא יודעים מה לעשות כדי להשיג את יעדי האופטימיזציה.
מערכת מעקב מקיפה היא רכיב הכרחי בסביבה שלכם. המערכת עוקבת אחרי כל המדדים החיוניים שצריך להעריך כדי להשיג את יעדי האופטימיזציה. כשמתכננים את מערכת המעקב, חשוב לתכנן מעקב אחרי ארבעת אותות הזהב לפחות.
אתם יכולים להשתמש בשירותים מנוהלים כמו Monitoring ו-Logging כדי לעקוב אחרי הסביבה שלכם בלי שתצטרכו להגדיר פתרון מורכב למעקב.
יכול להיות שתצטרכו להטמיע מערכת מעקב שיכולה לעקוב אחרי סביבות היברידיות וסביבות מרובות עננים כדי לעמוד בדרישות של מדיניות הגבלת נתונים שמחייבת אתכם לאחסן נתונים רק במיקומים פיזיים מסוימים, או בשירותים שמשתמשים בכמה סביבות ענן בו-זמנית.
אימוץ גישה שמתאימה לענן
מוכנות לענן היא פרדיגמה שמתארת דרך יעילה לעיצוב ולהפעלה של אפליקציה בענן. קרן 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: צמצום עלויות.
מדידה וניתוח חוזרים
אחרי שמשלימים את פעולות האופטימיזציה של האיטרציה הזו, חוזרים על המדידות ועל הניתוח כדי לבדוק אם הגעתם ליעדים שהגדרתם. עליכם לענות על השאלה הבאה:
האם עמדתם ביעדי האופטימיזציה?
אם עניתם כן, אתם יכולים לעבור לקטע הבא.
אם התשובה היא לא, צריך לחזור לתחילת השלב של אופטימיזציה של הסביבה והצוותים.
שיפור של לולאת האופטימיזציה
בקטע הזה, מעדכנים ומשנים את לולאת האופטימיזציה שפעלתם לפיה באיטרציה הזו, כדי שתתאים יותר למבנה ולסביבה של הצוות.
הגדרת לולאת האופטימיזציה
כדי לבצע אופטימיזציה יעילה של לולאת האופטימיזציה, צריך לתעד ולהגדיר את הלולאה בפורמט סטנדרטי, פשוט ונוח לניהול, שמאפשר לבצע שינויים. אתם יכולים להשתמש בשירות מנוהל באופן מלא כמו Cloud Composer כדי ליצור, לתזמן, לנטר ולנהל את תהליכי העבודה. אפשר גם לתאר את התהליכים באמצעות שפה כמו מודל וסימון של תהליכים עסקיים (BPMN). אחרי כן, תוכלו להגדיר את התהליכים האלה באמצעות שפה סטנדרטית כמו שפת ביצוע תהליכים עסקיים (BPEL). אחרי שמאמצים IaC, אפשר לתאר את התהליכים באמצעות קוד ולנהל אותם כמו את שאר הסביבה.
אוטומציה של לולאת האופטימיזציה
אחרי שמגדירים את לולאת האופטימיזציה, אפשר להגדיר אוטומציה של משימות שחוזרות על עצמן כדי לחסוך זמן, להפחית את העומס ולשפר את היעילות של לולאת האופטימיזציה. אתם יכולים להתחיל להפוך לאוטומטיות את כל המשימות שלא דורשות החלטה אנושית, כמו מדידת נתונים והפקת דוחות מצטברים לניתוח על ידי הצוותים שלכם. לדוגמה, אפשר להגדיר אוטומציה של ניתוח נתונים באמצעות Cloud Monitoring כדי לבדוק אם הסביבה שלכם עומדת ביעדי רמת השירות (SLO) שהגדרתם. האופטימיזציה היא משימה מתמשכת, ואתם חוזרים על לולאת האופטימיזציה שוב ושוב. לכן, גם אוטומציות קטנות יכולות לשפר משמעותית את היעילות.
מעקב אחרי לולאת האופטימיזציה
כמו שעשיתם לכל המשאבים בסביבה שלכם, אתם צריכים לעקוב אחרי לולאת האופטימיזציה כדי לוודא שהיא פועלת כמצופה, וגם לחפש צווארי בקבוק ויעדי אופטימיזציה עתידיים. כדי להתחיל לעקוב אחרי הלולאה, אתם יכולים לעקוב אחרי הזמן והמשאבים שהצוותים שלכם השקיעו בכל שלב באופטימיזציה. לדוגמה, אפשר להשתמש במערכת למעקב אחרי בעיות ובכלי לניהול פרויקטים כדי לעקוב אחרי התהליכים ולהפיק נתונים סטטיסטיים רלוונטיים לגבי מדדים כמו זמן פתרון הבעיה והזמן עד לסיום.
המאמרים הבאים
- קרא על שיטות מומלצות לאימות תוכנית העברה.
- כדי ללמוד על מושגים וטכניקות אחרים שיעזרו לכם להתכונן לאופטימיזציה, מומלץ לקרוא את ספרי ה-SRE.
- מתי כדאי לפנות לקבלת עזרה בנוגע להעברות
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Marco Ferrari | Cloud Solutions Architect