מהם תפקידי ה-on-call?

מה בעצם האחריות של on-call, ועל פי מה היא נקבעת? זאת בעיה שמתמודד אתה כל ארגון שנדרש לתת שירות מעבר לשעות העבודה.

מה בעצם תפקיד הכונן בכלל?

בעיקר לדאוג ליציבות המוצר או השירות בהתאם למדדים שהחברה הגדירה לעצמה – גם בשעות הלא שגרתיות שלה.
קיים מתח מובנה בין שתי תפיסות של ה-on call:

  • הכונן כמי שמביא לפתרון הבעיה – לאורך כל המסלול שלה
  • router לצוותים ולאנשים בתוך הארגון שיביאו לפתרונה/הבנתה.
בספר ה-sre של גוגל, יש פרק שמוקדש לתפקידי ה-on-call – מומלץ ביותר.

לפי מה מוגדר תפקיד ה-on call?

יש יתרונות וחסרונות בין התפישות – והקו המנחה מנוהל בין היתר, בין פרמטרים הבאים:

  1. הקו המנחה של הארגון

    ארגונים גדולים נוטים לדרוש מה-on call להיות יותר router על חשבון הפתרון המלא, שכן – לעובד במערכת גדולה כל-כך אין כל הכלים לפתור תקלות בעצמו מההתחלה ועד הסוף; גם אם הוא מכיר – הוא לא יודע את כל השיקולים של הצוות המפתח; לפעמים – הבנה של הצוות הרלוונטי לבדה סבוכה.מאידך, בסטארטאפ צעיר יצופה מהמתכנת ה-on call – נקרא לו שלמה – לצעוק לגרשון, שנמצא 2 מטר ממנו (נו, המגבלות של הקורונה), אם יכול להיות שהפיצ׳ר של אתמול קורא ל-api חדש ללא מנגנון timeout ולמה הוא היה עצלן ולא הוסיף טסטים לקריאות ארוכות מדי וברצף; שלמה, ייאלץ אף להוסיף תיעוד לתקלה, ואולי אפילו רפרנס לתקלה בהערה בקוד עם todo (או אולי עוד שורה ב-Monday); כלומר – יביא יותר מתוך פתרון התקלה.

  2. הקו המנחה של האלרט

    קיימים אלרטים שפעולה פשוטה יחסית תיתן מענה מהיר לתקלה, והנזק במקרה שלא הוא קטן (העלאת מספר הרפליקות/ המכונות, ריסוט של סרביס וכיו״ב), במקרה כזה אולי מצופה מה-on call להתחיל בפתרון שלכל הפחות לא יזיק לפתני שיזעיק את שאר הצוות. כמובן – עדיף שגם לפעולות קצרות כאלו יהיה תיעוד שיאפשר למנהלים לקבל החלטות לגבי תיעדוף עבודת תשתית שתפתור את המצבים האלו לבד.

    via GIPHY

  3. הקו המנחה של ה-on call

    בתלות עם יחסי הארגון עם ה-on-call (למשל – מתכנת/ devops/ SRE ותיק): יהיו on call שיראו בעצמם יותר ראוטרים, ויהיו שיראו את עצמם כפותרי התקלה – וזה תלוי בסט הכלים שיש להם, ועד כמה הארגון והם סומכים על הידע שלהם בתוך הקונטקסט של האלרט. למשל – מתכנת שעבר בין צוותים והוא ותיק והארגון עצמו מכיר את דרך פעולותיו – למתכנת כזה יתאפשר יותר מרחב לביצוע פעולות, ויש לו יותר כח החלטה על דרך הפעולה שלו (לנתב לצוות הספציפי שקשור לתקלה או לפתור אותה בעצמו)כל on-call, עבור כל אלרט מתוך התפיסה של כל ארגון נע במתח הזה.מה הקו המנחה שלכם בתפישת תפקיד ה-on call?

    via GIPHY

מאמרים נוספים

עלויות מעבר מערכות לוגים ואלרטים

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

אחריות SRE

יש נטייה, בכל יצירה של תפקיד חדש – לשאול מאי נפקא מינה? בהקשר של SRE עולה השאלה האלמותית: מה ההבדל בין SRE ל-devops? גוגל הפיקו את הסרטון הנהדר הבא: אני חושב שזה קצת סמנטי,

אלרט טוב, ואלרט רע

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

יציבות בפרוייקטים? יאן ווגינפירר מסביר

יאן מנהל את החברות eventrys ו-daynix יאן, ספר על daynix שלך הקמנו אותה עם עוד שותפים לפני 9 שנים, כולנו מפתחי קרנל. בין אם זה לינוקס קרנל, וונדוז קרנל דרייברז או אמבדד. הרגשנו שצריך

לכתוב test-ים של js ב-python

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