15 شاخص برای موفقیت عملکرد DevOps

عملکرد DevOps درون سازمان شما چگونه است؟ در این مقاله به 15 شاخص برای موفقیت عملکرد DevOps خواهیم پرداخت. اگر برای سنجش عملکرد آن نیاز به کمک دارید، ما در این مقاله، فهرستی از برخی معیارهای کلیدی DevOps را تهیه کرده‌ایم. این معیارها می‌توانند در درک چگونگی عملکرد تیم شما در طی زمان به‌شما کمک کنند.

تعریف DevOps برای سازمان خود را بیابید

کلمه‌ی DevOps برای افراد مختلف معانی متفاوتی دارد. برخی می‌گویند این یک فرهنگ است و هر تامین‌کننده‌ای در این صنعت ادعا می‌کند که ابزارهای آن‌ها به DevOps کمک می‌کند. بسته به تعریف شما از DevOps، برخی از این معیارها ممکن است کم و بیش برای شما و تیم شما حائز اهمیت باشد. ما DevOps را به‌عنوان هر آنچه که مربوط به استقرار و نظارت بر برنامه‌های شماست، تعریف می‌کنیم. از بسیاری جهات، این امر به مهندسی امنیت سایت منتهی می‌شود.

چالش های DevOps خود را مشخص کنید

قبل از اینکه بدانید کدام یک از معیارهای DevOps نیاز به بررسی دارند، باید مشخص کنید سازمان شما با چه چالش‌هایی مواجه است و قصد حل کدام یک از مشکلات آن‌را دارید؟ 

انواع متریک های DevOps

DevOps به‌طور کلی‌ تحویل همیشه و به‌موقع کد است. شما می‌خواهید سریع به جلو بروید و البته در این سرعت، صدمه‌ای نبیند. با کنترل متریک‌های ‌عملکرد DevOps، می‌توانید برآورد کنید که قبل از شروع اختلال در روند کار، تا چه حد می‌توانید سریع حرکت کنید.

