دواپس بدرد نمی خوره

سالهاست داریم خودمو رو گول میزنیم!

اول همه چیز خوب شروع شد!

هدف اولیه ی DevOps بسیار زیبا بود:

اضافه شدن فرهنگ تکمیل چرخه ی نرم افزار و بهترین روش های امنیتی، تست کردن و پیاده سازی و ... !

با ساده تر شدن فرآیندهای تست و دیپلوی و معروف تر شدن فریم ورک های Batteries Included دیگر از تمام برنامه نویسان انتظار میرفت تا استفاده از ابزار مرتبط با تست نویسی(Jest، Pytest و ...)، Containerization (مثل Docker) و ابزار CI/CD (قدیم Jenkins بود که نسبت به آلترناتیو مدرن یعنی github actions بسیار سخت تر بود!) را بلد باشند. ارتباط تنگاتنگ این ابزار با زبانهای برنامه نویسی و برنامه ها باعث شده بود تیم های Operations (یعنی Ops در DevOps) تمرکز خود را بر روی بالانگهداشتن سرورها و مانیتورینگ سرورها گذاشته و وظیفه ی دیپلوی به عهده ی تیم های Development (یعنی Dev در DevOps) باشد. به این صورت ما نرم افزارهای پایدارتر و چرخه های کوتاهتر و بهتری را تجربه می کردیم.

در طی سالهای پس از معرفی اولیه تکنولوژی های Containerization (یعنی از 2012 به بعد) ، DevOps به یک هیولای بسیار زشت و با چشم های کور تبدیل شد! حالا وظیفه ی دیپلوی کردن و نوشتن فرآیندهای CI/CD به گردن متخصصین DevOps افتاده است! متخصصینی که نه به اندازه ی کافی بر روی Operations تمرکز دارند و نه با برنامه ها و زبانهای برنامه نویسی، برای دیپلوی بهینه و نوشتن درست CI/CD ،آشنایی دارند! چی شد که اینطور شد؟

1- بی کفایتی برنامه نویسان و خیانت آموزش دهندگان

اکثر افرادی که به آموزش برنامه نویسی مشغول بودند هیچگاه تجربه ی واقعی ای از محیط اجرای یک محصول واقعی را نداشتند و برنامه نویسان نیز دنبال گرفتن جواب های خود از منابع مختلفی بودند که در این محیط ها چرخه ی نرم افزار اهمیت خاصی نداشت! به همین خاطر چرخه ی نرم افزار به فرآموشی سپرده شد!

همانطور که در چرخه ی توسعه ی نرم افزار میبینید، عملیات دیپلوی جزئی از فرآیند توسعه ی نرم افزار است.

2- بوجود آمدن تیم DevOps

ابتدا برنامه نویسان ارشد و میانرده علاوه بر عضو تیم اصلی برنامه نویسی بودن، عضو یک تیم داخلی DevOps نیز بودند و این تیم با مدیریت branch های Version Control عملیات تست، دیپلوی و نسخه بندی برنامه را نیز مدیریت می کردند در یک نقطه ی نامشخص زمانی و به علت تصمیمات نادرست مدیریتی (و پیدایش Agile mentor ها و Scrum Master های بی سواد)اما این تیم از تیم اصلی برنامه نویسی جدا شد و دیگر چیزی به نام DevOps وجود نداشت! DevOps جدید از طریق Terraform و فایل های YAML کارهای ساده و پیش پا افتاده را برای تیم Development انجام میداد. حالا دیگر تیم Development باید برای کارهای مختلف از این تیم جدید کمک میگرفت:

• به دیتابیس جدید نیاز داریم: تیکت به تیم DevOps
• به یک فضای Object Storage نیاز داریم: تیکت به تیم DevOps
• به یک دسترسی جدید به لاگ ها و گزارش ها نیاز داریم: تیکت به تیم DevOps

میتوان رویکرد فعلی را تحمل کرد اما اگر حجم کارها زیاد شود تنها با افزایش تعداد اعضای هردو تیم میتوان سرعت را افزایش داد یا حداقل مانع کاهش سرعت شد!

