![](https://habrastorage.org/getpro/habr/upload_files/490/991/932/490991932a4c876a3bf0ee1b7cd7ba52.jpg)
В последние годы произошло много разных событий, и мы, как большая организация, прочувствовали всё на себе. Пришлось очень быстро решать всевозможные проблемы. Хочу поделиться нашим опытом и сделанными выводами, которые кому-то покажутся спорными, кому-то — неуместными, а кому-то — очень важными.
Историческая справка
Мы проанализировали разные исследования за длительный период (в основном от компаний DORA и Puppet), и вот что выяснили в наших «археоайтишных раскопках».
Сам термин «DevOps» пошёл в народ на конференции DevOps Days в 2009 году. А в 2011 году на LinkedIn в вакансиях начали появляться навыки, определявшие функции и задачи этой профессии, люди начали активно искать по этому слову. В 2013-м ещё не было никаких DevOps и SRE, потому что 75 % респондентов считали себя админами и инженерами, 17 % — IT-менеджерами, и 8 % — IT-консультантами. А уже в следующем году начали появляться первые специалисты, определявшие себя как DevOps. С годами их становилось всё больше. В 2018 году поголовье достигло пика, а затем начался спад, длящийся до сих пор.
![](https://habrastorage.org/getpro/habr/upload_files/791/5a8/bf3/7915a8bf384517c433b269a4b1013ffa.png)
Раньше в исследованиях писали, что DevOps занимаются автоматизацией, инструментами CI/CD, мониторингом, журналированием и другими задачами. Но с 2018 года в отчётах Puppet и DORA возникает роль SRE. При этом Google, который к тому времени купил DORA, сразу же поясняет, что не будет разделять DevOps и SRE, потому что это взаимодополняющие концепции, и будет писать их так: DevOps/SRE. Напомню, что SRE — это человек, который должен, владеть всем, чем владеет DevOps, и при этом иметь навыки разработки, больше заниматься надёжностью, доступностью и масштабируемостью систем.
В 2020 году появилась ещё одна роль — platform-инженер. Обратите внимание, как коррелируют графики:
![](https://habrastorage.org/getpro/habr/upload_files/431/52f/ef6/43152fef675e041c53f92d66fef2ea53.png)
Возможно, в будущем они сойдутся. Хотя непонятно, как скоро это случится.
Требования к platform-инженеру включают в себя все навыки DevOps и SRE, а также умение переносить какие-то узкие решения в общедоступные платформы, чтобы всем участникам стало проще, доступнее и удобнее.
Тренды
![](https://habrastorage.org/getpro/habr/upload_files/0c7/70d/774/0c770d77489e25509c7e73b15b02cbc7.png)
Наверное, всем знаком хайпографик Gartner. Я выделил на нём ключевые тренды, максимально повлиявшие на DevOps.
![](https://habrastorage.org/getpro/habr/upload_files/fdb/b7d/041/fdbb7d04110dc76f066231942be776d2.png)
Многие знакомые вам практики уже близки к плато продуктивности, они наверняка внедрены в ваших компаниях и приносят пользу. SRE уже не на пике, начинает сползать в долину разочарований, но я уверен, что эта роль тоже выйдет на плато. А на пике сейчас SLSA — новый набор практик про безопасность, учитывающих происходящее в мире. К ним подбираются platform-инжиниринг и AI/ML. GitOps ещё только в начале своего пути.
Теперь посмотрим, как эти тренды влияют на DevOps сегодня и повлияют в ближайшем будущем.
ИИ-помощники
Об этой технологии сейчас говорят на каждом углу и возлагают на неё огромные надежды. Вот что сегодня предлагают крупные компании:
![](https://habrastorage.org/getpro/habr/upload_files/7ce/51f/7bb/7ce51f7bb6e78796175493acaf791d90.png)
Эти помощники уже помогают снизить порог входа и быстрее писать код. У нас тоже есть подобная разработка — GigaCode. Вот для чего им пользуются на сегодняшний день:
![](https://habrastorage.org/getpro/habr/upload_files/507/ef7/ecf/507ef7ecf59e026973b802694a0468a2.png)
А вот оценка того, насколько сильно ИИ-помощники сейчас могут помочь в работе DevOps/SRE:
![](https://habrastorage.org/getpro/habr/upload_files/5ff/62e/14d/5ff62e14d039f15537a5f3abc59c8711.png)
Набор функций тут очень общий, в вашей компании он может чем-то отличаться, но в среднем он будет таким.
А что касается перспективного применения ИИ-помощников в DevOps/SRE, то общая картина такая:
![](https://habrastorage.org/getpro/habr/upload_files/b85/9c5/14e/b859c514e51104965a2aecf6feb40fa4.png)
С этими задачами мы сталкиваемся каждый день, и «вторые пилоты» могут серьёзно сэкономить нам время на выполнение рутины.
Когнитивная нагрузка
Отрасль очень быстро начала отклоняться от первичных ожиданий от идей DevOps:
DevOps стал названием профессии, хотя должен быть культурой.
Вместо формирования синергии многие организации просто перенесли нагрузку на разработчиков или DevOps-инженеров.
DevOps-теория не реализовалась на практике.
Многие видят в этом ключевую проблему — высокую когнитивную нагрузку. А чем она выше, тем быстрее наступает выгорание, люди разочаровываются в своей работе. В чём причина высокой когнитивной нагрузки? Люди вынуждены в своей работе заниматься чем-то очень слабо связанным друг с другом, плохо описанным, непонятным и сложным. И приходится всё это выстраивать в какой-то сквозной процесс, который даст определённый результат.
Когнитивная нагрузка бывает внешняя и внутренняя. Первая связана с подачей информации, вторая — с её сложностью. Нагрузку исследуют через физиологические реакции, поведенческие шаблоны и субъективные опросы.
Дэниел Брайант представил на PlatformCon 2022 вот такую таблицу, в которой показал, как с годами возрастала когнитивная нагрузка на разработчика:
![](https://habrastorage.org/getpro/habr/upload_files/1e3/cee/b03/1e3ceeb031215c63b15388eed13b1d12.png)
Сегодня доступно необъятное множество инструментов, все переходят на облачные вычисления, и попутно популяризируются такие сложные продукты, как Terraform, Kubernetes и другие. В результате ваш рабочий инструментарий вполне сегодня может выглядеть так:
![](https://habrastorage.org/getpro/habr/upload_files/4a9/7e7/454/4a97e7454badd3645a58e7c170952252.png)
Даже для самых простых задач разработчику приходится осваивать множество очень сложных инструментов. И здесь я хочу поделиться нашим опытом.
Платформенная инженерия
У нас в компании DevOps тоже стал отдельной профессией (или выделенной командой). На рисунке показаны основные сложившиеся у нас топологии команд, и все они соответствуют антипаттернам — как делать не надо. К тому же ещё и безопасность подкидывает интересные перспективные практики, вообще находясь вне команд.
![](https://habrastorage.org/getpro/habr/upload_files/d06/175/945/d06175945a634b238c90c940dfc36e3f.png)
Что делать? Идти в платформенную инженерию. И начать нужно с трёх столпов, на которых держится любая платформа:
Улучшить опыт разработки, построив внутреннюю платформу разработчиков.
Платформа — это не набор инструментов и подходов.
Платформа — это некое объединяющее, сквозное решение, позволяющее не погружаться в обилие инструментов. Единый продукт, связывающий весь SDLC.
Внутренняя платформа разработки
Эта концепция выделилась как тренд, как ветка платформенного инжиниринга. Сумма всех технологий и инструментов, которые платформа связывает вместе, призвана упростить клиентский путь и дать разработчикам простые возможности самообслуживания. Сейчас в этом направлении идёт очень много компаний.
А что не является платформой?
PaaS-подобные решения, которые имеют приставку «DevOps», например, Heroku. То есть всё, что не реализует весь жизненный цикл ПО.
Каталоги услуг, заказов, доступов и подобного. Это лишь интерфейсы к платформам.
Всё, что доступно из коробки, даже если оно называется платформой. Любая платформа создаётся под специфику конкретной компании, универсальных вариантов не бывает.
Если всё сделано правильно и хорошо, то платформа будет стимулировать масштабное повышение производительности и скорости разработки, создаст более эффективную рабочую среду для разработчиков и команд эксплуатации.
Основные функции платформы:
оркестрация инфраструктуры;
конфигурация приложений;
управление развёртыванием;
управление средами;
управление ролевыми моделями.
Мы отталкивались от референсной схемы архитектуры от Humanitec:
![](https://habrastorage.org/getpro/habr/upload_files/8b5/827/bf9/8b5827bf92587197ba085977f194f918.png)
Developer Control Plane — это рабочее место разработчика. У него есть IDE, API, ИИ-помощники, портал для взаимодействия с коллегами. Ему больше никуда не надо ходить. Нужно лишь, чтобы всё это начало работать: появились ресурсы, стенды, доступы и прочее. То есть ключевое в этой схеме — оркестратор, который может с уровня очень высокой абстракции забрать инструкции о том, что хочет разработчик, и интерпретировать их под всю сложность нижележащих инструментов и сервисов.
Команда платформенного инжиниринга
Успешная команда платформенного инжиниринга требует полного набора навыков DevOps/SRE и глубокие знания в интеграции систем. Она занимается стандартизацией, автоматизацией и возможностями самообслуживания, снижает порог входа в инструменты. То есть задача команды — проложить пути между золотыми клетками:
оптимизировать рабочие процессы;
расширять журналирование и мониторинг производительности, поиск потенциальных проблем;
визуализировать рабочие процессы для улучшения архитектуры платформы;
тесно сотрудничать с владельцами продуктов;
повышать скорость интеграций;
решать общие проблемы;
объединять все инструменты в бесшовный клиентский путь;
обучать сотрудников.
Как мы видим это у себя в Сбере:
![](https://habrastorage.org/getpro/habr/upload_files/bdf/809/73d/bdf80973d54dac0916070cc25160dae1.png)
Это топология команды в концепции развития платформы. Мы стремимся избавить продуктовые команды от DevOps-специалистов, чтобы они занимались созданием ценностей и зарабатывали деньги своими продуктами. А всю сложность чтобы скрыла под собой внутренняя платформа разработки. За CD сейчас отвечают продуктовые команды, и для снижения когнитивной нагрузки они вынуждены делать узкоспециализированные, точечные решения. Но это тупиковый путь, если инструменты централизованы: они могут меняться и дополняться новыми. Мы считаем, что DevOps-команды могут через сообщество в связке с командой внутренней платформы участвовать в развитии платформы, приносить туда свои решения, чтобы у них было будущее.
ML-инжиниринг
Выше я показывал, как ИИ-помощники помогают экономить время разработчика. Платформа практически во всех случаях ещё эффективнее освобождает нас от решения сложных рутинных задач. На что тогда DevOps/SRE-специалисту тратить это время? Очевидно, что можно помогать развивать платформу. Но Сбер очень активно применяет машинное обучение, у нас практически все продукты уже поставляются вместе с моделями. И мы понимаем, что где-то рядом рождается целая отдельная методология их поставки, которая будет отличаться от классического DevOps. Для обучения и дообучения моделей нужны данные и навыки работы с ними. При этом на рынке практически нет инженеров, умеющих работать с обычными дистрибутивами и моделями. При этом в Сбере очень востребованы МО-инженеры.
![](https://habrastorage.org/getpro/habr/upload_files/6a1/0c9/55a/6a10c955a7834696866e205bad3d207e.png)
Здесь зелёным выделены те дополнительные функции, которые сейчас рождаются, и в рамках которых нужно наращивать знания.
Подытожу: DevOps/SRE-специалист может развивать платформу, может учиться правильно выкатывать модели. Но платформа должна всё это каким-то образом реализовать, поэтому в ней должен появиться ещё один слой абстракции:
![](https://habrastorage.org/getpro/habr/upload_files/fae/f23/e88/faef23e885df43532e0bc8d43f8a15b5.png)
В завершение ещё раз повторю наши ключевые выводы по поводу будущего DevOps:
Платформы и ИИ-помощники снижают когнитивную нагрузку и объём рутины для DevOps/SRE-специалистов. Освободившееся время можно потратить на развитие новых практик и получение знаний.
Модели машинного обучения начинают внедряться повсюду вместе с продуктами и становятся их неотъемлемой частью. Нужно учиться выкатывать их правильно.
Для будущего DevOps/SRE-специалиста есть два перспективных направления: платформенный инженер и ML-инженер.
Для работы с моделями в рамках платформы необходима новая функциональность, а для этого нужны платформенным командам нужны навыки специалистов по машинному обучению.
Комментарии (7)
inf
11.09.2024 13:38+1DevOps-теория не реализовалась на практике.
Видимо потому что не было никакой теории, а лишь чьи-то хотелки, которые не опирались на действительность. А в действительности все хотят сидеть за стенами и перекидывать ответственость за неё. В этом смысле девопс даже вреден.. ходит тут стены ломает, людям работать мешает))
inf
11.09.2024 13:38Будущего у девопс-инженера примерно два:
Уйти в корпорцию и стать "набором инструментов" узкозаточеных на определённом куске "платформы".
Существовать в небольших стартапах оставаясь универсалом-многостаночником.
luxter
11.09.2024 13:38+1Спасибо, статья интересная. Идея "Мы стремимся избавить продуктовые команды от DevOps-специалистов" звучит отлично, а как с этим на практике?
В своём опыте работал в разных командах и везде разный уровень людей в разработке. Кто-то постоянно в запаре и не может/не хочет вникать вообще во что-то из девопс задач: деплой в прод ночью, откат, добавить переменную окружения к микросервису и ещё кучу всего, что обычно просят нас делать :) Люди либо не хотят, либо не умеют вникать, потому что привыкли, что есть девопс к которому можно прийти и попросить сделать, потому что это всегда девопсы и делают.
Полагаю, что для достижения желаемого ( из моего первого абзаца) должен быть очень высокий уровень процессов и культуры в команде/проекте. Что вообще редкость. Я, например, нигде не видел настоящего CI, чтобы каждый день все правки шли в мастер и была постоянная интеграция. Что говорить про остальное)
Tsimur_S
То есть девопсам навыками разработки обладать не нужно?
Vlan-48
Ну вообще странно видеть в статье которая позиционируется как анализ такой недочет. В полемику я вступать конечно не буду, достаточно прочитать две книги, про то как devops меняет мир и sre гугловскую и сразу понятно чем эти вещи отличаются.
Keirichs
Как я понял общаясь с коллегами, в банках вообще какое-то своё понимание кто такой devops инженер и причём в каждом банке это понимание своё.