אירועים ו-Service Health של Google Cloud

כדי להתעדכן בסטטוס של מוצרי Google Cloud ‎, כדאי להשתמש במקורות המידע הבאים:

  • ‫Service Health בהתאמה אישית – כלי שמציג לפי התאמה אישית את המוצרים והאזורים ב- Google Cloud‏שבהם אתם משתמשים בפרויקטים או בארגון שלכם. ב-"Service Health בהתאמה אישית" אפשר למצוא הודעות על אירועים פעילים ואירועים קודמים ב-Google Cloud‏ , שיכול להיות שמשפיעים על הפרויקטים והמשאבים שלכם.

    הגישה אליו אפשרית דרך:

  • ‫Service Health של Google Cloud כולל:

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

    כולם יכולים לגשת אל Service Health שלGoogle Cloud באמצעות:

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

אפשר גם לבדוק אם יש שיבושים פעילים, בדף Support במסוף ‎Google Cloud ‎‏. הבעיות המוכרות שמוצגות בדף Support במסוף ‎ Google Cloud ‎ כוללות גם אירועים משניים ואירועים מוגבלים. בדף הבעיות המוכרות תוכלו ליצור בקשת תמיכה שקשורה לאירוע שפורסם, כדי לקבל עדכונים שוטפים ולדבר עם צוות התמיכה. בקשות תמיכה מתאימות לבעיות שלא עומדות בקריטריונים של אירועים, או כשיש צורך במענה אנושי פרטני מנציג תמיכה. אם יש לכם את חבילת השירות של תמיכת Premium,‏ Enhanced או Standard, כדי לדווח על אירועים תוכלו ליצור בקשת תמיכה במסוף Google Cloud. בכל מקרה אחר השתמשו בטופס הזה.

במאמר הזה נתמקד ב-Service Health של Google Cloud .

מהו Service Health של Google Cloud

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

‫Service Health של ‎Google Cloud נועד להיות זמין במקרים נדירים שבהם "Service Health בהתאמה אישית" לא זמין או מושפע משיבושים, או שהמוצר שמושפע עדיין לא מופיע ב-"Service Health בהתאמה אישית".

מתי אירוע מופיע ב-Service Health של Google Cloud

ברוב האירועים ב-‎ Google Cloud ‎‏, הלקוחות שמושפעים מקבלים הודעות על אירועים ישירות מ-"Service Health בהתאמה אישית" במסוף ‎ Google Cloud ‎‏. אם האירועים עומדים בתנאים להתראה, הם יפעילו גם את התראות Service Health שהגדרתם.

ב-Service Health של ‎ Google Cloud ‎ מופיעים אירועים שעומדים באחד מהקריטריונים האלה:

  • אירועים ציבוריים משמעותיים
  • אירועים במוצרי ‎ Google Cloud ‎ שעדיין לא זמינים ב-Service Health בהתאמה אישית
  • אירועים שקורים כשלוח הבקרה של "Service Health בהתאמה אישית" לא זמין

אירוע משמעותי

ב-Google Cloud ‎‏, אירוע מוגדר משמעותי אם הוא עומד בכל התנאים האלה:

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

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

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

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

מחזור החיים של אירוע

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

בתרשים שכאן מוצגים תחומי האחריות של צוותי מהנדסי המוצר וצוותי התמיכה:

תרשים של מחזור החיים

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

זיהוי

אנחנו משתמשים בניטור פנימי ובקופסה שחורה ב-‎Google Cloud ‎ כדי לזהות אירועים. למידע נוסף, ראו פרק 6 במסמך Site Reliability Engineering.

מענה ראשוני

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

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

תרשים תקשורת

חקירה

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

צמצום פגיעות ותיקון שלהן

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

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

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

המשך מעקב

במהלך האירוע, נציגי Customer Care שולחים עדכונים שוטפים. בדר"כ העדכונים כוללים:

  • מידע נוסף על האירוע, כמו הודעות שגיאה, אזורים או תחומים (zones) שהושפעו, מאפיינים שהושפעו או אחוזי השפעה.

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

  • לוחות זמנים לתקשורת, בהתאם לאירוע.

  • שינויים בסטטוס, כמו פתרון האירוע.

הסקת מסקנות לאחר האירוע

כל אירוע מנותח פנימית ב-Google לאחר סיומו, כדי להבין את מלוא היקפו ולזהות אפשרויות לשיפור האמינות. השיפורים שמזוהים מיושמים עם המשך מעקב אחריהם. למידע נוסף על הסקת מסקנות לאחר אירועים ב-Google, ראו פרק 15 במסמך Site Reliability Engineering.

דוח אירוע

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

מודל של נתוני אירועים

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

בסכימה ב-JSON יש שדות שמסומנים בתוויות Stable ו-Unstable. באופן כללי, שדות של מזהים נחשבים ל-Stable, ושדות כמו שמות מוצגים נחשבים ל-Unstable ועשויים להשתנות ללא התרעה. כדאי להשתמש בשדות Stable רק בשילוב עם מערכת חיצונית או עם אוטומציה של מבנה. אפשר ליצור פתרונות משתלבים כדי לצרוך את הנתונים שמופיעים בלוח הבקרה של Service Health של ‎Google Cloud ‎ באופן פרוגרמטי?

שאלות נפוצות

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

