במסמך הזה מוסבר איך צוות התמיכה של Google Cloud ומהנדסי המוצר עובדים יחד כדי לטפל באירוע ולעדכן את הלקוחות.
הדיאגרמה הבאה מציגה את תחומי האחריות של צוותי הנדסת המוצר וצוותי התמיכה.
בקטעים הבאים מוסבר על תחומי האחריות האלה.
זיהוי
אנחנו משתמשים בניטור פנימי וסינתטי ב-Google Cloud כדי לזהות אירועים. למידע נוסף, ראו את פרק 6 בחוברת Site Reliability Engineering.
מענה ראשוני
כשמזוהה אירוע, צוות של Google Cloud Service Health מנהל את התקשורת איתכם. בדרך כלל העדכון הראשון על אירועים הוא תמציתי וכולל רק אזכור של המוצר שקשור לאירוע. הסיבה לכך היא שאנחנו מעדיפים להודיע מהר במקום לפרט. בעדכונים הבאים נוכל לפרט יותר.
כדי למסור לכם כמה שיותר מידע בלי להציף אתכם בבעיות שלא משפיעות עליכם, אנחנו משתמשים בערוצי תקשורת שונים בהתאם להיקף ולחומרה של הבעיה:
חקירה
צוותים של מהנדסי מוצר הם שחוקרים את הגורמים לבעיות. פעמים רבות מהנדס בתפקיד Site Reliability Engineer מנהל את האירוע, אבל גם מהנדסי תוכנה או בעלי תפקידים אחרים יכולים לנהל אותו, בהתאם לסיטואציה ולמוצר. למידע נוסף, ראו את פרק 12 בחוברת Site Reliability Engineering.
צמצום הפגיעה ופתרון הבעיה
מבחינת Google, הבעיה נפתרת רק כשמיושמים שינויים שבסבירות גבוהה מאוד יסיימו את האירוע. לדוגמה, הפתרון יכול להיות החזרה למצב קודם (roll back) בעקבות שינוי שגרם לאירוע.
במהלך האירוע, צוותי Service Health והמוצר ינסו להפחית את ההשפעה של הבעיה. הפחתת ההשפעה היא צמצום ההשלכות או ההיקף של הבעיה, לדוגמה, על ידי הקצאת משאבים נוספים באופן זמני למוצר שחווה עומס יתר.
אם לא תימצא דרך להפחית את ההשפעה, נציגי Service Health ינסו למצוא פתרונות זמניים ולעדכן עליהם. פתרונות זמניים הם פעולות שאפשר לבצע כדי לתת מענה לצורך, למרות שהאירוע לא נפתר. פתרון זמני יכול להיות שימוש בהגדרות שונות לקריאה ל-API כדי למנוע נתיב קוד בעייתי.
המשך מעקב
במהלך האירוע, צוות Service Health שולח עדכונים שוטפים. בדר"כ העדכונים כוללים:
מידע נוסף על האירוע, כמו הודעות שגיאה, אזורים או תחומים (zones) שהושפעו, מאפיינים שהושפעו או אחוזי השפעה.
הפעולות שנעשו בניסיון להפחית את ההשפעה, כולל פתרונות זמניים.
לוחות זמנים לתקשורת, בהתאם לאירוע.
שינויים בסטטוס, כמו פתרון האירוע.
ניתוח רטרואקטיבי
כל אירוע מנותח פנימית ב-Google אחרי שהוא מסתיים, כדי להבין את ההיקף המלא שלו ולזהות אפשרויות לשיפור האמינות. השיפורים שמזוהים מיושמים והמעקב אחריהם נמשך. למידע נוסף, ראו את פרק 15 בחוברת Site Reliability Engineering.
דוח אירוע
כשלאירוע יש השפעה רחבה ומשמעותית, Google מספקת דוח אירוע עם פירוט של תיאור הבעיה, ההשפעה, הגורמים, הפתרונות וצעדי המנע. כמו בשלב של הניתוח הרטרואקטיבי, אנחנו מקדישים תשומת לב לפעולות שביצענו כדי להפיק לקחים מהבעיה ולשפר את האמינות. המטרה של Google בכתיבה ובפרסום דוחות של ניתוח רטרואקטיבי היא לשמור על שקיפות, ולהראות את המחויבות שלנו ליצירת מוצרים יציבים ללקוחות.