Рынок услуг облачной миграции растет в среднем на 23% ежегодно и исчисляется миллиардами долларов. Эксперты прогнозируют переход на облачные сервисы 100% бизнеса. С каждой новой миграцией крупных игроков у последователей остается все меньше страхов. Но те, что остались, могут стать причиной отказа от перехода на модель SaaS. В этой статье мы пройдемся по “черному” списку и докажем, что миграция в облачный биллинг избавит от многих проблем, а не добавит новых.
К идее облаков крупные телекоммуникационные компании приходят не просто так. Скапливаются сотни серверов и ЦОДов, которые нужно постоянно обновлять, модернизировать и апгрейдить. Обслуживание такой груды “железа” выходит недешево, приходится держать штат айтишников и программистов или платить за аутсорс. Перестает устраивать текущая биллинговая система: не справляется с нагрузками, не вмещает растущую базу клиентов, медленно подстраивается под рынок, а маркетинговый функционал не позволяет проводить исследования абонентов и строить прогнозы. Кажется, что облачный биллинг - это отличная идея. Что же с ней не так?
Размер имеет значение
Абонентов у крупных телеком-операторов - тысячи, миллионы. Каждую секунду биллинг тарифицирует, считает, формирует документы, передает информацию в личные кабинеты пользователей и контролирует взаиморасчеты с российскими и зарубежными партнерами. Как такой массив данных переносить в облака?
На деле большим компаниям даже легче мигрировать - их вычислительные мощности сконцентрированы в едином центре. Опыт удаленной работы по всей стране уже есть, поэтому переход от собственного Центра Обработки Данных в облачный происходит менее болезненно. Чтобы сократить риск ошибок при переносе объемных данных составляется план миграции с поэтапным переходом. В плане вендор совместно с клиентом прописывает информацию о переносимых сервисах, список этапов,способы проверки каждого этапа, последовательность и сроки. Устанавливается приоритет переноса и обговариваются каналы передачи данных. В плане миграции мы определяем RTO - время простоя, RPO - величину потери данных и то, как мы планируем минимизировать эти показатели. Важно заранее обновить и модифицировать программу, чтобы неисправности не стали причиной проблем.
В поэтапном плане миграции прописывается все аспекты процесса: аппаратный или программный уровень миграции; переход с помощью переносных систем хранения данных, резервного копирования или каналов связи; частичный, полный перенос системы или разворачивание программы с нуля.
Здесь же возникает еще один страх клиентов - простои. Крупные операторы не могут себе позволить остановить работу биллинга даже на короткое время, поэтому мы проводим бесшовную миграцию в облако без остановки работающей программы. Если по техническим причинам или из-за особенностей системы бесшовный переход невозможен, стараемся обойтись малой кровью. У команды Forward Telecom был опыт такого перехода. Мы готовили полную копию системы и использовали два часа на переключение сервисов. Миграцию проводили в день, когда спрогнозировали минимальную нагрузку со стороны пользователей и переводили систему на модель SaaS поздно ночью.
Миграция биллинга в облако - это как последний шаг перед финишем, самый трудный, но все же победный. После перехода забота о стабильности и поддержке биллинговой системы, которая обслуживает огромную базу абонентов, полностью ложится на плечи вендора.
За семью печатями
Главный страх при миграции в облака №2 - безопасность. Чем больше абонентов - тем больше информации - тем больше вопросов и опасений возникает у крупных операторов. Служба безопасности обычно скептично относится к облачным сервисам и слабо представляет, как можно защитить данные клиентов и сотрудников на чужой территории.
Однако уровень безопасности, который обеспечивает для своих систем оператор, чаще всего уступает уровню защиты облачного вендора. Взломать поставщика и обойти все инструменты защиты облака гораздо сложнее, чем получить информацию от инсайдера в самой компании. А Forward Telecom предотвращает даже утечки по вине неосторожных сотрудников. В нашем арсенале логирование, распределение прав, многоуровневые бэкапы, песочницы, верификация файлов, проверка геолокации при доступе, проверка аппаратно-программных слепков устройств и система алертов.
Чтобы обезопасить себя и абонентов на юридическом уровне, после первых переговоров перед началом проекта подписывается NDA. С составлением документа лучше не тянуть и оформить соглашение перед передачей вендору информации, которой нет в открытом доступе.Технико-коммерческое предложение тоже следует проверить скрупулезно, иначе поставщик будет вправе запросить доплату за услуги, не прописанные в документе - например, за ленты, на которых будет переносится информационную система, или за канал передачи.
Само собой, подписывается и SLA с ответственностью исполнителя и параметрами облачного биллинга. Но красивые цифры не гарантируют безопасность: гарантии должны касаться не только гипервизора, но и учитывать доступность сети и СХД. Крупные операторы не зря выбирают для подобных переходов вендоров с именем - опытные разработчики несут большие репутационные риски, поэтому такие нюансы для них в порядке вещей.
Выбирая между российскими и зарубежными поставщиками, стоит помнить о законодательных и санкционных рисках. Серверы российских вендоров находятся на территории Российской Федерации, поэтому у них ниже сетевая задержка и нет проблем с соблюдением нормативных требований безопасности и хранением персональных данных.
Зависимость
Еще один страх - зависимость от вендора. “Исчезнет поставщик или обрубит доступ к программе - и останемся мы без биллинга и без клиентов”. Лечится эта фобия тремя этапами.
- Возвращаемся к тому, что поставщик должен иметь вес в отрасли и опыт работы с крупными компаниями. Ноунейм-вендорам испариться гораздо проще: о них никто не слышал и связями они обзавестись не успели. С состоявшимися разработчиками, которые на рынке более 10 лет, все сложнее: никто не захочет добровольно нести огромные финансовые убытки и разрушать репутацию надежного партнера. Для большей уверенности можно нанести визит в ЦОДы поставщика по договоренности.
- Нужно предусмотреть резервные каналы и правильно прописывать условия договора. Все возможные, невозможные риски и пути решения проблем должны быть прописаны на бумаге.
- Кажется, что программа в собственности компании - это панацея от бед. Но нельзя застраховать себя от всех форс-мажоров: внезапное отключение электричества в здании или в городе, поломка оборудования без возможности восстановления, обиженный сотрудник с доступом к системе, стихийные бедствия. А об уровне защищенности системы у вендора и у телеком-компаний мы уже говорили - см. предыдущий раздел.
Общественное мнение
Еще одно неочевидное препятствие, с которым сталкиваются крупные компании при переводе биллинга в облако - саботаж и сопротивление сотрудников. Работники опасаются волны увольнений, боятся не разобраться в новой системе. Им приходится тратить много времени на аудит бизнес-процессов и обучение, снижаются показатели выработки и, как следствие, зарплата. Подразделения не могут прийти к компромиссу в смежных процессах, а работа в новом биллинге по схеме “как понял” приводит к сбоям и ошибкам.
Крупным операторам связи сложнее справиться с негативом в большом коллективе, однако при грамотной подготовке сотрудников к переходу и поэтапному переводу на облачный биллинг можно избежать игнорирования и саботажа.
Наши главные рекомендации:
- Говорить с сотрудниками. Заранее рассказывать им о переходе и его причинах, собирать обратную связь - и не один раз, а на каждом этапе миграции. Коллеги часто помогают процессу и помогают выявить слабые места.
- Идти на уступки. На время перехода лучше снизить показатели KPI для сотрудников, чья работа завязана на работе в системе. Следует учитывать, что на адаптацию коллективу понадобится от одного до трех месяцев, поэтому несправедливо требовать от работников ту же скорость работы и абсолютную правильность оформления данных.
- Обучать и обеспечить консультационную поддержку. Совокупность вебинаров, пошаговых инструкций и видеоуроков позволит сотрудникам быстрее освоиться в биллинге и минимизировать критические ошибки в системе. В первые месяцы работы линия консультаций вендора должна быть доступна для любого работника. В пиковые периоды - закрытие месяца или квартала - можно договориться с поставщиком о дополнительной поддержке пользователей. Команда Forward Telecom всегда приоритезирует заявки от недавно перешедших в облако клиентов, чтобы помочь им в первую очередь.
К миграции нужно подходить осознанно и объективно оценивая риски, не преувеличивая их размеры. Мы знаем, что крупные компании после миграции получают улучшенную программу и спокойствие, а IT-директора перестают ночевать на работе, решая технические проблемы. И надеемся, что смогли убедить в этом вас.
