هیچ مهندس DevOps وجود ندارد. پس چه کسی وجود دارد و با آن چه باید کرد؟

اخیراً چنین تبلیغاتی در اینترنت هجوم آورده است. با وجود دستمزد دلپذیر، نمی توان خجالت کشید که بدعت وحشی در آن نوشته شده است. در ابتدا فرض بر این است که «DevOps» و «مهندس» می‌توانند به نحوی در یک کلمه با هم بچسبند، و سپس فهرستی تصادفی از الزامات وجود دارد که برخی از آنها به وضوح از جای خالی sysadmin کپی شده‌اند.

در این پست می‌خواهم کمی در مورد اینکه چگونه به این نقطه از زندگی رسیدیم، DevOps واقعاً چیست و اکنون با آن چه کنیم صحبت کنم.

چنین جاهای خالی را می توان به هر طریق ممکن محکوم کرد، اما واقعیت همچنان پابرجاست: تعداد زیادی از آنها وجود دارد و در حال حاضر بازار اینگونه عمل می کند. ما یک کنفرانس devops برگزار کردیم و آشکارا اعلام کردیم:DevOops - نه برای مهندسان DevOps." این برای بسیاری عجیب و وحشیانه به نظر می رسد: چرا افرادی که یک رویداد کاملاً تجاری را انجام می دهند مخالف بازار هستند. حالا همه چیز را توضیح می دهیم.

درباره فرهنگ و فرآیندها

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

به عنوان مثال، توضیح تفاوت بین یک مدیر سیستم و یک رویکرد SRE برای مدیریت خدمات کتاب معروف Google SRE آغاز می شود. مطالعات جالبی در داخل انجام شده است نظرسنجی DORA - واضح است که بهترین توسعه دهندگان به نحوی موفق می شوند تغییرات جدید را سریعتر از یک بار در ساعت به تولید برسانند. آنها با دست خود بیش از 10٪ آزمایش نمی کنند (این را می توان از DORA سال گذشته). آنها چطور این کار را انجام میدهند؟ یکی از عناوین گزارش می‌گوید: «عالی یا بمیر». برای بررسی دقیق این آمار از نظر تست می توانید به سخنرانی باروخ سادوگورسکی مراجعه کنید. «ما DevOps داریم. بیایید همه آزمایش‌کنندگان را اخراج کنیم.» در کنفرانس دیگر ما، هایزنباگ.

وقتی بین رفقا توافقی وجود ندارد،
تجارت آنها خوب پیش نخواهد رفت،
و چیزی از آن بیرون نمی آید، فقط آرد.
روزی روزگاری یک قو، یک خرچنگ و یک پیک..."

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

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

حلقه شرور

رشته "مهندسی devops" از کجا آمد؟ ما یک نسخه داریم! ایده‌های DevOps خوب بودند – آنقدر خوب که قربانی موفقیت خودشان شدند. برخی از استخدام کنندگان و قاچاقچیان انسان که فضای خاص خود را دارند، شروع به چرخیدن در اطراف این موضوع کردند.

تصور کنید: دیروز در خیمکی شاورما درست می کردید و امروز یک مرد بزرگ هستید، یک استخدام کننده ارشد. یک فرآیند کامل جستجو و انتخاب نامزدها وجود دارد، همه چیز آسان نیست، شما باید درک کنید. فرض کنید رئیس یک بخش می گوید: یک متخصص در X پیدا کنید. کلمه "مهندس" را به X اختصاص می دهیم و کارمان تمام می شود. به لینوکس نیاز دارید؟ خب، این قطعا یک مهندس لینوکس است، اگر DevOps می خواهید، پس یک مهندس DevOps. جای خالی نه تنها شامل یک عنوان است، بلکه متنی نیز باید در آن وارد شود. ساده ترین راه این است که بسته به تصور شما مجموعه ای از کلمات کلیدی را از گوگل وارد کنید. DevOps از دو کلمه تشکیل شده است - "Dev" و "Ops"، به این معنی که ما باید کلمات کلیدی مربوط به توسعه دهندگان و مدیران را به هم بچسبانیم، همه در یک انبوه. اینگونه است که جای خالی مهارت در 42 زبان برنامه نویسی و 20 سال استفاده همزمان از Kubernetes و Swarm ظاهر می شود. نمودار کار.

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

