Системный мониторинг: сопровождаем СЭД проактивно

Алексей Корепанов, руководитель проектов внедрения DIRECTUM

Особенности сопровождения СЭД у крупных заказчиков

После внедрения системы электронного документооборота (СЭД) процессы в компании продолжают развиваться и адаптироваться под меняющееся окружение. В предыдущем материале мы рассмотрели общие принципы сопровождения СЭД в крупной компании.

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

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

Организация мониторинга

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

Верхний уровень мониторинга предполагает контроль внедрения в СЭД новых процессов.

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

Дальнейшее развитие СЭД потребует от нас мониторинга нагрузки на оборудование. На верхнем уровне мы контролируем, позволит ли имеющееся «железо» внедрить новые процессы. Если показатели загрузки начинают достигать 60-80%, то без обновления оборудования новые задачи будет невозможно автоматизировать, так как возникает риск неработоспособности уже внедренных процессов и остановки системы.

В идеальном случае этот сценарий нужно учесть еще на нулевом этапе внедрения и развития системы. Нагрузку на оборудование рекомендуется указывать в плане внедрения новых процессов на 1-3-5 лет (или аналогичном документе).

На следующем уровне системного мониторинга необходимо отслеживать текущие процессы:

●   загрузку оборудования;

●   длительность выполнения операций у пользователей, поскольку она не всегда коррелирует с загрузкой оборудования (Например, нагрузка на SQL-сервер может быть низкой, но есть проблема с каналами или конкретной рабочей станцией, влияющая на быстродействие);

●   динамику инцидентов.

Рассмотрим каждый из них более подробно.

Контроль загрузки оборудования

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

С точки зрения производительности, ключевым элементом здесь является SQL-сервер. Основными показателями мониторинга являются:

o    Нагрузка на CPU. По рекомендациям Microsoft, ее значение не должно превышать 80%. Если же постоянная нагрузка держится на уровне 60-80%, необходимо либо оптимизировать процессы, либо менять оборудование.

o    Нагрузка на диски (IOPS). Microsoft рекомендует в качестве идеальных показателей отсутствие очереди на дисках и длительность отработки запроса к диску не более 25 миллисекунд. Время выполнения запроса в конечном итоге влияет на выполнение операции у пользователя.

o    Блокировки запросов, которые также влияют на длительность выполнения операций у пользователей.

o    Кэш планов запросов.

o    Время жизни страницы в оперативной памяти.

Другие показатели уже не так явно влияют на длительность выполнения операций и не так быстро изменяются – их мы анализируем реже.

При организации мониторинга серверной части важно не забыть о «слоне» – о работоспособности сервисных служб. Если обращаться к примеру DIRECTUM, то здесь используется множество служб сервисов: сервис интеграции (DISI), сервис захвата и преобразования (DCTS), workflow, сервер сеансов; SQL-сервер в данном контексте тоже является службой. Рекомендуется отслеживать работу всех служб, которые используются в системе.  

Инструменты мониторинга:

●   SCOM, Zabbix или аналоги;

●   счетчики Windows Server для контроля показателей сервера в долгосрочном периоде и отслеживания динамики;

●   инструменты SQL-сервера;

●   инструменты Центра администрирования DIRECTUM для мониторинга служб.

Периодичность контроля:

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

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

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

Контроль длительности операций

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

Инструменты мониторинга

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

Классификация информации и анализ

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

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

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

В профайлинге также есть информация о работе служб DIRECTUM. Отклонения по длительности выполнения операций службами могут помочь выявить ошибки в прикладной разработке и оптимизировать работу службы.

Периодичность контроля

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

Контроль динамики инцидентов

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

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

На этапе сопровождения системы в службу Service Desk поступают обращения пользователей. Здесь отслеживается два направления:

●   Обращения, связанные с длительностью операций. Эта информация анализируется вместе с результатами профайлинга;

●   Непосредственно инциденты. Здесь мы также вычисляем средние значения их количества (в день) для сравнения с целевым показателем. Если в ходе развития СЭД мы отмечаем рост числа инцидентов по одной компоненте или бизнес-процессу, значит, последние доработки могли оказать негативное влияние, и нужно оптимизировать работу системы.

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

* * *

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

Источник: Журнал LAN