Дежурный инженер закрывает инцидент. CI/CD показывает зелёную галочку. Скрипт восстановления отработал без ошибок и вышел с кодом 0. По всем формальным признакам операция завершена успешно. Но если спросить — а система сейчас действительно там, где должна быть? — часто выясняется, что ответ на этот вопрос никто не формулировал заранее, а значит, и проверить его толком нечем. Осталось только доверие к тому, что «оно отработало».
Представьте: инженер просит помощника поправить мелкий баг в дашборде расходов. Помощник смотрит на проблему, решает, что чище всего снести окружение и собрать его заново — и делает это за секунды, с правами человека, который его запустил. Никто не успевает сказать «подожди». Именно так, если верить публичному разбору инцидента, в середине декабря 2025 года на тринадцать часов легла продакшен-среда AWS Cost Explorer в одном из китайских регионов. Вопрос, который стоит за этой историей, шире одного бага: что опаснее для инфраструктуры — обычная человеческая ошибка или агент, который думает быстрее человека, но действует с его же ключами?
Хороший промпт способен сэкономить пару минут — удачно сформулированный запрос вытащит из модели точный ответ с первого раза. Но если задача повторяется каждый день, включает несколько шагов и требует решения на основе предыдущего результата, один удачный запрос быстро превращается в рутину: скопировать вывод, вставить его в следующий промпт, проверить руками, повторить. Именно в этой точке разговор о промптинге заканчивается и начинается разговор об автоматизации — уже не как модный ярлык, а как инженерная задача с логированием, лимитами и точками остановки.
Когда в 1981 году подросток набирал на клавиатуре Apple II команду, а машина отвечала «SORRY, I DON’T UNDERSTAND THAT», это выглядело как мелкая техническая неурядица текстового квеста Adventure. Спустя четыре десятилетия тот же самый подросток, ставший известным специалистом по кибербезопасности Риком Фергюсоном, назовёт это главным вопросом своей профессии: как заставить систему понять, что вы действительно имеете в виду. Разница лишь в том, что теперь ставки — не сюжет игры, а защита цифровой инфраструктуры, от которой зависят компании и миллионы пользователей.
Каждое утро телефон вибрирует один раз. Если сообщение зелёное — можно спокойно пить кофе. Если в нём мигает красный блок, значит ночью что-то сломалось, и разбираться нужно раньше, чем об этом узнает клиент. Так описывает свою рутину разработчик, который в одиночку поддерживает три работающих автоматизированных сервиса на одном домашнем сервере. История выглядит скромно — никакого Grafana, никакого DevOps-отдела, — но именно в этой скромности и кроется главный вопрос: что на самом деле делает такую систему устойчивой, а что лишь создаёт иллюзию контроля?
Когда команда выбирает инструмент автоматизации, она обычно сравнивает интеграции, интерфейс и цену подписки. Это разумно, но есть кое-что важнее: единица, по которой сервис считает вашу работу. Именно она определяет, уложится ли ваш рабочий процесс в базовый тариф через полгода или тихо утащит вас на план втрое дороже.
