למה למהנדסים לא אכפת מניטור יישומים?

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

ניטור הוא רק. זו עובדה ידועה. העלה את Nagios, הפעל את NRPE במערכת המרוחקת, הגדר את Nagios ביציאת NRPE TCP 5666 ויש לך ניטור.

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

(בדרך כלל הם מתקינים את PNP4Nagios, RRDtool ו-Thruk, מגדירים התראות ב-Slack ועוברים ישר ל-nagiosexchange, אבל נעזוב את זה לעת עתה).

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

האם הניטור קשה?

כל שרת, בין אם זה לינוקס או ווינדוס, בהגדרה ישרת מטרה כלשהי. Apache, Samba, Tomcat, אחסון קבצים, LDAP - כל השירותים הללו הם פחות או יותר ייחודיים במובן אחד או יותר. לכל אחד יש תפקיד משלו, מאפיינים משלו. ישנן דרכים שונות לקבל מדדים, KPIs (מדדי ביצועים מפתח), שמעניינים אותך כאשר השרת נמצא תחת עומס.

תמונה על ידי לוק צ'סר על Unsplash

(הלוואי לוחות המחוונים שלי היו כחולים ניאון - נאנח בחולמניות -... הממ...)

כל תוכנה המספקת שירותים חייבת להיות בעלת מנגנון לאיסוף מדדים. לאפצ'י יש מודול mod-status, מציג את דף מצב השרת. ל-Nginx יש - stub_status. ל- Tomcat יש JMX או יישומי אינטרנט מותאמים אישית המציגים מדדי מפתח. ל-MySQL יש פקודה "הצג מצב גלובלי" וכו'.
אז למה מפתחים לא בונים מנגנונים דומים באפליקציות שהם יוצרים?

האם רק מפתחים עושים זאת?

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

תמונה על ידי טים גו על Unsplash

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

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

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

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

הדבר הזה מחלל

מנטליות ה-devops מתארת ​​את הסינרגיה בין חשיבה לפיתוח (dev) לחשיבה תפעולית (ops). כל חברה שמתיימרת "לעשות devops" חייבת:

1. אומרים דברים שהם כנראה לא אומרים (הכוונה למם The Princess Bride - "אני לא חושב שזה אומר מה שאתה חושב שזה אומר!")
2. עודדו גישה של שיפור מתמיד של המוצר.

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

העבר שמאלה, שמאלה, אמרתי לי-

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

תמונה על ידי NESA מאת Makers על Unsplash

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

בקיצור

1. הוביל את הסוס שלך למים. הראה למפתחים כמה צרות הם יכולים להימנע מעצמם, עזרו להם לזהות את מדדי ה-KPI והמדדים הנכונים עבור האפליקציות שלהם, כך שיהיו פחות צעקות מבעל המוצר שעליו צועקים ה-CTO. הביאו אותם אל האור, בעדינות ובשלווה. אם זה לא עובד, אז תשחד, איום ושידל אותם או את בעל המוצר ליישם קבלת מדדים אלה מהיישומים מהר ככל האפשר, ואז צייר את התרשימים. זה יהיה קשה מכיוון שזה לא יראה בעדיפות ומפת הדרכים של המוצר יהיו פרויקטים מניבים רבים בהמתנה. לכן, תצטרך מקרה עסקי כדי להצדיק את הזמן וההוצאות המושקעות ביישום ניטור במוצר.
2. עזור למהנדסי מערכת לישון טוב בלילה. הראה להם ששימוש ברשימת "בוא נשחרר" עבור כל מוצר שיוצא הוא דבר טוב. והקפדה על כל היישומים בייצור מכוסים במדדים תעזור לך לישון טוב יותר בלילה על ידי כך שתאפשר למפתחים לראות מה משתבש ואיפה. עם זאת, הדרך הנכונה לעצבן ולתסכל כל מפתח, בעל מוצר או CTO היא להתמיד ולהתנגד. התנהגות זו תשפיע על תאריך השחרור של כל מוצר אם תחכה שוב לרגע האחרון, אז העבר שוב שמאלה והכנס את הבעיות האלה לתוכנית הפרויקט שלך בהקדם האפשרי. במידת הצורך, עשה את דרכך לפגישות המוצר. תלבש שפם מזויף לבד או משהו, זה לעולם לא ייכשל. העבירו את החששות שלכם, הדגימו יתרונות ברורים ובשרו.
3. ודא שגם פיתוח (dev) וגם תפעול (ops) מבינים את המשמעות וההשלכות של מדדי מוצר שנעים לאזור האדום. אל תשאיר את Ops כשומר הבלעדי של בריאות המוצר, וודא שגם מפתחים מעורבים (#productsquads).
4. יומנים הם דבר נהדר, אבל גם מדדים. שלבו אותם ואל תתנו לבולי העץ שלכם להפוך לאשפה בכדור בוער ענק של חוסר תועלת. הסבירו והראו למפתחים מדוע אף אחד אחר לא יבין את היומנים שלהם, הראו להם איך זה להסתכל על יומנים חסרי תועלת ב-3:15 בבוקר.

תמונה על ידי מרקו הורבט על Unsplash

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

מקור: www.habr.com