Перезагрузка наблюдаемости для небольшой компании, которая убирает лишнее

Почему у маленьких команд появляется слишком много шума

Маленькие команды не ставят себе цель собрать шумный стек мониторинга. Обычно это происходит после нескольких стрессовых инцидентов. Что-то ломается, люди добавляют больше алертов, дольше хранят логи и делают еще один дашборд. В моменте это кажется безопасным, но стопка продолжает расти.

После одного болезненного сбоя никто не хочет удалять алерт, который может помочь в следующий раз. Поэтому алерты накапливаются. Остается предупреждение о высокой загрузке CPU. В другом инструменте появляется еще одно предупреждение о той же проблеме. Потом кто-то добавляет третью проверку, на всякий случай.

Через несколько месяцев команда получает уведомления о проблемах, которые исчезают сами, прежде чем кто-то успевает среагировать. Так начинается усталость от алертов. Люди отключают уведомления, игнорируют дашборды или думают, что очередной пинг — это снова ложная тревога.

С данными происходит то же самое. Логи хранятся дольше, потому что сначала хранилище кажется дешевым. Лишние метрики остаются включенными, потому что выключать их страшно. Трейсы собираются слишком широко, потому что у команды нет времени их настраивать. В итоге компания платит за хранение огромного объема данных, которые никто не открывает после первых дней.

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

Обычно такая схема приводит к одни и тем же проблемам:

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

Именно последняя часть важнее всего. Шум не просто раздражает. Он меняет то, как люди работают. Инженеры перестают смотреть на графики в обычной работе, потому что слишком многие графики говорят слишком много всего. Во время инцидента они тратят время на сортировку дублей вместо того, чтобы найти первый понятный сигнал.

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

Как выглядит хорошее покрытие на самом деле

Хороший мониторинг начинается с боли пользователей, а не с каждой цифры, которую умеют собирать ваши инструменты. Если люди не могут войти в систему, оплатить покупку, загрузить страницу или завершить главное действие, команда должна узнать об этом быстро. Это важнее, чем дашборд, полный графиков, которые никто не проверяет.

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

Этого достаточно для многих команд. Чем больше данных, тем чаще никто не выбрал, что действительно важно.

У каждого сервиса также должен быть небольшой экран состояния. На практике обычно хватает нескольких показателей: процент успешных запросов, задержка, всплески ошибок, очередь задач и один бизнес-сигнал, например завершенные заказы или отправленные формы. Если график не помогает дежурному инженеру решить, что делать дальше, ему не место на первой странице.

Простой пример делает это понятнее. Представьте SaaS-продукт с логином, оплатой и ночной задачей импорта. Хорошее покрытие показывает команде, если резко растут ошибки входа, платежные запросы начинают зависать или очередь импорта перестает двигаться. Оно не собирает бесконечные debug-логи со всех контейнеров весь день только потому, что инструмент это позволяет.

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

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

С чего начать: с вопросов, которые уже задает команда

Возьмите последний реальный инцидент как карту. Команде сначала не нужны новые графики. Ей нужна четкая память о том, что пошло не так, что люди проверяли и что на самом деле помогло исправить проблему.

Начните перезагрузку с одного недавнего сбоя, замедления или странного бага. Соберите команду в одной комнате и разберите событие простыми словами. Без теории. Поговорите о том, когда в последний раз пользователи реально почувствовали боль.

Спросите, что именно сломалось. Будьте точны. Фраза «сайт тормозил» слишком расплывчата, чтобы по ней что-то выстраивать. «Запросы к оформлению заказа начали зависать после деплоя» или «фоновые задачи перестали отправлять счета» — уже то, что можно измерить. Как только проблема становится конкретной, слабые сигналы быстро выходят на первый план.

Потом спросите, кто заметил это первым. Этот вопрос быстро показывает слепые зоны. Если об этом сообщила поддержка из-за злых писем, ваш мониторинг пропустил проблему, которую почувствовали клиенты. Если инженер заметил всплеск ошибок или проваленную health check, этот сигнал заслужил свое место.

Следом идет влияние на клиентов. Многие команды могут назвать CPU, память и количество контейнеров, но не могут сказать, сколько пользователей оказалось заблокировано. Это неправильный порядок. Вам нужен быстрый способ отвечать на простые вопросы: сколько логинов не сработало, сколько заказов остановилось, сколько задач застряло и как долго длилась проблема.

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

Все остальное должно доказывать свою полезность. Если во время инцидента никто не открыл дашборд, алерт или поток логов, он может выглядеть занятым, но не приносить пользы.

Пятиминутный разбор часто дает больше, чем неделя споров о дашбордах. Возможно, релиз замедлил логин на 18 минут, поддержка заметила это первой, а команда исправила проблему, посмотрев на таймлайн деплоя и один график базы данных. Это учит гораздо большему, чем стена из метрик по хостам.

Если сигнал не помогает понять, что сломалось, кто это заметил, как это ударило по клиентам или что помогло все исправить, он, скорее всего, больше увеличивает счет, чем помогает команде.

Как провести перезагрузку за одну неделю

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

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

