Управление мультиплатформенной инфраструктурой

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

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

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

Программа

Инфраструктурный «зоопарк»: где начинается зависимость

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

Почему компании мигрируют и как не сломать бизнес

Как меняется проект миграции, если компании нужно перейти в аттестованный контур или использовать сертифицированное ПО?
Когда требование регулятора может стать поводом не только перенести инфраструктуру, но и пересмотреть её архитектуру?
Когда компании действительно пора разгружать собственный ЦОД и переносить часть нагрузок в облако?
Что нельзя просто «взять и перенести» из собственного ЦОДа в облако?
Когда экономия от смены облачного провайдера действительно окупает стоимость и риск миграции?
Что чаще всего удерживает заказчика у текущего провайдера, даже когда экономика уже не устраивает?
Что вы должны сделать, чтобы клиент через три года не оказался в таком же vendor lock — только уже у вас?
Чем реальная катастрофоустойчивость отличается от резервной площадки, которая существует только на схеме?
Кто должен определять RTO и RPO - ИТ или бизнес?
Можно ли использовать мультиплатформенность как инструмент DR: основной контур у одного провайдера, резервный у другого?
Как поддерживать резервную среду в актуальном состоянии и сколько времени должно занимать реальное переключение?
Как часто нужно реально переключаться на резервную площадку, чтобы быть уверенным, что DR работает?

Мультиплатформа через 3–5 лет: норма или возврат к одному стеку?

Через три-пять лет мультиплатформенная инфраструктура останется нормой или компании снова потянутся к крупным вертикальным экосистемам «один вендор - один стек»?
Что сегодня сильнее всего создаёт vendor lock?
Если компания сегодня понимает, что уже живёт в мультиплатформенном «зоопарке», какие три действия ей нужно сделать в первую очередь?