ב-Service Health של ‎Google Cloud ‎ נשמרת היסטוריית השיבושים וההפסקות הזמניות במוצרי ‎Google Cloud ‎ מחמש השנים האחרונות. בכרטיסייה Overview בלוח הבקרה מופיע הסטטוס הנוכחי של המוצרים, בחלוקה לפי שילוב של שפה ואזור. כדי לראות מידע מהשנה האחרונה על שיבושים והפסקות זמניות במוצר, לחצו על View history בלוח הבקרה. כדי לראות את היסטוריית השיבושים במוצר מסוים מחמש השנים האחרונות, לחצו על See more באותו מוצר.

איך אפשר לראות מידע על סטטוסים אזוריים של מוצרי ‎ Google Cloud ‎‏?

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

אפשר ליצור פתרונות משתלבים כדי לצרוך את הנתונים שמופיעים בלוח הבקרה של Service Health של ‎ Google ‎ באופן פרוגרמטי?

כן, אפשר לצרוך את הנתונים שמופיעים ב-Service Health של ‎ Google Cloud ‎ בדרכים האלה:

  • באמצעות פיד RSS

  • באמצעות קובץ היסטוריה בפורמט JSON

    מכאן אפשר להוריד את הסכימה לקובץ JSON.

פיד ה-RSS וקובץ ההיסטוריה בפורמט JSON מכילים את הסטטוסים של האירועים, ואפשר לצרוך אותם באמצעות פתרונות משתלבים.

צריך להשתמש בשדות שמסומנים בתווית Stable בקובץ ההיסטוריה בפורמט JSON, במקום בשדות שמסומנים בתווית Unstable. לדוגמה: אם אתם מנסים לזהות באופן פרוגרמטי אירועים שמשפיעים על קבוצה מסוימת של מוצרים, השתמשו במזהי המוצרים (affected_products>id) ולא בשמות המוצגים שלהם.

מזהי מוצרים לעומת שמות מוצרים

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

מה עושים אם כבר יש פתרונות משתלבים שהתבססו על Service Health‏ של ‎ Google Cloud ‎ לפני חלוקת הסטטוסים לאזורים ושינוי השם ל"לוח הבקרה של Service Health" של ‎ Google Cloud ‏?

גם בפיד ה-RSS וגם בקובץ ה-JSON, חלוקת הסטטוסים לאזורים נוספת למידע שכבר פורסם לפני הוספת החלוקה ושינוי השם של Service Health‏ של ‎Google Cloud ‎, לכן הפתרונות המשתלבים הקיימים אמורים לעבוד. עם זאת, אם אתם רוצים לצרוך את הסטטוסים בחלוקה לאזורים באמצעות הפתרונות המשתלבים, יכול להיות שתצטרכו לשנות אותם.

תוכלו להיעזר בהסבר הבא על האופן שבו החלוקה לאזורים מופיעה בפיד RSS ובקובץ ה-JSON:

  • פיד RSS

    חלוקת הסטטוסים לאזורים היא תוספת חדשה למידע שהפיד סיפק לפני הוספת החלוקה הזו. המידע על המקומות שהושפעו מתווסף להודעת ה-RSS.

  • קובץ JSON

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

    כיום אנחנו מעדכנים על האירועים ב-‎ Google Cloud ‎ בדיוק כמו קודם, אבל בכל אירוע עדכון הסטטוס מכיל את השדות החדשים האלה:

    • updates.affected_locations: מכיל רשימה מובנית של המיקומים שהושפעו מהאירוע נכון למועד פרסום העדכון. השדה הזה כלול בכל רשומת עדכון ורשומת most_recent_update.
    • currently_affected_locations: מכיל את המידע העדכני ביותר על המיקומים שמושפעים בפועל מהאירוע. בניגוד לרשימה updates.affected_locations, הרשימה הזו הופכת לריקה כשהאירוע נפתר (כלומר, כשהשדה end מוגדר לערך שאינו ריק).
    • previously_affected_locations: מכיל רשימה של מיקומים שבעבר הושפעו מהאירוע, אבל כבר לא מושפעים ממנו עכשיו. ככל שהאירוע מתקדם, בחלק מהמיקומים נמצא פתרון להפסקה הזמנית בשירות. אותם מיקומים ימשיכו להופיע בשדה previously_affected_locations field. כשהאירוע נפתר (כלומר, כשהשדה end מוגדר לערך שאינו ריק), השדה הזה מכיל רשימה של כל המיקומים שבעבר הושפעו מהאירוע.

מה עושים אם נתקלים בבעיה שלא מופיעה בלוח הבקרה?

בלוח הבקרה של Service Health של ‎ Google Cloud ‎ מוצגים הסטטוסים העדכניים וההיסטוריים של כל האירועים המשמעותיים שמשפיעים על השירותים והמוצרים ב-‎ Google Cloud ‎‏. אם נתקלתם בבעיה שלא מופיעה בלוח הבקרה, יכול להיות שהבעיה מוגבלת רק לפרויקטים או למכונות שלכם, או שהיא משפיעה רק על מספר מצומצם של לקוחות. יכול להיות שאירועים בהיקף קטן יותר מופיעים ב-Customer Care Portal. בכל בעיה שלא מופיעה בלוח הבקרה אתם יכולים לפנות לשירות הלקוחות.

אם אתם כבר משתמשים ב-Service Health בהתאמה אישית, כדאי לבדוק אם הבעיה מופיעה שם כדי לדעת אם הפרויקט או המכונה שלכם מושפעים ממנה.

אם אתם משתמשים במסוף ‎ Google Cloud ‎‏, כדי לדווח על בעיות תוכלו ללחוץ על הכלי Send feedback בפינה הימנית העליונה.

מי מעדכן את לוח הבקרה?

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