Chaos Engineering או תיקונים בסביבת הייצור
כמויות גדולות של משאבים מושקעות בבדיקת מוצרי תוכנה כאשר חברות שואפות לבנות מוצר יציב ועמיד במיוחד. עם זאת, הדבר לא תמיד מניב את התוצאות הרצויות.
האם תיקון מוצר התוכנה בסביבת הייצור נשמע טוב יותר משבירת התוכנה? ובכן, הדבר עשוי להיות תלוי במי נשאל.
אז אולי עלינו לבחור באילו מילים להשתמש כאשר אנו מציגים זאת לבעלי עניין או למנהלים. יש כאלה שאולי לא יאהבו מונחים "הרסניים" ולעיתים נידרש להשתמש במונחים "יצירתיים". אך שבירת התוכנה כדי לראות את חולשותיה ולהפוך אותה לחזקה, אמינה ויציבה יותר מובילה אותנו למסקנה שעלינו לשבור אותה תחילה ואז לתקן אותה.
איך זה נקרא כאשר אתה מתנסה בתוכנה כדי לראות כמה זמן היא תחזיק מעמד תחת העומס הנתון וכמה זמן היא תוכל לשמור על שלמותה לפני שתתקלקל? האם יש לזה שם?
הרשו לי להציג בפניכם את Chaos Engineering (להלן בטקסט CE).
מהי הנדסת כאוס?
כמה הגדרות של CE אומרות שזו הדיסציפלינה של ביצוע ניסויים על מערכת על מנת לבנות אמון ביכולתה של המערכת לעמוד בתנאים סוערים בסביבת הייצור.
נניח שאתם בונים תוכנה שמבצעת פונקציונליות כלשהי. התוכנה עובדת היטב ומתפקדת היטב בכל הבדיקות שנערכו. אבל מה אם בסביבת הייצור התוכנה תידחף עד לקצה גבול היכולת שלה ובסופו של דבר תתקלקל. אובדן ההכנסות עלול להיות עצום. ככל שהמערכת גדולה יותר, כך ההפסד עלול להיות משמעותי יותר. כדי למנוע זאת, עלינו למזער את הסיכון שהוזכר קודם לכן.
יש ליישם CE במערכות עצומות הזמינות למשתמשים כמעט בכל עת. ככל שיש יותר משתמשים, כך ההשפעה גדולה יותר.
בואו נצלול לעומק הנושא הנתון.
הנדסת כאוס בפועל
כאשר אנו מדברים על פיתוח תוכנה, עלינו לחשוב על עמידותה של מערכת תוכנה, אשר בדרך כלל מוגדרת כדרישת תוכנה. זוהי היכולת של מערכת תוכנה נתונה לסבול כשלים תוך הבטחת איכות שירות (QoS) נאותה. דרישה זו עשויה לעיתים קרובות להיות קשה להשגה עבור צוותי פיתוח בשל ידע מועט או לוח זמנים צמוד לפרויקט. כאן נכנסת לתמונה הנדסת כאוס.
CE היא טכניקה המסייעת לעמוד בדרישת העמידות ויכולה לשמש כנגד כשלי אפליקציה, כשלי תשתית וכשלי רשת.
הדבר נעשה על ידי הזרקת כשלים במערכת הספציפית באופן מבוקר ומנוטר, כדי לקבל תובנה לגבי עמידותה של מערכת נתונה. אם מתגלים פגמים משמעותיים, עלינו לטפל במצב כדי למצוא פתרון לצמצומם. עם CE, אנו יכולים לחשוף חולשות במערכת ספציפית, למצוא פתרון להתמודדות עמן ולבנות מערכת עמידה יותר עם סיכון מינימלי לאובדן הכנסות או ל"בושת שוק" שהמשתמשים שלנו יכולים ליצור על ידי ביקורת על תוכנה ספציפית.
ניסויי CE עוקבים אחר מספר הנחיות או שלבים.
שלב #1
עלינו להגדיר מצב תקין של המערכת הנצפית שאמור לייצג את ההתנהגות התקינה ושתהיה לו פלט מדיד. לשם כך, עלינו למדוד את פלט המערכת על פני פרק זמן קצר ולהגדיר נתונים אלו כמצב תקין או יציב.
שלב #2
עלינו להניח הנחה שמצב תקין זה יהיה נוכח הן בקבוצת הביקורת והן בקבוצת הניסוי. היא צריכה להתבסס על נתונים מדידים שכבר אספנו.
שלב #3
עלינו להציג את המצבים המייצגים אירועי עולם אמיתי אשר ידמו בעיות שרת (כיבוי שרת, תגובות פגומות, זינוקי תעבורה, מיצוי משאבים), בעיות רשת (רוחב פס נמוך, השהיה, אובדן מנות או כשל קישור מוחלט), בעיות דיסק קשיח (מיצוי משאבים, נתונים פגומים) וכו'.
רצוי לבצע ניסויים אלה ישירות בסביבת הייצור כדי להבטיח את האותנטיות והרלוונטיות של המערכת הפרוסה כעת. אך יש להיזהר שלא להשפיע על המשתמשים במהלך התהליך. אם חוויית המשתמש נפגעת, יש להפסיק את הבדיקה מיד. יש ללמוד מהניסיון הזה ולהתאים את אסטרטגיית הבדיקה. יש לנסות שוב.
שלב #4
עלינו להפריך את ההשערה עם המצבים השונים הן בקבוצת הביקורת והן בקבוצת הניסוי.
שלב #5
אוטומטו את התהליך כדי להריץ את הניסויים הללו באופן רציף. באופן ידני זה עלול להיות בלתי בר-קיימא.
המערכת צריכה לתפקד למרות כשלים, וכאן נכנסת לתמונה הנדסת כאוס.
היתרונות של הנדסת כאוס
CE יכול להיות קצת קשה להגדרה בהתחלה, אך בטווח הארוך זה אמור להשתלם. אנו יכולים לראות את היתרונות שלו מנקודת מבט עסקית, של הלקוח וטכנית.
מנקודת מבט עסקית, כשלים במערכת יכולים להוביל את החברה למצב לא רצוי בשוק, וזה יכול לגרום לאובדן הכנסות, למוניטין שלילי, לעלויות תחזוקה גבוהות, לקשיים בגיוס עובדים חדשים ובחתימת חוזים עסקיים חדשים וכו'.
מנקודת המבט של הלקוח, CE יכלה לשמור על ביקורות מוצר טובות, זמינות מוצר גבוהה, מוניטין טוב בקרב משתמשים קיימים וזרימה יציבה של משתמשים חדשים.
מנקודת המבט הטכנית, טכניקה זו יכולה לסייע בצמצום בעיות מערכת או תקלות, לסייע בהבנה טובה יותר של חולשות המערכת, לשפר את המערכת ולשפר את המהירות הנדרשת לתיקון התקלות.
הדוגמאות מהחיים האמיתיים לדברים שיכולים לקרות הן רבות.
כולנו משתמשים במדיה חברתית לצורך תקשורת. רובנו נמצאים בקבוצות מסוימות. נניח שאתם מפספסים התראה אחת שאמורה להגיע בדיוק בזמן כדי שתנקטו פעולה מסוימת. היא מגיעה מאוחר מדי. תרחיש אחר: דמיינו שיש לכם פתרון בסמארטפון שיכול לעקוב אחר המיקום הגיאוגרפי שלכם ונותן לכם מידע שגוי.
הנה כמה דוגמאות נוספות. תארו לעצמכם כמה דברים יכולים להשתבש במקרה של טכנולוגיה המשמשת לנהיגה אוטונומית. מקרה נוסף יכול להיות פתרון תוכנה פנימי שיוצר קבצי PDF שלעיתים קרובות עובדים זקוקים להם כדי לחתום על עסקים חדשים. אם פתרון התוכנה הזה יפסיק לעבוד כאשר ישנם דברים שצריכים להיות מסופקים בזמן, אזי ההשפעה על רווחי החברה יכולה להיות מורגשת.
ולבסוף, דמיינו שהחברה שלכם היא בנק גדול עם סניפים רבים המחזיק בנתח שוק משמעותי במדינה מסוימת. גרסה חדשה של אפליקציית הבנק יוצאת לאור. האפליקציה נבדקה באופן שטחי עקב מחסור במשאבים, אך הוחלט להעלות אותה לפרודקשן. במעבר לפרודקשן מתעוררות בעיות סביבתיות מסוימות, והאפליקציה הופכת לבלתי זמינה לכל משתמשיה. דירוג האפליקציה בחנות יורד. גם המוניטין של החברה נפגע. יש להימנע ממצבים כאלה באמצעות גמישות והכשרת המהנדסים.
אולי עם CE במקום, הדברים האלה לא היו קורים.
בואו נבהיר כמה דברים
אם עדיין לא נתקלתם במונח הנדסת כאוס, ייתכן שאתם תוהים לגבי כמה דברים, לכן הרשו לי להסביר אותם.
- CE לא נועד ליצור כאוס אלא להוות פתרון במקרה שהבעיות שהוזכרו מתעוררות.
- הכול נעשה בסביבה מבוקרת (לפחות כך זה אמור להיות אם אתה לא רוצה לבלגן את העניינים).
- הכל מנוטר גם כן מכיוון שאנו זקוקים לנתונים אלה בהמשך
- מלבד הוספת תכונות חדשות, מפתחים דואגים לאמינות, כותבים ומבצעים בדיקות יחידה.
- פתרונות תוכנה צריכים להיות נבדקים היטב לפני הייצור, ו-CE חורג מכך. בדיקות מספקות נתונים שאנו מצפים להם. CE מספק נתונים בלתי צפויים שניתן להשתמש בהם ליצירת פתרונות עמידים.
- CE מיועד בעיקר למערכות גדולות, כפי שהוזכר קודם לכן, אך הוא שימושי גם למערכות קטנות יותר.
- לא נדרשים כלים מיוחדים.
- מומלץ להפוך את הנדסת כאוס לאוטומטית.
- באמצעות ניסויים ב-CE, אנו לומדים מאפיינים חדשים של המערכת וצוברים ידע חדש או בונים את הביטחון שלנו בפתרון התוכנה.
שימוש בהנדסת כאוס
בשנת 2011 פרסמה Netflix את המאמר "The Netflix Simian Army", שהיה הפעם הראשונה שבה הוצגה הנדסת כאוס (Chaos Engineering). מתוך אותו סיפור גם נולד "Chaos Monkey" (שפותח בשנת 2010 על ידי צוות ההנדסה של Netflix) ככלי תוכנה המדמה באופן אקראי כשלים של מופעי פרודקשן. ייתכן שחלקנו צפו בחיילים ממערב אפריקה מוסרים רובה AK-47 לקוף (YouTube: "Ape With AK-47"), דבר הדומה לתוצאות – בלתי צפויות. כמו כן, Chaos Monkey אינו פועל כשירות, אלא כמעין משימת cron מתוזמנת אשר קוראת ל-Chaos Monkey פעם בשבוע כדי ליצור לוח זמנים של סיומים.
הזכרנו את "Simian Army" ממש לפני רגע – אז מה זה? זוהי חבילה שלמה של כלים המעוררים כשלים, החורגת מעבר ל-Chaos Monkey עצמו. היא כוללת את Latency Monkey, Conformity Monkey, Doctor Monkey, Janitor Monkey, Security Monkey, 10-18 Monkey, Chaos Gorilla ו-Chaos Kong. נעזוב זאת לעת עתה, שכן ייתכן שיהיה זה יותר מדי לפרט מה בדיוק עושה כל כלי. חבילה זו נוצרה ב-2011. ב-2012 Chaos Monkey הפך לזמין לציבור.
בשנת 2016 הוצג ה-"Gremlin" על ידי Kolton Andrus ו-Matthew Fornaciari, ובסוף 2017 הוא הועמד לרשות הציבור כפתרון ה-CE הארגוני המנוהל הראשון בעולם.
בשנת 2019, CE עברה לשיקולים רציניים של אימוץ, בעיקר על ידי מסחר אלקטרוני וחברות טכנולוגיה גדולות. זה מובן בגלל ההשפעה הישירה על ההכנסות עקב זמן ההשבתה שעלול להתרחש.
בשנת 2020, "Amazon Web Services" (AWS) הוסיפה את CE ל-"Well-Architected Framework" (WAF) ו-"Fault Injection Simulator" (FIS) הוצג כשירות להרצת ניסויי כאוס באופן מקורי ב-AWS. עד מהרה כמה עסקים עצומים החלו לאמץ את Chaos Engineering.
בשנת 2021, לראשונה אי פעם, פרסמה Gremlin את דוח State of Chaos Engineering המדגים את חשיבות ה-CE.
הפחתת זמן התיקון הממוצע (MTTR) וזמן הזיהוי הממוצע (MTTD), פחות באגים ועמידות גבוהה יותר של המערכת הם היתרונות שנמצאו במחקר על השפעת ה-CE בחברות שאימצו את ה-CE.
כלים שנוכל לציין הם Chaos Mesh, Litmus, ChaosBlade, בין אלה שכבר הוזכרו Gremlin, Simian Army ו-Chaos Monkey. כלים אחרים זמינים גם כן, אך אשאיר זאת לך.
שימוש ב-Chaos Engineering עשוי להעיד שחברות מסוימות מיישמות אסטרטגיית בדיקות "shift left" הממוקמת בשלבים ההתחלתיים ביותר של מחזור חיי פיתוח התוכנה (SDLC).
ולבסוף, כך מגדירים CE בדרך המיטבית:
- עצבו את חוסן המערכת ברמות התשתית, הרשת, הנתונים, האפליקציה, האנשים והתרבות.
- השתמשו בפסקי זמן, ניסיונות חוזרים ומנגנוני גיבוי – טכניקות שאומצו על ידי Netflix.
- בעת תחילת יצירת השערה, נסו את טכניקת החשיבה החישובית.
- השתמשו בצוות Chaos Engineering כדי להכין עבורכם את כל הדרוש ל-CE.
- הכשירו את עצמכם ואת העובדים שלכם.
- השתמש באסטרטגיית Canary Deployment ו-Canary Testing, שכן זוהי הדרך הבטוחה ביותר להחדיר כשל ולנטר תוצאות.
אימוץ Chaos Engineering יכול להניב תשואה על ההשקעה (ROI) בכל הנוגע לזמינות ולאמינות השירותים של החברה.
אני מקווה שפיתוח תוכנה עתידי ישתמש באסטרטגיות ובשיטות העבודה הטובות ביותר הזמינות והמוסברות.
תקציר
Chaos Engineering היא גישה ממושמעת לבדיקת עמידות תוכנה על ידי הכנסה מכוונת של כשלים מבוקרים למערכת. במקום להסתמך solely על בדיקות מסורתיות, היא עוזרת לארגונים להבין כיצד אפליקציות מתנהגות תחת לחץ בעולם האמיתי, כולל בעיות תשתית, שיבושים ברשת או זינוקים בלתי צפויים בתעבורה. על ידי ביצוע ניסויים בסביבות מנוטרות, צוותים יכולים לזהות חולשות מוקדם, לשפר את אמינות המערכת ולהפחית את הסיכון להשבתה יקרה בייצור.
שיטה זו חשובה במיוחד עבור מערכות בהיקף גדול בעלות זמינות גבוהה, שבהן כשלים עלולים להשפיע על הכנסות, מוניטין ואמון הלקוחות. Chaos Engineering תומכת בתגובה טובה יותר לאירועים, מפחיתה את הזמן הממוצע לזיהוי ולפתרון ומחזקת את היציבות הכוללת של המערכת. עם אימוץ מוכח על ידי חברות כמו Netflix ו-AWS, היא הפכה לפרקטיקה חשובה לבניית מערכות תוכנה מודרניות ועמידות.
Chaos Engineering היא פרקטיקה הכוללת הכנסה מכוונת של כשלים למערכת כדי לבחון את עמידותה ואת יכולתה לעמוד בהפרעות מהעולם האמיתי. היא מסייעת לצוותים לזהות חולשות לפני שהן גורמות לבעיות בייצור.
מערכות מודרניות הן מורכבות ומבוזרות, מה שהופך אותן לרגישות יותר לכשלים בלתי צפויים. Chaos Engineering מאפשר לארגונים לבדוק תרחישים אלה באופן יזום, להפחית זמן השבתה, לשפר אמינות ולהגן על ההכנסות.
לא. בדיקות מסורתיות מתמקדות בהתנהגויות צפויות בסביבות מבוקרות, בעוד ש-Chaos Engineering בוחן תנאים בלתי צפויים בסביבות אמיתיות או דמויות ייצור כדי לחשוף חולשות נסתרות במערכת.
זה יכול, אם לא מנהלים זאת בזהירות. עם זאת, שיטות עבודה מומלצות כוללות ביצוע ניסויים מבוקרים ומנוטרים, לרוב עם אמצעי הגנה כגון פריסות canary, כדי למזער או להימנע מכל השפעה שלילית על המשתמשים.
Chaos Engineering מועיל ביותר למערכות הדורשות זמינות גבוהה, כגון פלטפורמות מסחר אלקטרוני, אפליקציות בנקאיות ושירותים דיגיטליים בהיקף רחב. ניתן גם להציגו בשלב מוקדם יותר במחזור החיים של הפיתוח כדי לבנות חוסן מלכתחילה.
פעלו לפי אסטרטגיות ושיטות הפיתוח הטובות ביותר. הפקידו את הפרויקט שלכם בידי המומחים שלנו.
Marcin Zyga
Chief AI & Information Officer