ב־19 באוקטובר 2025 חוותה Amazon Web Services הפרעה משמעותית באזור צפון וירג'יניה (US-EAST-1). לפי סיכום האירוע הרשמי של AWS, שגיאה במערכת ניהול ה־DNS של DynamoDB יצרה רשומת DNS ריקה לנקודת הקצה האזורית. התקלה השפיעה על DynamoDB ועל שירותים נוספים שהיו תלויים בו, אך אין בסיס לקבוע שמדובר היה בתקלה ישירה ב־Microsoft 365.
מה ארגונים צריכים לבדוק באירוע ענן
גם כאשר Microsoft 365 עצמו ממשיך לפעול, מערכת עסקית יכולה להיפגע אם אינטגרציה, ספק צד שלישי, שירות API או תהליך אוטומציה שלה מתארחים באזור הענן שנפגע. לכן חשוב להפריד בין מצב השירות של Microsoft לבין מצב הרכיבים החיצוניים המחוברים אליו.
- מיפוי תלות: תעדו אילו יישומים, ממשקים וספקים נשענים על כל אזור ושירות ענן.
- בדיקת סטטוס נפרדת: בדקו את לוחות הסטטוס של AWS, Microsoft ושל הספק הספציפי — לא רק את היישום שבו המשתמש רואה את התקלה.
- תכנון התאוששות: הגדירו זמני התאוששות ויעדי אובדן נתונים, ובחנו אם נדרש תכנון רב־אזורי. מעבר אוטומטי בין אזורים אינו מתקבל בחינם ודורש תכנון, שכפול ובדיקות.
- התמודדות עם כשל זמני: בתהליכי API רצוי להשתמש בתורים, ניסיונות חוזרים מדורגים ומנגנוני מניעת כפילויות, בהתאם לאופי המערכת.
- תרגול ותקשורת: בדקו את תוכנית ההמשכיות העסקית ועדכנו משתמשים בנוסח מדויק שאינו מייחס את התקלה לספק הלא נכון.
הלקח: ארכיטקטורה לפני סיסמאות
ענן ציבורי, ענן פרטי או סביבה היברידית יכולים כולם לסבול מתקלות. רמת החוסן נקבעת לפי הארכיטקטורה, פיזור התלות, הגיבויים והיכולת להתאושש — לא לפי תווית השיווק של התשתית. כפי שמדגיש אריאל מרום בעבודתו בתחום הענן וה־IT, תכנון טוב מתחיל במיפוי נקודות הכשל ובבדיקות התאוששות תקופתיות.
מקורות: סיכום האירוע הרשמי של AWS; סיכומי אירועים של AWS.
קרדיט תמונה: Pixabay / Pexels, ברישיון החופשי של Pexels.
