Как количественно и квалифицированно оценить преимущества облачной миграции

Совершенно очевидно, что будущее корпоративного бизнеса находится в облаке. Это особенно верно, если учесть, какую огромную роль облачная миграция сыграла в корпоративном пространстве всего за последние несколько лет:

Расходы на облачные вычисления с 2009 года выросли в 4,5 раза по сравнению с расходами на ИТ, и ожидается, что они вырастут более чем в 6 раз до 2020 года.

Обзор облачных вычислений Forbes

Это подтверждается последними данными Oracle, чей второй прогноз на 2019 год заключался в том, что 80 процентов всех корпоративных рабочих нагрузок, включая те, которые считаются «критически важными», будут перемещены в облако в течение следующих 12 месяцев.

Несмотря на почти повсеместное распространение облака на предприятии (и растущее знакомство с облачными технологиями для ИТ-специалистов и непрофессионалов), перенос рабочих процессов в облако - непростая задача. Это особенно верно, когда дело доходит до управления ожиданиями и фактического предоставления улучшений - независимо от того, связаны ли они с затратами или производительностью - после завершения миграции.

Чтобы команды не давали обещаний, которые они не могут выполнить, им нужна прозрачность на каждом этапе миграции в облако. В конце концов, « ты не можешь управлять тем, что не можешь измерить, Гласит старая мантра, и поэтому ИТ-команды должны иметь видимость на каждом этапе миграции, чтобы определять точные ожидания и опережать проблемы, прежде чем они сорвут все предприятие.

Определение приемлемых целей по производительности

Для начала командам необходимо полностью понимать, какие приложения, сетевая инфраструктура или процессы выходят из строя чаще всего. ИТ-специалистам, вероятно, потребуется межфункциональное собеседование, чтобы получить информацию и заинтересовать всю организацию.

Обосновать необходимость миграции в облако может быть легко, если ИТ-отделы думают в общих чертах. Несомненно, разгрузка обслуживания сетевого оборудования будет выглядеть привлекательной для лиц, принимающих решения с учетом бюджета, но сколько предварительных инвестиций необходимо, прежде чем бизнес сможет получить эту экономию?

Одной стоимости может быть недостаточно, чтобы соблазнить всех лиц, принимающих решения. Если миграция в облако повысит производительность нескольких приложений, которые считаются критически важными для бизнеса, будет ли это происходить за счет инструментов, используемых в других местах? Будет ли влиять на производительность приложения в процессе миграции и как долго? Требуется ли новое обучение для пользователей?

Команды должны разобраться во всех этих вопросах, прежде чем передавать свои предложения по миграции руководству. Это потребует от ИТ-специалистов серьезного осмысления текущего состояния сети, чтобы создать базовый уровень существующей производительности. Таким образом, команды могут подтвердить или проинформировать лиц, принимающих решения, о том, где больше всего необходимы улучшения, и поместить решение в контекст облака.

Базовая производительность перед миграцией

Опыт конечного пользователя - вот где все начинается. В конце концов, ИТ не добьется успеха, если конечный пользовательский опыт сотрудников не улучшится - или даже станет заметно хуже - после миграции в облако. Даже лица, принимающие решения, которые сосредоточены исключительно на чистой прибыли, согласятся с этим, поскольку плохой пользовательский опыт может иметь эффект домино на производительность более крупного бизнеса. Таким образом, ИТ-отделам необходимо сосредоточиться на «текущем состоянии» сети (наряду с удовлетворенностью пользователей), прежде чем какие-либо архитектуры будут исключены.

Для приложений это требует синтетического веб-тестирования, которое дает ИТ-специалистам местное видение того, что пользователи на самом деле испытывают в местах, где они работают, а также четкую видимость на всем пути доставки. Имея эту информацию под рукой, ИТ-отдел может установить «критерии приемки», которым они должны соответствовать во время и после облачная миграция, чтобы пользователи остались довольны. Некоторые примеры критериев могут выглядеть так:

