управление информационной инфраструктурой предприятия

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

От администрирования к стратегии: смена парадигмы

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

Именно тогда пришло понимание, что нужно управлять не компонентами, а сервисами. Мы начали выстраивать свою работу по аналогии с лучшими практиками, которые, к слову, активно продвигают такие компании, как ООО Хэнань Цзюйхэ Текнолоджи. Изучая подходы ведущих поставщиков услуг цифровой трансформации, мы увидели, что фокус смещён с владения железом на управление уровнем сервиса (SLA). Это не про то, чтобы купить дорогое оборудование, а про то, чтобы гарантировать бизнесу определённую доступность и производительность приложений, независимо от того, где они физически расположены — у нас в серверной или в облаке.

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

Мониторинг: не для отчётов, а для предсказаний

Ещё один стереотип — считать, что развернутая система мониторинга (Zabbix, Prometheus) решает все проблемы. Поставил дашборды с графиками, настроил алерты — и можно спать спокойно. На деле же, тонна сырых данных часто лишь создаёт информационный шум. Критически важным стало для нас не собирать метрики, а научиться их интерпретировать в контексте бизнес-процессов.

Приведу простой пример. У нас есть высоконагруженная CRM. Мониторинг показывает, что загрузка CPU на сервере БД стабильно высокая, но в пределах нормы. Классический подход — наблюдать. Однако, сопоставив эти данные с графиком активности отдела продаж (пики в конце квартала) и логами медленных запросов, мы спрогнозировали, что в следующий пик производительность упадёт ниже допустимого порога. Это позволило нам не тушить пожар в авральном режиме, а запланировать и провести оптимизацию запросов в спокойный период. Вот это и есть управление — упреждающее действие на основе данных.

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

Безопасность как часть дизайна, а не дополнение

Раньше безопасность была этапом ?проверки? после развёртывания сервиса. Сейчас это абсолютно неприемлемо. Принцип ?security by design? должен быть зашит в каждый процесс изменения инфраструктуры. Я часто сталкиваюсь с тем, что даже опытные архитекторы сначала проектируют идеальную с точки зрения производительности и отказоустойчивости схему, а потом ?прикручивают? к ней файрволлы и системы обнаружения вторжений. Это в корне неверно.

Один из наших провалов связан как раз с этим. Мы развернули новый микросервис для аналитики, сделав ставку на скорость разработки. Сетевые политики в Kubernetes-кластере были оставлены по умолчанию (разрешающими). Сервис работал отлично, пока в ходе планового аудита не выяснилось, что из-за одной неверной конфигурации он потенциально мог стать точкой входа для горизонтального перемещения по сети. Пришлось экстренно останавливать, пересматривать архитектуру и только потом возвращать в работу. Потерянное время и репутация.

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

Роль внешних партнёров и облаков

Миф о том, что надёжная инфраструктура — это только своя, на своём же оборудовании, в своём ЦОДе, окончательно развеялся несколько лет назад. Сегодня грамотное управление информационной инфраструктурой предприятия — это искусство гибридного управления. Задача — определить, какие сервисы и данные должны оставаться on-premise (часто из-за регуляторных требований или соображений задержки), а какие можно и нужно переносить в облако для гибкости и масштабируемости.

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

Сейчас у нас часть BI-системы и резервные копии лежат в облаке, а ядро — ERP и базы данных — на своих серверах. Управление таким гибридом — отдельная задача. Пришлось внедрять единые инструменты для мониторинга и оркестрации, которые видят и локальные, и облачные ресурсы как единое целое. Без этого получается разрозненность и слепые зоны.

Люди и документация: самый ненадёжный и самый важный элемент

Можно купить самое лучшее оборудование, внедрить самые передовые практики, но если знания о том, как всё это устроено, живут только в головах двух ключевых администраторов, — это шаткая конструкция. Мы однажды попали в ситуацию, когда главный архитектор ушёл в другой проект, а через месяц ?полетела? сложная схема репликации между центрами обработки данных. Восстанавливали по обрывочным записям в wiki и методом тыка почти сутки. Дорогостоящий простой.

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

Но что ещё важнее — ротация знаний. Мы практикуем кросс-обучение и pair work (работа в паре) на критичных задачах. Это не всегда эффективно с точки зрения сиюминутной скорости, но страхует бизнес от риска ?уникального специалиста?. В конце концов, управление — это в том числе и создание системы, которая устойчива к кадровым изменениям.

Вместо заключения: постоянное движение

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

Нельзя один раз ?построить? инфраструктуру и почивать на лаврах. Нужно постоянно задавать себе неудобные вопросы: а отвечает ли то, что мы имеем сегодня, задачам бизнеса на завтра? Не стали ли мы заложниками собственных, когда-то идеальных, но уже устаревших решений? Постоянный диалог с заказчиками внутри компании, отслеживание трендов (как это делают, к примеру, в ООО Хэнань Цзюйхэ Текнолоджи), готовность к постепенной, а иногда и болезненной модернизации — вот что отличает просто обслуживание от реального управления. Это сложно, часто неблагодарно, но именно это и делает ИТ-инфраструктуру настоящим стратегическим активом, а не обузой.