صادقانه بگویم، ایوان اغلب به تلاش های بیهوده همکارانش از بخش نظارت می خندید. آنها تلاش زیادی برای اجرای معیارهایی که مدیریت شرکت به آنها دستور داده بود انجام دهند. آنقدر سرشان شلوغ بود که نمی خواستند هیچ کس دیگری کاری بکند.
اما این برای مدیریت کافی نبود - آنها دائماً معیارهای جدید بیشتری را سفارش می دادند و خیلی سریع از آنچه قبلاً انجام شده بود استفاده نمی کردند.
اخیراً، همه درباره LeadTime صحبت می کنند - زمان ارائه ویژگی های تجاری. این معیار یک عدد دیوانه را نشان داد - 200 روز برای ارائه یک کار. چقدر همه اوه و آه کردند و دستشان را به سوی آسمان بلند کردند!
پس از مدتی، سر و صدا به تدریج خاموش شد و مدیریت دستور ایجاد معیار دیگری را دریافت کرد.
برای ایوان کاملاً واضح بود که معیار جدید به همان اندازه بی سر و صدا در یک گوشه تاریک خواهد مرد.
در واقع، ایوان فکر کرد، دانستن این شماره به هیچ‌کس چیزی نمی‌گوید. 200 روز یا 2 روز - هیچ تفاوتی وجود ندارد، زیرا نمی توان دلیل را با تعداد مشخص کرد و فهمید که خوب یا بد است.
این یک تله معمولی از معیارها است: به نظر می رسد که یک معیار جدید جوهر وجود را بازگو می کند و راز مخفی را توضیح می دهد. همه به این امید زیادی دارند، اما به دلایلی هیچ اتفاقی نمی افتد. بله، چون راز را نباید در متریک جستجو کرد!
برای ایوان، این یک مرحله گذرانده بود. او این را فهمید برای اندازه گیری ها، و تمام اسرار باید در آن جستجو شود ، یعنی این است که این متریک تشکیل شده است.
برای یک فروشگاه آنلاین، هدف نفوذ مشتریان آن خواهد بود که پول وارد می‌کنند، و برای DevOps، تیم‌هایی هستند که با استفاده از خط لوله توزیع‌ها را ایجاد و عرضه می‌کنند.
یک روز، ایوان که روی یک صندلی راحت در سالن نشسته بود، تصمیم گرفت به دقت فکر کند که چگونه می‌خواهد معیارهای DevOps را ببیند، با در نظر گرفتن این واقعیت که هدف از نفوذ تیم‌ها هستند.
هدف از DevOps Metrics
واضح است که همه می خواهند زمان تحویل را کاهش دهند. البته 200 روز خوب نیست.
اما چگونه، این سوال است؟
این شرکت صدها تیم را استخدام می کند و هزاران توزیع روزانه از طریق خط لوله DevOps انجام می شود. زمان تحویل واقعی به عنوان یک توزیع ظاهر می شود. هر تیم زمان و ویژگی های خاص خود را خواهد داشت. چگونه می توان چیزی در میان این آشفتگی پیدا کرد؟
پاسخ به طور طبیعی مطرح شد - ما باید تیم‌های مشکل‌دار را پیدا کنیم و بفهمیم چه اتفاقی برای آنها می‌افتد و چرا این همه طول می‌کشد، و از تیم‌های "خوب" یاد بگیریم که چگونه همه چیز را سریع انجام دهیم. و برای انجام این کار، باید زمان صرف شده توسط تیم ها در هر یک از استندهای DevOps را اندازه گیری کنید:
"هدف این سیستم انتخاب تیم ها بر اساس زمان عبور آنها از جایگاه خواهد بود، یعنی. در نتیجه، باید لیستی از دستورات را با زمان انتخاب شده دریافت کنیم، نه یک عدد.
ایوان فکر کرد، اگر بفهمیم که در مجموع چقدر در جایگاه صرف شده است و چقدر برای استراحت بین جایگاه ها صرف شده است، می توانیم تیم ها را پیدا کنیم، آنها را صدا کنیم و دلایل را با جزئیات بیشتری درک کنیم و آنها را حذف کنیم.
نحوه محاسبه زمان تحویل برای DevOps
برای محاسبه آن، لازم بود به فرآیند DevOps و ماهیت آن بپردازیم.
این شرکت از تعداد محدودی سیستم استفاده می کند و اطلاعات را فقط از آنها می توان دریافت کرد و هیچ جای دیگر.
تمام وظایف در شرکت در جیرا ثبت شد. زمانی که وظیفه ای بر عهده می گرفت، یک شاخه برای آن ایجاد می شد و پس از پیاده سازی، یک commit به BitBucket و Pull Request انجام می شد. هنگامی که یک PR (درخواست کشش) پذیرفته شد، یک توزیع به طور خودکار ایجاد و در مخزن Nexus ذخیره می‌شود.
سپس، توزیع بر روی چندین غرفه با استفاده از Jenkins برای بررسی صحت عرضه، آزمایش خودکار و دستی اجرا شد:
ایوان توضیح داد که از کدام سیستم ها چه اطلاعاتی می توان برای محاسبه زمان در غرفه ها گرفت:
- از Nexus – زمان ایجاد توزیع و نام پوشه ای که حاوی کد فرمان است
- از جنکینز – زمان شروع، مدت و نتیجه هر کار، نام جایگاه (در پارامترهای شغل)، مراحل (مراحل کار)، پیوند به توزیع در Nexus.
- ایوان تصمیم گرفت Jira و BitBucket را وارد خط لوله نکند، زیرا... آنها بیشتر مربوط به مرحله توسعه بودند، و نه به پخش توزیع نهایی روی غرفه ها.
بر اساس اطلاعات موجود نمودار زیر ترسیم شد:
با دانستن اینکه چقدر طول می کشد تا توزیع ها ایجاد شوند و چه مقدار زمان برای هر یک از آنها صرف می شود، می توانید به راحتی کل هزینه های گذراندن کل خط لوله DevOps (چرخه کامل) را محاسبه کنید.
در اینجا معیارهای DevOps هستند که ایوان به آنها دست یافت:
- تعداد توزیع های ایجاد شده
- سهم توزیع‌هایی که به غرفه آمدند و از غرفه گذشتند
- زمان صرف شده روی پایه (چرخه ایستاده)
- چرخه کامل (کل زمان برای همه جایگاه ها)
- مدت زمان کار
- زمان توقف بین جایگاه ها
- زمان توقف بین راه اندازی کار در همان جایگاه
از یک طرف، معیارها خط لوله DevOps را از نظر زمانی بسیار خوب توصیف می کردند، از طرف دیگر، آنها بسیار ساده در نظر گرفته می شدند.
ایوان که از کار خوب انجام شده راضی بود، یک ارائه ارائه کرد و رفت تا آن را به مدیریت ارائه دهد.
عبوس و با دست های پایین برگشت.
همکار کنایه آمیز لبخند زد: "این یک شکست است، برادر."
ادامه مطلب را در مقاله “'.
منبع: www.habr.com