מאז שהתחלתי לטכנולוגיה בשנת 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 לעומת איכות האות בעיה נוספת הייתה שבהתבוננותינו באירועים, פירושו זמן להתאוששות ( ) was being treated as a headline metric. But we found that MTTR was most often a symptom, not a root cause. MTTR מדדי התעשייה מראים בדרך כלל שהקבוצות האליטה הגיעו ל-MTTR תוך פחות משעה, אבל מה שהבנו היה שהמהירות אינה רק אוטומציה – היא אותות אמינות נמוכה, כגון שגיאות 500 כלליות או אזהרה מאוחרת ממדידות מצטברות, לא באמת עוזרים. high-fidelity signals לעומת זאת, אותות מפורטים ומקשרים – כגון יומן מובנים עם userId, requestId ושלב שירות – חותכים ישירות לגורם השורש. אם יומני האינטרנט שלך אינם עונים על שאלות אלה, MTTR שלך הוא לא על מהירות הצוות - זה על בהירות האות. כיצד המודל של סומו לוגיק יכול היה להציל את היום So what could have gone differently—and better—during my cloud modernization project? ראשית, אני באמת רוצה שתהיה לנו ניתוח יומן טוב יותר ומעקב אחר ביצועי יישומים (APM).ואז עם זה APM, ניהול יומן, מנועי שירות, אזהרות ומדיטות מוגדרות בקשר הדוק עם הצלחה פונקציונלית או כישלון.אני רוצה (בכל פרויקט) כי עבור כל תכונה חדשה היה לי מדיטציה קשורה להצלחה שלה. ואני רוצה את הכתבות שלי בחזרה!בפרסום הקודם שלי, " "אני בוחן איך ניתן לצרוך יומנים באופן קבוע, אבל אתה משלם רק כאשר אתה צריך לשאול או לנתח אותם. DevSecOps: הגיע הזמן לשלם על הביקוש שלך, לא על צריכת, תגית: sumo logic האם אתה צוות ללא כיסוי בדיקות יחידה מלאה? סובל מחוסר אזהרות בזמן אמת או מדדים גרניריים? על תקציב צמוד? עם צריכת מלאה של אפס עלויות, צוותים יכולים להירשם כמה שהם צריכים ללא דאגה.ואם האירוע הזה סוף סוף מתרחש (והוא יהיה), ניתוח יכול להיות מופעל על פי דרישה, במחיר הוגן הקשור ישירות להשפעה של הלקוח או המשך העסק.האנשים בתקציב שמחים; אתה שמח. גישה זו מחזירה שליטה ומורידה את החרדה כי צוותים מורשים לחקור היטב כאשר זה הכי חשוב. אבל לחכות: אתה גם צריך משולב עוזר מכונה כדי לנקות את השאלות שלך תצפית מודרנית היא לא רק על כל הנתונים היפים הללו – זה גם על לדעת איפה להסתכל על הנתונים הללו. . high-fidelity signals כאשר יש לך צריכה בלתי מוגבלת, יש לך טון של נתונים וכאשר אתה מתחיל לחפש מידע, אתה צריך מקום להתחיל.  that automatically group anomalous behavior, detect outliers, and surface correlated signals across services before you write a single query. machine-assisted triage tools מאחורי הקלעים, 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 מקצועי: 
 
 "תמקד את הזמן שלך על מתן תכונות / פונקציונליות שמאפשרות להרחיב את הערך של הקניין הרוחני שלך. "תמקד את הזמן שלך על מתן תכונות / פונקציונליות שמאפשרות להרחיב את הערך של הקניין הרוחני שלך. במאמר זה, הסתכלנו על האופן שבו מודל אכילה בעלות אפס תואם את המשימה הזו.הוא עוזר לקבוצות לזהות במהירות את הגורמים הבסיסיים, להפחית את זמן ההפסקות ואת רמות הלחץ הנמוכות יותר – הכל מבלי לשבור את התקציב. שיהיה לכם יום נהדר באמת!

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

האודיו הזה מופק בשפת המקור של הסיפור!

יותר מדי זמן; לקרוא

Make resilience your competitive advantage

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

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

Fortunate Son From Our Neighborhood

The TechBeat: Everything You Need to Know to Implement Generative AI for Your Enterprise (3/12/2024)

The TechBeat: Investigating Internet Freedom: Unseen Aspects of Our Online Existence (1/20/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/14/2024)

Fortunate Son From Our Neighborhood

The TechBeat: Everything You Need to Know to Implement Generative AI for Your Enterprise (3/12/2024)

The TechBeat: Investigating Internet Freedom: Unseen Aspects of Our Online Existence (1/20/2024)

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/14/2024)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps