پایه و اساس DevOps ، تغییر است. Keep CALMS !
به وسیله DevOps، کسانی که با آخرین ابزارهای توسعه کار میکنند، محتاطانه عمل نمی کنند. DevOps علاوه بر افراد و فرایند ها، به ابزارها هم اهمیت می دهد و روش های مختلفی برای گرد هم آوردن این سه مجموعه در کنار هم ایجاد می کند.
کافی است تا عبارت “DevOps” را در google جستجو کنید تا دیاگرام ها و متدولوژی های بسیاری را پیدا کنید که هر کدام از آن ها جنبه ی متفاوتی را برجسته کرده اند. اما می توان گفت که همه ی آن ها در موارد زیر با هم مشترک اند:
- فرهنگ سازی | Culture
- خودکارسازی | Automation
- تفکر ناب | Lean thinking
- اندازه گیری همه چیز | Measurement
- اشتراک گذاری | Sharing
به این چهار مورد اصول یا چارچوب CALMS در DevOps می گویند.
چارچوب CALMS در DevOps چیست ؟
چارچوب CALMS را می توان در پنج واژه ی فرهنگ سازی، خودکارسازی، تفکر ناب، اندازه گیری و اشتراک گذاری برشمرد. (این موضوع در برخی مطالب با عنوان “اصول CALMS در DevOps چیست” مطرح شده است که چارچوب صحیح تر است، در آینده در مطلبی جداگانه اصول DevOps را معرفی خواهم کرد)
Culture | فرهنگ
همه میدانیم فرهنگ چیزی نیست که یک نفر بتواند آن را پیاده سازی کند. فرهنگ در یک محیط طبیعی که شامل سرتاسر تیم تولید نرم افزار می شود وجود دارد. منظور از سرتاسر همه ی افراد است از جمله توسعه دهندگان (Development)، تضمین کنندگان کیفیت (QA) و تیم های عملیات (Operation) و … . در چنین اکوسیستمی که متشکل از مجموعه ای از افراد و ابزارها است، برای رفع موانع و تسهیل همکاری برای دستیابی به اهداف نهایی، یک کار فرهنگی لازم است.
هیچ چیز زشت درباره فرهنگ وجود ندارد.
فرهنگ سازمانی نقش اساسی در موفقیت یک کسب و کار ایفا می کند، به همین دلیل پرداختن به آن بسیار مهم و ضروری است. فرهنگ در DevOps، یک خط قرمز است. زمان صرف شده در فعالیت های غیر ضروری، سیلوهای مسوولیت، دیوار بین تیم ها و تعاملات نامناسب از جمله مهمترین موانع در رسیدن یک سازمان به اهدافش هستند. DevOps توصیه می کند که تیم ها را از سیلو هایشان خارج کنید و دیوار بین آن ها را بشکنید تا با هم تعامل بهتری داشته باشند. با همسو کردن اهداف متفاوت تیم ها، به هدف اصلی سازمان یعنی ایجاد و تحویل ارزش به برسید.
Automation | خودکارسازی :
هنگامی که فرهنگ سازی در سازمان انجام شد، می توانید بر خودکارسازی یا اتوماسیون تمرکز کنید. اتوماسیون تنها به نوشتن Script ها و استفاده از Unit Test ها یا Functional Test ها محدود نمی شود. خودکارسازی شامل همه قسمت ها از جمله Continuous-Integration ، Continuous-Delivery/Deployment، Infrastructure-Automation و هر جای دیگری می شود.
با راه اندازی Automation می توانید برای همه چیز برنامه ریزی کنید.
فرایند های دستی بسیار کند و مستعد خطای انسانی هستند. راهی برای رهبری تمامی ابتکارات جدید به وسیله اتوماسیون پیدا کنید و برای رسیدن به مقیاس های بزرگتر به طور مستمر به اتوماسیون فکر کنید.
Lean | ناب:
بعد از راه اندازی اتوماسیون، به یاد داشته باشید که همچنان ناب بمانید و اصول تولید ناب نرم افزار را رعایت کنید.
اجرای Lean به معنی نگه داشتن همه چیز در حداقل است.
ابزارها، جلسات و حتی iteration ها و همه چیز دیگر باید Lean باشد یعنی در حداقل ممکن باشد. تفکر ناب یعنی ارزش محور بودن فعالیت ها و کاهش فعالیت های اضافه و در حداقل نگه داشتن همه چیز. این هم بخشی از فرهنگ DevOps است. وقتی شما ناب هستید، برای هر ابزار، و روشی که انتخاب می کنید، هدفی دارید.
ناب بودن تنها به یک یا چند فرد محدود نمی شود و شامل همه ی تیم ها و افراد می شود.
باید تیم را در اندازه ای نگه داشت که بیشترین کارایی را داشته باشد. یک آشپزخانه با آشپزهای بیش از حد، بازده کمی خواهد داشت. اگر پیچیدگی اپلیکیشن به گونه ای باشد که نیاز به تیم های بزرگ باشد، تیم را به زیرگروه های کوچکتر تقسیم کنید، همانطور که سازمان های بزرگ این کار را می کنند. (spotify یکی از موفق ترین مثال ها در این زمینه است)
Measurement | اندازه گیری :
اندازه گیری مانند چسبی است که همه چیز را در کنار هم قرار می دهد. زمانی شما یک سازمان چابک و ناب هستید که همه چیز را اتوماتیک می کنید، ممکن است که توانایی به خاطر سپردن و مستند سازی را از دست بدهید.
اگر تیمی در همه موارد شفافیت لازم را نداشته باشد و کارها اندازه گیری نشوند، در نهایت اشتباهات بزرگی رخ خواهد داد.
اگر اندازه گیری به روش صحیحی انجام شود، اشتباهات بزرگ رخ نمی دهد. در صورت اندازه گیری و گزارش گیری در همه ی تیم ها و فرایند ها است که قادر به تجزیه و تحلیل ارتباط بین فرایند ها، ابزارها و داده های محصولات در کنار خواهید بود. اندازه گیری به شما کمک می کند که نقاط ضعف را بشناسید و در جهت بهبود آن گام بردارید و در نهایت بتوانید روند پیشرفت را پایش کنید.
با این وجود نمی توانید با یک excel ساده این کار را انجام داد. در یک سازمان ناب، شما فرصت ندارید که همه چیز را به صورت دستی و غیر اتوماتیک ثبت کنید. این کار بسیار زمان گیر و مستعد خطای انسانی است.
اندازه گیری و جمع آوری داده ها باید با ابزارهای پیشرفته تری انجام شود. ابزارهایی که شامل قابلیت هایی فراتر از نظارت و گزارش گیری رویدادها هستند و می توانند بینش جدیدی به شما انتقال دهند. به این ترتیب می توانید از فکر کردن به نحوه دریافت و ثبت اطلاعات در عملیات مهم جلوگیری کنید و آن را به ابزارهایی با بستر مناسب بسپارید. بعد از آن که متوجه شدید به چه چیزهایی باید به طور مستمر نظارت داشته باشید، می توانید یک داشبورد بسازید که گویای تمام اطلاعات مهم و مورد نیاز باشد.
Sharing | به اشتراک گذاری :
بعد از آنکه داده ها را جمع آوری کردید، باید اشتباهات و نحوه ی جلوگیری از آن و دانش جدیدی که از این راه بدست آوردید را منتشر کنید.
ایجاد جریان اطلاعات دوطرفه یکی از مزیت های شکستن دیوار بین تیم ها می باشد و باعث جلوگیری از انداختن توپ در زمین تیم دیگر می شود. با این وجود اگر اطلاعات به صورت proactive و فعالانه به اشتراک گذاشته نشوند، ارزشی نخواهند داشت.
Sharing و Reporting کاملا با هم متفاوت هستند، Sharing تنها گزارش واقعیات نیست، بلکه مبادله ی ایده ها در سر تا سر تیم ها و به طور دائمی است. Reporting معمولا به صورت انفعالی (reactive) اتفاق می افتد در حالی که Sharing به صورت فعالانه و proactive می باشد.
توسعه دهندگان می توانند به تیم های QA و عملیات، ابزارهای جدیدی برای ارتقا کیفیت محصول پیشنهاد بدهند، و تیم عملیات می تواند پیشنهاد ایجاد قابلیت هایی در نرم افزار را به تیم توسعه بدهد تا به مدیریت بهتر محصول کمک کند.
چارچوب CALMS در DevOps برای آزادسازی خلاقیت ها است نه ردیابی عملکرد افراد
تمامی جریان های DevOps از جمله CALMS، مانند یک نقشه راه هستند، نه تعریف تمامی گام های لازم برای رسیدن به هدف. اگر با راهنما پیش بروید، حتما به هدف خواهید رسید، هر چند با راهکارها و گام های متفاوت.
چیزی که در توصیف CALMS از DevOps منحصر به فرد است، تاکید بر بعد فرهنگی DevOps است.
از CALMS برای رها سازی جهت بروز خلاقیت ها استفاده کنید، نه برای ردیابی عملکرد افراد
فرهنگ سازی، هیچوقت کار آسانی نبوده و نخواهد بود. برای شکل گیری فرهنگ و جا افتادن آن در سازمان زمان لازم است. در ابتدا این کار سخت است و ممکن است با ناسازگاری هایی روبرو شوید، اما بعد از مدتی به یک عادت تبدیل می شود.
CALMS یک نقشه راه است، نه تعریف تمامی گام ها و جزئیات لازم برای رسیدن به هدف، پس به یاد داشته باشید که به تنهایی کافی نیست.
برخی از موارد که در چارچوب CALMS به آن اشاره نشده است
داشتن iteration و ضرب آهنگ منظم و همچنین نتیجه گرا بودن، از موارد مهمی هستند که در CALMS به آن ها اشاره نشده است و می تواند مکمل CALMS باشند. از موارد دیگری که در CALMS به آن اشاره نشده، Security و امنیت محصول است، اما قطعا DevOps امنیت محصول را بهبود می دهد. تمامی موارد اشاره شده شامل بعد فرهنگی و فناوری می باشند.
به طور طبیعی اگر شما نتیجه گرا باشید، ذهن تحلیلگری دارید و با افرادی که همکاری خوبی با هم دارند و دارای تفکر ناب هستند، سریع تر به نتیجه خواهید رسید. برای اجرای این چارچوب، باید پیشرفت خود را در بازه های زمانی کوچک، با سرعت مناسب و به طور مستمر ارزیابی کنید. این قطعات می تواند iteration ها باشند.
این تمرین مهم است نه به این دلیل که CALMS باید به یک استاندارد تبدیل شود یا نه، به این دلیل که زمانی که جنبش های جدیدی به وجود می آیند (مانند جنبش DevOps)، باید مسیری از عادت به عملکرد فعالانه وجود داشته باشد. CALMS به کسانی که با Operations زندگی کرده اند و همچنین کسانی که حتی نمی دانند Operations چیست کمک می کند.
تفاوت CALMS و ITSM
کسانی است که با ITSM آشنایی دارند ممکن است دچار این چالش ذهنی بشوند که تفاوت DevOps و ITSM چیست؟ آیا DevOps یک راهکار جایگزین برای ITSM است؟
اگر با مشاهده مثال ها و اسناد ITSM تفاوت ها به وضوح مشخص نبود، کلمه ی اختصاری CALMS در یک نگاه سریع به تشریح تفاوت های این روش ها کمک می کند. همانطور که مشاهده می کنید، فرهنگ اولین گام است، با مشاهده گزینه های بعدی، به سرعت مشخص می شود که نمی توان هیچ مقایسه ی مورد به موردی برای ITSM و DevOps داشت.
ITSM به طور کلی بر مستندسازی، کنترل تغییرات، و تکرارپذیری تمرکز دارد، در حالی که DevOps بر افرادی که این نتایج را بدیت می آورند تمرکز دارد. یک مولفه اصلی در ITSM، تکرارپذیر بودن است، اما ساختار و فرایند ها اهداف اصلی نیستند.
