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

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

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

ОРГАНИЗАЦИЯ МОНИТОРИНГА

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

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

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

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

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

  • загрузку оборудования;
  • длительность выполнения операций пользователями, поскольку этот показатель не всегда коррелирует с загрузкой оборудования (например, нагрузка на SQL-сервер может быть низкой, но работа пользователей затруднена вследствие длительных задержек из-за проблем с каналами или конкретной рабочей станцией);
  • динамику инцидентов.

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

Объекты системного мониторинга
Объекты системного мониторинга

 

КОНТРОЛЬ ЗАГРУЗКИ ОБОРУДОВАНИЯ

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

Ключевое значение для достижения требуемой производительности имеет SQL-сервер. Основными контролируемыми показателями при мониторинге являются следующие:

  • Нагрузка на ЦПУ. Согласно рекомендациям Microsoft, значение этого показателя не должно превышать 80%. Если же постоянная нагрузка составляет 60–80%, необходимо либо оптимизировать процессы, либо менять оборудование.
  • Нагрузка на диски (IOPS). Microsoft рекомендует в качестве идеальных показателей отсутствие очереди на дисках и отработку запроса к диску не более чем за 25 мс. В конечном итоге от времени выполнения запроса зависит длительность осуществления операции с точки зрения пользователя.
  • Блокировки запросов. Они тоже оказывают влияние на длительность выполнения операций у пользователей.
  • Кеш планов запросов.
  • Время нахождения страницы в оперативной памяти.

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

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

Какие инструменты используются:

  • SCOM, Zabbix или аналоги;
  • счетчики Windows Server для контроля показателей сервера за длительный период и отслеживания их динамики;
  • инструменты SQL-сервера;
  • инструменты центра администрирования DIRECTUM для мониторинга служб.

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

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

КОНТРОЛЬ ДЛИТЕЛЬНОСТИ ОПЕРАЦИЙ

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

Инструменты мониторинга. Мониторинг осуществляется при помощи средств пользовательского профилирования (профайлинга), а также (частично) журнальных файлов системы, где фиксируется время выполнения конкретных операций. Затем информация по всем пользователям агрегируется и анализируется.

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

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

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

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

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

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

КОНТРОЛЬ ДИНАМИКИ ИНЦИДЕНТОВ

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

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

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

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

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

* * *

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

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

Купить номер с этой статьей в PDF