Чек-листы

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

Ревизия алертов

Периодичность: ежемесячно. Исходные данные: журнал срабатываний за период с отметками о действиях (см. измерение шума).

• У каждого правила, которое вызывает дежурного, есть команда-владелец.
• У каждого такого правила есть ссылка на инструкцию с первыми шагами диагностики, и ссылка открывается.
• Доля срабатываний, приведших к действию, выше 50% для каждого правила вызова. Правила ниже порога переведены в задачи, перенастроены или удалены.
• Нет правил, которые не срабатывали ни разу за последние полгода и при этом дублируют другое правило.
• Вызов дежурного выполняется по симптомам, видимым пользователю. Алерты по причинам (процессор, память, очереди) направлены в задачи или на дашборд.
• Для правил вызова задан параметр for или используется оценка скорости расходования бюджета ошибок.
• Алерты-следствия подавляются при активном алерте-причине.
• Интервал повторного уведомления не короче часа.
• Уровень важности определяет маршрут доставки: вызов, задача или только дашборд.
• Число вызовов дежурного вне рабочего времени за период известно и сравнено с предыдущим периодом.

Ревизия логов

Периодичность: ежеквартально. Исходные данные: статистика объёма логов по сервисам и по шаблонам сообщений.

• Известен объём логов на один обработанный запрос для каждого сервиса, и он не вырос без причины с прошлой ревизии.
• Десять самых частых шаблонов сообщений просмотрены; для каждого понятно, зачем он нужен.
• Ни одно сообщение с уровнем ERROR не описывает ожидаемую ситуацию (см. что не является ошибкой).
• Уровень DEBUG выключен во всех сервисах рабочего окружения, либо известно, кто и до какого срока его включил.
• Все сервисы пишут структурированные логи с согласованными именами полей.
• Идентификатор трассировки или запроса присутствует во всех записях, связанных с обработкой запроса.
• В логах нет паролей, токенов, номеров карт и других чувствительных данных; маскирование встроено в форматтер.
• Для повторяющихся сообщений настроено ограничение частоты.
• Для каждого потока логов задан срок хранения; аудит хранится отдельно и не семплируется.

Аудит CI

Периодичность: ежемесячно. Исходные данные: история запусков основной ветки и запросов на слияние за период.

• Известна доля сборок, которые упали и прошли при перезапуске без изменений кода. Она ниже 2%.
• Список нестабильных тестов построен по истории запусков: тесты с разным результатом на одном коммите.
• Каждый тест в карантине имеет владельца и срок; тесты с истёкшим сроком исправлены или удалены.
• Тесты из карантина продолжают запускаться в отдельном неблокирующем задании.
• Автоматические повторы настроены только для сбоев инфраструктуры, а не для упавших тестов.
• Быстрые проверки (форматирование, линтеры, модульные тесты) выполняются первыми и укладываются в пять минут.
• Медианное время полного конвейера известно и не выросло с прошлой ревизии без причины.
• Нет необязательных проверок, результат которых никто не смотрит.
• Версии инструментов проверки закреплены и обновляются отдельными изменениями.
• Уведомления о результатах сборки приходят только автору изменения и только при падении.

Ревизия уведомлений

Периодичность: ежеквартально, лично для каждого участника команды.

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