היום שבו 8.5 מיליון מחשבים מתו — ומה זה לימד אותי על בניית תוכנה שלא יכולה להיכשל
ישבתי בלובי של מלון בהיידראבאד כשהטלפון שלי התחיל לרטוט. לא הזרזיף הרגיל של התראות Slack — זה היה מבול. כל צי מכונות ה-Windows של לקוח אחד עבר לכחול. אחר כך לקוח נוסף. ואז פרצה הידיעה: שדות תעופה מקרקעים טיסות, בתי חולים מבטלים ניתוחים, בנקים מקפיאים עסקאות. הכול בגלל עדכון קובץ יחיד מ-CrowdStrike שהיה קטן יותר מהתמונה שהייתם מצלמים של ארוחת הצהריים שלכם.
19 ביולי 2024. היום שבו כ-8.5 מיליון מערכות Windows קרסו בו-זמנית אל מסך המוות הכחול (Blue Screen of Death). היום שבסופו של דבר עלה לכלכלה העולמית יותר מ-$10 מיליארד בנזקים. והיום שבו נעשיתי אובססיבי לשאלה שעדיין מדירה שינה מעיניי: מדוע אנו בונים את המערכות הקריטיות ביותר בהיסטוריה האנושית על יסודות שקובץ תצורה יחיד יכול להרוס?
אני מנהל את Veriprajna, חברת ייעוץ בתחום ה-AI. אנחנו בונים את מה שאני מכנה פתרונות "Deep AI" — מערכות שמשתלבות בתשתית הליבה, ולא עטיפות ChatGPT דקות ששולטות בשוק כרגע. כשקרתה תקלת CrowdStrike, מחצית מתעשיית ה-AI משכה בכתפיים. "בעיה של אבטחה", אמרו. "לא התחום שלנו". אבל אני ראיתי משהו אחר. ראיתי בדיוק את אותה שבריריות ארכיטקטונית שפוקדת כל ארגון שממהר להרכיב AI על גבי הפעילות שלו בלי להבין מה קורה מתחת לפני השטח.
במשך חודשים אחרי התקלה פירקתי לגורמים את ניתוח שורש הבעיה, עקבתי אחר ההליך המשפטי של Delta Air Lines, וחקרתי את המחקר המתפתח על אימות פורמלי. מה שגיליתי שינה את הדרך שבה הצוות שלי בונה הכול. כתבתי כאן פירוק אינטראקטיבי ומקיף של הניתוח המלא, אבל המסה הזו היא הסיפור שמאחורי המחקר — החלקים שלא נכנסים בצורה מסודרת לתוך נייר לבן.
קובץ קטן מ-JPEG הפיל את התעופה העולמית
הנה מה שקרה באמת, בלי הז'רגון.
פלטפורמת האבטחה Falcon של CrowdStrike פועלת בתוך ליבת (kernel) מערכת ההפעלה Windows — השכבה העמוקה והמיוחסת ביותר של מערכת ההפעלה. תחשבו על זה כעל חדר המנועים של אונייה. אם משהו משתבש למעלה על הסיפון, אפשר לתקן. אם משהו משתבש בחדר המנועים, האונייה טובעת.
כדי לזהות איומים חדשים במהירות, CrowdStrike בנתה מערכת בשם "Rapid Response Content". במקום לדחוף עדכוני תוכנה מלאים (שהם איטיים ודורשים בדיקות), הם דוחפים קובצי תצורה קטנים — למעשה דפי הוראות שאומרים למנוע האבטחה אילו דפוסים לחפש. זה חכם. זה גם, כפי שלמדנו, מסוכן באופן מפחיד.
באותו בוקר נפרסו שתי מערכות הוראות חדשות לזיהוי סוג מסוים של תקשורת בין-תהליכית. ההוראות האלה הפנו אל 21 פרמטרי קלט. הבעיה? המנוע שרץ על כל נקודת קצה — הקוד עצמו שמתבצע בליבה — הבין רק 20 פרמטרים.
הענן אמר "קראו 21 שדות". הליבה ידעה על 20 בלבד. אי-ההתאמה הזו הקריסה 8.5 מיליון מחשבים.
המאמת בענן אישר את העדכון מכיוון שאצלו הגדרת התבנית כללה 21 שדות. הוא בדק מול הציפייה של עצמו, לא מול המציאות של מה שנקודת הקצה יכלה להתמודד איתו. כשהמפרש ברמת הליבה ניסה לגשת לשדה ה-21 הזה, הוא קרא מעבר לגבול הזיכרון המוקצה. במרחב הליבה, זו אינה שגיאה שניתן להתאושש ממנה. זו קריסה מיידית. מסך כחול. אתחול. קריסה שוב. אתחול. קריסה שוב. לולאת מוות אינסופית.
אני זוכר שהסברתי את זה למשקיע לא-טכני על ארוחת ערב כמה שבועות מאוחר יותר. הוא בהה בי ואמר, "אז אתה אומר לי שאף אחד לא בדק אם הדבר שמקבל את העדכון בכלל מסוגל לעבד את העדכון?" הנהנתי. הוא הניח את המזלג. "זה לא באג תוכנה. זו רשלנות."
הוא לא טעה. ושופט בג'ורג'יה, למעשה, יסכים איתו.
מדוע 40,000 שרתים היו חייבים להיות מתוקנים ביד
החלק בסיפור שלא זוכה למספיק תשומת לב הוא השחזור — או ליתר דיוק, אי-האפשרות של שחזור מרחוק.
הנה האירוניה האכזרית: סוכן CrowdStrike הוא הדבר שמקבל פקודות מהענן. "בטל את העדכון הזה". "החל את התיקון הזה". אבל הקריסה קרתה כה מוקדם ברצף האתחול שהסוכן מעולם לא אותחל. התוכנה שאמורה הייתה לקבל את אות ההצלה הייתה בדיוק הדבר שגרם לטביעה.
הצוות שלי התחיל לקרוא לזה בעיית "הסוכן המת". כל מכונה שנפגעה נותרה יתומה. היא לא יכלה ליצור קשר עם הבית. היא לא יכלה לקבל הוראות. התיקון היחיד היה לאתחל פיזית כל מכונה למצב בטוח (Safe Mode), לנווט אל C:\Windows\System32\drivers\CrowdStrike\, ולמחוק ידנית את הקובץ הפגום.
עבור Delta Air Lines, פירוש הדבר היה נגיעה בכ-40,000 שרתים ואלפי תחנות עבודה. ביד. אחת בכל פעם.
ניהלתי בעבר מבצעי שחזור IT, והלוגיסטיקה בקנה מידה כזה כמעט בלתי נתפסת. אתה צריך גישה פיזית למכונות שעשויות להימצא בחדרי שרתים נעולים בערים שונות. אתה צריך טכנאים שיודעים לאתחל למצב בטוח — שבעידן של הצפנת BitLocker לרוב דורש מפתחות שחזור המאוחסנים על... שרתים אחרים שגם הם קרסו. זה צבים עד הסוף.
המתחרות של Delta — American Airlines, United — התאוששו תוך יום עד שלושה ימים. השיבוש של Delta נמשך יותר מחמישה ימים והביא ליותר מ-7,000 טיסות שבוטלו ו-$550 מיליון בהפסדים. ההבדל? מערכת מעקב הצוותים של Delta, התוכנה שמספרת לחברת התעופה היכן נמצאים הטייסים והדיילים שלה ומתי הם זמינים, פעלה כמעט לחלוטין על Windows. כששרתים אלה מתו, Delta לא רק איבדה מחשבים. היא איבדה את היכולת לדעת היכן נמצאים אנשיה שלה.
מה קורה כשבאג תוכנה הופך ל"רשלנות חמורה"?
כאן הסיפור עובר מחדר השרתים לאולם בית המשפט, וכאן, לדעתי, ההשלכות נעשות באמת משנות-תעשייה.
Delta תבעה את CrowdStrike. זה לבדו אינו מפתיע — חברות תובעות ספקים אחרי כשלים גדולים כל הזמן. מה שמפתיע הוא מה שהשופטת התירה להמשיך.
מבחינה היסטורית, ספקי תוכנה היו מוגנים על ידי החוזים שלהם. בתוך תנאי השירות תמיד קבורה תקרת אחריות — לרוב מוגבלת לכל מה שהלקוח שילם עבור המנוי. זה הסדר נוח. אתה מוכר תוכנה שפועלת ברמה העמוקה ביותר של תשתית הלקוח, ואם היא הורסת הכול, החשיפה המרבית שלך היא שנים עשר חודשי דמי רישוי.
במאי 2025, השופטת Kelly Lee Ellerbe מבית המשפט המחוזי של מחוז Fulton סירבה לדחות את טענות Delta בדבר רשלנות חמורה ו — וזו הטענה שגרמה לי להתיישר בכיסא — הסגת גבול מחשב.
טענת הרשלנות החמורה פשוטה: CrowdStrike דחפה את העדכון לכל 8.5 מיליון המערכות בו-זמנית. ללא פריסה מדורגת. ללא פריסת קנרי (canary). ללא "בואו ננסה את זה קודם על 1% מהמכונות ונראה מה קורה". עורכי הדין של Delta טענו שזה מייצג התעלמות מודעת מסיכונים ידועים. הדוח הפנימי של CrowdStrike לאחר האירוע הודה שב-Content Validator הייתה שגיאת לוגיקה ושה-Content Interpreter חסר בדיקת גבולות בזמן ריצה.
אבל טענת הסגת גבול המחשב היא זו שאמורה להטיל אימה על כל ספק SaaS שקורא את זה. Delta ביטלה את ההסכמה לעדכונים אוטומטיים בהגדרותיה. CrowdStrike דחפה את העדכון בכל זאת דרך מנגנון קובץ הערוץ ברמת הליבה. השופטת פסקה שחובות סטטוטוריות בנוגע להסגת גבול מחשב הן בלתי תלויות בהסכם המנוי — כלומר תקרת האחריות שבחוזה אינה חלה.
כשספק עוקף את ההעדפות המפורשות שלך כדי לדחוף קוד לתוך הליבה שלך, תקרת האחריות שבחוזה עשויה שלא להגן עליו. זו המציאות המשפטית החדשה.
שוחחתי עם שלושה מנהלי אבטחת מידע (CISO) שונים מאז הפסיקה הזו, וכל אחד מהם אמר את אותו הדבר: "אנחנו כותבים מחדש את הסכמי הספקים שלנו". עידן האמון הבלתי מוגבל בעדכונים אוטומטיים מספקי אבטחה הסתיים.
ההקבלה הלא-נוחה לתעשיית ה-AI
כאן אני עומד להיות בוטה, וכאן חלק מהעמיתים שלי בתחום ה-AI לא יאהבו את מה שיש לי לומר.
תעשיית ה-AI בונה על אותם יסודות שבריריים ש-CrowdStrike חשפה. אנחנו פשוט עושים את זה מהר יותר ועם יותר הייפ.
השוק כרגע נשלט על ידי מה שאני מכנה "עטיפות LLM" — שכבות יישום דקות שמבצעות קריאות API ל-GPT-4 או ל-Claude, עוטפות את התגובה בממשק משתמש נחמד, וקוראות לזה מוצר AI. ראיתי מצגות גיוס מחברות שכל הארכיטקטורה הטכנית שלהן היא פשוטו כמשמעו "אנחנו שולחים פרומפט ל-OpenAI ומציגים את התוצאה". הן מוערכות בעשרות מיליוני דולרים.
הייתי בכנס בשנה שעברה שבו מייסד הדגים בגאווה את "כלי ניתוח האבטחה המונע-AI" שלו. שאלתי שאלה פשוטה: "מה קורה אם OpenAI משנה את ה-API שלו, מעלה מחירים פי 10, או נופל למשך שש שעות?" הוא הביט בי כאילו שאלתי מה קורה אם כוח הכבידה יפסיק לפעול. "זה לא יקרה", הוא אמר.
זה יקרה. זה תמיד קורה. תקלת CrowdStrike הוכיחה שאפילו ספקי התשתית המהימנים ביותר, אלה שהימרתם עליהם את כל הפעילות שלכם, יכולים לדחוף קובץ פגום אחד ולהפיל את הכול.
לכן בנינו את Veriprajna סביב מה שאני מכנה "Deep AI" — ואני רוצה להיות מדויק לגבי כוונתי, כי המונח מושלך לכל עבר ברישול.
פתרון Deep AI אינו שוכר את הבינה שלו מספק צד-שלישי יחיד. הוא משתמש בארכיטקטורות היברידיות — מודלי שפה קטנים ומתמחים, מודלי ראייה-שפה, רשתות עצביות מבוססות-גרף — הפרוסים על התשתית של הלקוח עצמו כשמקרה השימוש דורש זאת. הוא משתלב ברמת המערכת, לא ברמת ממשק המשתמש. וחשוב מכך, הוא משתמש באימות פורמלי כדי לספק ערבויות מתמטיות לגבי התנהגותו, ולא רק ניחושים הסתברותיים מיטביים.
ההבדל חשוב. עטיפת LLM נותנת לך צ'אטבוט שלרוב צודק. מערכת Deep AI נותנת לך מנוע שניתן להוכיח מתמטית שהוא נכון עבור המשימה הספציפית שאותה הוא נועד לבצע.
מדוע נעשיתי אובססיבי לאימות פורמלי
אהיה כן: לפני תקלת CrowdStrike, חשבתי שאימות פורמלי הוא סקרנות אקדמית. משהו שחוקרים מפרסמים עליו מאמרים ואף אחד לא משתמש בו בסביבת ייצור. המיקרו-קרנל seL4 — ליבת מערכת הפעלה שאומתה פורמלית — היה מרשים אך נראה כהישג חד-פעמי שדרש שנים של מאמץ ברמת דוקטורט.
אז קראתי את ניתוח שורש הבעיה של CrowdStrike בפעם השלישית, ומשהו התחבר.
כל האסון התמצה בפער סמנטי. המאמת בענן האמין שלתבנית יש 21 שדות. המפרש בנקודת הקצה האמין שיש לה 20. שני רכיבים של אותה מערכת החזיקו באמונות סותרות לגבי המציאות, ואף אחד לא תפס זאת כי לא היה מפרט משותף וקפדני מתמטית ששני הרכיבים אומתו מולו.
אימות פורמלי מבטל פערים סמנטיים. הוא משתמש בהוכחות מתמטיות כדי להבטיח שהתוכנה — היישום עצמו — תמיד עומדת במפרט שלה. לא "לרוב". לא "בבדיקות שלנו". תמיד. אם ההוכחה מאומתת, התוכנה אינה יכולה להפר את המפרט שלה. נקודה.
הצוות שלי בילה שבועות בשנה שעברה בהתנסות במסגרת עבודה בשם VeCoGen, המשלבת מודלי שפה גדולים עם מנועי אימות פורמלי כדי לייצר אוטומטית קוד C מאומת. ה-LLM מציע יישומים מועמדים, ובודק הוכחות מאשר מתמטית את הנכונות לפני שמשהו נפרס. אם בקוד יש באג — אפילו עדין כמו שגיאת off-by-one בגבול מערך — ההוכחה נכשלת והקוד נדחה.
אני זוכר את הפעם הראשונה שהצלחנו להריץ אותו על דוגמה לא-טריוויאלית. מהנדס הצוות הראשי שלי, שהיה סקפטי לגבי כל המיזם, הביט בפלט המאומת ואמר, "אז ה-AI כותב את הקוד וגם את ההוכחה שהקוד נכון?" כן. ובודק ההוכחות הוא מערכת נפרדת ומהימנה שלא אכפת לה מהביטחון של ה-AI — אכפת לה רק מהאמת המתמטית.
אנחנו נכנסים לעידן שבו קוד שנוצר על ידי AI יועדף על פני קוד שנכתב ביד — לא כי AI חכם יותר, אלא כי AI יכול לייצר את ההוכחה המתמטית לצד היישום.
Martin Kleppmann העלה את התחזית הזו לאחרונה, ואני חושב שהוא צודק לחלוטין. "בודק ההוכחות" הופך לשומר הסף. אין הוכחה, אין פריסה. זה ההפך ממודל CrowdStrike, שבו המאמת בעצם החתים בחותמת גומי עדכונים על סמך ההנחות של עצמו.
מה אם המערכת הייתה יכולה לרפא את עצמה?
יש פרט על 19 ביולי שרודף אותי. הקריסה קרתה בכל העולם, בכל 8.5 מיליון נקודות הקצה, כי לא היה מנגנון אוטומטי לזהות את דפוס הכשל ולעצור את הפריסה בזמן אמת.
תחשבו על זה. מיליוני מכונות התחילו לקרוס בו-זמנית. אותות הטלמטריה היו שם — קריאות זיכרון מחוץ לתחום, קריסות ליבה (kernel panics) מיידיות, לולאות אתחול. אבל שום מערכת לא ניטרה את האותות האלה באופן שיכול היה להפעיל מתג ניתוק אוטומטי.
זו הבעיה שטלמטריה מונעת-AI נבנתה כדי לפתור. ניטור מסורתי פועל על כללים סטטיים: "התרע אם ניצול המעבד עולה על 90%". זה כמו להתקין גלאי עשן שמופעל רק כשהבית כבר אחוז להבות. מה שאתה צריך הוא מערכת שמבינה איך נראה "נורמלי" ברמה גרנולרית ויכולה לזהות את המיקרו-שניות הראשונות של סטייה.
בנינו את מה שקהילת המחקר מכנה AI-Driven Telemetry Analytics, או מסגרות AITA. אלה משתמשות בלמידת מכונה לא-מפוקחת — יערות בידוד (isolation forests), מקודדים אוטומטיים (autoencoders), אשכול מבוסס-צפיפות — כדי לבסס קווי בסיס התנהגותיים לרכיבי המערכת. התוצאות מהמחקר האחרון מרשימות: 35% הפחתה בזמן הממוצע לזיהוי חריגות, 40% הפחתה בהתרעות שווא, ודיוק זיהוי חריגות המגיע ל97.5% דיוק (precision) עם 96.2% היזכרות (recall).
בתרחיש CrowdStrike, מערכת עם AITA הייתה מזהה את הקריאה מחוץ לתחום כסטייה מהתנהגות הבסיס תוך המילישניות הראשונות של החלת העדכון. היא הייתה יכולה להפעיל מתג ניתוק מקומי — לבודד את הדרייבר הפגום, לחזור לתצורה התקינה האחרונה הידועה — לפני שהקריסה התפשטה. לא אחרי ש-8.5 מיליון מכונות קרסו. לפני שהמכונה השנייה קרסה.
אנחנו לא מדברים על מדע בדיוני. אנחנו מדברים על מערכות שכבר קיימות במחקר ועוברות לסביבת ייצור. השאלה אינה אם ארגונים יאמצו ארכיטקטורות שמרפאות את עצמן. השאלה היא אם יאמצו אותן לפני או אחרי המפולת הגלובלית הבאה.
איך בעצם בונים לעבר העתיד הזה?
אנשים תמיד שואלים אותי גרסה כלשהי של: "בסדר, השתכנעתי שזה חשוב. אבל החברה שלי לא יכולה לבנות הכול מחדש מאפס. איפה מתחילים?"
שאלה הוגנת. הנה לאן הגיעה המחשבה שלי אחרי שנה של התמודדות עם זה.
ראשית, בצעו ביקורת על מה שרץ בליבה שלכם. לרוב הארגונים אין מושג כמה סוכנים של צד-שלישי פועלים ב-Ring 0 — רמת ההרשאה העמוקה ביותר. כל אחד מהסוכנים האלה הוא סיכון פוטנציאלי בסגנון CrowdStrike. דרשו שכל ספק הפועל ברמת הליבה יספק הוכחות לנהלי פריסה מדורגת, ניהול גרסאות סכמה בין המאמתים בענן שלו לבין המפרשים בנקודות הקצה, ובדיקות סימולציה של לולאות אתחול. אם אינם יכולים לספק זאת, זו התשובה שלכם לגבי הקפדנות ההנדסית שלהם.
שנית, הפסיקו להתייחס ל-AI כשכבת ממשק משתמש. אם "אסטרטגיית ה-AI" שלכם היא אוסף של כלי עטיפת LLM שכולם תלויים באותם שניים או שלושה ספקי מודלים, יש לכם סיכון ריכוזיות שמשקף את בעיית התלות של CrowdStrike. התחילו לבנות או לרכוש מודלים מתמחים שרצים על התשתית שלכם עבור זרימות העבודה הקריטיות ביותר שלכם. זו המשמעות של ריבונות AI בפועל — לא אידאולוגיה, אלא חוסן תפעולי.
שלישית, הפכו את האימות הפורמלי לדרישת רכש, לא לשאיפה מחקרית. הכלים קיימים כבר עכשיו. VeCoGen ומסגרות דומות מאפשרות לייצר קוד מאומת בקנה מידה גדול. עבור כל רכיב קריטי-לבטיחות — כל דבר שנוגע בליבה, מעבד עסקאות פיננסיות, או מקבל החלטות רפואיות — דרשו הוכחה מתמטית לנכונות, ולא רק אחוזי כיסוי בדיקות.
התווכחתי עם לקוח פוטנציאלי על הנקודה האחרונה הזו. הוא אמר, "אתה מבקש מאיתנו להאט את צינור הפריסה שלנו". אמרתי, "צינור הפריסה של CrowdStrike היה מהיר מאוד. הוא דחף עדכון פגום ל-8.5 מיליון מכונות תוך דקות. המהירות לא הייתה הבעיה. מהירות ללא אימות הייתה הבעיה."
הוא חתם על החוזה.
התקדים שמשנה הכול
הנה מה שלדעתי רוב האנשים בתעשיית הטכנולוגיה מפספסים לגבי תיק Delta נגד CrowdStrike.
פסיקת הרשלנות החמורה אינה עוסקת רק בחברת תעופה אחת ובספק אבטחה אחד. היא מבססת סטנדרט של זהירות חדש עבור עדכוני תוכנה אוטומטיים. כששופט אומר שדחיפת קוד לא-בדוק למיליוני מכונות ללא פריסה מדורגת עשויה להוות רשלנות חמורה, זה חל על כל ספק שעושה את אותו הדבר. כששופט אומר שעקיפת העדפות העדכון של לקוח כדי לדחוף קוד ברמת הליבה עשויה להוות הסגת גבול מחשב באופן בלתי תלוי בחוזה, זה כותב מחדש את הכללים עבור כל חברת SaaS עם מנגנוני עדכון אוטומטי.
ה"רשלנות החמורה" של היום תהפוך לציפיית הבסיס של המחר. פריסות מדורגות, אימות פורמלי, בדיקת גבולות בזמן ריצה, טלמטריה שמרפאת את עצמה — אלה כבר אינם יתרונות תחרותיים. הם הסטנדרט המינימלי שבתי משפט ורגולטורים ידרשו.
והנה הדבר שמרגש אותי, גם כשהוא מפחיד אותי: תעשיית ה-AI עומדת להתמודד עם אותו יום דין. כרגע, רוב מערכות ה-AI פועלות באופן הסתברותי — הן "לרוב צודקות", וכשהן טועות, אנחנו מושכים בכתפיים וקוראים לזה הזיה. אבל ככל ש-AI חודר עמוק יותר לתשתית קריטית — ניהול רשתות חשמל, אישור טיפולים רפואיים, ביצוע עסקאות פיננסיות — "לרוב צודק" יישא את אותו משקל משפטי כמו "לא בדקנו את העדכון לפני שדחפנו אותו ל-8.5 מיליון מכונות".
העלות של $10 מיליארד של תקלת CrowdStrike אינה המחיר של באג. היא המקדמה על שדרוג גלובלי לאופן שבו אנו בונים ומאמתים תוכנה.
החברות שמבינות זאת — שמשקיעות ב-Deep AI, באימות פורמלי, ובארכיטקטורות ריבוניות עכשיו — לא רק ימנעו את האסון הבא. הן יגדירו את הסטנדרט שכל השאר ייאבקו לעמוד בו אחרי שזה יקרה.
אני יודע באיזה צד של המפריד הזה אני רוצה להיות. השאלה היא אם תבחרו לפני ה-19 ביולי הבא, או אחרי.
