מדדי DevOps - היכן ניתן לקבל נתונים לחישובים

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

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

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

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

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

ואכן, חשב איוון, ידיעת המספר לא אומרת כלום לאף אחד. 200 ימים או יומיים - אין הבדל, כי אי אפשר לקבוע את הסיבה לפי המספר ולהבין אם היא טובה או רעה.

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

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

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

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

מטרת מדדי DevOps

ברור שכולם רוצים לצמצם את זמן האספקה. 200 ימים זה, כמובן, לא טוב.

אבל איך, זו השאלה?

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

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

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

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

כיצד לחשב זמן אספקה ​​עבור DevOps

כדי לחשב אותו, היה צורך להתעמק בתהליך ה-DevOps ובמהותו.

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

כל המשימות בחברה נרשמו בג'ירה. כאשר נלקחה משימה, נוצר עבורה סניף ולאחר היישום בוצעה התחייבות ל-BitBucket ול-Pull Request. כאשר התקבלה PR (Pull Request), הפצה נוצרה באופן אוטומטי ונשמרה במאגר Nexus.

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

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

• מ-Nexus - זמן יצירת הפצה ושם התיקיה שהכילה את קוד הפקודה
• מג'נקינס – שעת התחלה, משך ותוצאת כל משרה, שם הדוכן (בפרמטרי המשרה), שלבים (שלבי עבודה), קישור להפצה בנקסוס.
• איוון החליט לא לכלול את ג'ירה ו-BitBucket בצנרת, כי... הם היו קשורים יותר לשלב הפיתוח, ולא לפתיחת החלוקה המוגמרת על דוכנים.

על סמך המידע הקיים, התרשים הבא:

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

להלן מדדי ה-DevOps שאיבן סיים איתם:

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

מצד אחד, המדדים אפיינו היטב את צינור DevOps מבחינת זמן, מצד שני הם נחשבו לפשוטים מאוד.

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

הוא חזר קודר ובידיים למטה.

"זה פיאסקו, אחי," חייך הקולגה האירוני...

קרא עוד במאמר "כמה תוצאות מהירות עזרו לאיוון".

מקור: www.habr.com