• تعداد دفعات استقرار Deployment frequency
• تغییر میزان حجم کار change volume
• زمان استقرار Deployment time
• زمان بین شروع و اتمام یک فرآیند Lead time
• تیکت‌های مشتری  Customer tickets
• نرخ کنترل خطا Defect escape rate
• تست و ارزیابی نتیجه‌ی خودکار Automated test pass
• توافق‌نامه خدمت یا محصول Service level agreements
• در دسترس بودن Availability
• نرخ خطا Error rates
• استفاده از اپلیکیشن و ترافیک Application usage and traffic
• کارایی اپلیکیشن Application performance
•  استقرار ناموفق  Failed deployments
• میانگین زمان برای تشخیص خطا (Mean time to detection (MTTD
• میانگین زمان ریکاوری (Mean time to recover (MTTR

اهداف DevOps: سرعت ، کیفیت و عملکرد

هدف اصلی DevOps ها کنترل سرعت، کیفیت و کارایی برنامه است. شما اگر می‌خواهید نوشتن کدها را با حداکثر سرعت به‌پایان برسانید، بسته به نوع محصول، تیم و تلورانس ریسک متفاوت خواهد بود.

اگر هیچ یک از متریک‌های DevOps را در سرعت کار خود دنبال نمی‌کنید، بایستی حداقل کیفیت کار خود را بسنجید. شاید شما تلاش می‌کنید تا کدهای باکیفیت بنویسید و به سرعت توجه نمی‌کنید، زیرا خطاهای برنامه آخرین مسئله‌ایست که به‌دنبال آن هستید. سومین تکه از معادله، کارایی است. ممکن است بگویید که این هدف، با سایر اهداف یعنی سرعت بالا و کیفیت مغایرت دارد. عملکرد مرتبط با کیفیت است اما شاید اندکی تفاوت دارد.

اندازه استقرار Deployment Size

یک معیار خوب دیگر DevOps، کنترل تعداد story ها،‌ قابلیت‌ها یا رفع باگ‌هاست. بسته به این که هر یک از task ها، چه مقدار گستردگی دارند، تعداد آن‌ها می‌تواند بسیار متفاوت باشد.‌ شما همچنین می‌توانید پیگیری کنید چه تعداد story point ها یا روز‌های مفید کاری برای انجام task نیاز است.

تعداد دفعات استقرار Deployment frequency

پیگیری تعداد دفعاتی که استقرار برنامه را انجام می‌دهید یکی از معیارهای خوب برای ارزیابی عملکرد DevOps است. در نهایت، هدف این است deployment های کوچک‌تر ولی با تعداد دفعات بیشتری داشته باشید. هر چه deployment های برنامه را به تعداد بیشتری و سایز کوچک‌تری پیاده کنید؛ عملیات تست و release آن راحت‌تر می‌شود.

پیشنهاد ما آن است که شمارش تعداد deployment های محصول و خدمت به‌صورت جداگانه انجام شود. توالی زمانی استقرار deployment در محیط‌های پیش تولید و QA نیز اهمیت دارد. لازم است تا زود به زود استقرار در QA را انجام دهید تا زمان کافی برای تست داشته باشید. یافتن باگ‌ها در QA برای کاستن نرخ انتشار و عیب اهمیت دارد.

زمان استقرار Deployment time

شاید کمی عجیب به‌نظر برسد، ولی پیگیری زمانی که برای یک استقرار واقعی مورد نیاز است، متریک مناسب دیگری است. یکی از برنامه‌های ما  در Stackify با قوانین Azure اجرا شده است و در حدود یک ساعت زمان برای استقرار لازم دارد. این زمان یک کابوس است. پیگیری چنین مواردی می‌تواند به شناسایی مشکلات احتمالی کمک کند. اگر زمان واقعی اجرا سریع و کوتاه باشد، استقرار زود به زود بسیار راحت‌تر است. 

زمان بین شروع و اتمام یک فرآیند Lead time

Lead time یا زمان بین شروع و اتمام یک فرآیند، متریک کلیدی عملکرد DevOps است. این متریک را این چنین تعریف می‌کنیم: زمان بین آغاز یک فرآیند کاری تا استقرار آن. این متریک به‌شما کمک می‌کند تا بدانید که اگر کار بر روی فرآیندی را امروز آغاز کرده‌اید، به صورت میانگین چه مدت زمانی طول می‌کشد تا به محصول نهایی تبدیل شود.

تیکت های مشتری Customer ticket

بهترین و بدترین نشانه از مشکلات برنامه، پشتیبانی درخواست مشتریان و بازخوردها است. قطعاً زیاد تمایلی ندارید که،‌ کاربران باگ‌ها را بیابند و با نرم‌افزار شما مشکل داشته باشند. بنابراین، کاربران هم می‌توانند متریک خوبی در ارزیابی کیفیت و مشکلات عملکرد برنامه شما باشند.

نرخ کنترل خطا Defect escape rate

 آیا می‌دانید چه مقدار خطای نرم‌افزاری در تولید در مقابل QA یافت می‌شود؟ اگر می‌خواهید که برنامه سریعاً استقرار یابد، لازم است تا خطای نرم‌افزار را قبل از تبدیل شدن برنامه به محصول نهایی بیابید.  این متریک DevOps جهت پیگیری خطاهای احتمالی (در بازه زمانی) به هنگام استقرار محصول نهایی استفاده می‌شود.

تست و ارزیابی نتیجه خودکار Automated test pass

برای افزایش سرعت، بسیار توصیه می‌شود که تیم شما از unit تست‌های مختلف و تست عملکردی استفاده کنند. از آنجایی که DevOps ها بسیار وابسته به اتوماسیون هستند، نظارت بر میزان عملکرد تست‌های خودکار از متریک‌های DevOps است. خوب است که بدانید  تغییرات کد در چه بازه زمانی منجر به شکست تست شما می‌شود. 

توافق نامه خدمت یا محصول Service level agreements

هر شرکتی برای خود توافق‌نامه‌هایی برای محصول یا خدمت خود SLA دارد که طبق آن عمل می‌کند. همچنین اهمیت دارد که شما به توافق‌نامه‌های خود پایبند باشید. حتی اگر توافق‌نامه رسمی هم وجود نداشته باشد، نیاز ها و انتظاراتی وجود دارد که باید برآورده کنید.

در دسترس بودن یا Availability

بی شک نمی‌خواهید که برنامه شما به شکست منجر شود. بسته به نوع برنامه شما و نحوه استقرار آن، ممکن است مقداری اتلاف زمان برای downtime داشته باشید . پیشنهاد می‌کنیم این زمان و سایر موارد برنامه ریزی نشده را نیز در زمان‌بندی خود در نظر بگیرید.

نرخ خطا یا Error rates

پیگیری میزان نرخ خطا در برنامه شما اهمیت بالایی دارد. همچنین پیگیری مداوم عملکرد برنامه و مشکلات مرتبط با uptime نیز حائز اهمیت هستند. exception handling best practices مناسب برای یک نرم افزار خوب حیاتی است.

• باگ‌ها: exceptionهایی که در کد شما بعد از استقرار نمایان می‌شود را شناسایی کنید.
• مسائل مربوط به تولید: مسائل مربوط به اتصال به پایگاه داده، query time out و سایر مسائل مربوط را استخراج کنید.

برای بیشتر برنامه‌ها، خطاها یک حقیقت غیر‌قابل اجتناب هستند. در Stackify میلیون‌ها پیغام در ساعت را، در هزاران سرور و بیش از هزار پایگاه‌داده SQL پردازش می‌کنند. اینجا تعداد اندکی خطا وجود دارد و این بخشی از اتفاقات یک سیستم شلوغ است. اهمیت دارد که نرخ خطاها را کنترل کنید و به دنبال رفع موانع باشید.

استفاده از اپلیکیشن و ترافیک Application usage & traffic

پس از استقرار برنامه، می‌خواهید ببینید که میزان تراکنش‌ها یا دسترسی کاربران سیستم شما طبیعی است یا خیر؟ اگر ترافیکی نداشته باشید یا مانع بزرگی در ترافیک وجود نداشته باشد، جایی مشکلی وجود دارد. بدترین حالت این است که هیچ ترافیکی وجود نداشته باشد. چنانچه از میکروسرویس‌ها استفاده می‌کنید ممکن است موانع را در ترافیک ببینید و به‌طور ناگهانی یکی از اپلیکیشن‌های شما ترافیک زیادی را ایجاد کند.

کارایی اپلیکیشن Application performance

قبل از این که استقرار برنامه را انجام دهید، باید از ابزاری مانند Retrace برای جست‌وجوی مشکلات عملکردی، خطاهای پنهان و سایر مسائل استفاده کنید. در طول و بعد از استقرار برنامه، باید هر تغییری را در عملکرد برنامه کنترل کنید. رایج است که پس از استقرار برنامه، تغییرات عمده‌ای را در استفاده از sql queries، web service یا دیگر مسائل مرتبط با برنامه ببینید. ابزارهایی مانند Retrace می‌توانند ارزیابی‌های با ارزشی را مانند آنچه که در شکل زیر ارائه شده است، ارائه نمایند که شناسایی مشکلات را تسهیل می‌کند.

استقرار ناموفق Failed deployments

تمامی ما آرزو داریم که این اتفاق هرگز به‌وقوع نپیوندد. اما هر از چند گاهی، استقرار ناموفق برنامه‌ی شما منجر به ایجاد مشکلات اساسی برای کاربران شما شده است؟ ما هرگز نمی‌خواهیم که درگیر مشکلات rebuild یک برنامه شکست‌خورده باشیم اما همیشه باید برای این حالت برنامه‌ریزی داشته باشیم. چنانچه استقرار ناموفق منجر به مشکلاتی برای شما  ‌شود حتما ً این متریک را در طول زمان درنظر بگیرید. این بررسی می‌تواند تحت عنوان میانگین زمان شکست یا MTTF بررسی شود‌.

میانگین زمان برای تشخیص خطا MTTD) Mean time to detection)

زمانی که مشکلی به‌وقوع می‌پیوندد، اهمیت دارد که سریع مشکل را شناسایی کنید. بی‌شک نمی‌خواهید که مشکل اساسی در سیستم داشته باشید‌ و در خصوص آن ندانید. داشتن اپلیکیشن‌های مانیتورینگ قدرتمند و پوشش‌دهی مناسب جایگاه این ابزار در برنامه به شما در شناسایی سریع مسائل کمک می‌کند. البته به‌محض شناسایی سریع‌، بایستی سریعاً آنان را رفع کنید.

میانگین زمان ریکاوری MTTR) Mean time to recovery)

