«Болевые точки» контроля доступности приложений

08.09.2015 | Ровнов Павел
Want create site? Find Free WordPress Themes and plugins.

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

История отказа сервера рассылки сообщений

История началась с обращений клиентов приложения «Клиент-Банк» одного банка в службу поддержки. Клиенты сообщали о невозможности отправки корреспонденции в сторону банка. Для проверки доступности сервера рассылки сообщений (SMTP-сервера) администратор приложения вручную выполнил несколько пробных SMTP-запросов и тем самым определил, что подключение к серверу устанавливается с задержкой ~20 секунд – время от TCP SYN до получения «SMTP 220 Service ready». Поскольку таймаут установления соединения с сервером, в соответствии с конфигурацией клиента, составлял 10 секунд, клиент не дожидался ответа сервера и разрывал соединение.
В течение следующих нескольких часов администратором были последовательно выполнены проверки состояния вычислительных ресурсов SMTP-сервера, сетевых устройств, СЗИ и каналов связи с «внешним миром»… Каждая новая проверка давала все больше информации о текущем состоянии отдельных сетевых элементов, но никаких намеков на возможную причину проблемы. Еще более запутанной ситуацию делал тот факт, что часть клиентов никаких проблем при работе с приложением не испытывала.
Как выяснилось позже, причина проблемы была в том, что ни один из DNS-серверов, являющихся вспомогательными для сервера рассылки сообщений, не был доступен. В момент установления соединения с клиентом сервер рассылки сообщений запрашивал у DNS-сервера домен-источник письма. Таймаут ожидания ответа от DNS-сервера, как можно догадаться, составлял 20 секунд. Таким образом, клиенты, домены которых были известны SMTP-серверу (находились в кэше), обслуживались мгновенно, остальные же были вынуждены ожидать таймаута ответа от DNS-сервера.
Что касается самих DNS-серверов, то один из серверов, указанных в настройках сервера рассылки, был давно выведен из эксплуатации, а с резервным сервером была нарушена связность на уровне приложения.
После того, как причина отказа была установлена, было решено переконфигурировать сервер рассылки сообщений для использования новой пары DNS-серверов. И проблема обслуживания клиентов была решена.

С моей точки зрения, основными «болевыми точками» контроля доступности приложения в описанной истории являются:
1) сбор данных;
2) анализ данных и компетенции.
Рассмотрим «болевые точки» по очереди.
Сбор данных. Стоит отметить, что значительная часть времени, которое было затрачено на выявление причины отказа, ушло именно на ручной сбор данных о состоянии приложения в целом и формирующих его элементах. В отдельных случаях доступ к журналам событий требовалось запрашивать у других администраторов, что также отнимало время.
Очевидное решение – это сбор данных централизованной системой мониторинга функционирования приложений. В этом случае, во-первых, в момент, когда на счету каждая минута, данные уже собраны и нужно лишь осуществить поиск по ним (а-ля big data), во-вторых, администратору может быть предоставлен доступ к информации о событиях всей инфраструктуры в целом, а не отдельных элементов.
Анализ данных и компетенции. Из каких элементов сформировано приложение? Как связаны эти элементы между собой? Какие условия должны быть выполнены для того, чтобы приложение функционировало? Все эти вопросы требуют экспертизы, которой, возможно, обладает разработчик информационной системы, но не администратор приложения.
Одним из возможных подходов к решению проблемы может быть компенсация фактора людей и их компетенций (триада факторов «people», «process» и «technology») за счет технологий. На этапе ввода информационной системы в действие могут быть идентифицированы и описаны все компоненты приложения, их взаимосвязи и зависимости, которые впоследствии могут быть транслированы в правила обработки событий системой мониторинга. Фактически экспертиза, скрытая в правилах обработки событий, позволяет снизить каждодневную нагрузку на администратора, задачей которого становится лишь реагирование на инциденты.

Надеюсь, рассказанная мной история и ее анализ помогут не наступить на известные грабли при обеспечении доступности приложений.
А какие «болевые точки» контроля доступности приложений приходят на ум Вам? Оставляйте ваши комментарии ниже.

Did you find apk for android? You can find new Free Android Games and apps.
Комментариев пока нет
Добавить комментарий