הנדסת כאוס, שיטה לבדיקת resilience של יישומים בענן | ורד שיינמן

זמן השבתה של דקה בודדת של AWS מוערכת בסביבות $154,333, לא כולל קנסות, השפעה על הלקוח, עלויות תפעול ופגיעה במוניטין. מכיוון שעסקים מסתמכים יותר ויותר על יישומים בענן, הבטחה שהיישומים הללו עמידים בפני כשלים שונים היא דבר חשוב ביותר. כאן נכנסת לתמונה הנדסת כאוס - chaos engineering, המציעה שיטה לבדוק ולשפר את העמידות של יישומים בענן [1]

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

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

 אז איזה חולשות במערכת ענן הנדסת כאוס עוזרת לזהות ולשפר?

1. בעיות scalability: בעיות בהוספת מופעים נוספים (אופקית) או בהגדלת המשאבים של מופעים קיימים (אנכית).
2. פעפוע תקלות: רוב היישומים תלויים בשירותים חיצוניים, שירותים בענן מקושרים אחד בשני. כשל בשירות אחד יכול לגרום לשרשרת כשלים מדורגת.
3. בעיות גיבוי: בזמן ששירות אחד לא מגיב, שירות אחר שתלוי בו מפעיל מערכות גיבוי ותמיכה ובכך נמנעת השבתה רחבה של כל הענן.
4. בעיות התאוששות (recovery):  לאחר ששירות מסוים לא היה פעיל וחזר לפעול, הוא עשוי לעלות מחדש בצורה לא תקינה, או ששירותים שתלויים בו לא ידעו למצוא אותו או יחוו תקלות כתוצאה מתגובה מאוחרת או כפולה .
5. פגיעות אבטחה (security vulnerabilities): הגדרות שגויות שחושפות נתונים או גישה לא מורשית.
6. בעיות קונפיגורציה: הבדלים בין סביבות שונות (פיתוח, בדיקות, פרודקשן) המובילים להתנהגות בלתי צפויה.
7. בעיות פרישה (deployment): עדכונים חלקיים או שגויים.

הבנת הנדסת כאוס

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

היתרונות העיקריים בשימוש בהנדסת כאוס הם:

1. חוסן משופר: על ידי זיהוי וטיפול בכשלים פוטנציאליים הנדסת כאוס עוזרת ליצור מערכות עמידות  יותר.
2. ביצועים משופרים: הבנה כיצד מערכת מתנהגת תחת עומס יכולה להוביל לשיפור ביצועים כללים.
3. מודעות תפעולית: ניסויי כאוס קבועים מגבירים את המודעות וההבנה של תלויות המערכת וסיבות לכישלונות ודרך התאוששות המערכת.
4. מערכת מודולרית יותר.
5. תכנון כשלים מודע (אנחנו בוחרים מה לעשות כאשר המערכת נכשלת באופנים מסויימים, ולא מקבלים את מה שבמקרה יצא).
6. הפיכת תקלות לאירוע שגרתי - אם משהו בכל זאת קורה, כל בעלי התפקידים יודעים מה לעשות, ויש סיכוי טוב יותר שחלקים גדולים יותר מהעבודה עברו אוטומציה.

 שלבים מרכזיים של הנדסת כאוס:

1. הגדרת מצב יציב: הבנה ותיעוד כיצד נראות פעולות רגילות עבור המערכת במצב שימוש רגיל.

2. ניסוח השערה: הנחה כיצד המערכת תתנהג בתנאי כשל מסוימים.

3. הפעלת ניסויים: הכנסת כשלים בצורה מבוקרת ותצפית על התנהגות המערכת.

4. ניתוח תוצאות: השוואה בין ההתנהגות הנצפית להשערה וזיהוי אי התאמות.

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

יישום הנדסת כאוס

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

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

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

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

תכנון ימים של משחקי הכאוס

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

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

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

ביצוע ימים של משחקי הכאוס

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

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

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

ניתוח ותיקון יום לאחר הכאוס

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

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

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

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

שימוש בכלים להנדסת כאוס בארגונים גדולים

רוב הספקיות ענן הגדולות בעולם פיתחו כלים משלהן להנדסת כאוס על מנת לסייע למשתמשים שלהם לבנות ולתחזק אפליקציות עמידות המסוגלות לעמוד בפני שיבושים בלתי צפויים. לגוגל אין שירות הנדסת כאוס ייעודי, עם זאת, משתמשים שלהם יכולים לנצל את התכונות של Istio ו-Kubernetes לדמות תקלות רשת ולבדוק את חוסן המיקרו-שירותים בתוך (Google Kubernetes Engine (GKE ובנוסף להשתמש בכלי קוד פתוח להנדסת כאוס.

בטבלה הבאה ניתן לראות כמה הכלים בהם ניתן להשתמש מעל כל פלטפורמת ענן:

המלצות ומשמעויות כספיות:

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

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

לסיכום

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