לעשות יותר עם פחות?לא בלי יומנים טובים יותר וכלים טובים יותר

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

חוויה אחת יוצאת דופן מהזמן שלי כארכיטקט backend על פרויקט מודרניזציה ענן.minimize or eliminate service-level loggingההחלטה הושלמה על ידי העלות הגבוהה של צריכת יומן על פלטפורמת המעקב שלנו.

זה עבד – עד שזה לא עבד.

באמת היינו זקוקים לבלוגים האלה!

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

// Sample (but not the real) log line removed during our cost-cutting
{
  "timestamp": "2025-03-21T14:05:03Z",
  "service": "preference-engine",
  "level": "ERROR",
  "message": "Worker queue overflow: unable to dispatch to worker pool",
  "requestId": "abc123",
  "userId": "admin_42"
}

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

_sourceCategory=prod/preference-engine "Worker queue overflow"
| count by userId, requestId

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

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

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

אבל זה לא היה סוג "טוב" של lean. ואת המועד שלנו לעבור לתוך הענן היה קבוע. היינו מרוץ נגד תאריך חיסכון דפדפן. זה פירושו לכתוב מחדש את השירותים לתוך עיצוב מקורי בענן, לתאם עם צוות הלקוח, ולספק תחת לחץ.we relied on logs to resolve our issuesזה היה בסדר בהתחלה, פשוט הוסיפנו את הדו"חות הדרושים בעת עבודה על כל שיטה.

אבל כאשר החטיבה נחתכה, הצוות היה חשוף, רשת הבטיחות העיקרית שלנו נעלמה.

שורש סיבה ללא רשת

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

אבל מהר מאוד הבנו שהביטחון שלנו היה מוטעה והכיסוי הבדיקה שלנו היה חסר.

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

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

_sourceCategory=prod/preference-engine OR prod/frontend error
| join ( _sourceCategory=prod/tester-feedback “queue error” )
  on requestId
| fields requestId, _sourceCategory, message

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

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

MTTR לעומת איכות האות

בעיה נוספת הייתה שבהתבוננותינו באירועים, פירושו זמן להתאוששות (MTTR) was being treated as a headline metric. But we found that MTTR was most often a symptom, not a root cause.

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

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

אם יומני האינטרנט שלך אינם עונים על שאלות אלה, MTTR שלך הוא לא על מהירות הצוות - זה על בהירות האות.

כיצד המודל של סומו לוגיק יכול היה להציל את היום

So what could have gone differently—and better—during my cloud modernization project?

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

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

האם אתה צוות ללא כיסוי בדיקות יחידה מלאה? סובל מחוסר אזהרות בזמן אמת או מדדים גרניריים? על תקציב צמוד?

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

גישה זו מחזירה שליטה ומורידה את החרדה כי צוותים מורשים לחקור היטב כאשר זה הכי חשוב.

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

תצפית מודרנית היא לא רק על כל הנתונים היפים הללו – זה גם על לדעת איפה להסתכל על הנתונים הללו.high-fidelity signals.

כאשר יש לך צריכה בלתי מוגבלת, יש לך טון של נתונים וכאשר אתה מתחיל לחפש מידע, אתה צריך מקום להתחיל.machine-assisted triage tools that automatically group anomalous behavior, detect outliers, and surface correlated signals across services before you write a single query.

מאחורי הקלעים, Sumo Logic השתמשה אלגוריתמים סטטיסטיים ולימוד מכונה כדי:

• יומני קבוצות לפי דמיון (אפילו אם מתוארים באופן שונה בין גרסאות).
• זיהוי חריגים במדידות ובלוגים (לדוגמה, פסקי שגיאה לפי שירות, אזור או קבוצת משתמשים).
• להעשיר את ההפרעות עם מטא-נתונים (לדוגמה, תגיות AWS, Kubernetes pod info, תוויות הפצה).
• קבוצות עיבוד שפה טבעית רשומות על ידי דמיון סמנטי, לא רק תואמות חוטים.

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

דוגמה ל Workflow

_sourceCategory=prod/* error
| logreduce

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

Error: Worker queue overflow
Error: Auth token expired for user *
Error: Timeout in service *

לאחר הקבוצות, צוותים יכולים להסתובב לקשר עמוק יותר:

| where message matches "Auth token expired*"
| count by userId, region

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

מסקנה

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

הקוראים שלי עשויים לזכור את הצהרת המשימה האישית שלי, אשר אני חושב יכול לחול על כל IT מקצועי:

"תמקד את הזמן שלך על מתן תכונות / פונקציונליות שמאפשרות להרחיב את הערך של הקניין הרוחני שלך.

"תמקד את הזמן שלך על מתן תכונות / פונקציונליות שמאפשרות להרחיב את הערך של הקניין הרוחני שלך.

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

שיהיה לכם יום נהדר באמת!