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

Самые опасные инциденты в ИТ начинаются с фразы «мы ничего не меняли»: почему именно она должна настораживать бизнес?

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

Когда локальная проблема оказывается показательной?

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

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

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

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

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

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

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

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

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

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

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

Что показывает практика?

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

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

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