مدتیه که هر وقت آگهی های شغلی به چشمتون می خوره یا سری به لینکدین می زنید، به راحتی می تونید متوجه بشید که درخواست نیروی DevOps خیلی زیادتر شده و به خوبی رو به رشده. اگر از شرح شغلی و لیست مهارت های متنوع شون بگذریم، خوبه که یه دواپس کار و سازمانی که می خواد همچین کسی رو استخدام کنه، بدونه که چه شاخص هایی برای اندازه گیری میزان موفقیت در این حوزه وجود داره.
یک مرکز پژوهشی به نام DevOps Research and Assessment با نام مخفف DORA که اخیرا توسط گوگل هم در اختیار گرفته شده، ۶ ساله که گزارش هایی رو در خصوص وضعیت DevOps در دنیا ارائه میده و تحقیقات نسبتا گسترده ای داشته. فعلا آخرین گزارش در دسترس سال ۲۰۱۹ منتشر شده که اطلاعات جامع و به درد بخوری داره و مرورش رو پیشنهاد می کنم. حوزه های مختلفی وجود داره که می شه درباره شان صحبت کرد ولی در این مقاله می خواهیم به طور خلاصه چند تا شاخص مهم را معرفی کنیم
یه سریا می گن یا باید سرعت رو نگه داریم یا کیفیت رو. جمله هایی مثل «فلانی کیفیت رو فدای سرعت کرده» یا «کارش زیاد طول کشیده ولی در عوض کیفیت داره» و جملات کلیشه ای از این قبیل رو زیاد شنیدیم. اما در این بین، فرهنگ DevOps با اتوماتیک سازی که به نظرم کار اصلیشه، قصد افزایش سرعت و کیفیت همزمان داره و این اتفاق باحال با ابزار ها و تکنولوژی هایی که داریم به خوبی شدنیه. خب بهبود این دو مقوله نیازمند اندازه گیریه و اندازه گیری هم به شاخص نیاز داره. پس در این دو حوزه ی سرعت و کیفیت (پایداری) چه شاخص هایی رو می تونیم داشته باشیم؟
یعنی چند بار در ماه (یا بازه ی زمانی دلخواه) سرویس ها رو بدون خطا و درست (بدون Down Time یا پایین اومدن سرویس) دیپلوی یا منتشر می کنیم. هر چه قدر این نرخ بالاتر باشه، یعنی رساندن فیچر و رفع مشکلات و ... و به معنای کلی انتقال ارزش به مشتریان سریع تر صورت می گیره. از طرفی برای تیم فنی این مزیت رو داره که یک یا چند فیچر بزرگ رو به قطعات کوچک تری تقسیم کنند و هر وقت تموم شد منتشر کنن. این امر چند تا مزیت داره از جمله رفع مشکلات سریع تر انجام می شه و باگ کمتر پیش میاد و همچنین از طرفی چابک بودن تیم حفظ می شه. رویکرد آبشاری در مقابل رویکرد چابک نیازمند زمان زیادی از ایده پردازی و پیاده سازی تا انتشار داشت ولی با پیاده سازی DevOps این زمان کاهش پیدا می کنه و می توانیم مدام در حال تغییر و ارزش آفرینی برای مشتریان و بهتر کردن محصول مون باشیم. اگر روی پروژه هایی کار می کنید که جرئت دست زدن به سرویس و آپدیت اش رو ندارید و انصافا هر دیپلوی براتون نفس گیره، مقدار این شاخص به شدت بالاست و در چنان وضعیت بدی قرار دارید که به نظرم خدا نصیب گرگ بیابون نکنه (طفلی برنامه نویسا و ادمین سیستم شون!)
چقدر طول می کشه تا کد کامیت شده روی پروژه به سرور های اصلی و نهایتا محصول در دست مشتریان برسه. حتی اگر CI/CD رو هم پیاده سازی کرده باشید ولی چندین ساعت طول می کشه تا کد ها به سرور اصلی برسن، خب پس چرا اصلا اینهمه زحمت کشیدیم! مثل قدیما همون دستی دیپلوی کنیم خوشحال تریم... (خسته نباشی دلاور، خدا قوت پهلوان!)
راه های زیادی وجود داره تا فرایند دیپلوی و بازنشانی خودکار سرویس هامون رو بهینه تر و پرسرعت تر کنیم. مثلا فرایند های سنگین بیلد گرفتن و اجرای تست رو روی کلود یا سرور هایی جداگانه و مناسب انجام بدیم و روی سرور اصلی لبه اجراشون نکنیم، راه اندازی داکر رجیستری و داکرایز کردن سرویس ها تا از کلی امکانات از جمله multi stage build و base image و غیره استفاده کنیم. کلی قدم می شه ورداشت و مسلما از نتایج هر قدم شگفت زده خواهیم شد. اینطوری می شیم یه دواپس کار خفن!
اگر هر وقت برنامه نویسا و تیم توسعه باید قبل از پوش کردن روی master یا برنچ اصلی بهمون اطلاع بدن، همیشه برای هر دیپلوی اتوماتیک CI/CD روی سرور اصلی دستامون از شدت استرس عرق کنه و بعد از پایان فرایند CI/CD باید مدام این ور و اون ور سرور خرده کاری کنید تا سرویس درست کار کنه و ... این شاخص برامون به شدت بالاست و اوضاع خوب نیست. بالا بودن این شاخص نمایانگر اینه که کیفیت و پایداری سیستم پایینه و البته روی تعداد دیپلوی ها و سرعت مون هم تاثیر منفی داره. باید تا جایی که می توانید خیالتون از دیپلوی اتوماتیک راحت باشه مثلا قبل از دیپلوی روی سرور اصلی تست های Integration و Unit test و سایر تست ها اجرا بشن تا دیپلوی ناموفق نداشته باشیم یا کمتر باشه و همچنین تا آخر کار دیپلوی، به درستی و بدون خطا CI/CD رو پیاده سازی کنیم.
ناگهان متوجه می شویم که آخرین کامیت و تغییراتی که روی سرور اصلی اعمال شده دچار مشکله و در وضعیت اورژانسی هستیم. باید سریع بتوانیم به وضعیت پایدار قبلی برگردیم یا مشکل رو حل کنیم (این وسط باید یادمون باشه که در این شرایط تست رو به بهانه ی وضعیت اضطراری نادیده نگیریم) به هر حال تا جای ممکن باید زمان بازگشت به وضعیت پایدار رو پایین بیاریم تا کیفیت و پایداری سیستم بهبود پیدا کنه. اقداماتی همچون versioning باید به صورت پایه ای رعایت بشه و برای پکیج های قابل اجرا از نرم افزار هامون یه پایگاه رجیستری جامع و در دسترس داشته باشیم. از امکانات پیش فرض ابزار های CI/CD هم میشه استفاده کرد مثل Environment در Gitlab CI که خیلی جالبه. در ضمن، بالا بودن شاخص «زمان شروع تا اتمام فرایند هر تغییر» روی این شاخص تاثیر مستقیم می ذاره.
بررسی و مرور شاخص ها تمام شد ولی خیلی از سوالات مان باقی ماند مثل: چجوری اینا رو اندازه گیری و مانیتور کنیم؟ برای بهبود هر کدوم از این شاخص ها به تفصیل چه راهکار ها و ابزار هایی رو در دسترس داریم؟ آیا شاخص های دیگری هم هست؟ یک سازمان چگونه می تواند در این مسیر حرکت کند و چه الزامات و پیش نیاز هایی برای طراحی مسیر راه و بهبود این شاخص ها وجود دارد؟ و .... دوست دارم آروم آروم به هر کدام از این ها بپردازیم.
کار مهندسی دواپس، یه کار بزن در رو نیست بلکه باید به طور مداوم رشد و بهبود پیدا کنه و با تکنولوژی های جدید هماهنگ و سازگار بشه
منبع
ممنونم که تا اینجا اومدید. پذیرای فیدبک هاتون هستم Happy Devopsing :)
