יש בעיות בחיים שלנו. פה ושם יש תקלות.

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

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

בנייה נכונה של תהליכים וטיפול בתקלות אוטומציה אלו תורות שלמות בפני עצמן, במאמר הזה אתרכז באופן ספציפי בכלי מובנה של מערכת Make שנועד לתת מענה לתקלות שונות – Error handlers.

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

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

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

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

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

יאללה!

קודם כל: איך להוסיף Error handler?

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

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

כפי שניתן לראות, ישנם 5 סוגים של א"ה ש-Make מציעים, אבל למעשה אפשר להוסיף כל מודול כא"ה. כלומר, אפשר לא להשתמש בא"ה הקיימים אלא להגדיר שבמקרה של תקלה האוטומציה, נניח, תשלח לנו מייל באמצעות מודול של Gmail.

כעת אסביר על 5 הא"ה המובנים של Make, שמכונים אצלם גם Directives.

Rollback

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

מתי טוב להשתמש בזה?

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

Break

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

ניתן לראות שכשמנסים להוסיף א"ה של Break צץ עליו מעין עיגול אזהרה אדום, שמזכיר לנו להפעיל הגדרה בהגדרות הסנריו שהכרחית כדי שה-Break יוכל לפעול:

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

אם כל הניסיונות ייכשלו – הריצה עדיין תישמר וניתן יהיה לטפל בה ידנית. את הריצות שנתקעו אפשר למצוא בחלון של כל סנריו תחת הכותרת Incomplete executions:

ומשם אפשר להריץ אותן ידנית.

מתי טוב להשתמש בזה?

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

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

Resume

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

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

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

מתי טוב להשתמש בזה?

אם אנחנו יודעים מראש על פרמטר ספציפי שיכול לייצר בעיות (למשל: גוגל דרייב לא יכול לפתוח תיקייה אם שם התיקייה כבר "תפוס"), אפשר להשתמש ב-Resume כדי להחליף את הערך הזה ולאפשר לאוטומציה להמשיך לרוץ. למשל: אם אני מנסה לפתוח תיקייה בשם XXXX והשם הזה כבר קיים, אני יכולה להגדיר שהשם החלופי של התיקייה יהיה XXXX-1.

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

Ignore

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

מתי טוב להשתמש בזה?

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

Commit

במקרה של שגיאה במודול עם א"ה מסוג Commit, התוצאה תהיה דומה ל-Ignore, למעט העובדה ש-Commit מפסיק לגמרי את הריצה של הסנריו. המשמעות היא שאם הסנריו מתחיל מעיבוד כמה באנדלים של מידע – כולם יזכו להתעלמות והמודולים בהמשך הסנריו לא יופעלו עליהם (בניגוד ל-Ignore שמאפשר לאוטומציה לזנוח רק את הבאנדל הבעייתי בעוד הבאים בתור יעובדו כרגיל).

מתי טוב להשתמש בזה?

האמת? מעולם לא השתמשתי בזה, אבל מניחה שאם זה קיים בטח יש לזה איזה שהוא שימוש 😂

אבל רגע… זה תלוי מה התקלה!

נכון, בהרבה מקרים נרצה להגדיר פתרונות שונים לסוגים שונים של בעיות, לכן Make מאפשרת להפריד בין סוגי תקלות ולהגדיר א"ה שונה לכל סיטואציה – באמצעות שימוש ב-Router ופילטור לפי סוג התקלה.

למשל במקרה הזה:

הפעולה שהאוטומציה מנסה לעשות היא רישום של איש קשר חדש ל-Smoove. הגדרתי שאם השגיאה שקרתה היא שאיש הקשר כבר קיים ברשימה – לא יקרה כלום (Ignore). זו לא באמת שגיאה מבחינתי, והכי חשוב שהאוטומציה תמשיך לרוץ כשאיש הקשר הבא ייכנס. בכל תקלה אחרת אני ארצה לבדוק נקודתית מה התרחש ולתקן ידנית במידת הצורך (Break).

כדאי לשים א"ה על כל מודול ומודול?

זו שאלה שאני עצמי מתלבטת בה, ולרוב מכריעה שלא – בעיקר בגלל שזו משימה מעיקה שלוקחת זמן ולרוב אין בה צורך. בשלב הבנייה אני נוטה לשים א"ה מראש רק במודולים שאני צופה שיעשו בעיות, למשל מודולים של Gmail תמיד יקבלו אצלי א"ה של Break עם ניסיון נוסף אחרי 60 דקות, פשוט כי השרתים של ג'ימייל נוטים לא להגיב מדי פעם. בשלב הטסטים וה-QA בדרך כלל נעלה על התקלות הנפוצות, ונוכל לתת להן מענה לעתיד – בין אם במודול עצמו ובין אם בעזרת א"ה מתאים.

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

אז לסיכום:

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