Пожалуйста, реализуйте этот простой SLO

[Dhwtj]

Реквестирую разъяснительную бригаду

[Dhwtj]

Это сатирический рассказ (перевод статьи с английского), описывающий «хоррор-стори» из жизни SRE-инженера (Site Reliability Engineering). В нем высмеиваются корпоративная абсурдность, некомпетентное управление и то, как, казалось бы, простая задача превращается в кошмар из-за постоянно меняющихся требований.

Вот подробный разбор того, что произошло в истории, по этапам:

1. Начало: «Простая задача»

Новичку дают задачу на 2 сторипоинта (то есть очень простую, на полдня): реализовать SLO (Service Level Objective — соглашение об уровне качества услуги) для доступности сервиса. Менеджер требует «четыре девятки» (99.99% доступности), считая это само собой разумеющимся и не давая никаких инструкций.

2. Первая пятница: Проблема с 4xx ошибками

Новичок делает SLO по учебнику (учитывая все коды ответов, кроме 200-ок, как ошибки). На демо менеджер недоволен: график показывает, что они исчерпали бюджет ошибок.

• Суть проблемы: В логах много кодов 4xx (ошибки клиента, например, 404 Not Found).

• Реакция менеджера: Он заявляет, что это не вина сервиса, а тупых пользователей, и заставляет исключить 4xx из расчетов.

• Урок: Определение «успешного запроса» всегда субъективно и зависит от бизнеса.

3. Вторник: Инцидент и «тишина»

Сервис лежит уже 4 часа, но аларма не было.

• Суть проблемы: Сервис упал так, что перестал отправлять какие-либо метрики («тишина»). Система мониторинга видела: запросов = 0, ошибок = 0. 0/0 = 0% ошибок (или отсутствие данных), поэтому тревога не сработала.

• Требование: Менеджер требует переключиться на метрики с балансировщика нагрузки (Load Balancer), так как он видит, что сервис недоступен, даже если сам сервис «молчит».

4. Четверг: Проблема с фронтендом

Всплывает новая проблема: фронтенд (веб-интерфейс) сломан и шлет неправильные данные, из-за чего бэкенд отдает ошибку 400 (Bad Request).

• Суть проблемы: Менеджер ранее запретил считать 4xx ошибками, но тут 4xx-ошибка возникает из-за бага их же фронтенда. Менеджер хочет, чтобы эти конкретные 4xx считались ошибками доступности.

• Техническая ловушка: Балансировщик, метрики с которого теперь используются, не умеет смотреть заголовки (чтобы отличить запросы от своего UI от запросов внешних клиентов).

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

5. Следующая пятница: «Инновация»

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

6. Финал (Понедельник): 102% и увольнение

Руководство видит отчет, где доступность скачет и показывает 102%.

• Техническая причина: Новичок пытался объяснить «race condition» (состояние гонки) при сборе метрик. Prometheus собирает (скрейпит) метрики не мгновенно и не идеально синхронно. Если числитель (общее кол-во запросов) обновился, а знаменатель (успешные) еще нет, или метрики взяты из разных источников в разное время, математика ломается, давая абсурдные проценты.

• Результат: Менеджер, который сам поставил невыполнимые и противоречивые условия, обвиняет новичка в некомпетентности за то, что задача на 2 балла затянулась на 2 недели. Новичка увольняют, забирая ноутбук.

Главная мысль

Рассказ демонстрирует Dunning-Kruger effect в менеджменте и теорию кривой обучения:

1. Менеджер не понимал сложность задачи («просто сделайте SLO»).

2. Постоянно менялись требования (скопируйте 4xx — нет, не копируйте — нет, копируйте только от UI).

3. Инструменты (метрики) использовались не по назначению без правильной настройки.

4. Вину за архитектурные проблемы и управленческий хаос свалили на исполнителя самого низшего звена.