Гарантировать технологическое качество информационной системы после развертывания информационной системы и обеспечение соответствия заявленным технологическим требованиям в процессе эксплуатации информационной системы.
Документ описывает общий подход к проведению нагрузочного тестирования и общие положения по организации тестовой инфраструктуры, исходя из предположения, что в дальнейшем тестовая инфраструктура может быть использована для целей обеспечения технологического качества, например, при переходе на новые версии информационной системы.
Под технологическим качеством информационной системы подразумевается:
Под проблемами качества работы системы подразумеваются проблемы доступности, стабильности, устойчивости, работоспособности и производительности информационной системы. Неполное соответствие функционала системы требованиям пользователей не является проблемой качества и не обсуждается в рамках данной методики.
В процессе эксплуатации информационной системы возможно изменение требований к информационной системе в связи с изменениями требований бизнеса, например, увеличение числа пользователей или изменение спектра решаемых информационной системой задач. В этом случае также требуется обеспечить технологическое качество работы системы в результате внесения любых изменений.
Под изменениями рабочей системы подразумеваются любые изменения программного, аппаратного, организационного или инфраструктурного уровней системы, включая, но не ограничиваясь, следующими изменениями:
Для учета изменений состояния системы вводится понятие «версия системы». Версией системы называется ее состояние в определенный момент времени. Публикацией версии называется ее запуск в рабочую эксплуатацию. Версия системы имеет уникальный номер и описание: дату публикации и перечень новых значений всех параметров системы, изменившихся по сравнению с предыдущей версией. Версии системы нумеруются по возрастанию – более поздние версии имеют большие номера.
Версии публикуются в соответствии с календарным планом после принятия решения о публикации версии. Решение о публикации версии должно приниматься с учетом технологических особенностей новой версии системы.
Внесение изменений в рабочую или тестовую систему вне процедуры публикации версии не допускается. Иначе говоря, любые изменения могут быть внесены только в одну из следующих запланированных версий (при этом все изменения заранее известны). После внесения изменений считается, что версия системы также изменилась.
Под гарантией технологического качества работы информационной системы подразумевается проверенный опытным путем и доказанный факт соответствия определенной версии информационной системы предъявленным технологическим требованиям в определенных условиях и профиле нагрузки. При изменении условий или версии системы невозможно гарантировать технологическое качество без проверки и проведения комплекса аналогичных испытаний. При проведении комплекса приемочных испытаний при каждом изменении версии появляется возможность контролировать не ухудшение технологических показателей даже при незначительных (на малом отрезке времени) отклонениях в технологических параметрах качества информационной системы.
Основные этапы организации проведения нагрузочного тестирования информационной системы включают, но не ограничиваются следующими этапами.
Все последующие этапы обязательно выполняются с учетом результатов предыдущих этапов. Указанные этапы не могут быть проведены параллельно либо в другом порядке. Параллельность выполнения работ может быть достигнута организационными мерами в рамках каждого из этапов.
Основной задачей этапа является сбор технологических требований и формулирование технического задания.
Технологические требования - это формализованное описание критериев технологического качества работы информационной системы. Могут быть включены (но не ограничиваются) все критерии технологического качества. Например, требование по устойчивости информационной системы может формулироваться как отсутствие аварийных завершений процессов кластера серверов в течение некоторого времени (например, в течение всего нагрузочного теста или 1 недели эксплуатации рабочей системы) и одинаковое устойчивое поведение при неизменных сценариях работы с информационной системой (другими словами, поведение системы не должно меняться при неизменном воздействии на систему).
Можно выделить следующие основные шаги этапа.
Профиль нагрузки - совокупность сценариев работы информационной системы, включающая нагрузку, создаваемую пользователями и механизмами интеграции информационной системы. Часто невозможно учесть все аспекты профиля нагрузки для сложных систем, так как чем сложнее система, тем больше времени будет затрачено на проектирование, программирование и поддержку адекватного профиля нагрузки для неё, что не всегда является необходимостью. Оптимальный подход в данном случае заключается в балансировании между стоимостью разработки теста и покрытием функциональности системы, в результате которого появляются допущения о влиянии на общую производительность той или иной части тестируемой системы. Например, оптимальным выбором может быть формирование 20% операций, создающих 80% нагрузки на информационную систему. Нужно также учитывать, что профиль может изменяться в зависимости от характера деятельности организации, поэтому, иногда допустимо будет выделение нескольких профилей, характерных, например, определенным периодам в деятельности организации.
Ключевая операция - такое действие в информационной системе, которое удовлетворяет следующим условиям:
Более подробную информацию по операциям и методике их оценки можно найти в статье Оценка интегральной производительности системы по методике APDEX.
Составление точных сценариев нагрузочного тестирования на этом этапе не всегда возможно, т.к. в процессе сбора требований может оказаться, что потребуется провести более полный анализ эталонной информационной системы. Тем не менее, в конце этого этапа мы должны точно понимать и уметь отвечать на вопросы:
Если информационная система уже существует требуется обязательно собрать информацию о текущем характере работы информационной системы. Если это сделать, появляется возможность обратить значительное внимание на технологические проблемы и устранить их на следующих этапах. Также при анализе текущей информационной системе можно заранее попытаться спрогнозировать узкие места при решении задач масштабирования или внесения изменений в версию информационной системы.
Можно выделить следующие основные шаги этапа.
Более подробная информация по анализу загруженности оборудования представлена в соответствующих статьях для Linux и Windows.
Встраивание подсистемы БСП ОценкаПроизводительности необходимо для того, чтобы оценить реальную частоту выполнения операций определенными пользователями и реальную производительность выполнения этих операций в рабочей системе. Без тщательного анализа будет неправильным считать, что все выявленные проблемы в рабочей системе обязательно воспроизведутся и на тестовой базе. По этой причине требуется получить не только оценку производительности, но и изменения производительности в зависимости от других факторов, например, нагрузки на систему или выполнения других операций в этот же период времени.
Анализ журнала регистрации позволит выявить операции, которые по каким-то причинам не были учтены в составлении сценария работы системы. Собственно по полученной оценке производительности и результатам анализа журналов (в т.ч. системных) появляется возможность уточнить требования к информационной системе, зафиксировать список проблем и сформирования более точные списки ключевых операций и сценариев нагрузки.
Можно выделить следующие основные шаги этапа.
Результатом этого этапа является подготовленная наполненная тестовыми данными информационная база с внедренной конфигурацией ТестЦентра и подготовленными тестовыми обработками.
Примером тестовой обработки является обработка ТЦШаблонТестовойОбработки, которая входит в состав конфигурации ТестЦентр. Необходимо подготовить столько обработок (по примеру ТЦШаблонТестовойОбработки), сколько различных операций планируется использовать при моделировании профиля нагрузки. Все обработки необходимо выполнить несколько раз и проверить, что они выполняются без ошибок.
Для каждой роли пользователя необходимо создать отдельную обработку по примеру ТЦОбработкаРоли (также входит в состав конфигурации ТестЦентр). Для этой роли необходимо указать все операции, которые будут выполняться выбранной ролью. Все обработки ролей также необходимо выполнить несколько раз подряд и убедиться, что они выполняются без ошибок.
Необходимо составить сценарий тестирования, заполнив соответствующие сценарии в подсистеме ТестЦентр. Сценарии должно в точности соответствовать формальному описанию сценариев в документах с требованиями к информационной системе.
Рекомендуется подготовить несколько сценариев:
Запуск проектного сценария с полноценной нагрузкой сразу может оказаться неудачным в виду несоответствия системы некоторым заранее сформулированным критериям. По этом причине рекомендуется сначала убедиться в соответствии системы технологическим требованиям в однопользовательском режиме, с минимальной нагрузкой, затем уже с половинной и полной нагрузкой. Такой подход позволит сэкономить усилия и время при расследовании и исправлении выявленных технологических проблем.
При подготовке сценариев следует всегда проверять, что все ключевые операции обязательно присутствуют сценарии нагрузочного тестирования.
Методика расчета параметров серверного оборудования изложена в статье.
В целом подход по использованию указанной методики сильно зависит от того, есть ли уже информационная система у клиента, и может ли она быть использована в качестве эталонной информационной системы для расчета параметров серверного оборудования.
Если информационная система уже существует, то требуется провести расчет требований к оборудованию на основании имеющейся статистики по загруженности оборудования с учетом новых профилей нагрузки
Если информационной системы ещё нет (или новые профили значительно отличаются от существующей нагрузки), требуется выполнить ряд шагов.
Все шаги подробно изложены в статье. В результате этого шага мы должны получить формализованные требования к серверному оборудованию, которое будет использоваться в нагрузочном тестировании. Также мы должны получить требования к оборудованию с нагрузчиками.
Следует учитывать, что в процессе выполнения работ по оптимизации информационной системы могут быть исправлены проблемы параллельной работы. Это в свою очередь приведет к увеличению параллельности работы (отсутствию очередей там, где раньше они были) и увеличению нагрузки на оборудование. Таким образом, в процессе нагрузочного тестирования скорее всего потребуется скорректировать параметры серверного оборудования. Заранее понять (без выполнения работ на нагрузочном тесте) объем изменений параметров серверного оборудования может оказаться практически невозможно (в зависимости от сложности системы).
Можно выделить следующие основные шаги этапа.
Развертывание и настройка оборудования - этап, требующий аккуратного конфигурирования тестовой среды с учетом требований к информационной системе. При использовании виртуализации потребуется жестко ограничить выделении ресурсов для всех серверных машин. В противном случае вы рискуете получить неповторяемый результат и очень большие отклонения результатов при повторении тестов и неизменности версии системы и условий. В результате правильной настройки влияние виртуальных машин друг на друга должно быть сведено к минимуму там, где это действительно необходимо. При настройке выделения ресурсов следует также учитывать архитектуру тестового оборудования с целью минимизации накладных расходов самой тестовой системы.
После развертывания оборудования, следует настроить сервер СУБД и кластер серверов 1С Предприятия так, как планируется для работы на рабочей системе. Если же рабочая эталонная система уже существует, может оказаться проще получить снимки виртуальных машин. В этом случае следует обеспокоиться получением и активацией лицензий, а также запрещением доступа с тестовой площадки "наружу" во избежании "случайных" рассылок, синхронизаций, писем и т.п. с тестовой системы (при настроенным аналогичных процедурах в рабочей системе).
После развертывания серверов и тестовой информационной базы может потребовать скорректировать подготовленные сценарии. Для этого вы можете воспользоваться обработкой ТЦПреобразованиеСценариев, которая входит в состав ТестЦентра.
Рекомендуется на этом этапе:
Этап обеспечения технологического качества информационной системы на тестовой площадке является центральным в процессе проведения нагрузочного тестирования. Собственно именно для получения качественного результата на этом этапе были проведены все предыдущие этапы.
Рекомендуется в первую очередь обеспечить технологическое качество при однопользовательском выполнении всех сценариев с контролем технологических требований
После обеспечения технологического качества при однопользовательской работе рекомендуется приступать к решению задачи при многопользовательском выполнении сценариев.
Рекомендуется приступать к решению проблем производительности в последнюю очередь, т.к. в результате устранения проблем избыточных блокировок и других проблем параллельной работы, например, взаимоблокировок, характер нагрузки и производительность могут сильно измениться. При выявлении проблем производительности, например, неоптимальной работы запросов следует убеждаться, что
Если требования не выполняются, то, возможно, заниматься в первую очередь оптимизацией именно этого найденного неоптимального запроса не стоит.
Результатом этого этапа является успешное прохождение всех подготовленных сценариев с обязательным соответствием всем технологическим требованиям.
Все изменения, выполненные в тестовой системе на предыдущем этапе необходимо обязательно проверить на нагрузочном тесте без изменения требований к информационной системе. Все выполненные и проверенные изменения должны быть зафиксированы с указанием того
В этом случае все изменения будут иметь проверенное на практике обоснование к применению их в будущем в рабочей системе. Требования к информационной системе формулируются с обязательным применением при внедрении рабочей информационной системы (в противном случае теряется смысл проведения работ по обеспечению качества на тестовой площадке).
Результатом этого этапа является документ, необходимый к применению в рабочей системе клиента, который содержит (для каждой проблемы):
Если рабочая система уже существует, то сформулированные требования формируются в check-list либо перечень доработок к предлагаемому решению.
Это обязательный этап, которым должно завершаться нагрузочное тестирование в случае отсутствия рабочей информационной системы. На этом этапе рабочая площадка клиента готовится в соответствие с требованиями, сформулированными на всех этапах выполненного нагрузочного тестирования. Нагрузочные тестирование не проводятся просто с целью «посмотреть и ничего не сделать», т.к. результат этого тестирования не возможно будет применить на практике. Даже в случае выявления проблем, их исправление всё же придётся проверить в тех же самых условиях (иначе как проверить, что проблема исправлена?)
Результатом этого этапа является применение всех сформулированных на предыдущем этапе требований.
Анализ представляет исследование по получению всех возможных сценариев работы с требуемыми профилями нагрузки с механизмами, реализованными в конфигурации.
В результате проведенного анализа и сбора данных получаем таблицу, в которой сведены
Ниже приведен пример сценария работы. На практике, такие сценарии могут быть достаточно большие (сотни строк и десятки ролей). Оптимальным подходом при формировании сценария может быть составление 20% операций, создающих 80% нагрузки на информационную систему. Не требуется приводить в сценарии все возможные использования всех операций в информационной системе, если их использование не вытекает из требований бизнеса клиента.
|
Роль |
Количество |
Операция |
Интенсивность (оп./час) |
оп./мес |
|---|---|---|---|---|
|
"Управление денежными средствами" |
10 |
Проведение документа «Платежное поручение входящее» |
4 |
485 |
|
Проведение документа «Платежное поручение исходящее» |
4 |
311 | ||
|
Проведение документа «Платежный ордер на списание денежных средств» |
1 |
35 | ||
|
Проведение документа «Расходный кассовый ордер» |
3 |
85 | ||
|
"Управление закупками" |
15 |
Открытие формы документа «Поступление товаров и услуг» |
30 |
988 |
|
Проведение документа «Поступление товаров и услуг» |
27 |
898 | ||
|
"Управление затратами" |
10 |
Проведение документа «Требование-накладная» |
10 |
750 |
|
Проведение документа «Реализация товаров и услуг» |
12 |
763 | ||
|
Проведение документа «Счет-фактура выданный» |
15 |
228 | ||
|
"Управление производством" |
10 |
Проведение документа «Акт об оказании производственных услуг» |
10 |
400 |
|
Проведение документа «Отчет производства за смену» |
1 |
19 |
Из полученных сценариев работы в системе необходимо выделить список ключевых операций, без которых выполнение ролей пользователей при работе с системой невозможно. Все полученные ключевые операции обязательно включены хотя бы один из сценариев.
Скорость и безошибочность выполнения этих операций будет контролироваться на протяжении всего нагрузочного теста.
Наличие ошибок при проведении нагрузочного тестирования равнозначно тому, что тестирование не было выполнено успешно.
Условия успешного выполнения нагрузочного теста могут быть сформулированы следующим образом:
Целью работ является достижение следующих значений показателей качества и устойчивости работы системы:
Коэффициент производительности вычисляется исходя из целевого времени, заданного для каждой ключевой операции (колонка Т таблицы, приведенной в разделе 3.2 настоящего Приложения) и времени выполнения ключевых операций при работе пользователей (в т.ч. виртуальных пользователей) с ИС
|
Ключевая операция |
Целевое время Т (сек.) |
|---|---|
|
Проведение документа «Платежное поручение входящее» |
1 |
|
Открытие формы документа «Поступление товаров и услуг» |
0,5 |
|
Проведение документа «Поступление товаров и услуг» |
2 |
|
Проведение документа «Отчет производства за смену» |
4 |
Методика подробно приведена в статье.
Устойчивость системы определяется количеством падений и зависаний кластера серверов 1С:Предприятия в единицу времени.
Падение кластера серверов 1С:Предприятия
Падением кластера серверов 1С:Предприятия называется самопроизвольная выгрузка любого процесса кластера серверов 1С:Предприятия или всех его процессов одновременно.
Зависание кластера серверов 1С:Предприятия
Зависанием кластера серверов 1С:Предприятия называется состояние кластера, при котором он не отвечает на запросы пользователей, не позволяет создать новое клиентское подключение и т.п., но при этом остается загруженным в память рабочего сервера.
Методика вычисления коэффициента устойчивости работы системы
Коэффициент устойчивости работы системы вычисляется за период времени равный одной календарной неделе.
Коэффициент устойчивости работы системы вычисляется по формуле (NС + NH)/7, где:
Для целей обеспечения технологического качества новых версий информационной системы создается постоянный тестовый стенд. Такая задача как правило появляется в тот момент, когда ведется непрерывная доработка информационной системы под нужды клиента. При этом у клиента нет желания тестировать на пользователях новые версии информационной системы из-за значительных рисков. В этом случае требуется проверять все изменения и гарантировать их технологически качественную работу (а также работу всей системы) до того, как эти изменения попадут в продукционную среду.
Тестовый стенд должен соответствовать (но не ограничивается этими требованиями) рабочей системе по следующим параметрам:
Тестовый стенд должен содержать полную копию рабочих информационных баз на момент начала разработки новой версии. Тестовый стенд следует организовать максимально близким по настройкам к продукционной среде.
При наличии такой тестовой системы сотрудники эксплуатирующей организации получают возможность проводить на тестовой версии ряд тестов, включая функциональные и нагрузочные (многопользовательские) тесты. Выполняются все тесты, которые выполнялись перед публикацией предыдущей версии. Тесты могут быть доработаны (расширены) по решению разработчиков 1С на основании анализа состава планируемых изменений, а так же проблем, возникших в рабочей системе за прошедшее время.
Предлагается следующая классификация серверов и зон при развертывании тестовой системы.
Для того, чтобы тестовые серверы со временем не превратились в серверы разработки (и, как следствие, не перестали решать свою задачу) необходимо:
Можно выделить следующие этапы организации тестового стенда.
Первым обязательным этапом организации тестового стенда является анализ схемы доступа к внутренним серверам продукционной площадки. Результатам анализа является документ, включающий в себя:
Необходимо решить, каким образом будут синхронизироваться данные с рабочей площадкой. Способ синхронизации будет определяться выбранной схемой резервирования и тем, как планируется использовать тестовый стенд.
Наиболее оптимальным с точки зрения затрат и решения конкретной задачи обеспечения качества изменений является еженочное восстановление backup-ов баз, снимков виртуальных машин на подготовительной площадке.
Такой подход дает следующие преимущества:
Горячее резервирование не рассматривается, т.к. в этом случае на площадке не получится полноценно проводить весь комплекс необходимых подготовительных работ, изменять конфигурацию компонент системы, менять версию платформы и т.д.
Развертывание холодной копии баз данных обязательно требует тренировки и проверки автоматическими средствами на наличие возможных проблем согласованности данных.
Для этих целей потребуется организация некоторых простых приемочных тестов для автоматизированной проверки подготовительной площадки на предмет её работоспособности сразу после синхронизации в ночное время.
Холодная копия виртуальных машин накатывается с одного из последних срезов, которые получаются средствами, например, Veeam или open-source. Такие срезы должны делаться на продукционной площадке с некоторой периодичностью, например, каждые 4 часа. Храниться при этом должны несколько копий срезов за достаточный для восстановления период времени в случае возникновения скрытых проблем (например, неделю).
Методика расчета параметров серверного оборудования подробно описана в статье и не является целью этого регламента.
Минимально можно выделить следующее оборудование, необходимое для организации подготовительной площадки для одной единицы масштабирования.
Требуется разделить доступ к тестовой и продукционной среде таким образом, чтобы максимально полно сохранить соответствие машин в тестовой среде машинам в продукционной среде. При миграции (развертывании) виртуальных машин в тестовой среде адресация машин не должна меняться. В этом случае поведение должно полностью быть схожим рабочей среде.
При организации адресации стоит учитывать, что с тестовой среды не должны приходить реальным пользователям какие-либо рассылки или оповещения. В этих целях рекомендуется закрывать доступ к интернет или другим ресурсам рабочей системы с тестовой среды.
Получение копий определяется тем, какая задача ставится при организации тестовой площадки. Вполне возможно рассматривать вопрос организации тестовой зоны также с целью некоторого резервирования. Получение копий будет различным для
Важным вопросом также будет являться, как будет организовано дублирование по ключам лицензий. Его необходимо заранее проработать именно для конкретной информационной системы, иначе имеется значительный риск блокировки лицензий в продукционной зоне.
На этом этапе необходимо точно решить, какие ключи будут использоваться (физические или программные), будут ли они дублировать друг друга, и будет ли эта же схема отражаться на подготовительной площадке.
Одним из вариантов получения копий является:
Восстановление подготовительной площадке соответственно происходит в обратном порядке:
Синхронизация с рабочей площадкой должна проходить в автоматическом режиме и не должна отличаться от механики восстановления данных на продукционной системе в случае аварии. По сути это является способом обеспечить проверку backup-ов на случай аварии и необходимого восстановления продукционной среды из backup-ов. Такая организация синхронизации с рабочей площадкой также обеспечивает максимальную схожесть по параметрам и настройкам тестовой среды и продукционной среды.
Для решения задачи "обеспечение качества рабочей системы при изменении версии" вводится правило: все изменения в рабочую систему вносятся через тестовую площадку. Сначала изменения попадают на тестовый стенд, затем на рабочий.
Существует только одно исключение из этого правила: изменения в рабочую систему могут вноситься, минуя тестовый стенд, только в период недоступности рабочего стенда по техническим причинам, только в экстренных случаях. В таких случаях требуется проводить дополнительную синхронизацию тестовой и продукционной площадки или отражение примененных изменений в ручном режиме. Изменяться состояние тестового стенда может следующими способами:
Изменяться состояние рабочего стенда может следующими способами:
Check-лист готовится заранее при выполнении изменений на подготовительном стенде.
Перед применением изменений на рабочей площадке check-листы распечатываются и передаются каждому участнику плановых работ.
Синхронизация участников выполняется оперативно по телефону, чату.
Журнал регистрации проведенных работ – специальный документ, который ведут все участники эксплуатации рабочий и подготовительной системы. В такой журнал попадают записи, отражающие все изменения в очень сжатой форме. Цель журнала – в случае аварии быстро определить, кто, когда вносил критичные изменения, и какие именно изменения были.
2015-01-01 Администратор1 <admin_example@1c.ru> +79871234567
* server-1c-prod-1
- поправил com connector, выполнив команду из rdp сеанса C:\1C\current\regsvr32 comcntr.dll
Во время проведения тестирования контролируются показатели технологического качества работы системы на соответствие их технологическим требованиям и сравниваются с аналогичными показателями, полученными при тестировании предыдущей версии. Если показатели новой версии ухудшились по сравнению с предыдущей версией, то принимается согласованное решение о дальнейших действиях. Ответственные за эксплуатацию информационной системы договариваются либо отложить выпуск до исправления проблем качества, либо опубликовать версию, не смотря на наличие проблем.
После исправления проблемы необходимо провести повторное контрольное тестирование.
Версия, успешно прошедшая тестирование, публикуется в рабочей системе в соответствии с планом публикации версий. Версия, не прошедшая процедуру тестирования не может быть опубликована.
Группа эксплуатации ведет постоянный контроль качества рабочей системы. Если какие-либо показатели качества работы текущей версии оказываются хуже, чем у предыдущей версии, то принимается согласованное решение об устранении проблемы. Участники эксплуатации договариваются либо об отказе использования текущей версии и откате на предыдущую версию, либо о продолжении работы не смотря на существующие проблемы.
При выявлении проблем в рабочей системе может быть принято решение о доработке тестов таким образом, чтобы в следующий раз подобная ошибка была выявлена на стадии тестирования на тестовых стендах, а не в продукционной среде.