3- به عنوان DevOps باید چکاری انجام دهم؟

اگر یک متخصص DevOps مدرن و باسواد باشید حس خوبی به کار خود نخواهید داشت!

شما چیزهای بسیار مهمی که باید کار خود را با توجه به آنها انجام دهید نمی دانید:

• بهترین روش پیاده سازی و معماری پروژه چیست؟ جواب این سوال به این خاطر که ارتباط شما با هسته ی برنامه ها به حداقلی ترین میزان خود رسیده برای شما نامشخص است!
• امنیت سیستم به چه صورت است؟ شما هیچ ایده ای ندارید که برنامه ها چطور نوشته شده اند و آیا تمام ملزومات امنیتی توسط برنامه نویسان محترم رعایت شده است یا نه!
• افزایش ظرفیت سیستم باید در کدام لایه رخ دهد؟ Bottle Neck سیستم برای شما مشخص نیست و تنها راه بهبود کارایی و سرعت سیستم ،از دید شما، افزایش منابع یا پیاده سازی معماری های پیچیده است(نه بهتر کوئری زدن و کش کردن در لایه ی نرم افزاری)
• نام گذاری و نسخه گذاری سرویس ها به چه صورت است؟ Nah. NAH. nah-prod. PROD-NAH. PRODUCTION-NAH
• چگونه می توان هزینه ی سیستم را کاهش داد؟ نمیدانید دقیقا هر سرویس چطور از منابع در اختیار خود و دیگر سرویس ها استفاده میکند پس هر تصمیمی که بگیرید باید از دید شما بدون ریسک باشد و معمولا هیچ کار واقعا اثر گذاری است دست شما بر نمی آید!

4- انجام کارهای DevOps در شائن من نیست!

از گذشته اکثر برنامه نویسان خود را برتر از System Admin ها میدانستند و با ورود System Admin های کلاسیک به حوزه ی DevOps باعث دید منفی برنامه نویسان بی سواد و ابله به این حوزه شدند. مشکل اینجا بود که در ابتدا که DevOps زیبا بود از یک متخصص DevOps انتظار میرفت هم Dev بلد باشد و هم Ops! در حال حاضر اما با چیز بسیار عجیبی رو به رو هستیم! متخصصین DevOps ای که یا برنامه نویسی(Development ) بلد نیستند و یا دیدی نسبت به بخش Operations ندارند!

به نظر شخص من با رویکرد فعلی اهمیت DevOps از دید سرمایه گذاران و مالکین و مدیران کسب و کار کاهش پیدا میکند. خلاصه ی حرف من این است که اگر در هر نقطه ای از آشنایی با DevOps قرار دارید و قصد فعالیت در این حوزه را دارید: هم Dev بلد باشید و هم Ops! قرار نیست که به اندازه ی برنامه نویس ارشد یا متخصص ارشد زیرساخت سواد کسب کنید ولی باید بتوانید پلی بین تما اعضای تیم باشید!

دلایل افت کیفیت، کارایی و ارزش DevOps را باهم بررسی کردیم و حالا در مورد اهمیت DevOps خواهیم گفت.

در واقعیت قرار بود DevOps جایی برای گرفتن بهترین تصمیم های سخت باشه و هرچقدرم این تصمیم ها سخت باشن هزینه ی اجرا و نگهداریشون کم باشه! تغییرات اساسی توی زیرساخت کسب و کار شما چقدر سادست؟

زیرساخت یک کالاست! مثل کالا ازش استفاده کنید!

زیرساخت ها کالاهایی هستن که اجاره میکنیم یا میخریم و باید بتونیم همیشه بهترین کالا ( با توجه به قیمت و کیفیت) رو داشته باشیم و نباید وابستگیمون به شدت به یک کالا زیاد بشه که نتونیم ازش جدا بشیم!

تجربه:

در چند ماهی که در یک پوزیشن سینیور در یک شرکت اروپایی بودم بیش از 40 زیرساخت بر پایه ی VM، Docker، Containerd و Kubernetes را برای حدودا 15-20 کسب و کار منتقل کردیم. این کار همیشه در ابتدا با چالش و استرس همراه بود ولی بعد از انتقال و برنامه ریزی درست دیگه تمام این کسب و کارها میتوانستند در آینده این کار را مجددا بدون چالش و استرس اضافه انجام دهند.