• Время отклика должно быть в пределах 5 процентов от уровня до миграции.
• Уровень ошибок обслуживания должен быть равен или ниже уровней до миграции.
• Доступность приложения должна быть равна или ниже уровней до миграции.
• Затраты на инфраструктуру должны быть сокращены как минимум на X процентов в ходе миграции.

Таким образом, командам необходимо следить за скоростью доставки приложений пользователям, задержкой между серверами (внутренними и внешними, DNS и т. Д.), Частотой ошибок, типами ошибок и проблемами производительности конкретного браузера. Только имея все эти данные, ИТ-специалисты могут понять, в каком состоянии находится сеть перед миграцией.

Продолжать наблюдение на протяжении всего переноса

После того, как команды установили базовые параметры, важно, чтобы они продолжали следить за своими критериями приемлемости на протяжении всего процесса миграции. Команды должны иметь возможность создавать информационные панели и оповещения, которые могут указывать, когда сеть не соответствует критериям, в идеале с использованием тех же показателей, если не решения для мониторинга, которые они ссылались на базовую производительность.

• Время работы - Для облачных приложений ИТ-отделам следует ожидать, что время простоя будет ограничено минутами в течение любой недели. Большинство общедоступных приложений стремятся к 99,9% или выше (~ 7 минут в любую рабочую неделю).
• DNS - Для приложений, которые сейчас находятся в облаке, ИТ-отдел, вероятно, будет иметь локальный DNS-сервер или общедоступную службу DNS, предоставляющую IP-адрес. Это то, что следует активно отслеживать, поскольку это предотвратит соединения для всех пользователей в данном месте.
• Задержка, RTT - Теперь, когда услуги находятся за пределами центра обработки данных или вне офиса, может быть значительная разница во времени, которое требуется для передачи трафика от клиента к серверу. Пики здесь могут быть связаны с проблемами с локальной сетью, интернет-провайдером или приложением.
• Вместимость - Оплата пропускной способности от интернет-провайдера - это одно, но сквозная пропускная способность сети между местоположением пользователя и сервером приложений, вероятно, будет иметь другое узкое место. Это измерение позволяет ИТ-специалистам определять, когда перегрузка влияет на скорость соединения.

Скачки и скачки - полезные индикаторы ошибок, связанных с миграцией, которые необходимо устранять немедленно - даже до появления новых бизнес-запросов - чтобы остановить проблемы до того, как они начнут распространяться. Решая проблемы, ИТ-специалисты смотрят прямо на проблему, и команды с большей вероятностью найдут наиболее подходящее решение.

Используйте мониторинг для подтверждения успеха

Базовый план, который команды проводили перед миграцией, необходимо переделать для сравнения после того, как новая сетевая архитектура будет внедрена. Ключевым моментом здесь является использование тех же процессов (использование, шаблоны, время и т. Д.), Которые были протестированы в старой сети.

При всех миграциях в облако теряется определенный уровень контроля. Независимо от того, идет ли речь о «голом железе», уровне ОС или доступе, также важно, чтобы группы использовали современные решения для мониторинга, которые могут обеспечить такой же уровень видимости в новой сети, поддерживаемой облаком. Если инфраструктура больше не принадлежит ИТ-специалистам, уровень прозрачности старых инструментов мониторинга будет снижен. Это очень важно, поскольку многие решения для мониторинга не могут обеспечить видимость в облачных средах или даже за пределами ИТ-брандмауэров.

Без понимания проблем, выходящих за рамки брандмауэра, ИТ-специалистам сложно выявлять проблемы, связанные с инфраструктурой интернет-провайдеров или сторонних поставщиков, и быстро их решать. Это может задержать миграцию в процессе ее выполнения и вызвать у пользователей за пределами ИТ ностальгию по дням, предшествующим облачным технологиям, если производительность постоянно снижается.