Когда ИТ-решения становятся бизнес-риском и как этого избежать

На одном реальном примере разберем, как отсутствие зафиксированной архитектуры создает бизнес-риск и как справляться с такими ситуациями.

В один не слишком прекрасный понедельник история началась с сообщения аккаунт-менеджера из разряда «все пропало»: разработка встала, сроки горят, а все вопросы — к инфраструктуре.

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

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

При этом члены команды были уверены, что инфраструктура размещена в одном облаке, хотя, согласно истории проекта, ее переносили в другую среду. Чтобы устранить это расхождение, пришлось проверять факты — разбираться, где реально находится VM и кто за нее отвечает. Поиск на сервере имен (nslookup) домена дал однозначный ответ: инфраструктура работает в том облачном контуре, куда ее переносили ранее.

С доступами ситуация оказалась не легче. Формально у инфраструктуры был владелец доступов — один из руководителей разработки. Но на практике информацию пришлось собирать вручную: понадобилось опросить несколько человек и поднять старые таблицы с перечнем прав. По счастливой случайности нашлась и база паролей к разным стендам и контурам — без нее двигаться дальше было бы просто невозможно.

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

На уровне виртуальной инфраструктуры все выглядело корректно — формально сеть работала. Значит, проблема была глубже, на уровне конкретной виртуальной машины. При попытке подключиться к ней выяснилось, паролей root никто не знал и зафиксированы они не были. Тем не менее внутрь попасть удалось — благодаря знанию привычек создателей. А там стало ясно, что сетевая связность отсутствует.

Таким образом, из-за отсутствия документации заурядный инцидент превратился в масштабное расследование.

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

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

«Бесхозные» виртуальные машины не удалили полностью — их лишь отключили и фактически отправили в корзину. Нам оставалось понять, какая из них обеспечивала сетевую связность.

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

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

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

Любая инфраструктура, как живой организм, постоянно меняется. Со временем в ней появляются «костыли», временные решения, ручные настройки. Если их нигде не фиксировать, в момент сбоя разобраться в происходящем будет намного сложнее.

Чтобы избежать подобных сценариев, важно несколько вещей.

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

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

В-третьих, требуется маркировка критичности. Важно заранее понимать, какие ресурсы допустимо отключать ради оптимизации или обслуживания, а какие напрямую влияют на работоспособность сервиса и релизный процесс.

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

Инфраструктуру можно сравнить пациентом. Если не знать, условно говоря, об аллергии человека на препарат, ему можно серьезно навредить. В инфраструктуре то же самое: закрытый порт, нетипичный маршрутизатор или сервис «на коленке» — и внезапно именно он оказывается критически важным.

Документация — как медицинская карта, которая позволяет быстрее и правильнее «лечить» систему. Люди меняются, интеграторы приходят и уходят, а инфраструктура остается.

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!