Как недокументированные ИТ-решения становятся угрозой для бизнеса

Алексей, вы считаете, что самые опасные инциденты в ИТ начинаются с фразы «мы ничего не меняли». Почему именно она должна настораживать бизнес?

Потому что эта фраза почти всегда означает одно: изменения действительно были, просто они нигде не зафиксированы. В сложных ИТ-системах отсутствие формальных изменений в таск-трекере или релиз-нотах вовсе не означает, что система осталась прежней. Инфраструктура живет своей жизнью:  масштабируется, оптимизируется, передается между командами. И если знания о том, как она устроена, существуют только в головах отдельных людей, бизнес фактически теряет управляемость над критически важными процессами.

В одном из ваших кейсов все началось с того, что перестали доходить коммиты до продуктивной среды. Почему такая, на первый взгляд, локальная проблема оказалась показательной?

Потому что она выглядела как мелкий технический сбой, а по факту вскрыла системную проблему. Разработчики увидели, что обновления из внутреннего Git больше не попадают ни в тестовый контур заказчика, ни в продакшен. При этом все уверяли, что никаких изменений в инфраструктуре не было. Симптомы указывали на сетевую проблему, но довольно быстро стало понятно, что дело не в одном конкретном компоненте, а в отсутствии целостного представления о системе.

С чего началось расследование?

С попытки понять базовую вещь — где именно физически и логически находится инфраструктура. И это уже тревожный момент: команда, которая проектировала решение, давно не работала в компании, а актуального описания архитектуры не существовало. Мы восстановили контакты с бывшими участниками проекта, получили ориентиры и начали проверять облачную среду, которую считали основной. Но оказалось, что нужной инфраструктуры там просто нет.

То есть реальная архитектура отличалась от той, что существовала «в головах»?

Именно, дальше пришлось буквально заниматься цифровой археологией: разбирать IP-адреса, маршруты, точки связности, выяснять, кому принадлежат те или иные контуры. В итоге стало понятно, что система развернута в другом облаке. Когда мы получили к нему доступ, перед нами оказалась масштабная инфраструктура из сотен виртуальных машин, часть из которых была выключена. Git-сервис формально отвечал, но цепочка доставки изменений где-то обрывалась, и без карты зависимостей понять, где именно, было невозможно.

В какой момент стало ясно, что проблема связана не с багом, а с управленческим решением?

Когда мы восстановили хронологию событий, накануне кто-то принял решение сократить затраты и отключил часть виртуальных машин. Это не было саботажем или ошибкой из-за некомпетентности. Человек действовал логично в рамках той информации, которой обладал. Проблема в том, что у него не было понимания, какие компоненты действительно критичны для работы системы, потому что это нигде не было зафиксировано.

Как в итоге удалось восстановить работоспособность?

Фактически методом перебора: мы начали последовательно включать виртуальные машины, наблюдая за поведением системы. В какой-то момент заработала доставка коммитов, и стало ясно, что ключевой компонент — это виртуальная машина с абсолютно неприметным названием, не отражающим ее реальную роль. Она оказалась ядром всей цепочки. Если бы в рамках оптимизации ее не просто выключили, а удалили, восстановление заняло бы значительно больше времени и уже с прямыми рисками остановки сервисов.

Почему такие истории особенно опасны именно с точки зрения бизнеса, а не ИТ?

Потому что бизнес видит последствия, но не видит причин. Сегодня это выглядит как задержка обновлений, завтра, как сорванный релиз, а послезавтра, как простой сервиса, финансовые потери и репутационные риски. При этом корень проблемы часто не в технологиях как таковых, а в отсутствии управляемости: непонятно, кто за что отвечает, что можно менять без последствий, а что трогать нельзя ни при каких обстоятельствах.

Многие руководители считают документацию избыточной бюрократией. Что показывает практика?

Практика показывает, что документация — это форма страхования. Она нужна не для отчетов и не для галочки. Она позволяет принимать управленческие решения без риска случайно отключить критический элемент системы. Когда инфраструктура растет, команды меняются, а решения передаются из проекта в эксплуатацию, именно зафиксированная архитектура и ответственность по компонентам позволяют бизнесу сохранять устойчивость.

Какой главный вывод вы бы сделали из этого кейса для руководителей?

Фраза «и так понятно» — один из самых опасных сигналов в ИТ. Если что-то действительно понятно, это должно быть зафиксировано. Документирование — не про формализм, а про контроль. И очень часто именно оно отделяет локальный технический инцидент от ситуации, когда «встает» уже не сервис, а бизнес целиком.