Ценность DevOps-культуры в 2020-х
Публичный постВот смотрите, есть некий DevOps, без которого ни одна техкомпания не может жить.
Что такое DevOps? В официальных интерпретациях это культура, охватывающая набор практик для ускорения цикла разработки – про SDLC, TTM и прочие акронимы. Грубо говоря, пилить софт быстрее, и чтобы он ломался медленнее.
Зачем нужен был DevOps? После всех прочитанных книг о DevOps создается впечатление, что это в первую очередь про "нормально делай – нормально будет". Судя по истории создания, движуха ведет отсчет с конца нулевых, когда кусок разработки уже мог в Agile, а кусок эксплуатации в общем конвеере все еще подвисал. То есть, DevOps затевался для ускорения поставки софта за счет ускорения админских вещей и более близкой коллаборации с админов с разрабами. Отчасти это было еще и про взаимозаменяемость: админ в целом знает, как работает код, разраб знает как работает инфраструктура и что может пойти не так.
Чего добилась индустрия с DevOps?.
Софт стали деплоить чаще и чище, это правда.
За последние 10 лет появилось неимоверное количество тулкита, решающее те или иные проблемы с CI/CD и автоматизацией инфраструктуры. Даже не про деплои, вот смотришь на тот же Zabbix со стороны Prometheus и больше не хочешь запевать шарманку про "Good Old Days"
Та же облачность позволила поместить инфраструктуру в код практически полностью, открывшись для коллаборации с разработкой.
С учетом того, что слово DevOps встречалось в каждом клочке такого прогресса, можно считать, что прогресс был вызван запросом – а запрос в свою очередь был вызван движением community.
Чего не добилась индустрия с DevOps?.
Инфраструктура не стала проще, она стала еще сложнее. Одно время был хайп на инфраструктуру по одной кнопке, как в Heroku, но на деле все это кануло в лету. AWS, Kubernetes, Prometheus, Terraform, Chef/Ansible: все эти инструменты требуют отдельного фулл-тайм специалиста, хотя задумывались, как элементы доступной инфраструктуры для разработчиков.
Silos остались. Конечно, они зависят от культуры. В компаниях с хорошей культурой о принципах DevOps, по крайней мере, задумываются. В бодишопах до сих пор принято все проблемы и заботы по работе нового сервиса валить на админов. Корпораты DevOps также затронул весьма поверхностно. В большинстве контор админов переименовали в DevOps-инженеров, а проблемы с непониманием и стеной несогласия остались и по сей день. В ответ на вопрос почему обычно встречается довод о недопрофессионализме в индустрии и о том, что только Netflix может себе позволить гармонию в вопросах delivery.
Культ карго, отпугивающий адекватный контингент. Зашедший в индустрию в виде чистого холста, на DevOps успели порисовать бюрократы со своими сертификациями; рекрутеры с тайтлом DevOps Engineer (усложняя попытки объяснить чем на деле является DevOps); хайпожоры, пытающиеся за счет имени движения продвинуть свой новый PaaS.
Что говорят о DevOps сейчас?
Перед заходом со своими вопросами в клуб я погулял по Hacker News и нашел множество отличных комментариев. Конкретики в текущее состояние DevOps они, правда, все равно не добавляют.
DevOps is a valuable role, and I'm glad there's a focus on supporting developers and their needs, and in empowering developers to manage their own build and deployment infrastructure. In a larger organization, having a dedicated person or team working closely with developers on software build, test, and deployment automation is great. [link]
DevOps is a movement. There’s no certificate, role, set of tools or prescriptive process. There’s no specification, it’s not a product, or job title. There’s no one true voice on what DevOps is or isn’t. It’s about attitude, ideas, customs and behaviors. Culture, paradigms and philosophy. It’s a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It’s a conversation. It’s about taking the best experiences and sharing those with others.
DevOps as an ideal is founded on the concept that there exists a set of people who want to be evenly responsible for both the development and the operations. I have not so far met more than one or two of these people, certainly not enough to staff a company with. Barring such miraculous hiring, viewing DevOps as getting your development people and operations people to work effectively together is just fine. [link]
Исходя из этой картины, у меня сегодня складывается субъективное впечатление стагнации и пессимизма (того самого, технологического). Некоторые задачи были решены в индустрии 3-5 лет назад, некоторые не решаются до сих пор, и прогресса в них не видится никакого.
Поэтому у меня к вам следующие вопросы:
- Какие проблемы остались в индустрии, которые может охватить scope DevOps-движухи?
- Релевантен ли сейчас вообще топик "DevOps как культура" в наши дни? Не настало ли еще время заменить его другим сводом практик?
- От кого должна исходить инициатива, когда мы говорим про внедрение практик? Это больше про технический менеджмент или про непосредственно самих DevOps-инженеров?
- В чем основная проблема реализации практик DevOps в вашей компании? Это про нехватку времени на реализацию? Квалификацию инженеров? Неявные результаты?
Инструментам и тулкитам надо повзрослеть, но это вряд ли случится, пока крупные игроки не наметят какой-то общий вектор развития, а не будут тянуть каждый одеяло на себя, как это происходит сейчас в AWS/GCP/Azure.
Ядро Linux очень сложное, но это инструмент, который кое-как подбит под общий знаменатель, уже является взрослым, никто не ожидает каких-то groundbreaking changes. Кубер же, Terraform, helm и прочие из набора повседневных средств SRE достаточно молоды, нестабильны и фрагментированны. Если на ядре 4.x ты хоть сейчас вполне можешь содержать живой и взрослый продакшн, то с последними достаточно уйти в отпуск чтобы всё сломалось.
Следствием этого как раз и является тот силос, который достаётся админам. Средний девелопер сейчас даже написать деплой в прод в разумное время не сможет, он просто посмотрит на этот бардак, скажет "ок, удачи, я ливаю" и оставляет этот кувшин со змеями тому, кому платят за фуллтайм-поддержку этой мерзости.
В нашем отделении больницы по аутсорсной разработе такая ситуация наблюдается:
Для решения текущих проблем бизнеса.
Опять бизнес. Бизнесу стала важна скорость выкатывания нового функционала клиентам. Оказалось, что если собрать под конкретный проект в одну команду - сборную солянку - девелоперов, тестеров, сисадминов и безопасников и посадить их рядом, то все завертится быстрее чем если бы они были частью разных организаций с разными большими боссами занимающимися политикой.
Инфраструктура стала проще, но для тех кто ей пользуется - self-service это ведь мантра DevOps.
Хотя и для тех кто ей управляет - тоже. Та же облачная инфраструктура - теперь (в общем случае, с некоторыми исключениями) чтобы замасштабировать или развернуть с нуля инфраструктуру под новый проект или рынок, не нужно планировать и выделять огромный бюджет, арендовать новые площади в дата центрах, закупать серверное и сетевое оборудование, отправлять в дата центр на несколько суток спецназ из сисадминов пережимать патч-корды и проводить первоначальную настройку этого всего. Теперь достаточно создать тикет в Джире для команды из нескольких человек, которая за пару спринтов развернет это все с помощью Terraform, Packer, Ansible и AWS/GCP/Azure без отрыва от своих основных задач.
В пессимизм можно впасть если вспомнить типичные pre-DevOps процессы и инфраструктуру, хорошо описанные в книге The Phenix Project, которые были нормой до популяризации этого движения.
В наши дни, во многих даже больших олдскульных корпорациях девелоперам не нужно больше неделями и даже месяцами ждать выполнения заявки на новую виртуальную машину или изменение настройки файрвола - теперь достаточно лишь кликнуть на кнопку или открыть пул-реквест. А это победа и торжество DevOps.
Я думаю, со стороны многих стартапов взаимодействие инфраструктуры и кода и нормальный процесс вокруг этого дела (как я понимаю devops) - это необоснованя трата ресурса.
Темп развития стартапов слишком быстрый, выхлоп стартапов скорее всего мизирный. И нанимать человека-двух в условиях ограниченного ресурса и времени на то, чтобы сделать все красиво - скорее всего без очень серьезной аргументации получит нет от бизнеса.
А когда стартап, пропустивший стадию выстраивания взаимодейтсивя инфраструктуры и кода, и заменяющий ее саасом \ рукатроном, выростает, понять откуда начинать делать лучше уже значительно сложнее
Задам наводящий вопрос, а что такое культура ?
(а потом приду и за проповедаю свое мнение и видение)
Так вот, культура это такое интересное явление которое можно начинать изучать когда прошло какое-то время, хотя-бы лет 10.
А до этого времени там слишком много всего лишнего и важные аспекты не выделены. Поэтому в 21м году можно обсуждать культуру сисадминства, а вот devops как-то еще рано.
Да и у каждой компании свое понимание что такое культура и иногда это выражается в витиеватых взмахах руками вместо явной вербализации.
Есть мнение что Devops подход появился как эмержентная практика когда программисты начали делать экстремальное программирование и подходов сисадминства стало не хватать. И Девопс отлично вписался когда появилась архитектура условных микросервисов (или хотя бы 1 сервис 1 виртуалка) в этот момент сисадминство перестало мастшабироватся и быть способным справится с управлением этой инфраструктурой.
Попутно там добавлялось ожидание того что девопсы еще налаживают коммуникации и ваще вся компания может делать девопс, но ынтерпрайзы не захотели менять политику и поэтому появились отдельный девопс отделы где ямл инженеры пилят код ибо так написал Гартнер. Ну и появилось семейство билд-инженеров - человек собирающий релизы, CI/CD - людей которые пишут pipeline сборки, infra/cloud инженеров которые пишут IaC, что там еще а ну logging/monitoring тоже отдельный инженер...
Получили еще пачку колодцев, а коммуникации запатчить забыли и получился ажаль вместо девопс-культуры ))
В некоторых стартапах еще бывают ростки девопса в том изначально не извращенном ынтерпрайзами смысле, но это редкость..
хех сказал в начале что рано изучать, а тут сделал портянку с описанием текущего стейта...
Тем не менее неявно считывается вопрос а что дальше ? куда двигаться что будет в будущем ?
Один умный человек сделал карту того как появился devops и что ждать в будущем и там фокус на serverless и ожидание того что serverless повлечет за собой создание новой архитектурной практики.. Ждемс..
Кроме того devops неплохо покрывал шаги в вот этой доктрине
И на самом деле особо не важно какова будет практика будущего, а вот покрытие шагов в такой доктрине приведет к решению тех проблем которые пытались решить девопсом, ажайлом и свеже расхайпленным тулингом
воспользуюсь моментом и пиарну свой канал где пишу об этом вот всем и копипащу умные мысли умных людей https://t.me/deep_thought_aas