تو این پست میخوام در مورد دواپس صحبت کنم. چیزی که خیلی بهمون کمک میکنه تا چرخهی تولید نرمافزار رو خیلی بهینه و با کیفیت بیشتری پیش ببریم.
دواپس یک فرهنگه که شامل یکسری اصول هست که با رعایت آنها میتونیم فرآیند توسعهی نرمافزار خودمون رو بهبود بدیم و در نتیجهی پیادهسازی صحیح آن بتونیم زندگی راحتتری رو هم برای خودمون هم برای محصولمون فراهم کنیم. از نظر من محصول یک موجود زنده است که نیاز داره بهش پرداخته بشه و شرایط لازم برای ادامهی زندگیش فراهم بشه و دواپس کمک میکنه که چرخهی زندگی یک محصول بهتر و صحیحتر پیش بره.
پس دواپس شد یک سری مجموعه رفتار (فرهنگ) و اصول که به ما کمک میکنه که محصول خودمون رو بهینه توسعه بدیم و در زمانهایی که نیاز داریم اون رو رشد بدیم و بزرگش کنیم.
قبلتر به این صورت بود که تیمهای توسعه (Development) و استقرار و نگهداری (Operation) از هم مستقل بودن و هر کدوم کار خودشون رو میکردن و درک درستی از هم نداشتن. به گونهای که تیم توسعه نسبت به پایداری سرویس روی پروداکشن، خودش رو پاسخگو نمیدونست و تیم اپریشن هم دوست داشت به چیزی دست نزنه و در برابر هر تغییری مقاوت داشتن. کلا فضای تعامل بین این دو تا تیم وجود نداشت و هر تیمی که زورش تو سازمان بیشتر بود میتونست حرف خودش رو به کرسی بنشونه و کارش رو پیش ببره.
مثلا تیم توسعه یا بهتر بگم دولوپر پروژه میگفت سرویس تو کامپیوتر من داره درست کار میکنه پس حله در صورتی که کامپیوتر اون پر از دیپندنسیها و لایبریهای مختلفی بود که در طول زمان جمع شده بودند و بیچاره اون سیسادمینی که میخواست اون کد رو تو پروداکشن استقرار بده و نگه داره.
یا مثلا تو سیسادمینها این جمله خیلی محبوب بود که چیزی که کار میکنه رو دست بهش نزن یعنی تا زمانی که مجبور نمیشدن دست به سیستمها و به روزرسانی اونها نمیزدن. اگر زورشون تو سازمان هم میچربید دیگه تیم توسعه برای هر تغییری که داشت باید کلی دردسر میکشید و دست و پا میزد تا بتونه روی پروداکشن اعمالش کنه.
همانطور که مشخصه فضای خوبی حاکم نبود و انگار نه انگار که اینها تو یه شرکت و برای یک هدف دارن باهم کار میکنند. اصتلاحا هزینهی تعامل این دو تا تیم تو سازمان خیلی زیاد بود و هیچکدوم از کار همدیگه درک خوبی نداشتن. با توجه به تعارض بین این دو تا تیم هزینهی توسعهی نرمافزار در سازمان خیلی زیاد بود و مشکلات متعددی رو به همراه داشت. از این رو دواپس که ترکیبی از تیم توسعه و اپریشن هست ایجاد شد تا بتونه این فضا رو بهبود بده و دیوار مجازی که بین این دو تا تیم هست رو بر داره. این رویکرد نسبت به تمام چرخهی تولید نرمافزار خودش رو مسئول میدونست و از ابتدای تا انتهای این چرخه رو مدیریت میکرد.
تیم دواپس به کل فرآیند توسعه و استقرار نرمافزار پاسخگو هست و تو تمام فرآیند حسب پروژه و سازمان میتونه وارد بشه و نفوذ کنه تا اون رو بهبود بده تا تولید نرمافزار و استقرار اون به خوبی پیش بره.
یه نکتهی مهم دیگه اینکه با روشهای سنتی، مقیاسپذیری (Scalability) نرمافزار با مشکلات متعددی همراه شده بود که دیگه نمیشد با همون روش سنتی ادامه داد و نیازمند به یه رویکرد جدید برای بهبود آن بودیم.
دواپس یک فرهنگه و هر سازمان به فراخور خودش و مواردی که داره به گونهای اون رو پیادهسازی میکنه. نمیشه برای همهی سازمانهای یه نسخهی مشترک پیچید و هر سازمان تعریف خودش رو از دواپس داره. البته که اصول دواپس در همهی سازمانها یکی هستش و با توجه به متریکهای دواپس میتوانیم میزان استقرار این رویکرد در هر سازمانی رو ارزیابی کنیم.
مثلا یکی از اصول دواپس اتومیشن هست که میبایست تمام اکشنهایی که لازم است اجرا شود اتومیت باشه اما هر سازمان با توجه به استکی که داره و دانش تیم دواپس میتونه از ابزار مد نظر خودش برای این کار استفاده کنه. مثلا یکی از ansible استفاده میکنه یکی دیگه از salt یا chef یا هر چیزی دیگه ولی مهم اینه که اتومیشن وجود دارد و تمام اکشنها به صورت خودکار انجام میشه.
علاوه بر مهارتهای سخت (Hard Skills) مهارتهای نرم (Soft Skills) نیز در دواپس خیلی اهمیت داره و فردی که میخواد کار دواپس انجام بده باید روی مهارتهای نرم خودش هم تمرکز کنه و هواره تلاش کنه که اونها رو هم رشد بده. به عنوان مثال میتونیم به کار تو تیم (Team Working)، توانایی حل مسائله، همکاری (Collaboration)، مدیریت احساسات، گفتگو و … اشاره کرد.
تا اینجا یه سری دلایل گفتیم که چرا دواپس لازمه اما اگر بخواهیم دقیقتر بررسی کنیم میتونیم به این موارد اشاره کنیم:
دواپس دارای مزایای متعددی است که به برخی از آنها اشاره میکنم:
دواپس دارای یک سری اصول است که رد پای اونها رو میتونید تو همهجا دنبال کنید و همواره این اصول بین تمام سازمانها مشترک خواهد بود. در ادامه به برخی از آنها اشاره میکنم:
البته تعداد اصول دواپس میتونه بیشتر از این موارد باشه که من سعی کردم مهمترین اصول دواپس رو اینجا لیست کنم و در ادامه یکم بیشتر به اونها میپردازم:
به صورت کلی دواپس کمک میکنه که تعامل بین تیمها و افراد بیشتر بشه. از اون جهت که دیگه اون دیوار مجازی بینشون نیست و دارن تو یه تیم باهم کار میکنند در نتیجه تعامل و همکاری خیلی بیشتری باهم دارند. یه نکتهی مهم دیگه این که قبلا هم بهش اشاره کردیم دواپس نیاز به مهارتهای نرم هم مضاف بر مهارتهای سخت داره. یک فردی که داره تو تیم دواپس کار میکنه باید بتونه به خوبی با دیگران تعامل کنه و ارتباط برقرار کنه. خیلی از موضوعات میتونه با گفتگو برطرف بشه در صورتی که اگر تعامل درستی پیرامون اون شکل نگیره خودش به مشکل بزرگی مبدل بشه.
پاسخگویی خیلی آیتم مهمی است. شما وقتی پیرامون موضوعی پاسخگو باشید رفتارتون نسبت به اون موضوع تغییر میکنه و میتونید اقدامات خیلی بهتری رو برنامهریزی کنید. قبلا مشکل این بود که تیم اپریشن پیرامون انتشار نرمافزار و کارایی اون پاسخگو نبود و تیم توسعه پیرامون استقرار و پایداری سرویس روی پروداکشن پاسخگو نبود. اما الان تیم دواپس پیرامون تولید، کارایی نرمافزار، انتشار، استقرار و نگهداری آن پاسخگو میباشد و برای بهبود تمام این مسیر برنامهریزی میکند.
یکی از مهمترین اصولی است که میشه در موردش صحبت کرد. یه جمله هست که میگه اگر قراره کاری رو دوبار انجام بدم حتما اتومیتش میکنم. اتومیشن و خودکارسازی خیلی تو دواپس اهمیت داره و تقریبا ما تمام کارهایی که انجام میدیم رو خودکار میکنیم و بعدش تمرکز اصلی خودمون رو روی اتومیشنها و بهتر کردن اونها قرار میدیم. هر چقدر هم یک کار جذاب باشه اگر به دفعات زیادی انجام بشه کسالت آور میشه و به نظرم من کلا کار تکراری برای انسان نیست و باید ماشین اون رو انجام بده. انسانها خوبه که ماشینها رو مدیریت کنند و ماشینها و ابزارها کارهای تکراری رو انجام بدن.
برای این کار ابزارهای مختلفی در اختیارمون هست. به عنوان مثال میتونیم نصب و کانفیگ ابزارهای مورد نیاز رو با Configuration Managementها انجام بدیم یا اینکه با استفاده از CI/CD تمام فرآیند تولید تا نگهداری نرمافزار رو کامل خودکار کنیم. یا اینکه کاملا کل زیرساخت خودمون رو با استفاده از Infrastructure as code پیادهسازی کنیم. یا اینکه با استفاده از اسکریپتینگ برخی از اکشنهایی که دیگه با هیچ ابزاری نخواستیم یا نمیشد خودکار کنیم رو اتومیت کنیم. بازم تکرار میکنم در این حد که اگر کاری رو قراره دو بار انجام بدیم اون رو خودکار میکنیم.
یکی از مزایای استفاده از اتومیشن و خودکارسازی تمام فرآیندها اینه که میتونیم به راحتی کارها رو به دیگران منتقل کنیم و اصتلاحا تراک فکتور (Truck Factor) ما رو کاهش میده. یعنی دیگه به شخص خاصی وابسته نیستم. یکی دیگه از مزایای اتومیشن اینه که خودش میتونه داکیومنت هم باشه. معمولا گرفتن داکیومنت از آدمهای فنی کار سختی هست اما اتومیشن میتونه داکیومنت خوبی برای سرویس ما باشه. به صورت کلی وقتی فرآیندی رو اتومیت میکنیم اون رو قابل انتقال به دیگران، قابل تکرار و قابل بهبود کردیم که این خیلی به ما کمک میکنه.
بهبود مستمر اصلی است که خوبه آدم تو زندگی شخصی خودش هم همواره اون رو رعایت کنه. همواره هر چند کوچیک اما مستمر بهبود در سرویسها و سامانهها ایجاد میکنیم که در بلندمدت نتایج به صورت کامل متفاوت خواهد بود. وقتی کار گِل کمتری داشته باشیم زمان داریم که بتونیم فرآیندها و اتومیشنهای خودمون رو بهتر کنیم. به صورت کلی بهبود مستمر تنها راه نجات ما خواهد بود که همواره ما رو رشد میده و بهتر میکنه. به صورت کلی یه جمله هست که میگه کارهای ما رو ماشینها انجام میده و ما اونها رو مدیریت میکنیم.
اندازهگیری خیلی مهمه و ما تلاش میکنیم که همه چیز رو اندازهگیری کنیم. به صورت کلی هر چیزی که بتونیم اندازه بگیریم و بسنجیم میتونیم مدیریتش کنیم و اون رو بهتر کنیم. در نتیجه ما تلاش میکنیم که همه چیز رو اندازه بگیریم. خود دواپس متریکهایی داره که باهاش میزان پیادهسازی دواپس تو سازمان خودمون رو هم میتونیم اندازهگیری کنیم. یه نکتهی مهم دیگه اینکه تصمیمهایی که میگیریم در راستای تغییر در ساختارمون بر اساس دیتاهایی هست که داریم و تو سیستمهای مختلف اونها رو اندازه گرفتیم.
به عنوان مثال اگر بتونیم هزینهی هر دقیقه توقف (Downtime) تو سرویس خودمون رو حساب کنیم به راحتی میتونیم تصمیم بگیریم که چقدر میتونیم هزینه کنیم تا تعداد دقایق کمتری سرویسمون از دسترس خارج بشه.
مانیتورینگ و لاگینگ رو نیز بر روی تمام موارد انجام میدهیم. من میگم مانیتورینگ و لاگینگ چشم و گوش ما تو سرویسها و سرورها هستند. هر جایی که اونها رو نداشته باشیم انگار نسبت به سرویسهای خودمون غریبه هستیم و نمیتونیم ارتباط خوبی با اونها داشته باشیم. به صورت کلی سرویسها و سرورها اگر به درستی کانفیگ شده باشند خودشون دارن به ما میگن که چه مشکلی دارند و حتی خیلی زودتر هم دارن به مشکلات خودشون اشاره میکنند فقط لازمه که ما حواسمون باشه و به موقع اکشن لازم رو انجام بدیم.
تست مهمه چون به ما کمک میکنه که زودتر و در جای درستی با خطا مواجه بشیم و مواردی که اشتباه هست تو پروداکشن و به لبهی دسترسی مشتری نرسه که خیلی برای ما میتونه مطلوب باشه. به صورت کلی خوبه که همواره همه چیز رو تست کنیم و هرچقدر میزان پوشش تستهای ما بیشتر باشه میتونه بیشتر خیالمون راحت باشه که دیگه کمتر غالفگیر میشیم. یه نکتهی مهم که تو خیلی از سرویسها باهاش مواجه شدم اینه که همه میگن تست خوبه ولی برای همسایه. :) یعنی براش وقت نمیگذارن و هر موقع ازشون میپرسی میگن که زمانش رو نداریم. این دیدگاه امکان بروز خطا تو پروداکشن و در سطح مشتری رو به شدت افزایش میده تا جایی که میتونید از این نوع نگاه پرهیز کنید.
این اصل خیلی مهمه و به صورت کلی مبنای تمام تصمیمات ما را شکل میده. مثلا اینکه تو استک خودمون از چه ابزارهایی استفاده کنیم یا اینکه از چه زیرساختی برای استقرار نرمافزار خودمون کمک بگیریم یا اصلا چه تعداد مشتری رو میتونیم پشتیبانی کنیم یا هر موضوع دیگهای که نیاز به تصمیمگیری داشته باشه حتما قبلش دیتای کافی پیرامون آن یا جمعآوری میکنیم و یا ایجاد میکنید. مثلا در انتخاب ابزارها یا زیرساخت یا هر چیزی شبیه این پارامترهای مختلف رو لیست میکنیم و با انجام benchmarkهای لازم ابزار خودمون رو انتخاب میکنیم. این موارد جز داکیومنتهای پروژه میباشد و همواره تلاش میکنیم که آنها را نگهداری کنیم. یا اینکه سامانهی ما چقدر میتونه مشتری رو پشتیبانی کنه با انجام Observability ابتدا یه شهودی نسبت به اون پیدا میکنیم و سپس با انجام لود تست بررسی میکنیم که چه نقاطی هست که باید بهبود بدیم تا بتونیم ظرفیت بیشتری رو ایجاد کنیم. پس به صورت کلی تمام تصمیمات خودمون رو با دیتایی که ایجاد یا استخراج کردیم بیمه میکنید.
نکتهی مهم: سرویسهای ما همانند یک موجود زنده هستند و نیاز است که همواره پایش و نگهداری بشن. سرویسها میتونن خراب بشن و ما تمام تلاش خودمون رو میکنیم که خرابیهایی با برنامهریزی داشته باشیم تا کمترین هزینه رو ایجاد کنیم و بیشتر رضایت مشتری رو همواره داشته باشیم.
یه جملهی معروفی هست که میگه هر چیزی رو که نتونی اندازه بگیری نمیتونی مدیریتش کنی. همانطور که قبلا هم گفتیم ما میتونیم میزان استقرار دواپس را تو شرکت خودمون بررسی کنید. متریکهای دواپس به ما کمک میکند که ببنیم چقدر فرهنگ دواپس رو تو سازمان خودمون پیادهسازی کردیم. دواپس داری متریکهای زیادی است که من اینجا به این چهار تا متریک که توسط DORA داره پایش و بررسی میشه اشاره میکنم. DORA توسط Google Cloud ایجاد و دنبال میشه و شعار خیلی جالبی داره که میگه (Get Better at Getting Better) و داره تلاش میکنه با بررسیهایی که انجام میده توسعهی نرمافزار رو بهبود بده. این گروه معمولا به صورت سالانه یه سری گزارش از دواپس میده که اینجا میتونید گزارش سال ۲۰۲۳ این گروه رو مطالعه کنید.
Lead time for changes:
میزان زمانی که طول میکشه تا یه تغییر در کد روی سرویس ما دیپلوی شود. در طی این مسیر تستها ران میشود. به صورت خلاصه مدت زمانی که طول میکشد تا کد پوش شده روی سرورها دیپلوی شود. به بیان دیگه میزان زمان فرآیند بیلد، تست و دیپلوی میباشد.
Change failure rate:
نرخ تغییراتی است که روی پروداکشن اعمال شده و خراب میباشد. خرابیهای یا Failهایی که در پروسهی CI/CD رخ میدهد رو شامل نمیشود بلکه داره در مورد تغییرات خرابی صحبت میکنه که به روی پروداکشن دیپلوی شده باشد.
Time to restore service:
مدت زمانی که طول میکشه یه fail رو درستش کنیم و اصلاحش کنیم. میتونیم حتی میانگین زمان Down time مربوط به ده تا پروداکشن incident خودمون رو حساب کنیم.
Deployment frequency:
نرخ تغییراتی میباشد که روی سرویس مستقر میشود. به عبارتی به نرخ تغییرات ما و تعداد آن برمیگردد و یکی از متریکهای اصلی دواپس میباشد.
این گروه (DORA) یه چکلیست هم داره که میتونیم با استفاده از اون ارزیابی کنیم که الان سازمان ما یا سرویس و سامانهی ما تو چه وضعیتی قرار داره که به نظرم خیلی میتونه بهمون دید بده و پایش مداوم اون بهمون کمک میکنه که کارایی و کیفیت بالاتری رو تو چرخهی نرمافزار خودمون داشته باشیم. کلا نگاه خوبی داره به این موضوع و توصیه میکنم حتما بهش سر بزنید و باهاش کار کنید.
سعی کردم تو این متن یه گذری هر چند کوتاه روی مفاهیم اصلی دواپس داشته باشیم. حتما لازمه که بیشتر در موردش بدونیم و بخونیم. حتما تو یه پست دیگه در مورد مسیر آموزش دواپس و ابزارهای متنوع این حوزه باهاتون صحبت میکنم.