Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service. В прошлых статьях мы описали подход и показали пути решения проблем с контролем ресурсов команды и инфраструктуры, с ними можно ознакомиться тут и тут. Сегодня мы поговорим о построении процесса взаимодействия команд разработки и тестирования со службой DevOps, при этом отходя от дежурств подразделения в чате.

Для начала попробую описать суть проблемы. Представим, что у нас есть небольшое подразделение, не более 5 человек, которое как служба - одна на все команды разработки и тестирования. Количество обращающихся команд может быть от 10 до 20. Казалось бы – не мало ли людей на такое количество команд? Да, не много. А не хотим ли мы увеличить состав? Но реальность такова, что проблему обращений надо решить с помощью имеющихся в наличии ресурсов, а потом, разобравшись с ней и построив процесс работы с бэклогом команды и пониманием его объёма, уже запрашивать ресурсы на расширение команды. Пока этого нет, можем рассчитывать только на имеющиеся руки.

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

• Отсутствие контроля за входящим потоком обращений;

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

• Не проводится RCA (root cost analysis) после каждого спринта;

• Количество задач в бэклоге только растёт, команда тонет в них, график выгорания команды стремится к 0.

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

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

Составляем табличку в базе знаний, например, в notion или confluence. Поскольку у нас спринты в 3 недели (у вас это могут быть спринты или релизы), то лучше в первый раз собирать информацию за 2-3 спринта. Для начала я бы собрал задачи с проблемами за этот период, у них может быть своя метка или epic link, если их нет, то предстоит увлекательное путешествие к тому, чтобы они появились. Если это 2-3 трёхнедельных спринта, то для начала, на примере jira, мы воспользуемся фильтром, чтобы их найти.

Берём задачи за период времени по проекту в jira и с нужным нам типом задач, добавляем назначение людей и получаем первый вариант фильтра:

project = BIM AND assignee in (aleksandr.krylov, pam, pam-pam, pam-pam-pam) AND createdDate >= "2023/10/01" AND createdDate <= "2023/10/21"  ORDER BY created DESC, duedate ASC

Рекомендую сразу сделать фильтр по полям, чтобы получилось что-то вроде этого:

Многие поля очевидны, другие мы будем разбирать в следующей статье по работе с бэклогом. Стоит отметить, что на данном этапе у вас скорее всего не будет индикатора того, что задача относилась к проблеме и её фиксу, поэтому вам предстоит это сделать. Я сделал epic – devops_troubleshooting и задачи с ошибками с разбивкой на спринты (отдельное поле под номер спринта) добавлял в этот epic. После этого у нас получится примерно такой фильтр, который дальше мы сможем использовать, меняя либо сроки, либо номер спринта и сразу видеть картину проблемных задач в конкретный спринт.

project = BIM AND issuetype in (DevOps) AND assignee in (aleksandr.krylov, pam, pam-pam, pam-pam-pam) AND "Epic Link" = BIM-35573 AND createdDate >= "2023/10/01" AND createdDate <= "2023/10/21"  ORDER BY created DESC, duedate ASC

В фильтр мы добавили тип задач DevOps, который ранее отсутствовал, и тут тоже надо будет потратить время на поиск и перенос старых задач, которые мы хотим посчитать, и добавить их в наш новый epic. Супер, теперь у нас есть список. Что мы с ним делаем? Заносим его в табличку с, например, такими полями:

• № - номер таски, чтобы знать их количество;

• Код задачи;

• Тема задачи;

• Автор задачи (дальше можно будет разделить их на QA и DEV);

• Исполнитель (человек со стороны DevOps);

• Статус по задаче, могут быть ещё не решённые;

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

• Тип ошибки. Описываем – что и почему произошло;

• Постоянное решение – как сделать так, чтобы это не повторялось. Обучить ребят не делать какую-то ошибку в данном случае – это тоже решение.

Итого у Вас получиться что-то в этом роде

Первые 2 строки в более читабельном виде

