Наблюдаемость: как узнать о сбое раньше клиента

Есть простой вопрос, который переворачивает разговор о поддержке: «Как вы узнаёте, что что-то сломалось?» Если ответ — «звонят пользователи», значит наблюдаемости нет, и любой договор о сроках восстановления держится на удаче. Наблюдаемость — это способность ответить на вопрос «что сейчас происходит внутри системы», не заходя на сервер и не гадая. Продаётся она не как технология мониторинга, а как разница между «узнали за минуту» и «узнали в понедельник от клиента».

Три слоя, из которых складывается ответ

Метрики. Числа во времени: сколько запросов, сколько ошибок, сколько секунд занял ответ, сколько места осталось. Отвечают на вопрос «что-то не так?» — быстро и дёшево, но без подробностей.

Логи. Записи о том, что происходило. Отвечают на вопрос «что именно случилось?». Дороже в хранении и требуют дисциплины: если каждый пишет как хочет, разбирать нечего.

Трассировки. Путь одного запроса через все системы: зашёл на сайт, пошёл в базу, оттуда в платёжный сервис, вернулся. Отвечают на вопрос «где именно потерялось время?». Незаменимы, когда систем много и все кивают друг на друга.

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

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

Почему мониторинг и наблюдаемость — не одно и то же

Мониторинг проверяет заранее известные вещи: жив ли сервер, есть ли место на диске, отвечает ли сайт. Он ловит поломки, которые уже случались и о которых кто-то подумал заранее.

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

Отсюда простая формулировка для клиента: мониторинг отвечает на вопросы, которые вы задали заранее. Наблюдаемость позволяет задать вопрос, о котором вы не думали, — в момент, когда он понадобился.

Как об этом говорить с клиентом

Не «внедрим систему мониторинга», а «сократим время от поломки до её обнаружения». Это измеримо и понятно всем, включая финансового директора.

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

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

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

Где вендоры преувеличивают

«Автоматически находит причину». Инструмент показывает корреляции и подсвечивает аномалии. Причину устанавливает человек. Обещание автоматического разбора обесценивается на первом же нетривиальном сбое.

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

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

«ИИ предскажет сбой». Аномалии находит, тренды показывает. Предсказание конкретной аварии — маркетинг. Осторожная формулировка «раньше замечает отклонение» честна и всё равно ценна.

Что спросить у своего инженера перед встречей

1. Сколько данных в сутки будет генерировать инфраструктура клиента и во что это превращается в деньгах?
2. Что мы храним долго, а что удаляем через неделю — и как это объяснить?
3. Кто настраивает правила оповещений и сколько времени займёт доводка до приемлемого уровня шума?
4. Что мы даём из коробки для его стека, а что придётся дописывать?
5. Как выглядит работа дежурного после внедрения — что он видит первым делом?

Красные флаги на стороне клиента

• О сбоях узнают от пользователей. Это не только техническая проблема — это репутация, которая тратится каждый раз заново.
• Оповещения отключены или уходят в общий чат. Значит, шум победил, и новая система повторит судьбу старой, если не заняться правилами.
• Нет дежурства. Инструмент, который некому смотреть ночью, ночью бесполезен. Иногда честнее продать внешнее дежурство, чем панель.
• Разбор инцидентов ищет виноватого. В такой культуре люди прячут информацию, и никакая наблюдаемость не поможет: данные будут, а разговора не будет.

Вопросы, которые задаст технический директор

«Сколько это будет нагружать наши системы?» — сбор данных потребляет ресурсы. Нужны цифры, а не «незначительно».

«Что с чувствительными данными в логах?» — в логи регулярно утекают персональные данные и токены. Ответ должен включать маскирование, иначе разговор с безопасностью закончится плохо.

«Мы сможем это унести с собой?» — про открытые стандарты сбора данных. Готовность ответить «да, формат открытый» снимает страх привязки.

«Что произойдёт, если упадёт сама система наблюдения?» — вопрос, который отличает опытного собеседника. Хороший ответ есть не у всех поставщиков.