در ابتدای پروژه

فرآیند DevOps مدرن در ابتدا کمی چالش برانگیز است و باید به ابعاد مختلف سیستم فکر کنید ولی بعد از پیاده سازی های اولیه دیگه فقط ماژول های Terraform و فایل های Yaml را کپی و paste میکنید! متاسفانه هیچکس تا زمانی که چیزی به مشکل نخورد به زیرساخت ها و عملیات DevOps اهمیتی نمی دهد و این باعث شده تا DevOps مدرن به یک فرآیند copy-paste-driven تبدیل شود! DevOps مدرن منجر به جدایی بیشتر تیم ها و نهایتا به infrastructure configuration management منجر شد اما هدف اولیه ی DevOps در اصل platform engineering و developer self-service بود! این فاصله گرفتن از هدف اولیه منجر به کاهش تخصص نسل های جدید برنامه نویسان نسبت به گذشته نیز شد و در نهایت DevOps به یک کار بی ارزش(نسبت به گذشته ی DevOps ) تبدیل شد.

تاثیر Ops در چرخه ی حیات نرم افزار

به تصویر software development lifecycle در بالا مجددا نگاه کنید! DevOps در ابتدا قرار بود چند مسئله ی فرهنگی را به این چرخه اضافه کند:

• پیشرفت مداوم با کار تیمی (تمام اعضای تیم از تمام فعالیت های DevOps آگاه باشند)
• برقراری ارتباط موثر بین اعضای تیم
• بهبود روحیه ی تیم با درک تاثیر فردی در روند رشد و توسعه ی محصول
• ایجاد فضایی برای گفت و گو و پیشنهاد و بهبود توسط تمام اعضای تیم

این مدل در ابتدا واقعا کار میکرد و برنامه نویسان همگی از این وضعیت راضی بودند و همه همواره در حال یادگیری و رشد بودند اما با گذر زمان تعریف main-stream از DevOps دچار تغییر شد و نهایتا با تعاریف ساده ای مثل موارد زیر مواجه شدیم:

• فرآیند DevOps یعنی اتوماسیون تا جایی که سازمان به ما اجازه دهد!

در فرهنگ کلاسیک DevOps تنها بهبود فرآیند توسعه و عرضه برای برنامه نویسان مهم بود و اتوماسیون به عنوان بخشی از فرآیند توسط برنامه نویسان مشخص می شد و نه مدیران سازمان!

• استفاده از ابزار و روش های مشخص برای اتوماسیون فرآیند های توسعه و عرضه ی نرم افزار و کاهش زمان هر چرخه ی حیات!

ابزار مشخص؟ کاهش زمان هر چرخه ی حیات؟ این مسئله با عدم قطعیت و حجم واقعی کار لازم برای ایجاد تغییرات معنا دار در یک نرم افزار کاملا تداخل دارد! برای بسیاری از کارهایی که میتوانیم آنها را بهبود ببخشیم بهترین ابزار یا ابزار مشخص وجود خارجی ندارد!

تعاریف زیادی در سالهای اخیر برای DevOps معرفی شدند اما به نظر شخص من DevOps فرهنگ و دانش داشتن بیشترین بهره وری و کارایی در حداقلی ترین میزان کار کردن است!

در نهایت برای درک بهتر DevOps چرخه ی DevOps معرفی شد که کارهای Dev و Ops را از یکدیگر تفکیک میکرد!

تصویر بالا را با چرخه حیات نرم افزار مقایسه کنید! مراحل 1 تا 6 از Plan تا Deploy دقیقا مراحل Development هستند اما طبق این چرخه دیگر دو مرحله ی اساسی از Development که Release و Deploy هستند در بخش Operations قرار دارند! شاید شروع مشکل همینجا باشد! پس تا قسمت بعدی این مقاله تصویر زیر را به خاطر داشته باشید!