Привет! Меня зовут Олег, в IT я около 8 лет, и попал в отрасль тогда, когда начинался хайп вокруг гибких методологий разработки на российском рынке. Так что у меня была возможность своими глазами посмотреть, к чему все это привело в больших компаниях.
Кроме того, гибкие методологии разработки способствовали развитию инженерных практик.
Сейчас ситуация такова, что инженерных практик и инструментов существует очень много. Главный вопрос тут — зачем их внедрять и стоит ли их внедрять просто ради внедрения?
Вот, к примеру, набор из уже имеющихся практик и инструментов. Начинает напоминать какой-то зоопарк:
Причем этот список можно постоянно расширять.
В этом посте я предлагаю посмотреть на эти практики и инструменты не с технической точки зрения, а как на способ изменить коммуникацию между командами в большом энтерпрайзе.
Немного истории
Начнем с истоков — почему появился DevOps?
В компании есть разработчики и есть сопровождение. У каждого из департаментов есть свои конкретные цели. Разработка должна быстро доставлять новые фичи в прод, а сопровождение — сохранять доступность.
А ещё у них разные приоритеты: у разработчиков — time to market, у сопровождения — SLA.
Как это пофиксить?
Первый способ очевиден — взять и объединить всех в одну команду, поставить всем одну и ту же цель.
А если точнее — у каждого теперь будет по две цели.
В итоге разработчики начнут печалиться из-за того, что они положили систему после релиза, а сопровождение будет напрягаться, если фичу не поставили в срок. В такой схеме в компании вообще не должно быть администраторов и разработчиков. Получается своеобразная кросс-функциональная команда.
Это в теории. А вот в реальности (особенно у больших компаний) объединить всех в одну команду гораздо сложнее, чем кажется.
Второй вариант — немного костыльный. Можно сделать абстракцию команды, попробовать создать контракт взаимодействия между командами.
Когда два отдела общаются, у них нет четкого контекста обсуждения. Сопровождение обычно считает, что разработчики что-то сделали, сейчас внедрят какую-то непонятную штуку и кааааааак положат систему. А за KPI-то волнительно.
Разработчики же не понимают, чего сопровождение напрягается — нормально же всё сделали, сейчас внедрим, ничего не должно сломаться.
Таким образом, в какой-то степени инженерные практики и инструменты вроде IAC, CI/CD Pipelines решают проблему коммуникации, просто декларируя контракт.
Например, вы внедряете новую систему, фичу, пайплайн — и просто один раз договариваетесь между двумя отделами о том, как мы осуществляете поставку. И это чуть-чуть снижает проблему взаимодействия. Ведь если каждый раз мы внедряемся одинаково, вроде как на проблему эту можно чуть-чуть закрыть глаза, сопровождению, ну, наверное, хотя бы на этапе внедрения ничего не сломается.
IaaC
Если идти чуть дальше, также можно описать инфраструктуру и практику infrastructure as code
Допустим, мы описали инфраструктуру, и теперь при ее изменении мы тоже точечно фокусируемся на каком-то контексте. Например, если мы просто рядом добавляем новый сервер, на который не идет нагрузка, то тут и обсуждать нечего.
С этой стороны интересно смотрится контейнерная виртуализация и кубер-кластера с той точки зрения, что на самом деле это тоже некоторый контракт взаимодействия подразделений. Здесь есть манифесты, есть декларация, где описали инфраструктуру. И теперь, разговаривая с сопровождением, мы общаемся на уровне конкретных элементов контракта взаимодействия.
Вот пример — контейнер и под:
iVersion: v1
kind: Pod
metadata:
name: cm-vol-example
spec:
containers:
- name: mypod
image: alpine:latest
command: ["/bin/sh", "-c”]Например, мы хотим поменять версию. Все сразу видят, что меняется один элемент, и у меня появляется версия образа, значит, мы обсуждаем только образ. Так как CI/CD у нас уже настроена, мы не обсуждаем внедрение.
Такой подход помогает в решение озвученной проблемы еще лучше. Понятно, что это лучший вариант, это все-таки костыль, но применение этих практик помогает снизить затраты на коммуникацию при внедрении.
В реальном мире
Как обычно, всё несколько сложнее. Взаимодействие в большой компании надо выстраивать не только между разработкой и сопровождением, а между сотнями вот этих милых людей.
Есть юристы, финансисты, безопасность, архитектура. Само собой, это не все отделы компании, а только те, что уместились на скрин. Каждый отдел тоже преследует свою собственную цель.
Здесь же у нас, например, возникает проблема с безопасностью, потому что они пытаются сохранить безопасность системы, у них тоже свой KPI.
И мы приходим к проблеме с другой стороны.
Теперь у нас разработчики сталкиваются с безопасностью, support тоже сталкиваются с безопасностью. На самом деле это напоминает такую большую внутрикорпоративную разборку. И вот эту картинку.
Внедряются практики FinOps, NetOps и другие. И все пытаются описать контракт взаимодействия друг с другом.
Что можно делать с ИБ?
Вы помните, что у разработчиков в приоритете time-to-market, они пытаются быстро доставить релиз. Приоритет ИБ — сохранить безопасность системы.
Первый вариант — попробовать объединить в одну команду разработчиков и безопасность.
Если у кого-то получилось так сделать, напишите, пожалуйста, в комментах, как всё прошло.
Второй вариант — попробовать описать контракт.
С точки зрения ИБ, здесь приходит на помощь практика DevSecOps, когда мы пытаемся описать инструменты взаимодействия с безопасностью. По сути, мы пытаемся договориться с ИБ о том, что для нас безопасность.
Мы декларируем наши правила, например, синтаксического анализа кода. Скажем, мы пишем конфигурацию и декларируем, что если все отмечено зеленым, то это безопасно.
Если у нас есть уязвимости, то мы обсуждаем с ИБ именно конкретную уязвимость — что в таком-то пакете при такой-то поставке синтаксический анализатор кода обнаружил конкретную уязвимость. Причем еще и классифицируем такие уязвимости.
Плюс в том, что то же самое сделать для инфраструктуры и для контейнерной виртуализации. Тогда у нас получится контракт с ИБ, который мы пытаемся внедрить в наш pipeline.
Саму конфигурацию можно хранить в системе управления версиями (изменять ее, глядя друг на друга, и общаться через MR).
Другой вопрос — как объединить всех. Это сейчас неслабый вызов для нашей отрасли: как нам подружить все отделы, какие инструменты нам внедрить. Потому что на самом деле это пока все выглядит как точечное решение проблемы.
Приходите на митап
Тема, как видите, актуальная. Поэтому скоро мы проведем еще один митап под названием «Путь воина: как стать девопс-инженером и построить крутой карьерный путь», где я буду одним из спикеров (вместе с коллегами из СИБУР Диджитал, Сбермаркета, Магнита и ЛАНИТ.
Если вам интересно — подключайтесь (митап проведём в Zoom), все подробности и расписание уже на лендинге.