Компания iiko занимается написанием и продажей программного обеспечения для управления ресторанным бизнесом. Пять лет назад iiko стала предоставлять свои разработки по модели SааS (ПО как сервис), и тогда ей потребовалось создать блок эксплуатации и обслуживания. Компания практикует DevOps; об этом в преддверии конференции «Корпоративный DevOps 2019», посвященной DevOps как управленческому подходу и его роли в цифровой трансформации, которую издательство «Открытые системы» проведет в Москве 26 ноября, рассказал Сергей Гнутов, руководитель эксплуатации и технической поддержки компании iiko.
- Почему компания прибегла к DevOps?
Мы решили предоставлять свою продукцию как сервис, поэтому пришлось перестроить вcе процессы и идеологию взаимодействия внутри команды. Стандартный подход к управлению неприменим при работе с облачными сервисами: здесь любое действие требует гораздо большей скорости реакции, сложных инструментов и тесного взаимодействия в команде, начиная с тех, кто общается с клиентами, и заканчивая теми, кто пишет код.
Обычное управление с четкой иерархией и согласованием — простая, но очень громоздкая система. В современных реалиях, когда продукция требует обновлений каждый день, командно-административный процесс выстроить невозможно. Нужно либо содержать большую команду, либо до рынка продукт будет идти медленно. То и другое приводит к неэффективности компании.
- DevOps — подход к взаимодействию команды разработчиков и службы эксплуатации. Но чаще всего на конференциях об этом рассказывают представители одной стороны, разработки. Вы в своем выступлении предлагаете посмотреть на DevOps глазами службы эксплуатации. На чем сделаете акцент?
На проблемах, которые возникают при взаимодействии, на том, как на эти проблемы смотрит служба эксплуатации, и на нашем практическом опыте их преодоления.
.jpg) |
|
| Сергей Гнутов: «Внедрение DevOps в конце концов делает команду единым целым, с общим инструментарием, целеполаганием, задачами» | |
- В iiko быстро наладили этот процесс?DevOps позволяет справиться с проблемами за счет построения горизонтальных связей, гибкости и разрешения стандартных противоречий, существующих между командой эксплуатации и командой разработки. Как известно, первая всегда хочет стабильности, вторая – изменений. С DevOps все команды рассматривают продукт как единое целое. Этапы разработки, тестирования, эксплуатации остаются, но они подконтрольны единой команде. Это меняет подходы к отдельным этапам и к взаимодействию команд, позволяет компании быть экономически эффективной и снизить затраты на реализацию решений.
Внедрение не останавливается до сих пор – его нельзя разделить на стадии и отметить финальную точку. Одна из особенностей этого подхода заключается в постоянных улучшениях: нужно создать такую модель, которая фокусируется на недостатках системы и постоянно пытается их исправить. Мы не прекращаем работать над тем, чтобы новая операция была лучше предыдущей.
- Как у вас сочетаются SAFe и DevOps?
DevOps – концепция, SAFe – конкретный инструмент организационного и технического характера одновременно (Scaled Agile Framework, SAFe – фреймворк для реализации принципов Agile в крупных организациях – М. С.). И если технический аспект у agile-компаний разный (например, могут быть различные производственные среды), то управленческий – универсальный. Во всех таких компаниях есть этапы планирования, оценки эффективности исполнения и пр. SAFe объединяет команду для выполнения бизнес-задач. При этом в нем есть элементы, которые подходят для различных организационных моделей.
- Чем вам нравится именно SAFe?
SAFe хорошо детализирован, в нем понятно, что нужно делать. Проблемой гибких фреймворков является то, что они слишком размыты. Если спросите аудиторию, что такое Agile, то все дадут этому разные определения. А инструменты должны быть точные. Вы можете проводить разные исследования, но, например, микроскоп – всегда микроскоп, с определенной оптикой и настройками. Так и SAFe – у него четкие блоки планирования, исполнения задач, распределения ролей в командах, оценки эффективности изменений и т.д. Причем блоки могут функционировать автономно, для нас это важно. Ведь скорость – одна из ключевых характеристик изменений. Если вы полгода что-то готовите, а потом еще полгода это внедряете, то половина людей забывает за это время, что было в самом начале. Мы хотели, чтобы фреймворк заработал, так сказать, с колес. Поэтому стали постепенно встраивать SAFe в существующие процессы, и он показал себя хорошо.
- Если DevOps – мировоззренческая концепция, то как вы меняете мышление людей?
Это самое сложное – заставить сотрудников думать по-другому. Впрочем, такие изменения не происходят одномоментно. Человек, который хочет поменять идеологию компании, должен видеть картину сверху и понимать, как эту картину создать. И здесь, как в сказке про суп из топора. Сначала вы говорите, что можете сварить суп из топора, но потом просите немного соли, затем добавляете лук, далее – морковь. В конце концов у вас получается нормальный суп.
Так и с командой. Люди поначалу всегда отвергают изменения, в этом и корень проблемы. Но если у вас есть видение того, что нужно сделать, вы разобьете путь на несколько этапов. Сначала просто познакомите всех в команде, потом создадите канал коммуникации. Далее – подготовка совместного инструмента, планирование, эксплуатация, разработка и пр. Между тем вы постоянно улучшаете взаимодействие, в том числе и в неформальной обстановке – допустим, идете вместе пить пиво. Люди привыкают работать сообща; вы даете им целеполагание; они видят результаты. Все эти шаги в конце концов делают команду единым целым, с общим инструментарием, целеполаганием, задачами.
- А эти шаги надо продумывать заранее, или они скорее интуитивные?
Думаю, 50 на 50. Нельзя сделать универсальный список шагов и составить к нему инструкцию, инструментарий зависит от конкретной ситуации в компании. В то же время примерный общий набор шагов вполне понятен.
- Как новые люди внедряются в команду? Если с имеющимися сотрудниками надо провести немалую работу, то тяжело ли обучать новичков?
В DevOps это проще, чем в других средах, благодаря гибкости и горизонтальности подхода. Если новый человек приходит в систему, система сама его научит всему необходимому. Сначала вы выстраиваете систему, потом она начинает работать на вас. Поэтому с каждым конкретным человеком не нужно проходить все этапы – вы погружаете его в среду, и она делает свое дело.
- Как часто у вас меняются люди?
У нас довольно стабильная команда. Ротация кадров на уровне 10-15% в год. Это немного с точки зрения рынка.
- Покажете на конкретных примерах, как внедряли DevOps, что получалось, что нет?
Давайте оставим примеры для конференции.
