מה זה Observability? הסבר + משרות פתוחות בישראל

זמן קריאה: 6 דקות

Observability היא היכולת להבין מה קורה בתוך מערכת מתוך מה שהיא פולטת החוצה - מדדים, לוגים וטרייסים - כולל לענות על שאלות שלא חשבתם עליהן מראש. זה ההבדל מניטור, שעונה רק על מה שהוגדר לו. בלוח HiTakeJob פתוחות כרגע 20 משרות שמזכירות Grafana, 20 שמזכירות Prometheus ו-110 שמזכירות Kubernetes.

ההבדל מניטור - בשאלה אחת

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

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

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

שלושת המקורות

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

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

מה מודדים בכל שכבה

מערכת שלמה נמדדת בארבע רמות, ולכל אחת שאלה אחרת:

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

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

איך נראית חקירת תקלה אמיתית

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

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

מה הופך לוג לשימושי

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

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

מה מקשר בין שלושת המקורות

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

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

למה התראות טובות קשות יותר מדשבורדים

דשבורד יפה קל לבנות; מערכת התראות שאפשר לחיות איתה קשה. הכלל המרכזי: התראה צריכה לדרוש פעולה אנושית מיידית. כל דבר אחר הוא דשבורד או דוח.

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

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

מה זה אומר על העלות

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

מה שעושים בפועל: דוגמים חלק מהטרייסים במקום את כולם, שומרים לוגים מפורטים לתקופה קצרה ומסוכמים לתקופה ארוכה, ומגדירים מדיניות שמירה לפי סוג. אלה החלטות הנדסיות לכל דבר, והן חלק מתפקידם של צוותי תשתית - אפשר לראות אותן ב43 משרות תשתיות ו-IT הפתוחות כרגע, ובהקשר הרחב יותר במה זה DevOps.

שאלות נפוצות

מה ההבדל בין ניטור ל-Observability?

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

מאיפה מתחילים במערכת שאין בה כלום?

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

אילו כלים נפוצים בישראל?

בלוח שלנו 20 משרות מזכירות Grafana לתצוגה, 20 מזכירות Prometheus לאיסוף מדדים, ו-8 מזכירות Elasticsearch שמשמש בין היתר לחיפוש בלוגים. לצידם קיימים שירותים מסחריים מנוהלים.

כמה טרייסים צריך לשמור?

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

האם זה רק עניין של צוותי תשתית?

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

מה זה SLO ואיך זה קשור?

SLO הוא יעד אמינות מדיד שנגזר מהמדדים שאתם אוספים, וההתראות הטובות ביותר נגזרות ממנו ולא מסף טכני שרירותי. פירטנו את הנושא במה זה SLA, SLO ו-SLI.