zabika.ru 1

Первое обобщение результатов

Терминология



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

  2. Тестированиепроцесс проверки работоспособности системы в определенном окружении. В данном документе предполагается, что тестирование состоит в исполнении набора сценариев и сопоставлении состояния системы после исполнения каждого сценария с ожидаемым состоянием.

  3. Событие – информация, поступающая от объектов мониторинга (объем данных не ограничен, время сбора данных также не ограничено)

  4. Результаты тестирования – список описаний, соответствующий этапам исполнения тестового сценария (список поступает целиком или постепенно, но время сбора результатов ограничено)

  5. Штатные данные – это данные об успешном выполнении определенных действий системы

  6. Нештатные данные – это данные об безуспешном выполнении определенных действий системы

  7. Непрерывная работа – постоянная готовность к выполнению каких-либо действий (например, готовность зарегистрировать событие)

  8. Работа по расписанию – готовность к выполнению каких-либо действий в случае наступления определенного момента времени

Проблематика


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

С одной стороны, тестирование распределенного приложения намного сложнее, чем не распределённого. Это вызвано целым рядом причин: часто необходима сложная инфраструктура для работы такого приложения; не все компоненты могут находиться под контролем разработчиков; затруднено применение отладчиков, количество состояний, в которых может находиться система гораздо больше, чем в случае не распределённой системы, практически всегда предполагается применение параллельного программирования.


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

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

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

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

Что «это»


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

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

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

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


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

  6. Возможность оповещения разработчиков о нештатных событиях

  7. Возможность удобного поиска событий в протоколе.

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

  9. Возможность выполнения набора тестов по расписанию

  10. Возможность удалённого администрирования и использования

На данном этапе предполагается, что такая система должна быть пригодна для использования в Enterprise Java-приложениях.

Зачем «это» нужно


Такая система позволит внедрить более совершенный процесс обеспечения качества распределенного ПО. Основными выигрышами от применения такого процесса и системы будут следующие:

  1. Уменьшения доли ошибок развёртывания (неправильной конфигурации) в общей совокупности ошибок, связанных с работой распределённого ПО.

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

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

  4. Уменьшение времени реакции разработчиков на сообщения об отказах.

Требования к «этому»

Общие требования к подсистеме тестирования




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

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


  3. Тестовый сценарий должен быть редактируемым разработчиками (тестовый файл, XML, скрипт..)

  4. Отдельные тестовые воздействия (составные части сценария) могут представлять собой процедуры, выполненные на языке программирования.

  5. Исполнение тестовых сценариев должно быть возможно производить от имени определенного пользователя. (Интеграция со встроенной системой безопасности)

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

  7. Исполнение тестовых сценариев в тестовом окружении может выполняться автоматически (периодически).

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



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

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


  4. Система должна позволять изменять интенсивность протоколирования событий (verbosity, log level) для каждого компонента распределенного приложения отдельно.

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

  6. Кэш событий в каждом из компонентов распределенного приложения должен иметь фиксированный (настраиваемый размер). Если в кэше больше нет места и ядро системы не готово принять содержимое кэша, то самое старое событие удаляется из кэша и вместо него записывается новое. При этом фиксируется время в течение которого произошедшие события вытеснялись из кэша новыми событиями.

  7. Система мониторинга должна иметь возможность регистрации в каждом компоненте распределенного приложения системы счётчиков. Например, для такого компонента, как web-сервер, может быть полезен такой счётчик, как время выполнения клиентского запроса (среднее, максимальное,...)

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

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

  10. Система мониторинга не имеет прямой связи с системой тестирования. Т.е. Она может быть развёрнута независимо от того, имеется ли потребность тестирования в данной инсталляции системы.
Общие требования к системе

  1. Система должна предоставлять интерфейсы для удалённой работы с ней.
  2. При реализации системы, приоритет должен отдаваться стандартным решениям, протоколам, компонентам.


  3. Система должна быть пригодна для интегрирования в широкий класс разрабатываемых приложений.

  4. Система по возможности не должна содержать закрытые и/или коммерческие компоненты внешних поставщиков


Существующие решения


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

В данном сравнительном анализе были рассмотрены 4 системы (IBM ACTK (только Log & Trace Analyzer в силу отсутствия доступа к другим компонентам ACTK), MS AsmL, Apache Continuum и JUnit/JUnit EE).

Обоснование выбора данных систем состоит в следующем.

IBM ACTK — наиболее известная система мониторинга и анализа функционирования распределенных систем, предназначенная для разработки средств автоматизации администрирования крупных программно-аппаратных комплексов.

MS AsmL — специфическая разработка корпорации Microsoft в области тестирования программных компонентов, отличающаяся от типичных способов автоматического тестирования (Unit-тестирвоание) возможностью построения модели исполняемой программы.

JUnit/JUnit EE — Де-факто индустриальный стандарт в области автоматического модульного тестирования для платформы Java.

Apache Continuum — Система обеспечения постоянной готовности последних сборок и их автоматического тестирования для платформы Java.

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


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

Приведем сравнительные таблицы.








Ограничения масштаба разрабатываемого решения


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

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

Конфигурация системы


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

Возможности повторного использования


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

Повторное использование возможно на нескольких уровнях. Во-первых, это подходы к решению определённых задач. Например, архитектурные решения, использованные в ACTK представляются весьма перспективными. Более того, скорее всего это единственный путь создания в определённом смысле горизонтального решения проблемы управления отказами (хотя бы в классе систем, основанных на платформе Java). Во-вторых, это повторное использование стандартных протоколов и форматов. Представляется целесообразным использование web-интерфейса (возможно с модификациями) системы постоянных сборок Apache Continuum, а также XML-формата событий CBE, который активно применяется в ACTK (Log & Trace Analyzer). Представляется критически важным, чтобы основными языками тестовых сценариев были форматы систем автоматической сборки Ant/Maven. Это необходимо, чтобы задействовать возможности автоматического тестирования, основанные на JUnit/JUnitEE. Естественно, что эти форматы также хорошо понятны и известны широкому кругу разработчиков.


Во-можно также повторное использование множества готовых компонентов. Таких как, например, СУБД, библиотеки компонентов JSF (например, IceFaces), библиотеки работы с электронной почты (JavaMail) и системами обмена мгновенными сообщениями (Snack). Также предполагается использовать Apache Tomcat 6, как основу для развёртывания компонентов разрабатываемого приложения, т.к. Tomcat является стандартным и широко применяемым продуктом, в т.ч. в таких серверах приложений, как SJAS, JBoss и другие. Возможно также использовать встраиваемые БД, такие как Berkeley DB JE, для ведения локальных журналов различными компонентами.

План работ


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

  1. До конца июня описать архитектуру системы (UML). Подобрать и изучить компоненты, использование которых представляется разумным.

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

  3. В течение сентября-декабря реализация основной функциональности системы.

  4. Январь-май 2009г. — испытания, пробное внедрение, подготовка подробной документации, презентация системы на конференции M$ и МНСК. Подготовить статью в реферируемое издание. Возможно потребуется какое-то время на освоение TeX.