Недавно я побывала на DevOpsForum 2019, которую устраивал Logrocon. На этой конференции участники пытались найти решения и новые инструменты для эффективного взаимодействия бизнеса и специалистов по разработке и информационно-технологическому обслуживанию.
Конференция удалась: было реально много полезных докладов, интересные форматы выступлений и куча общения с докладчиками. И особенно важно, что мне никто ничего не пытался продать, чем последнее время грешат спикеры на больших конференциях.
Выжимка из выступлений Райффайзенбанка, Альфастрахования, опыт Манго Телеком при внедрении автоматизации и другие подробности под катом.
Обычно, я устраиваю охоту за интересными мне спикерами в кулуарах. На DevOpsForum 2019 в поле моего интереса попал докладчик из Райффайзенбанка — Михаил Бижан. Во время выступления он рассказал, как они поступательно подсаживают свои команды на DevOps, зачем им это нужно и как продать бизнесу идею DevOps-трансформации. Ну и в целом, говорил о том, как увидеть свет в конце пайплайна.
Михаил Бижан, директор по автоматизации в Райффайзенбанке
Сейчас у них в компании не «тру DevOps». То есть он тру, но не во всех командах. При внедрении DevOps, они опираются на готовность команд как с точки зрения конкретных инженеров, так с точки зрения потребности продукта и зрелости той платформы, на которой этот продукт построен. Миша рассказал, как объяснить бизнесу зачем нужен DevOps.
У банковского сегмента есть несколько драйверов роста: стоимость услуг и расширение клиентской базы. Повышение стоимости услуг — не очень хороший драйвер, а вот рост клиентской базы — наоборот. Если конкуренты выпускают объективно крутой продукт, все клиенты уходят туда, потом со временем рынок выравнивается. Поэтому выведение на рынок новых продуктов и скорость их выведения — основная вещь, на которую ориентируются банки. Как раз для этого и нужен DevOps, и бизнес это понимает.
Следующее важное замечание: DevOps не всегда уменьшает time to market. DevOps не может работать один, это всего лишь часть процесса создания и выведения продукта на рынок от разработки до продакшена (от кода до клиента). Но все, что до кода, прямого отношения к DevOps не имеет. То есть маркетологи могут годами изучать рынок и всю жизнь догонять конкурентов. Необходимо быстро понимать, что нужно клиенту и планировать реализацию той или иной фичи — часто именно этого не хватает для того, чтобы DevOps работал и компания достигала цели. Поэтому, в первую очередь в Райффайзенбанке договорились с бизнесом о том, что необходимо научиться использовать DevOps. Автоматизация ради автоматизации не сильно поможет в борьбе за новых клиентов.
В общем, Миша считает, что DevOps нужно внедрять, но с умом. И надо быть готовым к тому, что в начале трансформации у команды будет падать производительность, она будет зарабатывать меньше денег, но зато потом это оправдается.
Еще один интересный для меня как для тестировщика доклад сделал Егор Маслов из «Манго Телеком». Презентация называлась «Автоматизация полного цикла тестирования в SCRUM команде». Егор считает, что DevOps создан именно для SCRUM, но в тоже время внедрить DevOps в SCRUM-команду достаточно проблематично. Так выходит потому, что SCRUM-команда все время куда-то бежит, некогда отвлекаться на нововведения и перестраивать процесс. Проблема также состоит в том, что SCRUM не предполагает выделения в команде суб-команд (команда тестировщиков, команда разработчиков и так далее). Ну и кроме того, для автоматизации существующего процесса нужна документация, а в SCRUM чаще всего документация отсутствует полностью — «продукт важнее какой-то писанины».
После перехода на SCRUM, тестировщики стали советоваться с разработчиками, как тестировать фичи. Постепенно объем функционала увеличивался, документация отсутствовала, и они стали ловить много багов в том функционале, в котором не было покрытия тестами и вообще уже не ясно кто и когда его тестировал. В двух словах — разброд и шатание. Решили перейти на автоматизацию тестирования. Но и тогда случился полный фейл. Они привлекли аутсорсных специалистов для автоматизации, которые писали на неизвестном для штатных тестировщиков стеке. Фреймворк для автотестов конечно работал, но после того, как аутсорсеры ушли, он прожил две недели. Далее была попытка введения автотестирования номер два. Она началась с того, что все нужно строить внутри компании, своими силами (правильный вектор: наращивайте экспертизу внутри), в рамках SCRUM, и в процессе создавать документацию. Стек для автоматизации должен быть равен стеку продукта (вот тут прям плюсую, ну не тестируйте вы проект на JavaScript чем-то иным). В конце спринта они устраивали демо того, как работает автотест, с участием всей команды (полезно). Таким образом, повышались вовлеченность в процесс автоматизации всех членов команды, а также доверие к автотестам и шанс на то, что данный автотест точно будет использоваться (а не будет закомментирован через месяц по причине постоянных провалов).
Между докладами прогулялась по стендам партнеров конференции и утащила/выиграла много всякой всячины. Эх, люблю я раздатку!
Вишенкой на торте DevOpsForum 2019 для меня стала часовая пленарная сессия с экспертами DevOps. Были приглашены четыре участника сессии, которые должны были посмотреть на DevOps с разных сторон: Антон Исанин (Альфастрахование, директор по разработке), Наиля Замашкина (Финтех Лаб, операционный директор), Олег Егоркин (Ростелеком, Agile-коуч) и Антон Мартьянов (независимый эксперт, смотрел на DevOps с точки зрения бизнеса).
Эксперты сели поближе к народу и тут понеслось: целый час участники из зала задавали свои вопросы, а эксперты отдувались. Иногда выходили настоящие дебаты. Вопросы были самые разные, например: нужны ли вообще DevOps-инженеры, почему нельзя вырастить их из системных администраторов, надо ли всем предлагать DevOps, в чем его ценность и так далее.
Затем, я пообщалась с Антоном Исаниным лично. Обсудили необходимость нести культуру DevOps в каждый дом и раскрыли темную сторону DevOps трансформации.
Представим, что все собрались и решили, что DevOps нужен как продукту, так и бизнесу и команде. Понеслись внедрять. Все получилось. Выдохнули. DevOps сделал нас ближе к клиенту, теперь мы быстро сможем выполнять все его хотелки. В итоге имеем большое подразделение Ops со строгими регламентами и требованиями, и оно все время фигачит дефекты на продукт, создает кучу заявок. Причем все дефекты идут со статусом «срочно», даже если клиенту неожиданно захотелось раскрасить кнопку в желтый цвет вместо зеленого. Растет проект, растет количество релизов и соответственно количество дефектов и непониманий новой функциональности клиентами. Ops нанимает еще 10 человек, чтобы успевать репортить дефекты, а разработка нанимает еще 15, чтобы успевать их закрывать. И вместо того, чтобы внедрять новые фичи, команда работает с бесконечными SD’шками, поясняя функционал пользователю да и саппорту за одно. В итоге и Ops, и разработка при деле, но клиент и бизнес недовольны: новые фичи застревают. Получается, DevOps вроде есть, а вроде его и нет.
Про необходимость внедрять DevOps Антон однозначно заявил, что это напрямую зависит от масштабов бизнеса. Если обслуживание одного клиента в год приносит компании миллиард — DevOps не нужен (при условии, что тебе не нужно выкатывать этому клиенту новые изменения регулярно). Все и так в шоколаде. Но если бизнес растет, появляется больше клиентов, тогда надо уже соответствовать. Как правило, крутого Ops в компании изначально нет. Сначала мы пилим продукт, а только потом понимаем, чтобы продукт работал, нужно посматривать за серверами, следить за поставками. Тогда и возникает Ops. Остается понять, что Ops, как отдельное подразделение начнет выставлять кучу барьеров для разработки и все поставки начнут буксовать. То есть в данном кейсе культура DevOps уже актуальна, только нужно не забывать про ее темную сторону.
Конференция удалась: было реально много полезных докладов, интересные форматы выступлений и куча общения с докладчиками. И особенно важно, что мне никто ничего не пытался продать, чем последнее время грешат спикеры на больших конференциях.
Выжимка из выступлений Райффайзенбанка, Альфастрахования, опыт Манго Телеком при внедрении автоматизации и другие подробности под катом.
Меня зовут Яна, я работаю тестировщиком, занимаюсь автоматизацией, а также DevOps и обожаю ходить на конференции и митапы. За последние два года я была на конференциях Олега Бунина (HighLoad++, TeamLead Conf), на мероприятиях Jug (Heisenbug, JPoint), на TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Первым делом я обращаю внимание на программу конференции. В меньшей степени смотрю на то, о чем будет доклад, в большей степени — на спикера. Даже если доклад окажется очень технологичным и интересным, не факт что ты сможешь применить какие-то best practices из доклада у себя в компании. И тогда тебе нужен спикер.
Свет в конце пайплайна в Райффайзенбанке
Обычно, я устраиваю охоту за интересными мне спикерами в кулуарах. На DevOpsForum 2019 в поле моего интереса попал докладчик из Райффайзенбанка — Михаил Бижан. Во время выступления он рассказал, как они поступательно подсаживают свои команды на DevOps, зачем им это нужно и как продать бизнесу идею DevOps-трансформации. Ну и в целом, говорил о том, как увидеть свет в конце пайплайна.
Михаил Бижан, директор по автоматизации в Райффайзенбанке
Сейчас у них в компании не «тру DevOps». То есть он тру, но не во всех командах. При внедрении DevOps, они опираются на готовность команд как с точки зрения конкретных инженеров, так с точки зрения потребности продукта и зрелости той платформы, на которой этот продукт построен. Миша рассказал, как объяснить бизнесу зачем нужен DevOps.
У банковского сегмента есть несколько драйверов роста: стоимость услуг и расширение клиентской базы. Повышение стоимости услуг — не очень хороший драйвер, а вот рост клиентской базы — наоборот. Если конкуренты выпускают объективно крутой продукт, все клиенты уходят туда, потом со временем рынок выравнивается. Поэтому выведение на рынок новых продуктов и скорость их выведения — основная вещь, на которую ориентируются банки. Как раз для этого и нужен DevOps, и бизнес это понимает.
Следующее важное замечание: DevOps не всегда уменьшает time to market. DevOps не может работать один, это всего лишь часть процесса создания и выведения продукта на рынок от разработки до продакшена (от кода до клиента). Но все, что до кода, прямого отношения к DevOps не имеет. То есть маркетологи могут годами изучать рынок и всю жизнь догонять конкурентов. Необходимо быстро понимать, что нужно клиенту и планировать реализацию той или иной фичи — часто именно этого не хватает для того, чтобы DevOps работал и компания достигала цели. Поэтому, в первую очередь в Райффайзенбанке договорились с бизнесом о том, что необходимо научиться использовать DevOps. Автоматизация ради автоматизации не сильно поможет в борьбе за новых клиентов.
В общем, Миша считает, что DevOps нужно внедрять, но с умом. И надо быть готовым к тому, что в начале трансформации у команды будет падать производительность, она будет зарабатывать меньше денег, но зато потом это оправдается.
Автоматизация тестирования в «Манго Телеком»
Еще один интересный для меня как для тестировщика доклад сделал Егор Маслов из «Манго Телеком». Презентация называлась «Автоматизация полного цикла тестирования в SCRUM команде». Егор считает, что DevOps создан именно для SCRUM, но в тоже время внедрить DevOps в SCRUM-команду достаточно проблематично. Так выходит потому, что SCRUM-команда все время куда-то бежит, некогда отвлекаться на нововведения и перестраивать процесс. Проблема также состоит в том, что SCRUM не предполагает выделения в команде суб-команд (команда тестировщиков, команда разработчиков и так далее). Ну и кроме того, для автоматизации существующего процесса нужна документация, а в SCRUM чаще всего документация отсутствует полностью — «продукт важнее какой-то писанины».
После перехода на SCRUM, тестировщики стали советоваться с разработчиками, как тестировать фичи. Постепенно объем функционала увеличивался, документация отсутствовала, и они стали ловить много багов в том функционале, в котором не было покрытия тестами и вообще уже не ясно кто и когда его тестировал. В двух словах — разброд и шатание. Решили перейти на автоматизацию тестирования. Но и тогда случился полный фейл. Они привлекли аутсорсных специалистов для автоматизации, которые писали на неизвестном для штатных тестировщиков стеке. Фреймворк для автотестов конечно работал, но после того, как аутсорсеры ушли, он прожил две недели. Далее была попытка введения автотестирования номер два. Она началась с того, что все нужно строить внутри компании, своими силами (правильный вектор: наращивайте экспертизу внутри), в рамках SCRUM, и в процессе создавать документацию. Стек для автоматизации должен быть равен стеку продукта (вот тут прям плюсую, ну не тестируйте вы проект на JavaScript чем-то иным). В конце спринта они устраивали демо того, как работает автотест, с участием всей команды (полезно). Таким образом, повышались вовлеченность в процесс автоматизации всех членов команды, а также доверие к автотестам и шанс на то, что данный автотест точно будет использоваться (а не будет закомментирован через месяц по причине постоянных провалов).
Кстати на DevOpsForum 2019 работал открытый микрофон — давно известный и, на мой взгляд, полезный формат выступлений. Ходишь ты такой, слушаешь доклады, а потом решаешь, что в рамках конференции стоит обсудить некую тему или проблему, поделиться релевантным опытом решения задачи.
Еще я подметила то, что организаторы сделали поток коротких докладов. Каждый доклад длится не более 10 минут, потом идут вопросы. Таким образом можно охватить сразу много тем и пристать с вопросами к спикерам, которые заинтересовали.
Между докладами прогулялась по стендам партнеров конференции и утащила/выиграла много всякой всячины. Эх, люблю я раздатку!
Круглый стол и вопросы DevOps c директором по разработке в Альфастраховании
Вишенкой на торте DevOpsForum 2019 для меня стала часовая пленарная сессия с экспертами DevOps. Были приглашены четыре участника сессии, которые должны были посмотреть на DevOps с разных сторон: Антон Исанин (Альфастрахование, директор по разработке), Наиля Замашкина (Финтех Лаб, операционный директор), Олег Егоркин (Ростелеком, Agile-коуч) и Антон Мартьянов (независимый эксперт, смотрел на DevOps с точки зрения бизнеса).
Эксперты сели поближе к народу и тут понеслось: целый час участники из зала задавали свои вопросы, а эксперты отдувались. Иногда выходили настоящие дебаты. Вопросы были самые разные, например: нужны ли вообще DevOps-инженеры, почему нельзя вырастить их из системных администраторов, надо ли всем предлагать DevOps, в чем его ценность и так далее.
Затем, я пообщалась с Антоном Исаниным лично. Обсудили необходимость нести культуру DevOps в каждый дом и раскрыли темную сторону DevOps трансформации.
Представим, что все собрались и решили, что DevOps нужен как продукту, так и бизнесу и команде. Понеслись внедрять. Все получилось. Выдохнули. DevOps сделал нас ближе к клиенту, теперь мы быстро сможем выполнять все его хотелки. В итоге имеем большое подразделение Ops со строгими регламентами и требованиями, и оно все время фигачит дефекты на продукт, создает кучу заявок. Причем все дефекты идут со статусом «срочно», даже если клиенту неожиданно захотелось раскрасить кнопку в желтый цвет вместо зеленого. Растет проект, растет количество релизов и соответственно количество дефектов и непониманий новой функциональности клиентами. Ops нанимает еще 10 человек, чтобы успевать репортить дефекты, а разработка нанимает еще 15, чтобы успевать их закрывать. И вместо того, чтобы внедрять новые фичи, команда работает с бесконечными SD’шками, поясняя функционал пользователю да и саппорту за одно. В итоге и Ops, и разработка при деле, но клиент и бизнес недовольны: новые фичи застревают. Получается, DevOps вроде есть, а вроде его и нет.
Про необходимость внедрять DevOps Антон однозначно заявил, что это напрямую зависит от масштабов бизнеса. Если обслуживание одного клиента в год приносит компании миллиард — DevOps не нужен (при условии, что тебе не нужно выкатывать этому клиенту новые изменения регулярно). Все и так в шоколаде. Но если бизнес растет, появляется больше клиентов, тогда надо уже соответствовать. Как правило, крутого Ops в компании изначально нет. Сначала мы пилим продукт, а только потом понимаем, чтобы продукт работал, нужно посматривать за серверами, следить за поставками. Тогда и возникает Ops. Остается понять, что Ops, как отдельное подразделение начнет выставлять кучу барьеров для разработки и все поставки начнут буксовать. То есть в данном кейсе культура DevOps уже актуальна, только нужно не забывать про ее темную сторону.
