איך איבן עשה מדדי DevOps. מושא השפעה

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

אפילו בסופי שבוע הוא חשב על מדדים: "אז מה אם אני מודד זמן? מה זה ייתן לי?

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

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

איך להיות?…

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

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

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

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

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

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

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

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

— דניס, בבקשה תגיד לי, האם אפשר איכשהו להבין שהצוות עבר דוכן זה או אחר?
- בוודאי. ג'נקינס שלנו משליך את הדגל אם המבנה יצא בהצלחה (עבר את המבחן) על הספסל.
- סופר. מה זה דגל?
- זהו קובץ טקסט רגיל כמו "stand_OK" או "stand_FAIL", שאומר שהאסיפה עברה או נכשלה במבחן. ובכן, אתה מבין, נכון?
- אני מניח שכן. האם זה כתוב לאותה תיקייה במאגר שבו נמצא האסמבלי?
- כן
— מה קורה אם ההרכבה לא תעבור את ספסל הבדיקה? האם אצטרך לבנות חדש?
- כן
- טוב, אוקיי, תודה. ועוד שאלה: האם אני מבין נכון שאני יכול להשתמש בתאריך יצירת הדגל בתור תאריך העמדה?
- בהחלט!
- סופר!

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

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

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

להמשך ...

מקור: www.habr.com