ارزیابی میزان موفقیت عملکرد DevOps با DevOps KPI

The four dimensions of DevOps metrics

مدیریت DevOps با استفاده از معیارهای ارزیابی

امروزه و در عصر DevOps، پیوسته لازم است که شاخص های کلیدی عملکرد (KPI) را ارزیابی کنید تا میزان موفقیت DevOps مشخص شده و امکان تغییرات بیشتر فراهم شود.

DevOps بدون tradeoff

DevOps در اصل از طریق جنبش چابک (Agile Movement) رشد پیدا کرد و در واقع راهکاری برای افزایش سرعت ارائه نرم افزار توسط تیم های توسعه نرم افزار به مشتریان است. در حال حاضر DevOps دربرگیرنده همه بخش های فرایند ارائه نرم افزار است از برنامه ریزی گرفته تا ایمن سازی، نظارت و بروز رسانی اپلیکیشنی که از قبل تولید شده است.

امروزه، DevOps به طور گسترده برای build، تست و ارائه نرم افزار توسط کسب و کارهای مختلف پذیرفته شده است. در این دنیای رقابتی، پرتحرک و همیشه متصل، DevOps شرکت ها را قادر ساخته که از طریق از بین بردن سیلوهای توسعه (Dev) و عملیات (Operation)، با خواسته ی کاربران در مورد تحویل و ارائه سریع همگام شوند.software was a key enabler for the business

این شرایط اهمیت کیفیت نسبت به گذشته را دوچندان کرده است؛ در نتیجه کسب و کارها نمی توانند صرفا برای ارائه سریع نرم افزار به بازار، کیفیت را نادیده بگیرند. با ارائه ی یک اپلیکیشن با عملکرد ضعیف در یک فروشگاه اپلیکیشنی (app store) که کاربران نظرات منفی زیادی در آن درج می کنند، به سرعت می توان شهرت و خوشنامی یک برند را از بین برد. با استفاده از DevOps، بهینه سازی کارها در جهت افزایش سرعت، همزمان با حفظ کیفیت و کاهش خطرها قابل انجام است. Batchهای کوچک، سریع تر ارائه شده و به صورت ذاتی مشکلات مربوط به کیفیت و امنیت را کاهش می دهد.

افزایش سرعت در توسعه نرم افزار به روش سنتی، اغلب اوقات باعث کاهش کیفیت و افزایش آسیب پذیری می شود.   همچنین در روش های سنتی افزایش سرعت، کیفیت و امنیت عاملی برای افزایش هزینه ها محسوب می شود. اما ابتکارات DevOps می تواند واقعا منجر به بهبود در تمام این چهار بُعد شود: سرعت، کیفیت، بهره‌وری و امنیت. کلید کار اتخاذ چارچوبی برای معیارها است که مشخص کند چه جاهایی در حال پیشرفت هستید و چه جاهایی هنوز نیاز به بهبود دارید.

DevOps without trradeoffs

وجود معیارهای ارزیابی ضروری است

اکثر سازمان ها DevOps را به دلیل یک نیاز بیزینسی خاص مثل بهبود زمان بازاریابی، کاهش نقایص یا تراز کردن بهتر ابتکارات IT با استراتژی بیزینسی پیاده سازی می کنند. اما از آنجا که DevOps هیچ فریم ورک رسمی ندارد، روش های زیادی برای ارزیابی موفقیت DevOps وجود ندارد، در حالیکه این ارزیابی حیاتی است. از آنجا که خیلی از سازمان ها DevOps را به صورت تدریجی پیاده سازی می کنند – اول در یک پروژه و بعد آرام آرام آن را در سراسر سازمان گسترش می دهند – چند پروژه اول باید موفقیت آمیز باشند؛ طوریکه بتوانند پشتیبانی انحصاری برای DevOps ایجاد کنند. همانطور که مشتریان ما به ما گفته اند: “هر چیزی که ارزیابی شود، بهبود پیدا می کند.”

"people issues" were the biggest challenge to adopting DevOps

