Облачный скачок: через тернии к успеху

Исследования и прогнозы в IT
Продолжим разговор про вопросы миграции на облачные платформы и тонкости, связанные с этим процессом. Ранее я уже упоминал о всех факторах, которые нужно учесть на стадии планирования и выполнения перехода. Сегодня настало время обсудить действия, которые необходимо предпринять непосредственно после миграции чтобы переход был максимально гладким и не вызвал неудобств у пользователей.

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

Этап №1 — Тест-драйв

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

Этап №2: — Мониторинг производительности

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

Во-первых, как тестеры они неэффективны. Во-вторых, такие занятия отнимают у работников ценное время, а у их родной компании деньги. Наблюдение за производительностью должно производиться специализированной системой мониторинга. Если ее нет в плане – добавьте ее.

Какие задачи должна выполнять система мониторинга?

Выявление проблем с архитектурой системы и течением информации в ней.

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

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

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

Потребление ресурсов: необходимо постоянно наблюдать за потреблением ресурсов облачными сервисами. Гибкость и масштабируемость облачной платформы также означают, что если код плохо оптимизирован, то в попытке достичь необходимой скорости работы, будут появляться все новые инстансы приложений, замедляя работу и уменьшая количество ресурсов, доступных другим приложениям. Мониторинг этих показателей поможет выявить наиболее ресурсоемкие приложения и помочь оптимизировать их работу. Таким образом по мере увеличения количества пользователей, эффективность работы приложений будет возрастать.

Этап №3: Эластичность как ключевое преимущество

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

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

Как всегда, инструменты мониторинга должны быть отзывчивы. Значительное время отклика и высокопроизводительные системы плохо сочетаются. Желательно также ввести несколько состояний – триггеров, которые бы санкционировали подключение новых ресурсов. Например, замедление передачи данных и увеличение количества запущенных инстансов приложений говорят о более серьезной нагрузке чем каждое из этих состояний поодиночке.

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

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn