Сегодня миграция в облако – один из популярных пунктов в стратегиях развития многих компаний. При этом данный процесс – многоступенчатый и включает множество подводных камней.
Чтобы помочь каждому, кто планирует перенести свои рабочие нагрузки в облако или пока только раздумывает об этом, мы решили собрать самые показательные примеры ошибок – и вместе с ведущим системным администратором Beget Никитой Порушковым разобрать, что именно пошло не так и как этого можно было избежать.
1. Иллюзия всемогущества
Многие воспринимают облако как волшебную кнопку и думают, что оно решит все проблемы. На деле все не так радужно – если есть плохо написанное приложение или хаос в процессах, облако только усилит эти проблемы.
К примеру, если компания решает перенести монолитное приложение в облако, ожидая мгновенной масштабируемости, то в итоге оно будет так же падать при нагрузках, только теперь еще и счет от облачного провайдера вырастет в разы.
Кейс из практики:
- Ритейлер планировал перенести устаревшую платформу в облако, чтобы справиться с увеличением трафика в «черную пятницу», однако устаревшие платежные шлюзы и инструменты синхронизации запасов оказались несовместимы с новым стеком, а когда трафик резко возрос, платформа не выдержала нагрузки, оплата не прошла и тысячи клиентов отказались от своих покупок, что привело к негативным отзывам в соцсетях и потере дохода в размере 15 млн долл.
Комментарий эксперта:
Важно понимать, что облако – это не магия, а всего лишь чужие ресурсы, предоставляемые по подписке. Даже обычный shared-хостинг – это, по сути, облако, только более простое. Разница лишь в уровне: современные провайдеры предлагают не только железо, но и целый набор готовых сервисов, которые могут быть полезны для конкретных задач бизнеса. Это довольно частая проблема.
Кто-то думает, что он приобретает сервисы под ключ, однако на деле – просто покупает тот же сервер и его физическое обслуживание. Логическую работу все равно зачастую делает сам клиент. Хотя облачные модели все чаще и чаще пытаются предоставить и полный сервис – там, где можно осуществить стандартизацию.
К примеру, shared-hosting – это стандартизация большой части веб-стека, которая состоит из nginx-apache-mysql, может предоставляться сразу как сервис и реализовываться для всех одинаково. Но стоит добавить туда кастомизацию в виде сервера на nodejs или postgresql – и уже возникают проблемы.
Так же и в облаке – базы, файловые хранилища и другие стандартизованные вещи все чаще представляются уже как сервисы, а не как ресурсы.
2. Плохая локальная экспертиза
Иногда компании начинают перенос с конца или хаотично: часть сервисов в облаке, часть на старых серверах. Подобный подход создает технический долг и увеличивает сложность поддержки. К примеру, если бухгалтерия компании работает в облачном приложении, а база клиентов – всё еще на локальном сервере, то интеграция может быть нестабильна. Кроме того, возможны дополнительные проблемы со связностью сервисов, а также сложностью их поддержки.
Кейсы из практики:
- Медицинская организация перенесла данные пациентов с локальных серверов в облачное хранилище, однако из-за неправильного скрипта IAM и ненастроенных резервных копий были удалены записи о пациентах, и этот перенос сервера в облако вызвал судебные иски из-за нарушений HIPAA – то есть правил конфиденциальности в целях защиты информации о физическом и психическом здоровье пациентов.
- Сеть быстрого питания «Додо Пицца» не изучила специфику магнитных дисков Azure Storage – и в результате балансер обрывал старые TCP-сессии, к чему приложение готово не было.
- Непродуманный перенос баз в облако может вызвать дополнительные временные затраты в будущем – например, из-за необходимости вносить изменения в архитектуру системы, как это произошло с телекоммуникационной компанией Linxdatacenter: изначально в проект закладывалась возможность даунтайма, но потом выяснилось, что простой по некоторым системам абсолютно недопустим. Пришлось выделить дополнительное время для планирования миграции, собрать «лабораторию» для проведения тестов перед миграцией «боевых» систем.
Комментарий эксперта:
Планируя переход, можно легко переоценить экономию. В облаке не нужно покупать серверы, содержать дата-центр и оплачивать ресурс «железных» специалистов, но всё еще нужно содержать администраторов, которые поддерживают уже верхнеуровневую инфраструктуру.
Зачастую, если не нужна надежность железной инфраструктуры, можно сделать серверную в подсобном помещении – и, если не обращать внимания на то, что она может перестать работать из-за невнимательного уборщика, то обычно такой вариант дешевле, чем использовать облачные ресурсы.
Помимо железа, сети, пространства, нужны специалисты, которые будут поддерживать «железную» составляющую, а их может просто не быть – и это снова приводит к необходимости облачной составляющей в контексте простоты, несмотря на большую стоимость.
Но разработчики и администраторы, которые будут поддерживать уже «софтварную» архитектуру, всё равно нужны, от них никуда не уйти – и именно их экспертиза вносит основной вклад в успешную работу инфраструктуры. «Облако» может заменить как раз типовые решения и проблемы низкого уровня, но без понимания своей инфраструктуры любые движения не очень полезны.
3. Недостаток экспертизы по конкретному провайдеру
Порой складывается впечатление, что мигрировать в облако – это просто. И понимание нюансов работы облачной платформы не так важно, как знания собственной инфраструктуры. Это не так – у каждой облачной платформы есть довольно большое количество особенностей, связанных с работой системы, выделением ресурсов, функционированием сети. И это отдельные знания, которые не относятся к экспертизе в области собственных микросервисов. Бывает так, что внутренней экспертизы не хватает, и перенос осуществляется просто с надеждой, что всё запустится и будет работать как-то само.
Кейсы из практики:
- SaaS-стартап решил перейти на облачную платформу самостоятельно. В результате внутренняя команда допустила критические ошибки в проектировании сети, перераспределила ресурсы и раскрыла конечные точки из-за неправильной настройки групп безопасности – эти проблемы привели к атаке программой-вымогателем и незапланированным расходам в размере 80 тыс. долл.
- Перевод IBM системы электронной почты в облако обернулся тем, что тысячи сотрудников компании не смогли отправлять письма, получать оповещения о предстоящих совещаниях и планировать работу в календаре. Всё это из-за того, что финансовый директор ввел политику сокращения расходов и отказывался нанимать людей, которые могли бы ускорить процесс миграции внутренних сервисов в облако.
- При выполнении переноса пяти конфигураций 1С в облако компания с офисами в Москве и на Дальнем Востоке столкнулась со сбоями системы – такая ошибка миграции произошла в том числе из-за того, что в точности повторить топологию сетевой инфраструктуры в рамках теста оказалось невозможно, так как сетевые инженеры, которые изначально создавали сеть и настраивали связи между площадками, уже не работали в компании, а их преемники не знали всех тонкостей системы.
- Во время миграции Globe Telecoms многие сотрудники изначально сопротивлялись внедрению новых облачных инструментов и продолжали полагаться на устаревшие системы, поскольку не были знакомы с новой платформой, что замедлило процесс миграции.
- Банк TSB не сумел должным образом организовать и проконтролировать процесс миграции на новое ПО, в результате чего не менее 1 млн клиентов остались без доступа к принадлежащим им счетам, а британские регуляторы наложили многомиллионный штраф – по мнению экспертов, TSB поплатился в том числе за гордыню собственного руководства, которое в кризисный момент отказалось от помощи со стороны разработчиков предыдущей версии информационной системы, ранее использовавшейся в банке.
Комментарий эксперта:
Даже базовые сервисы в облаке требуют понимания их устройства. Без опыта можно «накликать» инфраструктуру, которая работает, но не оптимально и не безопасно или непонятно как, а может и вовсе не работать, но это хотя бы будет заметно сразу.
Каждый год появляются истории с дефолтными доступами какой-нибудь cloud-базы или доступом вообще без какой-либо авторизации. Это как раз происходит по причине того, что нюансы самой платформы и ее особенности не были изучены.
4. Дальнейшая привязка к инфраструктуре провайдера
При миграции в облако важно понимать, что чем больше инфраструктуры вы туда переносите, тем больше вы зависите от конкретных решений, которые предоставляет именно этот облачный провайдер. Зачастую соединение инфраструктурных сегментов от разных провайдеров – это дополнительная сложность. А какой-то отдельный провайдер может не предоставлять весь спектр необходимых сервисов. Кроме того, в будущем, когда вся инфраструктура будет завязана на конкретных решениях, провайдер может их ликвидировать либо качество может сильно ухудшиться.
Кейс из практики:
- LinkedIn отменил миграцию в облако Microsoft Azure спустя 4 года после объявления о планируемом переезде – из-за того, что возникли проблемы при переносе существующих программных инструментов, а переработать их для функционирования на готовых инструментах нового поставщика облачных услуг оказалось невозможно.
Комментарий эксперта:
Выбирая облако, люди часто не думают, что привязываются к конкретному API, SLA и политике ценообразования. Если облачный сервис упал, нельзя практически никак повлиять на провайдера – в этом плане вы будете полностью зависеть от качества работы другой компании.
Также вы будете завязаны на тех решениях, которые предоставляет провайдер, а перейти к новому поставщику может быть крайне сложно.
Зачастую это не проблема, но при планировании важно обращать внимание на данный момент.
Советы эксперта: как избежать ошибок при миграции в облако
✔ Составьте план миграции – начните с инвентаризации сервисов и данных, определите, что переносить в первую очередь, а что лучше оставить на месте.
✔ Считайте деньги – сравнивайте стоимость облака и собственной инфраструктуры на горизонте нескольких лет и не забудьте учесть скрытые расходы (трафик, лицензии, поддержку).
✔ Оцените риски зависимости – подумайте заранее, сможете ли вы при необходимости сменить провайдера.
✔ Повышайте экспертизу – инвестируйте в обучение команды или привлекайте внешних специалистов хотя бы на начальном этапе.
✔ Не верьте в магию – облако лишь инструмент, а не решение всех проблем, поэтому если внутри компании хаос, то он останется и в облаке.
Комментарий эксперта:
Проблемы миграции в облако – это не какие-то уникальные «облачные» трудности. Они те же, что и в любых IT-проектах: отсутствие плана, недостаток знаний, завышенные ожидания. Облако дает мощный инструмент, но пользоваться им нужно с умом.
Заключение
Сегодня 95% крупных компаний в России используют облачные технологии. По прогнозам, к 2028 году такие технологии станут необходимостью для большинства компаний в мире, а к 2029 – объем рынка услуг по миграции в облако вырастет до 637,13 млрд долл.
В то же время каждому, кто планирует перенести рабочие нагрузки в облако, важно понимать, что такая миграция представляет масштабный комплекс задач, с которыми лучше разобраться заранее.
