"Война и мир" или DevOps в большом Enterprise

Всем привет! Меня зовут Марат Биккин. В Enterprise я работаю уже около 10 лет. За это время я прошел путь от разработчика 1С, был экспертом по технологическим вопросам, корпоративным архитектором, и вот теперь руковожу командой, которая внедряет DevOps.

Я буду рассказывать про DevOps в большой компании – как большие компании приходят к DevOps, с чем сталкиваются, на какие грабли наступают, на какие грабли наступили мы. Я не буду рассказывать основы о том, что такое DevOps и не буду погружаться в глубины технических деталей.

Поднимите руки - кто из присутствующих в зале работает в Enterprise или на Enterprise? Руки подняли где-то 20-30% – значит, вы точно в правильной аудитории. Всем остальным, я думаю, будет интересно заглянуть за занавес. Поехали!

 

Наше подразделение – дирекция региональных продаж (ДРП) Газпром нефти

 

 

Зададим контекст. Когда я буду говорить «мы», я буду говорить про Дирекцию Региональных Продаж (ДРП) – это бизнес-единица «Газпром нефти», которая непосредственно работает с клиентами (с физическими лицами, с мелкооптовыми клиентами).

• у нас около 6 миллионов клиентов;
• из них примерно 2 миллиона пользуются нашими мобильными приложениями;
• мы управляем примерно 1200 АЗС, правильнее сказать – точками продаж, потому что на них мы продаем не только бензин, но и кофе и сопутствующие товары.

 

 

• Для того чтобы все это работало, нужно достаточно много Ит-продуктов– их у нас действительно много, больше 70.
• По каждому продукту мы релизимся 1-2 раза в месяц.
• Время реализации проекта (Time-to-market) в среднем 130 дней для всех продуктов и примерно 70 дней для продуктов на 1С.

 

 

1С – это не самая большая и, может быть, не самая важная, но довольно значимая часть нашего ландшафта. Большая часть бэкенда ДРП работает на 1С.

Мы начали знакомство с 1С в 2008 году, и с той поры количество продуктов постепенно росло, количество одновременно работающих пользователей также, а количество экземпляров баз, как вы видите, снижалось. Кроме всего прочего, это означает, что мы научились работать с большими высоконагруженными приложениями.

 

Зачем нужна цифровая трансформация?

 

 

Давайте попробуем ответить на вопрос: «Зачем разрабатывать такое количество продуктов?»

Есть термин «Цифровая трансформация», который уже прошел пик своего хайпа. Сейчас я попробую рассказать, что это значит для нас.

• Во-первых, маржинальность нефтепродуктов падает. Рынок очень конкурентный и сильно зарегулированный поэтому нужны новые источники дохода.
• Во-вторых, буквально из ниоткуда появляются цифровые платформы. Это ребята, которые построили бизнес там, где, казалось бы, невозможно его сделать – например, «Яндекс.Такси» или «Додо Пицца».
• В-третьих, появились новые технологии, которые радикально поменяли клиентский опыт – опыт того, как клиент взаимодействует с нашим товаром или с нашей услугой. Самый простой пример – это, конечно, мобильный телефон. Я прихожу со своим телефоном на заправку – я могу выпустить из него карту лояльности, могу оплатить товары, могу заправиться с помощью приложения, не выходя из машины, могу изменить рецепт своего кофе, который будет приготовлен на АЗС. Если мы не будем этим заниматься, значит, этим будет заниматься кто-то другой, и мы рискуем остаться – если не без всех клиентов, то без большой их части.

 

Как масштабировать Agile-подходы к разработке в Enterprise?

 

 

Чтобы все это работало, большие компании внедряют гибкие практики разработки - все знают про Agile. Но вот беда – эти практики очень тяжело масштабируются на уровень большой компании. Это действительно трудно.

 

 

Существует множество фреймворков масштабирования. Один из них показан на слайде, называется SAFe. Глядя на него лично мне хочется сказать: «Это слишком сложно, пожалуйста, верните мне мой Waterfall».

 

 

