بر اساس یک بحث چت
اخیراً، نبردهای واقعی بر سر تعریف DevOps و SRE شعله ور شده است.
علیرغم این واقعیت که از بسیاری جهات بحث در مورد این موضوع از جمله من، قبلاً در مورد من تأثیر گذاشته است، تصمیم گرفتم دیدگاه خود را در مورد این موضوع به دادگاه جامعه حبره بیاورم. برای کسانی که علاقه مند هستند، به گربه خوش آمدید. و بگذارید همه چیز از نو شروع شود!
ماقبل تاریخ
بنابراین، در زمان های قدیم، تیمی از توسعه دهندگان نرم افزار و مدیران سرور به طور جداگانه زندگی می کردند. اولی با موفقیت کد را نوشت، دومی با استفاده از کلمات گرم و محبت آمیز مختلف خطاب به نفر اول، سرورها را راه اندازی کرد، به طور دوره ای به توسعه دهندگان می آمد و در پاسخ یک "همه چیز روی دستگاه من کار می کند" جامع دریافت می کرد. کسب و کار منتظر نرم افزار بود، همه چیز بیکار بود، دوره ای خراب می شد، همه عصبی بودند. مخصوصا اونی که هزینه این همه آشفتگی رو داد. دوران با شکوه چراغ. خوب، شما از قبل می دانید که DevOps از کجا آمده است.
تولد شیوه های DevOps
سپس بچه های جدی آمدند و گفتند - این یک صنعت نیست، شما نمی توانید اینطور کار کنید. و مدل های چرخه زندگی را آوردند. برای مثال، مدل V در اینجا قرار دارد.
پس ما چه می بینیم؟ یک کسب و کار با یک مفهوم همراه می شود، معماران راه حل هایی را طراحی می کنند، توسعه دهندگان کد می نویسند و سپس شکست می خورد. یک نفر به نحوی محصول را آزمایش می کند، کسی به نحوی آن را به کاربر نهایی تحویل می دهد و جایی در خروجی این مدل معجزه آسا یک مشتری تجاری تنها در انتظار آب و هوای موعود در کنار دریا نشسته است. ما به این نتیجه رسیدیم که به روش هایی نیاز داریم که به ما امکان می دهد این روند را ایجاد کنیم. و ما تصمیم گرفتیم شیوه هایی ایجاد کنیم که آنها را اجرا کند.
انحراف غزلی در موضوع چیستی عمل
منظور من از تمرین ترکیبی از تکنولوژی و نظم است. یک مثال، تمرین توصیف زیرساخت با استفاده از کد terraform است. نظم و انضباط نحوه توصیف زیرساخت با کد است، در ذهن توسعه‌دهنده است و فناوری خود زمین است.
و آنها تصمیم گرفتند که آنها را DevOps Practices بنامند - فکر می کنم منظور آنها از توسعه تا عملیات بود. ما به چیزهای هوشمندانه مختلفی رسیدیم - تمرین های CI/CD، تمرین های مبتنی بر اصل IaC، هزاران مورد. و ما می رویم، توسعه دهندگان کد می نویسند، مهندسان DevOps شرح سیستم را به شکل کد به سیستم های کاری تبدیل می کنند (بله، متاسفانه کد فقط یک توضیح است، اما تجسم سیستم نیست)، تحویل ادامه می یابد، و غیره مدیران دیروز، با تسلط بر شیوه های جدید، با افتخار دوباره به عنوان مهندس DevOps آموزش دیدند و همه چیز از آنجا پیش رفت. و عصر بود و صبح بود... متاسفم، نه از آنجا.
باز هم همه چیز خوب نیست، خدا را شکر
به محض اینکه همه چیز آرام شد و "روش شناسان" حیله گر مختلف شروع به نوشتن کتاب های قطور در مورد شیوه های DevOps کردند، اختلافات بی سر و صدا در مورد اینکه مهندس DevOps بدنام کیست و اینکه DevOps یک فرهنگ تولید است شروع شد، نارضایتی دوباره به وجود آمد. ناگهان معلوم شد که تحویل نرم افزار یک کار کاملاً بی اهمیت است. هر زیرساخت توسعه پشته مخصوص به خود را دارد، در جایی باید آن را جمع آوری کنید، در جایی باید محیط را مستقر کنید، در اینجا به Tomcat نیاز دارید، در اینجا به روشی حیله گر و پیچیده برای راه اندازی آن نیاز دارید - به طور کلی، سر شما در حال تپش است. و مشکل، به اندازه کافی عجیب، در درجه اول در سازماندهی فرآیندها بود - این تابع تحویل، مانند یک گلوگاه، شروع به مسدود کردن فرآیندها کرد. علاوه بر این، هیچ کس عملیات را لغو نکرد. در مدل V قابل مشاهده نیست، اما هنوز کل چرخه زندگی در سمت راست وجود دارد. در نتیجه باید به نحوی زیرساخت ها را حفظ کرد، نظارت بر نظارت، حل و فصل حوادث و همچنین رسیدگی به تحویل ضروری است. آن ها در توسعه و بهره برداری با یک پا بنشینید - و ناگهان معلوم شد که توسعه و عملیات است. و سپس تبلیغات عمومی برای میکروسرویس ها وجود داشت. و با آنها، توسعه از ماشین های محلی شروع به حرکت به سمت ابر کرد - سعی کنید چیزی را به صورت محلی اشکال زدایی کنید، اگر ده ها و صدها میکروسرویس وجود داشته باشد، تحویل ثابت به وسیله ای برای بقا تبدیل می شود. برای یک "شرکت کوچک کوچک" همه چیز درست بود، اما هنوز؟ گوگل چطور؟
SRE توسط Google
گوگل آمد، بزرگترین کاکتوس ها را خورد و تصمیم گرفت - ما به این نیاز نداریم، ما به قابلیت اطمینان نیاز داریم. و قابلیت اطمینان باید مدیریت شود. و من تصمیم گرفتم که به متخصصانی نیاز داریم که قابلیت اطمینان را مدیریت کنند. من آنها را مهندس SR صدا کردم و گفتم، این برای شماست، این کار را به خوبی انجام دهید. اینجا SLI است، اینجا SLO است، اینجا نظارت است. و بینی خود را در عمل فرو کرد. و او "DevOps قابل اعتماد" خود را SRE نامید. به نظر می رسد همه چیز خوب است، اما یک هک کثیف وجود دارد که گوگل می تواند از عهده آن برآید - برای موقعیت مهندسان SR، افرادی را استخدام کنید که توسعه دهندگان واجد شرایط بودند و همچنین تکالیف کوچکی را انجام دادند و عملکرد سیستم های کاری را درک کردند. علاوه بر این، خود گوگل با استخدام چنین افرادی مشکل دارد - عمدتاً به این دلیل که در اینجا با خودش رقابت می کند - لازم است منطق تجارت را برای کسی توضیح دهیم. تحویل به مهندسان آزاد واگذار شد، مهندسین SR قابلیت اطمینان را مدیریت می کنند (البته نه مستقیم، بلکه با تأثیرگذاری بر زیرساخت، تغییر معماری، ردیابی تغییرات و شاخص ها، برخورد با حوادث). خوبه، میتونی . اما اگر گوگل نیستید، اما قابلیت اطمینان هنوز به نوعی یک نگرانی است، چه؟
توسعه ایده های DevOps
درست در آن زمان Docker وارد شد، که از lxc رشد کرد، و سپس سیستم‌های ارکستراسیون مختلف مانند Docker Swarm و Kubernetes، و مهندسان DevOps بازدم کردند - یکسان سازی روش‌ها تحویل را ساده کرد. آن را تا حدی ساده کرد که حتی امکان برون سپاری تحویل به توسعه دهندگان وجود داشت - what is deployment.yaml. کانتینرسازی مشکل را حل می کند. و بلوغ سیستم‌های CI/CD در حال حاضر در سطح نوشتن یک فایل است و ما می‌رویم - توسعه‌دهندگان می‌توانند خودشان آن را مدیریت کنند. و سپس شروع به صحبت در مورد اینکه چگونه می توانیم SRE خودمان را با... یا حداقل با کسی بسازیم، می کنیم.
SRE در Google نیست
خوب، خوب، ما تحویل را تحویل دادیم، به نظر می‌رسد می‌توانیم نفس خود را بیرون بدهیم، به روزهای خوب گذشته برگردیم، زمانی که ادمین‌ها بارگیری پردازنده را تماشا می‌کردند، سیستم‌ها را تنظیم می‌کردند و بی‌صدا چیزی غیرقابل درک از لیوان‌ها را در آرامش و سکوت می‌نوشیدند... توقف کنید. به این دلیل نیست که ما همه چیز را شروع کردیم (که حیف است!). ناگهان مشخص شد که در رویکرد گوگل به راحتی می‌توانیم روش‌های عالی را اتخاذ کنیم - بار پردازنده مهم نیست، و نه اینکه هر چند وقت یکبار دیسک‌ها را در آنجا تغییر می‌دهیم یا هزینه را در فضای ابری بهینه می‌کنیم، اما معیارهای تجاری همان بدنام هستند. SLx. و هیچ کس مدیریت زیرساخت را از آنها حذف نکرده است و آنها باید حوادث را حل کنند و به طور دوره ای در حال انجام وظیفه باشند و به طور کلی در بالای فرآیندهای تجاری باقی بمانند. و بچه ها، کم کم برنامه نویسی را در سطح خوبی شروع کنید، گوگل از قبل منتظر شماست.
به طور خلاصه. ناگهان، اما شما قبلاً از خواندن خسته شده اید و نمی توانید صبر کنید تا تف کنید و در یک نظر در مورد مقاله برای نویسنده بنویسید. DevOps به عنوان یک روش تحویل همیشه بوده و خواهد بود. و به جایی نمی رسد. SRE به عنوان مجموعه ای از شیوه های عملیاتی این تحویل را بسیار موفق می کند.
منبع: www.habr.com