אם ה-AI מקבל את ההחלטה ב-3 לפנות בוקר, מי מפוטר ב-9?
עודכן: לפני 7 ימים
מאת: אבי שליסמן | מייסד ומנכ"ל MoovingON
15.10.2026
תקציר
ה-AI נכנס במהירות לניהול ותפעול סביבות פרודקשן, אבל ככל שהוא מקבל יותר החלטות בזמן אמת, עולה שאלה מהותית: מי אחראי כשההחלטה שלו שגויה?
ה-AI מצטיין במשימות רוטיניות כמו סינון וקיבוץ התראות, זיהוי שינויים אחרונים, בניית ציר זמן והרצת Runbooks לתקלות מוכרות. בכך הוא מפחית עומס ומונע הקפצות מיותרות של מהנדסים בשעות הלילה.
אבל באירועים מורכבים, שבהם המידע חלקי והסיכון העסקי גבוה, נדרש שיקול דעת אנושי. ה-AI יכול להמליץ על דרך פעולה, אך אינו יכול לשאת באחריות להחלטות קריטיות.
כאן טמון גם סיכון נוסף: ככל שה-AI מטפל במקרים הפשוטים, לצוות האנושי נשארים רק האירועים המורכבים והחריגים. לכן קיצוץ בצוותי On-call עלול דווקא להחליש את היכולת להתמודד עם המצבים הקריטיים ביותר.
הפתרון הוא להגדיר מראש נקודת מסירה ברורה בין ה-AI לאדם: מתי האוטומציה נעצרת, למי מועבר הטיפול, ואיזה מידע הוא מקבל.
האוטומציה היא החלק הקל. האתגר הניהולי האמיתי הוא להחליט איפה היא נעצרת ומי לוקח אחריות משם.
רקע
כולם מסכימים שה-AI ישנה מן הקצה אל הקצה את האופן שבו אנחנו מנהלים ומתפעלים סביבות פרודקשן. אבל לגבי השאלה החשובה באמת יש הרבה פחות הסכמה: כשה-AI מקבל החלטה במהלך אירוע תפעולי, והיא מתבררת כשגויה – של מי הייתה ההחלטה בעצם?
רוב הצוותים עדיין לא ענו על השאלה הזו. הם משלבים AI בשרשרת התפעול כלי אחר כלי, קודם לסינון התראות, אחר כך לתיקון אוטומטי (Auto-remediation). כל צעד כזה נראה הגיוני לחלוטין בפני עצמו. אבל יחד נוצרת מערכת שבה החלטות קריטיות מתקבלות באמצע הלילה, בלי שאף אחד יודע בוודאות מי אחראי עליהן.
עדיף להסדיר את זה עכשיו, ולא לחכות ל-Post-mortem שאחרי האירוע.
במה ה-AI באמת מצוין?
ה-AI מצטיין בחלקים הסיזיפיים והרוטיניים של ניהול אירוע. הוא יודע לקבץ (Correlate) התראות שמקורן באותה בעיה, לזהות במהירות מה היה ה-Commit או השינוי האחרון שבוצע, ולהרכיב ציר זמן (Timeline) בזמן אמת. כשהוא נתקל בבעיה מוכרת שכבר ראה מאה פעמים, הוא יכול להריץ את ה-Runbook ולבצע את התיקון מהר יותר ממה שאדם מסוגל אפילו להקליד.
וזה בדיוק רוב העומס בלילה טיפוסי: מבול של התראות שרובן רעש, כפילויות או תקלות מוכרות עם פתרון ידוע מראש.
כשמעבירים את העבודה הזו ל-AI, המהנדסים שלכם מפסיקים להתעורר באמצע הלילה בגלל זוטות שמכונה יכולה לפתור בתוך שניות. זה מצוין, וככל שהטכנולוגיה משתפרת, הגיוני להעביר אליה אפילו יותר מהעבודה הזו.
איפה הוא חייב לעצור?
אבל יש רגעים במהלך אירוע שדורשים משהו אחר לגמרי: שיקול דעת אנושי וניהול סיכונים.
האם לבצע Failover לאזור (Region) אחר כשיש סיכון ממשי לאובדן מידע (Data loss)? האם להעיר את ה-CTO ב-3:00 לפנות בוקר?
בשני המקרים המידע חלקי, הלחץ בשיאו, והמחיר של טעות נופל ישירות על העסק.
ה-AI יכול להמליץ על דרך פעולה, אבל הוא לא יכול לשאת באחריות. אם המעבר בין האזורים יסתבך, הלקוח שלכם – וגם הדירקטוריון – לא יסתפקו בהסבר ש"המודל החליט".
בסביבות שפועלות תחת רגולציה, דרישות תאימות (Compliance) או SLA מחמיר, נדרש גם תיעוד ברור של מי קיבל את ההחלטה ומתי. המשפט "ה-AI ביצע את זה אוטומטית" לא יספק שום מבקר.
החלטה מהירה יותר היא עדיין החלטה – ומישהו חייב להיות אחראי עליה.
הסיכון השקט
גם בני אדם מקבלים החלטות שגויות, ולכן טעות של AI היא לא בהכרח הסיכון הגדול ביותר. הסכנה האמיתית שקטה ומורכבת יותר, והיא מתפתחת מתחת לרדאר.
כשמערכת ה-AI מטפלת בכל המקרים הפשוטים והרוטיניים, לצוות האנושי נשארות רק הבעיות המורכבות והחריגות – אותם מקרים אפורים שבהם ה-Runbooks כבר לא נותנים תשובה.
על הנייר, זה עשוי להיראות כמו הזדמנות לקצץ בתקנים. בפועל, האנשים שנשארים חייבים להיות דווקא המנוסים והבכירים ביותר – והם צריכים להיות בשיא הריכוז בדיוק כשהמקרה המורכב הזה מגיע.
אם כל הקפצה לילית הופכת לאירוע מורכב ושוחק, המהנדסים הבכירים יהיו הראשונים להישחק – ולעיתים גם הראשונים לעזוב.
ארגונים מסוימים מסתכלים על נתוני האוטומציה וממהרים לצמצם את צוותי ה-On-call. בפועל, הם הפכו לאוטומטי את החלק הקל של העבודה, ובמקביל דיללו את קו ההגנה שאמור להתמודד עם החלק הקשה.
ארגונים שעושים את זה נכון לא בהכרח מקצצים בכוח האדם. הם משנים את אופי התפקיד של צוותי הלילה ושומרים על מעטפת אנושית חזקה למקרים שבהם האוטומציה מגיעה לקצה גבול היכולת שלה.
הגדירו מראש את נקודת המסירה (Handoff)
לכל תהליך שאתם מפקידים בידי ה-AI צריך להגדיר מראש קו ברור שבו המערכת נעצרת ומעבירה את הטיפול לאדם.
למשל: "ה-AI רשאי לבצע Restart לשירות עד פעמיים. אם הבעיה לא נפתרה, עליו להקפיץ כונן אנושי ולהציג לו סיכום של כל הצעדים שכבר בוצעו."
הגדרת הגבול הזה אינה החלטה טכנית קטנה של המהנדס שכותב את הסקריפט. זו החלטה ניהולית לכל דבר – בדומה להגדרת סמכויות חתימה או אישור הוצאות בארגון.
ברגע המסירה (Handoff), המהנדס שמקבל את הקריאה חייב לקבל תמונה מלאה: מה ידוע על מקור הבעיה, אילו צעדים המערכת כבר ניסתה, מה היו התוצאות ולמה היא החליטה לעצור.
כך הוא לא מתחיל מאפס, אלא נכנס לאירוע כשהוא יודע בדיוק מה כבר קרה ואיזו החלטה נדרשת ממנו עכשיו.
ולא פחות חשוב: חייב להיות מישהו בצד השני שיקבל את הטיפול – ב-3:00 לפנות בוקר, בסוף השבוע וגם כשהמהנדס הבכיר נמצא בחופשה.
בשבוע יש 168 שעות. כדי לאייש עמדה מבצעית אחת במתכונת 24/7 נדרשים בפועל כשישה אנשים, ומעליהם מנהל חזק, כשמביאים בחשבון חופשות, ימי מחלה, הכשרות ותחלופה.
בלי הכיסוי האנושי הזה, כל מנגנון ההסלמה עלול פשוט ליפול בין הכיסאות.
4 שאלות שכל מנהל חייב לשאול את הצוות ברבעון הקרוב
אילו שלבים בטיפול באירועים פועלים כיום באופן אוטומטי, ומי הגדיר את הגבול שבו האוטומציה נעצרת?
כשהאוטומציה נתקלת בלילה באירוע שאינה יכולה לפתור, מי בדיוק האדם שמוקפץ ומקבל את הטיפול?
האם נוכל להציג ללקוח או למבקר (Auditor) תיעוד מדויק של מי קיבל כל החלטה באירוע המשמעותי האחרון שלנו?
אם נצמצם את צוותי ה-On-call בעקבות הכנסת AI, מי יישאר לטפל דווקא במקרים שהמודל לא מסוגל לפתור?
בשורה התחתונה: איפה עובר הקו?
לכל תהליך אוטומטי חייבת להיות נקודת עצירה שבה אדם נכנס לתמונה.
ליישם את האוטומציה עצמה זה החלק הקל. לקבוע מראש איפה היא נעצרת, מי מקבל את השליטה ומה הסמכות שלו לעשות – זה האתגר הניהולי האמיתי.
ה-AI מעניק למערכות שלכם סקייל ויכולות שלא היו להן בעבר. אבל בסופו של דבר, האנשים הם אלה שנושאים באחריות לתפעול שלהן.
כשאתם משלבים AI בסביבת הפרודקשן, תמצאו בקלות עשרות משימות שאפשר להפוך לאוטומטיות. אבל השאלה הקריטית באמת היא אחרת:
איפה התהליך האוטומטי נעצר – ומי נמצא שם כדי לקחת ממנו את השליטה?
אם התשובה שלכם למשמרת הלילה היא "מי שבמקרה תורן On-call" – זה בדיוק המקום שבו כדאי להתחיל לעשות סדר.
תגובות