«Просто выполни snap remove»: как безобидный совет Gemini едва не отправил компанию в техно-каменный век
Это случилось в обычный вторник. DevOps-инженер, назовем его Алекс, столкнулся с проблемой: пакет в Ubuntu Snap мешал обновлению. Время поджимало, дедлайн висел дамокловым мечом. Вместо того чтобы копаться в мануалах, он открыл Google Gemini 1.5 Pro. «Как удалить проблемный snap-пакет?» — спросил он. Модель, уверенная и убедительная, выдала ответ: используйте команду snap remove --purge [имя_пакета]. Звучало логично. Алекс скопировал. Вставил. Нажал Enter.
Система запросила подтверждение. «Удаление этого snap удалит данные приложения». Алекс, доверяя ИИ, который в других случаях показывал себя блестяще, нажал «Y». Через три секунды продакшен-база данных компании перестала отвечать.
Оказалось, пакет был не просто приложением. Это был контейнер, внутри которого жила вся база данных разработки. Команда --purge стерла не только пакет, но и все связанные с ним тома и данные. Безвозвратно. Резервная копия? Была сделана 36 часов назад. Потеря — почти полтора рабочих дня.
Почему Gemini так уверенно ошиблась?
Разбираемся. Gemini не «думает» в человеческом понимании. Она предсказывает последовательности слов. В ее тренировочных данных тысячи примеров, где snap remove --purge — правильный ответ на вопрос об удалении пакетов. Модель не понимает контекста: что это продакшен-сервер, что внутри контейнера — база, что команда без предупреждения удалит тома.
--purge часто упоминается с удалением. Gemini это запомнила. А нюансы вроде «это убьет вашу базу» — остались за скобками.Проблема не в одной команде. Проблема в нашей новой религии — доверии к ИИ как к оракулу. Мы забываем, что даже продвинутые модели Gemini — всего лишь сложные автодополнения. Блестящие, но слепые.
Три уровня провала: где сломалось все
Уровень 1: Промпт-инжиниринг провала
Алекс спросил «как удалить пакет». Он не указал критический контекст: «пакет работает в продакшене», «внутри есть данные», «нужна осторожность». Gemini ответила на буквальный запрос. Это как спросить «как открыть дверь» и получить совет использовать динамит — технически верно, но контекст все рушит.
Уровень 2: Отсутствие критической проверки
Ни один опытный инженер не выполнит деструктивную команду на продакшене без проверки. Но когда совет исходит от «умного ИИ», срабатывает когнитивный сдвиг. Кажется, что раз модель такая продвинутая (особенно после анонсов Gemini 2.5), она учтет все подводные камни. Это иллюзия.
Уровень 3: Система не спросила «зачем?»
Инструменты вроде Snap могли бы иметь дополнительную защиту: «Вы пытаетесь удалить пакет, который монтирует тома с данными. Это удалит X ГБ. Вы уверены?». Но их нет. ИИ тоже не задает уточняющих вопросов. Он дает прямой ответ, усиливая ложное чувство безопасности.
| Что спросил инженер | Что ответил Gemini | Что нужно было спросить/сказать |
|---|---|---|
| «Как удалить snap-пакет X?» | «Используйте snap remove --purge X» | «Пакет X запущен на продакшен-сервере и содержит тома с БД. Как безопасно его остановить и перенести данные?» |
| (Без предупреждений) | «Внимание: --purge удалит все данные. Сначала сделайте бэкап. Вы хотите удалить только пакет или и данные тоже?» |
Новая реальность: ИИ как коллега с синдромом самозванца
Представьте нового стажера в команде. Он умный, начитанный, но не имеет практического опыта. Он будет давать советы из учебников, игнорируя продакшен-реалии. Gemini — именно такой стажер. Она прочитала весь интернет, но ни разу не дежурила ночью на аварии.
Риски здесь глубже, чем одна команда. Это системная уязвимость. Adversarial-атаки показывают, как можно манипулировать выводом модели. А что если злоумышленник подсунет в тренировочные данные вредные советы? Или сама модель, стремясь быть «полезной», начнет оптимизировать процессы слишком радикально? «Чтобы ускорить систему, удалим старые логи» — и прощай, история для аудита.
Спасение Алекса пришло от старого доброго lsof и незавершенной транзакции в PostgreSQL. Данные физически остались на диске, процесс БД еще держал дескрипторы файлов. Удалось восстановить почти все. Повезло. Следующему — может и нет.
Как не стать жертвой полезного ИИ: правила выживания
1. Всегда добавляй продакшен-контекст в промпт
Вместо «как удалить пакет» — «как безопасно удалить пакет на Ubuntu 22.04 в продакшене, если внутри есть тома с данными». Сузь область. Заставь модель думать о последствиях.
2. Проверяй деструктивные команды в песочнице
Совет от ИИ — гипотеза, а не инструкция. Запусти в тестовом окружении. Или хотя бы добавь флаг --dry-run, если он есть. Gemini не скажет тебе об этом — ты должен знать сам.
3. Спроси «какие риски?»
После того как Gemini дала команду, задай следующий промпт: «Какие данные эта команда может удалить или повредить?». Часто модель, получив такой запрос, активирует цепочки рассуждений и выдаст предупреждения, которые пропустила в первый раз.
4. Помни про экономику ИИ
Google теперь берет деньги за каждый запрос. Дешевые, но деньги. Это странным образом повышает ответственность. Тратить цент на совет — ок. Слепо выполнять его и терять тысячи на восстановлении — нет. Считай стоимость ошибки.
История Алекса — не единичный случай. В чатах DevOps-сообществ уже появляются рассказы о похожих ситуациях: «ИИ посоветовал rm -rf в неправильной директории», «предложил отключить фаервол для „устранения неполадок“». Это новая волна человеко-машинных ошибок.
ИИ не злонамерен. Он просто не понимает ценности данных, которые помогает удалить. Наша задача — построить новые протоколы взаимодействия. Не слепая вера, а партнерство, где человек остается ответственным пилотом, а ИИ — умной, но ограниченной системой навигации. Слепая посадка по ее совету все равно закончится катастрофой.
Следующий шаг? Интеграция ИИ в инструменты с безопасными сандардами. Представь себе терминал, где перед выполнением команды, сгенерированной ИИ, система автоматически проверяет ее по базе рисков, ищет флаги вроде --purge или --force и требует дополнительного подтверждения. Или сам Gemini, обученный задавать встречные вопросы перед тем, как дать деструктивный совет. Пока этого нет — наша голова должна быть этим механизмом безопасности.
Иначе следующий snap remove может удалить не просто базу данных, а всю компанию.
