איך מתחזקים אוטומציות - ניטור שגיאות, גיבוי ומה עושים כשזה נשבר
רוב האוטומציות שאנחנו נקראים לתקן לא נשברו בגלל באג. הן נשברו כי משהו סביבן זז - טוקן פג תוקף, ספק שינה גרסת API, מישהו שינה שם של עמודה בגיליון. מה שהופך את זה ליקר הוא לא השבר עצמו, אלא השבועיים שעברו עד שמישהו בעסק שם לב.
אוטומציה טובה נעלמת מהתודעה. זה בדיוק מה שרצינו כשבנינו אותה, וזה גם מה שהופך את היום שבו היא מפסיקה לעבוד לכל כך לא נעים. בעסק שאין בו ניטור, הדרך הרגילה לגלות שהתהליך נפל היא לקוח שמתקשר לשאול איפה החשבונית שלו, או מנהל שמסתכל בסוף החודש על דוח ורואה מספר שלא מסתדר.
המאמר הזה הוא מה שאנחנו עושים בפועל אחרי שאוטומציה עולה לאוויר. לא תיאוריה של אמינות מערכות, אלא הדברים שבאמת מחזיקים תהליך עסקי חי לאורך שנים: איך מגלים שמשהו נשבר, מה בונים כדי שיישבר פחות, מה מגבים, ומה עושים בשעה הראשונה אחרי שזה קרה.
למה אוטומציות נשברות גם כשאף אחד לא נגע בהן
השאלה הראשונה שנשאלת כשתהליך נופל היא מי נגע. ברוב המקרים אף אחד לא נגע, וזו בדיוק הנקודה. אוטומציה איננה קובץ שיושב לבד בפינה, היא שרשרת של תלויות במערכות חיצוניות שממשיכות להשתנות בלי לשאול אתכם.
- שינויי API וגרסאות. ספק מוציא גרסה חדשה, מסמן את הישנה כמיושנת, ואחרי כמה חודשים סוגר אותה. השדה שהתרגלתם אליו משנה שם או מבנה, והתהליך שמצפה לו מקבל ערך ריק.
- פקיעת טוקנים וכישלון של OAuth refresh. חיבור מול Google, מול מערכת CRM או מול ספק סליקה מתחדש ברקע דרך refresh token. ברגע שמישהו שינה סיסמה, הפעיל אימות דו-שלבי, או הסיר את האפליקציה מרשימת ההרשאות - החידוש נכשל והחיבור מת. לפעמים בשקט מוחלט.
- מגבלות קצב. ספקים מגבילים כמה קריאות מותר בדקה או ביום. ביום רגיל אתם רחוקים מהתקרה, אבל ביום מכירות, אחרי דיוור, או אחרי ייבוא של קובץ גדול, פתאום נתקלים בה. חלק מהרשומות עוברות וחלק לא, וזה נראה כמו התנהגות אקראית.
- שינוי שם של עמודה בגיליון או של שדה ב-CRM. מישהו במחלקת המכירות החליט ש׳טלפון׳ יהיה ׳נייד׳, או ששדה סטטוס יקבל ערך חדש. מבחינתו זה סידור קוסמטי, מבחינת האוטומציה זה שדה שנעלם.
- שינוי תמחור או מכסות של הפלטפורמה. מספר הפעולות החודשי נגמר באמצע החודש, או שהתוכנית שהייתם בה כבר לא כוללת רכיב מסוים. התהליך לא שגוי, הוא פשוט מפסיק לרוץ.
- בן אדם בעסק. עובד חדש שינה תבנית מייל, מנהל מחק תיקייה בדרייב כדי לסדר, מישהו הסיר משתמש מהחשבון ואיתו את החיבור שהיה רשום על שמו.
- זמן. אזור זמן ושעון קיץ מזיזים תהליך מתוזמן בשעה, ותהליך שאמור לרוץ בסוף יום עסקים רץ פתאום לפני שהנתונים נכנסו. בישראל זה גם נפגש עם שבוע עבודה שמתחיל ביום ראשון, בעוד לא מעט כלים מניחים ברירת מחדל של שבוע אמריקאי.
אף אחד מהדברים האלה הוא לא תקלה חריגה. זו התנהגות רגילה של סביבה חיה. ההנחה שצריך לעבוד לפיה היא שכל חיבור חיצוני ייפול מתישהו, והשאלה היחידה היא אם תדעו על זה באותו יום או בעוד שלושה שבועות.
כשל רועש מול כשל שקט
כשל רועש הוא הנוח מבין השניים. ההרצה נכשלת, מופיע אדום בלוג, יש הודעת שגיאה עם קוד. אתם יודעים בדיוק מה קרה ואיפה. אם יש ניטור, אתם יודעים גם מתי.
כשל שקט הוא הבעיה האמיתית. ההרצה מסתיימת בהצלחה, הכול ירוק, אבל התוצאה שגויה. ראינו תהליך שיצר חשבוניות בסכום אפס במשך שבוע, כי שדה של מחיר שינה מבנה והמיפוי החזיר ערך ריק שהמערכת קיבלה כאפס לגיטימי. ראינו סינון שמחזיר אפס רשומות כי מישהו שינה ערך סטטוס מ׳שולם׳ ל׳שולם במלואו׳ - התהליך רץ כל יום בהצלחה מוחלטת ולא עשה כלום. ראינו כפילויות לקוחות שנוצרו כי לוגיקת ההשוואה על שמות בעברית לא טיפלה ברווח כפול ובגרש.
הרצה ירוקה היא לא הוכחה שהעסק קיבל את מה שהוא צריך, היא רק הוכחה שהמכונה לא נחנקה.
ההבדל הזה קובע איך בונים ניטור. ניטור שמקשיב רק לשגיאות תופס את הכשל הרועש ומפספס לגמרי את השקט. כדי לתפוס את השקט צריך למדוד תוצאה, לא סטטוס.
ניטור בפועל - ארבעה דברים שמספיקים לרוב העסקים
התראה לערוץ שאדם באמת קורא
התראות למייל נקברות. זו לא אמירה על משמעת אישית, זו פשוט המציאות של תיבה שמקבלת מאה הודעות ביום. אנחנו שולחים התראות תקלה לערוץ ייעודי ב-Slack, ובעסקים ישראליים רבים פשוט לקבוצת WhatsApp שכוללת את מי שאחראי. הודעת התראה טובה כוללת את שם התהליך, מה נכשל, על איזו רשומה, וקישור ישיר להרצה. התראה שכתוב בה רק ׳שגיאה בתהליך 4׳ תגרום לאנשים להתעלם ממנה תוך שבועיים.
כלל שנוי במחלוקת אבל חשוב: אם ערוץ ההתראות מקבל יותר משתיים־שלוש הודעות בשבוע במצב תקין, הוא כבר לא ערוץ התראות. עדיף לצמצם, לאחד שגיאות זהות להודעה אחת מסכמת, ולהשאיר את הצפצוף למה שבאמת דורש תגובה.
התראת heartbeat לתהליכים מתוזמנים
לתהליך שרץ לפי לוח זמנים יש מצב כשל שאף מנגנון שגיאות לא יתפוס: הוא לא רץ בכלל. השרת היה למטה, התזמון בוטל, מכסת הפעולות נגמרה, מישהו כיבה את ה-workflow כדי ׳לבדוק משהו׳ ושכח להחזיר. אין שגיאה כי אין הרצה.
הפתרון הוא מנגנון הפוך: התהליך מדווח על עצמו בכל סיום מוצלח לשירות חיצוני, והשירות מתריע אם הדיווח לא הגיע בזמן הצפוי. אפשר לעשות את זה בשירותי ניטור ייעודיים, ואפשר גם בשורת קוד קטנה מול טבלה ב-Airtable שבודקים אותה פעם ביום. העיקרון חשוב יותר מהכלי.
לוג הרצות שאפשר לחפש בו
כשמשהו נשבר, השאלה הראשונה היא ׳מאיזה רגע׳. בלי לוג הרצות עם חותמות זמן ומזהי רשומות, התשובה היא ניחוש, ואיתה מגיע תיקון ידני של אלף רשומות במקום שלושים. Make ו-Zapier שומרים היסטוריית הרצות בהתאם לתוכנית, ו-n8n שומר לפי ההגדרות שלכם. שווה לוודא כמה זמן ההיסטוריה נשמרת אצלכם בפועל, כי בתוכניות זולות זה לפעמים ימים בודדים. לתהליכים שנוגעים בכסף אנחנו כותבים לוג משלנו לטבלה נפרדת, עם מזהה הזמנה, מזהה חשבונית וזמן, כי זה מה שמאפשר להוכיח אחר כך מה קרה.
בדיקת שפיות תקופתית על מספרים
זו הבדיקה שתופסת את הכשל השקט, והיא פשוטה עד כדי גיחוך. בוחרים שני מספרים שאמורים להיות קרובים, ומסתכלים עליהם פעם בשבוע או בחודש: כמה הזמנות נסגרו מול כמה חשבוניות נוצרו, כמה לידים נכנסו לטופס מול כמה רשומות נוצרו ב-CRM, כמה תשלומים נקלטו מול כמה סומנו כשולמו. פער עקבי הוא סימן שמשהו בתהליך מפספס, גם אם כל ההרצות ירוקות.
אפשר לאוטמט גם את זה: תהליך שרץ בראשון בבוקר, סופר את שני המספרים, ושולח הודעה אחת לערוץ. שתי שורות. זה אחד הדברים הכי משתלמים שאנחנו בונים ללקוחות.
טבלת תקלות - מה מזהים, כמה מהר מגיבים ומי מטפל
| סוג תקלה | איך מזהים | זמן תגובה סביר | מי מטפל |
|---|---|---|---|
| טוקן או חיבור OAuth שפג | שגיאת הרשאה חוזרת בכל הרצה, התראה בערוץ | עד יום עסקים | מי שמחזיק את החשבון בעסק, בליווי הספק |
| שינוי שדה או שם עמודה | כשל שקט או שדה ריק בפלט, מתגלה בבדיקת שפיות | יום עסקים, אחרי עצירת התהליך | מי שבנה את התהליך |
| חריגה ממגבלת קצב | שגיאות 429 בחלק מההרצות, התנהגות לא עקבית | כמה שעות, לרוב פתיר בהגדרות | הספק או מי שאחראי טכנית |
| תהליך מתוזמן שלא רץ | התראת heartbeat, היעדר רשומות חדשות | כמה שעות אם התהליך נוגע בלקוח | מי שמנהל את הסביבה |
| מכסת פעולות או תשלום שנגמר | התראה מהפלטפורמה, עצירה גורפת של הכול | מיידי | בעל החשבון בעסק |
| שגיאה חד-פעמית ברשומה בודדת | רשומה בתור המתים, שורה בלוג | אפשר לרכז לטיפול שבועי | מי שמטפל בנתונים בעסק |
| נתון שגוי שכבר יצא ללקוח | תלונה של לקוח או השוואת מספרים | מיידי, כולל תיקון מול הלקוח | בעל התהליך העסקי, לא רק הטכני |
חוסן שבונים פנימה, לא מדביקים אחר כך
רוב ההבדל בין תהליך שדורש טיפול פעם בשבוע לתהליך שדורש טיפול פעם בחצי שנה נקבע בשעת הבנייה, לא בשעת התקלה. אלה המנגנונים שאנחנו מכניסים כברירת מחדל לכל תהליך שנוגע בכסף או בלקוח.
- Retry עם השהיה מדורגת. חלק ניכר מהשגיאות הן רגעיות - שרת עמוס, timeout, מגבלת קצב. ניסיון חוזר אחרי כמה שניות, ואז אחרי דקה, ואז אחרי חמש, פותר אותן בלי שאף אדם ידע. ניסיון חוזר מיידי בלולאה, לעומת זאת, רק מחמיר עומס.
- Idempotency. לפני שפועלים, בודקים אם הפעולה כבר בוצעה - לפי מזהה הזמנה, מזהה תשלום או מפתח ייחודי אחר. בלי זה, ניסיון חוזר אחרי כשל חלקי מייצר חשבונית כפולה או שתי הודעות WhatsApp לאותו לקוח. זו הטעות שהכי מביכה מול לקוח קצה.
- תור. כשיש התפרצות של אירועים, במקום לירות הכול בבת אחת מכניסים לתור ומעבדים בקצב קבוע. זה גם מונע חריגה ממגבלות וגם הופך את ההתנהגות לצפויה.
- ענף שגיאה מפורש. בכל שלב שיכול להיכשל יש מסלול שני שאומר מה קורה אז: לוג, התראה, שמירה בצד. תהליך שמסתיים בשגיאה בלי מסלול כזה פשוט נעלם.
- תור מתים לרשומות שנפלו. רשומה שנכשלה גם אחרי הניסיונות החוזרים לא נזרקת - היא נשמרת בטבלה ייעודית עם הסיבה והזמן. אחר כך אפשר לתקן ולהריץ מחדש רק אותה, במקום להריץ הכול מחדש ולקוות.
- מגבלת שפיות. אם תהליך שרגיל לעבד עשרים רשומות ביום פתאום מעבד אלפיים, עדיף שיעצור וישאל. זה מנגנון שחוסך מהומה כשמישהו מייבא קובץ ישן בטעות.
גיבוי ושחזור - שני דברים שונים
עסקים מגבים workflows בערך באותה מידה שהם מגבים מחשבים ניידים, כלומר לא. וזה חבל, כי אוטומציה מורכבת היא נכס שנבנה על פני שבועות, והיא יושבת בפלטפורמה שאתם לא שולטים בה. חשבון שנסגר בטעות, מחיקה של תהליך על ידי משתמש, או שדרוג שהשתבש - כל אחד מהם יכול למחוק את העבודה.
מה מגבים
- את ה-workflow עצמו: ייצוא JSON ושמירה בריפוזיטורי גיט. אפשר לאוטמט את זה - תהליך שרץ לילה, מושך את ההגדרות דרך ה-API של הפלטפורמה ודוחף לגיט. היתרון על פני קובץ בדרייב הוא היסטוריית שינויים, שמאפשרת לראות מה בדיוק השתנה ביום שבו הכול הפסיק לעבוד.
- את הקרדנציאלס בנפרד ובאופן מאובטח. מפתחות וטוקנים לא נכנסים לגיט, גם לא לריפו פרטי. מקומם במנהל סודות או בכספת סיסמאות ארגונית, עם רשימה מסודרת של מה מחובר לאן ועל שם מי.
- את בסיס הנתונים, אם אתם מריצים בעצמכם. n8n על שרת פרטי שומר הכול ב-Postgres, וצריך לגבות אותו כמו כל בסיס נתונים. חשוב במיוחד: את מפתח ההצפנה שמצפין את החיבורים. גיבוי בסיס נתונים בלי המפתח הזה הוא גיבוי של טקסט מוצפן שלא תוכלו לפתוח.
- את הנתונים העסקיים שהתהליך כותב אליהם. Airtable, Google Sheets ובסיסי נתונים אחרים - עם היסטוריה, לא רק עותק אחרון, כי טעות שרצה שבוע דורשת חזרה לנקודה שלפניה.
ובעיקר - בדיקה שהשחזור עובד
גיבוי שלא נבדק הוא הנחה, לא ביטוח. פעם ברבעון שווה לקחת תהליך אחד, לייבא את הגיבוי שלו לסביבה נפרדת, לחבר מחדש את הקרדנציאלס ולוודא שהוא רץ. הפעם הראשונה שעושים את זה כמעט תמיד מגלה משהו: קרדנציאל שלא היה בגיבוי, משתנה סביבה חסר, או תלות בקובץ ידני שאף אחד לא תיעד. עדיף לגלות את זה ביום רגיל.
ניהול שינויים - איפה בודקים ומתי לא נוגעים
כל אוטומציה שרצה בעסק היא פרודקשן, גם אם היא נבנתה בחצי שעה. פירוש הדבר שעריכה חיה של תהליך פעיל היא עריכה על לקוחות אמיתיים. בכלים שאין בהם הפרדת סביבות מובנית, עושים את זה בשכפול: משכפלים את התהליך, עורכים את העותק, מריצים אותו על נתוני בדיקה או על טווח מצומצם, ורק אז מחליפים.
כמה כללים פשוטים שחוסכים הרבה: שומרים גרסה לפני כל שינוי משמעותי, כותבים בשם התהליך או בהערה מה שונה ומתי, ולא מכניסים שני שינויים גדולים באותו יום - כי כשמשהו נשבר תרצו לדעת איזה מהם אשם.
והכלל הכי לא מתוחכם שיש: לא עולים לאוויר עם שינוי משמעותי כשאין מי שיטפל בו בשעות הקרובות. הניסוח האמריקאי הוא ׳לא נוגעים בפרודקשן ביום שישי׳, ובלוח הזמנים הישראלי זה בפועל יום חמישי אחר הצהריים. תהליך גבייה שנשבר בחמישי בערב מייצר שני ימים שקטים שבהם אף אחד לא מקבל חשבונית, ומתחיל את יום ראשון בבור.
נוהל התגובה - מה עושים בשעה הראשונה
כשמתגלה תקלה, האינסטינקט הוא לפתוח את התהליך ולהתחיל לתקן. זה בדרך כלל הסדר הלא נכון, כי כל דקה שהתהליך רץ שבור מוסיפה רשומות פגועות שתצטרכו לתקן ידנית אחר כך. זה הסדר שאנחנו עובדים לפיו.
- 1לעצור את הדימום. משביתים את התהליך או את השלב הבעייתי. גם אם התיקון ייקח חמש דקות, קודם עוצרים.
- 2להעריך את טווח הפגיעה בזמן. מתי ההרצה האחרונה הידועה כתקינה, ומתי התגלתה התקלה. זה הטווח שצריך לבדוק.
- 3לזהות את הרשומות שנפגעו בפועל. שולפים מהלוג את כל ההרצות בטווח, ומפרידים בין מה שנכשל בגלוי, מה שהצליח נכון, ומה שהצליח עם נתון שגוי.
- 4להחליט מה קורה מול לקוחות. אם יצאו הודעות שגויות, חשבוניות כפולות או מסמכים חסרים - מי מודיע ללקוח ומה אומרים. זו החלטה עסקית, לא טכנית, והיא לא מחכה לסוף התיקון.
- 5לתקן ידנית את מה שנפל. לרוב זה עבודה מייגעת ולא מתוחכמת: להשלים רשומות, לבטל כפילויות, לשלוח מה שלא נשלח. עדיף לעשות את זה לפני שמפעילים מחדש, כדי לא לערבב ישן וחדש.
- 6לאתר את הסיבה השורשית ולתקן אותה. לא לעקוף אותה בתנאי נוסף שמסתיר את הסימפטום. שדה שהשתנה מתוקן במיפוי, טוקן שפג מחודש עם בעלות ברורה, מגבלת קצב מטופלת בתור.
- 7להריץ מחדש בטווח מצומצם ולוודא. רשומה אחת, אחר כך עשר, ורק אז הכול.
- 8להוסיף את הבדיקה שהייתה תופסת את זה מוקדם יותר. אם התקלה התגלתה מלקוח, סימן שחסר ניטור. זה השלב שהופך את התקלה למשתלמת.
בעסקים שיש בהם יותר מאדם אחד שנוגע במערכות, שווה שהנוהל הזה יהיה כתוב במסמך אחד קצר, עם שמות. מי מחליט להשבית, מי מודיע ללקוחות, ולמי מתקשרים בערב.
צ׳קליסט תחזוקה
חודשי - כעשרים דקות
- מעבר מהיר על לוג ההרצות: אחוז הכשלים, ותהליכים שהתנהגותם השתנתה.
- בדיקת שפיות על זוג מספרים אחד לפחות בכל תהליך שנוגע בכסף.
- בדיקת התור המתים - האם הצטברו שם רשומות שאף אחד לא טיפל בהן.
- מבט על צריכת המכסה בפלטפורמה מול התוכנית, כדי לא להיתקע באמצע חודש.
- האם התראה כלשהי הופיעה בערוץ ואף אחד לא הגיב. אם כן, זו בעיה בפני עצמה.
רבעוני - כשעה עד שעתיים
- סקירת חיבורים והרשאות: על שם מי רשום כל חיבור, ומה קורה אם אותו אדם עוזב.
- רענון של טוקנים שידוע שיש להם תוקף, לפני שהם פוגעים.
- בדיקת שחזור אמיתית של תהליך אחד מהגיבוי.
- מעבר על תהליכים שכבר לא בשימוש - כיבוי או מחיקה מסודרת, כי תהליך ישן שרץ ברקע הוא מקור מצוין להפתעות.
- בדיקה מול הצוות מה השתנה בעסק: מוצר חדש, שדה חדש ב-CRM, ספק שהוחלף. שינויים עסקיים הם הסיבה הכי נפוצה לכך שאוטומציה נכונה הופכת ללא רלוונטית.
כמה זה עולה ומי אחראי
יש שלוש דרכים סבירות לנהל תחזוקה, ואף אחת מהן לא מתאימה לכולם. אפשר שהעסק יחזיק את זה בעצמו - מישהו פנימי שיודע להיכנס, לקרוא לוג ולתקן דברים פשוטים. אפשר לעבוד לפי שעות לפי הצורך, כלומר משלמים רק כשמשהו נשבר, מה שמתאים כשהתהליכים לא קריטיים ואפשר לחיות עם המתנה. ואפשר ריטיינר חודשי, שהמשמעות שלו היא ניטור מצדנו, זמן תגובה מוסכם, ומכסת שעות לשינויים קטנים.
מה שסביר לצפות מריטיינר, מכל ספק: שהוא יידע על תקלה לפניכם, שיהיה זמן תגובה כתוב ולא הבטחה בעל פה, שהגיבויים יהיו במקום שגם אתם ניגשים אליו, ושאם תחליטו להיפרד תקבלו את ה-workflows ואת התיעוד בלי ויכוח. מה שלא סביר לצפות: שריטיינר ימנע תקלות. הוא לא מונע, הוא מקצר.
מתי ריטיינר תחזוקה הוא בזבוז כסף
עסק עם שתי אוטומציות פשוטות - טופס שנכנס לגיליון, והודעת WhatsApp אוטומטית ללקוח חדש - לא צריך ריטיינר חודשי. הוא צריך ערוץ התראה אחד שמישהו באמת קורא, וכעשרים דקות בחודש. תשלום חודשי קבוע במצב כזה קונה בעיקר שקט נפשי, וזה מוצר יקר יחסית.
אותו דבר נכון כשהעסק עומד להחליף מערכת ליבה בחודשים הקרובים. אין הרבה טעם לשלם על תחזוקה שוטפת של תהליכים שממילא ייבנו מחדש. ואם התהליך העסקי עצמו עדיין לא יציב ומשתנה כל שבועיים, מה שאתם צריכים זה לא תחזוקה אלא להחליט איך העסק עובד. תחזוקה של תהליך שלא הוחלט עליו היא תשלום חודשי על אי-ודאות.
הקו שאנחנו מציעים ללקוחות: ריטיינר מוצדק כשהאוטומציה נוגעת ישירות בכסף או בהתחייבות ללקוח, כשיש מספיק תהליכים כדי שאף אחד לא זוכר את כולם, או כשאין בעסק אף אדם שיודע להיכנס ולתקן. בכל מצב אחר, התחילו מניטור ומצ׳קליסט, ותראו כמה פעמים בשנה באמת הייתם צריכים אותנו.
שאלות שחוזרות
- כל כמה זמן צריך לבדוק אוטומציות שעובדות טוב?
- אם יש ניטור אמיתי - התראה על כשל לערוץ שאדם קורא, וגם התראת heartbeat לתהליכים מתוזמנים - לא צריך לבדוק ידנית כל יום. מספיק עשרים דקות בחודש כדי לעבור על לוג ההרצות ולהשוות שני מספרים שאמורים להתאים, למשל כמה חשבוניות נוצרו מול כמה הזמנות נסגרו. פעם ברבעון שווה לעשות סבב עמוק יותר על הרשאות, טוקנים וגיבויים.
- אני חייב לשלם ריטיינר תחזוקה לספק שבנה לי את האוטומציה?
- לא בהכרח. עסק עם שתיים־שלוש אוטומציות פשוטות שרצות על Make או Zapier לרוב לא צריך ריטיינר חודשי, הוא צריך ערוץ התראה אחד שעובד ובן אדם שמקדיש לזה זמן קצר בחודש. ריטיינר מתחיל להיות מוצדק כשיש עשרות תהליכים, כשהאוטומציה נוגעת בכסף או בהתחייבות ללקוח, או כשאין בעסק אף אחד שיודע להיכנס ולתקן.
- מה זה כשל שקט ולמה הוא יותר מסוכן משגיאה רגילה?
- כשל שקט הוא הרצה שמסתיימת בהצלחה טכנית אבל מייצרת תוצאה שגויה או ריקה - למשל חשבונית שנוצרה בסכום אפס כי שדה שונה, או סינון שמחזיר אפס רשומות כי טקסט של סטטוס עודכן. שגיאה רגילה צועקת, הכשל השקט לא. לכן בנוסף לניטור שגיאות צריך בדיקת שפיות תקופתית על מספרים, שמשווה כמות פלט לכמות קלט.
- איך מגבים אוטומציות ב-n8n או ב-Make?
- את ה-workflow עצמו מייצאים כ-JSON ושומרים בריפוזיטורי גיט, כך שיש גם עותק וגם היסטוריית שינויים. את הקרדנציאלס לא שומרים באותו מקום - הם הולכים למנהל סודות או לכספת סיסמאות של הארגון. אם אתם מריצים n8n על שרת שלכם, צריך לגבות גם את בסיס הנתונים ואת מפתח ההצפנה, כי בלי המפתח הגיבוי של החיבורים לא שווה הרבה.
- כמה זמן סביר לחכות לתיקון כשאוטומציה קריטית נופלת?
- זה תלוי במה שסוכם מראש, ולכן שווה לסכם. לתהליך שנוגע ישירות בלקוח או בגבייה, זמן תגובה של כמה שעות עסקים הוא סביר, ולתהליך פנימי אפשר לחיות עם יום עסקים. מה שלא סביר הוא ספק שאין לו ערוץ תמיכה מוגדר ואתם מגלים את התקלה לפניו.
- האם אפשר לבנות אוטומציה שלא נשברת אף פעם?
- לא. אפשר לבנות אוטומציה שנשברת בצורה מנוהלת - שמנסה שוב לפני שהיא מוותרת, שלא שולחת פעמיים את אותו דבר, ששומרת בצד את הרשומה שנפלה במקום לאבד אותה, ושמודיעה לבן אדם. ההבדל בין מערכת טובה לרעה הוא לא מספר התקלות אלא כמה עבודה ידנית כל תקלה מייצרת.