تقاضا باعث ایجاد عرضه می شود و همه این جاهای خالی زباله با تعداد دیوانه ای از مدیران سیستم پر شده است که متوجه شدند: شما می توانید همه کارها را مانند قبل انجام دهید، اما با نامیدن خود "دوپس" چندین برابر بیشتر به دست آورید. همانطور که سرورها را از طریق SSH به صورت دستی پیکربندی کردید، پیکربندی آنها را ادامه خواهید داد، اما اکنون ظاهراً این یک عمل توسعه است. این نوعی پدیده پیچیده است که تا حدودی با دست کم گرفتن مدیران کلاسیک و هیاهوی تبلیغاتی پیرامون DevOps مرتبط است، اما به طور کلی، اتفاقی که افتاد، افتاد.

بنابراین ما عرضه و تقاضا داریم. دور باطلی که خودش را تغذیه می کند. این چیزی است که ما با آن مبارزه می کنیم (از جمله با ایجاد کنفرانس DevOops).

البته، علاوه بر مدیران سیستم که نام خود را "devops" تغییر داده اند، شرکت کنندگان دیگری نیز وجود دارند - به عنوان مثال، SRE های حرفه ای یا توسعه دهندگان زیرساخت به عنوان کد.

کاری که مردم در DevOps انجام می دهند (واقعا)

بنابراین شما می خواهید در یادگیری و به کارگیری شیوه های DevOps جلوتر باشید. اما چگونه این کار را انجام دهیم، به کدام جهت نگاه کنیم؟ بدیهی است که نباید کورکورانه به کلمات کلیدی محبوب اعتماد کنید.

اگر کاری هست، یکی باید آن را انجام دهد. ما قبلاً متوجه شده ایم که اینها "مهندس توسعه" نیستند، پس چه کسانی هستند؟ درست تر به نظر می رسد که این را نه بر حسب سمت، بلکه برحسب حوزه های کاری خاص صورت بندی کنیم.

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

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

البته یک بخش فنی هم هست. اگر کد جدید شما در عرض یک ماه آزمایش می‌شود، اما تنها یک سال بعد منتشر می‌شود، و سرعت بخشیدن به آن از نظر فیزیکی غیرممکن است، ممکن است به شیوه‌های خوب عمل نکنید. شیوه های خوب توسط ابزارهای خوب پشتیبانی می شوند. برای مثال، با در نظر گرفتن ایده Infrastructure-as-Code، می توانید از هر چیزی از AWS CloudFormation و Terraform گرفته تا Chef-Ansible-Puppet استفاده کنید. شما باید همه اینها را بدانید و بتوانید انجام دهید، و این قبلاً یک رشته مهندسی است. مهم است که علت را با معلول اشتباه نگیرید: ابتدا طبق اصول SRE کار می کنید و تنها سپس این اصول را در قالب چند راه حل فنی خاص پیاده سازی می کنید. در عین حال، SRE یک متدولوژی بسیار جامع است که به شما نمی گوید چگونه جنکینز را راه اندازی کنید، بلکه در مورد پنج اصل اساسی است:

• ارتباط بین نقش ها و بخش ها بهبود یافته است
• پذیرش اشتباهات به عنوان بخشی جدایی ناپذیر از کار
• ایجاد تغییرات به تدریج
• استفاده از ابزار و سایر اتوماسیون ها
• اندازه گیری هر چیزی که قابل اندازه گیری است

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

در رشته SRE، استفاده از ابزارها تنها یک بخش از موفقیت است، هرچند مهم است. ما باید دائماً از نظر فنی پیشرفت کنیم، ببینیم در دنیا چه اتفاقی می افتد و چگونه می توان آن را در کارمان اعمال کرد.

به نوبه خود، راه حل های Cloud Native اکنون بسیار محبوب شده اند. همانطور که امروزه توسط بنیاد محاسبات Cloud Native تعریف شده است، فناوری‌های Cloud Native سازمان‌ها را قادر می‌سازد تا برنامه‌های کاربردی مقیاس‌پذیر را در محیط‌های پویا امروزی، مانند ابرهای عمومی، خصوصی و ترکیبی توسعه دهند و اجرا کنند. به عنوان مثال می توان به کانتینرها، مش خدمات، میکروسرویس ها، زیرساخت های تغییرناپذیر و API های اعلامی اشاره کرد. همه این تکنیک‌ها به سیستم‌های با جفت آزاد اجازه می‌دهند تا الاستیک، قابل کنترل و بسیار قابل مشاهده باقی بمانند. اتوماسیون خوب به مهندسان این امکان را می دهد که تغییرات بزرگی را به طور مکرر و با نتایج قابل پیش بینی انجام دهند بدون اینکه آن را به یک کار طاقت فرسا تبدیل کنند. همه اینها توسط مجموعه ای از ابزارهای شناخته شده مانند Docker و Kubernetes پشتیبانی می شود.

