Привет! Меня зовут Каро Манасян, я Chief DevOps Officer Московской биржи, и сегодня мы поговорим про… DevOps. Вокруг этого слова поднят такой уровень хайпа, что каждый интерпретирует его, как хочет. То ли это методология, то ли культура, то ли человек… Однако, на данный момент это понятие можно систематизировать и, не побоюсь этого слова, получить некоторую хрестоматию, так как с момента появления этой формы процессов разработки прошло достаточно много времени и можно все самое важное собрать в одном месте.
Давать классические определения DevOps или xOps не буду, так как на просторах habr достаточно много материала на эту тему. Я же не хочу, чтобы ты еще раз почитал, что DevOps – это «методология, направленная на ускорение процессов разработки…» Скучно 😄 Поэтому статья будет построена таким образом, чтобы ты узнал некоторые важные аспекты DevOps, о которых никто не упоминает в разговорах, а еще понял, как применить его здесь и сейчас (или с чего начать этот процесс в большой корпорации). Будет две части: в первой мы поговорим про soft-направления, такие как коммуникации, качество информации и единые цели, а во второй – про hard: технологии, разработку, CI/CD, архитектуру, тестирование и метрики.
Трехзвенная модель DevOps
Состав модели я поделил на 3 слоя:
Информация и коммуникации
Основой всего и вся является информация и связи между объектами, которые мы называем коммуникацией. Залогом успеха любого процесса или конвейера считаются правильно выстроенные коммуникации, где поток информации имеет высокий уровень качества.
Единая цель
Если каждый член команды или подразделение компании имеют разные цели (в глобальном смысле слова), то все остальные практики не будут иметь никакой ценности. Вспомните известную басню «Лебедь, рак и щука», которая отлично показывает, что бывает, когда каждый тянет в свою сторону, а работа с места не двигается, даже если у тележки есть прекрасные колеса.
Технологии
После коммуникаций и единой цели, технологии являются тем компонентом, которые упрощают и ускоряют процессы (про это – во второй части статьи).
Отличным практическим примером приведенной мной модели является опыт Сергея Павловича Королева, гения и основоположника отечественной космонавтики. Я всегда привожу именно его пример, так как создание космических аппаратов является очень сложной задачей с высокими рисками и неопределенностью. К тому же многих методологов и экспертов обвиняют в том, что они рассказывают теорию и в реальной жизни так не бывает, а опыт Сергея Павловича показывает обратное.
Итак, перед ним стояла задача создать первый космический пилотируемый корабль. Первым делом он объединил рабочих и проектировщиков в одну команду, так как не признавал делений и ограничений между разными ведомствами и подразделениями. Это позволило значительно упростить и ускорить обмен информацией между командами: согласитесь, быстрее и легче договориться с человеком, если он рядом. После этого он определил главную цель для всех – построить безопасный и качественный корабль. А затем применил некоторые технологии, которые позволили ускорить процессы разработки и исключить человеческий фактор. Отметим также фигуру самого Королева – он был настоящим лидером, который заряжал всех вокруг своими идеями и взглядами, а также умел набирать в команду поистине лучших. Конечно, это не все практики и подходы, но определяющую роль в этой задаче играла именно эта модель.
Коммуникации, или научите всех общаться
Что такое качество информации?
Обычно под качеством информации понимают набор свойств и характеристик, которые позволяют использовать ее эффективно и с низкими временными, человеческими и материальными ресурсами на ее обработку для получения ценности. Представим простой технический пример, где есть звено, обрабатывающее входящий звук. Чем больше помех и шумов в звуке, тем хуже будет выходной сигнал. Конечно же, сегодня различные технические решения позволяют обрабатывать практически любой сигнал, но ресурсы, потраченные на эту операцию, могут быть неоправданными. Качество информации можно измерить соотношением количества обратно возвращенных артефактов к количеству передач информации с одного звена в другое. Под артефактом мы понимаем некоторый результат, который получается в конце каждого этапа, готовый к передаче на следующее звено для обработки. Представим схему, на которой отображены 3 этапа:
Как видно из схемы, артефакты перемещаются между этапами слева направо, и одна из важнейших задач – минимизировать число возвратов артефакта на предыдущий этап для дополнительной доработки. Идеально, если таких возвратов не будет. Это будет означать, что все участники процесса понимают не только контекст своей задачи, но и контексты смежных этапов. Поэтому очень важно до внедрения CI/CD и всего инженерного нормализовать информацию, ее качество, структуру и восприятие. Говоря простым языком, стремитесь получать всегда максимально завершенный и понятный артефакт, который будет готов к обработке последующими звеньями. Как это понять? Очень просто – собирайте обратную связь от коллег.
Инженерная культура и сообщества
Важную роль в построении DevOps в компании играет фактор готовности людей к изменениям. Процесс внедрения новых практик в разы усложняется, если члены команд не готовы принять их или не понимают целей. Чтобы не допустить этого, необходимо ввести практику непрерывного обучения и повышения технической зрелости людей и команд. Любой новый инструмент или новый подход должны быть четко описаны и презентованы командам. Очень часто ошибочно делается акцент на инструментах и на процессах, но на самом деле на переднем плане в DevOps — люди, которые должны понимать, зачем и для каких целей внедряются те или иные паттерны.
Один из самых действенных вариантов упрощения коммуникаций и повышения осведомленности команд о новых практиках и подходах – это организация сообществ по направлениям. При этом нужно учесть, что сообщество должно иметь всегда:
лидера/лидеров;
четко определенные цели и повестку;
виртуальное грейдирование.
Развитие сообществ — это не задача одного дня или месяца. Это долгая и последовательная работа лидеров и заинтересованных людей. И здесь как раз начинает формироваться инженерная культура без выделения отдельных «DevOps-команд».
На Московской Бирже IT-сообщества — это объединение людей, связанных общими интересами и целями по технологическим практикам и подходам, направленным на ускорение принятия решений, сокращение времени доставки ценностей, а также развитие экспертизы сотрудников, обучение и личностный рост Сейчас мы находимся на начальном этапе создания сообществ и в будущем выпустим отдельную статью про наши достижения и успехи.
Мы у себя выделили 4 основных задачи в рамках развития инженерной культуры и сообществ. Их решения четко показывают системный подход, когда DevOps – не один человек отвечающий за все, а каждый айтишник в компании.
Единая цель, или куда мы идем
Стратегия DevOps-трансформации, или как двигать в правильном направлении
Блок единой цели я решил начать именно со стратегии DevOps в больших компаниях и это неспроста. Обычно мы привыкли под стратегией понимать некий большой и «страшный» документ, где описан план развития компании. Но в случае с DevOps это некоторое видение и шаги, как компания с точки А придет в точку Б. Без этого, мы получаем, как правило, эффект «слепых улучшений», когда бесконечно внедряем практики DevOps, но на что они влияют и какую ценность несут – не знаем.
Первая моя стратегия DevOps, которую я отправил CIO состояла из одной странички, где была показана текущая картина, картинка to-be с переходом на платформенную модель и тезис, какую это несет в себе пользу и ценности. В дальнейшем эту структуру as is/to be нужно детализировать до конкретных команд, шагов и местами технологий. Важно подчеркнуть, что на Мосбирже такая стратегия является частью ИТ-стратегии и тесно связана с ней. Если у вас в компании со стороны CIO и менеджмента нет целей трансформации в сторону DevOps, то ваша стратегия не сможет ни на что повлиять, и это будет подход «снизу», который, как правило, не работает или работает частями.
Один из самых распространенных вопросов на тему стратегий – это «Кто должен ее написать?» Составлять такой план должна роль, равноудаленная от подразделений разработки и сопровождения. В противном случае оценка текущего состояния может быть необъективной. Но при этом в составлении так или иначе принимают участие лидеры команд для получения более точной картины. Если рассматривать пример Московской биржи, то эту роль на себя взял новый Департамент по производственным процессам и инновациям, куда в свою очередь вошла команда DevOps-платформы.
Оргструктура и платформы
С вопросом, кто должен составить стратегию, мы разобрались, теперь давайте поймем, с чего начать блок as is. По моему мнению, оценка текущего состояния должна начинаться с организационной структуры, которая предполагает получение наглядного представления основных единиц. Данный этап позволит не только понять, как устроена структура, но и установить все связи между подразделениями. Иными словами, мы должны получить некую текущую карту со всеми взаимосвязями. Выше мы говорили про качество информации и коммуникаций, и здесь как раз мы смотрим на реальные связи, которые в конечном счете выдают ценность. Задача, на самом деле непростая, хотя, на мой взгляд, очевидная, но традиционные организационные диаграммы не помогают понять, каковы фактические модели коммуникации в вашей организации.
Чтобы получить такую картину необходимо обрисовать текущую структуру, формальную и далее на эту схему спроецировать фактическую схему взаимодействия с неформальной точки зрения, которая способствует созданию новых ценностей в компании. Представим 2 команды: разработка и сопровождение.
Однозначно можно сказать, что если мы рассматриваем весь поток создания некоторой ценности, то в отдельности – без взаимодействия и неформальной структуры – эти команды не смогут способствовать созданию продукта. Именно поэтому мы на формальную структуру наносим все взаимосвязи между разными людьми и командами, которые можно объединить в «круги создания ценностей».
Такую модель можно брать за основу для оценки текущего состояния структуры, которая поможет правильно определить вектор и тип стратегии по DevOps-трансформации. Подчеркну очень важный момент: к этому процессу нужно подходить масштабно и системно, по всей организации, так как локальные оптимизации отдельно взятых подразделений или групп помогают непосредственно вовлеченным сотрудникам и командам, но не помогают улучшить общую доставку ценности конечным клиентам. Их влияние на всю цепочку доставки ценностей может быть незначительным (в каких-то случаях даже отрицательным), если в процессе доставки имеются более серьезные узкие места (чуть дальше мы поговорим про это в контексте Value-Stream Mapping – VSM). Например, если команды внедряют подходы CI, инфраструктуру как код, решения контейнеризации, оркестрации или «умный» мониторинг, это может сократить время подготовки инфраструктуры или тестовых полигонов с нескольких месяцев или недель до нескольких часов или минут. Но если при этом каждое изменение требует долгих согласований или утверждений с разными уровнями руководителей, которые собираются раз в неделю или раз в месяц, то ценности будут доставляться в лучшем случае еженедельно, или же скорость вообще останется на прежнем уровне. Поэтому повторю еще раз: прежде чем внедрять разного рода практики и технологии, необходимо понять и изменить организационную структуру, культуру и взаимодействия таким образом, чтобы они способствовали результативному внедрению технологий, паттернов и подходов.
Чтобы этот раздел был полным, давайте поговорим про платформы. Сейчас практически все мировые IT-издания пишут, что создание платформ в больших компаниях значительно ускоряет и улучшает процессы и продукты. И в эту же историю сейчас идут компании при масштабировании DevOps. Почему такой подход кардинально отличается от подхода «DevOps-команды»? Инфраструктура как сервис, которая имеет готовые автоматизированные инструменты управления внутренними сервисами, является ядром платформенной модели. При таком видении предполагается, что любой разработчик и член команды сможет по нажатию кнопки получить нужный ему ресурс и начать разработку. Само слово «платформа» означает некоторый слой, над которым строятся производственные процессы, в отличие от «DevOps-команды», которая является частью и звеном производственного процесса. Рекомендую почитать книгу Team Topologies: Organizing Business and Technology Teams for Fast Flow. Там очень хорошо описаны эти аспекты.
Каждая компания может по-своему создавать платформы. Вот один из примеров структуры с DevOps-платформой, которая состоит из:
команды Платформы;
команды сложной подсистемы или complicated subsystem team;
департамента разработки(dev) с продуктовыми командами;
департамента сопровождения(ops);
департамента информационной безопасности;
команда-драйвер всего процесса.
И здесь мы видим, что команда платформы не имеет интеграций в команды разработки, а наоборот, является для них boost-площадкой, где есть все самое нужное.
Чтобы такая история полетела в правильном направлении, платформа должна обладать некоторыми свойствами, а именно:
обязательно давать возможность продуктовым командам (stream-aligned), выполнять работу с существенной автономией от команды платформы;
команда платформы должна относиться к сервисам, которые она предлагает, как к продуктам, которые должны быть удобными, понятными и легкими в использовании;
платформа создается для разработчиков и инженеров. Они являются клиентами для команды платформы, поэтому вы должны учесть их особенности и хотелки. И конечно же обращать внимание на UX/DevEx, чтобы решениями было приятно пользоваться;
масштабирование DevOps должно происходить по всей организации, а не только в небольших частях;
непрерывная обратная связь от команд: развитие, основанное на информации от конечных пользователей;
культура постоянного экспериментирования и обучения всех команд;
платформенная модель должна быть направлена на сокращение стоимостей разработки, сопровождения и выпуска релизов. Насколько именно – определяется в рамках метрик для каждой из команд.
Командообразование и лидерство
Давайте попробуем взглянуть на термин командообразования с точки зрения одной из основ DevOps. Эта основа нам говорит, что когда-то давно, были раздельные команды разработки и сопровождения, между ними были высокие и толстые стены, через которые они занимались перекидыванием софта, в какой-то момент эту стену сломали и получился DevOps. Окей, а как это сделать? В начале статьи мы как раз говорили про культуру и сообщества, которые сильно влияют на все команды и помогают им стать сильнее, но когда мы говорим про отдельно взятые команды, то здесь необходимы чуть другие подходы, которые смогут повысить результативность и командный дух, а также сформировать у них общие навыки работы в команде. Гугл мне подсказал, что «командообразование» – это бизнесовый термин, который используется в рамках создания и повышения эффективности команд. Тогда получается, что тимбилдинг — это набор инструментов, которыми сломали ту самую стену между dev и ops.
Процесс командообразования можно поделить на много частей, но основных – семь. Это:
формирование единой цели для команды;
повышение ответственности за весь продукт и результат у каждого члена команды;
совместное выполнение задач;
формирование креативности;
быстрый шаринг информации;
1-2-1 митинги и получение обратной связи;
повышение доверия между членами команды.
Центральный игрок в командообразовании – это лидер команды. Он должен постоянно поддерживать этот процесс и применять новые техники. Но многим руководителям мешают личные составляющие: гордость, страх набирать в команду людей, сильнее самого себя, неумение говорить «спасибо» и хвалить коллег, а также признавать собственные ошибки. Я привел всего несколько примеров, но весьма показательных, так как уверен, что именно они порой не дают команде состояться, а также найти линии продуктивной коммуникации и работы с другими подразделениями. Прежде чем ты пойдешь дальше по статье, послушай рецензию от Максима Лапина (CFO Московской Биржи) на книгу “Окружи себя лучшими” и поймешь, почему команда должна состоять из лучших.
Командообразование и лидерство являются важнейшей составляющей в практиках DevOps, именно поэтому параллельно рисованию стратегий, топологий и планов нужно учесть фактор командообразования и способы, которые помогут сделать этот процесс лучше.
VSM: карта потока ценностей
Value-stream mapping или карта потока ценностей позволяют найти в процессах проблемы и уязвимые точки. В целом можно сказать, что весь DevOps (имею в виду знак бесконечности) представляет из себя VSM. Говоря простым языком, если мы возьмем любой процесс, разложим на мелкие кубики или подпроцессы, выставим им исполнителей и определим начальную и конечную цели, то получим карту потока ценностей. Запрос VSM в интернете выдает очень много разных результатов, иногда даже пугающих и непонятных. С первого взгляда может показаться, что создание таких карт может быть весьма трудозатратным процессом, но на самом деле это не так, если начать с самого простого. Возьмите очень маленький кейс, выявите контекст и цели, расскажите про это всей команде и сделайте наброски на бумаге. Все, ваш первый VSM готов, и по нему уже можно сделать выводы и найти проблемные точки. Как раз такие VSM должны стать частью вашего плана по масштабированию DevOps.
Выводы
Качество информации и коммуникаций – наше все. Научите людей общаться и строить взаимоотношения, а руководителей – быть лидерами, которые набирают в команду сильнейших. Те самые soft-skills, которые я перечислил, развивать сложнее всего, но DevOps в первую очередь именно про это, а не только про CI/CD и про то, как задеплоить свой сервис в k8s, о чем сейчас много говорят и пишут. Я очень часто убеждаюсь в том, что всякие hard-задачи легко решить, когда люди и команды умеют общаться и поддерживать хорошую атмосферу. В свою очередь, это позволит создать крутую и сильную инженерную культуру в компании. Согласен, вещи очевидные, но далеко не все об этом говорят и обращают на них внимание. У меня у самого не всегда получается, но я стараюсь 😉.
Следующий важный блок – это стратегия и видение, которые должны описывать, где вы сейчас и к чему должны прийти с указанием стримов создания ценности (VSM), на которые направлена будет ваша стратегия. Те практики и мысли, про которые мы сегодня поговорили в статье, сейчас активно развиваются и совершенствуются на Московской бирже. Мы активно усиливаем инженерную культуру, создаем крутые продукты и сервисы, которые являются уникальными во всем мире.
На этом я заканчиваю первую часть большого материала по DevOps. Во второй части, которая выйдет чуть позже, расскажу про технологии и процессные паттерны, которые мы используем, а также о том, что из них работает отлично, а что не очень.
