דו"ח ניתוח לאחר המוות של הבר: זה נפל על עיתון

סוף החודש הראשון ותחילת החודש השני של קיץ 2019 התברר כקשה וסומן בכמה נפילות משמעותיות בשירותי ה-IT העולמיים. בין הבולטים שבהם: שני תקריות חמורות בתשתית CloudFlare (הראשון - עם ידיים עקומות ויחס רשלני כלפי BGP מצד כמה ספקי אינטרנט מארה"ב; השני - עם פריסה עקומה של CF עצמם, שהשפיעה על כל מי שמשתמש ב-CF , ואלה שירותים בולטים רבים) ותפעול לא יציב של תשתית ה-CDN של פייסבוק (השפיע על כל מוצרי FB, כולל אינסטגרם ו-WhatsApp). היינו צריכים גם להיתפס בהפצה, למרות שההפסקה שלנו הייתה הרבה פחות מורגשת על הרקע העולמי. מישהו כבר התחיל לגרור מסוקים שחורים וקנוניות "ריבוניות", אז אנחנו מפרסמים נתיחה פומבית שלאחר המוות של התקרית שלנו.

03.07.2019, 16: 05
החלו להירשם בעיות במשאבים, בדומה לתקלה בקישוריות פנימית לרשת. לאחר שלא בדקו הכל במלואו, הם החלו להטיל דופי בביצועי הערוץ החיצוני כלפי DataLine, שכן התברר שהבעיה היא בגישה של הרשת הפנימית לאינטרנט (NAT), עד כדי העברת ה-BGP לכיוון DataLine.

03.07.2019, 16: 35
התברר שהציוד המספק תרגום כתובות רשת וגישה מהרשת המקומית של האתר לאינטרנט (NAT) נכשל. ניסיונות לאתחל את הציוד לא הובילו לכלום, החיפוש אחר אפשרויות חלופיות לארגון קישוריות החל לפני קבלת מענה מתמיכה טכנית, שכן מניסיון, סביר להניח שזה לא היה עוזר.

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

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

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

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

03.07.2019, 17: 27
הפונקציונליות המוגבלת של Habr שוחזרה.

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

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

03.07.2019, 17: 52
NS הופעל מחדש והמטמון נוקה. הפתרון שוחזר.

03.07.2019, 17: 55
כל השירותים התחילו לעבוד מלבד MK, Freelansim ו-Toaster.

03.07.2019, 18: 02
חבר כנסת ופרילנסים התחילו לעבוד.

03.07.2019, 18: 07
החזר סשן BGP תמים עם DataLine.

03.07.2019, 18: 25
הם החלו לרשום בעיות במשאבים, שנבעו משינוי בכתובת החיצונית של מאגר ה-NAT והיעדרה ב-acl של מספר שירותים, שתוקן באופן מיידי. הטוסטר התחיל לעבוד מיד.

03.07.2019, 20: 30
הבחנו בשגיאות הקשורות לבוטים של טלגרם. התברר שהם שכחו לרשום את הכתובת החיצונית בכמה acl (שרתי פרוקסי), שתוקן מיד.

ממצאים

• הציוד, שזרע בעבר ספקות לגבי התאמתו, נכשל. היו תוכניות לבטל אותו מהעבודה, מכיוון שהוא הפריע להתפתחות הרשת והיו לו בעיות תאימות, אך במקביל הוא ביצע פונקציה קריטית, ולכן כל החלפה הייתה קשה מבחינה טכנית מבלי להפריע לשירותים. עכשיו אתה יכול להמשיך הלאה.
• ניתן למנוע את בעיית ה-DNS על ידי התקרבותם לרשת השדרה החדשה מחוץ לרשת ה-NAT ועדיין יש להם קישוריות מלאה לרשת האפורה ללא תרגום (וזה הייתה התוכנית לפני התקרית).
• אתה לא צריך להשתמש בשמות תחום בעת הרכבת אשכולות RDBMS, שכן הנוחות של שינוי שקוף של כתובת ה-IP אינה הכרחית במיוחד, שכן מניפולציות כאלה עדיין דורשות בנייה מחדש של האשכול. החלטה זו הוכתבה מסיבות היסטוריות, וקודם כל, מהברור של נקודות קצה לפי שם בתצורות RDBMS. בכלל, מלכודת קלאסית.
• באופן עקרוני, נערכו תרגילים הדומים ל"ריבונות הרונט"; יש על מה לחשוב במונחים של חיזוק יכולות ההישרדות האוטונומית.

מקור: www.habr.com