وجود معیارهایی که نشان دهنده موفقیت آمیز بودن یک آزمایش باشند، می تواند به غلبه بر مقاومت های داخلی در برابر پذیرش DevOps کمک کند. یکی از نظرسنجی های شرکت Gartner از مدیران مشاغل2 و  بخش IT مشخص کرد که “people issue” (موارد مربوط به افراد) بزرگترین چالشی است که سازمان ها در پذیرش DevOps با آن روبرو هستند و 43 درصد پاسخ دهندگان مقاومت در برابر تغیرات را بزرگترین مانع دانسته اند. از آنجا که DevOps نیاز به تحول فرهنگی و تغییرات فرایند و فناوری دارد، وجود پشتیبانی و حمایت انحصاری از آن ضروری است.

بعلاوه، DevOps به عنوان یک سیر تکاملی شناخته شده است که نیاز به بهبود مستمر (Continuous Improvement) دارد. اما اگر نتایج را ارزیابی نکنید، متوجه نمی شوید که DevOps را چطور درون سازمانتان تکامل دهید.

ارزیابی در مسیر تکامل DevOps بسیار ضروری و حیاتی است. اما چطور می توان موفقیت DevOps را ارزیابی کرد؟ چه چیزی باعث عملکرد فوق العاده‌ی یک سازمان می شود؟ کدام شاخص های کلیدی عملکرد (KPI) این قابلیت را دارند که مشخص کنند چه چیزی برای شما خوب کار می کند و چه چیزی خیر – و اطلاعاتی برای توضیح علت (علت کار نکردن بعضی روش ها) فراهم کنند؟ چه چیزهایی را ارزیابی می کنید، چطور آن ها را ارزیابی می کنید و این اعداد دقیقا چه چیزی را نشان می دهند؟

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

DevOps metrics are essential

معیارهای ارزیابی DevOps در چهار بعد

برای تعیین بهترین شاخص های کلیدی عملکرد (KPI) جهت ارزیابی DevOps، شرکت Hewlett Packard Enterprise Software Services (به اختصار HPE) در ابتدا بزرگترین چالش های ارائه نرم افزار را که مشتریان گزارش شده بود را بررسی کرده است:

  1. کند بودن زمان عرضه به بازار  | Slow time to market
  2. ایجاد تجربیات ضعیف برای کاربران | Poor user experience
  3. هزینه های بالا | High cost
  4. پیش پینی پذیری ضعیف  | Poor predictability
  5. آسیب پذیری و ریسک  | Vulnerabilities and risk

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

شرکت HPE ریشه این مشکلات را چهار حوزه متفاوت می داند:

  1. سرعت | Velocity
  2. کیفیت | Quality
  3. بهره‌وری | Productivity
  4. امنیت | Security

DevOps می تواند تمام این چهار مورد را بدون از دست رفتن هیچکدام برآورده کند. موفقیت در هر یک از این چهار حوزه می تواند زمان عرضه به بازار، تجربیات کاربر، هزینه، پیش بینی پذیری و امنیت را کاملاً بهبود ببخشد.

شرکت HPE، رهبری تعریف معیارهایی که شرکت های امروزی باید ارزیابی و نظارت کنند را بر عهده گرفته است. بعضی از بزرگترین مشتریان DevOps در حال حاضر این فریم ورک را قبول و پیاده سازی کرده‌اند.

سرعت (Velocity) : نرخ ارائه تغییرات نرم افزاری توسط یک سازمان را ارزیابی می کند.
کیفیت (Quality) : ارزیابی می کند که تغییرات نرم افزاری ارائه شده چقدر نیازهای کسب و کار را برآورده و در جهت رضایت عمل می کنند.
بهره وری (Productivity) : ظرفیت و کارایی یک سازمان در تحویل تغییرات نرم افزاری را ارزیابی می کند.
امنیت (Security) : آسیب پذیری هایی که هنگام تحویل تغییرات نرم افزاری نمایان می شوند را ارزیابی می کند.

سرعت، کیفیت، بهره وری و امنیت به یکدیگر وابسته اند. بهبود یک حوزه منجر به بهبود در سه حوزه دیگر می شود بدون این که نیازی به tradeoff باشد.

The four dimensions of DevOps metrics