Потом разметьте каждый пункт простыми ярлыками. Полезный — помог обнаружить, объяснить или исправить реальную проблему. Дубликат — это еще один алерт или дашборд, который рассказывает то же самое. Неиспользуемый — это то, что никто не открывает, не доверяет или не понимает, зачем оно существует.

Будьте строги. Дашборд, который красиво выглядит, но никогда не меняет решение, — неиспользуемый. Три алерта, которые срабатывают во время одного и того же деплоя, — это дубликаты, даже если каждый приходит из разного инструмента.

Прежде чем удалять старые логи или трейсы, сократите срок хранения. Так проверка будет безопаснее. Если debug-логи хранятся 30 дней, сократите их до 7 или 14 и посмотрите, как это повлияет на поддержку, реакцию на инциденты и требования комплаенса за один релизный цикл. Большинство команд понимают, что им нужно короткое окно для глубокой детализации и более длинное окно только для сводных метрик.

Дальше объедините пересекающиеся алерты в одно правило, которое сонный инженер поймет в 3 часа ночи. «Оформление заказа не работает больше 5 минут» лучше, чем набор из алертов по CPU, памяти, перезапускам и таймаутам, которые срабатывают одновременно. Именно здесь усталость от алертов обычно снижается особенно быстро.

Последний день используйте, чтобы сократить дашборды. Оставьте небольшой набор: один экран состояния сервиса, один экран релизов и одно место для просмотра ошибок. Если у графика нет владельца или действия, с которым он связан, удалите его.

После следующего релиза посмотрите, что команда пропустила и чего никто не заметил. Эта проверка важнее, чем споры на встрече. Если после реального релиза никто не попросил вернуть удаленный сигнал, значит, вы, скорее всего, сделали правильный выбор.

Простой пример небольшой продуктовой команды

Представьте команду из пяти человек с веб-приложением, оплатой, API и несколькими фоновыми задачами. Со временем их стек наблюдаемости оброс шумом. Появилось много дашбордов, много алертов и debug-логи почти на каждый запрос. Счет рос, но ответы не приходили быстрее.

Их перезагрузка начинается с четырех сигналов, которыми они действительно пользуются. Они следят за ошибками приложения, потому что сломанные экраны быстро подрывают доверие. Они смотрят на сбои оплаты, потому что потерянные платежи важнее почти всего остального. Они измеряют задержку API, потому что медленные запросы часто появляются раньше больших сбоев. И они наблюдают за нагрузкой базы данных, потому что она часто объясняет, почему все приложение ощущается медленным.

Потом они убирают то, что никто не читает. Команда перестает хранить debug-логи для каждого запроса. Эти логи помогали в нескольких глубоких расследованиях, но в обычные дни создавали огромный объем данных и почти никакой пользы. Вместо этого они оставляют структурированные логи ошибок, небольшой выбор логов запросов и достаточно контекста, чтобы связать проблему клиента с конкретным событием, когда она появляется.

Они также сокращают алерты. До перезагрузки почти у каждой метрики был порог, и кто-то получал уведомление даже о безобидных всплесках. Это создавало усталость от алертов, и люди начинали игнорировать уведомления. После уборки они оставляют один алерт на клиентские сбои и один — на зависшие фоновые задачи. Если растут ошибки оплаты или очередь задач перестает двигаться, кто-то реагирует. Если CPU подскакивает на две минуты и ничего не ломается, никого не выдергивают из работы.

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

Обычно этого достаточно. Команда тратит меньше на расходы по наблюдаемости, быстрее находит реальные проблемы и держит внимание на тех частях, которые клиенты замечают первыми.

Где обычно растет счет

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

Чаще всего первый скачок вызывают метрики. Команда добавляет такие теги, как user ID, маршрут, регион, тариф, номер сборки и тип устройства, потому что каждый из них кажется полезным. Но вместе они превращают одну метрику в тысячи временных рядов. Большинство из них не отвечают ни на один реальный вопрос, но вы все равно платите за хранение и запросы к ним.

Следующая утечка — логи. Команды держат их 30, 90 или 365 дней, потому что удалять данные кажется опасным. Потом никто не читает ничего старше прошлой недели, если только юридическая, аудиторская или безопасностная причина не вынуждает это сделать. Если у продукта стабильный поток трафика, старые логи накапливаются очень быстро.

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

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

Пересечение инструментов тоже съедает деньги. Один сервис хранит логи, другой — метрики, третий собирает трейсы, а четвертый обещает понимание инцидентов, читая те же самые события. Команда платит нескольким вендорам, чтобы ответить на один базовый вопрос: что сломалось, когда это началось и кто заметил первым?

Небольшая SaaS-команда может использовать один инструмент для графиков инфраструктуры, один для логов приложения, один для APM и один для алертов. После перезагрузки наблюдаемости они часто видят, что два из них рассказывают одну и ту же историю разными графиками. Удалить один дубликат обычно больно гораздо меньше, чем люди ожидают.

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

Ошибки, из-за которых перезагрузка проваливается

