
Привет, Хабр! Меня зовут Ахмед, я Deputy CTO в Сравни.
Сегодня расскажу вам об опыте управления дежурствами в ИТ-команде.
Представьте: вы нашли баг на проде; хотите рассказать о находке коллегам, которые отвечают за эту функциональность. Идёте в рабочий мессенджер, пишете в канал или групповой чат соответствующей команды.

А дальше не всё идёт гладко.
Инженер-1 – человек ответственный, но молчаливый – просто увидел сообщение и пошёл разбираться, не предупредив, что проблема взята в работу.
Инженер-2 – коллега более коммуникабельный – увидел сообщение позднее, написал, что начинает исследование проблемы. Получаем двух инженеров, занятых одной и той же проблемой – упс!

Не допустить такую и подобные ситуации поможет процесс дежурства. Вам достаточно будет указать в мессенджере специальный тег, на который отреагирует конкретный инженер – сегодняшний дежурный. Если нужно, вы сможете посмотреть состав дежурных в теге одним кликом (чтобы понять, кто конкретно займется вашей проблемой).
Давайте расскажу, как такое настроить.
Как появился наш процесс дежурства: боль → экселька → боль
Проблема “разные люди занимаются одной задачей” – не единственная беда, которая случается без настроенного процесса дежурств.
Другой пример с теми же вводными: вы нашли баг, идёте оповестить причастных. Инженер-1 очень занят и решает, что его коллеги точно подхватят вопрос.
Инженеры-2 и 3 заняты не меньше и тоже уверены, что люди из команды не оставят запрос без внимания. Ответственность размывается, проблема остаётся без реакции.
Кроме проблем на проде, поводом сходить к коллегам могут быть обращения пользователей (“что-то не работает”), проблемы с инфраструктурой; билд, в конце концов, не собирается.
Отлавливать и отрабатывать такие запросы с помощью дежурств – идея не новая. Подобная практика существует во многих компаниях; у нас – завелось не с первого раза.
Первыми из наших коллег к рабочей схеме дежурств пришли DevOps-инженеры.
В Сравни есть выделенная команда, которая выстраивает инфраструктуру и помогает разработчикам разбираться с сопутствующими вопросами. Разработчики приносили свои запросы в общий канал как угодно: не тегали ответственного или тегали всех сразу.
Проблема могла долго болтаться без реакции (“думаю, подхватит кто-то другой”), после этого эскалировалась на лида, тот точечно тегал ответственного сотрудника, которому необходимо было взять обращение в работу. Не самая удобная и комфортная схема; случалось недовольство и споры.
Глядя на всё это, лид DevOps-направления составил график дежурств и закрепил его в канале команды. Предполагалось, что коллеги, которые приходят с обращениями, должны ознакомиться с графиком ответственных и призвать конкретного человека.

На деле же экселька оказалась непосильно сложным каналом получения информации – её ненавидели, отвергали, проклинали, игнорировали.
Тогда ребята из DevOps обратили внимание на возможности планировщика в Grafana OnCall.
Там удалось обнаружить следующий воркфлоу:
Создаёте учетные записи для всех дежурных; линкуете учётки с корпоративным мессенджером.
Заполняете график дежурных в календаре.
Создаёте в мессенджере обезличенный тег, по которому коллеги будут меншенить дежурных. У нас устоялся нейминг вида {teamName}_duty.
Добавляете в Grafana ссылку на календарь, указываете название тега дежурного.
Готово – после синхронизации с календарем, Grafana будет автоматически подставлять в обезличенный тег нужного дежурного, которому будут приходить оповещения.
Календарь может быть любой, что умеет генерировать ics-ссылки. Привязки к какому-то конкретному почтовому серверу нет. График создается аналогично встрече. Вместо названия встречи указывается Grafana-юзернейм дежурного. Это может быть один или несколько человек. Можно управлять временными интервалами дежурств или выставить дежурство на весь день.
Трюк именно с тегом прямо сейчас доступен в Grafana OnCall только для Slack. Есть интеграции с Telegram, MS Teams и прочими; там можно будет настроить оповещения в рамках создания цепочки эскалации, чтобы присылать алерты о наступившем событии.
Давайте расскажу по шагам, как настроить расширенную версию воркфлоу, с тегами и Slack.
Инструкция по настройке
Этап 1: подготовка на стороне Grafana OnCall
Заходим в раздел Administration → Users and access → Teams.
Создаём команду.
Добавляем туда всех, кто будет дежурить.

Далее каждый участвующий в дежурстве человек должен зайти в свою учётку и привязать Slack-аккаунт: Alerts & IRM → OnCall → Users. Это нужно для автоматического назначения дежурного в тег.
Этап 2: подготовка на стороне календаря
Создаем отдельный календарь, название – любое.
В календаре создаем встречу.
Тут есть пара нюансов:
Вместо названия встречи нужно прописать юзернейм дежурного из Grafana.
Указываем часы дежурства.
Тут подойдут любые интервалы. Можно выставить весь день, в таком случае смена дежурного будет происходить по умолчанию в 00:00 UTC.

Создаём ссылку на календарь: Настройки → Посмотреть все параметры Outlook → Общие календари → Публикация Календаря

Копируем isc-ссылку.
Этап 3: создаем планировщик в Grafana OnCall
Возвращаемся в настройки Grafana OnCall: Alerts & IRM → OnCall → Schedules
Выбираем свою команду, созданную ранее, затем создаем новый планировщик (New Schedule):
Импортируем расписание (Import schedule from iCal Url)

Заполняем обязательные поля, необходимые для запуска ротации:
Name – название вашего дежурства;
Primary schedule iCal URL – ссылка на календарь, созданная ранее;
Assign to team – выбираем из дропдауна свою команду;
Slack Channel – открытый канал, куда будем слать алерты;
Slack user group – тег {teamName}_duty.

После заполнения обязательных полей жмём Create Schedule.
Синхронизация обычно занимает несколько секунд, по итогу видим наш график.

You build it, you run it
Этот воркфлоу разом закрыл все наши перечисленные выше боли – как те, с которыми приходилось сталкиваться коллегам с запросами, так и для дежурных.
Сейчас для того, чтобы сообщить о проблеме, не нужно искать какие-то таблички или оставлять безадресные сообщения. Любой желающий знает, что достаточно написать свой вопрос, проставить общий тег дежурного и конкретный человек займется твоим вопросом.
Любой дежурный знает, не заглядывая в календарь, что сегодня его дежурство – Grafana OnCall в назначенное время присылает уведомление в мессенджер.

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

Если хочется узнать, кто конкретно сегодня дежурит, просто жмём на тег:

Резюмируя все вышесказанное, могу сказать, что мы посчитали этот опыт удачным. Практику DevOps-инженеров подхватили разработчики – используют для дежурств по алертам и обработке обращений от коллег. Ещё эту практику сейчас внедряют у себя наши QA-инженеры, которые обрабатывают сообщения о проблемах клиентов на проде.
Для того, чтобы схема заработала, достаточно оказалось выбрать подходящий инструмент; в нашем случае – Grafana OnCall. Но инструменты – это всего лишь инструменты; могут быть разные, и для получения нужного результата пользоваться ими можно по-разному.
Что принципиально важно, без чего дежурства точно не поедут – зафиксировать договоренности, прозрачно и недвусмысленно.
Так и запишем:
Необходимое условие сетапа для дежурств: договориться о процессе;
Достаточное: автоматизировать.