Разбор: как доказать, что ваша автоматизация действительно работает

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

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

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

Вместо этого весь день на её ноутбуке работал локальный стенд. Тридцать шесть часов аптайма. Его лог зафиксировал ноль байт за весь рабочий день.

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

Производство проверяет, а не отлаживает

Вот правило, которое она вынесла из этого дня. Стоило оно дорого, поэтому теперь закреплено в письменном виде.

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

Локальный стенд отвечает на сотню дешёвых вопросов плохо и на один дорогой не отвечает вообще. Это правильное разделение.

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

Инструмент — то, что врёт

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

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

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

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

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

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

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

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

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

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

Если автоматизируешь что-то важное — задай себе три вопроса перед запуском. Что может соврать в моём измерении? Что останется незамеченным, если метрика сломается? Что докажет успех, если я не буду верить ничему своему? И только потом пиши код.