Большинство неудачных перезагрузок проваливаются не из-за инструмента. Они проваливаются потому, что команда меняет дашборды и правила алертов, но не меняет то, как люди работают во время инцидентов.

Одна частая ошибка — убрать алерты, не спросив тех, кто отвечает на них в 2 часа ночи или во время релиза. Менеджер может увидеть 40 шумных алертов и удалить половину за один проход. Дежурный инженер часто знает, что только три из них были шумом, а два тихих на вид алерта были ранним сигналом сломанной формы регистрации или зависшей платежной задачи.

Другая ошибка — слишком рано удалять данные. Команды часто сокращают срок хранения логов или ужесточают пороги раньше, чем проверят, помогает ли новая схема в реальной проблеме. Это быстро экономит деньги, но может оставить вас вслепую. Если сократить логи с 30 дней до 3, а платежный баг вернется после еженедельного пакетного запуска, вы потеряете нужный след.

Более безопасный подход — оставить короткий период пересечения. Запустите новые пороги на неделю-две, сравните инциденты, а потом удалите старые данные и правила, которые никому не понадобились.

Сначала смотрите на клиента

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

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

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

Оставляйте сигнал только если команда может ответить на все четыре вопроса:

• Кто смотрит на него, когда что-то ломается?
• Какое действие он запускает?
• Какого пользователя или бизнес-шаг он защищает?
• Замедлит ли его потеря диагностику в реальном инциденте?

Если никто не может ответить на эти вопросы, уберите его пока. Перезагрузка наблюдаемости работает, когда команда сохраняет сигналы, которые меняют решения, и убирает все остальное.

Короткая проверка перед тем, как добавлять что-то новое

Большинство стеков растет по одному срочному запросу за раз. Новый алерт появляется после сбоя. Новый дашборд — после жалобы клиента. Через шесть месяцев никто уже не помнит, какие сигналы все еще помогают, а какие просто лежат и увеличивают счет.

Хорошая перезагрузка требует одного простого правила: не добавляйте метрику, поток логов или трейсы, если никто не может сказать, какое решение они помогут принять. Если сигнал не меняет действия команды, это шум, просто упакованный в осторожность.

Перед тем как что-то новое попадет в стек, прогоняйте короткий фильтр:

1. Спросите, какое действие должен запускать сигнал. «CPU высокий» — слабый ответ. «Задержка очереди выше 2 секунд, значит, мы масштабируем воркеры или смотрим на медленную задачу» — уже понятно.
2. Спросите, кто вообще будет на него смотреть. Если никто не проверяет его в еженедельном обзоре или во время инцидента, пока не храните это.
3. Спросите, не дает ли уже такой же ответ другой график. Многие команды платят дважды за одну и ту же историю: один раз в метриках и еще раз в логах.
4. Спросите, как долго команде на самом деле нужны данные. Debug-логи за обычную неделю редко требуют такого же хранения, как аудиторские события или записи по оплате.
5. Спросите, достаточно ли выборки. Хранение 10 процентов повторяющихся трейсов или логов часто показывает картину без сохранения каждого события.

Небольшие команды чаще всего теряют деньги на дублировании и привычке. Один дашборд показывает задержку API. Другой — ту же задержку по конечным точкам. Те же тайминги есть и в логах. И в трейcах тоже. Во время инцидента команда проверяет один или два из этих источников, а не все четыре.

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

Перезагрузка наблюдаемости — это не про то, чтобы убрать видимость. Это про то, чтобы оставить сигналы, которые помогают людям действовать, и убрать те, что только делают счет внушительнее.

Что делать после того, как стек стал легче

Легкая система остается легкой только если команда записывает несколько простых правил. Если эти правила живут только в голове одного инженера, шум быстро возвращается. Добавляются новые сервисы, старые дашборды остаются, и счет снова начинает расти.

Сделайте правила достаточно короткими, чтобы их мог соблюдать любой в команде:

• Каждый алерт должен описывать действие, которое должен сделать человек.
• У каждого дашборда должен быть один владелец и одна цель.
• У логов должен быть стандартный срок хранения, а более долгое хранение — только по понятной причине.
• Новые метрики должны отвечать на реальный вопрос, а не на «может, потом пригодится».
• Команда должна убирать неиспользуемые панели, алерты и запросы во время обычного обслуживания.

Держите эти правила на видном месте и пересматривайте их, когда выпускаете что-то крупное. Это важнее, чем длинная политика, которую никто не читает.

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

Для роста нужен небольшой запас. Маленькой компании стоит оставить место для нескольких дополнительных сигналов, когда она запускает новую функцию, меняет инфраструктуру или входит в более напряженный сезон. Но держите эти добавления на коротком поводке. Решите, когда вы их пересмотрите, и уберите, если после запуска они перестали помогать.

Здесь же внешний взгляд может сэкономить время. Свежий взгляд часто замечает пересечение инструментов, дублирующие алерты или срок хранения логов, который уже не имеет смысла. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как временный CTO и советник, и такой обзор архитектуры и инфраструктуры естественно вписывается в эту работу.

Лучшая облегченная система — не самая маленькая. Это та, которой команда все еще доверяет в плохой день.