Подходя к офису ты думаешь, что сейчас придешь, нальешь себе кофе, поболтаешь с коллегами, откроешь таск-трекер и спокойно начнешь рабочий день. Инженеры GitHub 27 апреля 2026 года тоже так думали… И начали. А через пару часов поиск по репозиториям, issues и PR-ам начал отваливаться — до 65% запросов уходили в таймауты. Но самое странное: все дашборды были зелёными. CPU — в норме, память — в норме, 200 OK — летят. А пользователи обрывают линию техподдержки. Потому что метрики меряют техническое здоровье, а не бизнес-результат.
Как так получилось?
GitHub — не слепая система: мониторинг зафиксировал деградацию поиска, поднял инцидент. Но метрики видели только следствие — перегрузку балансировщиков. Они не могли классифицировать природу этой нагрузки. А причина оказалась в распределённом скрейпинге: более 600 000 уникальных IP-адресов гнали анонимный поисковый трафик, обходя rate limits, и сжимали 30% дневного объёма в четырёхчасовое окно.
Балансировщики захлебнулись, время ответа выросло, и поиск перестал возвращать результаты. Дашборды были зелёными, потому что они измеряли техническое здоровье компонентов, но не различали тип нагрузки. А различать нужно: если это обычный рост — масштабируйся, если баг клиента — чини клиента, если скрейпинг — вводи конитроль для анонимного трафика. GitHub не сразу понял это, и инцидент длился больше шести часов.
Когда инженеры GitHub наконец поняли, с чем имеют дело, они развернулись в четырёх направлениях одновременно: разгружали балансировщики, масштабировали балансировочный слой, блокировали аномальный трафик и тюнили настройки балансировщиков. К 21:33 UTC основные последствия были устранены, и поиск начал возвращать результаты. Ещё чуть больше часа команда мониторила систему, и в 22:46 UTC инцидент был официально закрыт.
Но главное — выводы, которые GitHub сделал после инцидента. Они не ограничились «починили и забыли». Во-первых, масштабировали сам балансировочный слой и применили оптимизации для работы с соединениями, чтобы подобное насыщение не повторилось. Во-вторых, добавили новые мониторы и механизмы контроля, которые позволяют ограничивать анонимный трафик, защищая зарегистрированных пользователей. И в-третьих — пересмотрели саму логику мониторинга: теперь система должна не просто фиксировать «нам плохо», а различать тип нагрузки, чтобы скрейпинг больше не оставался незамеченным риском.
Именно здесь граница наблюдаемости: GitHub не был слеп, но система видела следствие, а не причину. И только когда причина стала ясна, применили правильные действия. Теперь система умнее — она не просто кричит «мне больно», а подсказывает, где именно болит и что с этим делать.
Наблюдаемость (observability) — это способность системы объяснить своё поведение в момент, когда она ведёт себя не так, как ожидалось.
Как заложить наблюдаемость в требования
На этапе проектирования нужно задать один главный вопрос: какое объяснение должно быть доступно команде через пять минут после начала деградации? Ответ на него раскладывается на пять конкретных вопросов:
Какая бизнес-операция страдает? Не сервис, не компонент, а операция: поиск, платёж, заказ, регистрация. Пользователь мыслит результатом, а не железками.
Как мы поймём, что операция деградирует? Ошибки, задержки, дубли, ложный success, устаревший результат.
С чем мы можем перепутать симптомы? В случае GitHub перегрузку балансировщиков перепутали с обычным ростом нагрузки, а не со скрейпингом.
Какие данные позволят различить причины? Если этих данных нет — вы не различите причины.
Какое действие должно следовать из понимания? Если после отклонения метрики непонятно, что делать — это не наблюдаемость, а сигнализация.
Таким образом, получаем следующую систему требований к разным аспектам наблюдаемости:
1. Требования к метрикам.
Каждая критичная бизнес-операция должна иметь сквозную метрику, проходящую через все слои системы.
2. Требования к логированию.
Каждый запрос к критичной операции должен оставлять структурированный лог с обязательными полями.
3. Требования к трейсингу.
Каждый запрос должен передавать идентификатор для отслеживания, позволяющий отследить бизнес-операцию от начала до завершения через все слои.
4. Требования к оповещениям.
Уведомления об отклонениях должны приходить с дифференцирующей информацией, а не просто «модуль сломался».
5. Требования к дашбордам.
Важно учесть, что дашборд лучше строить не по компонентам, а по бизнес-операциям.
6. Требование к действиям.
Для каждого различимого класса причин должен быть описан конкретный механизм вмешательства с проверяемыми шагами.
Бизнес не платит за дашборды и метрики. Бизнес платит за то, чтобы сервис работал, а инциденты заканчивались быстро. Инцидент с поиском на GitHub длился больше шести часов. Если бы у них были заложены требования различать трафик по источнику (authenticated vs anonymous), время диагностики сократилось бы с двух-трёх часов до 15–20 минут.
Для платформы с миллионами пользователей это прямые потери: упущенная выручка, отток пользователей, удар по репутации.
Конкретные требования —к метрикам, к логам, к дашбордам по бизнес-операциям, копопвещениям, к проверяемым runbook'ам — это не бюрократия. Они позволяют сократить MTTR (Mean Time To Resolve) с часов до минут.
Эта статья – конспект выпуска подкаста “Граница сложности”. Из аудиоверсии вы узнаете о том, как инженеры GitLab удалили базу в продакшене и что общего у метрики с Красной Шапочкой.
Послушать полный выпуск можно здесь: