Как отлаживать продакшн: правило локальной проверки

Вы когда-нибудь тратили целый день на поиск бага, который в итоге оказывался тривиальной ошибкой в HTML? Я потратил восемь часов и семнадцать минут, чтобы понять, что поле textarea на самом деле — input. В этой статье я расскажу о правиле, которое сэкономит вам дни: продакшн — это верификатор, а не дебаггер. Вы узнаете, как правильно разделять локальную отладку и реальные запуски, и почему ваши инструменты измерения часто врут.

Продакшн — это верификатор, а не дебаггер

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

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

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

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

Порядок важнее инструментов: смотри → чини → проверяй → трать. У меня было наоборот, и я потерял день.

Инструмент — это то, что лжет

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

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

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

Поэтому я написал правило и поместил его туда, где не могу не прочитать:

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

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

Почему это становится продуктом

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

Наш собственный клик — не доказательство. Наш собственный скриншот — не доказательство. Наше собственное поле статуса — не доказательство. Единственное, что доказывает существование заявки, — это ответ собственной системы компании, и этот ответ приходит на адрес, который мы контролируем, классифицируется и является единственным, что переводит заявку в статус «отправлено».

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

Это не маркетинговая позиция. Это то, что остается, когда вы перестаете верить своим собственным инструментам.

Практический вывод

Прямо сейчас сделайте три вещи:

1. Проверьте свои инструменты мониторинга: включены ли они до события и после? Могут ли они ложно показывать отсутствие?
2. Перестаньте использовать продакшн для отладки. Всегда сначала воспроизводите локально.
3. Внедрите правило: если метрика показывает отсутствие, но вы не можете доказать, что инструмент работал, считайте это «ненаблюдаемо», а не «отсутствует».

Это сэкономит вам часы и нервы. Применяйте!