در مسیر دواپس با من همراه شو!

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

چیزی که این روزها برای ما کاربرهای حوزه تکنولوژی جذابه، شاید یکی مطالب مربوط به مشخص شدن Roadmap باشه(برای تازه‌کارها) و جذاب‌تر از اون، مطالبی که توش درمورد چالش‌هامون صحبت میکنیم و بررسیشون میکنیم و حلشون میکنیم؛ مثل بلاگ‌های فنیِ بچه‌های اسنپ، کافه‌بازار و... که توش از چالشی که براشون توی پروژه پیش اومد صحبت میکنند، نحوه بررسی اون چالش و ابعاد مختلف موضوع رو شرح میدن و در نهایت میگن که چطور براش راهکار پیدا کردن و اون راهکار رو به چه شکلی پیاده‌سازی کردن؛ به شخصه برای منم اینجور مقالات که تجربیات رو منتقل میکنه خیلی مفیدتر و جذاب تره؛ حالا خوشحال میشم شماهم بگین که نظرتون درمورد این موضوع چیه و چه مطالبی رو احساس میکنید الان بیشتر میتونه براتون مفید واقع بشه؟

گرچه گاهی مواقع، مطالبی که توش چیزهای جدید هم شرح داده میشه و معرفی میشه هم میتونه جذاب و مفید باشه؛ مثل این مطلب که میخوام توش، به برداشت و دیدگاه خودم بگم دواپس چیه؟

چرا؟ چون خیلی از دوستانم ازم میپرسن که دواپس دقیقا چیه و چیکار میکنه و تنبل تر از این حرفان که برن سرچ کنن و مطالب دیگه رو بخونن... یا شایدم میخونن ولی هنوز یکسری چیزا براشون گنگ و حل نشدس(همونطور که برای من هم در اوایل یکسری مسائل حل نشده بود و الان هم همچنان مسائلی هست که حل نشدن هنوز واسم!)، در نتیجه گفتم یکبار به زبون خودم و به برداشت خودم، بگم که داستان چیه، شاید اگر دو روز دیگه یکنفر دیگه هم ازم پرسید دقیقا داری چیکار میکنی توی محل کارت، بتونم بهش لینک بدم بگم بیا این مطلب رو بخون متوجه شی :)).

سعی میکنم چیزای تکراری ننویسم مثل مطالب دیگه، نیام باز بگم که دواپس یک فرهنگ است و فلان و فلان، دوست دارم سعی کنم به زبون خودم یک موضوع رو شرح بدم؛ شاید حتی توش خطا و اشکال هم داشته باشم، پس حرفه‌ای تر ها اشکالی دیدن حتما بهم بگن که روش بازنگری داشته باشم!

خب؛ کلمه دواپس از کجا اومده؟

نمیدونم والا، برین سرچ کنین ببینین از کجا اومده :))

فقط در همین حد بهتون بگم که DevOps، ترکیبی از دو کلمه Development(توسعه) و Operation(عملیات) هستش؛ توی پروژه‌ها و شرکت‌ها، خب مشخصا یک تیم توسعه داریم که وظیفش نوشتن کد و اضافه کردن فیچر(همون چیزمیزایِ جدید) به سیستم هستش و یک تیم عملیات داریم که وظیفش، پایدار نگه‌داشتن سیستم و سرویس هستش.

اینجا یک تناقض بزرگ داریم، اون چیه؟ اینکه برنامه‌نویس‌های ما مرتبا میان نرم افزار مارو تغییر میدن و توی این تغییرات، همراه با درست کردن یک چیز جدید، دوتا چیز که قبلا داشته درست کار میکرده رو خراب میکنن ?

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

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

پس اینجا دواپس به وجود میاد، یک مهندس مظلوم که بین توسعه و عملیات(یا زیرساخت) قرار میگیره تا همه داد و بیدادهای هر دو طرف سر اون تخلیه شه ?. (شوخی میکنما!!)

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