velocity iconچرا اندازه گیری و ارزیابی سرعت مهم است؟

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

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

سرعت زیاد در تحویل نرم افزار، علاوه بر ایجاد مزیت رقابتی برای شرکت، نحوه تعامل کسب و کار با بخش IT را هم بهبود می بخشد.

quality iconچرا اندازه گیری و ارزیابی کیفیت مهم است؟

طبق نظرسنجی ای1 که شرکت Forrester Consulting از تصمیم گیرندگان IT امریکایی و اروپایی انجام داده است، 78 درصد از پاسخ دهندگان بهبود کیفیت را یکی از خواسته های اصلی گروه های بیزینسی اعلام کرده اند.

با DevOps نیازی به قربانی کردن کیفیت برای رسیدن به سرعت بیشتر نیست. برای افزایش سرعت می توانید ارائه نرم افزار را به واحدهای کوچکتری تقسیم کنید، به طوریکه در واقع تعدادی micro service با وابستگی حداقلی یا بدون هیچ وابستگی ارائه خواهید کرد. unitهای کوچکتر یعنی تحویل سریع تر به همراه کیفیت بالاتر و ریسک کمتر.

بعلاوه DevOps از طریق ایجاد فرهنگی برتر و ابزارهایی برای پشتیبانی از آن، کیفیت را وارد تمامی مراحل زنجیره ارائه نرم افزار می کند.
از نظر فرهنگی، DevOps بر مسئولیت های مشترک، انتظار کیفیت از توسعه دهندگان، تست کنندگان، اعضای تیم امنیت و عملیات و همه افراد بین آن ها تاکید دارد. از نظر تکنیکی، DevOps مستلزم حداکثر میزان ممکن اتوماسیون برای سرعت بخشیدن به فرایندها و کاهش خطاهای انسانی است. و استفاده از یک رویکرد Shift-left در تست، امنیت و مانیتورینگ به بهبود کیفیت کمک می کند.

shift left testing رویکردی در تست نرم افزار یا سیستم است که بر انجام تست در مراحل اولیه چرخه حیات تاکید دارد (moved left on project timeline). این نیمه اول قاعده کلی تست نرم افزار است: “تست زودتر و پر تکرار” (Test Early and Often)

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

productivity iconچرا اندازه گیری و ارزیابی بهره وری مهم است؟

همه ی هدف و تمرکز DevOps این است که به سازمان های فناوری اطلاعات کمک کند تا ارزش بیشتری برای بیزینس ایجاد کند. اما در صورتیکه تلاش های شما بخوبی با بیزینس هماهنگ نشده باشد، هر چقدر هم سریع بتوانید نرم افزارهایی با کیفیت عرضه کنید، این امر (ایجاد ارزش برای بیزینس) میسر نمی شود.

در صورتیکه DevOps درست اعمال شود، سازمان ها شاهد افزایش سرعت و کیفیت بدون افزایش هزینه ها خواهند بود. در حقیقت با کوتاه کردن چرخه ها، شما شاهد افزایش ارزش های کسب و کاری خواهید بود. ارزیابی و نظارت بر معیارهای بهره وری، یک چرخه‌ی بازخورد (feedback loop) برای بخش IT ایجاد می کند. بدین ترتیب تمرکز خود را بر ایجاد ویژگی هایی که مورد استفاده کاربران است می گذارید و در نتیجه اتلاف منابع کمتر صورت می گیرد و و ارزش بیزینسی افزایش می یابد.

security iconچرا اندازه گیری و ارزیابی امنیت مهم است؟

سرعت اهمیت زیادی در DevOps دارد اما در دنیای امروزی، اهمیت امنیت هم به همین اندازه زیاد است. تیم ها باید اطمینان داشته باشند که حین عملیات، باعث آسیب پذیر شدن سیستم نمی شوند.

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

