תחקיר אחרי תקלה עם Claude ו-GPT-6: מהכאוס בסלאק לציר זמן, סיבות שורש ומשימות שנסגרות

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

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

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

לפני שפותחים צ’אט: איסוף, ניקוי ותיוג של החומרים

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

1. אספו את כל המקורות למקום אחד. בדרך כלל אלה:

• ייצוא של ערוץ האירוע בסלאק או ב-Teams, כולל שעות. אפשר להעתיק ידנית אם אין הרשאות ייצוא, העיקר שחותמות הזמן יישמרו.
• שרשורי מיילים רלוונטיים, עם תאריך ושעה לכל הודעה.
• תמלולים של שיחות. Zoom, Teams ו-Google Meet יודעים להפיק תמלול אם האפשרות מופעלת בחשבון. אם יש לכם רק הקלטה, תמללו אותה קודם.
• לוגים, גרפים מניטור וצילומי מסך של התראות.
• פניות לקוחות לשירות, אם היו.

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

=== מקור S1: ערוץ #incident-payments בסלאק, שעון ישראל ===
=== מקור M1: שרשור מיילים מול ספק הסליקה, שעון UTC ===
=== מקור T1: תמלול שיחת זום 14:30, תמלול אוטומטי, עלולות להיות בו טעויות ===

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

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

4. נקו מידע רגיש. הסירו מספרי כרטיסי אשראי, סיסמאות, טוקנים, תעודות זהות ופרטי לקוחות. השתמשו בחשבון ארגוני (Claude for Work, ChatGPT Business או Enterprise וכדומה) שמדיניות הנתונים שלו אושרה אצלכם, ולא בחשבון פרטי. אם אתם לא בטוחים מה המדיניות, שאלו את מי שאחראי על אבטחת מידע לפני שאתם מעלים משהו.

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

שלב 1: ציר זמן שכל שורה בו נשענת על מקור

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

פרומפט לבניית ציר זמן:

אתה עוזר לי לבנות ציר זמן לתחקיר אירוע. מצורפים מקורות מתויגים (S1, M1, T1 וכו’).

כללים:

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

פורמט: טבלה עם העמודות שעה | סוג | מה קרה | מקור | רמת ודאות (גבוהה/בינונית/נמוכה).

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

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

ההפרדה בין “מה קרה”, “מה ידעו” ו“מה עשו” היא הלב של תחקיר טוב. המערכת התחילה להחזיר שגיאות ב-13:05. ההתראה הראשונה הגיעה ב-13:22. מישהו התחיל לטפל ב-13:40. שלושת המספרים האלה מספרים שלושה סיפורים שונים: על זמן הגילוי, על זמן התגובה ועל זמן התיקון. כשהכול מעורבב בטבלה אחת בלי סיווג, הפערים האלה נבלעים.

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

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

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

פרומפט אימות (בשיחה חדשה, עם אותם מקורות):

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

אם יש לכם גישה לשני הכלים, גם Claude וגם ChatGPT, שווה לבנות את הטבלה באחד ולאמת בשני. מודלים שונים טועים בדרכים שונות, וההצלבה תופסת יותר. Gemini יכול לשמש כבודק שלישי, במיוחד אם החומרים שלכם כבר יושבים ב-Google Drive.

שלב 2: ניתוח סיבות שורש בלי להאשים אנשים

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

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

פרומפט לניתוח סיבות שורש:

על בסיס ציר הזמן המאומת המצורף, בצע ניתוח סיבות שורש לפי הכללים הבאים:

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

פורמט: לכל גורם כתוב כותרת קצרה, הסבר של 2-3 משפטים, סיווג (טכני / תהליך / תקשורת / ניטור / ידע), ורמת ביסוס.

למה שלוש שאלות נפרדות? כי רוב התחקירים עונים רק על הראשונה. “השרת נפל בגלל תעודת SSL שפגה” היא תשובה נכונה וחלקית. החלק המעניין הוא למה אף אחד לא קיבל התראה 30 יום מראש, ולמה לקח שעה וחצי להבין שזו התעודה. לרוב שם נמצאים התיקונים הזולים והאפקטיביים.

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

אחרי הניתוח, העבירו את הטיוטה דרך “מסנן האשמה”:

פרומפט לניקוי שפה מאשימה:

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

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

שלב 3: רשימת משימות שמישהו באמת סוגר

זה החלק שבו רוב התחקירים מתים. מסמך מרשים עם 23 “המלצות”, שאף אחת מהן לא בוצעה שלושה חודשים אחרי, כשאותה תקלה חוזרת.

בעיות נפוצות ברשימות משימות של תחקירים:

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

פרומפט להפקת משימות:

על בסיס ניתוח סיבות השורש המצורף, הצע משימות פעולה לפי הכללים הבאים:

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

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

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

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

פרומפט לבדיקת מעקב:

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

שלב 4: כתיבת מסמך התחקיר הסופי

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

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

פרומפט לכתיבת המסמך:

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

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

אם אתם עושים תחקירים באופן קבוע, שמרו את ההנחיות והתבנית במקום אחד: ב-Projects של Claude, בפרויקט או ב-GPT מותאם ב-ChatGPT, או ב-Gem ב-Gemini. כך כל תחקיר מתחיל מאותה נקודה, והאיכות לא תלויה בזיכרון של מי שכותב. עוד רעיונות לבניית תבניות כאלה תמצאו במדריכים שלנו.

טעויות נפוצות

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

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

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

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

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

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

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

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

לחכות יותר מדי. אחרי שבועיים אנשים כבר לא זוכרים למה עשו מה שעשו. השתדלו להריץ את שלב ציר הזמן תוך יומיים-שלושה מסיום האירוע.

סיכום וצ’קליסט התחלה

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

צ’קליסט לתחקיר הבא שלכם:

• אספתי את כל המקורות: צ’אט, מיילים, תמלולים, לוגים ופניות לקוחות
• תייגתי כל מקור במזהה (S1, M1, T1…) ובאזור הזמן שלו
• הסרתי סיסמאות, טוקנים ופרטים אישיים, ואני עובד בחשבון שמאושר בארגון
• החלפתי שמות בתפקידים לשלב הניתוח
• בניתי ציר זמן עם ציטוט חובה והפרדה בין מה קרה, מה ידעו ומה עשו
• אימתתי את ציר הזמן בשיחה חדשה, ועדיף במודל אחר
• הכנתי רשימת פערים ושאלות לאנשים שהיו שם
• ניתחתי שלוש שאלות: למה קרה, למה לא גילינו מוקדם, למה התיקון לקח זמן
• העברתי את הטקסט דרך מסנן השפה המאשימה
• יש לי לכל היותר 7 משימות, כל אחת עם סיווג וקריטריון סגירה
• בעלים ותאריכי יעד נקבעו בפגישה, מול האנשים
• המשימות הועברו לכלי ניהול המשימות של הצוות
• קבעתי ביומן בדיקת מעקב בעוד 30 יום
• שמרתי את הפרומפטים והתבנית בפרויקט קבוע לתחקיר הבא

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