این مدیریت، در فازهای مختلف انجام میشه که باید درموردشون صحبت کنیم، در ادامه میخوام بهتون بگم مسئلمون چیه؟ راهکارش چیه؟ بعدش ابزاری که واسه این موضوع استفاده میشه چیه.

توی دواپس، ما دنبال این هستیم که تمامی فرآیندهارو به شکل اتومات انجام بدیم، توی هر لایه‌ای مثل Build کردن پروژه، تست کردن پروژه، دپلوی کردن پروژه بروی Stage و Production، مانیتور کردنش و هر مورد دیگه‌ای که توی فرآیندهای دواپسی ما انجام میشه. (اگر یکجا رفتین نیروی دواپس شدین، خداییش تنبلی نکنین، همه کارارو اتومات کنین هم خطای انسانی کمتره، هم خودتون راحت ترین، هم کارا به شکل اتومات و سریع‌تر انجام میشه، هم خیلی با کلاسه)

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

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

فرآیندی که در ادامه دارم شرح میدم، نمونه ساده‌ی یک سناریو هستش و داستان میتونه خیلی پیچیده‌تر از این حرفا باشه و خیلی مولفه‌های دیگه رو هم شامل بشه، خلاصه که حواستون باشه!

خب کد توسط تیم توسعه نوشته میشه، و بروی مخرن Git ما قرار میگیره(اینکه Git یا سیستم‌های کنترل ورژن چیه، خودش کلی جای بحث داره، برین بخونین درموردش خدایی جذابه...؛خلاصش اینه که بستری داره فراهم میشه که توسعه و نگه‌داری و کنترل ورژن و ایجاد فیچر و جلوبردن پروژه به شکل تیمی رو برای شما راحت‌تر میکنه)، دواپس میاد یک پایپلاین CI/CD(سی آی/سی دی) میسازه، حالا این پایپلاین چیه؟ یک ساختاری هستش که توسط ابزارهایی مثل Jenkins، Azure DevOps ، Gitlab و... ایجاد میشه و به ما اجازه میده که ما داخلش یکسری فرآیندهارو تعریف کنیم که به شکل اتومات انجام بشن(دارم خیلی خلاصه میگما! داستانش خیلی طولانیه برین سر فرصت بخونین درموردش)؛ در این پایپلاین، به شکل اتومات، کد رو از روی مخزن گیت برداشته میشه و میره روی Build Serverهای ما و پروژه Build میشه، پس فاز برداشتن کد و Build کردنش انجام شد به شکل اتومات، بعدش در فاز بعدی، پروژه ما وارد فرآیندی میشه که روش تست‌های مختلف انجام بشه که مطمئن بشیم قبل از انتشار، کدمون داره درست کار میکنه و مشکل جدی‌ای نداره(این تست ها میتونه توسط ابزارهای مختلفی مثل Selenium انجام بشه که اینم بحثش مفصله)، در مرحله بعدی، میریم که Deploy رو انجام بدیم و پروژه‌ی Build و Test شده رو به سرورهای پروداکشن یا استیج انتقال بدیم(فکر کنین اگر سرورهامون زیاد باشن چقدر این موضوع ترسناک میتونه باشه!).

(همین مرحله میتونه خودش شامل فازهای مختلفی باشه، مثل استپ کردن سرویس‌های درحال اجرایِ قبلی، بکاپ‌گرفتن از فایلهای اجرایی قبلی(که اگر مشکلی پیش اومد بتونیم سریع rollback کنیم) و سپس انتقال پروژه جدید، اجرا کردن سرویس‌های مربوطه، اتومات‌سازی اجرای پروژه جدید(تعریف سرویس) و هزار مورد دیگر که میتونه به این فرآیند اضافه شه بسته به ساختار نرم افزارمون.)

در کنار این موارد، ما فاز مانیتورینگ و مدیریت Log رو هم(توسط ابزارهایی مثل Prometheus+Grafana و ELK Stack) انجام میدین که مطمئن شیم، در سطح سرویس و زیرساخت، نرم افزارمون داره درست عمل میکنه و مشکل خاصی وجود نداره، یا اگر مشکلی داره به وجود میاد سریع متوجهش شیم و زود حلش کنیم.

