הנדסת כאוס: אמנות ההרס המכוון. חלק 2

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

"אם אתה לא מצליח להכין תוכנית, אז אתה מתכנן להיכשל." - בנג'מין פרנקלין

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

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

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

אל תתעסק עם פנדה הכאוס!

תשובה קצרה: מקד שירותים קריטיים לאורך נתיב הבקשה.

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

1. תראה היסטוריית קריסות ולזהות דפוסים;
2. להחליט על תלות קריטית;
3. השתמש במה שנקרא אפקט בטחון יתר.

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

1. התשובה נמצאת בעבר

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

"כדי להבין את ההווה, אתה צריך לדעת את העבר." - קרל סאגאן

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

"האם ניתן היה לחזות זאת ולפיכך למנוע זאת על ידי הזרקת תקלות?"

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

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

עם זאת, הכל היה בסדר לזמן מה.

ואז, כבר בתנאים מלחיצים למדי, אחד המקרים החל לבצע משימת קרון ETL רגילה לא קריטית. השילוב של תעבורה גבוהה ו-cronjob דחף את ניצול ה-CPU לכמעט 100%. עומס יתר של CPU האט עוד יותר את התגובות לבדיקות תקינות, עד כדי כך שה-ELB החליט שהמופע חווה בעיות ביצועים. כצפוי, המאזן הפסיק לחלק אליו תעבורה, מה שבתורו הביא להגדלת העומס על שאר המקרים בקבוצה.

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

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

אז הבנו לנצח את הנקודות הבאות:

• התקנת תוכנה בעת יצירת מופע חדש אורכת זמן רב; עדיף לתת עדיפות לגישה הבלתי ניתנת לשינוי זהב AMI.
• במצבים קשים, תגובות לבדיקות בריאות ו-ELB צריכות לקבל עדיפות - הדבר האחרון שאתה רוצה הוא לסבך את החיים עבור המקרים הנותרים.
• שמירה מקומית במטמון של בדיקות בריאות עוזרת מאוד (אפילו לכמה שניות).
• במצב קשה, אל תריצו משימות cron ותהליכים לא קריטיים אחרים - חסכו משאבים למשימות החשובות ביותר.
• בעת שינוי קנה מידה אוטומטי, השתמש במופעים קטנים יותר. קבוצה של 10 דגימות קטנות עדיפה על קבוצה של 4 דגימות גדולות; אם מקרה אחד נכשל, במקרה הראשון 10% מהתנועה יתחלקו על פני 9 נקודות, במקרה השני - 25% מהתנועה על פני שלוש נקודות.

לפיכך, האם ניתן היה לצפות זאת מראש, ולפיכך למנוע זאת על ידי הכנסת הבעיה?

כן, ובכמה אופנים.

ראשית, על ידי הדמיית שימוש גבוה במעבד באמצעות כלים כגון stress-ng או cpuburn:

❯ stress-ng --matrix 1 -t 60s

מתח- ng

שנית, על ידי העמסת יתר של המופע עם wrk וכלי עזר דומים אחרים:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

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

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

האם זה היה חלום, או שזה באמת קרה?

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

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

2. בניית מפת תלות

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

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

זיהוי ותיעוד תלות נקרא "בניית מפת תלות» (מיפוי תלות). זה נעשה בדרך כלל עבור יישומים עם בסיס קוד גדול באמצעות כלי פרופיל קוד. (פרופיל קוד) ומכשור (מִכשׁוּר). אתה יכול גם לבנות מפה על ידי ניטור תעבורת הרשת.

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

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

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

אתה יכול להשתמש בתוכנות כמו netstat - שירות שורת פקודה המציג רשימה של כל חיבורי הרשת (שקעים פעילים) במערכת. לדוגמה, כדי לרשום את כל החיבורים הנוכחיים, הקלד:

❯ netstat -a | more 

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

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

קונסולת AWS X-Ray

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

יישומים רבים משתמשים ב-DNS כדי להתחבר לתלות, בעוד שאחרים עשויים להשתמש בגילוי שירות או אפילו בכתובות IP מקודדות בקובצי תצורה (למשל. /etc/hosts).

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

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

חור שחור DNS

אם בתוך /etc/hosts או קבצי תצורה אחרים, תמצא כתובות IP שאינך יודע עליהן דבר (כן, למרבה הצער, זה גם קורה), אתה יכול לבוא לעזרה שוב iptables. נניח שגילית 8.8.8.8 ולא יודע שזו הכתובת הציבורית של שרת ה-DNS של גוגל. על ידי שימוש ב iptables אתה יכול לחסום תנועה נכנסת ויוצאת לכתובת זו באמצעות הפקודות הבאות:

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

סגירת גישה

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

הערה: במקרה הספציפי הזה עדיף להשתמש whois 8.8.8.8, אבל זו רק דוגמה.

אנחנו יכולים ללכת אפילו יותר עמוק לתוך חור הארנב, כי כל מה שמשתמש ב-TCP ו-UDP תלוי למעשה גם ב-IP. ברוב המקרים, IP קשור ל-ARP. אל תשכח את חומות האש...

אם אתה לוקח את הגלולה האדומה, אתה נשאר בארץ הפלאות, ואני אראה לך עד כמה עמוק חור הארנב".

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

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

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

3. היזהרו מעודף ביטחון עצמי

"מי שחולם על מה, מאמין בזה." - דמוסתנס

האם שמעת אי פעם על אפקט ביטחון יתר?

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

מבוסס על אינסטינקט וניסיון...

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

היזהרו מהמפעיל בעל הביטחון העצמי המוגזם:

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

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

סיכום

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

בכך מסתיים החלק השני. אנא כתוב ביקורות, שתף דעות או פשוט תמחא כפיים בינוני. בחלק הבא אני באמת אשקול כלים ושיטות להחדרת כשלים למערכות. עד!

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «הנדסת כאוס: אמנות ההרס המכוון. חלק 1";
• «כמה זמינות גבוהה מסופקת ב-Kubernetes";
• «ניטור ו-Kubernetes (סקירה ודוח וידאו)";
• «ניסוי ב-kube-proxy וחוסר זמינות של צומת ב-Kubernetes".

מקור: www.habr.com