DevOps ظرفیت تغییر در فرهنگ و فرآیند و ابزار هایی که با آنها محصولات نرم افزاری تولید می شود را دارد. همانطور که حرکت از مدلهای قدیمی کاری به دیجیتال باعث تغییر در فرهنگ کاری و مدل تجارت کسب و کارها شده، حرکت به سمت DevOps نیز یک تغییر کوچک در بخشی از سازمان نیست.
شاید اولین سوالی که در زمینه DevOps Transformation مطرح می شود چرایی و شرح مراحل لازم جهت انجام این مهم است. در این سند سعی شده با ارائه یک مثال نحوه نگرش مورد نیاز سازمان و اهمیت این موضوع شرح داده شود.
تصویر زیر نمایش دهنده مدل معمول سازمانها جهت انجام پروژه می باشد. سازمان تصمیم به پیاده سازی Agile Transformation می گیرد. آیا سایر بخش های سازمان از شنیدن این موضوع خوشحال هستند؟ معمولا جواب این سوال خیر است.
تمام فلسفه Agile ارتباط بهتر بین مهندسان و بیزینس است و این موضوع می تواند برای تیم بیزینس مشکل ساز باشد زیرا این تیم باید همواره در کنار مهندسان حضور داشته باشد، همچنین تیم Operation هم با افزایش تعداد تغییرات روزانه روبرو خواهد شد.
نتیجه ایجاد مانعی به نام Change management process بود و وظیفه این فرآیند اطمینان از این موضوع است که هیچوقت چیزی تغییر نخواهد کرد! این رویکرد و سایر فرآیندها وfunction های موجود در ITIL V3 باعث بروز مشکلات متعدد برای تیم های توسعه شد.
جهت رفع این مشکلات DevOps طراحی شد. نحوه تفکر ما درباره devops نباید به شکل یک تعریف باشد بلکه تاریخچه و چرایی ایجاد دوآپس باید مورد نظر قرار گیرد.
حرکت DevOps توسط مجموعه ایی از افراد شکل گرفت که هدف آنها حل مشکلی بود که تاکنون بدون پاسخ باقی مانده بود.
How we build large scale distributed reliable, secure systems and be able to keep making changes to them while keeping them secure & reliable
مشکل مطرح شده دارای جوابی ساده نیست و ما نیازمند ابزارهایی جهت کمک به رفع آن هستیم. در سالهای آتی هر موسسه ایی شروع به بررسی روشهای مختلفی جهت حل مشکل مطرح شده نمود، و سپس روشهای مختلف پیاده سازی بررسی شد تا Best Practice های مرتبط با حل مشکل مشخص شوند.
کشف اول:
Software delivery شما بر روی business شما تاثیر گذار است. شرکتهایی که فرآیند Software delivery بهتری داشتند ۲ برابر شانس بیشتری جهت گذر از اهداف تجاری خود داشتند. این اهداف شامل سودآوری، سهم بازار، بهینه بودن، اهداف مرتبط با ماموریت سازمان و مشتری هستند.
کشف دوم:
نحوه اندازه گیری performance باید از دو روش زیر صورت گیرد.
اندازه گیری speed یا throughput بر اساس دو معیار Lead time for change (از ورژن کنترل تا محیط production) و Release frequency (تعداد انتشار محصول در بازه زمانی مشخص) خواهد بود.
اندازه گیری stability بر اساس دو معیار Time to restore service (مدت زمان بازگرداندن سرویس به حالت فعال) و Change fail rate (درصدی از پابلیش ها که باعث بروز مشکل شده و نیاز به rollback یا پابلیش دیگری برای رفع مشکل بوده اند)
با شنیدن نام DevOps اکثر افراد به ابزار یا تغییر ساختار سازمانی فکر می کنند، اما پیغام اصلی DevOps Transformation فرهنگ و Architecture است. تغییر ساختار سازمانی راه مناسبی برای پیاده سازی DevOps نبوده و ابزارها نیز به خودی خود مشکلات را رفع نخواهد کرد.
این سوال مطرح می شود که DevOps چیست؟
مهم ترین و سخت ترین چیزی که باید یاد گرفت این است که چطور هر کاری را که انجام می دهیم به صورت iterative و در گام های کوچک باشد. نه تنها برای توسعه محصول بلکه در سایر مراحل مثل تغییر معماری، تغییر سازمان، تغییر فرهنگ. مدلی که سازمان های ما طراحی شده اند با این نوع تفکر همخوانی ندارد، بودجه های سالانه، مدیران اجرایی با زمان کم جهت نمایش توانایی های خود و در نتیجه تلاش آنها از طریق تعریف پروژه های بزرگ با زمان و بودجه محدود، با این روش نمی توان تغییرات ماندنی ایجاد نمود. تغییراتی که باقی می مانند از طریق برداشتن قدم های کوچک و تمرین و پیدا کردن مسیر درست و یادگیری مداوم به دست می آیند. شاید این مدل از ایجاد تغییرات مثل پروژه های بزرگ Big Bang جلب توجه نکند ولی احتمال موفقیت آن بسیار بیشتر است.
مثال کلاسیک اول این موضوع پروژه ها هستند. ما معمولا در محدوده پروژه ها کار می کنیم زیرا بودجه بندی های بر اساس پروژه این موضوع را تشویق می کند. جهت بررسی مشکلاتی که این مدل تفکر می تواند برای سازمان ایجاد کند سندی به نام Black swan farming تهیه شد که نتیجه تحقیق در یک شرکت کشتیرانی دانمارکی به نام Maersk است. در این تحقیق back log این شرکت با بیش از ۳۰۰۰ فیچر که منتظر develop بودند مورد بررسی قرار گرفت. مدل بررسی بر اساس Opportunity Cost مرتبط با عدم ارائه فیچر در نظر گرفته شد، عدم ارائه feature در هر هفته چقدر برای Maersk هزینه خواهد داشت ( یکی از روش های اولویت بندی به نام Cost of delay ).
نتیجه به دست آمده این بود که در میان ۳۰۰۰ فیچر موجود، ۳ فیچر وجود دارند که عدم ارائه آنها به سازمان هزینه هفتگی بالغ بر ۲ میلیون دلار به سازمان تحمیل می کند. این ۳ فیچر بخشی از یک project plan بزرگ بوده و قابل مشاهده نبودند، بعد از این موضوع تمام کارها متوقف شده و اولویت سازمان هرچه زودتر آماده شدن ۳ فیچر بود.
در تمام پروژه ها، بخش کوچکی از فیچرها برای سازمان بسیار مهم هستند و این اهمیت غیر قابل مشاهده است، یکی از مسائلی که ما باید آن را رها کنیم ایده کار کردن در قالب پروژه است. تیم باید توجه خود را معطوف به مهم ترین نیازمندی ها کند و اینکار نیازمند تمرکز و شفافیت و اولویت بندی شفاف است.
مثال دوم موضوع باز طراحی معماری یا Re Architecture است، همه ما پروژه های باز طراحی معماری زیادی را حتی در ایران مشاهده کردیم که پس از ۲ یا ۳ سال بدون نتیجه مشخصی با شکست مواجه شده اند و مجددا یک پروژه چند ساله برای باز طراحی معماری تعریف شده است. یکی از مشکلات این نوع پروژه ها تمرکز بر تکنولوژی به جای outcome است.
افرادی که می توانند به سوال های زیر جواب مثبت دهند احتمال موفقیتشان در پیاده سازی Continuous Delivery و DevOps و رسیدن به سطح Performance بالا بسیار بیشتر است.
- آیا تیم من می تواند تغییرات بزرگی در طراحی سیستم ایجاد کند بدون اینکه از شخصی بیرون از تیم اجازه بگیرد و یا به تیم دیگری وابستگی داشته باشد؟
- آیا تیم من می تواند کارش را بدون نیاز به راهنمایی و ارتباط با شخصی خارج از تیم تمام کند؟
- آیا تیم من می تواند Deploy و Release محصولات و سرویس های خود را مستقلا و بدون نیاز به سایر محصولات و سرویس هایی که به آنها وابسته است انجام دهد؟
- آیا تیم من می تواند بیشتر test ها را به صورت On demand و بدون نیاز به محیط پیچیده برای تست انجام دهد؟
- آیا تیم من می تواند Deployment نسخه جدید محصول و سرویس را در ساعات کاری معمول بدون بروز down time صورت دهد؟
نکته پر اهمیت این است که شما می توانید با استفاده از MainFrame هم به خروجی های بالا برسید، و می توانید از ابزارهای جدید و جذاب استفاده کنید ولی به خروجی های بالا نرسید.