حالا یکبار دیگه به این تصویر بنگرید:

این چرخه مرتبا درحال تکرار هستش، در بخش Dev، برنامه‌ریزی، توسعه‌کد، تست و Build داره انجام میشه و در بخش Ops، ریلیز، دپلوی، مانیتورینگ داره انجام میشه؛ این یعنی دواپس!

حالا توجه داشته باشین که سناریویی که ما مطرح کردیم، خیلی ساده بود و فرآیند Build و Test بخاطر وابستگی‌هایی که ممکنه وجود داشته باشه، میتونه بسیار پیچیده و چالش برانگیز باشه؛ در ترکیب این لایه با Deploy، ممکن هستش که ما از راهکارهای Containerization استفاده کنیم و در نتیجه با ابزارهایی مثل داکر و کوبرنتیز(درصورت اسکیل بزرگتر و وجود چند کلاستر) هم درگیر شویم! دیگه خودتون حساب کنین چقدر داستان میتونه پیچیده شه؛ فقط خود کوبرنتیز خودش دنیایی هستش که ما توش راهکارهای مقیاس‌پذیری و High Availability و Fault tolerance رو به شکل پیچیده در لایه کانتینر، Storage، نتورک و... میتونیم مدیریت کنیم؛ یا مثلا در لایه زیرساخت و کانفیگ و مدیریت سرورها، میتونیم از ابزارهای Configuration Manager دیگری مثل Ansible استفاده کنیم که مدیریت سرورهای زیاد در Scaleهای بزرگ رو برامون تسهیل میکنه.

(درمورد رسالت داکر و Containerization حتما مطالعه داشته باشین، چون بحثش مفصله اینجا بازش نمیکنم فعلا.)

خیلی موارد رو کلی مطرح کردیم، ولی فکر کنم ایده گرفتین که چیکار داریم میکنیم، نه؟

ده ها ابزار و راهکارهای دیگه توی هرکدوم از این لایه‌هایِ چرخه‌ی دواپس موجود هستش که میتونیم روزها درموردشون صحبت کنیم، فقط در لایه زیرساخت برین ببینین ابزارهایی مثل Kubernetes و OpenStack(که البته بیشتر مرتبط با Cloud Engineer ها هستش ولی گاهی در دواپس هم باهاش درگیر میشن) چه عظمتی دارن و چه کارهایی رو باهاشون انجام میدن، یا مثلا برین ببینین برای مانیتورینگ، چقدر راهکارها و ابزارها وجود دارن...

(مانیتورینگ در سطح سرویس خیلی جذابه‌ها... فکر کن مثلا مانیتور کنی فلان صف من توی RabbitMQ اگر تعدادش از N کمتر بود، منو متوجه کن چون این موضوع طبیعی نیست).

شرکتا هر کدوم هر بخش از دواپس رو که نیاز دارن پیاده سازی میکنن، خیلی از فرآیندها هنوز که هنوزه اتومات نیست، خیلی از این Stepها هنوز که هنوزه به شکل درست پیاده‌سازی نشده در بسیاری از شرکت‌ها، ده‌ها ابزار و راهکارهای دیگه هستش که میتونیم کلی درموردشون صحبت کنیم، لایه به لایه این موارد ابزارهای مختلفی داره که راهکارهای مختلفی رو پیاده‌سازی میکنن... برین ببینین چه چیزی توی پروژه و سازمانتون کمه، ببینین راهکارش چیه و ابزارش چیه... اون ابزار رو یاد بگیرین و پیاده‌سازی کنین.

امیدوارم این مطلب واستون مفید واقع شده باشه

حتما نظرتون رو باهام به اشتراک بذارین، خوشحال میشم واقعا.

بگین دیگه چی بنویسم بدردتون بخوره؟

ارادت / سجاد غفاریان