Самые опасные слова в ИТ: «мы ничего не меняли»
В 17:46 пятницы мониторинг краснеет. Очередь сообщений растет, уведомления не уходят, пользователи получают 500-ю ошибку, а в чате появляется фраза, после которой инженер молча тянется к кофе: «Мы ничего не меняли».
Через минуту выясняется, что разработчик утром поправил «буквально одну строку», администратор днем перевыпустил сертификат, аналитик уточнил обязательность поля, а пользователь, у которого все сломалось первым, просто зашел через VPN с нового ноутбука. То есть никто ничего не менял. Система, видимо, решила развиваться самостоятельно.
У каждого свой порог, после которого действие считается изменением.
Одна строка, которая ни на что не влияет
Разработчик действительно изменил одну строку: добавил проверку на null и заменил библиотечный метод на более современный. Pull request посмотрели одним глазом, тесты прошли, сборка зеленая.
Проблема в том, что строка жила в общем компоненте, который использовали несколько сервисов и старый модуль интеграции, написанный человеком, давно ушедшим и, вероятно, начавшим новую жизнь под другим именем.
Большие изменения хотя бы пугают. Для них готовят стенд и план отката. Маленькие выкатывают со словами «там нечему ломаться». В этот момент у маленького изменения появляется мотивация.
На аварийном созвоне звучит еще одна классика: «У меня локально работает». То есть локально другая база, тестовые данные и выключенная интеграция.
Код можно не трогать напрямую и все равно изменить его поведение. Достаточно поменять формат данных, таймаут, права доступа или версию зависимости.
Сервер никто не трогал
Администратор тоже ничего не менял. Он только обновил образ контейнера, поправил маршрут, перезапустил сервис и перевыпустил сертификат. Причем сертификат закончился сам, без согласования с командой.
Инфраструктура полна событий, для которых не нужен человек. Заполняется диск. Протухает токен. DNS помнит то, чего уже нет. Ночная cron-задача раз в месяц доказывает, что забытый код не становится безопаснее от того, что его редко вызывают.
Если команда восстанавливает картину по памяти, это не расследование, а корпоративный спиритический сеанс. Один помнит, что обновление было вчера. Второй уверен, что неделю назад. Третий не знал об обновлении, но подозревал неладное еще утром.
Здесь полезнее логи, история конфигураций и аудит. Человеческая память плохо версионируется и почти никогда не поддерживает diff.
Требования остались прежними
Менеджер не менял требования. Он лишь уточнил, что поле теперь обязательное, но только для части клиентов, кроме старых договоров и случаев, когда заявку создает интеграция. Старое поведение нужно сохранить, новое включить поэтапно, а интерфейс желательно не трогать.
В документе это два предложения. В архитектуре — новая ветка логики, миграция данных, доработка API и пересмотр тестов.
Слово «уточнение» работает как упаковка. Внутри может находиться полноценное изменение требований, но снаружи оно выглядит достаточно компактно, чтобы не пересматривать сроки.
Если меняется поведение системы, это изменение. Даже когда оно начинается со слов «там буквально один нюанс».
Пользователь просто работал
Пользователь тоже ничего не менял. Он открыл тот же файл, нажал ту же кнопку и получил ошибку.
Только файл перед этим переименовали, открыли в мобильном приложении, сохранили в новом формате и отправили через мессенджер. Затем пользователь подключился через VPN и повторил все под другой учетной записью.
Для него это не цепочка изменений. Это обычная работа.
Ничего не меняли. Изменилось все
К концу созвона выясняется, что каждый действительно не менял ничего важного. Просто одна небольшая правка встретилась с новым сертификатом, другими данными и старой конфигурацией. По отдельности все было допустимо. Вместе получилось происшествие.
В сложной системе изменение редко приходит с табличкой «это я все сломало». Оно проходит через соседний сервис, кеш, права доступа, внешний API или условие, которое три года считалось невозможным.
Поэтому зрелость команды определяется не способностью никогда ничего не ломать. Таких команд не существует. Важнее, насколько быстро она может понять, что изменилось, локализовать причину и безопасно вернуть систему в рабочее состояние.
Для этого нужны версионирование конфигураций, прозрачные релизы, аудит действий, мониторинг, воспроизводимые окружения и заранее подготовленный откат. А еще культура, в которой сообщение об изменении не считается признанием вины.
В «Потенциале» мы придерживаемся такого подхода. Не обещаем, что сложные системы никогда не удивляют — такое обещание само по себе звучало бы подозрительно. Но выстраиваем разработку и эксплуатацию так, чтобы после слов «мы ничего не меняли» начинался не поиск виноватого, а проверка фактов.
Потому что самые опасные слова в ИТ — не «у нас авария». Авария хотя бы честна. Опаснее услышать: «Мы ничего не меняли». Это значит, что изменения уже произошли. Просто никто не открыл diff.