У крупной компании сегодня редко бывает одна инфраструктурная среда. Это может быть собственный ЦОД, несколько облаков, российские платформы, унаследованные системы — и у каждой среды свои требования к эксплуатации и безопасности. Выбора стало больше, но управлять всем этим сложнее: растёт число ручных операций, усиливается зависимость от отдельных платформ и провайдеров, увеличивается TCO, а миграция превращается в отдельный рискованный проект. Причины для перехода между платформами при этом вполне практические: требования к целевому контуру, устаревание собственного ЦОДа, невыгодная экономика текущего провайдера, необходимость построить DR или перенести нагрузки в другой регион. Поэтому вопрос уже не в том, нужна ли компаниям мультиплатформенность, а в том, как сделать её управляемой. В прямом эфире AM Live разберём, как провести аудит инфраструктуры, автоматизировать миграцию, переносить нагрузки между ЦОДами, облаками и платформами и строить катастрофоустойчивую архитектуру. И отдельно проверим главный тезис: действительно ли единый слой управления даёт заказчику свободу выбора — или сам становится новой точкой зависимости. Программа Инфраструктурный «зоопарк»: где начинается зависимость Как выглядит современная ИТ-инфраструктура крупного заказчика? В какой момент удобная экосистема одного вендора превращается в vendor lock? Нужен ли мультиплатформенной инфраструктуре единый слой управления? Почему инфраструктурная миграция до сих пор часто остаётся отдельным проектом на недели или месяцы? Что компания должна знать о своей инфраструктуре до того, как вообще начинать миграцию? Какие этапы миграции уже реально автоматизировать, а где участие инженера всё ещё необходимо? В какой момент миграция перестаёт быть рискованным проектом и становится обычной операцией? Почему компании мигрируют и как не сломать бизнес Как меняется проект миграции, если компании нужно перейти в аттестованный контур или использовать сертифицированное ПО? Когда требование регулятора может стать поводом не только перенести инфраструктуру, но и пересмотреть её архитектуру? Когда компании действительно пора разгружать собственный ЦОД и переносить часть нагрузок в облако? Что нельзя просто «взять и перенести» из собственного ЦОДа в облако? Когда экономия от смены облачного провайдера действительно окупает стоимость и риск миграции? Что чаще всего удерживает заказчика у текущего провайдера, даже когда экономика уже не устраивает? Что вы должны сделать, чтобы клиент через три года не оказался в таком же vendor lock — только уже у вас? Чем реальная катастрофоустойчивость отличается от резервной площадки, которая существует только на схеме? Кто должен определять RTO и RPO - ИТ или бизнес? Можно ли использовать мультиплатформенность как инструмент DR: основной контур у одного провайдера, резервный у другого? Как поддерживать резервную среду в актуальном состоянии и сколько времени должно занимать реальное переключение? Как часто нужно реально переключаться на резервную площадку, чтобы быть уверенным, что DR работает? Мультиплатформа через 3–5 лет: норма или возврат к одному стеку? Через три-пять лет мультиплатформенная инфраструктура останется нормой или компании снова потянутся к крупным вертикальным экосистемам «один вендор - один стек»? Что сегодня сильнее всего создаёт vendor lock? Если компания сегодня понимает, что уже живёт в мультиплатформенном «зоопарке», какие три действия ей нужно сделать в первую очередь?
Регистрация и подробности — на официальном сайте организатора.
