שיעורים על מצוינות תפעולית שלמדתי במשך עשור באמזון: כך נמנע את תקרית CrowdStrike הבאה
שיעורים על מצוינות תפעולית שלמדתי במשך עשור באמזון: כך נמנע את תקרית CrowdStrike הבאה
תקרית הסייבר העולמית שנגרמה בעקבות תקלה בקרב המערכות של CrowdStrike, הייתה תזכורת כואבת לחשיבותה של מצוינות תפעולית בקרב חברות סייבר. בעולם הדיגיטלי של היום, איכות הנהלים שעומדים מאחורי הכשלים הטכניים היא שתקבע אם תקלה קטנה תהפוך למשבר עולמי או שתעבור בשלום.
אז איך חברות סייבר יכולות למנוע את התקלה הבאה? איך יוצרים חסינות אל מול אתגרים טכנולוגיים ותקלות בלתי צפויות? ואיך נראים נהלים שמשקפים מצוינות תפעולית? על בסיס מידע והניסיון שצברתי במשך יותר מעשור של עבודה עבור הארגונים הגדולים בעולם, ביניהם; AWS, אמזון ו-VMWare - הרכבתי מספר כללי אצבע שנועדו למנוע את התקלה הבאה, בהם משתמשים ארגונים אלו לצד Upwind, בה אני משמש כסמנכ"ל מוצר בשנה האחרונה.
מציאת סיבת השורש - ומעבר לה
קל היה למצוא את הסיבה הטכנית שגרמה לתקלה במערכות Crowdstrike, אך היא הייתה רק חלק קטן מן הבעיה הגדולה שהביאה לקריסה עולמית שראינו. התקלה נגרמה כתוצאה מעדכון תקול לקובץ ההגדרות של מנהל ההתקן של Falcon, שגרם לשגיאה לוגית ברכיב הליבה של החיישן. כתוצאה מכך - נגרמה תקלה בכל מחשב שהושפע ממנו.
די פשוט לומר, "מצאנו את הבעיה, נתקן אותה, ונבצע בדיקות טובות יותר בפעם הבאה". אבל השאלה האמיתית היא - מדוע התקלה לא אותרה עוד לפני שחרור הגרסה? זו בדיוק המשמעות של מצוינות תפעולית. תיקון תקלות עם גילויין הוא בהחלט חשוב, אך בניית נהלים משמעותיים ומעקב אחריהם בכל שכבות הארגון חשובה הרבה יותר. באמצעות כך, ניתן להקטין את הסיכוי לכשל דרמטי, להקל על ההתמודדות עם תקלה בעת שהיא מתרחשת וגם לאפשר זיהוי מוקדם של בעיות.
פיתוחים טכנולוגיים עלולים להיכשל ואף צפויים לעשות זאת, אבל המנגנונים התפעוליים שסביבם לא אמורים לקרוס יחד איתם. המפתח ליצירת סביבה ארגונית בטוחה הוא לנטר את המערכות באופן תמידי, לצפות ולהתכונן לכשלונות ולאחר שהם מתרחשים - לטפל ולחקור אותם בצורה מהירה וסדורה.
אם כן, הצעד הראשון לחברה שחוותה תקלה צריכה לעשות הוא להבין מהם הכשלים התפעוליים שעמדו מאחוריה. הדרך הטובה ביותר לעשות זאת היא שיטת "חמשת ה-Whys". מדובר בכלי פשוט אך חזק לחשיפת ניתוח סיבות שורש התקלות, במסגרתו נשאל את עצמנו שוב ושוב "למה?". באמזון, השיטה הזו הייתה חלק בלתי נפרד מתהליך תיקון השגיאות שלנו, ועזרה לנו ליצור חשיבה ביקורתית ולפתור בעיות מערכתיות במקום סימפטומים בודדים.
להמחשת השיטה על תקרית CrowdStrike: נשאל, למה קרתה התקלה? כי החיישן ניסה לגשת לקלט שלא היה בזיכרון (למה?), כי הוא ציפה ל-21 קלטים וקיבל רק 20 (למה?) כי כך הוגדר הקוד (למה?) כי התבניות שהוגדרו לו לא נבדקו במלואן (למה?) כי הן לא גרמו לתקלות במסגרת עדכונים קודמים.
כעת, כשיש לנו שיטה אפקטיבית לתחקור בעיות, נוכל לשאול את עצמנו - איך ניתן למנוע בעיות עתידיות באמצעות מצוינות תפעולית ונהלים ברורים?
הצעד הראשון הוא לדאוג שבכל צוות יהיה גורם מוגדר מראש שישמש כמנהל אירוע במהלך התקלה, כך שתמיד יש למי לפנות ברגע האמת. הצעד השני הוא יצירת ערוצי תקשורת ייעודיים למצבי חירום, הכוללים צוותי שירות לקוחות ותקשורת חיצונית, באמצעותם ניתן לנהל ציפיות ולהגן על המוניטין של הארגון. עוד מרכיב חשוב שמסייע בהתנהלות הוא יצירת מערכת תעדוף ברורה על פי רמת חומרת התקלה, כל הבעיות הקריטיות יטופלו בהקדם. כאמור, מומלץ לבצע תחקירים כדי לטפל בממצאים, כשלפעמים תיקון באג קטן יכול להוביל לשיפורי מערכת משמעותיים. לסיום, גם כאשר הכל עובד בדיוק כמו שצריך, חשוב לבצע תרגילים וסימולציות קבועות לזיהוי חולשות במערכות.
לסיכום, יצירת תרבות של מצוינות תפעולית היא מסע מתמשך המשקף את חוזקו של הארגון. באמזון, ביקורות מוכנות תפעולית (ORR) היו חיוניות לפני כל השקת מוצר או פיצ'ר מרכזי, והן נערכו בקפדנות כדי להבטיח מוכנות ובטיחות. אם הבדיקה לא עברה בהצלחה, המוצר לא הושק - גם כשמחיר הדחייה היה כבד.
מצוינות תפעולית רציפה וממושכת צריכה להיות חלק מהתרבות הארגונית שלך. מדובר מחויבות מתמשכת שיש לתחזק באמצעות פגישות חוץ ארגוניות אשר כוללות את כל הדרגים. תקרית Crowdstrike מזכירה לנו שאפילו הטכנולוגיה הטובה ביותר יכולה להיכשל אם לארגון שפיתח אותה אין נהלי תפעול מצוינים וחזקים. הסיפור תמיד יהיה רחב יותר מהטכנולוגיה, מכיוון שכדי ליצור טכנולוגיה מעולה שיכולה להתמודד עם תקלות ואתגרים, יש ליצור סביבת עבודה במסגרתה כשלים ותקלות מובילים לשיפורים מערכתיים משמעותיים.
ג'ושוע בירגין הוא CPO ב-Upwind Security
