Как мы перешли от аутсорса и создали свою эффективную команду DevOps

Меня зовут Кирилл Шагин, я руковожу командами SRE, DevOps и DBA в компании Ви.Tech — это дочка ВИ.ру. В наших IT-решениях мы используем современный стек, у нас 4 кластера K8S и более миллиона пайплайнов в месяц.

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

Как мы пришли к аутсорсу

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

Инженеры на аутсорсе настроили «кубы», CI/CD-пайплайны и начали внедрять современные DevOps-практики. В итоге мы определили 2 постоянные задачи, которые выполнялись силами аутсорсинга:

1. Помощь разработчикам с текущими проблемами (дежурства).

2. Решение плановых задач от команд разработки («разверните», «поднимите»).

Через три года начались проблемы…

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

Как следствие — просроченные задачи, подведенные разработчики и цели. Чтобы хоть как-то выйти из положения, часть задач команда разработки стала делать сама. Это привело к целому зоопарку технологий, так как разработчики глубоко не погружались в DevOps-практики и выполняли задачи на скорую руку, кто как «нагуглит».

Забираем у аутсорса дежурные задачи

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

1. Команда из шести человек (5 инженеров и 1 тимлид).

2. Дежурить должны все инженеры.

3. Процессы дежурств отсутствуют, поэтому придётся «идти на ощупь».

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

Для решения ситуации мы описали процесс дежурств, согласно которому инженер выполняет следующие действия:

1. Берёт задачу.

2. Ставит статус «в работе».

3. Решает задачу.

4. То, что не успел сделать, доделывает на следующий рабочий день.

5. После решения задачи обновляет документацию.

С помощью Grafana OnCall и Slack автоматизировали процесс обращений к дежурному. Разработчик писал в канал Slack и бот отправлял дежурному сообщение, которое содержало текст задачи и ссылку на тред.

Хорошо ли работает новый процесс дежурств?

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

• автоматизация не регистрирует заявки;

• непонятно было как передавать заявки между сменами дежурных;

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

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

Ещё одно важное правило — заявки должны решаться по очереди от старых к новым, чтобы задачи не терялись. Также прописали внутренний регламент для инженеров:

• дежурства проходят ежедневно с 09:00 до 09:00 следующих суток;

• на одного инженера не должно быть более двух дежурств подряд;

• дежурный был освобождён от встреч, которые не связаны с инцидентами.

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

• дежурный в будние дни с 09:00 до 18:00 (мск) решает заявки, которые поступают от бота в Slack;

• в будние дни с 18:00 до 09:00 и в выходные дни дежурный выполняет задачи только по инцидентам на продуктовом окружении;

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

• дежурство проходит по всем окружениям — prod и dev.

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

Что ещё могло пойти не так?

Людей в компании становилось больше, а вместе с этим росло количество заявок. В месяц к нам поступало 500 задач. Плюс ко всему — количество DevOps-специалистов в нашей команде тоже увеличивалось, их нужно было погружать в инфраструктуру, процессы, проводить адаптацию. Следовательно необходим был обмен знаниями.

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

Ответы на последние вызовы

Для решения этих вопросов мы выполнили следующее:

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

• для удовлетворения требований заказчика по качеству и скорости решения задач мы ввели показатели SLA: реакция на задачу — 2 часа, решение — 1 час;

• для правильной маршрутизации заявок в соответствии с зоной ответственностью, мы доработали бота. Теперь по кнопке в Slack бот отправлял заявку на первую линию, где специалисты могут правильно распределить заявку.

• для отслеживания эффективности работы инженеров ввели метрики:

  • время, потраченное на решение заявки;

  • количество возвратов к дежурному в рамках одной задачи;

  • отслеживаем сроки проверки решения задачи заявителями.

Сейчас решение задач у нас занимает 1 час, а время реакции меньше часа.

Последние доработки процесса нам дали следующие результаты:

• теперь мы можем давать обещание на конкретное время реакции на заявки в дежурную смену;

• есть выверенные метрики по заявкам в дежурную смену;

• мы понимаем типы проблем, с которыми к нам обращаются и что из этого можно автоматизировать;

• четко видим точки роста;

