Вход |  Регистрация

Все Тэги

Уроки из китайского инцидента

11.03.2014243 просм.

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

В первом посте мы проанализировали причины и последствия масштабного инцидента с доступностью Интернета в Китае.

Сегодня мы остановимся на основных уроках, которые можно извлечь, и рассмотрим конкретные рекомендации.

Какие уроки можно извлечь

Естественно, возникает вопрос – а что все-таки можно сделать на практике для улучшения защиты и поддержки производительности веб-приложений и сервисов в нашу эру увеличивающей взаимозависимости?

1. Как получать объективную информацию о доступности приложения?

Восприятие конечного пользователя является единственным надежным критерием, по которому можно оценивать производительность всех элементов, которые находятся между дата-центром и конечными пользователями и влияют на производительность, такие как облако, сети доставки контента (CDN), Интернет-провайдеры, мобильные устройства и браузеры. Мы уже рассказывали об APM-инструментах нового поколения, у которых есть необходимый функционал.

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

2. Как выбирать сторонние сервисы для интеграции в приложение и мониторить их работоспособность?

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

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

3. Как обеспечить работоспособность бизнеса на случай недоступности сторонних сервисов?

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

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

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

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

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

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

5. Как отслеживать всю географию, где используется приложение?

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

Необходимо наладить использование имеющихся бесплатных сервисов (например, http://www.akamai.com/html/technology/dataviz1.html или https://www.outageanalyzer.com/), которые отслеживают инциденты известных поставщиков услуг, и какие регионы затронуты. Подобные сервисы, конечно, не помогут избежать подобных инцидентов, но как минимум дают организациям информацию о том, что проблема не на их стороне, и позволяет оперативно сконцентрировать усилия на приведении в жизнь планов непрерывности бизнеса и проактивном уведомлении пользователей о случившемся.

Заключение

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

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

Метки: , , ,

Добавить комментарий

Для отправки комментария вам необходимо авторизоваться.

Партнеры DevOpsHub и DevOpsWiki