Погружение в DevOps

Рыночный успех новых бизнес-идей в цифровой экономике определяется тем, насколько быстро, гибко и безопасно организован процесс непрерывного развертывания и сопровождения информационных систем поддержки бизнес-новаций. В цифровую эпоху потребителей не проймешь обезличенными обращениями или придуманными месяцы назад программами по привлечению внимания к товару. Они не станут неделями ждать, пока продакт-менеджеры согласуют со всеми смежными подразделениями каждый шаг. Изменения, реализованные программистами, должны доходить до клиентов за считанные часы.

Как же наладить бесконфликтное сотрудничество бизнес-подразделений, отделов разработки и эксплуатации, чтобы оперативно реагировать на внешние изменения и новые бизнес-вызовы? Как заставить работать вместе тех, кто привык к изоляции? Какое значение методология DevOps и связанные с ней практики имеют для бизнеса в условиях цифровой трансформации? Все эти вопросы обсуждались на конференции «Корпоративный DevOps 2019», организованной издательством «Открытые системы». Отличие этой конференции от многочисленных аналогичных мероприятий состоит в том, что ее участникам удалось сформировать объемную картину DevOps со стороны служб разработки, поддержки и бизнеса, погрузившись во все детали культуры производства ПО цифровой эпохи. Мероприятие проводится уже в третий раз и стало для издательства традиционным.

Антон Исанин, директор по разработке компании «Альфастрахование», поделился опытом DevOps-трансформации, в результате которой бизнес получил возможность быстро проверять гипотезы и мгновенно занимать рыночные ниши. У компании 13 млн клиентов, они приносят 11 млрд руб. прибыли, получаемой от сервисов, подготовкой которых занимаются 30 команд разработчиков и подразделений поддержки. Теперь, благодаря DevOps, приложения вводятся в промышленную эксплуатацию (причем без ущерба качества кода) не месяц, как раньше, а в течение двух дней. Однако быстрое развертывание чревато риском попадания дефектов в промышленные версии, и это способно дискредитировать продукт, хотя и компенсируется тем, что разработчики уже не боятся нарушить срок выпуска очередного релиза – выпустив еще сырой, но вполне пригодный для применения релиз, можно мгновенно получить отзывы от клиентов, разделив с ними ответственность за возможные просчеты. Однако здесь, по словам Исанина, важно соблюдать баланс. Так или иначе, любой сбой в предоставлении сервисов – это потеря денег, например лишь два часа простоев в год оборачиваются для страховой компании 10 млн руб потерь. Чтобы исключить такие ситуации, Олег Скрынник из компании Cleverics предложил применять простые и понятные метрики объективного сравнения команд: время на выполнение задачи; общее число задач в работе; загрузка команды на входе и выходе; число завершенных работ.

Антон Исанин: «Для успеха DevOps-трансформации важны не машины и технологии, а люди»

Критический взгляд на DevOps со стороны службы эксплуатации представил на конференции Сергей Гнутов, руководитель сервисного департамента компании iiko, предлагающей системы управления ресторанами. Сегодня компания в режиме SaaS обслуживает около 30 тыс. ресторанов в 30 странах мира, однако перейти с коробок на сервисную модель удалось далеко не сразу, потребовалось сформировать у команды, отвечающей за поддержку, новую культуру, без которой DevOps – пустой звук. Стремясь достичь приемлемых и таких важных для конкурентного рынка ключевых характеристик, как время вывода продукта на рынок и сокращение эксплуатационных издержек, компания обратилась к методологии, регламентирующей условия для обеспечения совместного целеполагания и планирования, а главное – поддержки непрерывных изменений.

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

«Любая система уязвима на стыках, и требуются единые средства мониторинга за продуктивной средой, в которую вовлечены различные специалисты», — подчеркивает Гнутов. За два года с момента начала работы по DevOps срок выпуска новых релизов сократился с трех месяцев до двух недель, при том что общее число приложений в контуре SaaS выросло в восемь раз.

Александр Поломодов (Tinkoff) предупредил слушателей о множестве мифов вокруг DevOps, затрудняющих понимание сути процесса непрерывной разработки и доставки приложений, начиная от отсутствия ясности при ответе на вопрос «кто или что такое DevOps?» и заканчивая «как внедрять DevOps?» Наличие различных толкований и спекуляций вокруг действительно сильно перегруженного термина «DevOps» сегодня мешает организации эффективного взаимодействия бизнес-подразделений, отделов разработки и эксплуатации.

Про инструментальные средства мониторинга работы команд рассказал Евгений Карасик, менеджер по продукту Mobile Center центра разработок компании Micro Focus: «В DevOps, как и в спорте, важна командная игра, однако команды в разных компаниях разные, а вот требования к их составу общие: владелец продукта, разработчик, тестировщик и др.». Компания предлагает средства интеграции инструментов непрерывной разработки, доставки и развертывания продуктов в реальном времени, способные обеспечить учет сиюминутных запросов пользователей, без чего сегодня уже не получить их признательности. В цифровую эпоху бизнес не спасут ни накопленные запасы данных о прошлом поведении его клиентов, ни вера в их приверженность бренду.

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

Почему отделы продаж знают и любят DevOps, рассказал Алексей Бондарев, директор департамента развития компании «Тионикс», национального оператора облачных сервисов в составе «Ростелекома». В компаниях, которые находящится под прессом постоянных изменений в продукте, обусловленных необходимостью учета непрерывно меняющихся требований клиента, невозможно работать без подобных DevOps методологий, позволяющих построить управляемый процесс принятия решений, взаимодействия подразделений как внутри организации, так и вне их при ясном понимании качества ПО.

Ключ к ускорению разработки — эффективное взаимодействие всех подразделений компании. Между тем, традиционно группы разработки были сосредоточены на том, чтобы изменения были выполнены в срок и не выходили за рамки бюджета, иногда — в ущерб надежности и сопровождаемости ПО. Службы эксплуатации, напротив, ратовали за стабильность монолитного продукта, что означало постоянные сложности при выпуске каждого очередного релиза. DevOps дает возможность выявить недостатки существующей архитектуры информационной системы, например неспособность монолитной структуры обеспечивать постоянные улучшения ПО. Теме трансформации методов и средств разработки как обязательной составляющей agile-трансформации посвятил свое выступление Александр Калиновский, ИТ-директор банка Home Credit.  В банке работает система на платформе Oracle, изначально нацеленная на решение единственной задачи, с зашитой внутри кода бизнес-логикой. Постепенно на эту систему «навешивались» все новые функции, и стало невозможным вычленять независимые программные компоненты для постоянного улучшения процесса создания конечной ценности  — для этого требуется «распилить монолит». Сегодня в Home Credit выходит два релиза ПО в месяц, а ранее было лишь три в год. 

Александр Калиновский: «В цифровую эпоху ИТ стали сферой коллективной ответственности множества взаимодействующих структурных единиц компании, сферой ответственности людей — представителей самых разных специальностей»

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

Большой интерес у слушателей конференции вызвал мастер-класс, проведенный Алексеем Ионовым и посвященный методам оценки уровня зрелости культуры DevOps. С помощью «DevOps-радара», по мнению Ионова, компании могут теперь создать собственную шкалу, позволяющую учесть новационные идеи команд и наметить конкретные пути дальнейшего совершенствования культуры.

«DevOps-радар» позволяет организации определить текущий уровень культуры DevOps и наметить направления ее совершенствования

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