چهار معیار اصلی DevOps یک مجموعه اندازه گیری هیجان انگیز است. از زمان انتشار کتاب تسریع سرعت آنها بیشتر و بیشتر مورد توجه قرار می گیرد. من کاملاً معتقدم که آنها برای تیم های مهندسی که به دنبال اثربخشی و کارایی هستند ، ضروری هستند.
چهار معیار اصلی DevOps عبارتند از:
- زمان منجر به تغییر
- استفاده از فرکانس
- نرخ شکست را تغییر دهید
- زمان متوسط برای بازیابی (MTTR)
درباره اندازه گیری آن می توانید در مقاله پاول دوال یا خواندن وضعیت تسریع در DevOps 2019 بیشتر بدانید.
در این مقاله ، من می خواهم کشف کنم که چرا آنها را دوست دارم و چرا ما آن را در Source Source کمی متفاوت اندازه می گیریم. من بر روی زمان منجر به تغییر و استفاده از فرکانس تمرکز خواهم کرد ، زیرا تجربه بیشتری در کار با آنها دارم.
چهار معیار اصلی DevOps برای تیم های مهندسی
هدف اصلی یک تیم مهندسی افزودن ارزش برای مشتریان از طریق فناوری است. ارائه ارزش انتزاعی است و توصیف معنای آن سخت است.
بعضی اوقات مقدار به یک خط کد یا حتی در تغییر پیکربندی تبدیل می شود. اما در مواقع دیگر ، ارزش به سه ماه کار 8 تیمی تبدیل می شود. این اتفاق می افتد زیرا ادراک ارزش به خود اثر وابسته نیست. این به آنچه کاربران نهایی از محصول در حال اجرا استخراج می کنند ، محدود است.
به همین دلیل اندازه گیری Story Points بی فایده است. این تیم براساس مقدار تلاش یک داستان کاربر یا کار مشخص ، یک مقدار عددی نسبت می دهد. بنابراین ، Story Points عملکرد مهندسی را بر اساس تلاش آنها اندازه گیری می کند. و همانطور که بیان شد ، با درک کاربر نهایی از مقدار ارتباط ندارد.
با این حال ، توسعه نرم افزار مدرن به چابکی نیاز دارد و از طبیعت کار ، از جمله ویژگی های دردناک یا اشکالات لغزنده ناشی نمی شود. چابکی از روندی صاف و پایدار حاصل می شود.
چند سال پیش ، استفاده از چابکی و روند کار در یک جمله خنده دار خواهد بود. اما هسته اصلی چابک پاسخ مناسب به تغییر است ، و تحقق بیشتر با کار کمتر نتیجه است و نه هدف.
با این وجود ، معیارهای چهار Key DevOps به بهترین متحدان Tech Leads ، مدیران مهندسی و VP های مهندسی تبدیل می شوند که به دنبال کارایی هستند. این نقش ها نیاز به توجه کامل به تصویر کلان دارند و معیارهای DevOps نمای کاملی از نحوه پاسخگویی سیستم به فعالیتهای روزانه دارند.
زمان منجر به تغییر و استفاده از فرکانس خط لوله توسعه را خلاصه می کند و هرگونه تغییر در روند کار منعکس کننده آنهاست. مدیران باید آنها را در داشبورد یا هر مکان قابل دسترسی و دقیق دیگری داشته باشند.
ملاحظات در مورد زمان سرب برای تغییر
Lead Time for Change مقدار زمان لازم برای دستیابی به تغییر کد را برای تولید اندازه گیری می کند. اندازه گیری برای تولید بسیار مهم است زیرا صحنه سازی یا هر محیط غیر رسمی دیگری هیچ ارزشی را ارائه نمی دهد.
با این حال ، بحث جالبی در مورد ضامن های ویژگی (یا پرچم های ویژگی) مطرح می کند. اگر تیم شما از ضامن ویژگی یا پرچم ویژگی استفاده کند ، استفاده از ویژگی جدید مرحله آخر زنجیره ارزش نیست. ویژگی ها باید برای افزودن ارزش فعال شوند ، بنابراین ، من اندازه گیری نه تنها زمان سرب برای تغییر بلکه زمان سرب برای مقدار را نیز در نظر می گیرم.
جنبه دیگری که می خواهم به آن اشاره کنم ، آمار است. توصیه این است که زمان متوسط تغییر را محاسبه کنید. این مقدار را در نقطه میانی توزیع فرکانس تولید می کند. به عبارت دیگر ، نیمی از تغییرات برابر یا کمتر از حد متوسط هستند. اما در مورد نیمه دیگر تغییرات چطور؟ آنها می توانند به میزان قابل توجهی بیشتر مصرف کنند.
در SourceLevel ، احتمالاً ما از صدک 75 به عنوان معیار پیش فرض و صدک 95 نیز پیگیری کرده ایم. صدک 75 جامع تر و واقع بینانه تر است. در مقابل ، صدک 95 به ما ایده کوچکی از کار خارج شده از شمارش را می دهد و 5٪ بالاترین تغییرات وقت گیر را حذف می کند ، زیرا آنها را بیش از حد می دانیم.
ملاحظات مربوط به فراوانی استقرار
فرکانس استقرار چند بار تغییر کد در یک دوره را اندازه گیری می کند. می تواند به صورت استقرار در ساعت ، روز ، هفته ، ماه و غیره اندازه گیری شود.
بسیار مهم است که دوره را به درستی تنظیم کنید. گفتن اینکه تیم در ماه چهار بار اعزام می شود ، به نظر می رسد تیم در هفته یک بار اعزام می شود. اما ممکن است دقیق نباشد. اگر تیم در پایان یک ماه چهار بار اعزام شود ، این بدان معنی است که تیم سرعت متفاوتی نسبت به اعزام یک بار در هفته دارد.
اگر معمولاً تیم شما یک یا صفر در روز اعزام دارد ، آن را در روز اندازه گیری نکنید. چند هفته اندازه گیری را شروع کنید. هنگامی که تیم بیش از هفت بار در هفته استقرار خود را آغاز کرد ، می توانید روزها جابجا شوید. هر زمان که ممکن است به بازه های زمانی کوتاه تر بروید ، اما همیشه به صحت اطلاعات احترام بگذارید.
به اختصار
چهار معیار اصلی DevOps مفید هستند و ایده کلی در مورد نحوه پاسخگویی سیستم به فعالیتهای روزمره ارائه می دهند. زمان سرب برای تغییر و استفاده از فرکانس بسیار بیشتر از Story Points است و باید در دسترس و دقیق باشد.
Tech Leads ، مدیران مهندسی و VP مهندسی از این معیارها بهره می برند. اگرچه معیارهای بیشتری برای بررسی مشکلات لازم است ، اما شاخص های بسیار خوبی برای سلامت فرآیند مهندسی هستند.
(سلب مسئولیت: نویسنده یکی از بنیانگذاران SourceLevel است)
برچسب ها
حساب رایگان خود را ایجاد کنید تا قفل تجربه خواندن سفارشی خود را باز کنید.