تیتر امروز دقیقا سوال یکی از دوستانی بود که تو محیطی بود که دیدی نسبت به DevOps نداشت و از من سوال کرد. و خوب فکر کردم جواب را اینجا بزارم ممکنه به درد بقیه هم بخوره. شاید بتونم کامل‌ترش کنم.
ببین قبلا یه سیستمی بود اینکه تیم توسعه مسوول برنامه نویسی و تولید بود و یه تیم زیر ساخت بود که محصول را تحویل می گرفت و دیپلوی می کرد. حتی یه دوره‌ای source control ها مثل gIt هم نبود و یا وقتی هم اومد یه سری پروژه ها استفاده نمی‌کردند.این موضوع یه باگ بزرگ داشت اون هم اینکه هیچ کس وقتی نرم افزار در اجرا به مشکل می خورد، مشکل را گردن نمی گرفت. یکی می گفت تقصیر تیم زیر ساخته. یکی می گفت تقصیر توسعه دهنده است که نمی فهمند. هر تیم هدف‌های جداگانه‌ای داشت در عین حال و این هدف ها با هم هم بعضی مواقع تداخل می‌کرد و نمی تونستند هم را درک کنند.
هنوز یه عده از دوستان با طرف مقابل زاویه دارند انگار هر کدوم طرف مقابلش بدهکار اون یکیه که همه کار طرف مقابل را بفهمه . در مورد این موضوع یه تصویر معروف هست، معروف به Wall of Confusion.
تصویر دو تا آدم با یک دیوار بینشون که که محصول را پرت می کنند طرف همدیگه .
چندین سال پیش یه گروهی اومدن گفتند این روند تولید نرم افزار و انتشار درست نیست و اومدن از ایده مدیریت کارخونه کپی گرفتند و گفتند که باید تولید نرم افزار هم مثل خط تولید کارخونه باشه. مواد خوام وقتی وارد نوار تولید می شه تهه کار محصول در بیاد. نباید هی محصول برگرده اول خط، نباید وقتی رسید آخر کار تازه بفهمیم که مشکل داریم. . اینجا بود که DevOps دقیقا از روی ایده های راه اندازی خط تولید کارخانه به وجود اومد. یعنی دیگه دو بخش Development و Operations جدا نداریم. قراره اینها با هم و در کنار هم مثل یک خط تولید کار کنند. در DevOps تمام تلاش این هست که وقتی شروع به توسعه می کنید وقتی محصول در اومد بشه بدون دغدغه دیپلوی کرد و بدونیم کار می کنه و مسوولیت ها هم مشخص باشه. حالا برای پیاده سازی این ایده کلی نحوه سرویس دهی و زیر ساخت تغییر کرد. کلود ها اساسا برای همین اومدن. برای اینکه این چرخه پیاده سازی بشه.
خیلی چیزا اینجا مهم می شه: اتوماسیون همه چیز، پیاده سازی تست های مختلف در چرخه تولید مثل تست functional test, smoke test, user acceptance test , security test و خیلی چیزهای دیگه. برای پیاده سازی اینها کلی ابزار مورد استفاده قرار گرفت یا پیاده سازی شد، مثل مجازی سازی، داکر و کوبرنیتیز، یا جنگینز و gitlab-ci . با ظهور این تولزهای جدید، نیاز به تکنسین های جدیدی پیدا شد، که دیگه فقط لینوکس نمی دونند و حتی لزوما دیگه عمیق بودن لینوکس مهم نیست براشون. باید تولزهای جدید را بدونند و بدونند چطوری این هدف جدید را دنبال کنند و حتی برنامه نویسی و اسکریپتینگ بدونند. حالا یا bashیا python. در کنار همه اینها روش‌های جدید سازمان دهی و شکستن تیم ها و نحوه ارتباطاتشون تعریف شد. یکی از تعریف های مهم که در کتاب The DevOps Handbook اومده The Three Ways هست:
- The First Way: Flow/Systems Thinking
- The Second Way: Amplify Feedback Loops
- The Third Way: Culture of Continual Experimentation and Learning
اینها سه تا اصل مهم در یک ساختار DevOps هستند. می تونید اینجا از زبان خود نویسنده اش در موردش بیشتر بخونید.
جالبه بدونی که Devops engineer هم یواش یواش داره کم رنگ می شه و اسم های جدیدی می بینی. که تحت تاثیر سرویسهای جدیدی هست که شرکتها دارند می دند. مثل Platform Engineer يا Cloud Engineer یا Cloud Architect و یا Site Reliable Engineer