• понимаем, в какой момент необходимо увеличить количество дежурных, чтобы не пострадали показатели SLA.

Забираем у аутсорса плановые задачи

Чтобы забрать на себя плановые задачи, нам нужно было решить следующие вопросы:

• как собрать требования у разработчиков;

• как 5 инженеров могут обслужить 20 команд разработки (200+ человек) с разным стеком;

• разобрать зоопарк из технологий в пайплайнах, инструментов сборки и доставки.

Мы внедрили двухнедельные спринты, которые запускали каждую среду. Внутри спринта есть два созвона с заказчиками. На первом созвоне обсуждаем приоритет задачи, а на втором — информируем о прохождении спринта.

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

Далее необходимо было собрать обратную связь по нашей работе. И тут мы столкнулись с неожиданными препятствиями.

Весёлые истории по сбору ОС

Для сбора обратной связи нужно было ответить на следующие вопросы:

• Что спрашивать?

• У кого спрашивать?

• Какой формат опроса использовать?

Наш тимлид разработал подробный опрос, который покрывал все наши кейсы. В качестве респондентов решили привлечь руководителей отделов и дирекций. Мы посчитали, что руководители являются первоисточником целей. А из целей, как правило, появляются плановые задачи. Опрос составили в Google Forms.

В опросе предлагалось оценить по шкале от 1 до 10 следующие показатели:

• Скорость выполнения ваших плановых задач.

• Качество выполнения ваших плановых задач.

• Уровень информирования о статусе ваших задач.

Также необходимо было дать развернутый ответ, что хотелось бы улучшить в работе команды DevOps.

Опрос создали, сейчас все его пройдут и всё расскажут

Мы разослали опрос, поставил срок выполнения и стали ждать обратной связи. Периодически напоминали о прохождении опроса. Но по достижении срока выполнения, опрос прошли всего 2 человека. На основании такой базы невозможно было провести анализ. Например, на вопрос о скорости выполнения задач один опрашиваемый поставил оценку 2, а второй — 10.

Вторая попытка сбора ОС

Мы выбросили гугл-формы, вооружились ручкой и листком бумаги и пошли к тимлидам лично. А с сотрудниками, которые работают удаленно, назначили онлайн встречи. По итогам общения понятнее не стало. Мы получили требования, которые не дают конкретики: «сделайте хорошо», «сделайте качественно» и «сделайте вчера».

Эволюция сбора ОС

Мы закрыли тему с опросами, которую упорно развивали 5 месяцев. За это время отдел DevOps вырос в 3 раза. Поэтому мы выделили 3 направления и на каждое назначили отдельную команду DevOps:

• Кластерное направление: сеньоры и лиды;

• Направление тестовых стендов: мидлы;

• Направление CI/CD: мидлы и джуны.

Мы решили, что если сбор ОС с заказчиков не работает, то будем собирать данные на основании статистики. Первое, на что стали собирать статистику — это время нахождения задачи в статусе. Для измерения поделили статусы на 2 группы: «влияем на время в статусе» и «не влияем на время в статусе». Написали на Go экспортер и по API снимали данные с YouTrack. Полученную информацию складывали в Victoria Metrics и отображали в Grafana.

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

Мы получили следующие показатели по заявкам:

• Путь от «обращение создано» до «пройдена оценка» — 30 дней, 50 процентиль;

• Путь от «в работе» до «заблокировано на клиенте» — 8,77 дней, 50 процентиль и 18,3 дня, 99 процентиль;

• Путь от создания задачи до «выполнено» — 47,5 дней, 50 процентиль и 354 дня, 99 процентиль;

• Путь от «в работе» до «ожидает проверки» — 14 дней, 99 процентиль и 7 дней, 50 процентиль.

Работа над показателями в красной зоне

В первую очередь проверили, как выполняется оценка задач. Выяснили, что некорректно выставлялась оценка инженерами направления CI/CD, где работали мидлы и джуны. Также обнаружили проблему в формулировках задач. По-прежнему разработчики ставили абстрактные задачи. Например: «разверните быстро, качественно, с Postgres и на 3 ДЦ».

