הגדרת מדדי USE לתשתיות: ניצול, רוויה, שגיאות

מדדי USE: היכן התשתית מאבדת יציבות

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

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

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

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

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

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

מה נותן היישום: מהירות תגובה ועתודת קיבולת

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

זמן גילוי תקלה

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

זמן שחזור השירות

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

סוג הכשלים ועלות ההשבתה

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

עתודת הקיבולת של הצומת

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

דרכים לאיסוף מדדי USE: סוכן, ייצואן, תשאול

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

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

שלבי היישום: מביקורת ועד מסירת נהלים

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

1. ביקורת כיסוי. ממפים צמתים, שירותים ותורים; עבור כל משאב מסמנים אילו משלושת האותות — ניצול, רוויה, שגיאות — כבר נראים, והיכן יש שטחים עיוורים: מאגרי חיבורים, תורי דיסק, ממשקי רשת.
2. סכמת איסוף נתונים. מגדירים נקודות דגימה, תדירות תשאול, סט תוויות ותקופת שמירה; מגבילים קרדינליות כדי שנפח האחסון לא יגדל עם מספר הקונטיינרים.
3. ערכי סף. עבור ניצול לוקחים סף לפי רמה יציבה לאורך חלון, עבור רוויה — לפי אורך התור וזמן ההמתנה, עבור שגיאות — לפי שיעור לאורך פרק זמן. סף בלי חלון מיצוע או מפספס ירידת ביצועים או מרעיש.
4. בדיקת התראות. מבצעים כשל תרגולי: מעמיסים על המשאב ומוודאים שהאות מגיע פעם אחת, עם הקשר ברור ונכבה בשחזור, ולא כמפולת על כל שלושת המדדים של אותו צומת.
5. מסירה לתפעול. מוסרים לוחות ניטור, כללי התראה כקונפיגורציה ונוהל תורנות: איזה אות אומר מה ובאיזה סדר לפעול בעת הפעלה.
6. סקירה אחרי עלייה לאוויר. אחרי כמה שבועות מנתחים הפעלות כוזבות והחמצות ומתקנים ספים לפי פרופיל העומס האמיתי — בלי זה התצורה מתרחקת מהמציאות במהירות.

מה מוסרים לידיים: סכמות, כללים, תיעוד

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

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

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

מקרה בוחן: איך סגרו שטחים עיוורים וקיצרו השבתה

מה היה לפני היישום

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

מה שינו

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

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

במה שונה דגימה מתמדת מתשאול מתוזמן?

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

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

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

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

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

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

ספקות טכניים לפני תחילת העבודות

מדדי USE מתארים כל צומת בשלושה ממדים — עומס (Utilization), רוויה (Saturation), שגיאות (Errors). הם נלקחים ממה שכבר נאסף: סוכנים על המארחים, ייצואני שירותים, אחסון סדרות זמן. אין צורך לשנות את הניטור הנוכחי — כללי חישוב, ספים ולוחות בקרה נוספים למערכת הקיימת.

כמה תגדל התקורה מאיסוף הנתונים?

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

איך לא לטבוע בהתראות כוזבות?

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

הסביבות שונות. סכמה אחת תתאים?

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

מה קורה אחרי המסירה?

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

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.