عملکرد DevOps درون سازمان شما چگونه است؟ در این مقاله به ۱۵ شاخص برای موفقیت عملکرد DevOps خواهیم پرداخت. اگر برای سنجش عملکرد آن نیاز به کمک دارید، ما در این مقاله، فهرستی از برخی معیارهای کلیدی DevOps را تهیه کردهایم. این معیارها میتوانند در درک چگونگی عملکرد تیم شما در طی زمان بهشما کمک کنند.
کلمهی DevOps برای افراد مختلف معانی متفاوتی دارد. برخی میگویند این یک فرهنگ است و هر تامینکنندهای در این صنعت ادعا میکند که ابزارهای آنها به DevOps کمک میکند. بسته به تعریف شما از DevOps، برخی از این معیارها ممکن است کم و بیش برای شما و تیم شما حائز اهمیت باشد. ما DevOps را بهعنوان هر آنچه که مربوط به استقرار و نظارت بر برنامههای شماست، تعریف میکنیم. از بسیاری جهات، این امر به مهندسی امنیت سایت منتهی میشود.
قبل از اینکه بدانید کدام یک از معیارهای DevOps نیاز به بررسی دارند، باید مشخص کنید سازمان شما با چه چالشهایی مواجه است و قصد حل کدام یک از مشکلات آنرا دارید؟
DevOps بهطور کلی تحویل همیشه و بهموقع کد است. شما میخواهید سریع به جلو بروید و البته در این سرعت، صدمهای نبیند. با کنترل متریکهای عملکرد DevOps، میتوانید برآورد کنید که قبل از شروع اختلال در روند کار، تا چه حد میتوانید سریع حرکت کنید.
هدف اصلی DevOps ها کنترل سرعت، کیفیت و کارایی برنامه است. شما اگر میخواهید نوشتن کدها را با حداکثر سرعت بهپایان برسانید، بسته به نوع محصول، تیم و تلورانس ریسک متفاوت خواهد بود.
اگر هیچ یک از متریکهای DevOps را در سرعت کار خود دنبال نمیکنید، بایستی حداقل کیفیت کار خود را بسنجید. شاید شما تلاش میکنید تا کدهای باکیفیت بنویسید و به سرعت توجه نمیکنید، زیرا خطاهای برنامه آخرین مسئلهایست که بهدنبال آن هستید. سومین تکه از معادله، کارایی است. ممکن است بگویید که این هدف، با سایر اهداف یعنی سرعت بالا و کیفیت مغایرت دارد. عملکرد مرتبط با کیفیت است اما شاید اندکی تفاوت دارد.
یک معیار خوب دیگر DevOps، کنترل تعداد story ها، قابلیتها یا رفع باگهاست. بسته به این که هر یک از task ها، چه مقدار گستردگی دارند، تعداد آنها میتواند بسیار متفاوت باشد. شما همچنین میتوانید پیگیری کنید چه تعداد story point ها یا روزهای مفید کاری برای انجام task نیاز است.
پیگیری تعداد دفعاتی که استقرار برنامه را انجام میدهید یکی از معیارهای خوب برای ارزیابی عملکرد DevOps است. در نهایت، هدف این است deployment های کوچکتر ولی با تعداد دفعات بیشتری داشته باشید. هر چه deployment های برنامه را به تعداد بیشتری و سایز کوچکتری پیاده کنید؛ عملیات تست و release آن راحتتر میشود.
پیشنهاد ما آن است که شمارش تعداد deployment های محصول و خدمت بهصورت جداگانه انجام شود. توالی زمانی استقرار deployment در محیطهای پیش تولید و QA نیز اهمیت دارد. لازم است تا زود به زود استقرار در QA را انجام دهید تا زمان کافی برای تست داشته باشید. یافتن باگها در QA برای کاستن نرخ انتشار و عیب اهمیت دارد.
شاید کمی عجیب بهنظر برسد، ولی پیگیری زمانی که برای یک استقرار واقعی مورد نیاز است، متریک مناسب دیگری است. یکی از برنامههای ما در Stackify با قوانین Azure اجرا شده است و در حدود یک ساعت زمان برای استقرار لازم دارد. این زمان یک کابوس است. پیگیری چنین مواردی میتواند به شناسایی مشکلات احتمالی کمک کند. اگر زمان واقعی اجرا سریع و کوتاه باشد، استقرار زود به زود بسیار راحتتر است.
Lead time یا زمان بین شروع و اتمام یک فرآیند، متریک کلیدی عملکرد DevOps است. این متریک را این چنین تعریف میکنیم: زمان بین آغاز یک فرآیند کاری تا استقرار آن. این متریک بهشما کمک میکند تا بدانید که اگر کار بر روی فرآیندی را امروز آغاز کردهاید، به صورت میانگین چه مدت زمانی طول میکشد تا به محصول نهایی تبدیل شود.
بهترین و بدترین نشانه از مشکلات برنامه، پشتیبانی درخواست مشتریان و بازخوردها است. قطعاً زیاد تمایلی ندارید که، کاربران باگها را بیابند و با نرمافزار شما مشکل داشته باشند. بنابراین، کاربران هم میتوانند متریک خوبی در ارزیابی کیفیت و مشکلات عملکرد برنامه شما باشند.
آیا میدانید چه مقدار خطای نرمافزاری در تولید در مقابل QA یافت میشود؟ اگر میخواهید که برنامه سریعاً استقرار یابد، لازم است تا خطای نرمافزار را قبل از تبدیل شدن برنامه به محصول نهایی بیابید. این متریک DevOps جهت پیگیری خطاهای احتمالی (در بازه زمانی) به هنگام استقرار محصول نهایی استفاده میشود.
برای افزایش سرعت، بسیار توصیه میشود که تیم شما از unit تستهای مختلف و تست عملکردی استفاده کنند. از آنجایی که DevOps ها بسیار وابسته به اتوماسیون هستند، نظارت بر میزان عملکرد تستهای خودکار از متریکهای DevOps است. خوب است که بدانید تغییرات کد در چه بازه زمانی منجر به شکست تست شما میشود.
هر شرکتی برای خود توافقنامههایی برای محصول یا خدمت خود SLA دارد که طبق آن عمل میکند. همچنین اهمیت دارد که شما به توافقنامههای خود پایبند باشید. حتی اگر توافقنامه رسمی هم وجود نداشته باشد، نیاز ها و انتظاراتی وجود دارد که باید برآورده کنید.
بی شک نمیخواهید که برنامه شما به شکست منجر شود. بسته به نوع برنامه شما و نحوه استقرار آن، ممکن است مقداری اتلاف زمان برای downtime داشته باشید . پیشنهاد میکنیم این زمان و سایر موارد برنامه ریزی نشده را نیز در زمانبندی خود در نظر بگیرید.
پیگیری میزان نرخ خطا در برنامه شما اهمیت بالایی دارد. همچنین پیگیری مداوم عملکرد برنامه و مشکلات مرتبط با uptime نیز حائز اهمیت هستند. exception handling best practices مناسب برای یک نرم افزار خوب حیاتی است.
برای بیشتر برنامهها، خطاها یک حقیقت غیرقابل اجتناب هستند. در Stackify میلیونها پیغام در ساعت را، در هزاران سرور و بیش از هزار پایگاهداده SQL پردازش میکنند. اینجا تعداد اندکی خطا وجود دارد و این بخشی از اتفاقات یک سیستم شلوغ است. اهمیت دارد که نرخ خطاها را کنترل کنید و به دنبال رفع موانع باشید.
پس از استقرار برنامه، میخواهید ببینید که میزان تراکنشها یا دسترسی کاربران سیستم شما طبیعی است یا خیر؟ اگر ترافیکی نداشته باشید یا مانع بزرگی در ترافیک وجود نداشته باشد، جایی مشکلی وجود دارد. بدترین حالت این است که هیچ ترافیکی وجود نداشته باشد. چنانچه از میکروسرویسها استفاده میکنید ممکن است موانع را در ترافیک ببینید و بهطور ناگهانی یکی از اپلیکیشنهای شما ترافیک زیادی را ایجاد کند.
قبل از این که استقرار برنامه را انجام دهید، باید از ابزاری مانند Retrace برای جستوجوی مشکلات عملکردی، خطاهای پنهان و سایر مسائل استفاده کنید. در طول و بعد از استقرار برنامه، باید هر تغییری را در عملکرد برنامه کنترل کنید. رایج است که پس از استقرار برنامه، تغییرات عمدهای را در استفاده از sql queries، web service یا دیگر مسائل مرتبط با برنامه ببینید. ابزارهایی مانند Retrace میتوانند ارزیابیهای با ارزشی را مانند آنچه که در شکل زیر ارائه شده است، ارائه نمایند که شناسایی مشکلات را تسهیل میکند.
تمامی ما آرزو داریم که این اتفاق هرگز بهوقوع نپیوندد. اما هر از چند گاهی، استقرار ناموفق برنامهی شما منجر به ایجاد مشکلات اساسی برای کاربران شما شده است؟ ما هرگز نمیخواهیم که درگیر مشکلات rebuild یک برنامه شکستخورده باشیم اما همیشه باید برای این حالت برنامهریزی داشته باشیم. چنانچه استقرار ناموفق منجر به مشکلاتی برای شما شود حتما ً این متریک را در طول زمان درنظر بگیرید. این بررسی میتواند تحت عنوان میانگین زمان شکست یا MTTF بررسی شود.
زمانی که مشکلی بهوقوع میپیوندد، اهمیت دارد که سریع مشکل را شناسایی کنید. بیشک نمیخواهید که مشکل اساسی در سیستم داشته باشید و در خصوص آن ندانید. داشتن اپلیکیشنهای مانیتورینگ قدرتمند و پوششدهی مناسب جایگاه این ابزار در برنامه به شما در شناسایی سریع مسائل کمک میکند. البته بهمحض شناسایی سریع، بایستی سریعاً آنان را رفع کنید.
این متریک کمک میکند تا بدانید چقدر زمان لازم است تا پس از شکست، recovery شوید. متریک کلیدی برای کسبوکار شما این است که از شکست جلوگیری کرده و در صورت شکست بهسرعت recovery کنید. معمولاً این متریک در مقیاس ساعت hr است و به معنای طول ساعات کاری کسب و کار شما است. داشتن ابزارهای مناسب مانیتورینگ، برای تشخیص سریع مشکلات و استقرار سریع برنامه جهت کاهش ,MTTR اهمیت زیادی دارد.
برای مثال در Stackify از متریکهای مشتری محور برای ردیابی تعداد log ها که از طریق API در دقیقه میرسد، استفاده میکنند. این معیار حیاتی کمک میکند حجم داده موجود در سیستم را درک کنیم. بسته به برنامه شما، ممکن است متریکهای مشتری محور مشابهی داشته باشید که برای برنامه شما حیاتی باشد. بعد از استقرار، ممکن است بخواهید تمامی معیارهای حیاتی را تحت نظر بگیرید تا مطمئن شوید همه چیز طبیعی است.
در کل اگر میخواهید از DevOps استفاده کنید، مطمئن هستیم که لیست ۱۵ شاخص برای موفقیت عملکرد DevOps که در مقاله شرح دادیم بهشما ایدههای خوبی در تعیین چیزی که تمایل به ردیابی یا بهبود آنرا دارید، خواهد داد. هدف DevOps مشارکت و همکاری و درگیرکردن برنامهنویسان و توسعهدهندگان نرمافزار در فرایند استقرار و مانیتورینگ برنامه است. اگر شما برای مانیتور برنامه خود نیازمند کمک هستید، حتماً محصول Retrace را چک کنید.
سینداد یعنی هدیهی سیمرغ، یا فرزند سیمرغ؛ به عبارتی یعنی خود سیمرغ، با همه ی شگفتی هایش، اما جوانتر و سرزنده تر. و این چیزی است که ما سعی می کنیم در سینداد باشیم. از سال ۱۳۸۵ دانش مان را به صورت خدماتی در حوزه ی هاستینگ، شبکه و تولید نرم افزار در اختیار مشتریان مان قرار داده ایم و به این افتخار می کنیم که تک تک آنها تا به امروز همراه ما مانده اند. باور داریم که سینداد صرفاً یک شرکت نیست، بلکه نوعی باور است به ارائه ی شگفت انگیز از هر چیز.
