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

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

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

Предистория

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

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

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

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

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

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

Всичко отново не е както трябва

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

SRE от Google

Пристигна Google, изяде най-големите кактуси и реши — това не е нужно, нуждаем се от надеждност. А надеждността трябва да се управлява. И реши — нуждаем се от специалисти, които ще управляват надеждността. Назова ги SRE инженери и каза: ето ви всичко, направете го, както обикновено, добре. Ето ви SLI, ето ви SLO, ето ви мониторинг. И посочи operations. И нарече своя "надежден DevOps" SRE. Изглежда всичко е наред, но има един мръсен хак, който Google можеше да си позволи — на позицията SRE инженери да наема хора, които имат квалификация на разработчици и още малко разбират от функционирането на работещи системи. Като проблем с наемането на такива хора има и самият Google — главно защото сам той конкурира себе си — трябва да някой да описва бизнес логиката. Доставката е натоварена на релиз инженерите, SRE инженерите управляват надеждността (разбира се, не директно, а влияейки на инфраструктурата, променяйки архитектурата, следейки промените и показателите, занимавайки се с инциденти). Красиво, възможно е. да пишете книги. А какво да правите, ако не сте Google, а надеждността все пак ви притеснява?

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

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

SRE не в Google

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

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

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