אשת IT לצד ארונות שרתים במרכז נתונים
צילום: Christina Morillo / Pexels. מקור: https://www.pexels.com/photo/software-engineer-standing-beside-server-racks-1181354/ . רישיון Pexels: https://www.pexels.com/legal-pages/license/ (מתיר שימוש מסחרי ופרסום ברשתות חברתיות, בכפוף לתנאי הרישיון).

תקלה ב־Google Cloud בלונדון נמשכה כמעט 8 שעות

תקרית תשתית באזור הענן europe-west2 של Google Cloud בלונדון גרמה לשיבושים שנמשכו כמעט שמונה שעות. לפי לוח הסטטוס הרשמי של Google, האירוע החל ב־19 באוקטובר 2026 בשעה 23:08 לפי שעון החוף המערבי בארה"ב והסתיים ב־20 באוקטובר בשעה 07:00 — משך של 7 שעות ו־52 דקות.

Google מסרה כי אירוע חשמל גרם להשבתה באזור הזמינות europe-west2-b. בתקופת התקלה חלק משירותי Google Cloud באזור לא היו זמינים, ובשירותים אחרים נרשמו שיעורי שגיאה מוגברים ותקלות רשת לסירוגין. החברה ציינה במפורש כי Looker Studio לא הושפע.

מה הושפע בפועל?

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

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

הלקח למנהלי IT: אזור ענן אינו תוכנית המשכיות

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

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

ארבע בדיקות שכדאי לבצע עכשיו

  • מיפוי תלות: לזהות אילו רכיבים תלויים ב־europe-west2 או באזור יחיד אחר, כולל שירותים מנוהלים.
  • בדיקת התאוששות: להריץ תרגיל מעבר מבוקר ל־Zone או Region חלופי ולמדוד זמן התאוששות בפועל.
  • קיבולת חלופית: לוודא שניתן להרים עומסים חדשים באזור חלופי גם בזמן אירוע, ולא להסתמך רק על תכנון תיאורטי.
  • התראות סטטוס: לחבר את צוותי התפעול ל־Personalized Service Health ולתהליך הסלמה פנימי ברור.

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

לקריאה נוספת: מה צריך לקחת בחשבון במעבר לענן.

מקורות

צילום: Christina Morillo / Pexels. מקור: Pexels. רישיון Pexels.

דילוג לתוכן