В последние годы произошло много разных событий, и мы, как большая организация, прочувствовали всё на себе. Пришлось очень быстро решать всевозможные проблемы. Хочу поделиться нашим опытом и сделанными выводами, которые кому-то покажутся спорными, кому-то — неуместными, а кому-то — очень важными. 

Историческая справка

Мы проанализировали разные исследования за длительный период (в основном от компаний 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 тоже стал отдельной профессией (или выделенной командой). На рисунке показаны основные сложившиеся у нас топологии команд, и все они соответствуют антипаттернам — как делать не надо. К тому же ещё и безопасность подкидывает интересные перспективные практики, вообще находясь вне команд.

Что делать? Идти в платформенную инженерию. И начать нужно с трёх столпов, на которых держится любая платформа:

1. Улучшить опыт разработки, построив внутреннюю платформу разработчиков.

2. Платформа — это не набор инструментов и подходов. 

3. Платформа — это некое объединяющее, сквозное решение, позволяющее не погружаться в обилие инструментов. Единый продукт, связывающий весь 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-инженер. 

• Для работы с моделями в рамках платформы необходима новая функциональность, а для этого нужны платформенным командам нужны навыки специалистов по машинному обучению.