במאמר הזה נסביר איך לתכנן ולעצב את שלב האופטימיזציה של ההעברה ל- Google Cloud. אחרי שפורסים את עומסי העבודה ב- Google Cloud, אפשר להתחיל לבצע אופטימיזציה של הסביבה.
המסמך הזה הוא חלק מסדרה של כמה חלקים בנושא מעבר ל-Google Cloud:
- העברה אל Google Cloud: איך מתחילים
- העברה אל Google Cloud: הערכה וגילוי של עומסי העבודה
- מעבר אל Google Cloud: תכנון ובניית הבסיס
- מעבר אל Google Cloud: העברת קבוצות נתונים גדולות
- העברה אל Google Cloud: פריסת עומסי העבודה
- מעבר ל- Google Cloud: מעבר מפריסות ידניות לפריסות אוטומטיות בקונטיינרים
- מעבר ל- Google Cloud: אופטימיזציה של הסביבה (המסמך הזה)
- Migrate to Google Cloud: שיטות מומלצות לאימות תוכנית מיגרציה
- מעבר אל Google Cloud: צמצום העלויות
התרשים הבא ממחיש את נתיב תהליך המיגרציה שלכם.
בשלב האופטימיזציה, אתם משפרים את הסביבה כדי להפוך אותה ליעילה יותר מהפריסה הראשונית.
המסמך הזה שימושי אם אתם מתכננים לבצע אופטימיזציה לסביבה קיימת אחרי המעבר ל- Google Cloud, או אם אתם בוחנים את האפשרות לבצע אופטימיזציה ורוצים לראות איך זה ייראה.
המבנה של שלב האופטימיזציה תואם למסגרת ההעברה שמתוארת בסדרה הזו: הערכה, תכנון, פריסה ואופטימיזציה. אתם יכולים להשתמש במסגרת הזו כדי לתכנן את כל תהליך ההעברה ולפרק את הפעולות הבלתי תלויות בכל שלב. אחרי שתשלימו את השלב האחרון של שלב האופטימיזציה, תוכלו להתחיל את השלב הזה מחדש ולמצוא יעדים חדשים לאופטימיזציה. שלב האופטימיזציה מוגדר כלולאת אופטימיזציה. כל הפעלה של הלולאה מוגדרת כאיטרציית אופטימיזציה.
אופטימיזציה היא משימה מתמשכת. אתם מבצעים אופטימיזציה של הסביבה שלכם באופן קבוע ככל שהיא מתפתחת. כדי להימנע ממאמצים כפולים ולא מבוקרים, אתם יכולים להגדיר יעדי אופטימיזציה מדידים ולהפסיק כשתגיעו ליעדים האלה. לאחר מכן, תמיד תוכלו להגדיר יעדים חדשים ושאפתניים יותר, אבל קחו בחשבון שלאופטימיזציה יש עלות מבחינת משאבים, זמן, מאמץ ומיומנויות.
בתרשים הבא מוצגת לולאת האופטימיזציה.
כדי לראות תמונה גדולה יותר של התרשים, אפשר לעיין בעץ ההחלטות לאופטימיזציה.
במאמר הזה תבצעו את השלבים הבאים שניתן לחזור עליהם בלולאת האופטימיזציה:
- העריכו את הסביבה, הצוותים ולולאת האופטימיזציה שאתם פועלים לפיה.
- מגדירים דרישות ויעדים לאופטימיזציה.
- אופטימיזציה של הסביבה והדרכת הצוותים.
- לכוונן את לולאת האופטימיזציה.
במאמר הזה נסביר כמה מהעקרונות והמושגים של הנדסת אמינות אתרים (SRE). Google פיתחה את תחום ה-SRE כדי להפעיל ביעילות ובאמינות תשתית גלובלית שמשרתת מיליארדי משתמשים. אם אתם צריכים לשנות הרבה מהתהליכים העסקיים ותהליכי שיתוף הפעולה, יכול להיות שלא יהיה מעשי לאמץ את כל תחום ה-SRE בארגון. יכול להיות שיהיה פשוט יותר ליישם קבוצת משנה של תחום ה-SRE שהכי מתאימה לארגון שלכם.
הערכת הסביבה, הצוותים ולולאת האופטימיזציה
לפני שמתחילים במשימת אופטימיזציה, צריך להעריך את הסביבה. כדאי גם להעריך את המיומנויות של הצוותים, כי יכול להיות שחסרות להם מיומנויות שנדרשות כדי לבצע אופטימיזציה של הסביבה. לבסוף, צריך להעריך את לולאת האופטימיזציה. הלולאה היא משאב שאפשר לבצע בו אופטימיזציה כמו בכל משאב אחר.
הערכת הסביבה
אתם צריכים להבין לעומק את הסביבה שלכם. כדי לבצע אופטימיזציה מוצלחת, צריך להבין איך הסביבה פועלת ולזהות תחומים פוטנציאליים לשיפור. ההערכה הזו יוצרת נקודת השוואה, כדי שתוכלו להשוות את ההערכה לשלב האופטימיזציה ולסבבי האופטימיזציה הבאים.
במאמר העברה אל Google Cloud: הערכה וגילוי של עומסי העבודה יש הנחיות מפורטות להערכת עומסי העבודה והסביבות. אם לאחרונה השלמתם את ההעברה ל-Google Cloud, כבר יש לכם מידע מפורט על האופן שבו הסביבה שלכם מוגדרת, מנוהלת ומתוחזקת. אחרת, אתם יכולים להשתמש בהנחיות האלה כדי להעריך את הסביבה שלכם.
הערכת הצוותים
אחרי שתבינו את הסביבה שלכם, העריכו את הצוותים כדי להבין את הכישורים שלהם. מתחילים ביצירת רשימה של כל המיומנויות, רמת המומחיות בכל מיומנות, ואילו חברי צוות הם בעלי הידע הרב ביותר בכל מיומנות. השתמשו בהערכה הזו בשלב הבא כדי לגלות אילו מיומנויות חסרות לכם כדי להגיע ליעדי האופטימיזציה. לדוגמה, אם אתם מתחילים להשתמש בשירות מנוהל, אתם צריכים את המיומנויות כדי להקצות את השירות, להגדיר אותו ולתקשר איתו. אם אתם רוצים להוסיף שכבת מטמון לאפליקציה בסביבה שלכם באמצעות Memorystore, אתם צריכים מומחיות כדי להשתמש בשירות הזה.
חשוב לזכור שאופטימיזציה של הסביבה יכולה להשפיע על התהליכים העסקיים ועל תהליכי שיתוף הפעולה. לדוגמה, אם תתחילו להשתמש בשירות שמנוהל במלואו במקום בשירות בניהול עצמי, תוכלו לתת למפעילים יותר זמן להיפטר מעבודה מיותרת.
הערכת לולאת האופטימיזציה
לולאת האופטימיזציה היא משאב שגם אותו אפשר לשפר. השתמשו בנתונים שנאספו בהערכה הזו כדי לקבל תובנות ברורות לגבי הביצועים של הצוותים במהלך סבב האופטימיזציה האחרון. לדוגמה, אם אתם רוצים לקצר את משך האיטרציה, אתם צריכים נתונים על האיטרציה האחרונה, כולל המורכבות שלה והיעדים שניסיתם להשיג. אתם צריכים גם מידע על כל החסימות שנתקלתם בהן במהלך האיטרציה האחרונה, כדי לוודא שיש לכם אסטרטגיית הקלה אם החסימות האלה יחזרו על עצמן.
אם זהו סבב האופטימיזציה הראשון, יכול להיות שאין לכם מספיק נתונים כדי לקבוע קו בסיס להשוואת הביצועים. מנסחים קבוצה של השערות לגבי הביצועים הצפויים של הצוותים במהלך האיטרציה הראשונה. אחרי האיטרציה הראשונה של האופטימיזציה, מעריכים את הלולאה ואת ביצועי הצוותים ומשווים אותם להשערות.
הגדרת הדרישות והיעדים של האופטימיזציה
לפני שמתחילים במשימת אופטימיזציה, כדאי לנסח קבוצה של יעדים מדידים וברורים לאיטרציה.
בשלב הזה מבצעים את הפעולות הבאות:
- מגדירים את דרישות האופטימיזציה.
- הגדירו יעדי אופטימיזציה מדידים בהתאם לדרישות האופטימיזציה שלכם.
הגדרת דרישות האופטימיזציה
אתם מפרטים את הדרישות שלכם לשלב האופטימיזציה. דרישה מבטאת צורך בשיפור, והיא לא בהכרח חייבת להיות ניתנת למדידה.
כדי להגדיר את הדרישות, אתם יכולים להכין שאלון שמבוסס על קבוצה של מאפייני איכות של עומסי העבודה, הסביבה ולולאת האופטימיזציה שלכם. השאלון כולל את המאפיינים שחשובים לסביבה, לתהליכים ולעומסי העבודה שלכם.
יש הרבה מקורות שיכולים לעזור לכם להגדיר את מאפייני האיכות. לדוגמה, תקן ISO/IEC 25010 מגדיר את מאפייני האיכות של מוצר תוכנה, ואפשר גם לעיין בGoogle Cloud רשימת המשימות להגדרה.
לדוגמה, השאלון יכול לכלול את השאלות הבאות:
- האם אפשר להגדיל או להקטין את התשתית והרכיבים שלה בצורה אנכית או אופקית?
- האם התשתית שלכם תומכת בביטול שינויים בלי התערבות ידנית?
- האם כבר יש לכם מערכת מעקב שמכסה את התשתית ואת עומסי העבודה?
- האם יש לכם מערכת לניהול אירועים בתשתית שלכם?
- כמה זמן ומאמץ נדרשים כדי ליישם את האופטימיזציות המתוכננות?
- האם הצלחת להשיג את כל היעדים בסבבים הקודמים?
על סמך התשובות לשאלון, אתם מכינים טיוטה של רשימת הדרישות לסבב האופטימיזציה הזה. לדוגמה, יכול להיות שהדרישות שלכם יהיו:
- לשפר את הביצועים של אפליקציה.
- להגדיל את הזמינות של רכיב בסביבה שלכם.
- לשפר את האמינות של רכיב בסביבה שלכם.
- להפחית את עלויות התפעול של הסביבה.
- כדי לצמצם את הסיכונים, כדאי לקצר את משך הזמן של כל איטרציה של אופטימיזציה.
- להגביר את מהירות הפיתוח ולקצר את זמן היציאה לשוק (Time to market).
אחרי שיוצרים את רשימת התחומים לשיפור, בודקים את הדרישות שברשימה. בשלב הזה אתם מנתחים את דרישות האופטימיזציה, מחפשים התנגשויות ומתעדפים את הדרישות ברשימה. לדוגמה, שיפור הביצועים של אפליקציה עלול להתנגש עם הפחתת עלויות התפעול.
הגדרת יעדים מדידים
אחרי שאתם מסיימים את רשימת הדרישות, הגדירו יעדים מדידים לכל דרישה. יעד מסוים יכול לתרום ליותר מדרישה אחת. אם יש לכם ספקות או שאתם לא מצליחים להגדיר את כל היעדים שאתם צריכים כדי לעמוד בדרישות, חזרו לשלב ההערכה של האיטרציה הזו כדי לאסוף את המידע החסר, ואז שפרו את הדרישות.
כדי להגדיר את היעדים האלה, אתם יכולים לפעול לפי אחד מתחומי ה-SRE, ההגדרה של מדדי רמת שירות (SLI) ויעדים למדידת רמת השירות (SLO):
- מדדי SLI הם מדדים כמותיים של רמת השירות שאתם מספקים. לדוגמה, SLI מרכזי יכול להיות זמן האחזור הממוצע של בקשה, שיעור השגיאות או קצב העברת הנתונים במערכת.
- יעדים למדידת רמת השירות (SLOs) הם ערכי יעד או טווחי ערכים של רמת שירות שנמדדת על ידי SLI. לדוגמה, יעד SLO יכול להיות שזמן האחזור הממוצע של בקשה יהיה פחות מ-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 מסמכי ה-Whitepaper כנקודות התחלה למציאת מיומנויות חדשות שהצוותים שלכם עשויים להזדקק להן כדי לבצע אופטימיזציה של הסביבה שלכם.
ניתוח נתונים
אחרי שאוספים את הנתונים, מנתחים ומעריכים אותם כדי להבין איך הסביבה, הצוותים ולולאת האופטימיזציה פועלים ביחס לדרישות וליעדי האופטימיזציה.
באופן ספציפי, אתם בודקים את הסביבה שלכם לפי:
- יעדי 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 כדי לנתח באופן אוטומטי את הסביבה והתהליכים שלכם, ולחפש יעדים לאופטימיזציה.
אחרי שמנתחים את כל נתוני המדידה, צריך לענות על שתי שאלות:
האם אתם עומדים ביעדי האופטימיזציה שלכם?
אם התשובה היא כן, סבב האופטימיזציה הזה הסתיים ואפשר להתחיל סבב חדש. אם עניתם לא, אתם יכולים לעבור לשאלה השנייה.
בהתחשב במשאבים שהקציתם, האם אתם יכולים להשיג את יעדי האופטימיזציה שהגדרתם לאיטרציה הזו?
כדי לענות על השאלה הזו, חשבו על כל המשאבים שאתם צריכים, כמו זמן, כסף ומומחיות. אם התשובה היא כן, אפשר לעבור לחלק הבא. אם לא, צריך לשפר את יעדי האופטימיזציה בהתאם למשאבים שאפשר להשתמש בהם באיטרציה הזו. לדוגמה, אם אתם מוגבלים בלוח זמנים קבוע, יכול להיות שתצטרכו לתזמן כמה יעדי אופטימיזציה לאיטרציה הבאה.
אופטימיזציה של הצוותים
אופטימיזציה של הסביבה היא אתגר מתמשך, ויכול להיות שהיא דורשת מיומנויות שאין לצוותים שלכם, כפי שגיליתם במהלך ההערכה והניתוח. לכן, כדי שהפעילויות שלכם יצליחו, חשוב מאוד לבצע אופטימיזציה של הצוותים על ידי רכישת מיומנויות חדשות וייעול התהליכים.
כדי לבצע אופטימיזציה של הצוותים, צריך:
- תכנון והטמעה של תוכנית הדרכה.
- לשפר את המבנה והתרבות של הצוות.
כדי שהצוותים שלכם ירכשו את המיומנויות שחסרות להם, אתם צריכים לתכנן ולהטמיע תוכנית הכשרה או לבחור תוכנית שהוכנה על ידי מדריכים מקצועיים שלGoogle Cloud . מידע נוסף זמין במאמר העברה אל Google Cloud: הערכה וגילוי של עומסי העבודה.
בזמן שאתם מבצעים אופטימיזציה של הצוותים, יכול להיות שתגלו שיש מקום לשפר את המבנה והתרבות. קשה להגדיר מראש מצב אידיאלי, כי לכל חברה יש היסטוריה וייחודיות משלה שתרמו להתפתחות המבנה והתרבות של הצוותים.
מנהיגות טרנספורמטיבית היא נקודת מוצא טובה ללמידת מסגרות כלליות לביצוע ולמדידה של שינויים ארגוניים שמטרתם לאמץ שיטות DevOps. בספר Site Reliability Engineering, שמתאר באופן מקיף את מתודולוגיית ה-SRE, תוכלו למצוא הנחיות מעשיות להטמעת תרבות DevOps יעילה בארגון. בספר Site Reliability Workbook, שהוא ספר נלווה, מוצגות דוגמאות קונקרטיות שמראות איך ליישם את העקרונות והשיטות של SRE.
אופטימיזציה של הסביבה
אחרי שמודדים ומנתחים את נתוני המדדים, יודעים אילו תחומים צריך לשפר.
בקטע הזה מפורטות שיטות כלליות לאופטימיזציה של סביבתGoogle Cloud . אתם יכולים גם לבצע כל פעילות אופטימיזציה שספציפית לתשתית ולשירותים שבהם אתם משתמשים.
הכול בקוד
אחד מהיתרונות הגדולים ביותר של שימוש בסביבת ענן ציבורי כמוGoogle Cloud, הוא שאפשר להשתמש בממשקים מוגדרים היטב כמו Cloud APIs כדי להקצות משאבים, להגדיר אותם ולנהל אותם. אתם יכולים להשתמש בכלים לבחירתכם כדי להגדיר את תהליך התשתית כקוד (IaC), ובמערכות לניהול גרסאות לבחירתכם.
אתם יכולים להשתמש בכלים כמו Terraform כדי להקצות את המשאבים ב- Google Cloud , ואז להשתמש בכלים כמו Ansible, Chef או Puppet כדי להגדיר את המשאבים האלה. תהליך IaC עוזר לכם להטמיע אסטרטגיית חזרה למצב קודם (rollback) יעילה למשימות האופטימיזציה. אתם יכולים לבטל כל שינוי שהחלתם על הקוד שמתאר את התשתית. בנוסף, אתם יכולים לבדוק את השינויים כדי למנוע כשלים לא צפויים בזמן עדכון התשתית.
בנוסף, אתם יכולים להחיל תהליכים דומים כדי להגדיר בקוד היבטים אחרים של הסביבה, כמו מדיניות כקוד, באמצעות כלים כמו 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 Native Computing Foundation (CNCF), אפליקציה מבוססת-ענן מוגדרת כאפליקציה שניתן לשנות את הגודל שלה, שהיא גמישה, ניתנת לניהול ולצפייה באמצעות טכנולוגיות כמו קונטיינרים, רשתות שירות (service mesh), מיקרו-שירותים (microservice), תשתית שלא ניתנת לשינוי וממשקי API הצהרתיים. Google Cloud מספק שירותים מנוהלים כמו GKE, Cloud Run, Cloud Service Mesh, Logging ו-Monitoring, כדי לאפשר למשתמשים לתכנן ולהפעיל אפליקציות שמתאימות לענן.
מידע נוסף על טכנולוגיות מבוססות-ענן זמין במאמרים CNCF Trail Map ו-CNCF Cloud Native Interactive Landscape.
ניהול עלויות
בגלל ההבדלים במודלים של החיוב והעלות, האופטימיזציה של העלויות בסביבת ענן ציבורי כמו Google Cloud שונה מהאופטימיזציה של סביבה מקומית.
מידע נוסף זמין במאמר מעבר אל Google Cloud: צמצום העלויות.
מדידה וניתוח מחדש
אחרי שתסיימו את פעילויות האופטימיזציה של האיטרציה הזו, חזרו על המדידות והניתוח כדי לבדוק אם הגעתם ליעדים. ענו על השאלה הבאה:
האם עמדת ביעדי האופטימיזציה?
אם עניתם כן, אתם יכולים לעבור לחלק הבא.
אם עניתם לא, חזרו לתחילת השלב אופטימיזציה של הסביבה והצוותים.
כוונון לולאת האופטימיזציה
בקטע הזה אתם מעדכנים ומשנים את לולאת האופטימיזציה שביצעתם באיטרציה הזו, כדי להתאים אותה למבנה הצוות ולסביבה שלכם.
הגדרת לולאת האופטימיזציה בקוד
כדי לבצע אופטימיזציה יעילה של לולאת האופטימיזציה, צריך לתעד ולהגדיר את הלולאה בצורה סטנדרטית, פשוטה וניתנת לניהול, שמאפשרת לבצע שינויים. אתם יכולים להשתמש בשירות שמנוהל במלואו, כמו Managed Airflow, כדי ליצור, לתזמן, לעקוב ולנהל את תהליכי העבודה. אתם יכולים גם לייצג קודם את התהליכים שלכם באמצעות שפה כמו מודל וסימון של תהליכים עסקיים (BPMN). אחרי זה, אתם יכולים להגדיר את התהליכים האלה באמצעות שפה סטנדרטית כמו שפת הביצוע של התהליך העסקי (BPEL). אחרי שמאמצים את IaC, אפשר לתאר את התהליכים באמצעות קוד ולנהל אותם כמו שמנהלים את שאר הסביבה.
אוטומציה של לולאת האופטימיזציה
אחרי שיוצרים קוד ללולאת האופטימיזציה, אפשר להפוך משימות שחוזרות על עצמן לאוטומטיות כדי להימנע מעבודה מיותרת, לחסוך זמן ולהפוך את לולאת האופטימיזציה ליעילה יותר. אתם יכולים להתחיל להפוך לאוטומטיות את כל המשימות שלא נדרשת בהן החלטה אנושית, כמו מדידת נתונים והפקת דוחות מצטברים לניתוח על ידי הצוותים שלכם. לדוגמה, אתם יכולים להפוך את ניתוח הנתונים לאוטומטי באמצעות Cloud Monitoring כדי לבדוק אם הסביבה שלכם עומדת ביעדי ה-SLO שהגדרתם. מכיוון שאופטימיזציה היא משימה שלא נגמרת, ואתם חוזרים על לולאת האופטימיזציה, אפילו פעולות אוטומטיות קטנות יכולות לשפר משמעותית את היעילות.
מעקב אחרי לולאת האופטימיזציה
כמו שעשיתם עם כל המשאבים בסביבה שלכם, אתם צריכים לעקוב אחרי לולאת האופטימיזציה כדי לוודא שהיא פועלת כמו שצריך, וגם לחפש צווארי בקבוק ויעדי אופטימיזציה עתידיים. אתם יכולים להתחיל לעקוב אחרי לולאת האופטימיזציה על ידי מעקב אחרי משך הזמן וכמות המשאבים שהצוותים שלכם השקיעו בכל שלב באופטימיזציה. לדוגמה, אתם יכולים להשתמש ב-Issue Tracker ובכלי לניהול פרויקטים כדי לעקוב אחרי התהליכים שלכם ולחלץ נתונים סטטיסטיים רלוונטיים לגבי מדדים כמו זמן פתרון הבעיות וזמן ההשלמה.
המאמרים הבאים
- שיטות מומלצות לאימות של תוכנית העברה
- כדי לקרוא על מושגים ושיטות אחרים שיעזרו לכם להתכונן לאופטימיזציה, קראו את הספרים בנושא SRE.
- איפה אפשר לקבל עזרה בנושא העברות
- השתתפות בקורס ההדרכה של Google Skills בנושא מעבר אל Google Cloud.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Marco Ferrari | Cloud Solutions Architect