امنیت هم مثل کیفیت به رویکردهای تست  shift-left نیاز دارد که با استفاده از این رویکرد مشخص کردن زود هنگام آسیب پذیری ها با هزینه های کمتر (هم از نظر زمانی هم از نظر هزینه های مالی) قابل انجام است. وقتی که تست shift-left را انجام دهید، تست امنیت در ابتدای چرخه توسعه انجام می شود. ارزیابی زود هنگام آسیب پذیری های امنیتی این اطمینان را ایجاد می کند که تولیدات قبل از این که به مرحله بعدی خط انتشار وارد شوند، پایدار و باثبات می شوند.

بعلاوه ارزیابی امنیت می تواند به مقابله با مقاومت ها در برابر پذیرش DevOps کمک کند. از آنجا که آسیب پذیری ها کاهش پیدا می کنند، می توانید نشان دهید که افزایش سرعت باعث تنزل پایداری یک محصول نمی شود.

در مطلب بعد یازده شاخص کلیدی عملکرد DevOps را معرفی و بررسی خواهیم کرد.

برگرفته از “Hewlett Packard Enterprise, “Measuring DevOps success
سایر منابع :

1Source: Forrester Consulting, “Application Delivery Speed Drives Success: How Mastering DevOps Enables Speed With Quality and Low Cost”
23Source: Gartner, “Survey Analysis: DevOps Adoption Survey Results,” September 2015

Share Button

Continuous Delivery چیست ؟

Continuous Delivery چیست

Continuous Delivery یا (CD)، رویکردی در مهندسی نرم افزار است که تیم ها را قادر می سازد نرم افزار تولید شده را به روشی سریع و مطمئن برای انتشار و تحویل آماده کنند. این فرایند از لحظه اضافه شدن یا تغییر کد در source control شروع می شود و شامل بیلد، تست، پیکربندی و انتشار در محیط های مختلف تست و محیط عملیات می شود. این مفهوم در فارسی به “تحویل مداوم” یا “تحویل مستمر” ترجمه شده است.

به عبارت دیگر: Continuous Delivery توانایی اعمال تغییرات در محیط عملیات در هر لحظه با روشی سریع و مطمئن و به طور کاملا پایدار می باشد. این تغییرات شامل همه انواع آن از جمله تغییرات پیکربندی در نرم افزار، زیرساخت و پلتفرم، افرودن ویژگی های جدید، رفع باگ و خطا ها می شود.

به وسیله محیط های تست مختلف، می توان یک Release Pipeline ایجاد کرد تا بتوان یک زیرساخت جدید را به طور اتوماتیک ایجاد کرد و نرم افزار را روی آن منتشر کرد. منظور از زیرساخت، سرور، سیستم عامل، سرویس دهنده ی وب، virtualization، شبکه و پیکربندی و تنظیمات آنها می باشد. به کمک این محیط های متوالی می توان فعالیت های طولانی Integration، تست عملکرد و تست های پذیرش نهایی را به تدریج انجام داد. فرایند Continuous Delivery در Release Pipeline با Continuous Integration شروع میشود و با انتشار و پایان تست در هر محیط، انتشار و تست در مرحله بعدی شروع می شود. مجموع این کارها به صورت حلقه های یک زنجیر در پشت سر هم قرار گرفته و فرایند Continuous Delivery را تشکیل می دهند.

ContinuousDelivery Process چیست

هدف Continuous Delivery چیست ؟

هدف CD این است که که انتشار و تحویل نرم افزار را به خصوص برای سیستم های توزیع شده در مقیاس بسیار بزرگ و محیط های عملیاتی پیچیده به یک فرایند روتین، ساده و قابل پیش بینی تبدیل کند. رسیدن به این هدف تنها در صورتی امکان پذیر است که کدهای نرم افزار همیشه در وضعیت آماده برای انتشار باشند، حتی در شرایطی که یک تیم با هزاران توسعه دهنده به طور روزانه در حال تغییر و به روزرسانی کد ها و نرم افزار هستند. به این ترتیب روش سنتی فازهای ادغام (Integration)، تست، پیکربندی و Hardening جای خود را به روش های اتوماتیک می دهد. همچنین زمان آماده شدن برای انتشار، زمان مهاجرت به محیطهای دیگر (Time to Remediate) و زمان برطرف کردن رخداد در محیط عملیات را کاهش (Time To Mitigate or time to remediate production incidents) می دهد.