این تعریف نسبتاً پیچیده و گسترده به این دلیل است که منطقه نیز بسیار پیچیده است. از یک طرف، استدلال می شود که تغییرات جدید به این سیستم باید کاملاً ساده اضافه شود. از سوی دیگر، برای کشف چگونگی ایجاد یک نوع محیط کانتینری که در آن سرویس‌های متصل آزاد بر روی یک زیرساخت تعریف‌شده توسط نرم‌افزار زندگی می‌کنند و با استفاده از CI/CD پیوسته در آنجا ارائه می‌شوند، و رویه‌های DevOps را پیرامون همه این موارد ایجاد می‌کنیم - همه اینها به موارد بیشتری نیاز دارد. بیش از یکی سگ را بخورد

با این همه چه باید کرد

هر کس این مشکلات را به روش خود حل می کند: برای مثال، می توانید جای خالی معمولی را منتشر کنید تا دور باطل را بشکنید. می توانید معنی کلماتی مانند DevOps و Cloud Native را بفهمید و از آنها به درستی و به درستی استفاده کنید. می توانید در DevOps توسعه دهید و با مثال خود رویکردهای مناسب را نشان دهید.

ما در حال برگزاری یک کنفرانس هستیم DevOops 2020 مسکو، که فرصتی را فراهم می کند تا عمیق تر در مواردی که قبلاً در مورد آنها صحبت کردیم کاوش کنیم. چندین گروه گزارش برای این کار وجود دارد:

• فرآیندها و فرهنگ؛
• مهندسی قابلیت اطمینان سایت;
• Cloud Native;

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

بدیهی است که در خود کنفرانس نمی توانید به طور همزمان روی سه مسیر بروید، بنابراین ما برنامه را به گونه ای سازماندهی می کنیم که هر شکاف زمانی موضوعاتی برای هر سلیقه داشته باشد.

تنها چیزی که باقی می ماند این است که بدانید اگر یک مهندس DevOps هستید چه کاری باید انجام دهید! ابتدا سعی کنید مشخص کنید که واقعاً چه کاری انجام می دهید. معمولاً آنها دوست دارند این کلمه را صدا کنند:

• توسعه دهندگانی که روی زیرساخت کار می کنند. گروه های گزارش در مورد SRE و Cloud Native برای شما مناسب ترین هستند.
• مدیران سیستم اینجا پیچیده تر است. DevOops در مورد مدیریت سیستم نیست. خوشبختانه کنفرانس ها، کتاب ها، مقالات، ویدئوهای بسیار عالی در اینترنت و ... با موضوع مدیریت سیستم وجود دارد. از سوی دیگر، اگر شما علاقه مند به توسعه خود از نظر درک فرهنگ و فرآیندها، یادگیری در مورد فن آوری های ابری و جزئیات زندگی با Cloud Native هستید، ما دوست داریم شما را ببینیم! به این فکر کنید: شما در حال انجام امور اداری هستید، و سپس چه خواهید کرد؟ برای جلوگیری از قرار گرفتن ناگهانی در موقعیت ناخوشایند، باید همین الان یاد بگیرید.

گزینه دیگری وجود دارد: شما پافشاری می کنید و همچنان ادعا می کنید که هستید به طور خاص یک مهندس DevOps و هیچ چیز دیگری، به هر معنی که باشد. پس باید شما را ناامید کنیم، DevOops کنفرانسی برای مهندسان DevOps نیست!

اسلاید از گزارش کنستانتین دینر در مونیخ

DevOops 2020 Moscow در تاریخ 29 تا 30 آوریل در مسکو برگزار می شود، بلیط ها از قبل موجود است. خرید در وب سایت رسمی.

متناوباً ، می توانید گزارش خود را ارسال کنید تا 8 فوریه لطفاً توجه داشته باشید که هنگام پر کردن فرم، باید مخاطب هدفی را انتخاب کنید که بیشترین سود را از گزارش شما خواهد برد (یک سورپرایز در لیست مدفون است).

منبع: www.habr.com