התקלה של Cloudflare אתמול ומה אפשר ללמוד ממנה כדי להגן על העסק

התקלה של Cloudflare אתמול ומה אפשר ללמוד ממנה כדי להגן על העסק

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

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

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

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

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

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

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

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

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

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

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

קרדיט תמונה
Christina Morillo

דילוג לתוכן