تفاوت Continuous Delivery و Continuous Deployment چیست ؟

بسیاری از مواقع دو مفهوم Continuous Delivery و Continuous Deployment به اشتباه به جای هم استفاده می شوند اما تقاوت این دو چیست ؟ Continuous Deployment به این معنی است که هر تغییر در نرم افزار به طور اتوماتیک (یا بر طبق یک زمان بندی مشخص) در محیط عملیات منتشر شود. اما Continuous Delivery به این معنی است که هر تغییر در نرم افزار، آماده انتشار در هر محیطی باشد اما ممکن است تصمیم این باشد که منتشر نشود (معمولا به دلایل کسب و کاری). این محیط ها شامل محیط تست تیم توسعه، محیط تست تیم کنترل کیفیت و محیط عملیات و هر محیط دیگری می شود.

تفاوت Continuous Delivery و دواپس چیست ؟

این دو مفهوم از جهاتی به هم نزدیک هستند و اما تفاوت های بنیادی با هم دارند. دامنه ی DevOps بسیار گسترده تر از CD است و علاوه بر خودکارسازی فرایند تحویل نرم افزار، شامل تغییرات فرهنگی به خصوص ارتباط بین تیم های مختلفی که در جریان آماده سازی و تحویل محصول نرم افزاری (Software Delivery) هستند هم می شود. (از جمله تیم های توسعه، عملیات، تضمین کیفیت، مدیریت و … ) اما Continuous Delivery روشی است برای اتوماتیک سازی زنجیره تحویل محصول و بر این موضوع تمرکز دارد که فرایند های مرتبط در کنار هم طوری اجرا شود که منجر شود محصول نرم افزاری، سریعتر، امن تر و با تکرار بیشتری به دست مشتری برسد.

DevOps CD CI Agile چیست

در نبود Continuous Delivery …

در نبود CD، انتشار نرم افزار یک bottleneck برای تیم های “عملیات فناوری اطلاعات” و در نهایت برای محصول است. فرایند دستی و غیر اتوماتیک، باعث انتشارهای غیر قابل اتکا، با تاخیر و پر از خطا می شود. تیم های درگیر این موضوع معمولا به کارهای دستی که افراد انجام می دهند تکیه می کنند که باعث مشکلات جدی خواهد شد.

حداقل الزامات اجرای Continuous Delivery

برای راه اندازی و اجرای Continuous Delivery الزاماتی وجود دارد که در کمترین حالت می توان از دو مورد زیر نام برد

  • زیربنایی از تست ها که تا حد قابل قبولی خیال شما را از اینکه نرم افزار به درستی کار می کند، راحت کند و به شما اعتماد به نفس لازم را برای شروع استقرار بدهد
  • ابزارهای خودکارسازی (automation) و اسکریپت های لازم که به شما اطمینان دهد استقرار با موفقیت انجام خواهد شد و در صورت نیاز امکان Rollback وجود خواهد داشت

سخن آخر

در آخر باید این این نکته را اضافه کنم که فرایند Continuous Delivery و Infrastructure as Code و Monitoring به طور قابل ملاحظه ای مکمل یکدیگر هستند. Continuous Delivery برای کنترل تاثیر تغییرات در محیط عملیاتی از استراتژی های استقرار از جمله Blue-Green Deployment و همچنین تکنیک Feature Flags (یا Feature Toggles) نیز پشتیبانی می کند. (در آینده راجع به استراتژی های انتشار مطلبی خواهم نوشت)
امروزه ارزش هایی که CD برای سازمان ها ایجاد می کند، آن را به یک نیاز ضروری تبدیل کرده است. برای رساندن ارزش به مشتریان نهایی، باید محصول را به طور پیوسته و بدون خطا منتشر کرد. Release Pipeline های پیشرفته به توسعه دهندگان اجازه می دهد که feature های جدید را سریع و مطمئن منتشر کنند. با کمک CD، رفع خطاها در محیط عملیات و اضافه کردن ویژگی های جدید بسیار سریع تر و با اطمینان بالا انجام خواهد شد و به دست مشتری خواهد رسید.

Share Button
Show Buttons
Hide Buttons