Еще две проблемы — неправильные статусы задач и большое количество заявок в статусе Code Review. То есть задача выполнена, но для закрытия требуется проверка заявителя. Как известно, все любят создавать, но мало кто любит проверять. В итоге в статусе проверки у нас висела большая часть задач, и долгое время они оставались без действий.

Для решения этих проблем мы предприняли следующие меры:

• Процесс оценки назначили на техлида;

• Задачи с абстрактными требованиями:

  • Оставляем без оценки;

  • Если такую задачу уже оценили ранее, убираем из спринта;

  • Возвращаем на доработку заказчику до тех пор, пока не будет ясных требований.

• Добавили детализацию в статусы:

  • Ожидание от отдела ЦОД;

  • Ожидание тестирования разработкой — ждем проверку со стороны разработчиков;

  • Ожидание отклика — ждем ответы на наши вопросы;

• Взяли под контроль Code Review. На дейли напоминаем лично кому какие задачи необходимо проверить.

• Создали ограничение на количество задач в состоянии Code Review. Если у заказчика числятся 2 задачи со статусом проверки, то его новые заявки не берутся в работу, пока он не выполнит эти проверки.

Итоговые метрики

В результате внедрения последних доработок мы получили следующие метрики:

• Отслеживаем количество задач в каждом статусе:

• Среднее время нахождения задачи в каждом статусе:

• Точность оценки

• Ситуативные «болевые точки», на основании которых можно строить графики и делать выводы.

Что изменилось в процессах

• Собираем задачи в спринт строго до определенного времени. Если заказчики хотят, чтобы их задачи попали в спринт, то им необходимо подготовить задачи к пятнице.

• Оценки по собранным задачам готовим за день до начала спринта. Чтобы не было ситуаций, что заказчики приходят на приоритезацию, а у задачи нет оценки.

• Выполняем подготовительные работы сразу, а не ждем планирования.

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

• Запретили изменять спринты «на лету».

• Жестко зафиксировали время спринтов.

• Оставили возможность подавать заявку без оценки. Но тогда по умолчанию назначаем ей оценку — весь спринт.

Что автоматизировали

• В «кубах» и на виртуальных машинах мы создали измерение выделяемых ресурсов, в «майках» (s, m, l, xl, xxl). Теперь команды легко друг друга понимают, когда обозначают вычислительные машины.

• Упаковали в роли Ansible всё, что было на техрадаре.

• Создали генератор плейбуков. Он помогает превратить роли Ansible в плейбуки, что позволяет выполнять развёртывание с помощью всего четырёх кнопок.

• Создали шаблоны развёртывания в Terraform. Теперь в репозиториях сервисов остались только конфигурационные файлы.

• Используем CDK от Terraform, чтобы дать разработчикам конфигурацию в yml. Это позволяет ограничить фантазию разработчиков, чтобы дальше yml они ничего не «городили».

Итоги внедрения новых процессов

• Путь от создания заявки до оценки — 20 часов вместо 30 часов;

• От оценки до выполнения — 20 часов вместо 45 дней;

• Проведение Code Review — 3,5 часов вместо 7 дней.

На основании полученного опыта хочу дать следующие советы:

1. Автоматизируйте взаимодействие с командой. Иначе придётся:

• каждый раз объяснять заказчику все тонкости процесса работы с DevOps отделом — «перейди туда», «нажми сюда», «сделай это».

• контролировать, что заказчик соблюдает все части процесса;

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

Сейчас нашему заказчику нужно нажать все лишь одну кнопку, чтобы развернуть сервис. По нажатию кнопки в DevOps автоматом создаётся 4 задачи, которые уже берут соответствующие инженеры.

2. Опросы работают только совместно со статистикой, которую нужно собирать самим.

3. Измеряйте все этапы работы над задачами.

4. Фокусируйтесь на улучшение тех этапов, на которые имеете непосредственное влияние.

5. Максимально декомпозированные задачи помогают всегда попадать в оценку. Например, если оценка задачи равна 10 часам, значит не достаточно декомпозирована. Сейчас у нас максимальная задача в спринте равняется 6 часам.

6. Автоматизация — ключ к уменьшению оценок. Так как убираем человеческий фактор, повторы, вероятность ошибки и упрощаем жизнь коллегам.