hiDevOps.com
FAQ
test
test2
مشاهدات، تجربیات و داستان های دواپس از زبان ما و شما
test
test2
bla bla
bla bla
سال 2007 میلادی آقای پاتریک دبوآ (Patrick Debois) درگیر پروژه ی جایی دیتاسنتر دولت بلژیک شد و با یک چالش مواجه شد: سیستم ادمین ها و توسعه دهندگان در تعامل با هم به مشکلاتی برمیخوردند که تاثیر منفی در روند اجرای کار داشت.
آگوست 2008 در کنفرانس سالانه چابک که در تورنتو کانادا برگزار شد(Agile 2008 Conference)، آقای اندرو شفر (Andrew Shafer) پیشنهاد نشستی با عنوان زیرساخت چابک (Agile Infrastructure) را می دهد که تقریبا با استفبال هیچکسی مواجه نمی شود به جز یک نفر و آن یک نفر کسی نبود به جز Patrick Debois ! به دلیل استقبال کمی که صورت گرفت، Andrew از برگزاری اون نشست صرف نظر میکنه. بعد از آن Patrick به دنبال Andrew در یک گفتگوی سرپایی راجع به این موضوع صحبت می کنند و گروه Agile System Administration را در google group ایجاد می کنند.
ژون 2009 در کنفرانس O’Reilly Velocity 2009، آقایان John Allspaw و Paul Hammond سخنرانی معروفی تحت عنوان “10 استقرار در روز: نتیجه همکاری توسعه و عملیات در فلیکر” داشتند. پاتریک که از راه دور این کنفرانس را تماشای می کرد، در توییتر ابراز تاسف کرد که نتوانسته به صورت حضوری شرکت کند. Paul Nasrat در پاسخ به این توییت پیشنهاد برگزاری کنفرانس در بلژیک را به Patrick Debois می دهد.
10 Deploys Per Day: Dev and Ops Cooperation at Flickr from John Allspaw
اکتبر 2009 Patrik به توصیه John عمل کرد و به فکر برگزاری یک کنفرانس در بلژیک افتاد. اول از همه باید یک اسم مناسب برای این کنفرانس انتخال می کرد. سه حرف Development و سه حرف از Operations به اضافه کلمه days چیزی بود که نام این کنفرانس را تشکیل داد “DevOpsDays”. این کنفرانس در 30 اکتبر با مجموعه قابل توجهی از توسعه دهندگان، sys admin ها، متخصصان ابزار و سایر افراد تشکیل شد. بعد از پایان کنفرانس مباحث در توییتر ادامه پیدا کرد. Patrik به هشتگ #DevOps را برای ادامه بحث انتخاب کرد تا خلاصه تر و راحت تر باشد. از آن زمان تا به حال، این جنبش را به نام DevOps (دوآپس) می شناسیم. (در نحوه نوشتن کلمه دوآپس توافق جامعی وجود ندارد و هر سه حالت DevOps و Devops و devops استفاده می شود)
آوریل 2012 Patrik Debois در یک مصاحبه ویدیویی در سال 2012 اذغان کرد که نامگذاری این جنبش به اندازه ای که به نظر می رسد خیلی عمدی نبوده. (به نظر میرسه منظور اینه که خیلی دقیق و فکر شده نیست). در ادامه Patrik میگوید: “من به این دلیل اسم DevOpsDays را در راستای همکاری تیم های توسعه و عملیات انتخاب کردم که اسم “Agile System Administration” طولانی بود و هیچ وقت برنامه ی بزرگی برای دنیایی به نام DevOps وجود نداشته.
سال 2013 موسسه Puppet Labs اولین نظرسنجی وضعیت دوآپس (State of DevOps) را برگزار کرد تا یک ارزیابی ای از روند رشد و عملکرد این حوزه به دست بیاید.
ممنون که ما را دنبال می کنید.
هدف مشترک هر کسب و کار، موفقیت تجاری است. تولید محصولات یا خدمات عالی که مشتری عاشق آن بشود منجر به درآمدزایی و سودآوری می شود. در سازمانی که افراد و دپارتمان های مختلف آن به درستی با یکدیگر تعامل ندارند، هزینه های سربار کارها زیاد شده و در نهایت به کسب و کار لطمه می زند.
اتهام به دیگر واحد ها و نادیده گرفتن چالش هایی که با آن درگیر هستند، یه هیچ وجه سازنده و مفید نیست. اگر افراد و تیم ها تعامل سازنده ای با هم نداشته باشند، فاصله ی بین آن ها به مرور بیشتر می شود و این به معنی تحمیل خسارت و زیان به سازمان و کسب و کار است.
در شرایطی که فشار سهامداران برای افزایش کیفیت و پایداری محصولات و کوتاه تر کردن زمان تولید و ارائه به بازار بیشتر از همیشه شده است، اهمیت برقراری ارتباط با یک زبان مشترک بین تیم ها و افراد بیشتر از همیشه شده است.
اگر شما یک مدیر یا کارشناس IT هستید و در حال حاضر از مزایای دواپس بهره نمی برید، توصیه من این است که در رویکرد خود یک بازنگری کلی داشته باشید، در ادامه علت این توصیه را توضیح خواهم داد …
در مطالب قبلی راجع به مفهوم DevOps صحبت کردیم (اینجا و اینجا). همچنین راجع به چارچوب CALMS در دواپس نوشتیم و در جایی دیگر راجع به کج فهمی هایی که در باره DevOps وجود دارد صحبت شد. در ادامه ی این سری مطالب قصد داریم راجع به اهمیت دواپس و مزایای دواپس بنویسیم. لطفا با ما همراه باشید.
هر شخص یا هر تیم مستقل، چه توسعه دهنده باشد، چه تیم عملیات، تضمین کیفیت یا تیم پشتیبانی، روزانه با چالش هایی مواجه می شوند. این چالش ها بر کسب و کار تاثیر گزارند، و حادثه ای در یک بخش می تواند در سایر بخش ها طنین انداز شود.
فارغ از اینکه چه کسی مسوول و پاسخگوی آن است، اما مشکل باید برطرف شود. سرزنش و گرفتن انگشت اشاره به سمت دیگران کمکی به حل مشکل نمی کند، و باید از زمان و منابع موجود برای حل مشکل کمال استفاده را کرد. بدون همکاری، فرایند حل مشکل طولانی تر می شود و می تواند منجر به پیدایش مشکلات دیگری هم شود که بلافاصله نمایان نمی شود.
همکاری با یکدیگر در سایه ی ارتباط موثر به شما اجازه می دهد که راه کارهایی را ایجاد کنید که بتواند از حادثه های مشابه در آینده جلوگیری کند.
با بهبود سرعت رسیدن به بازار می توانید مزیت رقابتی در بازاری را بدست آورید که نرم افزارها در آن عمر کمی دارند و خیلی زود به زود کهنه می شوند.
معرفی یک راهکار DevOps شما را قادر می سازد تا در یک دوره زمانی کوتاهتر از روش سنتی از یک مفهوم اولیه به یک محصول قابل قبول برسید. همچنین شما فرصت خواهید داشت منابع را زودتر آزاد کنید و بر بهبود نرم افزار و زیرساخت ها تمرکز کنید. به این معنی که شما با تحویل سریعتر ویژگی ها و قابلیت های جدید نرم افزاری می توانید رقبای خود را پشت سر بگزارید.
یکپارچه سازی مستمر فرایندی است که در آن توسعه دهندگان می توانند به طور مستمر کارهای خود را با هم یکپارچه کنند. (اطلاعات بیشتر: Continuous Integration). استفاده از یک فرایند بیلد اتوماتیک به همراه اجرای تست های اتوماتیک، ما را قادر می سازد که با هر تغییر در کد، از تاثیرات منفی احتمالی آن تغییر بر کل نرم افزار مطلع شویم.
تحویل مستمر رویکردی در مهندسی نرم افزار است که تیم ها را قادر می سازد نرم افزار تولید شده را به روشی سریع و مطمئن برای انتشار و تحویل آماده کنند. این فرایند از لحظه اضافه شدن یا تغییر کد در source control شروع می شود و شامل بیلد، تست، پیکربندی و انتشار می شود. (اطلاعات بیشتر: Continuous Delivery).
فرایند های CI و CD توسعه دهندگان را قادر می سازد تا مشکلات را هر چه سریعتر شناسایی و رفع کنند. شناسایی سریع مشکلات به معنی پیچیدگی کمتر و نیاز به کار کمتر برای رفع آن و فرایند دیباگ است. از ابزارهای رایجی که برای انجام عملیات CI و CD وجود دارند می توان به Jenkins، Team City و TFS یا Team Foundation Server اشاره کرد.
بنا به گزارش سالانه Puppet Labs در سال 2014، سازمان های فناوری اطلاعات با کارایی بالا که از روش های DevOps استفاده می کنند، بسیار چابک تر و قابل اطمینان تر از رقیبان خود هستند. گزارش سال 2015 همین موسسه نشان می دهد که روش های دوآپس و فرهنگ دوآپس سازمان ها را قادر می کند که بتوانند اپلیکیشن های خود را 30 برابر بیشتر منتشر کنند، همچنین زمان اعمال یک تغییر یا رفع یک مشکل 200 برابر سریعتر از سایر سازمان ها باشد. در چنین سازمانی بهره وری و تولید محصولات بهتر نرم افزاری، بارها بیشتر از سایر سازمان ها است.
ارزش این ابزارها و روش ها نه تنها در کسب و کار و کارایی محصولات است، بلکه تاثیر مثبتی در روحیه کارکنان آن سازمان دارد. در چنین شرایطی علاوه بر راحت تر شدن کارهای تکراری و خسته کننده، اجازه بروز خلاقیت های فردی نیز بیشتر خواهد شد.
به طور سنتی، نگهداری از سرورها و سخت افزارها و محیط های عملیاتی، بر عهده ی تیم IT Operation (عملیات) و افرادی که آن ها را با نام System Administrators می شناسیم بوده است.
کار کردن به عنوان یک تیم واحد با اعضای چند-عملکردی (cross-functional) شامل مدیران پایگاه داده (DBAs)، تحلیلگران کسب و کار، توسعه دهندگان، تضمین کنندگان کیفیت، و مهندسان عملیاتی و مهندسان DevOps، مزایای بسیاری را به همراه می آورد.
یک تیم به وسیله DevOps، علاوه بر عملکردها (functionality) به پایداری (stability) هم اهمیت می دهد. هر یک از اعضای تیم خود را مالک و مسوول اهداف کسب و کار می داند. تناوب و تکرار انتشارها، تغییرات کوچک، و ابزارهای پایش مانند New-Relic و Boundary به پیشرفت و بهبود محیط های عملیاتی، زیرساخت ها و پایداری سورس-کد ها کمک می کنند.
یکی از سنجه های ویژه در اهمیت به پایداری، تناوب و تکرار انتشارها است. دِوآپس، به مهندسان این امکان را می دهد که بتوانند سریعتر عیب یابی کنند و خطاها را برطرف کنند. این دسته از تمرین ها باعث کاهش شاخص MTTR می شوند. Mean-Time-To-Recover یک متریک بسیار مهم به این معنی است که نشان می دهد سرعت برگشت به وضعیت پایدار در زمان وقوع یک حادثه چقدر است. بنابراین بعد از یک failure در زیرساخت، بسیار سریعتر می توان پایدار را به سرویس بازگرداند.
نرم افزارهای مانیتورینگ اپلیکیشن ها و سرورها مانند New Relic و Boundary با فراهم کردن دسترسی مهندسان به اطلاعات حیاتی نرم افزار و محیط عملیاتی، به شناسایی خطاها کمک می کنند تا پایداری را حفظ کنند.
ترکیب همه ی این ابزارها و به-روش ها (Best Practices) همراه با خودکارسازی (automation) به تیم های DevOps اجازه می دهند تا پایداری کلی سرویس را بهبود ببخشند و خرابی های بحرانی زیرساختی را کاهش دهند. علاوه بر این، آن ها را قادر می سازد تا در آن هنگام سریعتر و چابک تر رفتار کنند.
ماهیت سریع و چابک تیم های DevOps تیم ها را قادر می سازد تا قابلیت های جدید را در قالب گسترشهای کوچک تر و ماژولارتر معرفی کنند. از آنجا که این استقرارها بیشتر هدفمند و ایزوله هستند، شناسایی باگ ها آسانتر است، رفع آن ها سریع تر انجام می گیرد و پیاده سازی آن ها نیز آسان است. فقط لازم است که تیم ها آخرین تغییراتی کد را مجددا بررسی کنند تا بتوانند مشکلات را رفع کنند.
این رویکرد مزایای قابل توجهی هم برای کسب و کارها دارد. امکان رفع سریع تر خطاها باعث رضایت مشتریان شده و منابع ارزشمند را آزاد می کند و می توان این منابع را بر اعمال دیگری مثل طراحی، توسعه و استقرار عملکردهای و ویژگی های جدید متمرکز کرد. استفاده ترکیبی از سیستم های کنترل نسخه(Version-Control)، یکپارچه سازی مستمر (Continuous-Integration)، ابزارهای استقرار خودکار (Deployment-Automation-Tools) و توسعه مبتنی بر تست (TDD) به تیم های DevOps این امکان را داده است که تغییرات را در بخش های کوچکتر و به صورت افزایشی (incremental) اعمال کنند.
به دلیل این پیاده سازی های ماژولارتر، تیم های DevOps می توانند زودتر مشکلات مربوط به پیکربندی، کدهای اپلیکیشن و زیرساخت را کشف کنند؛ زیرا بعد از اتمام کدنویسی، مسئولیت به تیم دیگری محول نمی شود.
به دلیل اعمال تغییرات به صورت کوچکتر و تدریجی، مشکلات، پیچیدگی کمتری داشته و تصمیم گیری برای رعفع آن ها سریع تر انجام می شود زیرا مسئولیت خطایابی و رفع مشکلات فقط متوجه یک تیم خاص می شود.
گزارش State of DevOps که هر ساله توسط Puppet Labs منتشر می شود، در سال 2015 نشان می دهد که، شرکت های IT با عملکرد و بهره وری بالاتر نسبت به رقبای خود با عملکرد ضعیف تر، بعد از fail شدن، 168 بار سریع تر قادر به جبران آن و بهبود وضهیت هستند.
با ترکیب چندین تیم و رشته به صورت یک تیم DevOps ناب و معتدل که مجموعه مهارت هایی با عملکرد متقابل داشته و به صورت کارآمد و موثر با هم ارتباط برقرار می کنند، شما به صورت خودکار انباره های سنتی را که به دلیل چند قسمتی شدن بوجود آمده اند را در هم شکسته و تجزیه می کنید. به این ترتیب دیگر هیچ کدام از متخصصین عامل شکست نخواهند بود. همه افراد تیم مسئولیت رسیدن به اهداف کاری را بر عهده می گیرند و به دلیل ماهیت مشارکتی DevOps اعضای تیم می توانند چندین چالش در حوزه های مختلف عملیاتی و توسعه را به عهده بگیرند. البته این رویکرد مزایای زیادی برای یک سازمان دارد و تیم ها را قادر می کند که اعمال را به سرعت و به صورت موثر انجام داده و در عین حال کیفیت و ثبات را حفظ کنند.
با پیاده سازی یک رویکرد DevOps می توانید هزینه ها و منابع مورد نیاز در پیاده سازی های سنتی IT را کاهش دهید. IT به صورت سنتی به عنوان یک مرکز ایجاد هزینه تلقی می شد اما پیاده سازی DevOps نشان داد که این رویکرد ارزش های کاری واقعی ایجاد می کند. وقتی از رویکردهای مدیریت ناب و ارائه مستمر استفاده می کنید، نتایج کیفی بالاتر و طول چرخه ها کوتاه تر می شود و در نهایت هزینه ها نیز کاهش می یابند. این رویکرد به کاهش منابع مورد نیاز از نظر سخت افزار و نیروی انسانی نیز ادامه می دهد. یک معماری ماژولار از اجزایی تشکیل شده که بخوبی بسته بندی شده و ارتباط کمی با هم دارند و به سازمان ها اجازه می دهد که از رایانش ابری به صورت موثر و کارآمد استفاده کنند.
رایانش ابری از طریق استفاده از فرایندهای خودکار و طراحی قوی، سرویس ها و محصولاتی را فراهم کرده که توانایی تطبیق با نیازهای مشاغل را دارند. مزایای رایانش ابری بی شمار هستند و همه این مزایا به کاهش هزینه ها کمک می کنند. هر چند DevOps و رایانش ابری نه متقابلا منحصربفرد و نه مستقیم به هم مرتبط هستند، اما در صورتیکه با هم ترکیب شوند یکدیگر را تقویت می کنند.
انعطاف پذیری ایجاد شده توسط فناوری ابری، تیم های DevOps را قادر به تامین سریع تر نیازهای مشاغل و مشتریان می کند. اگر نیاز به منابع بیشتر یا یک دیتابیس جدید و یا سرورهای تعادل بار باشد، فناوری ابری امکان تحویل خودکار این نیازها را در عرض چند دقیقه فراهم می کند.
همچنین سرویس های رایانش ابری در مواقع بازیابی از حادثه کمک کننده هستند؛ زیرا بیشتر مشکلات توسط ارائه دهنده سرویس مدیریت می شوند.
همچنین، بروزرسانی های خودکار نرم افزار و زیرساخت، که به صورت سنتی درخانه انجام می شد، به ارائه دهندگان ابری محول می شود. در نتیجه زمان و منابع مورد نیاز در قسمتهای دیگر آزاد می شود.
مزایای دیگری که به کاهش الزامات مربوط به هزینه ها و منابع کمک می کنند، عبارتند از: حداقل شدن هزینه های شروع و هزینه های عملیاتی انجام پروژه، افزایش مشارکت، افزایش دسترس پذیری و دسترسی به داده ها و بهبود امنیت.
در محیط های سنتی IT، زمان و منابع زیادی به هدر می روند. معمولاً برای انتظار جهت تکمیل کارها توسط دیگران یا حل چندین بارهی یک مشکل، زمان زیادی هدر می رود و این امر باعث سرخوردگی و ایجاد هزینه های مالی می شود.
محیط های تولیدی استاندارد و ابزارهای اتوماسیون می توانند به پیش بینی پذیر شدن استقرارها و تحویل محصولات کمک کنند. این فرایندها، افراد را از انجام کارهای روتین رها کرده و به آن ها اجازه می دهد که بر جنبه های خلاقانه تر نقش شان متمرکز شده، برای کسب و کار ارزش بیشتری ایجاد کنند و در نهایت همه از سود آن بهره مند شوند.
پیچیدگی یا نوع سیستم هایی که این شیوه ها به آن ها اعمال می شود، فاکتور چندان مهمی نیست. مادامی که معماری نرم افزار با در نظر گرفتن قابلیت تست و قابلیت استقرار ایجاد شود، امکان افزایش کارایی بیشتر می شود.
در گزارش “2015 State of DevOps Report” به چند نکته کلیدی اشاره شده که نشان می دهد تیم هایی با رویکرد Devops نسبت به رقیبانشان، از کارایی بالایی برخوردار بودند.
فکر میکنم شما هم موافق باشید که این افزایش قابل ملاحظه ای در عملکرد تیم ها است!
همانطور که در بالا اشاره شد، معرفی ادغام مستمر/یکپارچه سازی مستمر/CI، استاندارد سازی محیط های تولید و استقرارهای خودکار/CD، کارشناسان را قادر می سازد تا بر جنبه های مبتکرانه و خلاقانه تر نقش شان بیشتر تمرکز داشته باشند. زمان و منابع بیشتری که صرف آزمایش و نوآوری می شود، به تیم ها امکان توسعه و انتشار نرم افزارهای بهبود یافته را داده و این امر مستقیما به رسیدن به اهداف بیزنسی ترجمه می شود. محیط و فرهنگی که DevOps به ایجاد و پرورش آن کمک می کند، به درک عمیق تر و پیاده سازی به-روش ها کمک می کند.
به عنوان یک مهندس DevOps کاملا متعهد، می توانم با توجه به تجربیاتم به شما بگویم که کار کردن در یک محیط مشارکتی و چند مهارتی عامل بزرگی در زمینه رضایت شغلی است. من در نقشم به عنوان سرپرست توسعه دهندهی اپلیکیشن های وب، تمامی جوانب چرخه عمر محصول را مدیریت می کنم از مدیریت پیکربندی و زیرساخت گرفته تا توسعه، تست، اتوماسیون و استقرار. توانایی تشخیص مشکلات سرور، همزمان با دارا بودن مجموعه مهارت های لازم برای پیاده سازی اصطلاحات، سرمایه ای ارزشمند برای ما است.
اما دلیل اهمیت رضایت شغلی چیست؟
طبق گزارش سال 2014 Sate of DevOps “رضایت شغلی عامل شماره یک پیش بینی عملکرد (کارایی) سازمانی است.” یعنی رضایت اعضای تیم در انجام نقش شان عامل بسیار مهمی در افزایش کارایی شرکتی است.
شیوه ها و فرهنگ DevOps رضایت کارمندان را افزایش می دهد و این امر منجر به نتایج شغلی بهتر می شود.
داده های گزارش سال 2014 State of DevOps نشان داد که سازمان هایی که عملکرد خوبی دارند تعداد شکست هایشان (خرابی هایشان) 50 درصد کمتر است. این روند ادامه پیدا کرد و گزارش سال 2015 نشان داد که سازمان هایی که طرزتفکر و فرهنگ DevOps را اتخاذ کرده اند نسبت به آن هایی که رویکرد DevOps را پیاده سازی نکرده اند 60 برابر کمتر دچار شکست (خرابی) می شوند. این اطلاعات بسیار واضح هستند و مزایای عظیم DevOps را به عنوان یک طرز تفکر و فرهنگ برای مشاغل و البته افراد، مشخص کردند. شکست کمتر به معنی زمان بیشتر عملکرد سرویس و نیاز به منابع کمتر برای حل مشکلات است؛ در نتیجه به شما امکان می دهد که تمرکز بیشتری بر بهبودهای بیشتر و ابتکارات خلاقانه داشته باشید.
منبع: متن فوق برگرفته از سایت purplegriffon می باشد.
امیدوارم که توانسته باشم مزایای یک رویکرد DevOps را مشخص کرده باشم. فرهنگ فناوری اطلاعات مدام در حال تغییر است و روش های سنتی مدیریتِ انتشار محصولات، اغلب ناکارآمد، هزینه بر و زیانبخش هستند.
شاید کلمه DevOps، واژهای باشد که تازه باب شده است ولی قرار است ماندگار شود و در حال متحول کردن صنعت فناوری اطلاعات است.
افزایش کارایی، کاهش هزینه ها و تولید نرم افزار بهتری که شکست های (failure) کمتری داشته باشد مواردی هستند که تمام فروشنده های حوزه فناوری اطلاعات باید سعی به دستیابی به آنها داشته باشند. با استفاده از یک رویکرد DevOps این موارد قابل دستیابی تر هستند.
برای کسب اطلاعات بیشتر درباره DevOps و اینکه سازمان شما چطور می تواند تغییری فرهنگی به سمت پیاده سازی بهترین روش های DevOps داشته باشد با ما در ارتباط باشید.
شاخص های کلیدی عملکردی دواپس یا DevOps KPI که قبلا به چهار دسته سرعت، کیفیت، بهره وری و امنیت تقسیم کردیم را چطور ارزیابی میکنید؟ در این مطلب یازده شاخص کلیدی عملکرد، اصول و پایه های لازم برای ارزیابی موفقیت DevOps را معرفی و بررسی کرده ایم.
در مطلب قبلی با عنوان “ارزیابی میزان موفقیت عملکرد دواپس با شاخص های عملکرد کلیدی” به دلیل اندازه گیری و ارزیابی سرعت اشاره کردیم. اما با چه سنجه و متریک هایی می توان سرعت را اندازه گیری کرد؟ در اینجا قصد داریم چهار شاخص عملکرد کلیدی سرعت دواپس را معرفی و شرح دهیم.
مفهوم: مشخص میکند که هر چند وقت یکبار نسخه جدیدی از یک محصول یا سرویس ارائه میشود. و به صورت تعداد استقرارها در ماه، هفته، روز یا ساعت ارزیابی می شود.
دلیل اهمیت: استقرارهای مکرر و پی در پی نشان دهنده بهبود مستمر اپلیکیشن ها است که با افزودن ویژگی های تازه به آن ها، باعث ایجاد قابلیت رقابت در آن ها می شود. همچنین بروزرسانی های مکرر نشان می دهد که بخش IT در برابر تقاضای بیزینس برای ویژگی های جدید پاسخگو است. یک بیزینس در صورتیکه مشاهده کند که به جای شش ماه یکبار، هر ماه شاهد اضافه شدن ویژگی ها و امکانات جدید توسط بخش IT است، قدردان بخش IT خواهد بود. (اما فراموش نکنیم که استقرار بیش از حد مکرر ممکن است نشان دهنده این باشد که به دلیل عجله زیاد، مدام نرم افزارهای معیوب تولید می کنید.)
همچنین این معیار به سایر حوزه های استقرار نرم افزار که عملکرد درستی دارند هم اشاره می کند:
قبلا دو مطلب در رابطه با استقرار نرم افزار منتشر کردیم که خواندن آن خالی از لطف نیست :
مفهوم: یک استقرار واحد، برای یک محصول یا سرویس خاص چقدر زمان می برد. این معیار به صورت تعداد ساعات سپری شده از تایید استقرار تا اجرای آن در محیط بعدی بیان می شود.
دلیل اهمیت: در روش های سنتی، سیستم های شرکتی اتصال تنگاتنگی دارند(tightly coupled هستند)؛ هر زمان چیزی مستقر می شود، ممکن است در نهایت نیاز به استقرار مجدد کل اپلیکیشن باشد. یک دهه پیش، این امر قابل قبول بود – می توانستید از کار افتادگی پنج ساعتهی ویندوز را برای نیمه شب زمانبندی کنید، بدون این که این از کار افتادگی تاثیر منفی برای بیزینس داشته باشد. اما مشاغل امروزه جهانی هستند – مثلاً وقتی در امریکا نیمه شب است، در آسیا روز است – و اکثر شرکت ها در همه اوقات مشتریانی دارند که بیدار هستند. بنابراین سریع بودن استقرار امری حیاتی است.
امروزه، سیستم ها باید کمتر به هم وابستگی داشته باشند. به این ترتیب، می توان سرویس های خاص را بدون تاثیر بر کل سیستم تغییر داد. با استفاده از میکروسرویس ها و APIهایی که به وضوح تعریف شده و امکان کپسوله کردن و دسترسی آسان را فراهم کنند، می توانید سرعت استقرار را به میزان زیادی افزایش دهید.
بعلاوه افزایش سرعت استقرار نشان دهنده افزایش ثبات (سازگاری) در خط لولهی دواپس (DevOps Pipeline)، با جایگزینی کارهای دستی پرخطا در چرخه عمر محصول، توسط اتوماسیون است.
مفهوم: کل زمان حرکت یک محصول در چرخه QA
دلیل اهمیت: اکثر اوقات QA تبدیل به یک تنگنا می شود. ارزیابی زمان سپری شده برای یک محصول تولیدی در QA اطلاعات کلیدی درباره اینکه با چه سرعت و فرکانسی می توانید یک محصول یا سرویس ارائه دهید، در اختیارتان قرار می دهد. وقتی مقدار این سنجه بالا باشد، متوجه می شوید که می توانید فرکانس را بدون اینکه QA تبدیل به تنگنا شود، افزایش دهید. اگر این مقدار پایین باشد، نشان می دهد که نیاز به پیاده سازی تکنیک هایی مثل اتوماسیون تست در خط لولهی انتشار محصول دارید (release pipeline).
مفهوم: تعداد تولیداتی که یک تیم QA می تواند در یک دوره خاص به مصرف برساند.
دلیل اهمیت: افزایش تعداد تولیداتی که QA می تواند به صورت مثبت مورد مصرف قرار دهد تاثیر مثبتی بر زمانبندی انتشار دارد. ممکن است سرعت استقرار بالا باشد، اما بدون ادغام مستمر (Continuous Integration) باید تولیدات را به صورت دستی مدیریت کنید که این کار باعث کند شدن خط لوله انتشار (DevOps Pipeline) می شود. به طور مشابه، بدون Continuous Testing، حین فرایند تست زمان هدر می رود. نتیجه این است که تیم QA نمی تواند حداکثر تعداد تولیدات را در هر چرخه به مصرف برساند و پوشش تست – همچنین اطمینان از حرکت به مرحله بعد – دچار مشکل است.
ادغام و تست مستمر می تواند فرکانس اعتبار سنجی تولید را افزایش دهد – در بعضی موارد می تواند آن را در هر ماه تقریبا دو برابر کند. وقتی که مقدار این عدد بالا باشد، نشان دهنده پوشش بهتر تست، نشان دهنده ی اطمینان بیشتر برای حرکت به مرحله بعد تولید و سرعت بیشتر تولید است.
پیرو مطلب قبلی با عنوان “ارزیابی میزان موفقیت عملکرد دواپس با شاخص های عملکرد کلیدی” که در آن به دلیل اندازه گیری و ارزیابی کیفیت اشاره کردیم، در ادامه به سه تا از شاخص عملکرد کلیدی کیفیت در دواپس می پردازیم.
مفهوم: درصد استقرارهایی که بعد از اعتبار سنجی موفق تلقی شده اند. در اینجا موفقیت به این معنا است که بعد از استقرار، در فاصله ی کوتاهی مجبور به استقرار مجدد یا انتشار patch نشیم.
دلیل اهمیت: نرخ موفقیت بالا هنگام استقرار در سرورهای غیرتولیدی، دلالت بر کیفیت بالا در مراحل قبلی دارد. نرخ موفقیت پایین حاکی از ضعف کیفی کدنویسی است. در خیلی از شرکت ها، ممکن است System Integration Test و QA نرخ موفقیت بالایی داشته باشند ولی در عین حال در محیط پیش عملیات (Staging) موفق نباشند. این معیار می تواند به شما کمک کند تا مشکلات موجود در مرحله استقرار را هدف گرفته و از بین ببرید. نرخ موفقیت باید به مرور زمان افزایش پیدا کند.
در سازمان هایی که عملکرد خیلی خوبی دارند، مقدار این معیار باید به دلیل حذف مشکلات در پیش عملیات (Staging) – یا بهتر از آن، پیشگیری از این مشکلات – بالا باشد. اما خیلی از سازمان ها در این حوزه دچار چالش هستند و باید انتشارها (یا نسخه ها) را به عقب برگردانند. پایین بودن نرخ موفقیت بعد از یک فاز پیمایش موفق می تواند نشان دهنده چندین مشکل باشد:
مفهوم: تعداد حوادث و نقایص گزارش شده در یک نسخه خاص از یک محصول یا سرویس در محیط عملیاتی
دلیل اهمیت: حوادث و نقایص نشان دهنده از دست دادن زمان، پول و فرصت است. بالا بودن عدد این معیار نشان دهنده وجود مشکلاتی در حوزه های زیر است:
مفهوم: درصد قابلیت ردیابی (traceability) بین نیازمندی ها و تست ها (منظور امکان ارتباط دادن این دو به هم است).
دلیل اهمیت: عدم سازگاری بین نیازمندی ها و test case منجر به ایجاد مشکل و ضایعات حین چرخه استقرار نرم افزار می شود. وقتی که نیازمندی ها و test case ها به هم ارتباط نداشته باشند، تغییر در نیازمندی ممکن است منجر به شکست test case یا عدم وجود مواردی برای آزمایش شود. test case مشخص نمی کنند که چه تعداد از نیازمندی ها باید تحت پوشش قرار بگیرند و وقتی که تمامی نیازمندی ها را پوشش ندهند، این امر تاثیر منفی مستقیمی بر کیفیت نرم افزار و در نهایت بر تجربیات کاربر خواهد داشت.
وقتی که نیازمندی ها و test case ها با هم هماهنگی داشته باشند، تغییر در نیازمندی ها منجر به قابلیت مشاهده موارد متناظر در پوشش test case می شود. بروز رسانی هر یک از test case به نیازمندی ربط پیدا می کند. وجود ارتباط، تاثیر مثبت و مستقیمی بر کیفیت نرم افزار دارد. بالا بودن میزان این ارتباط نشان دهنده افزایش کیفیت نرم افزار؛ تناقض و ناسازگاری کمتر بین تحلیل گران، توسعه دهندگان و تیم QA؛ و بهره وری بالاتر است.
گروه دیگر از شاخص هایی که در مطلب قبلی با عنوان “ارزیابی میزان موفقیت عملکرد دواپس با شاخص های عملکرد کلیدی” اشاره شد، بهره وری یا Productivity بود. در این خصوص نیز دو شاخص عملکرد کلیدی وجود دارد که شرح خواهیم داد.
مفهوم: تعداد یا درصد ویژگی های استفاده نشده از یک محصول یا سرویس خاص وقتی که تولید شده است.
دلیل اهمیت: DevOps یک چرخه بازخوردی است (feedback loop) که شامل بیزنس، توسعه، تست، عملیات و کاربران می شود. پایین بودن میزان استفاده از ویژگیها به این معناست که بخش فناوری اطلاعات (IT) مشغول توسعه ویژگی ها و امکاناتی است که یا مورد تقاضا نیستند (بازخورد ضعیف از سوی بیزنس به بخش توسعه)، یا مورد نیاز نیستند (بازخورد ضعیف از طرف کاربران به بیزنس) یا به صورت ضعیف ساخته شده اند (مشکل در بازخورد از سوی بخش IT). هزینه ویژگی ها و امکاناتی که مورد استفاده قرار نمی گیرند، می تواند بسیار زیاد باشد، بنابراین مهم است که علت این امر شناسایی شود. بالا بودن تعداد ویژگی هایی که در یک محصول خاص استفاده نشده اند نشان دهنده منفی بودن میزان اثربخشی مدیریت و توسعه نیازمندی ها است.
مفهوم: زمان بازیابی یک سرویس یا عملکرد، وقتی که در اثر وجود نقصی که نیاز به اصلاح یا توسعه دارد، اختلالی بوجود آمده باشد. به بیان دیگر وقتی که خطایی پیدا می شود، چقدر طول می کشد که آن خطا اصلاح شده و محصول عرضه شود؟
دلیل اهمیت: اگر اپلیکیشنی با تمام ویژگی ها و عملکردهای مورد نیاز منتشر کنید، ولی مشخص شود که این اپلیکیشن قابل اطمینان نیست یا بازیابی آن بعد از شکست زمان زیادی می برد، این امر باعث می شود تمام ارزش های ایجاد شده توسط تولید ویژگی ها و توابع مناسب در مراحل قبل از بین برود. مسلما نمی توان از هر نوع شکستی پیشگیری کرد اما می توان انعطاف پذیری اپلیکیشن ها و نحوه پاسخگویی تیم را بهبود بخشید. هر دقیقه از کار افتادگی یک سرویس، باعث از دست دادن درآمد، مشتری ها و کیفیت برند می شود.
بعلاوه، MTTRS می تواند مشخص کننده مشکلاتی در سازمان باشد از جمله:
سرعت، کیفیت و بهره وری بدون امنیت می تواند کل سرویس را به خطر بیاندازد. در مطلب قبل با عنوان “ارزیابی میزان موفقیت عملکرد دواپس با شاخص های عملکرد کلیدی” به اهمیت اندازه گیری امنیت در دواپس اشاره کردیم و در ادامه دو تا از KPI های مهم در این خصوص را شرح خواهیم داد.
مفهوم: نسبت شکست در مقایسه با موفقیت در گذراندن اسکن امنیتی کدهای بعد از بیلد کردن محصول در یک دوره زمانی خاص.
دلیل اهمیت: مشخص شدن آسیب پذیری های امنیتی در مرحله تولید، به این موضوع را تضمین می کند که همیشه قبل ورود به سایر بخش های DevOps Pipeline، محصولاتی سبز و خوب تولید می شوند.
مفهوم: تعداد اسکن های امنیتی که در یک بازه زمانی یا فاز پردازش خاص، مشکلی را مشخص می کنند همراه تعداد مشکلات.
دلیل اهمیت: این نرخ باید با گذشت زمان یا با حرکت از مرحله ای به مرحله بعد در خط لوله کاهش پیدا کند. اگر نرخ موفقیت اسکن امنیتی رو به بهبود باشد، این اطمینان ایجاد می شود که سرعت توسعه و انتشار ویژگی های جدید طوری است که بجای آسیب رساندن به امنیت، باعث پایداری محصول می شود.
DevOps این قابلیت را دارد که زنجیره ارائه نرم افزار را به ماشینی با تفکر ناب، سریع و به شدت موثر تبدیل کند تا آنچه کاربران تقاضا دارند را عرضه کند. این تبدیل اهمیت بسیار زیادی دارد. طبق یکی از نظر سنجی های شرکت Forrester Consulting که در سال 2015 انجام شده، 64 درصد از پاسخ دهندگان بر این باورند که نرم افزار یکی از عوامل کلیدی توانمندساز مشاغل است و موفقیت مشاغل بستگی به اپلیکیشن هایی با کیفیت بالا دارد که مناسب با مدل های بیزنسی مدرن باشد.
DevOps has the potential to transform the software delivery chain into a lean, fast, highly effective machine that delivers what users want.
شرکت نرم افزاری HPE با کمک داده های حجیم معیارهایی را از منابع مختلف در سیستم های IT مختلف جمع آوری کرده است تا این 11 شاخص کلیدی عملکرد و موارد دیگر را تولید کند. ابتکار شرکت نرم افزاری HPE دیدگاهی واحد از معیارهای DevOps فراهم می کند که به شما برای بدست آوردن اطلاعات و بینش هایی درباره مسیر حرکت DevOps کمک می کند؛ به طوری که می توانید به شیوه ای موثر و کارآمد تبدیل و تحول DevOps را مدیریت کنید.
وقتی که شروع به استفاده از شاخص های کلیدی عملکرد برای ارزیابی موفقیت DevOps کردید، راه های زیادی برای گسترش داشبورد معیارهای دواپس و متناسب کردن آن با سایر سطوح سازمان خواهید داشت. برای گسترش معیارهای DevOps به سمت بالا و حوزه بیزنس، داشبورد KPIی DevOps را می توان به صورت یک داشبورد مخصوص مدیر ارشد فناوری اطلاعات درآورد که دیدگاهی سطح بالا از تشکیلات IT و همچنین میزان پیشرفت در فعالیت های عمده فراهم کند. (DevOps Dashboard)
یکی از شاخص های کلیدی عملکرد که در حال حاضر مشاغل علاقه زیادی به آن دارند، میزان استفاده از ویژگی ها است اما می توانید در کنار آن، زمان چرخه را هم نظارت کنید که نشان می دهد تولید یک ویژگی خواسته شده و استقرار آن در یک محصول چقدر زمان می برد. البته شاخص های کلیدی عملکرد از نوعِ اقتصادی نیز همیشه برای مشاغل متناسب و مهم هستند – که یکی دیگر از راه های گسترش داشبورد را تشکیل می دهند.
بعلاوه می توانید داشبورد DevOps را به سمت پایین هم گسترش دهید تا فعالیت های روزمرهی افراد را تحت پوشش قرار دهد.
DevOps یک سفر و یک سیر تکاملی است نه یک پیاده سازی یک شبه. هر چند خیلی از ابتکارات با برداشتن قدم های کوچک شروع می شوند، اما DevOps نیاز به تعهد به یک نوع فرهنگ جدید دارد. به همین خاطر است که شرکت هایی که امروزه به دنبال پیاده سازی دواپس هستند، احتمالا نیاز به تحویل طرح فعالیت تجاری جدید به مدیران سازمان دارند. سازمان های دیگری که از قبل دواپس را آزمایش و تجربه کرده اند، ممکن است آماده باشند که اطلاع را جمع آوری و رویکردشان را بهینه سازی کنند. در هر صورت وجود معیارهای قابل رویت و مفید در موفقیت DevOps تاثیر بسیار زیادی دارد.
منبع : “Hewlett Packard Enterprise, “Measuring DevOps success
امروزه و در عصر DevOps، پیوسته لازم است که شاخص های کلیدی عملکرد (KPI) را ارزیابی کنید تا میزان موفقیت DevOps مشخص شده و امکان تغییرات بیشتر فراهم شود.
DevOps در اصل از طریق جنبش چابک (Agile Movement) رشد پیدا کرد و در واقع راهکاری برای افزایش سرعت ارائه نرم افزار توسط تیم های توسعه نرم افزار به مشتریان است. در حال حاضر DevOps دربرگیرنده همه بخش های فرایند ارائه نرم افزار است از برنامه ریزی گرفته تا ایمن سازی، نظارت و بروز رسانی اپلیکیشنی که از قبل تولید شده است.
امروزه، DevOps به طور گسترده برای build، تست و ارائه نرم افزار توسط کسب و کارهای مختلف پذیرفته شده است. در این دنیای رقابتی، پرتحرک و همیشه متصل، DevOps شرکت ها را قادر ساخته که از طریق از بین بردن سیلوهای توسعه (Dev) و عملیات (Operation)، با خواسته ی کاربران در مورد تحویل و ارائه سریع همگام شوند.
این شرایط اهمیت کیفیت نسبت به گذشته را دوچندان کرده است؛ در نتیجه کسب و کارها نمی توانند صرفا برای ارائه سریع نرم افزار به بازار، کیفیت را نادیده بگیرند. با ارائه ی یک اپلیکیشن با عملکرد ضعیف در یک فروشگاه اپلیکیشنی (app store) که کاربران نظرات منفی زیادی در آن درج می کنند، به سرعت می توان شهرت و خوشنامی یک برند را از بین برد. با استفاده از DevOps، بهینه سازی کارها در جهت افزایش سرعت، همزمان با حفظ کیفیت و کاهش خطرها قابل انجام است. Batchهای کوچک، سریع تر ارائه شده و به صورت ذاتی مشکلات مربوط به کیفیت و امنیت را کاهش می دهد.
افزایش سرعت در توسعه نرم افزار به روش سنتی، اغلب اوقات باعث کاهش کیفیت و افزایش آسیب پذیری می شود. همچنین در روش های سنتی افزایش سرعت، کیفیت و امنیت عاملی برای افزایش هزینه ها محسوب می شود. اما ابتکارات DevOps می تواند واقعا منجر به بهبود در تمام این چهار بُعد شود: سرعت، کیفیت، بهرهوری و امنیت. کلید کار اتخاذ چارچوبی برای معیارها است که مشخص کند چه جاهایی در حال پیشرفت هستید و چه جاهایی هنوز نیاز به بهبود دارید.
اکثر سازمان ها DevOps را به دلیل یک نیاز بیزینسی خاص مثل بهبود زمان بازاریابی، کاهش نقایص یا تراز کردن بهتر ابتکارات IT با استراتژی بیزینسی پیاده سازی می کنند. اما از آنجا که DevOps هیچ فریم ورک رسمی ندارد، روش های زیادی برای ارزیابی موفقیت DevOps وجود ندارد، در حالیکه این ارزیابی حیاتی است. از آنجا که خیلی از سازمان ها DevOps را به صورت تدریجی پیاده سازی می کنند – اول در یک پروژه و بعد آرام آرام آن را در سراسر سازمان گسترش می دهند – چند پروژه اول باید موفقیت آمیز باشند؛ طوریکه بتوانند پشتیبانی انحصاری برای DevOps ایجاد کنند. همانطور که مشتریان ما به ما گفته اند: “هر چیزی که ارزیابی شود، بهبود پیدا می کند.”
وجود معیارهایی که نشان دهنده موفقیت آمیز بودن یک آزمایش باشند، می تواند به غلبه بر مقاومت های داخلی در برابر پذیرش DevOps کمک کند. یکی از نظرسنجی های شرکت Gartner از مدیران مشاغل2 و بخش IT مشخص کرد که “people issue” (موارد مربوط به افراد) بزرگترین چالشی است که سازمان ها در پذیرش DevOps با آن روبرو هستند و 43 درصد پاسخ دهندگان مقاومت در برابر تغیرات را بزرگترین مانع دانسته اند. از آنجا که DevOps نیاز به تحول فرهنگی و تغییرات فرایند و فناوری دارد، وجود پشتیبانی و حمایت انحصاری از آن ضروری است.
بعلاوه، DevOps به عنوان یک سیر تکاملی شناخته شده است که نیاز به بهبود مستمر (Continuous Improvement) دارد. اما اگر نتایج را ارزیابی نکنید، متوجه نمی شوید که DevOps را چطور درون سازمانتان تکامل دهید.
ارزیابی در مسیر تکامل DevOps بسیار ضروری و حیاتی است. اما چطور می توان موفقیت DevOps را ارزیابی کرد؟ چه چیزی باعث عملکرد فوق العادهی یک سازمان می شود؟ کدام شاخص های کلیدی عملکرد (KPI) این قابلیت را دارند که مشخص کنند چه چیزی برای شما خوب کار می کند و چه چیزی خیر – و اطلاعاتی برای توضیح علت (علت کار نکردن بعضی روش ها) فراهم کنند؟ چه چیزهایی را ارزیابی می کنید، چطور آن ها را ارزیابی می کنید و این اعداد دقیقا چه چیزی را نشان می دهند؟
این مقاله یازده شاخص کلیدی عملکرد را مشخص کرده که فنداسیون لازم برای معیارهای DevOps را ایجاد می کنند، رشته ای که همگام با تکامل روش های DevOps بیشتر و بیشتر درون شرکت هایی در انواع مختلف تنیده می شود. این یازده شاخص را در پست بعدی معرفی و بررسی خواهیم کرد.
برای تعیین بهترین شاخص های کلیدی عملکرد (KPI) جهت ارزیابی DevOps، شرکت Hewlett Packard Enterprise Software Services (به اختصار HPE) در ابتدا بزرگترین چالش های ارائه نرم افزار را که مشتریان گزارش شده بود را بررسی کرده است:
هر یک از این چالش ها به تنهایی می تواند موانعی برای یک شرکت در جهت برآورده کردن خواسته های کاربران ایجاد کند. هر یک از این چالش ها به تنهایی، در توانایی یک شرکت برای برآورده سازی تقاضاهای کاربران مانع ایجاد می کند. اما تقریبا هر شرکتی حداقل با سه یا چهار مورد از این چالش ها روبرو می شود و خیلی از شرکت ها با تمام این پنج چالش روبرو می شوند. جای تعجب نیست که خیلی از تیم های نرم افزاری اطلاع ندارند که کجا یا چطور شروع به اصلاح مشکلاتشان کنند.
شرکت HPE ریشه این مشکلات را چهار حوزه متفاوت می داند:
DevOps می تواند تمام این چهار مورد را بدون از دست رفتن هیچکدام برآورده کند. موفقیت در هر یک از این چهار حوزه می تواند زمان عرضه به بازار، تجربیات کاربر، هزینه، پیش بینی پذیری و امنیت را کاملاً بهبود ببخشد.
شرکت HPE، رهبری تعریف معیارهایی که شرکت های امروزی باید ارزیابی و نظارت کنند را بر عهده گرفته است. بعضی از بزرگترین مشتریان DevOps در حال حاضر این فریم ورک را قبول و پیاده سازی کردهاند.
سرعت (Velocity) : نرخ ارائه تغییرات نرم افزاری توسط یک سازمان را ارزیابی می کند.
کیفیت (Quality) : ارزیابی می کند که تغییرات نرم افزاری ارائه شده چقدر نیازهای کسب و کار را برآورده و در جهت رضایت عمل می کنند.
بهره وری (Productivity) : ظرفیت و کارایی یک سازمان در تحویل تغییرات نرم افزاری را ارزیابی می کند.
امنیت (Security) : آسیب پذیری هایی که هنگام تحویل تغییرات نرم افزاری نمایان می شوند را ارزیابی می کند.
سرعت، کیفیت، بهره وری و امنیت به یکدیگر وابسته اند. بهبود یک حوزه منجر به بهبود در سه حوزه دیگر می شود بدون این که نیازی به tradeoff باشد.
مهم ترین ویژگی DevOps سرعت است. DevOps به عنوان راهی برای عرضه سریع امکانات جدید توسط توسعه دهندگان در پاسخ به تقاضای کاربران برای محتوای سریع تر و بهتر، ایجاد شده است. و با توجه به اینکه سرعت، امری نسبی است –احتمالا همیشه می خواهید که سریع تر و سریع تر از قبل باشید– بیشتر تیم های توسعه دهنده فراموش می کنند که به دنبال چه هدفی هستند.
با اندازه گیری و ارزیابی سرعت متوجه می شوید که آیا در حال افزایش سرعت هستید یا کاهش آن و یا اینکه در یک الگوی خاص گرفتار شده اید. همچنین می توانید به بیزینس کمک کنید که به طور واضحتری میزان پاسخگویی بخش IT را مشخص کند.
سرعت زیاد در تحویل نرم افزار، علاوه بر ایجاد مزیت رقابتی برای شرکت، نحوه تعامل کسب و کار با بخش IT را هم بهبود می بخشد.
طبق نظرسنجی ای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)
کیفیت چیزی نیست که قابل حدس زدن باشد. بلکه باید آن را توسط معیارهای خاص تعریف و بر این اساس بر آن نظارت کرد.
همه ی هدف و تمرکز DevOps این است که به سازمان های فناوری اطلاعات کمک کند تا ارزش بیشتری برای بیزینس ایجاد کند. اما در صورتیکه تلاش های شما بخوبی با بیزینس هماهنگ نشده باشد، هر چقدر هم سریع بتوانید نرم افزارهایی با کیفیت عرضه کنید، این امر (ایجاد ارزش برای بیزینس) میسر نمی شود.
در صورتیکه DevOps درست اعمال شود، سازمان ها شاهد افزایش سرعت و کیفیت بدون افزایش هزینه ها خواهند بود. در حقیقت با کوتاه کردن چرخه ها، شما شاهد افزایش ارزش های کسب و کاری خواهید بود. ارزیابی و نظارت بر معیارهای بهره وری، یک چرخهی بازخورد (feedback loop) برای بخش IT ایجاد می کند. بدین ترتیب تمرکز خود را بر ایجاد ویژگی هایی که مورد استفاده کاربران است می گذارید و در نتیجه اتلاف منابع کمتر صورت می گیرد و و ارزش بیزینسی افزایش می یابد.
سرعت اهمیت زیادی در 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”
2–3Source: Gartner, “Survey Analysis: DevOps Adoption Survey Results,” September 2015