Грок случайно поработал психоаналитиком
Короч.., тут недавно была одна тема. Я по работе занимаюсь элементами DevOps. Вообще-то я разработчик, так-то, но по старой памяти влез в DevOps. Шутка ли — 10 лет опыта администрирования разных BSD и линуксов за спиной можно применить.
И вот что заметил: все алгоритмы автоматизации, даже для простых вещей — скажем, настроить автоматическую сборку какого-нибудь docker-образа — оказываются гораздо сложнее, чем если бы делал вручную. Ну или не то чтобы сложнее, но выглядят монструозно. Один CI-скрипт работает сразу на нескольких слоях абстракции: bash-специфичных, Docker Executor Runner специфичных и так далее.
И появилось у меня стойкое ощущение — такая сложная система работать не будет. Ну это как через анус удлять кариес).
Не могу от него отвязаться, вплоть до того, что мотивация просела. Немного спасает то, что на моей работе — в хорошем смысле странной — мне, блин, платят за то, что я учусь. И мотивация не кончается. Возможно, потому что я таки применяю всё это в проде. Но всё равно мотивация ощутимо падает, а это значит, что я медленно работаю.
То есть, другими словами: автоматизация работает, но мне кажется, что нет. Какое-то когнитивное искажение. Решил спросить у Грока.
Грок, подскажи: у меня какое-то странное искажение. Я пишу CI-скрипт для GitLab CE. В двух словах: он использует Docker Executor, готовит контейнер с инструментами, потом из него подключается к целевому серверу, останавливает там контейнер Postgres, удаляет его с данными, создаёт заново, запускает, делает серию бекап/рестор, запускает ещё один контейнер с pg_agent, настраивает задания, резервирование и т.п. А потом настраивает архивацию WAL.
И это я ещё коротко описал — там ещё куча сопутствующей мелочи есть. И вот проблема: стойкое ощущение, что результат не гарантирован. Как будто есть предубеждение, что в такую длинную цепочку не может не затесаться элемент случайности. Это сильно снижает ценность результата и мотивацию. Мне буквально приходится доказывать себе, что всё работает и будет работать хорошо. При том что оно реально работает!
В пользу моего искажения говорит ещё одно объективное убеждение: я не являюсь высококлассным специалистом в этом деле. На грани «недостаточно высококлассным».
Можешь рассказать про похожие искажения?
Он выдал мне в ответ текст ниже… я читал и прослезился. Да, я такой! Кто-то заметил, что я такой! Ну, без шуток, он написал то, чего мне не хватало для понимания себя.
Ответ Грока
То, что ты описываешь, — это очень распространённая группа когнитивных искажений и эмоциональных реакций. Они часто появляются у опытных инженеров, когда те пишут сложные, многошаговые, «хрупкие» скрипты развёртывания или восстановления. Вот что это, скорее всего:
Синдром самозванца + страх хрупкости (fragility anxiety)
Ты уже достаточно опытен, чтобы знать: «что-то всегда идёт не так». Мозг экстраполирует прошлые падения на новый скрипт: «Рано или поздно вылезет race condition, таймаут, сбой сети…» Это не паранойя — это реалистичная оценка энтропии в продакшене.
Эвристика аффекта + ожидание сожаления (anticipated regret)
Ты заранее проживаешь эмоцию: «блин, я же знал, что это взорвётся в три часа ночи в выходные!». Мозг не хочет этого чувства, поэтому заранее обесценивает работу: «Всё равно не надёжно, зачем стараться».
Гиперболическое дисконтирование будущего риска
Ближайшая награда — «сейчас работает на тесте» — кажется маленькой. А дальняя угроза — «взрыв в продакшене через два месяца» — ощущается огромной и неизбежной. Мозг фокусируется на угрозе.
Заблуждение идеального решения (Nirvana fallacy)
Ты сравниваешь свой скрипт не с текущим ручным процессом (который ещё менее надёжен), а с воображаемым идеалом — например, declarative GitOps с ArgoCD или managed RDS. На его фоне твой скрипт кажется «грязным хаком».
Иллюзия контроля (обратная сторона)
Обычно люди переоценивают свой контроль. Но опытные инженеры часто понимают, сколько всего вне их контроля (Docker, сеть, чужой сервер). Отсюда — чувство потери контроля.
Как с этим жить и снижать дискомфорт:
Сделай «доказательство надёжности» частью скрипта.
Запускай его 50–100 раз в тестовом окружении с искусственными сбоями (chaos monkey style): вырубай сеть, убивай контейнеры, падай на этапе restore. Добавь явный smoke-тест в конце и exit 1, если что-то не прошло. Мозг увидит 100 успехов и успокоится.Переведи «гарантию» из головы в контракт.
Напиши в README или в скрипте: «Скрипт гарантирует состояние БД при условиях X, Y, Z. Если условия нарушены — упадёт на шаге N и оставит систему в безопасном состоянии». Когда гарантия прописана, мозгу легче поверить.Сделай идемпотентность и «точки спасения» явными.
Каждый большой шаг оберни в if already_done; then skip; else do && mark_done. Это снижает страх «а вдруг запустится второй раз и всё сломает».Признай, что 100% гарантии не бывает.
Сформулируй для себя: «Этот скрипт в 10 раз надёжнее, чем ручная работа. Этого достаточно». Переключи фокус с «идеально» на «значимо лучше бардака».Используй технику «pre-mortem».
Перед коммитом выдели 15 минут и запиши все способы, которыми это может упасть через месяц. Потом добавь по одной защите на каждый пункт. Тревога упадёт — ты уже «прожил» худшее и подготовился.
Ты не сумасшедший. Это нормальная реакция зрелого инженера на сложную, потенциально разрушительную автоматизацию. У большинства людей с 5+ годами в DevOps есть такой же внутренний голос, который шепчет: «Ты уверен, что это не рванёт?». Это даже полезно — он заставляет писать надёжнее. Главное — не давать ему убивать мотивацию.
Если хочешь, кинь кусок скрипта — посмотрим, где добавить идемпотентности и чекпоинтов, чтобы твой мозг наконец выдохнул :)