Если у вас есть не только решение проблем, но и консультации, их тоже стоит выписать в отдельную табличку и вести её от спринта к спринту. Зачем это делать? Чтобы точно понимать, сколько времени тратит команда не только на решение проблем, но и на консультации, которых тоже может быть не мало. Выглядеть такая табличка может так:

А теперь самое дикое и печальное. Внимание! Нам надо за этот период времени сделать выгрузку по всем сообщениям чата и группировать все обращения по схожим темам.

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

• Причина ошибки;

• Количество;

• Корневая причина;

• Workaround – описание, как решалось сейчас;

• Постоянное решение.

Получится у Вас что-то в этом роде:

Считаем всё, вырабатываем постоянные решения и реализуем. Спустя несколько спринтов, вы заметите динамику, а сама картинка начнёт меняться через 3-4 спринта в лучшую сторону, если вы всё делаете верно. Если нет, то значит есть решения, которые не работают и надо что-то думать дальше. Важно не забывать каждые 3-4 спринта делать сводную таблицу и смотреть, действительно ли есть улучшения, и если нет, то выяснять причины. Вот как это может выглядеть:

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

• Повышение компетенции команды за счёт обучений, чтобы они либо не совершали ошибок, либо умели сами их решать;

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

• Снятие обратной связи по проблемам с команд с целью понимания, какие инструкции им непонятны (где нужно что-то расписать подробней или более простым языком), каких инструкций или обучалок им не хватает (собрать информацию, добавить, провести обучение и поставить процесс снятия обратной связи на поток, например, раз в 1-2 спринта);

• Документирование. Не бывает много мануалов, поэтому мы много документируем, документируем до бесконечности. Больше документации богу документации.

• Реализовать индикаторы понимания, когда и почему может быть плохо их окружению, а где может сбоить элемент инфраструктуры. Для этого лучше всего собирать метрики и реализовать дашборды мониторинга. Частично это было затронуто в предыдущей статье, а более подробно в будущем расскажет в одной из статей мой коллега Алексей Зуев.

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

Таким образом, постепенно повышая квалификацию коллег, мы, в том числе, снижаем нагрузку из чата по типовым проблемам, постепенно переводя решение задач в jira. Любая проблема, требующая более N минут времени DevOps специалиста, фиксируется в виде тикета в jira. По опыту, это решение не всегда корректно. Потому как таких проблем может быть много. Например, когда мы только приняли подобное решение, проблем, требующих меньше N минут, могло быть на 2-3 часа в день. Как мы это узнали? Создали единую задачу, куда ребята списывали проблемы чата и вторую - для списания на консультации из чата. Собрав статистику, мы обратили внимание, что их сильно больше, чем мы ожидали. Поэтому, в итоге, мы этот пункт пересмотрели, создав большущий процесс, схему которого можно увидеть ниже. Комментировать что-то дополнительно я не буду, на картинке всё подробно описано. По факту, мы создали единый процесс взаимодействия всех команд с подразделением DevOps. Было больно и не просто, но часть процесса внедрения этого флоу была описана в предыдущих статьях, на которые я ссылался в самом начале. Согласно этому флоу, только на определённом этапе, если всё совсем плохо и ничто не помогает, требуется привлечение DevOps. Выглядит процесс так:

Возникает ошибка и запускается правило 30 минут, куда входит:

• снятие первичной информации о проблеме;

• привлечение dev ответственного за задачу;

• просмотр борды мониторинга на предмет наличия проблем с элементами инфраструктуры

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

А далее уже по флоу, указанному выше ;)

Таким образом, мы построили прозрачный процесс взаимодействия команд разработки и тестирования со службой DevOps, убрав дежурства в чате. Снизив общий поток задач по возникающим проблемам за счёт ведения постспринтового RCA, мы закрыли проблему хаотичного ведения задач через чат и порядка 60% активностей, поступающих через Messenger. Теперь попробуем перейти к решению следующей проблемы, а именно развития сотрудников.