Есть менее сложные, менее объемные фреймворки, например LESS HUGE. Но даже здесь появляется множество новых менеджерских ролей, таких как Scrum-мастер сегмента, многочисленные координаторы, множество каких-то совещаний. И роль инженерных практик, значимость того, как разработчики взаимодействуют с эксплуатацией и другими функциями Enterprise, отходит на второй план. Это не очень здорово.

 

 

В результате, гигантская ледяная стена, которая существует в Enterprise между разработкой и эксплуатацией на продуктиве, никуда не исчезает.. В единицу времени за эту стену может попадать только очень маленькое количество изменений.

 

 

Что с этим делать?

Мы тоже начали с того, что адаптировали Agile-практики в наших командах. Иногда даже отказались от подрядчиков и полностью пересобрали команду из собственных разработчиков. Мы действительно почувствовали результат – мы начали быстрее разрабатывать.

Однако это практически не оказало влияние на Time to Market, потому что разработка – это еще не все процессы.

 

 

Тут на сцене появляется DevOps, который обещает Enterprise масштабировать практики Agile с разработки на эксплуатацию и инфраструктуру – обещает вовлечь в этот процесс контролирующие функции, такие, как информационная безопасность и  корпоративные архитектура. Вообщем, много чего обещает. В  ходе моего доклада попробуем ответить на вопрос: «А все ли эти обещания  реализуются?».

 

Особенности DevOps в Enterprise

 

 

Когда вы приходите в команду и говорите: «Давайте внедрим DevOps», команда говорит: «Да сейчас, за день сделаем – возьмем BitBucket, Bamboo, Jira, Kubernates, соединим все это одной линией и все заработает».

Да, заработает, если у вас одна команда, одно окружение, одна среда развертывания…. Но в Enterprise обычно много команд и все они совершенно разные..

 

 

Вот это – наши основные языки программирования и фреймворки. На самом деле, их гораздо больше, порядка 20 – все на слайд я собирать не стал.

 

 

Соответственно, когда у вас будет вторая, третья, четвертая команда, вы увидите примерно такую картинку – взаимодействие уже начинает быть сложнее, линии становятся все более запутанными.

А если у вас 100 команд, получится спутанный клубок…

Я не стану показывать эту картинку, чтобы вас не травмировать.

 

 

Кроме того, есть и другие Enterprise-особенности, о которых я уже говорил. Это:

1.  требования аудиторов / регуляторов;
2.  ограничения информационной безопасности и корпоративной архитектуры;
3.  какие-то сложные сложившиеся процессы согласования.

Со всем этим в DevOps нужно как-то выживать.

 

Зачем тогда нужен DevOps в Enterprise?

 

 

Возникает очень простой вопрос: «Если так сложно, может не стоит и начинать?». Действительно, некоторые консалтинговые агентства говорят, что примерно 50% внедрений DevOps в Enterprise неуспешны. Я не могу прийти к своему финансовому директору и сказать – мне нужно X миллионов рублей, чтобы внедрить DevOps. DevOps – это такая крутая штука, современный способ разработки. Но с вероятностью 50% у нас ничего не получится.

 

 

