Когда критически важные системы уже импортозамещены, очередь доходит до базовой ИТ-инфраструктуры. Запрос бизнеса часто звучит просто: «Сделайте так же, как сейчас, только без западного ПО».
Но за этим «как сейчас» скрываются технические и организационные нюансы, которые превращают проект в полосу препятствий. О вызовах, с которыми сталкиваются компании, — и о том, как с ними эффективно справляться в материале IT World.
Кейс 1. Невидимая зона ответственности
Многие проблемы начинаются с заблуждения о том, что компоненты базовой ИТ-инфраструктуры — почта, системы защиты данных, управления доступом и мониторинга — это универсальные продукты, которые по умолчанию решают все задачи в своей области: от хранения до защиты.
На практике это далеко не всегда так. Например, почти все отечественные почтовые решения не используют полноценные базы данных для хранения писем. Некоторые вендоры пытаются исправить ситуацию, предлагая продукты на PostgreSQL или другим решением БД с подробной документацией. Другие же прямо заявляют: «Хранение — не наша зона ответственности, это инфраструктура». То есть от почтовой системы — только доставка и доступ, все остальное остается на стороне заказчика.
Понимание зон ответственности может прийти слишком поздно — уже после сбоя, в ходе разбора которого выяснится, что за него, по сути, никто не отвечает.
Даже если все нюансы прописаны в договоре или коммерческом предложении, бизнес может продолжить воспринимать систему как цельный продукт — когда эти пункты не были детально обсуждены и разъяснены на этапе согласования. В случае с внедрением почтовой системы понимание зон ответственности за хранение и отказоустойчивость может прийти слишком поздно — после потери писем из-за внезапного сбоя.
Описанные в документации технические требования к инфраструктуре тоже не всегда гарантируют отсутствие рисков. Например, указано, что нужно выделенное хранилище, но нет ни слова про отказоустойчивость, резервирование или тонкости настройки. В итоге компания выделяет одну виртуальную машину под проект с сотнями почтовых ящиков — и система оказывается нестабильной или вовсе не запускается.
Что делать
● С самого начала нужно четко разграничивать зоны ответственности. Один из рабочих инструментов — чек-листы с подробным описанием, кто и за что отвечает. Если речь о хранилище — будь то S3, SMB-шара или NFS — это должно быть явно зафиксировано. Заказчик либо берет инфраструктурную часть на себя, либо соглашается на расширенный объем работ. Это повлияет на стоимость проекта, но снимет риски и вопросы с бизнеса.
● К проектированию любой ИТ-системы нужно подходить комплексно. Не просто «поставим сервер и заведем ящики», а учитывая всю архитектуру: хранилище, антиспам, DLP-интеграции и множество тех «мелочей», которые обязательно всплывут в самый неудобный момент. И все это должно быть отражено в проектной документации.
Кейс 2. Неинтегрируемая экосистема
Иногда недопонимание возникает из-за того, что стороны по-разному читают один и тот же договор. А иногда — потому что ключевые детали просто не были озвучены.
Представим, что компания решила заменить зарубежную платформу виртуализации отечественной. Вендор уверяет, что все нужные компоненты предусмотрены и работают «из коробки». Проект стартует. Подключается интегратор, начинается внедрение.
Изначально все идет по плану: платформа виртуализации разворачивается без проблем, система управления функционирует. Но самое интересное начинается после.
Система резервного копирования видит виртуальные машины, создает копии и даже умеет их восстанавливать — но не взаимодействует с системой управления виртуализацией. И наоборот: система управления не «знает» о существовании восстановленных машин. То есть формально все работает — технически виртуальная машина есть, но она «пропадает» из общей логики управления: в интерфейсе ее не видно, управлять ей невозможно.
«Все работает» и «все работает как надо» — далеко не всегда одно и то же
Так получилось, потому что на этапе пресейла не проговорили один важный момент. Заказчик хотел не просто платформу виртуализации, а платформу виртуализации с системой управления, резервным копированием и единым интерфейсом.
На первый взгляд ситуация некритичная. Можно оперативно выпустить патчи, доработать архитектуру. Но на практике — это минус полгода, а то и больше. Ведь если проект реализуется в закрытом контуре, инженеру придется буквально жить на площадке: получать SMS-уведомления о патчах, выезжать с территории за ними, при ошибках — вручную выгружать и отправлять логи.
Такой инцидент вполне может закончиться расторжением контракта, поскольку у заказчика складывается ощущение, что его ввели в заблуждение: обещали готовое, интегрированное решение, а на практике нужный результат так и не был достигнут.
Что делать
● Пилот, тестовый стенд, имитация сбоя и восстановления — желательно проверить всю цепочку вживую. Заявленные поставщиком характеристики — отличный ориентир, но не всегда гарантия, что система будет работать, как надо, — в нужной логике, под конкретные задачи и сценарии. Такой тест требует времени, ресурсов и часто — отдельной договоренности с вендором. Но он того стоит.
● Чем раньше к проекту будет привлечена техническая экспертиза, тем выше шансы избежать сюрпризов. Особенно, если подробно зафиксировать не только функциональные требования, но и ожидаемое поведение системы в реальных условиях. Если же интегратор подключается после утверждения архитектуры, его возможности в части изменения основных компонентов и других параметров могут быть ограничены.
● Чтобы избежать разночтений, важно согласовать все детали. То, что для заказчика — “сквозное управление и единый интерфейс”, для вендора может оказаться просто набором условно совместимых компонентов. Поэтому на старте проекта стоит зафиксировать, какие именно сценарии работы и уровень связки между системами ожидаются. Иначе, если стороны по-разному интерпретируют требования, возникнет недопонимание, способное запустить целую цепочку проблем.
Кейс 3. «Неуловимые» фичи
Когда подходящее решение выбрано, зоны ответственности разграничены, а функции прописаны, не стоит забывать еще об одном критическом моменте: в динамичной ИТ-среде условия могут меняться по объективным причинам — технологии развиваются, продукты адаптируются к регуляторным и рыночным требованиям. Это нужно учитывать.
Представьте: заказчик выбирает систему хранения данных под конкретные требования, и вендор предлагает решение, полностью соответствующее им. Однако процесс согласования затягивается на полгода — за это время меняется политика лицензирования, обновляется архитектура, спецификация, и некоторые функции, ранее заявленные как встроенные, становятся платными.
В итоге — даже при поставке оборудования по старым условиям — на стадии Pre-Migration Inspection (PMI), спустя несколько месяцев после старта проекта, ситуация снова меняется. Вместо ожидаемой версии ПО выходит другая — с обновленными условиями. Ключевые для заказчика функции (например, дедупликация, снапшоты и т. п.) больше не входят в базовую поставку: за них теперь нужно доплачивать. Более того, повысились требования к аппаратным ресурсам, а значит, чтобы система заработала, компании придется еще и расширить объем оперативной памяти.
Что делать
● Если критически важная функция заявлена, но не закреплена в техническом задании — не стоит подписывать договор, пока это не будет сделано. Перед заключением контракта также необходимо перепроверить, не изменилась ли политика лицензирования и остались ли нужные функции.
● Нужно быть в постоянном контакте с вендором, отслеживать технический и продуктовый роадмап: какие изменения в лицензировании и функциональности запланированы, как они могут повлиять на проект.
7 шагов, которые помогут сделать импортозамещение управляемым
Большинство проблем при реализации ИТ-проектов начинается не с технологий, а именно с разрыва ожиданий. На словах стороны договариваются, но в одни и те же термины вкладывают разный смысл, что неминуемо приводит к ошибкам и затяжным доработкам.
Как минимизировать риски:
- Тестируйте систему в реальных условиях. Пилот, тестовый стенд, имитация сбоя и восстановления — проверьте всю цепочку. Обещания поставщика — это ориентир, но не гарантия, что система будет работать именно так, как нужно.
- Привлекайте технических экспертов на этапе пресейла. После утверждения архитектуры интегратор уже не сможет повлиять на ключевые решения.
- Фиксируйте не только функциональность, но и сценарии эксплуатации. Как система должна вести себя в боевых условиях — это не менее важно, чем список технических характеристик.
- Четко разграничивайте зоны ответственности с самого старта. Кто отвечает за хранилище, отказоустойчивость, доступность сервисов — все должно быть зафиксировано.
- Проектируйте ИТ-систему комплексно. Даже простая почта — это не просто «ящик», а хранилища, антиспам, DLP, резервирование и другие компоненты. Без целостного подхода риски растут.
- Не подписывайте договор, пока не проверены ключевые функции. Есть сомнения — запросите демонстрацию системы и зафиксируйте все обязательства в техническом задании.
- Следите за роадмапом поставщика. Продукты развиваются: лицензии меняются, функции уходят, архитектура обновляется. То, что было доступно вчера, может стать платным или вовсе исчезнуть к моменту внедрения.