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

По мотивам дискусия в чата AWS Минск Общност

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

Предистория

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

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

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

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

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

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

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

Само всичко да се успокои, и различни хитри «методолози» започнаха да пишат дебели книги по DevOps практики, тихо започнаха споровете, кой всъщност е прословутият DevOps инженер и какво е DevOps — култура на производството, отново нарастна недоволството. Неочаквано се оказа, че доставката на софтуер е абсолютно нетривиална задача. Всяка инфраструктура на разработка има свой стек, някъде трябва да се сглобява, някъде да се развива среда, тук е нужен 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