Инженер уволился посреди релиза: про bus factor честно

Звонок пришёл в пятницу после обеда. Клиент — продуктовая компания, CI/CD только что встал в середине релизного окна — сообщил, что их штатный DevOps-инженер написал заявление об уходе два часа назад. Не через две недели, а сейчас. Пайплайн стоит, команда разработчиков не знает пароли от репозитория артефактов, а у кого ключи от продакшн-серверов — непонятно.

Это не редкость. В 2026 году дефицит DevOps-специалистов на российском рынке достиг точки, когда квалифицированного инженера переманивают быстро и на большие деньги. Bus factor единица — то есть один человек знает всё — стал системным риском, а не теоретической угрозой.

Почему bus factor = 1 — это архитектурная проблема

Bus factor — это количество людей, уход которых блокирует работу системы. Если цифра один, любое их исчезновение — отпуск, больничный, увольнение — останавливает производство.

Когда инфраструктура живёт в голове у одного человека, она существует в нескольких опасных формах одновременно. Пароли — в личном менеджере или «он помнил наизусть». Конфигурация серверов — настроена руками год назад, никто не воспроизводил. Пайплайн CI/CD — написан по наитию, без документации, «и так работает». Скрипты деплоя — в локальной папке на ноутбуке уволившегося.

Мы видели это многократно. Ещё в 2004-м писали, что штатный администратор, уходя, уносит с собой пароли, понимание сети и наработанные контакты. С тех пор масштаб вырос: теперь он уносит ещё и IaC-скрипты, Kubernetes-конфигурацию и секреты Vault, которые никто не ротировал.

Как взаимозаменяемость решает проблему

Когда мы берём проект на сопровождение, первое, что мы делаем — приводим инфраструктуру к воспроизводимому виду. Это не лозунг, это конкретные практики.

Вся инфраструктура описана кодом. Серверы, сети, окружения, балансировщики, правила файрвола — всё живёт в репозитории в виде Terraform-манифестов и Ansible-ролей. Развернуть новое окружение или восстановить существующее — это terraform apply и запуск плейбука, а не звонок инженеру с вопросом «а как ты там настраивал nginx три года назад?»

Секреты хранятся в Vault, доступы выданы по ролям. Ни у кого нет паролей «в голове» — всё управляется централизованно. Когда человек покидает проект, его доступы отзываются за минуты, а не обнаруживаются потерянными через полгода.

Каждая операция фиксируется. Изменения проходят через GitLab с описанием, инциденты документируются с разбором причин. Новый инженер открывает историю и видит не просто текущее состояние, но почему оно такое.

Результат — вход нового инженера в проект занимает минуты на доступы и часы на погружение, а не недели на «а как тут всё устроено». Репозиторий с кодом — это карта, которая не устаревает, потому что она же является источником правды о production.

Что происходит, когда инженер уходит — кейс

Возвращаясь к тому пятничному звонку: после него мы подключились к проекту на аварийной основе. Задача была понять, что вообще есть и в каком состоянии.

Картина оказалась классической для компании с bus factor 1. Инфраструктура настроена вручную, документация — один README с датой трёхлетней давности. Пайплайн CI/CD собран из кастомных скриптов, часть которых ссылается на переменные окружения, нигде не описанные. Доступы к облачному провайдеру — на личном аккаунте уволившегося инженера.

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

Если бы инфраструктура изначально была описана кодом, смена инженера прошла бы иначе: отозвать доступ, назначить другого, он смотрит репозиторий и продолжает работу. Не дни, а часы.

Дежурная смена закрывает и другие сценарии — отпуск, больничный, параллельный срочный проект. Когда за production отвечает команда, а не человек, один больничный не превращается в ночь без мониторинга. Мы эксплуатируем инфраструктуру в режиме 24/7 с реакцией от 15 минут — и это физически невозможно обеспечить в одно лицо.

Честный trade-off: дисциплина документирования стоит времени

Взаимозаменяемость не достаётся бесплатно. Чтобы она работала, нужна дисциплина документирования — и на неё уходит время, которое клиент не всегда видит.

Когда инженер делает изменение в инфраструктуре, он не просто применяет его — он фиксирует в коде, описывает в merge request, обновляет runbook если это нестандартная операция. Это занимает дополнительное время. Не огромное, но заметное на горизонте недели.

Клиент видит, что инженер «долго делал простую вещь». На самом деле он делал не только вещь, но и гарантию того, что следующий инженер сможет разобраться без часового звонка.

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

В SLA-договорах мы фиксируем обязательства по реакции и доступности — но за этими цифрами стоит именно эта дисциплина. Время реакции от 15 минут работает, только если инженер, принявший алерт, понимает систему. IaC и документация — это то, что делает такое понимание возможным для любого члена команды, а не только для того, кто «это писал».

Что остаётся у клиента при завершении сотрудничества

Отдельный вопрос, который нам задают: а что будет, если вы сами уйдёте?

Ответ прямой: вы остаётесь с воспроизводимым описанием контура в Terraform и Ansible, репозиторием в GitLab под вашим управлением, документацией по операциям и историей изменений. Не с «настройками в голове у инженера», а с кодом, который читается и воспроизводится.

Доступы, репозитории и ключи шифрования изначально остаются на вашей стороне — мы работаем в вашем контуре по выданным правам. Это принципиально: владение инфраструктурой не переходит к подрядчику.

Итог

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

Взаимозаменяемая команда, инфраструктура как код и дисциплина документирования — это ответ на этот риск. Не идеальный: дисциплина требует времени, а время стоит денег. Но это системный ответ, а не надежда на то, что ключевой человек не уйдёт.

Если хотите разобраться, как сейчас устроена ваша инфраструктура и где в ней bus factor — начните с обследования. Мы проводим его за 3–5 рабочих дней. Подробнее — на странице DevOps-аутсорсинга.