תפעול: מוצר שאפשר להבין גם כשאיש לא עומד לידו

תפעול: מוצר צריך להיות ניתן להבנה גם כשאיש לא עומד לידו#

במוצר לא מספיק שהמפתח ידע "איפה הבעיה כנראה". צריך יכולת לזהות תקלה, לקשור אותה לגרסה ולפעולה, להבין את ההשפעה ולבצע תיקון מבוקר. Observability — יכולת תצפית אינה אוסף של צילומי מסך; היא האופן שבו המערכת מספקת מידע על מצבה דרך מדדים, לוגים ועקבות ביצוע. מקור: OpenTelemetry.

שלושה סוגי מידע שונים#

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

Metrics: מדדים לאורך זמן — שיעור כישלונות, זמן תגובה, עלות לתהליך, תורים תקועים ושיעור תיקונים. בלעדיהם מזהים תקלות בעיקר מהתלונות.

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

ניטור ללא מי שמגיב אינו מערכת תפעול#

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

Runbook, שחזור והמשכיות#

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