Что может побудить нас переехать из железа в облако? А обратно? Иногда за этим стоит желание повысить отказоустойчивость, в других случаях — снизить затраты или вернуть контроль. Но достаточно ли хорошо мы понимаем, во что на самом деле ввязываемся? И какие подводные камни ждут на этом пути?
Я — Андрей Радыгин, сейчас руководитель одного из продуктовых направлений Deckhouse Kubernetes Platform, а до того — глава DevOps-агентства Fevlake. Много лет я строю производственные и бизнес-процессы, внедряю изменения и масштабирую команду. Пишу заметки о менеджменте на работе и в жизни в авторском телеграм-канале «Руководитель в production». В прошлом — специалист техподдержки, инженер эксплуатации, архитектор и руководитель технических департаментов.
Моя техническая экспертиза концентрируется на двух направлениях: хостинг-провайдеры и аутсорс в том или ином виде. Я видел много инфраструктур и миграций, поэтому в целом неплохо представляю, что обычно идёт не так.
В этой статье по мотивам доклада с DevOpsConf затрону тему не самых очевидных нюансов, с которыми столкнётся инженерная команда, мигрируя инфраструктуру на облака или в on-prem. У каждого решения есть причины, но прежде покажу на основе опыта и кейсов, какие неочевидные факторы следует учесть, чтобы миграция прошла хорошо. Не только в инженерном смысле, но и в соответствии с возможностями бизнеса. А именно:
скрытые затраты миграции: сколько на самом деле она может стоить;
метрики: как оценивать ROI миграции;
временные проблемы или сигнал к миграции;
инфраструктурные риски;
влияние облака/on-prem на обновление/устаревание технологий;
управление и мониторинг: чем отличается контроль инфраструктуры в on-prem и облаке;
архитектура отказоустойчивости: что справляется лучше — облако или on-prem.
Дисклеймер
Эта статья — не how-to и не пошаговый мануал с готовыми рецептами. Скорее, это общая инструкция, как не упустить важное, на что ориентироваться в процессе миграции, какие возможны риски и как посчитать свои планы в деньгах.
Миграция как решение: когда оправдана и когда нет
Прежде чем что-то делать, хорошо бы понять: а зачем? Какие цели мы хотим достичь? Особенно если речь о миграции инфраструктуры. Это большой проект.
Если не задумываться о целях — просто действовать по инерции, по указке сверху или в духе карго-культа, — обычно ничего хорошего не выходит. Потому что рано или поздно реальность начинает расходиться с ожиданиями, и гарантированно возникает негатив.
Типовые цели миграции в облако
Вот краткий список самых популярных целей при переезде в cloud. Он, конечно, не исчерпывающий, но даёт общее представление:
Повышение отказоустойчивости
Уменьшение количества слоёв управления
Динамическое масштабирование
Использование managed-сервисов
Получение механизмов Disaster Recovery
Снижение затрат
Например, мы хотим повысить отказоустойчивость. Или использовать managed-сервисы, чтобы переложить часть забот на облачного провайдера. Или внедрить механизмы Disaster Recovery, которых раньше не было. Или оптимизировать расходы. Всё это — вполне рабочие, понятные цели.
Когда и зачем возвращаться на on-premise
И такое тоже бывает. Здесь цели обычно другие:
Безопасность
Никакого оверсела
Гибкая настройка
Полный контроль над всеми уровнями инфраструктуры
Прозрачность и контроль расходов
Если мы переезжаем на on-premise, то, скорее всего, хотим вернуть себе полный контроль над инфраструктурой, безопасностью и бюджетами. Это может быть важно, если есть жёсткие требования по безопасности или нужно понимать и прогнозировать расходы по старой, привычной модели.
В обоих сценариях важно понимать, с чего начать. Например, с того, чтобы оценить, во сколько миграция обойдётся компании.
Миграция — это проект, а не кнопка
Шаг, который многие пропускают — но это большая ошибка — это планирование, оценка стоимости и рисков. Если вы отвечаете за миграцию, например, как owner направления или проекта, то финансы и риски автоматически становятся вашей зоной ответственности. Рано или поздно бизнес придёт к вам с этими вопросами и тогда очень важно хотя бы в общих чертах понимать: как всё считается и работает.
Считаем финансы
Когда я думал, как рассказать о расчёте бюджета и когда сам этим занимался, ощущения были… ну, скажем так, непростые. Но в итоге я выделил для себя два ключевых показателя, которые мног��е часто путают:
Payback Period (PP) — срок окупаемости.
Здесь простая логика: вложили 100 рублей, за год сэкономили 100 — значит, срок окупаемости один год.
Return on Investment (ROI) — процент возврата вложений за выбранный период.
Это то, сколько дополнительно мы заработаем после того, как окупили вложения.
Чтобы рассчитать срок окупаемости (PP), нужны три цифры:
MC (Migration Cost) — стоимость миграции.
AICold — текущая годовая стоимость инфраструктуры.
AICnew — прогнозная годовая стоимость инфраструктуры.
Посчитать ROI чуть сложнее, но несущественно:
добавляем период расчёта N (например, в годах);
умножаем на 100%, чтобы понять соотношение.
Даже если вы пока не собираетесь углубляться в метрики вроде ROI или Payback Period, стоимость миграции как проекта считать придётся в любом случае. С неё всё начинается.
Подсчёт стоимости миграции
Примерная формула расчёта стоимости миграции выглядит так (наверняка её можно дополнить еще какими-то факторами, которые я упустил):
Дальше мы пройдемся по каждому из слагаемых. Сначала следует оценить, какое влияние оказывает эта стоимость. Но как?
Начнём с простого: расчёт эффекта через трудозатраты.
Если инженеры работают на аутста��е, T&M или почасовке, — рассчитать легко. Посчитали часы, прикинули ставку, получили стоимость. Например, инженер стоит N рублей в час, тратит 100 часов — вот и получилась стоимость миграции.
Но что если у нас in-house команда? Люди на окладе, зарплату им всё равно платить. Тогда вроде бы неважно, сколько времени они тратят на миграцию — для бюджета цифра не меняется. Но это только на первый взгляд.
Здесь есть важный фактор, который надо учитывать и объяснять бизнесу. Отвлечение команд на такой большой проект, как миграция, особенно если они заняты на 100%, на 90% или на 147% — это гарантированное извлечение их ресурса из других параллельных задач, которые никогда не останавливаются.
Всегда есть бизнес-задачи, которые должны катиться. Но на миграцию потратится некоторый объём ресурсов. Надо транслировать бизнесу мысль, что в процессе миграции будет замедление прочей работы на N процентов, и если мы не хотим замедлять текущие проекты, нужно нанять дополнительных людей или приоритизировать задачи.
Важно понимать, что это замедление выражается не просто в занятости команды, а в ухудшении конкретных бизнес-показателей разработки: увеличивается Time-to-Market, замедляется доставка новых фич, страдает масштабируемость команд.
Аудит и планирование
Первый шаг для оценки стоимости миграции — аудит и планирование. Вроде бы это очевидно, как в любом проекте, но в случае с миграцией — особенно критично.
Здесь речь о полноценной проработке актуальной инфраструктуры, приложения и того, как всё взаимосвязано. Это непростой и ресурсоёмкий этап. В него вовлечены дорогостоящие с точки зрения экспертизы ребята — архитекторы, ведущие разработчики, PM. Их количественного ресурса сильно меньше, чем у прочих команд.
Чтобы показать, чем грозит пренебрежение аудитом и планированием, я нашёл публичный кейс, который хорошо иллюстрирует, как легко можно пойти по неправильному пути, если не уделить этому шагу достаточно внимания.
Кейс университета Варшавы (2015)
Задача: Запустить Big Data и HPC.
Университет Варшавы планировал внедрить инновационный супервычислительный кластер — один из первых в стране. Уже на первом этапе они допустили ряд базовых ошибок, из-за которых кластер не работал. Причём дело не в том, что он не дотягивал до 100% от ожидаемой мощности — он был загружен примерно на 15%. И ошибки смешные: например, кластер должен был быть мультитенантным, но поддерживал работу только в режиме single user. То есть, один пользователь — один гигантский кластер, который стоил сотни миллионов (не буду утверждать, но точно очень много).
Попытка исправить: гибридное облачное решение.
Прошло несколько лет. Приходит новый технический директор, видит это безобразие и говорит, что знает, как решить эту беду, сейчас всё исправит — надо сделать гибридное решение на базе облака, и тогда можно утилизировать ресурс как положено.
Запускается проект по созданию гибридной архитектуры. Но его не довели до конца. В 2022 году, если верить последним новостям, решение всё ещё не завершено.
Результат:
ROI = 0 (а скорее даже отрицательный).
Частичная реорганизация ИТ-систем.
Незаконченное гибридное решение.
Позже этот же технический директор, покинув университет, рассказывал в статье, что столкнулся с полным непониманием со стороны руководства. Им казалось: ну стоит же кластер, всё работает, зачем вообще что-то менять?
Среди причин он перечислил недостаток планирования, недооценку сложности инфраструктуры и сопротивление со стороны ИТ-персонала. Система очень сложная, и даже этот опытный технический директор недооценил, насколько. А всё потому, что не было плана и не провели нормальный аудит.
Перепроектирование архитектуры
Дальше может возникнуть задача перепроектирования архитектуры — и не только инфраструктуры, но и самого приложения, которое в ней работает.
Этот этап зависит от результатов предыдущего, потому что без аудита и планирования вы просто не поймёте, что именно нужно менять. А менять, скорее всего, придётся — особенно если вы переезжаете в облако. Возможно, приложение будет несовместимо с каким-то облачным функционалом или по другой причине. Главное — если вы не анализировали, какие доработки нужны приложению, и сразу начали миграцию и запуск в новой инфраструктуре, приложение может работать совершенно не так, как хотелось.
В перепроектирование, как правило, вовлечены инженер-архитектор, ведущий разработчик, разработка, QA. Все эти люди должны быть в курсе происходящего и вовремя включаться, чтобы избежать неприятных сюрпризов на проде.
Где брать недостающую экспертизу
Ещё один острый момент, о котором важно подумать — а хватает ли вашей команде знаний и опыта? Новая инфраструктура, новые окружения, новые технологии и как всё это будет выглядеть.
Если нужных скиллов в команде нет, то, возможно, придётся обращаться к аутсорсу, нанимать дополнительных специалистов. Это уже прямые финансовые затраты организации. И, вполне вероятно, что они не были заложены в изначальный бюджет. А значит, рано или поздно к вам как к тимлиду или архитектору придут с вопросом о том, почему выросли эти расходы.
Подготовка новой инфраструктуры
Дальше, кажется, быстрый шаг — запустить инфраструктуру, которую вы замечательно, классно напланировали. Но по факту — нет.
Если речь идёт о сотнях серверов, десятках или сотнях сервисов, то запуск новой инфраструктуры может занять до шести месяцев full-time работы нескольких DevOps-инженеров. Достаточно долго.
Стоимость всей инфраструктуры
Есть один тонкий, но очень важный момент, который нам с вами — как людям, с этим работающим — вроде бы понятен. Но бизнесу — нет. Старая инфра ещё работает и потребляет бюджет. Когда вы запускаете новую, она тоже начинает потреблять. Параллельно!
На графике это выглядит просто: по вертикали — стоимость, по горизонтали — время. И какой-то период у вас идут параллельные расходы, которые могут быть в 2–3 раза выше обычного, пока вы экспериментируете и разбираетесь с новой инфраструктурой.
Когда вы, не подумав о такой тривиальной вещи, принесёте финдиру чеки x2 от предыдущей стоимости провайдера и хостинга, скорее всего, буд��т много негатива. Я видел это множество раз. Смешно и, казалось бы, очевидно, но так и есть.
Перенос данных
Когда инфраструктуру запустили, наступает следующий этап — перенос данных. Сразу уточню: речь не про базу в 3 GB и не про «копеечные» данные в S3, а про кейсы, где данных — сотни терабайт или даже петабайты. Тут всё становится совсем другим по масштабу.
Стоимость исходящего трафика на 5 GB будет незаметна вам и бизнесу. Другое дело, когда 5 TB или 5 PB, и ещё придётся гонять их несколько раз, потому что обязательно кто-нибудь ошибётся и испортит только что перелитые данные.
Я прикидывал в разных облаках стоимость исходящего трафика таких объёмов — не буду приводить конкретные примеры, уверен, вы справитесь с этим. Суть в том, что счёт идёт на миллионы или десятки миллионов рублей за один прогон.
Помимо стоимости трафика, есть вопрос сложности переноса структуры данных. Если это S3 — это скорее вопрос техники, и он обычно не вызывает затруднений. Но миграция больших и сложных СУБД всегда сталкивается с проблемами.
Кейс про сложности с миграцией большой БД
Расскажу реальную историю. У ребят было хранилище:
более 2000 таблиц,
50+ миллиардов строк,
объём — больше 5 TB.
Они решили переехать на другую платформу. Подумали: «Ну, за полгода управимся». И не стали делать ни аудит, ни нормальное планирование. Просто начали миграцию.
Через пару месяцев приходят девопсы и говорят: «У нас лапки. Ничего не получается. Миграции отваливаются, данные не синхронизируются. Нужен DBA». Наняли DBA — первого, второго, — всё равно не едет.
Проект попал ко мне через полтора года незавершённой миграции. Всё пришлось перетряхивать с нуля. А вывод в том, что недооценили сложность и не сделали нормального планирования.
Кейс Dropbox (2016)
В 2016 году Dropbox принял решение мигрировать из AWS на собственную on-premise инфраструктуру. Это не факап — скорее, показательная история о том, как ожидания могут разойтись с реальностью.
Задача: Миграция из AWS с целью снижения затрат.
На тот момент у Dropbox было порядка 500 PB данных. В планах было уложиться с миграцией за год.
Результат:
Миграция растянулась на три года.
Возникли проблемы с синхронизацией данных.
Пользователи сталкивались с реальными сбоями из-за рассинхрона.
Причина — в первую очередь, неверная оценка сложности переноса данных. Это признали в самой компании. И хотя в итоге они добились своего — сэкономили деньги, само расхождение между планом и реальностью оказалось болезненным.
Тестирование и валидация
После того, как вы всё смигрировали, запустили и новая площадка работает, остаётся вопрос с тестированием и валидацией.
Сколько ресурсов потребуется? Много. Потому что:
разработчики должны писать тесты (если их ещё нет — держитесь);
QA-инженеров придётся привлекать;
DevOps-инженеры будут бегать и доделывать, что «забыли».
Казалось бы, как не тестировать перед подключением прода? Это же невозможно. Оказывается, возможно. Дальше — один из примеров.
Кейс TSB Bank (2015-2016)
В 2016 году крупный британский банк TSB перешёл в собственность другой корпорации. Возникла масштабная задача: мигрировать инфраструктуру между платформами и улучшить отказоустойчивость.
Результат:
Огромные репутационные и финансовые потери.
Уменьшение клиентской базы.
Стоимость всей провальной миграции составила около 300 млн фунтов стерлингов. Порядка 250 млн ушло на устранение последствий, плюс ещё штраф в районе 50 млн за потерю транзакций и финансовых данных. TSB лишился тысячи пользователей, и не просто так: у людей «поменялись нолики» на счетах.
Причины фантастические — команда практически не занималась тестированием. «В путь! Сейчас мы просто перетащим», и начали переключать. Не были предприняты меры для выполнения максимально бесшовной миграции.
История настолько яркая, что её взяла за основу компания, продающая инструменты для тестирования — и теперь с гордостью использует этот кейс в маркетинге.
Но это еще не всё.
Оптимизация после переезда
Предположим, вы всё протестировали, прод включили — казалось бы, уже замечательно. Но нет. Как показывает практика, ещё минимум полгода вместе с DevOps и разработкой вы будете что-то допиливать, дотюнивать, переделывать, наводить порядок в своей новой инфраструктуре.
Приведу пример. Компания переезжала в cloud. Всё переключили, функционально проверили — в целом работает. Нагрузочное тестирование не делали. Но при подаче трафика в прод всё развалилось — оказывается в облаке есть сетевые задержки и приложение не справляется с реальными нагрузками.
В результате микросервисы перестали успевать друг за другом — не дожидались ответов, происходили тайм-ауты, всё сыпалось. Мы срочно переключили обратно, вызвали разработку, переписали часть взаимодействий. Итог — прод откладывается, переключение отложили на полгода.
Возникает закономерный вопрос — как всё это посчитать?
Как считать и защищать цифры. Методика
В целом, как и в любом другом проекте, здесь работает привычный и понятный подход:
Составить план-график работ вместе с PM и тимлидом.
Декомпозировать крупные этапы в конкретные задачи.
Оценить трудозатраты по каждой задаче.
Дальше понятно: это либо прямые финансовые расходы, либо, если работает внутренняя команда, частичное изъятие ресурсов из текущих проектов. В любом случае, у вас на руках появляется набор цифр, с которым можно идти к бизнесу. Возможно, имеет смысл после третьего шага подстраховаться и умножить получившуюся сумму на два. На всякий случай.
Стоимость инфраструктуры
И, конечно, не забываем про стоимость самой инфраструктуры — её тоже нужно считать, чтобы использовать формулы из начала статьи. Ещё надо учесть не только текущую стоимость, но и прогнозируемый бюджет.
Годовая стоимость
Дальше поговорим о нюансах, которые часто всплывают именно при попытке построить такой прогноз. Я набросал ориентировочный список статей расходов отдельно для on-premise и для облака:
В on-premise есть свои неожиданные детали, непривычные тем, кто привык работать только с облаком. Казалось бы, базовые вещи: закупка дизеля, плата за электричество, охлаждение, обслуживание оборудования — но об этом нужно думать заранее. В облаке, с другой стороны, тоже хватает подводных камней. Один из самых ярких примеров — это трафик. Оплата трафика возникает в самых неожиданных (для неопытного администратора облака) местах, как например тарификация внутреннего трафика между разными регионами или между S3-хранилищем и виртуальными машинами. И таких мест достаточно много. Поэтому очень важно перед переездом в облако внимательно изучать их калькулятор и перекладывать на свои потребности.
Ну ещё прогнозы не всегда точны. Об этом поговорим отдельно.
Ошибки в прогнозах
Есть тип когнитивного искажения, когда мы продолжаем мыслить в старых категориях, даже если условия кардинально изменились. К примеру, когда мы переезжаем в облако из on-premise, у многих в on-premise ресурсов закуплено с большим-большим запасом. Стоят огромные гипервизоры, всё летает, есть запас мощности. Вы особо не думаете, что растёте каждые 1-3 месяца.
В итоге при переходе в облако рассчитываете бюджет на ресурсы, исходя из текущего потребления, и забываете о том, что через три-шесть месяцев утилизация может значительно вырасти, а вы это не заложили в бюджет. После чего приходит счёт x2 и вместе с ним бизнес и стейкхолдеры с вопросами: «Как так? Мы рассчитывали на другие цифры!». Особенно это больно бьёт по крупному энтерпрайзу.
Есть классный показательный пример. В крупной компании, когда ЦОД — это другое подразделение, к которому вы как DevOps или SRE не имеете отношения, они для вас как закрытая коробочка. Вы просите ресурсы — они дают. О том, что они потом бегают по рынку, покупают сервера, чтобы обеспечить эти ресурсы, никто не задумывается. А когда вы переезжаете в облако, чаще всего ресурсы становятся вашей ответственностью — это непривычно и приводит к допущению множества подобных ошибок.
В обратную сторону — из облака в on-premise — тоже есть нюансы. В облаке вы привыкаете к тому, что можно мгновенно масштабироваться. В on-premise так не выйдет. Купили сервера «впритык» — и вдруг попали на пиковую нагрузку, например, из-за маркетинговой активности, и уже не справились — трафик не помещается.
Есть ещё история с незнакомой моделью затрат, я показал её в таблице выше. Обязательно ознакомьтесь и составляйте себе детальный план статей непривычных расходов. Пообщайтесь с коллегами, кто уже живёт с «железом». Сходите на конференцию, спросите у коллег, что вас ждёт. Какие бывают непредсказуемые статьи расходов, как их учитывать, где искать подводные камни. Составьте свою смету и закладывайте всё это в бюджет.
Ещё важный момент при расчётах бюджета, о котором не стоит забывать — это учитывать возможный рост инфраструктуры.
Прогноз роста инфраструктуры
Когда мы занимаемся планированием инфраструктуры, особенно при расчёте ROI, важно помнить: она существует не сама по себе, а обслуживает бизнес. И, как бы банально это ни звучало, именно бизнес-метрики определяют, какой инфраструктура будет через полгода, год или два. Мы, как инженеры, часто об этом забываем, потому что фокусируемся на системе, но если не учитывать рост и изменение нагрузки, всё посчитанное может быстро устареть.
Надо идти к людям, которые отвечают за бизнес-метрики — это может быть CPO или даже CEO, зависит от структуры вашей компании, и вместе с ними обсудить, какие главные бизнес-метрики в организации.
Например, если у вас интернет-магазин, это может быть поток пользователей или RPS. И тогда у вас есть Kubernetes, ingress, вычислительные ресурсы — всё понятно, что и как масштабировать. А если у вас аналитический бизнес, с большими объёмами данных и ClickHouse, и бизнес планирует рост числа пользователей, которые загружают данные — значит, у вас инфра уже вырастет именно в этом месте, и это надо учитывать.
Поэтому находите свои бизнес-показатели, определяйте, как они влияют на инфраструктуру и составляйте прогноз на какой-то срок, релевантный для вас. Учитывайте это в расчёте ROI, потому что если в ROI заложить статичную цифру затрат на инфраструктуру на несколько лет, то потом цифры не сойдутся.
Нематериальные риски
Риски в проектах по миграции можно условно поделить на две большие категории:
Те, что можно залить деньгами в моменте (нанять людей, докупить ресурсы).
Те, где деньгами уже не поможешь. Потому что девять женщин не рожают за месяц ни ребёнка, ни половину ребёнка.
Рассмотрим популярные риски, которые влияют на длительность проекта и на стабильность инфраструктуры и приложения.
Опыт команды
Часто команде не хватает опыта для проведения миграц��и, особенно если инфраструктура сложная и проект нестандартный. Если в команде нет людей, которые участвовали в крупных миграциях, — почти гарантированно будут проблемы:
Длительность выполнения задач. Задачи выполняются дольше, чем опытным человеком, что логично.
Рост количества ошибок, которые надо исправлять. А иногда они вылезают, когда уже поздно исправлять, или не поздно, но точно больнее.
Неправильное архитектурное решение. Ошибки на уровне архитектуры — самый опасный сценарий. Он выстреливает, когда это больнее всего и нужно кардинально что-то менять.
Следующая история с рисками — ресурсы, которых часто не хватает.
Наличие ресурсов
Ранее мы говорили, что важно оценить трудоёмкость миграционного проекта. Но следующим шагом должно стать понимание: а вы вообще потянете это при текущей загрузке? Особенно если команда уже и так загружена на 100%. Я вижу такие типичные следствия нехватки ресурсов у команды:
Падает качество миграции и новой инфраструктуры.
Рост бэклога.
Задержка задач разработки для бизнеса.
Давление и негатив со стороны бизнеса по срокам.
Начинают миграцию: «Да что там, разберёмся!» Ресурсы постепенно вытягиваются из текущих бизнес-проектов — тех самых, которые имеют явную и понятную ценность для компании. Бизнес это замечает и начинает давить: «Быстрее, быстрее! Почему вы отвлекаетесь от важных задач? Давайте ускоримся».
Неокрепший тимлид начинает пропускать важные этапы тестирования и аудита: «Да ладно. Сейчас перевезём, а дальше по месту разберёмся». Как следствие, из-за неумения отстоять свою точку зрения перед руководством, в самый ответственный момент начинают вылезать критичные проблемы и аварии. И тот же бизнес снова приходит с вопросом: «Какого чёрта? Как это у нас downtime? Как это TTM вырос внезапно?»
Именно поэтому, если вы инициатор миграции, нельзя идти в это без поддержки бизнеса. Нужно заранее объяснять, зачем всё это делается, какую ценность даёт, на каком горизонте будет эффект. Потому что потом к бизнесу же и идти с отчётом.
Новые абстракции
Появление новых абстракций перекликается с наличием опытов и скилов в команде. Когда вы переезжаете в новую среду, будь то облако или железо, возникают задачи, с которыми вы либо никогда не сталкивались, либо успели о них забыть.
Переезд из cloud в on-premise
Если переезжаете на железо, всё это проявляется особенно остро. В облаке вы многие вещи получаете «из коробки». На своих железках — приходится вспоминать, как это вообще работает. Например:
Сегментирование сетей.
Управление нагрузкой гипервизоров (в облаке об этом вообще не думаем).
Не дай бог вы планируете разместить 100 виртуалок в каком-нибудь Proxmox и потом как угорелый бегать и вручную мигрировать между гипервизорами, чтобы нагрузка не развалила все перегруженные гипервизоры.
Хранение данных и сетевой доступ к ним.
Электропитание, охлаждение, ввод каналов и их резервирование, потопы в ЦОДах.
Все эти вопросы надо продумать, иначе обязательно начнутся проблемы — прежде всего, архитектурные.
Переезд из on-premise в облако
Здесь тоже есть нюансы:
Работа Load Balancer может отличаться от облака к облаку, и уж тем более от того, как было в on-prem.
IAM (управление доступами), интеграция в сервисы безопасности.
Прочие новые сервисы и сущности.
Смотрите внимательно, какие нестандартные для вас вещи появляются в целевой инфраструктуре.
Особенности managed-решений
Ещё один важный аспект, о котором стоит помнить при миграции, — это managed-решения и их ограничения.
Версионирование
Перед миграцией обязательно проверьте, что во всех сервисах, которые будут запущены в новой инфраструктуре и должны работать с managed-приложениями, используются версии, поддерживаемые провайдером. У managed-решений есть особенность: они поддерживают только ограниченное число версий — обычно не больше трёх последних. Всё, что старше, может не запуститься или работать с ошибками.
Я наблюдал множество ситуаций, когда 50 сервисов перетащили, и два из них — «дохленькие», с малым количеством трафика (но при этом вполне критичные по функционалу), про которые меньше всего думали. Вроде бы они поднялись, пробы проходят, и они как бы «живы». Но как только в новом месте пускают трафик — летят «пятисотки». Изначально упустили, что версии несовместимы, но это выяснилось слишком поздно — когда уже полетели запросы. Да и разработкой этих сервисов традиционно уже не занимаются, и вообще это легаси...
Управление и мониторинг
Также начинаются нюансы с тюнингом. Вообще managed-сервисы рассчитаны на «среднего потребителя». Если у вас специфичные corner-кейсы и есть экстра-нагрузки, то задумайтесь о том, что в managed-решениях вам никто не позволит конфигурировать ядро или тюнить файловую систему.
Помимо прочего, в managed-сервисах довольно интенсивная политика обновлений. Ваша разработка должна будет постоянно заниматься обновлениями всех библиотек в приложениях. Это надо планировать и выделять достаточно много времени. Не уверен, что они понимают это. Обязательно обсудите.
Следующий момент — возможности для мониторинга. Если у вас есть потребность вытаскивать какие-то низкоуровневые метрики, не факт, что managed-сервис даст это сделать. Надо помнить об этом. С другой стороны — а нужна ли здесь вообще эта метрика? Часто набор определённых метрик — это просто привычка и можно ограничиться меньшим, особенно в контексте перехода на управляемый провайдером сервис.
И, наконец, производительность и ограничения по объёму. Суть в том, что производительность может не совпасть с вашими потребностями, и это заранее надо проверить.
Архитектура отказоустойчивости
Один из ключевых вопросов, который также стоит обсудить — это отказоустойчивость и её целесообразность. Мы, инженеры, любим мериться «девятками», рассказывать, как наша система держит любые нагрузки, не падает ни при каких обстоятельствах и справляется с любыми невзгодами. Но за 15 лет работы я сделал простой вывод: по-настоящему катастрофоустойчивая архитектура — это очень сложно.
Чтобы построить действительно отказоустойчивую систему, вам придётся учесть множество факторов.
Вопросы распределённых систем:
неоднородность сетевых задержек,
сложность балансировки трафика между географически разнесёнными гео-зонами.
Вопросы хранения данных, которые встают в полный рост и редко легко решаются, потому что там есть:
CAP-теорема,
Backup/DR — синхронизация между регионами.
Архитектура самого приложения. Её почти всегда придётся менять или существенно дорабатывать. Просто взять и «переложить» существующее приложение в супер-отказоустойчивую инфру — не получится. Это работает только в презентациях. Настоящая отказоустойчивость требует изменений как на уровне инфраструктуры, так и на уровне приложения. И оба направления должны соответствовать.
В архитектуре приложения нужно будет учесть огромное количество сложностей, связанных с распределённостью, с Active-Active, разнесёнными по разным местам, а ещё:
Saga-паттерны
Eventual Consistency
Обработку отказов
Circuit Breakers.
Вопросы безопасности. Далеко не всегда есть возможность связать зоны напрямую физически. Поэтому в полный рост встанут вопросы с Zero Trust и mTLS.
Моделирование и тестирование катастроф. Можно построить сколь угодно красивую и в теории отказоустойчивую систему, но если вы ни разу не смоделировали катастрофу, не протестировали сценарии отказа — считайте, что у вас её и нет. Это как тот самый бэкап из шутки про бэкап, который ни разу не тестировали.
Производительность. Она обязательно просядет, потому что в по-настоящему отказоустойчивых системах это самое труднодостижимое. По крайней мере, с монолитом, размещённым в одном месте и на одной инфре, не сравнится никогда.
И последнее (как следствие сложности): катастрофоустойчивость — это очень дорого. Тут нечего добавить, поэтому смотрите на факторы целесообразности и контекст.
Факторы целесообразности
Когда вы размышляете над тем, надо ли строить отказоустойчивую или катастрофоустойчивую архитектуру, важно обращать внимание не только на техническую сторону, но и на целесообразность для бизнеса. На практике всё сводится к двум основным факторам:
1. Стоимость простоя
Потери дохода.
Потери производительности разработки.
Стоимость восстановления инфраструктуры.
2. Репутационные риски, что тоже про деньги:
Убытки из-за снижения лояльности пользователей.
Убытки из-за потери репутации.
Выводы
Миграция — это не просто технический процесс. Это большой и сложный проект, затрагивающий бизнес, команды, деньги, репутацию. Поэтому выводы здесь простые, но важные:
Планирование и оценка рисков — критически важны. Без них почти гарантированно что-то пойдёт не так. И чем позже вы это осознаете, тем дороже будет исправление.
Выравнивайте ожидания с бизнесом. Лучше сразу проговорить неприятные вещи про двойные расходы, сдвиги сроков, потенциальные даунтаймы, чем потом оправдываться, когда всё взорвётся.
Миграция — не всегда решение. Прежде чем бежать в облако или из облака, сделайте нормальный root cause-анализ.
Действуйте, исходя из реальных бизнес-потребностей. Мы строим инфраструктуру ради того, чтобы бизнес жил, развивался и был устойчивым.
Скрытый текст
А чтобы узнать больше из мира DevOps, приходите на конференцию DevOpsConf 2026 — это энергия и бесценный опыт лучших инженеров, CTO, CIO, техлидов и тимлидов, и всегда — это расширение профессионального кругозора, обсуждение практических вопросов, отработка навыков на мастер-классах и много-много нетворкинга!