Подписаться
Читать в телеграм
В первом случае ответственные за вышедший из строя участок технари корректируют его работу. Во втором случае нужно организовать совместную работу по устранению инцидента всех подразделений, обслуживающих бизнес-приложение. К сожалению, бывают ситуации, когда по результатам диагностики все сервисы работают штатно, но проблема для конечных пользователей по-прежнему налицо. Загвоздка именно в стыке, за нормальную работу которого зачастую не может поручиться никто.
При этом бизнес предъявляет к производительности приложений жесткие требования – каждый час простоя критичного «приклада» приводит к вполне ощутимым убыткам. Поэтому компаниям, для которых ИТ не являются профильным направлением бизнеса, целесообразно пользоваться услугами ИТ-аутсорсинга для наиболее критичных бизнес-процессов.
Рис. 1. Многослойная архитектура бизнес-приложения
Основные характеристики производительности приложения – среднее время выполнения пользовательских операций и доступность. Эти метрики очень важно настраивать, так как они позволяют своевременно обнаружить проблему и приступить к ее диагностике. Для повышения уровня доступности бизнес-приложения также необходим мониторинг всех его компонентов. Мы работаем по этому направлению много лет и выработали свои подходы. Для ряда операционных систем, средств резервного копирования, баз данных и т.д. мы разработали и применяем эталонные модели здоровья. Для наиболее критичных сервисов заказчиков мы настраиваем транзакционные метрики для мониторинга бизнес-приложений.
Мы также проводим аудит инфраструктуры, чтобы найти «узкие» места, и анализ архитектуры приложения, чтобы понять, удовлетворяет ли система предъявляемым к ней требованиям доступности. Это позволяет сформировать список прогнозируемых ошибок, которые могут негативно сказаться на работоспособности приложения, и заранее устранить их.
Наш подход иллюстрируют несколько характерных примеров, один из них – миграция основных бизнес-приложений одного из заказчиков. У него менялся как софт, так и весь вычислительный комплекс. К процессу миграции компания подошла основательно. Для сайзинга, разработки и сопровождения миграции бизнес-процессов были привлечены разработчики производителя софта. Мы спроектировали, внедрили и сейчас поддерживаем инфраструктуру для новых сервисов – от оборудования до приложения. По мере того как бизнес-приложения разворачивались в новом окружении, система мониторинга собирала все необходимые исторические данные.
Через месяц продуктивной работы от системы мониторинга поступил «тревожный звонок» о достижении первых порогов предупреждения заполнения файловых систем на новом оборудовании. Это было несколько неожиданно, так как сайзинг системы с учетом возможного роста был рассчитан на год. Еще через несколько недель стало понятно, что системы прибавляют не только в объеме. Требования к производительности аппаратного комплекса и системы хранения данных росли так же линейно, как и объем. И если с местом проблема еще решалась, то с производительностью все было не так просто. Таких нагрузок проектное решение, сформированное нами на основе сайзинга, не предполагало. Судя по тенденции роста нагрузки, полученной из системы мониторинга, к концу квартала можно было ожидать сильную деградацию производительности части бизнес-приложений вплоть до полной остановки сервиса. Проведенный нами экспресс-аудит СХД и базы данных позволил сформировать новое проектное решение, которое основывалось уже на реальных, а не на предполагаемых значениях. Систему модернизировали и в течение полугода мигрировали на оборудование другого класса.
Сейчас, когда от ввода в эксплуатацию нас отделяет 9 месяцев, мы понимаем, что только по объему при сайзинге системы вендор ошибся более десятка раз. Не последнюю роль здесь могло сыграть расширение филиальной сети заказчика. Важность мониторинга и своевременного планирования развития в данном случае сложно переоценить.
У другого нашего заказчика благодаря аудиту мы диагностировали негативно влияющие на производительность проблемы с оборудованием еще до ввода в эксплуатацию. За последние несколько лет его ИТ-инфраструктура выросла из нескольких стоек до нескольких серверных в разных ЦОД Москвы, не считая удаленных офисов и филиалов по стране. На очередном этапе модернизации компания расширила свою инфраструктуру на полтора десятка шасси и High-End массивов.
Когда часть оборудования планировали вводить в эксплуатацию, мы совместно с заказчиком решили при аудите по приемке новой системы провести нагрузочное тестирование СХД. Проектное решение предполагало использование на массивах гибридных пулов с несколькими уровнями хранения на FMD, SAS и SATA дисках. По расчетным данным, скорость IO должна была быть примерно как у самолёта. На практике самолёт взлетел, но «низенько». Причем скорость операций записи была еще приемлемой, а вот чтение оставляло желать лучшего. В результате тестирования мы пришли к выводу, что проблема воспроизводится на разных шасси одной модели, разных операционных системах, версиях FW (Firmware) оборудования. Аналогичные тесты на сервере другого вендора и той же СХД дали прекрасный результат. Таким образом, проблема была локализована, мы воспроизвели ее производителю СХД. Вместе с вендором мы выяснили, что из-за бага в FW лезвий операционные системы неэффективно использовали память и CPU для процессов операционной системы, что косвенно влияло на производительность IO.
Наиболее трудно диагностировать те проблемы, которые либо не воспроизводятся, либо имеют «плавающий» характер. Не так давно мы столкнулись с подобной на одном из проектов. В системе ERP, реализованной на SAP, часть запросов стала отрабатывать гораздо медленнее, чем раньше. Со стороны системы мониторинга проблем с оборудованием и его производительностью не наблюдалось. Нагрузка на СХД и серверы даже несколько снизилась. Первичная диагностика со стороны SAP проблем не выявила, было принято решение о комплексной проверке со стороны HW, ОС, СХД. Пока проверяли оборудование, проблема перестала воспроизводиться. Диагностику завершили, ошибки обнаружились только со стороны SAP при взаимодействии между компонентами ERP-системы. Как раз во время медленной работы приложения были зафиксированы ошибки «Communication error», которые заказчик интерпретировал как проблемы с сетью. При этом ошибки на интерфейсах сетевого и серверного оборудования отсутствовали, проблем в других системах из той же сети не было, и только часть новых запросов со стороны приложения работала медленно. Оставалось вооружиться tcpdump'ами, подготовить для сравнения всю диагностическую информацию и ждать воспроизведения сложившейся ситуации. Мы составили список первоочередных проверок, которые помогли бы выявить источник проблемы. Ждать пришлось недолго, через несколько дней ситуация повторилась. Первая же проверка показала отсутствие записей в DNS для одной из диалоговых инстанций в прямой зоне и для другой в обратной. После добавления заказчиком записей проблема ушла. Причины таинственного исчезновения записей из DNS и не менее загадочного их появления во время первого инцидента мы не установили, поскольку этот сервис поддерживался силами заказчика.
Таким образом, аудит, мониторинг и командная работа специалистов разных направлений позволяют нам как решать комплексные проблемы у заказчиков, так и в принципе предотвращать их появление.