Что с этим делать? Можно пойти за знаниями к тем, кто уже однажды прошел этот путь, кто уже достиг каких-то успехов и уже набил шишек. Я обращаю внимание на отчет DORA State of Devops (http://amp.gs/SHxu). Здесь и дальше в моей презентации на сером фоне будут приведены ссылки. Их можно скачать и использовать.

Этот отчет выходит 6-й год подряд, для его составления опросили больше 30 тысяч ИТ-профессионалов, которые так или иначе внедряли DevOps и используют его. И выводам этого отчета можно доверять – это достаточно статистически значимая выборка.

 

 

Я не буду говорить обо всех интересных выводах из отчета DORA State of Devops, вы можете почитать его сами. Обращу внимание на эту таблицу – по сути, это разница между тем, как разрабатывают те, кто только начинают использовать DevOps, и тем, как разрабатывает “элита” .

Иными словами, если вы, со своей командой разработки  нашли на рынке «денежное дерево» и все, что вы хотите – это быстро сделать продукт и это «денежное дерево» срезать, то помните, что существуют ребята, которые могут это сделать в 100 раз быстрее.

Здесь самое главное – это даже не эти цифры, а то, что у многих, у тех, кто начинает цифровую трансформацию, никаких цифр нет вообще. Вы не знаете, за сколько вы разрабатываете свой продукт и как быстро можете выпустить его на рынок:

• вы можете пойти к команде, собрать какие-то метрики вручную – это займет у вас несколько недель;
• потом вы несколько недель будете их обрабатывать.
• потом начнется новый релизный цикл и т.д.

 

 

Другими словами, цифровая трансформация – это такой большой авиалайнер:

• вы поднялись в воздух, но у вас нет панели управления, и вы свои координаты определяете по солнцу, а скорость определяете, высунув руку в окно – это не очень здорово;
• DevOps – это и есть та самая панель управления, которая предоставит все необходимые цифры о том, чтобы понять, что вы двигаетесь в правильном направлении.

 

Пять условий для старта внедрения DevOps

 

 

Подведем итоги – что нужно, чтобы вы могли стартовать проект по DevOps в вашей компании?

• Во-первых, вашей компании нужны цифровые продукты. Если у вас их нет, если у вас нет необходимости разрабатывать быстрее, тогда вам не нужен DevOps.
• Вы должны получить поддержку руководства – о том, как это сделать, мы немного поговорили.
• Важный пункт, который все недооценивают, который я недооценивал – это то, что у вас должна быть поддержка разработчиков. Мне всегда казалось, что стоит прийти к ним и сказать: «Ребята, тут есть классная штука, DevOps, внедрите его, и все будет быстрее» и все пойдут за тобой. На самом деле, нет. Очень много команд, и хорошо, если они тебе сразу скажут: «Нет, нам это неинтересно, у нас нет времени», еще хуже, если начнется режим итальянской забастовки. Они скажут: «Да, это крутая штука», а потом ничего не будут делать. Другими словами, это очень важно, нужно получить поддержку, а это достаточно сложно сделать, особенно если вы работаете с подрядчиками, а не с собственной командой.
• Вы должны понимать, как повлиять на метрики разработки в лучшую сторону
• И еще для старта проекта нужно, чтобы у вас был план.

 

Дорожная карта

 

 

У нас тоже был план, он достаточно простой – думаю, он типовой для таких проектов:

• сначала делаем аудит, понимаем, где мы находимся;
• потом выбираем инструменты;
• создаем прототипы и пилотируем их на командах;
• внедряем;
• масштабируем.

Вроде все достаточно просто.

 

 

Нам казалось, что нас ждет ровная дорога и где-то вдалеке светит солнце – символ того, что DevOps внедрен.

 

 

На самом деле, будет вот так – пороховой дым, локальные стычки, смешались в кучу кони, люди, и не все доживают до конца проекта.

 

Выбор инструментов для DevOps

 

 

Давайте пойдем по шагам

Я, наверное, не открою секрет, как в Enterprise обычно выбирают инструменты. Берут отчет Gartner, смотрят на лидеров в каждом классе и выбирают из этих лидеров.

Тут так не получится. В DevOps нет лидеров, при этом в DevOps очень много инструментов в разных классах.

Худшее, что вы можете сделать – это поверить какому-то вендору, поверить в то, что у него есть суперприложение, которое объединяет несколько классов и внедрить его. Вы попадете в ловушку вендорского lock-in, из которой будете потом долго выбираться. Но по счастью, у нас получилось не попасть, мы выбрали, по факту, лучший инструмент в каждом классе, и пошли дальше.

 

Процесс внедрения новых инструментов в большой компании

 

 

А что дальше? Те, кто работают в большой компании, наверное, знают, что дальше. Дальше – архитектурный комитет, который должен утвердить ваш выбор.

Со стороны это выглядит немного архаично: куча людей тратит довольно много времени чтобы выполнить такую большую задачу – забить мамонта. Во всем этом очень много шагов и это все выполняется достаточно медленно.

Предположим, вы все это сделали. Что дальше?

 

Пилотирование и создание прототипов

 

 

Дальше вы должны пилотировать.

И тут очень важно выбрать правильные пилоты:

• Я уже говорил про «итальянскую забастовку» и про то, что очень нужно, чтобы команда хотела внедрить DevOps, и у нее должны быть на это ресурсы.
• Нужно чтобы владелец продукта вас полностью поддерживал.
• Важно выбрать такую команду, которую можно было потом масштабировать:
• Если вы возьмете слишком технологически сложную команду, вы, скорее всего, споткнетесь.
• Если слишком простую, то скорее всего, ее решения невозможно будет масштабировать.
• Если вы возьмете какой-нибудь фреймворк, который использует только эта команда, скорее всего, это будет бессмысленно.

Поэтому мой совет – выбирать несколько команд, не все из них дойдут с вами до конца, не у всех получится сделать пилот, но, по крайней мере, на том, что получится, вы сможете дальше масштабироваться.

Кроме этого, та архитектура, которую вы выбрали... вы поймете что у неё есть ограничения, что ее недостаточно и надо будет где-то дорабатывать. И это нормально. Вы сделали MVP, вы потестили его на клиентах, поменяли и идете дальше.

 

Платформа DevOps ДРП

 

 

То, что у нас в итоге получилось, мы назвали это «Платформа DevOps ДРП» – это инструменты и сервисы, которые крутятся внутри корпоративной сети и предоставляют возможность использовать командам разработки инженерные практики.

 

 

Если погружаться глубже в детали, то получилось что-то наподобие вот этого. Хочу сразу сказать, что тут нет никакого rocket science, этот стек очень типовой для России в целом. Это практически повторение того, о чем рассказывал Валерий Максимов в своем докладе за исключением каких-то дополнительных инструментов.

• вы собираете требования, трекаете их в Jira, Confluence;
• вы разрабатываете в своей любимой IDE, где угодно – это может корпоративная сеть или вне нее, в каком-то облаке, это может быть какая-то среда разработки;
• дальше все это попадает в единую точку входа – GitLab;
• после этого проходит всевозможные проверки качества кода с помощью SonarQube, проверки информационной безопасности с помощью X-Ray, статических и динамических анализаторов;
• дальше все это тем или иным способом собирается Jenkins;
• развертывается на виртуалке или в контейнере;
• тестируется;
• и устанавливается на прод.

 

 

Важно сказать, что для 1С никаких отличий нет, все то же самое.

Мы, как 1С-ники иногда начинаем что-то выдумывать, не пытаемся искать на рынке существующие решения, а начинаем писать их самим. Вчера был доклад – по сути, ребята разработали свой собственный Jenkins для 1С. Мой совет – не надо так делать. Просто оглянитесь вокруг и используйте лучшее.

 

Основная проблема внедрения DevOps

 

 

Слайд, который мне дался с трудом.

Я всегда был очень техническим человеком, и продолжаю им оставаться. Верю, что технологии – если не меняют мир, то, по крайней мере, могут изменить проект. Но по факту технологии меняются слишком быстро. Виртуализация, контейнеризация, serverless – все это появилось очень быстро.

А вот культура меняется очень медленно. Я не могу взять и уволить половину людей в команде, потому что они не хотят применять DevOps. Я не могу сделать это в стартапе, тем более, не могу сделать это в Enterprise – это то же самое, что выстрелить себе в ногу.

 

 

Поэтому важно понимать, что DevOps – это не квантовый скачок. Это не переход из состояния 0 в состояние 1. Это больше похоже на лестницу, по которой вы будете долго подниматься наверх. И да, это – выход из зоны комфорта.

Продуктовым командам нужно научиться новым инструментам, продуктовым командам нужно полностью поменять свой подход. И это не только инструменты, но и взаимодействия.

 

Взаимодействие команды DevOps с продуктовыми командами

 

 

Мы, команда «Платформы DevOps ДРП», взаимодействуем с продуктовыми командами примерно так. По сути, это три направления взаимодействия.

• Первое – это «DevOps как сервис». К нам приходит команда, говорит: «Ребята, помогите». И мы делаем pipeline «от и до».
• Второй вариант – это совместная работа. К нам приходит команда, мы не знаем, как это делать, они не знают, как это делать. Мы вместе садимся и начинаем изобретать. Это может в итоге стать сервисом. А может навсегда остаться какой-то уникальной фичей для команды.
• И третья история – это фасилитация. Мы садимся вместе с Product Owner и пытаемся понять, отчего же в платформе кардинально не хватает, чтобы мне было удобно работать.

 

 

Надо сказать, что не мы это изобрели. Буквально на этой неделе вышла книжка Team Topologies. Это те ребята, которые делали сайт https://teamtopologies.com/ где были такие кругляши OPS\DEV, которые как-то пересекались между собой.

Так вот, они кардинально переработали этот подход.  В принципе книгу не обязательно скачивать, можно зайти на  сайт и  материалы посмотреть на нем. Там достаточно много их выступлений с объяснением того, как это работает.

 

Поменяйте подход к согласованию изменений

 

 

После того, как мы выбрали инструменты, внедрили тем или иным способом новую культуру, вы должны поменять ваш подход к согласованию изменений. Если вы этого не сделаете, у вас ничего не получится.

Вот эти разноцветные квадратики на слайде – это не просто квадратики. Я их взял из корпоративного стандарта по управлению изменениями. это – последовательные процессы, и они даже не все поместились у меня на слайд.

В общем, вы понимаете, что это долго. И это нужно менять. Без этого DevOps может быть, конечно, заведется, но большой выгоды не даст.

 

Привлекайте союзников

 

 

Чтобы изменить процессы в компании, нужно искать союзников, потому что любую битву невозможно выиграть без союзников.

Кто может быть союзником? Эксперты по информационной безопасности, корпоративные архитекторы, аудиторы  – любые обязательные согласующие или проверяющие процесс.

Дальше на примере информационной безопасности я попробую рассказать, как это можно сделать.

 

Побочный эффект от использования чужого кода

 

 

Картинка, которая, надеюсь, всем понятна – все сообщество Инфостарт возникло потому, что кто-то писал код и выкладывал его на сайт, а другие это использовали в своих проектах. Общемировая практики, все так делают (все видели мемы про stackoverflow ?). Когда я хочу что-то разработать, я первым делом поищу, не разработал ли это кто-нибудь другой.

 

 

Но когда мы берем такой код, мы, возможно, заносим с ним уязвимости. Или уязвимости, которая есть у существующей в коде библиотеки.

Конечно, я не нашел статистики по 1С (да и вообще к 1С эта аналогия не полностью применима), но по основным языкам программирования статистика примерно следующая – каждый год на треть прирастает количество найденных уязвимостей. По 1С был хороший доклад у Антона Дорошкевича, который пытался всех напугать, что уязвимости есть и в 1С и их могут использовать.

Хочу сказать, что наш сканер обнаруживает уязвимости в типовых продуктах, но это не означает, что это очень плохо. Уязвимость, по большому счету – это способ повысить привилегии у сотрудника, например, дать бухгалтеру посмотреть то, что он не должен видеть. Но, как рассказывал нам Антон, одно повышение привилегий может тянуть другое, и так в итоге мы можем потерять все данные всех наших баз.

 

 

Самое плохое, что исправление уязвимостей на проде примерно в пять раз дороже, чем исправление в среде разработки – мы тратим на это время наших и без того дорогих разработчиков. В Enterprise эта цифра, я думаю, еще выше – может быть в 10, а может быть и в 20 раз.

 

Причины появления DevSecOps

 

 

Если суммировать два моих предыдущих слайда, то получится, что информационная безопасность – это бутылочное горлышко.

У информационных безопасников очень много проблем, они не могут эти проблемы просто пропустить, сказать: «Да, пожалуйста, выпускайте на продуктив». Они должны с помощью разработчиков устранить эти проблемы, но это длительный процесс. И при этом мы вынуждены тратить очень дорогое время наших разработчиков – не чтобы разработчики делали фичи, а чтобы разработчики исправляли уязвимости.

Поэтому возник акроним DevSecOps, который рассказывает о том, как инструмент информационной безопасности встроить в pipeline, как сделать эти проверки автоматизированными.

Я не буду сейчас рассказывать об этом подробно, на эту тему можно сделать отдельный доклад.

 

 

Важно понимать, что для 1С все работает абсолютно точно так же. Есть разработка в EDT, в конфигураторе, где-то в облаках, по GitFlow или не по GitFlow – неважно. Все это попадает в GitLab. А на GitLab натравливается статический анализатор или динамический. Здесь для меня это просто черный ящик. Важно понимать, что мы не нашли такого анализатора для 1С на рынке и наша служба безопасности написала его сама для себя на 1С для 1С. Этот анализатор, по сути, зажигает красную или зеленую лампочку.

• Красную – если есть какие-то уязвимости в коде.
• Зеленую – если все ОК, можно выкатывать ваш pipeline дальше.

 

Стратегия масштабирования

 

 

Мы поговорили про то, как привлечь союзников, про то, как ускорить процессы согласования. Теперь немного поговорим про стратегию масштабирования (тиражирования).

Вы можете начинать масштабироваться, когда:

• у вас уже есть успешные пилоты;
• есть ресурсы в команде, чтобы делать это масштабирование;

Кто-то реализует DevOps в условиях GreenField – без всяких правил и ограничений, а потом, когда начинаются попытки его масштабировать, оказывается что это невозможно. Поэтому общий совет – не пытайтесь делать DevOps в некоем вакууме, делайте его сразу с точки зрения ваших стандартов. Если стандарты этого не позволяют, значит, их нужно адаптировать.

Как проводить масштабирование – честно признаюсь, мы сейчас находимся в процессе масштабирования, поэтому, возможно, в следующем году я буду рассказывать какие-то другие вещи, но сейчас они выглядят для меня следующим образом:

• Во-первых, это три направления взаимодействия с командой DevOps, про которые я говорил.
• Во-вторых, это большое количество продвижения – семинары, тренинги, обучение, кукбуки, постеры и пр.
• И в-третьих, вам нужна поддержка в самих командах. Если у вас ее нет, то вы не сможете масштабироваться.

 

Кривая успеха или «кривой успех»

 

 

Еще один важный слайд, который говорит о том, что DevOps – это не моментальный успех. Скорее всего, когда вы придете в команду и масштабируете на нее практики DevOps, у команды наступит некий провал в эффективности. Важно, чтобы в этот момент они не пошли к своим стейкхолдерам и не сказали, что ваш DevOps – это полная чушь и не ушли от вас.

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

 

DevOps в большой компании

 

 

Давайте финализировать – что такое DevOps в большой компании.

• Убедиться, что вы, ваша компания, готовы к этому. Это – пять условий, про которые я говорил выше
• Реализовать успешный Proof-of-concept,
• Правильно выбирать и утвердить инструменты - та самая картинка про “архитектурного мамонта”
• Развернуть платформу внутри или использовать готовую платформу в облаках ( если, конечно, вы имеете возможность использовать облака)
• Собрать правильную команду – без правильной команды, к сожалению, ничего не получится. Скорее всего, с помощью сторонних подрядчиков и консультантов вы этого не сделаете никогда, нужна именно сильная внутренняя команда
• Привлечь союзников которые участвуют в процессе разработки
• Тиражировать успех

Думаю, что с этим гайдлайном и с теми граблями, про которые я рассказал, вам будет проще и дорога к DevOps у вас будет более ровная.

Удачи!

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.