Будущее DevOps-инженера
В последние годы произошло много разных событий, и мы, как большая организация, прочувствовали всё на себе. Пришлось очень быстро решать всевозможные проблемы. Хочу поделиться нашим опытом и сделанными выводами, которые кому-то покажутся спорными, кому-то — неуместными, а кому-то — очень важными.
Историческая справка
Мы проанализировали разные исследования за длительный период (в основном от компаний DORA и Puppet), и вот что выяснили в наших «археоайтишных раскопках».
Сам термин «DevOps» пошёл в народ на конференции DevOps Days в 2009 году. А в 2011 году на LinkedIn в вакансиях начали появляться навыки, определявшие функции и задачи этой профессии, люди начали активно искать по этому слову. В 2013-м ещё не было никаких DevOps и SRE, потому что 75% респондентов считали себя админами и инженерами, 17% — IT-менеджерами, и 8% — IT-консультантами. А уже в следующем году начали появляться первые специалисты, определявшие себя как DevOps. С годами их становилось всё больше. В 2018 году поголовье достигло пика, а затем начался спад, длящийся до сих пор.
Раньше в исследованиях писали, что DevOps занимаются автоматизацией, инструментами CI/CD, мониторингом, журналированием и другими задачами. Но с 2018 года в отчётах Puppet и DORA возникает роль SRE. При этом Google, который к тому времени купил DORA, сразу же поясняет, что не будет разделять DevOps и SRE, потому что это взаимодополняющие концепции, и будет писать их так: DevOps/SRE. Напомню, что SRE — это человек, который должен, владеть всем, чем владеет DevOps, и при этом иметь навыки разработки, больше заниматься надёжностью, доступностью и масштабируемостью систем.
В 2020 году появилась ещё одна роль — platform-инженер. Обратите внимание, как коррелируют графики:
Возможно, в будущем они сойдутся. Хотя непонятно, как скоро это случится.
Требования к platform-инженеру включают в себя все навыки DevOps и SRE, а также умение переносить какие-то узкие решения в общедоступные платформы, чтобы всем участникам стало проще, доступнее и удобнее.
Тренды
Наверное, всем знаком хайпографик Gartner. Я выделил на нём ключевые тренды, максимально повлиявшие на DevOps.
Многие знакомые вам практики уже близки к плато продуктивности, они наверняка внедрены в ваших компаниях и приносят пользу. SRE уже не на пике, начинает сползать в долину разочарований, но я уверен, что эта роль тоже выйдет на плато. А на пике сейчас SLSA — новый набор практик про безопасность, учитывающих происходящее в мире. К ним подбираются platform-инжиниринг и AI/ML. GitOps ещё только в начале своего пути.
Теперь посмотрим, как эти тренды влияют на DevOps сегодня и повлияют в ближайшем будущем.
ИИ-помощники
Об этой технологии сейчас говорят на каждом углу и возлагают на неё огромные надежды. Вот что сегодня предлагают крупные компании:
Эти помощники уже помогают снизить порог входа и быстрее писать код. У нас тоже есть подобная разработка — GigaCode. Вот для чего им пользуются на сегодняшний день:
А вот оценка того, насколько сильно ИИ-помощники сейчас могут помочь в работе DevOps/SRE:
Набор функций тут очень общий, в вашей компании он может чем-то отличаться, но в среднем он будет таким.
А что касается перспективного применения ИИ-помощников в DevOps/SRE, то общая картина такая:
С этими задачами мы сталкиваемся каждый день, и «вторые пилоты» могут серьёзно сэкономить нам время на выполнение рутины.
Когнитивная нагрузка
Отрасль очень быстро начала отклоняться от первичных ожиданий от идей DevOps:
DevOps стал названием профессии, хотя должен быть культурой.
Вместо формирования синергии многие организации просто перенесли нагрузку на разработчиков или DevOps-инженеров.
DevOps-теория не реализовалась на практике.
Многие видят в этом ключевую проблему — высокую когнитивную нагрузку. А чем она выше, тем быстрее наступает выгорание, люди разочаровываются в своей работе. В чём причина высокой когнитивной нагрузки? Люди вынуждены в своей работе заниматься чем-то очень слабо связанным друг с другом, плохо описанным, непонятным и сложным. И приходится всё это выстраивать в какой-то сквозной процесс, который даст определённый результат.
Когнитивная нагрузка бывает внешняя и внутренняя. Первая связана с подачей информации, вторая — с её сложностью. Нагрузку исследуют через физиологические реакции, поведенческие шаблоны и субъективные опросы.
Дэниел Брайант представил на PlatformCon 2022 вот такую таблицу, в которой показал, как с годами возрастала когнитивная нагрузка на разработчика:
Сегодня доступно необъятное множество инструментов, все переходят на облачные вычисления, и попутно популяризируются такие сложные продукты, как Terraform, Kubernetes и другие. В результате ваш рабочий инструментарий вполне сегодня может выглядеть так:
Даже для самых простых задач разработчику приходится осваивать множество очень сложных инструментов. И здесь я хочу поделиться нашим опытом.
Платформенная инженерия
У нас в компании DevOps тоже стал отдельной профессией (или выделенной командой). На рисунке показаны основные сложившиеся у нас топологии команд, и все они соответствуют антипаттернам — как делать не надо. К тому же ещё и безопасность подкидывает интересные перспективные практики, вообще находясь вне команд.
Что делать? Идти в платформенную инженерию. И начать нужно с трёх столпов, на которых держится любая платформа:
Улучшить опыт разработки, построив внутреннюю платформу разработчиков.
Платформа — это не набор инструментов и подходов.
Платформа — это некое объединяющее, сквозное решение, позволяющее не погружаться в обилие инструментов. Единый продукт, связывающий весь SDLC.
Внутренняя платформа разработки
Эта концепция выделилась как тренд, как ветка платформенного инжиниринга. Сумма всех технологий и инструментов, которые платформа связывает вместе, призвана упростить клиентский путь и дать разработчикам простые возможности самообслуживания. Сейчас в этом направлении идёт очень много компаний.
А что не является платформой?
PaaS-подобные решения, которые имеют приставку «DevOps», например, Heroku. То есть всё, что не реализует весь жизненный цикл ПО.
Каталоги услуг, заказов, доступов и подобного. Это лишь интерфейсы к платформам.
Всё, что доступно из коробки, даже если оно называется платформой. Любая платформа создаётся под специфику конкретной компании, универсальных вариантов не бывает.
Если всё сделано правильно и хорошо, то платформа будет стимулировать масштабное повышение производительности и скорости разработки, создаст более эффективную рабочую среду для разработчиков и команд эксплуатации.
Основные функции платформы:
оркестрация инфраструктуры;
конфигурация приложений;
управление развёртыванием;
управление средами;
управление ролевыми моделями.
Мы отталкивались от референсной схемы архитектуры от Humanitec:
Developer Control Plane — это рабочее место разработчика. У него есть IDE, API, ИИ-помощники, портал для взаимодействия с коллегами. Ему больше никуда не надо ходить. Нужно лишь, чтобы всё это начало работать: появились ресурсы, стенды, доступы и прочее. То есть ключевое в этой схеме — оркестратор, который может с уровня очень высокой абстракции забрать инструкции о том, что хочет разработчик, и интерпретировать их под всю сложность нижележащих инструментов и сервисов.
Команда платформенного инжиниринга
Успешная команда платформенного инжиниринга требует полного набора навыков DevOps/SRE и глубокие знания в интеграции систем. Она занимается стандартизацией, автоматизацией и возможностями самообслуживания, снижает порог входа в инструменты. То есть задача команды — проложить пути между золотыми клетками:
оптимизировать рабочие процессы;
расширять журналирование и мониторинг производительности, поиск потенциальных проблем;
визуализировать рабочие процессы для улучшения архитектуры платформы;
тесно сотрудничать с владельцами продуктов;
повышать скорость интеграций;
решать общие проблемы;
объединять все инструменты в бесшовный клиентский путь;
обучать сотрудников.
Как мы видим это у себя в Сбере:
Это топология команды в концепции развития платформы. Мы стремимся избавить продуктовые команды от DevOps-специалистов, чтобы они занимались созданием ценностей и зарабатывали деньги своими продуктами. А всю сложность чтобы скрыла под собой внутренняя платформа разработки. За CD сейчас отвечают продуктовые команды, и для снижения когнитивной нагрузки они вынуждены делать узкоспециализированные, точечные решения. Но это тупиковый путь, если инструменты централизованы: они могут меняться и дополняться новыми. Мы считаем, что DevOps-команды могут через сообщество в связке с командой внутренней платформы участвовать в развитии платформы, приносить туда свои решения, чтобы у них было будущее.
ML-инжиниринг
Выше я показывал, как ИИ-помощники помогают экономить время разработчика. Платформа практически во всех случаях ещё эффективнее освобождает нас от решения сложных рутинных задач. На что тогда DevOps/SRE-специалисту тратить это время? Очевидно, что можно помогать развивать платформу. Но Сбер очень активно применяет машинное обучение, у нас практически все продукты уже поставляются вместе с моделями. И мы понимаем, что где-то рядом рождается целая отдельная методология их поставки, которая будет отличаться от классического DevOps. Для обучения и дообучения моделей нужны данные и навыки работы с ними. При этом на рынке практически нет инженеров, умеющих работать с обычными дистрибутивами и моделями. При этом в Сбере очень востребованы МО-инженеры.
Здесь зелёным выделены те дополнительные функции, которые сейчас рождаются, и в рамках которых нужно наращивать знания.
Подытожу: DevOps/SRE-специалист может развивать платформу, может учиться правильно выкатывать модели. Но платформа должна всё это каким-то образом реализовать, поэтому в ней должен появиться ещё один слой абстракции:
В завершение ещё раз повторю наши ключевые выводы по поводу будущего DevOps:
Платформы и ИИ-помощники снижают когнитивную нагрузку и объём рутины для DevOps/SRE-специалистов. Освободившееся время можно потратить на развитие новых практик и получение знаний.
Модели машинного обучения начинают внедряться повсюду вместе с продуктами и становятся их неотъемлемой частью. Нужно учиться выкатывать их правильно.
Для будущего DevOps/SRE-специалиста есть два перспективных направления: платформенный инженер и ML-инженер.
Для работы с моделями в рамках платформы необходима новая функциональность, а для этого нужны платформенным командам нужны навыки специалистов по машинному обучению.
