Zapier או Make נכשלו בשקט: איך מזהים הזמנה שלא עברה בלי לחכות ללקוח

כישלון שקט הוא ריצה שהסתיימה בלי סטטוס שגיאה ובלי שהפעולה בוצעה. ב-Zapier זה נראה כמו סטטוס Filtered או Safely halted; ב-Make זה מטפל שגיאות שהוגדר כ-Ignore או Resume. שתי הפלטפורמות מתייחסות לזה כאל התנהגות תקינה, ולכן לא נשלחת שום התראה.

מה בעצם קורה כשריצה "נכשלת בשקט"

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

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

למה הפלטפורמה לא שולחת התראה?

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

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

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

איך מגלים שהזמנה לא הגיעה, אם שום דבר לא נכשל?

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

1. הגדירו מה נספר במקור. מספר ההזמנות שנוצרו בחנות בחלון של שעה, למשל.
2. הגדירו מה נספר ביעד. מספר הרשומות שנוצרו במערכת שאליה האוטומציה כותבת, באותו חלון בדיוק.
3. הריצו את ההשוואה בתהליך נפרד לגמרי - לא בתוך אותו תרחיש שאתם בודקים. תרחיש אינו יכול לדווח על כך שהוא עצמו לא רץ.
4. התריעו על פער, ולא על שגיאה. פער של אחד הוא לרוב תזמון; פער עקבי הוא כשל.
5. שמרו את מזהי המקור שלא נמצאו ביעד. רשימת מזהים היא מה שמאפשר להשלים ידנית; מספר לבדו אינו מספיק.

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

מה לתעד בכל ריצה

• מזהה ייחודי של הרשומה שעובדה, ולא רק חותמת זמן.
• לאיזה ענף התרחיש הלך, כשיש יותר מאחד.
• תוצאה של כל שלב חיפוש: נמצא או לא נמצא. זה השדה שהופך safely halted ממסתורי למובן.
• מה החזירה מערכת היעד, כולל המזהה שנוצר בה.
• כמה זמן לקחה הריצה. עלייה חדה בזמן הריצה מקדימה לרוב כישלון בפועל, ולכן היא מדד שכדאי לשמור לאורך זמן ולא רק להסתכל עליו בזמן תקלה.

תיעוד כזה שווה יותר מכל התראה, כי הוא מאפשר לענות על השאלה "מה קרה להזמנה 4417" במקום על השאלה "האם היו שגיאות".

התראה שאנשים לא ישתיקו

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

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

איפה מתחילים כשאין שום ניטור

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

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

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

קשור: Zapier מול Make, n8n מול Make מול Zapier, מה זה webhook.

מקורות

• Zapier - Review run statuses in Zap workflows
• Zapier - Replay Zap runs
• Make - Error handling