מכסחת הבאגים: איך לבנות אוטומציה שלא נופלת - בדיקות, Error Handlers, ולוג לשחזור
הבנייה היא 20% מהזמן ועובדת ב-80% מהמקרים - כל השאר הוא בדיקות, טיפול בשגיאות ותחזוקה. עינת לבי-כהן, מכסחת הבאגים, לימדה בדיוק את ה-80% הזה: מאיפה באמת נולדים באגים (לחץ זמן, הנחות שגויות על פורמט תאריך, מערכות צד ג' שמשתנות), איך בודקים מקצה-לקצה לפני מסירה, איך עוטפים מודולים ב-Error Handlers שהסנריו לא ייפול, ואיך בונים לוג שמריץ מחדש כל מה שנכשל בלחיצת כפתור. 7 הפרומפטים למטה הופכים אתכם מבנאים שמפחדים ממסירה לבנאים ששולטים בפרודקשן.
הערת הכתבת: הסשן הזה (3.12.2024) הוא Make ספציפי, אבל אל תתנו לזה לבלבל - זה אחד הסשנים הכי חשובים בסדרה, והוא לא מזדקן. מה שעינת לימדה - לבדוק לפני שמוסרים, לטפל בשגיאות מראש, לתעד כדי לשחזר, ולתת ללקוח שקיפות - זו דיסציפלינת production אמיתית, והיא נכונה בכל כלי ובכל שפת קוד. והכלל פשוט: בנייה זה לא גמור, טסט זה לא גמור - בודקים לפני שמוסרים. גם היום, כשבונים עם קוד וסוכני AI, אותם עקרונות בדיוק מפרידים בין משהו שעובד בהדגמה למשהו ששורד בפרודקשן. הפרומפט הפתוח למטה בונה לכם צ'קליסט בדיקות מקצה-לקצה לאוטומציה אמיתית לפני מסירה.
כל אחד יודע לבנות אוטומציה שעובדת פעם אחת בהדגמה. מה שמפריד בין חובבן למקצוען הוא מה שקורה כשמשהו נשבר - וב-production, משהו תמיד נשבר. עינת לבי-כהן הגיעה למפגש ה-25 של אוטוטיוזדיי עם הכובע של "מכסחת הבאגים", ולימדה את הדיסציפלינה שרוב אנשי האוטומציה מדלגים עליה: לבדוק לפני שמוסרים, לטפל בשגיאות מראש, ולתעד כדי לשחזר. זה בדיוק ה-standard שנתנאל מדבר עליו - בנייה זה לא גמור, טסט זה חלק מהמקצוע.
המסע: 7 תחנות
כל תחנה = מה קרה בסשן + הפרומפט שאורז את זה בשבילכם
מפת המקורות לבאגים בעסק שלי
עינת פתחה ממה שכולם חווים ואף אחד לא ממפה: מאיפה נולדים באגים. היא פרשה את המקורות עם דוגמאות שכואבות בדיוק כי הן אמיתיות. לחץ זמן ('תעלה מהר, צריך למחר') שגורם לדילוג על בדיקות - פיצול סנריו לארבעה ושכחת תנאי, ופתאום נשלחו מיילים על חשבוניות ישנות ללקוחות. לחץ כסף - צמצום ההצעה עד שלא נשאר זמן לבדיקות (וכאן התובנה: הבנייה היא 20% מהזמן, השאר בדיקות ותחזוקה). הנחות שגויות - פורמט תאריך ישראלי מול אמריקאי, מע"מ קבוע בקוד שמייצר חשבוניות שגויות, טופס בלי קידומת 972 ללקוח בחו"ל. וגם: ריבוי שינויים קטנים 'בלי לבדוק', ומערכות צד ג' שמשתנות מעצמן (פייסבוק משנה אותנטיקציה). עינת לימדה שבאג הוא כמעט אף פעם לא מזל רע - הוא מקור מוכר שאפשר לצפות מראש.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
אבחון: איפה אני חשוף לבאג שיוצא החוצה ללקוח
ואז עינת נתנה 'מודל הבלם' לבחירת מה לבדוק - כי אי אפשר לבדוק הכל, אז בודקים קודם את מה שהכי מסוכן. היא סיווגה כל נקודה לשלוש קטגוריות: בסיס ופונקציונליות (תהליכי הליבה והלוגיקה, כולל תאימויות - טופס שנסגר באייפון אבל לא באנדרואיד), 'להיות הלקוח' (וזה הקריטי - כל מה שיוצא החוצה: כסף, חיובים, מיילים והודעות ללקוחות הקצה, כי אלה הטעויות שאי אפשר לבטל, והצד הפנים-ארגוני - דוחות שמקבלים על בסיסם החלטות), ומקרי קצה (מה שלא צופים, אבל ברגע שקורה נכנס למעגל תיעוד). ועינת בנתה מזה טבלת סיכון - לכל נקודה: מה הנזק אם זה נשבר, כמה זה סביר, ומה דחיפות התיקון. התובנה: מתעדפים בדיקות לפי נזק - וכל מה שנוגע בכסף, בתקשורת יוצאת, ובדוחות להחלטות, נבדק ראשון.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
צ'קליסט בדיקות מקצה-לקצה מבוסס אפיון
עינת עברה לפרקטיקה: תהליך בדיקות שיטתי בשני שלבים. שלב א' - בדיקות מיקרו תוך כדי פיתוח: בודקים כל רכיב בנפרד (כל סנריו, כל אינטגרציה), לא מחכים לבדוק הכל יחד בסוף. שלב ב' - בדיקות מקצה-לקצה: משכפלים את מסמך האפיון לגרסת בדיקות ועוברים מסלול-מסלול. ועינת נתנה את הזהב המעשי - מה לבדוק בכל נקודה: קלט (להזין במכוון תווים מיוחדים, שמות עם גרשיים וסוגריים, עברית וערבית מעורבות, פורמטים שונים של טלפון), חישוב (אם יש תנאי עם כמה מצבים - לבדוק את כולם, כי היה מקרה של 9 מצבים ש-8 עבדו והתשיעי לא), ופלט (לא 'נכתב משהו' אלא להיכנס ולוודא שמה שהיה אמור להיכתב באמת נכתב). ובדיקות מיוחדות - תאריכים, מע"מ, שמות קבצים בעברית, עומסים מול API limit. והטיפ הכי חד: בדיקה על ידי מי שלא פיתח - או אם זה אתה, אחרי הפסקה ושינוי state of mind.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
דפוסי עבודה מובנים ב-Make לצמצום באגים
פה עינת עברה ממניעה בדיעבד למניעה מראש: לבנות נקי מלכתחילה. שלושה דפוסים. עבודה מודולרית - כל פעולה כיחידה עם שמות משמעותיים, notes, וסטנדרטים אחידים (שקל לתחזק ולהביא אנשים). Set/Get variables כדי לא לשכפל לוגיקה - וכאן עינת לימדה נקודה שתופסת אנשים: ב-Make ה-scope לוקאלי לכל ענף ראוטר, אז כשמפצלים בתנאי (מצאתי subscriber קיים מול יצרתי חדש), בכל ענף עושים Set לאותו שם משתנה, ואחרי האיחוד עושים Get פעם אחת ומפעילים את הלוגיקה המשותפת פעם אחת - במקום לשכפל אותה בכל ענף. ו-Set הוא גם כלי דיבאג מצוין (שותלים ראוטר עם Set כדי לראות נוסחאות בעיניים לפני שדוחפים אותן). ומודול Create JSON לפני קריאות HTTP - במקום JSON ידני שנשבר על גרשיים וסלאשים, Create JSON מטפל אוטומטית באסקייפינג. נקי מראש = פחות באגים אחר כך.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
Error Handlers: שהסנאריו לא ייפול לעולם
וכאן עינת נכנסה ללב: Error Handlers, שהסנריו לא ייפול גם כשמודול נכשל. Break - מנסה שוב אחרי X זמן ומספר ניסיונות, מתאים לתקלות שרת ו-Rate Limit, ועינת נתנה אזהרה מבריקה: בריצה כמותית אל תיתן לכולם אותו interval, כי כולם יחזרו יחד ויתקעו שוב - מוסיפים רכיב רנדומלי, ועדיף גדילה מעריכית (1 ל-2 ל-4). Resume - כשמודול נכשל (מודול טלפון שנופל על קלט לא תקין), מזריקים ערך חלופי וממשיכים קדימה, ואז בודקים ב-IF ומחליטים - התראה ללקוח, לוג, או כלום - בלי להפיל את הסנריו. Router על Error Handler - הכי עוצמתי: לפי סוג השגיאה פעולות שונות. ועינת הוסיפה תובנה בוגרת: לא תמיד רוצים שהסנריו לא ייפול - אם אין דרך 'להחזיר מים לצינור' (הרשמה לוובינר עם תאריך שגוי), עדיף שייפול עד שמתקנים, כדי שלידים לא יירשמו לוובינר הלא נכון. לדעת מתי לתפוס שגיאה ומתי לתת לה להפיל - זו בגרות הנדסית.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
בניית לוג לשחזור ריצות בלחיצת כפתור
עינת נתנה כלי שמפריד בין 'תקלה = אסון' ל'תקלה = לחיצת כפתור': לוג שמריץ מחדש ריצות שנכשלו. שני סנריוס. הראשון - האוטומציה עם לוג מובנה: בתחילת הריצה כותבים שורת לוג (Sheets/Airtable) עם datetime, status שמוגדר מראש כ-'error' (מניחים כשל עד שמוכח אחרת!), Execution URL, ה-JSON המלא שהגיע, ושם הסנריו; לאורך הפלואו מעדכנים error_type בכל מודול קריטי; ורק בסוף, כשהכל הצליח, מעדכנים ל-'success'. השני - מנוע הרצה חוזרת: שולף מהלוג את כל השורות עם error, עושה קריאת HTTP חוזרת ל-Webhook המקורי עם ה-JSON השמור, ומסמן 'נשלח לריצה חוזרת' (כדי לא להיכנס ללופ). ועינת נתנה טיפ ביצועים קריטי: לשים את ה-Sheet של הלוג על חשבון נפרד - כי Rate Limit נספר פר-חשבון, וכך הלוגים לא יפילו את שאר האוטומציות. במקום לתקן 200 ריצות ידנית - מתקנים את הבאג, לוחצים כפתור, והכל רץ מחדש.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
רידנדנסי: חיווי הצלחה שקוף ללקוח הקצה
ואת הסשן עינת סגרה במשהו שרוב האנשים לא חושבים עליו - חיווי הצלחה שקוף ללקוח: רידנדנסי, או Observability בשפת התוכנה. הבעיה - משתמש ממלא טופס שמטריג שלושה תהליכים נפרדים (חשבונית, רישום, וואטסאפ), ורואה רק 'תודה על השליחה' בלי מושג מה קרה בפועל. עינת בנתה את הדפוס: בכל ענף שמבצע פעולה קריטית שותלים Set variable שמחזיר true אם הפעולה הצליחה לפי הקריטריון הנכון שלה (חשבונית - קוד 200 ולינק, וואטסאפ - נמסר), ובסוף מרכזים הכל להודעת סיכום עם סימני וי ואיקס לכל תהליך שנשלחת ללקוח. ועינת הוסיפה עיקרון זהב לתחזוקה: בכל מקום שכותבים בו מידע, לכתוב גם את ה-Execution URL של הריצה שיצרה את הרשומה - 'משיכת החוט' אחורה - כדי שכשמתקנים באג יודעים מיד מאיזו ריצה זה הגיע, וחוסכים שעות של reverse engineering. שקיפות היא לא רק כלפי הלקוח - היא מתנה לעצמך העתידי.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
🎯 מה עושים עם זה עכשיו?
קראת איך זה נעשה. עכשיו קחו את הכלים ותעשו את זה בעצמכם - כל הפרומפטים של הסשן, מוכנים להריץ על העסק שלכם. פלוס ההקלטה המלאה והתמלול.
הצטרפו לאוטוטיוזדיי+· 49 ש״ח בחודשעוד לא בשלים? בואו ללייב הבא בחינם ←רוצים לעבוד על התמלול הנקי?
העתיקו אותו ותעבדו איתו איך שנוח לכם.
🔒 התמלול המלא שמור לחברי אוטוטיוזדיי+. עם המנוי אתם מעתיקים אותו בקליק ועובדים איתו איך שנוח לכם.
לפתוח את התמלול · 49 ש״ח בחודששאלות ששאלתם (וה-AI ישאל גם)
מאיפה נולדים באגים באוטומציות?
בעיקר מלחץ זמן (דילוג על בדיקות), לחץ כסף, הנחות שגויות (פורמט תאריך, מע"מ קבוע בקוד), ריבוי שינויים קטנים 'בלי לבדוק', ומערכות צד ג' שמשתנות מעצמן. הבנייה היא 20% מהזמן - השאר בדיקות ותחזוקה.
מה בודקים קודם?
לפי נזק: כל מה שיוצא החוצה ללקוחות הקצה (כסף, חיובים, מיילים, הודעות) - כי אלה טעויות שאי אפשר לבטל. אחר כך דוחות שמשמשים לקבלת החלטות, ואז מקרי קצה. מתעדפים בדיקות לפי הסיכון.
מה ההבדל בין Break ל-Resume ב-Make?
Break מנסה שוב אחרי כשל (טוב לתקלות שרת ו-Rate Limit - עם interval רנדומלי כדי שכולם לא יחזרו יחד). Resume מזריק ערך חלופי וממשיך קדימה בלי להפיל את הסנריו, ואז מחליטים מה לעשות עם הכשל.
איך מריצים מחדש ריצות שנכשלו?
בונים לוג: כל ריצה נכתבת עם status=error בהתחלה (מניחים כשל), ומתעדכן ל-success רק בסוף. סנריו נפרד שולף את כל השורות עם error ומריץ אותן מחדש דרך ה-Webhook - במקום לתקן ידנית אחת-אחת.
💬 הדיון על הסשן
שאלות, תובנות, מה יישמנו - השרשור של הקהילה.
עוד אין תגובות - תהיו הראשונים לפתוח את הדיון 👇