این متریک کمک می‌کند تا بدانید چقدر زمان لازم است تا پس از شکست، recovery شوید. متریک کلیدی برای کسب‌و‌کار شما این است که از شکست جلوگیری کرده و در صورت شکست به‌سرعت recovery کنید. معمولاً این متریک در مقیاس ساعت hr است و به معنای طول ساعات کاری کسب و کار شما است. داشتن ابزار‌های مناسب مانیتورینگ، برای تشخیص سریع مشکلات و استقرار سریع برنامه جهت کاهش ,MTTR اهمیت زیادی دارد.

متریک های اپلیکیشن

برای مثال در Stackify از متریک‌های مشتری‌ محور برای ردیابی تعداد  log ها که از طریق API در دقیقه می‌رسد، استفاده می‌کنند. این معیار حیاتی کمک می‌کند حجم داده موجود در سیستم را درک کنیم. بسته به برنامه شما، ممکن است متریک‌های مشتری محور مشابهی داشته باشید که برای برنامه شما حیاتی باشد. بعد از استقرار، ممکن است بخواهید تمامی معیارهای حیاتی را تحت نظر بگیرید تا مطمئن شوید همه چیز طبیعی است.

نتیجه گیری

در کل اگر می‌خواهید از DevOps استفاده کنید، مطمئن هستیم که لیست 15 شاخص برای موفقیت عملکرد DevOps که در مقاله شرح دادیم به‌شما ایده‌های خوبی در تعیین چیزی که تمایل به ردیابی یا بهبود آن‌را دارید، خواهد داد. هدف DevOps مشارکت و همکاری و درگیر‌کردن برنامه‌نویسان و توسعه‌دهندگان نرم‌افزار در فرایند استقرار و مانیتورینگ برنامه است. اگر شما برای مانیتور برنامه خود نیازمند کمک هستید، حتماً محصول Retrace را چک کنید.‌