За мотивами дискусії у чаті
Останнім часом розгоряються справжні битви щодо визначення поняття DevOps і SRE.
Незважаючи на те, що вже багато в чому дискусії на цю тему вже набили оскому, в тому числі й мені, вирішив винести на суд хабра-спільноти та свій погляд на цю тему. Тим, кому цікаво, ласкаво просимо під кат. І нехай почнеться все по новій!
Передісторія
Отже, у давнину жила окремо команда розробників ПЗ та адміністраторів серверів. Перші благополучно писали код, другі, вживаючи різні теплі лагідні слова на адресу перших, налаштовували сервери, періодично приходячи до розробників і отримуючи у відповідь вичерпне "на моїй машині все працює". Бізнес чекав на програмне забезпечення, все простоювало, періодично ламалося, все нервували. Особливо той, хто за весь цей бардак платив. Чудова лампова епоха. Ну та ви й так у курсі, звідки ростуть ноги у DevOps.
Народження DevOps практик
Потім прийшли серйозні дядьки і сказали – це не індустрія, тож працювати не можна. І притягли моделі життєвого циклу. Ось, наприклад, V-модель.
Отже, що бачимо? Бізнес приходить із концепцією, архітектори проектують рішення, розробники пишуть код, далі провал. Хтось якось тестує продукт, хтось якось його доставляє кінцевому користувачеві і десь на виході цієї диво-моделі сидить самотній бізнес-замовник і чекає на обіцяну біля моря погоду. Дійшли висновку – потрібні методи, які дозволять цей процес налагодити. І вирішили створити практики, які б їх реалізовували.
Ліричний відступ на предмет, що таке практика
Під практикою я розумію зв'язку технології та дисципліни. Приклад - практика опису інфраструктури кодом на terraform. Дисципліна це те, як описувати кодом інфраструктуру, вона у розробника в голові, а технологія це власне terraform.
І вирішили вони назвати їх DevOps практиками - думаю мали на увазі from Development to Operations. Вигадали різні складні штуки — CI/CD практики, практики, що ґрунтуються на IaC принципі, тисячі їх. І понеслася, розробники пишуть код, DevOps інженери трансформують опис системи у вигляді коду в працюючі системи (так, код це на жаль, лише опис, але ніяк не втілення системи), доставка крутиться, ну і так далі. Вчорашні адміністратори, освоївши нові практики, гордо перекваліфікувалися на DevOps інженерів, і все понеслося. І був вечір, і був ранок… вибачте, не звідти.
Все знову не слава богу
Тільки все вляглося, і різні хитрі «методологи» почали писати товсті книги по DevOps практикам, тихо розгорялися суперечки, хто ж такий все-таки горезвісний DevOps інженер і що DevOps — це культура виробництва, знову назріло невдоволення. Несподівано виявилося, що доставка ПЗ — абсолютно нетривіальне завдання. У кожної інфраструктури розробки свій стек, десь збирати треба, десь розгортати environment, тут потрібен tomcat, тут потрібен ще хитромучений спосіб запуску — загалом, голова тріщить. А ще проблема, як не дивно, виявилася насамперед в організації процесів — ось ця функція доставки, як пляшкова шийка, почала блокувати процеси. До того ж, експлуатацію (Operations) ніхто не скасовував. Її у 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 як набір практик експлуатації робить цю доставку успішною.
Джерело: habr.com