למעלה fakapov ציאן

טוב לכולם! 

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

מבוא

לפני זמן רב, כאשר Cian כללה מונוליטים, ועדיין לא היו רמזים לשירותי מיקרו, מדדנו את הזמינות של משאב על ידי בדיקת 3-5 עמודים. 

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

העמודים הראשיים של האתר או איך אנחנו מבינים שהגענו לתחתית

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

נניח שגילינו שיש מספר קטעים סופר חשובים באתר שאחראים על השירות המרכזי – חיפוש ושליחת פרסומות. אם מספר הבקשות שנכשלו עולה על 1%, מדובר באירוע קריטי. אם תוך 15 דקות במהלך הפריים טיים שיעור השגיאות עולה על 0,1%, אז גם זה נחשב לאירוע קריטי. קריטריונים אלה מכסים את רוב התקריות; השאר הם מחוץ לתחום המאמר הזה.

התקריות הטובות ביותר Cyan

אז, בהחלט למדנו לקבוע את העובדה שקרה תקרית. 

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

אם אתה אוסף את כל הכשלים במהלך השנים האחרונות, המנהיגים הם: 

• תקריות הקשורות ל-mssql;
• תקריות שנגרמו על ידי גורמים חיצוניים;
• שגיאות אדמין.

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

מקום חמישי - "לעשות סדר ב-DNS"

זה היה יום שלישי סוער. החלטנו להחזיר את הסדר על כנו באשכול ה-DNS. 

רציתי להעביר שרתי DNS פנימיים מ-bind ל-powerdns, להקצות לזה שרתים נפרדים לחלוטין, שבהם אין שום דבר מלבד DNS. 

הצבנו שרת DNS אחד בכל מיקום של ה-DCs שלנו, והגיע הרגע להעביר אזורים מ-bind ל-powerdns ולהעביר את התשתית לשרתים חדשים. 

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

מסקנות:

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

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

מקום רביעי - "לעשות סדר ב-Nginx"

יום בהיר אחד, הצוות שלנו החליט ש"די היה לנו מזה", והתהליך של עיבוד תצורות nginx החל מחדש. המטרה העיקרית היא להביא את ההגדרות למבנה אינטואיטיבי. בעבר הכל היה "מבוסס היסטורית" ולא נשא שום היגיון. כעת כל server_name הועבר לקובץ באותו שם וכל ההגדרות הופצו לתיקיות. אגב, התצורה מכילה 253949 שורות או 7836520 תווים ותופסת כמעט 7 מגה בייט. רמה עליונה של מבנה: 

מבנה Nginx

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

זה נעשה הרבה יותר טוב, אבל בתהליך של שינוי שמות והפצת הגדרות, לחלק מהן הייתה הרחבה שגויה ולא נכללו בהנחיית include *.conf. כתוצאה מכך, חלק מהמארחים הפכו ללא זמינים והחזירו 301 לעמוד הראשי. בשל העובדה שקוד התגובה לא היה 5xx/4xx, לא הבחינו בכך מיד, אלא רק בבוקר. לאחר מכן, התחלנו לכתוב מבחנים לבדיקת רכיבי תשתית.

מסקנות: 

• מבנה את ההגדרות שלך בצורה נכונה (לא רק nginx) וחשוב על המבנה בשלב מוקדם של הפרויקט. כך תהפכו אותם למובנים יותר לצוות, מה שבתורו יקטין את ה-TTM.
• כתוב מבחנים עבור חלק ממרכיבי התשתית. לדוגמה: בדיקה שכל שמות השרתים המפתחים נותנים את הסטטוס הנכון + גוף התגובה. זה יהיה מספיק רק כמה סקריפטים בהישג יד שבודקים את הפונקציות הבסיסיות של הרכיב, כדי לא לזכור בטירוף ב-3 לפנות בוקר מה עוד צריך לבדוק. 

מקום שלישי - "פתאום נגמר המקום בקסנדרה"

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

יום סוער אחד, האשכול כמעט הפך לדלעת, כלומר:

• נותרו כ-20% מכלל החלל באשכול;
• אי אפשר להוסיף צמתים באופן מלא, מכיוון שהניקוי לא עובר לאחר הוספת צומת בגלל חוסר מקום במחיצות;
• הפרודוקטיביות יורדת בהדרגה מכיוון שהדחיסה אינה פועלת; 
• האשכול נמצא במצב חירום.

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

מסקנות:

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

מקום שני - "הנתונים נעלמו מאחסון ערך מפתח-ערך של קונסול"

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

מסקנות:

• שירותים ללא כל אישור אינם אמורים להכיל נתונים קריטיים לתפעול האתר. לדוגמה, אם אין לך הרשאה ב-ES, עדיף לשלול גישה ברמת הרשת מכל מקום בו אין צורך, להשאיר רק את הנחוצים, וגם להגדיר action.destructive_requires_name: true.
• תרגל את מנגנון הגיבוי והשחזור שלך מראש. לדוגמה, צור סקריפט מראש (למשל ב-Python) שיכול לגבות ולשחזר.

מקום ראשון - "קפטן לא ברור" 

בשלב מסוים, שמנו לב להתפלגות לא אחידה של עומס על nginx upstream במקרים שבהם היו 10+ שרתים ב-backend. בשל העובדה ש-round-robin שלח בקשות מה-1 עד האחרון במעלה הזרם לפי הסדר, וכל טעינה מחדש של nginx התחילה מחדש, ה-upstreams הראשונים תמיד קיבלו יותר בקשות מהשאר, כתוצאה מכך, הם עבדו לאט יותר והאתר כולו סבל. זה נעשה בולט יותר ויותר ככל שכמות התנועה גדלה. פשוט לעדכן את nginx כדי לאפשר אקראי לא עבד - אנחנו צריכים לעשות מחדש חבורה של קוד lua שלא המריא בגרסה 1.15 (באותו רגע). היינו צריכים לתקן את nginx 1.14.2 שלנו, ולהכניס לתוכו תמיכה אקראית. זה פתר את הבעיה. הבאג הזה זוכה בקטגוריית "קפטן אי-מובן מאליו".

מסקנות:

זה היה מאוד מעניין ומרגש לחקור את הבאג הזה). 

• ארגן את הניטור שלך כך שיעזור לך למצוא תנודות כאלה במהירות. לדוגמה, אתה יכול להשתמש ב-ELK כדי לנטר rps בכל קצה אחורי של כל במעלה הזרם, לנטר את זמן התגובה שלהם מנקודת המבט של nginx. במקרה זה, זה עזר לנו לזהות את הבעיה. 

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

מקור: www.habr.com