Расписание дежурств живет тут

Цель

Обеспечить стабильную поддержку работы витрины, при этом минимально влияя на Work-Life-Balance разработчиков.

Концепция

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

• следит за основными каналами нотификации об инцидентах
• локализует инциденты
• выполняет передачу инцидентов P3/P4 в соответствующие продуктовые команды
• самостоятельно устраняет инциденты P1/P2 на проде

Владелец процесса

Антонов Дмитрий, лидер бекенд разработки вертикали

Классификация инцидентов

• P1 - не работает основной сценарий использования, затронуто > 10% аудитории
• P2 - не работает вспомогательный сценарий использования, затронуто > 10% аудитории
• P3 - не работает основной сценарий использования, затронуто < 10% аудитории
• P4 - не работает вспомогательный сценарий использования, затронуто < 10% аудитории

SLA

Для описанных приоритетов инцидентов действуют следующие SLA

Каналы нотификации об инцидентах

• служба эксплуатации
• Телеграм-чат

График дежурств

Дежурства осуществляются по-очереди, длительность дежурства - 2 будних дня/ночи или 1 выходной день/ночь. Расписание составляется заранее, в начале месяца владельцем процесса. В случае необходимости в график могут быть внесены изменения - например, в случае отпуска или болезни. Сделать это можно с согласования с владельцем процесса. Актуальное расписание выкладывается на страницу Confluence.

Компенсация

Так как дежурства накладывают ограничения на Work-Life баланс, их нужно оплачивать. Схема оплаты - факт дежурства считается как 4 рабочих часа1. Дежурства аккумулируются и оплачиваются в конце месяца.

Процесс обработки инцидента

• дежурный получил информацию об инциденте
  • в нерабочее время: получил сообщение в Телеграм или звонок от дежурного
  • в рабочее время: получил сообщение в каналах нотификации или зафиксировал алерт от системы мониторинга
• проводится подтверждение инцидента - проверка того, что в системе в самом деле есть неработоспособность
  • на этом этапе в т ч убеждаемся, что причиной не является флакающая метрика
  • если причиной является флакающая метрика - заводим задачу на ее фикс
• проводится классификация инцидента
• в случае, если инцидент пришел не от дежурного сотрудника эксплуатации, осуществляется оповещение дежурного сотрудника эксплуатации об инциденте через чат “Инциденты СММ”
• осуществляется регистрация инцидента - заводится задача с типом XXX в проекте MVM
• проводится локализация инцидента: определяется компонент системы, в котором возник сбой
  • в случае если инцидент находится в системах вне вертикали, инцидент передается в соответствующую вертикаль. При этом дежурный предпринимает необходимые действия (в т ч эскалации) для влияния на смежную вертикаль вплоть до устранения дефекта
• в случае если инцидент является P1/P2, дежурный самостоятельно выполняет устранение инцидента
  • если компетенций дежурного не хватает, осуществляется эскалация на руководителя/участника команды, в которой произошел инцидент
• в случае если инцидент является P3/P4, дежурный собирает диагностическую информацию и заводит дефект в Jira ответственной команды

Разбор пост-мортемов

В случае если произошел инцидент P1/P2, то на следующий рабочий день дежурный собирает всех вовлеченных в возникновение инцидента участников для выработки AI, предотвращающих повторное возникновение инцидента в будущем.

Распространение знаний

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

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

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

Ритуалы

Процесс дежурств внедряет следующие ритуалы

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

Ответственным за проведение ритуалов является Владелец процесса.