"תמיד צריך להיות ערוכים לנפילה": התעשייה מגיבה לקריסה של AWS

תמונה: dreamstime

AWS, פלטפורמת שירותי הענן של אמזון והגדולה ביותר בעולם, קרסה היום (ב') ולקחה איתה אתרים ושירותים רבים. התקלה קרתה בריג'ן us-east-1 והשפיעה על לא מעט ספקיות ענקיות. האיזור הזה נחשב למרכזי והוא הראשון לקבל שירותים ופיצ'רים חדשים של AWS. הוא גם מכיל מספר גדול יחסית של אזורי זמינות (AZs) – מ-use1-az1 עד use1-az6.

על פי הדשבורד של AWS, יותר מ-20 שירותים שונים לא היו זמינים היום, בהם AWS Config, AWS Global Accelerator, AWS IAM Identity Center, AWS Identity and Access Management, AWS Private Certificate Authority, AWS Secrets Manager, AWS ועוד.

בהודעה הראשונית של אמזון נכתב: "אנו יכולים לאשר עלייה במספר התקלות ובזמני השיהוי עבור שירותי AWS רבים באזור US-EAST-1. ייתכן שבעיה זו משפיעה גם על פתיחת טיקטים לתמיכה דרך מרכז התמיכה של AWS או דרך ה-API של התמיכה. אנו עובדים כעת על טיפול בבעיה ופועלים הן להקטין את ההשפעה שלה והן להבין את הסיבה. נספק עדכון נוסף בתוך 45 דקות, או מוקדם יותר אם יהיה לנו מידע נוסף לשתף".

שעות לאחר מכן, באחד העדכונים האחרונים של אמזון נמסר כי "זיהינו גורם פוטנציאלי לתקלה עבור ממשקי ה-API של DynamoDB באזור US-EAST-1. בהתבסס על הבדיקה שלנו, נראה כי הבעיה קשורה ל-DNS של נקודת הקצה של DynamoDB API ב-US-EAST-1. אנחנו פועלים במספר דרכים במקביל כדי להאיץ את התיקון". עוד אומרים באמזון: "בעיה זו משפיעה גם על שירותי AWS אחרים באזור US-EAST-1. שירותים או פיצ'רים גלובליים המתבססים על נקודות קצה ב-US-EAST-1, כמו עדכוני IAM ודאטה-בייסים של DynamoDB, עלולים גם הם לחוות בעיות".

"לפעמים פשוט אין מה לעשות"

בעקבות התקלה, שוחחנו עם מספר מומחי IT וענן כדי להבין איך בדיוק ניתן להתכונן מראש לנפילה הבאה, שכמעט בוודאות תגיע. רותם לוי, Cloud & AI Security Architect בחברת CloudEdge פותח דווקא בתזכורת חשובה, בעיקר היום: "הענן הוא לא רק זמינות ונוחות, אלא בראש ובראשונה מוכנות והיערכות. השאלה האמיתית אינה 'מה קרה ל-AWS', אלא עד כמה אנחנו ערוכים לרגע שבו ספק הענן המרכזי או אזור קריטי בתשתית הגלובלית שלו מפסיק לעבוד". לדבריו, אם אין תכנית מוכנה מראש או במקרה בו המערכת תלויה לחלוטין בזמינות של AWS, "אין מה לעשות בשעות הראשונות וזה בסדר. הכי חשוב בשלב הזה הוא לגבש תמונת מצב, לעבור למתכונת אירוע ולתקשר בצורה שקופה את הכל".

מאיר גרינברג, Global IT and Security Manager, מוסיף: "כשהענן נופל הצעד הראשון שצוות IT צריך לעשות הוא קודם כל למפות את כל מה שיושב בענן שנפל. מיד לאחר מכן חייבים לשקף למשתמשים ולקוחות את המצב בכל דרכי התקשורת. במקרה הנוכחי של AWS, נפלו המון שירותי saas נוספים שקריטיים לחברות ולשירותים המסתמכים על AWS. מכאן נובע שגם משתמשים שלא עובדים באופן ישיר מול אמזון עדיין חווים פגיעה בשירותים קריטיים. הם חייבים להבין למה השירות מושבת".

רשימת שירותי AWS שנפלו בעקבות התקלה. תמונה: צילום מסך, AWS

"הצעד הראשון הוא אבחון השפעה מדויק: להבין מה מושבת בפועל, באילו אזורים ובאילו שירותים. ברגע שיש מיפוי ברור, אפשר להחליט אם מדובר בתקלה נקודתית (שניתן לעקוף באמצעים ארגוניים) או בתקלה מערכתית שדורשת מעבר לתוכנית התאוששות מאסון (DRP – Disaster Recovery Plan", מציין מרום גולדשמידט, יועץ סייבר, מרצה וארכיטקט Cloud, AI & Data Security, "במקרים כאלה, חשוב להפעיל תכנית מתועדת מראש ולא לאלתר, אחרת ארגון נכנס לאובדן שליטה בזמן אמת, ואף להיכנס לתרחישים בהם הנזק הסופי רב יותר מהנזק ההתחלתי".

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

גולדשמידט מצטרף לדבריו של לוי ואומר כי "תוכנית DR טובה בענן מתחילה בהנחה שגם ספק ענן עלול לקרוס בצורה נקודתית או רוחבית. זה אומר להפריד בין גיבוי נתונים לבין תלות תפעולית בשירותי ניהול זהויות או סודות (IAM, Secrets Management). יש לא מעט ארגונים שמתכננים DR ברמת השרתים, אבל שוכחים שברגע שאלמנטים נקודתיים כמו ניהול זהויות (IAM) לא פעילים, אז גם השרתים ה'מגובים' אינם נגישים. הפתרון הוא מודל של שליטה רב שכבתית: גיבויים מוצפנים בנפרד, משתמשי חירום קיימים גם בענן עצמו וגם מחוץ לענן ככל הניתן, והרשאות חירום שאינן תלויות ב-SSO או ב-MFA הפנימי של הספק".

מולטי קלאוד או מולטי ריג'ן?

מה אפשר לעשות כדי למנוע מצב שבו תקלה אזורית אחת משביתה מערכות שלמות? בנקודה זו יש לציין, כל המומחים שלנו תמימי דעים ומציינים את ה-Multi Region כפתרון הטוב ביותר כרגע. "⁠תמיד צריך לצאת מנקודת הנחה שאין 100% זמינות, תצורה של Multi Region ו-Multi Cloud יתנו מענה טוב ביותר", טוען גרינברג. לדבריו מוסיף לוי שטוען כי "מולטי קלאוד היא אמצעי יקר וקשה לתפעול, אבל דווקא מולטי ריג'ן יכול לעבוד כפתרון נוח ללא מעט ארגונים. גם בו צריך לשים לב שלא מסנכרנים את הכל ולא מגזימים, אבל את יכולות הליבה חשוב לגבות".

גולדשמידט: "התשובה היא לא Multi-Cloud לכל דבר, אלא Multi-Region Architecture עם גבולות תפעוליים מוגדרים היטב. במקרים שבהם נדרש רצף עסקי אמיתי, כדאי לתכנן מערכות קריטיות כך שיוכלו לפעול באזורים שונים או אפילו בחשבונות נפרדים באותו ענן. רק במקרים שבהם יש רגולציה או דרישות זמינות קיצוניות, באמת כדאי ללכת על Multi-Cloud 'מלא'. כמובן שאין 1 או 0 באף פתרון, ותמיד צריך לגבש פתרון נקודתי לכל תרחיש ולכל צורך. אין פה פתרון אחד שבאמת יתאים לכל סיטואציה. בקצרה – העיקרון הוא לא להכפיל הכול, אלא רק את מה שקריטי לפעילות הליבה".

איפה טמון הסיכון הגדול ביותר מבחינתכם: בתלות בענן אחד, בתצורת השירותים, או דווקא באשליה שהכול מנוהל אוטומטית?
לוי: "הסיכון הגדול הוא בתחושת האשליה ש'הענן תמיד יהיה למעלה'. האשליה הזו גורמת לנו להזניח את התכנון מראש למקרה של תקלה ויותר גרוע – אם כבר תכננו מראש, היא מונעת מאיתנו לתרגל. בנוסף, יש סיכון בתלות ריכוזית. אם הכל מונח אצל AWS, תקלה כמו זו שחווינו היום יכולה לעלות הרבה מאוד כסף לארגונים. אז מה עושים? פשוט מאוד – להניח מראש שיהיה כשל מתישהו במורד הדרך, לגדר את יכולות הליבה כך שלא משנה מה הן יוכלו לפעול ולהציב כמטרה ביטול של נקודת כשל אחת בכל רבעון".

כל עדכוני ה-IT, תשתית וטכנולוגיה בערוץ הטלגרם של ITtime

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

"כנראה יקרה שוב"

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

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