Още веднъж за DevOps и SRE

Въз основа на чат дискусия AWS Минска общност

Наскоро се разгоряха истински битки около дефиницията на DevOps и SRE.
Въпреки факта, че по много начини дискусиите по тази тема вече ме настръхнаха, включително и мен, реших да изложа моята гледна точка по тази тема в съда на общността на Хабра. За тези, които се интересуват, добре дошли в кат. И нека всичко започне отначало!

праистория

И така, в древни времена екип от разработчици на софтуер и администратори на сървъри са живели отделно. Първият успешно написа кода, вторият, използвайки различни топли, нежни думи, адресирани до първия, настройва сървърите, като периодично идва при разработчиците и получава в отговор изчерпателно „всичко работи на моята машина“. Бизнесът чакаше софтуера, всичко бездействаше, прекъсваше се периодично, всички бяха нервни. Особено този, който плати цялата тази каша. Славна ера на лампите. Е, вече знаете откъде идва DevOps.

Раждането на DevOps практиките

Тогава дойдоха сериозни момчета и казаха - това не е индустрия, не може да се работи така. И те въведоха модели на жизнения цикъл. Ето например V-модела.

И така, какво виждаме? Един бизнес идва с концепция, архитектите проектират решения, разработчиците пишат код и след това провал. Някой по някакъв начин тества продукта, някой по някакъв начин го доставя на крайния потребител и някъде на изхода на този чудо модел седи самотен бизнес клиент, чакащ обещаното време край морето. Стигнахме до извода, че се нуждаем от методи, които ще ни позволят да установим този процес. И решихме да създадем практики, които да ги прилагат.

Лирично отклонение по темата какво е практиката
Под практика имам предвид комбинация от технология и дисциплина. Пример е практиката за описване на инфраструктура с помощта на тераформиран код. Дисциплината е как да се опише инфраструктура с код, тя е в главата на разработчика, а технологията е самата тераформа.

И те решиха да ги нарекат DevOps практики - мисля, че имаха предвид от развитие до операции. Измислихме различни хитри неща - CI/CD практики, практики, базирани на принципа на IaC, хиляди от тях. И тръгваме, разработчиците пишат код, инженерите на DevOps трансформират описанието на системата под формата на код в работещи системи (да, кодът е, за съжаление, само описание, но не и въплъщение на системата), доставката продължава, и така нататък. Вчерашните администратори, усвоили нови практики, гордо се преквалифицираха като DevOps инженери и всичко тръгна оттам. И стана вечер, и стана утро... пардон, не от там.

Пак не всичко е наред, слава Богу

Веднага след като всичко се успокои и различни хитри „методолози“ започнаха да пишат дебели книги за практиките на DevOps, тихо се разгоряха спорове за това кой е прочутият инженер на DevOps и че DevOps е производствена култура, отново възникна недоволство. Изведнъж се оказа, че доставката на софтуер е абсолютно нетривиална задача. Всяка инфраструктура за разработка има свой собствен стек, някъде трябва да я сглобите, някъде трябва да разположите средата, тук имате нужда от Tomcat, тук имате нужда от хитър и сложен начин да го стартирате - като цяло главата ви се разбива. И проблемът, колкото и да е странно, се оказа преди всичко в организацията на процесите - тази функция за доставка, като пречка, започна да блокира процесите. Освен това никой не е отменил операциите. Не се вижда при V-модела, но все още има целия жизнен цикъл вдясно. В резултат на това е необходимо по някакъв начин да се поддържа инфраструктурата, да се наблюдава наблюдението, да се разрешават инциденти и да се справят с доставката. Тези. седи с единия крак и в разработката, и в експлоатацията - и изведнъж се оказа Development & Operations. И тогава имаше общия шум за микроуслугите. И с тях разработката от локални машини започна да се премества в облака - опитайте се да дебъгвате нещо локално, ако има десетки и стотици микроуслуги, тогава постоянната доставка се превръща в средство за оцеляване. За „малка скромна компания“ всичко беше наред, но все пак? Какво ще кажете за Google?

SRE от Google

Google дойде, изяде най-големите кактуси и реши - нямаме нужда от това, имаме нужда от надеждност. А надеждността трябва да се управлява. И реших, че имаме нужда от специалисти, които ще управляват надеждността. Нарекох ги SR инженери и казах, това е за вас, направете го както обикновено. Ето SLI, ето SLO, ето мониторинг. И си пъха носа в операции. И той нарече своя „надежден DevOps“ SRE. Всичко изглежда наред, но има един мръсен хак, който Google може да си позволи - за позицията на SR инженери да наеме хора, които са квалифицирани разработчици и също така са направили малко домашна работа и са разбрали функционирането на работещите системи. Освен това самият Google има проблеми с наемането на такива хора - главно защото тук се конкурира сам със себе си - необходимо е да се опише бизнес логиката на някого. Доставката беше възложена на инженери за освобождаване, SR - инженерите управляват надеждността (разбира се, не директно, а чрез влияние върху инфраструктурата, промяна на архитектурата, проследяване на промени и индикатори, справяне с инциденти). Браво, можеш пишат книги. Но какво ще стане, ако не сте Google, но надеждността все още е проблем?

Развитие на DevOps идеи

Точно тогава пристигна Docker, който израсна от lxc, а след това различни системи за оркестрация като Docker Swarm и Kubernetes, и инженерите на DevOps издишаха - обединяването на практиките опрости доставката. Това го опрости до такава степен, че стана възможно дори доставката да бъде възложена на разработчици - какво е deployment.yaml. Контейнеризацията решава проблема. А зрелостта на CI/CD системите вече е на ниво писане на един файл и тръгваме - разработчиците могат да се справят сами. И тогава започваме да говорим за това как можем да направим наш собствен SRE, с... или поне с някого.

SRE не е в Google

Е, добре, доставихме доставката, изглежда, че можем да издишаме, да се върнем към добрите стари времена, когато администраторите наблюдаваха натоварването на процесора, настройваха системите и тихо отпиваха нещо неразбираемо от чаши на спокойствие и тишина... Спри. Не затова започнахме всичко (което е жалко!). Изведнъж се оказва, че в подхода на Google можем лесно да възприемем отлични практики - не е важно натоварването на процесора, нито колко често сменяме дисковете там или оптимизираме разходите в облака, но бизнес показателите са същите прословути SLx. И никой не им е махнал управлението на инфраструктурата, а те трябва да разрешават инциденти, и да дежурят периодично, и като цяло да са в крак с бизнес процесите. И момчета, започнете малко по малко да програмирате на добро ниво, Google вече ви очаква.

Да обобщим. Изведнъж, но вече сте уморени от четене и нямате търпение да плюете и да пишете на автора в коментар към статията. DevOps като практика за доставка винаги е била и ще бъде. И не отива никъде. SRE като набор от оперативни практики прави тази доставка успешна.

Източник: www.habr.com