phone +7 (495) 66 014 66

× Общий раздел

Проведение нагрузочного тестирования

4 года 8 мес. назад #4943 от Дмитрий
Проведение нагрузочного тестирования

Краткое содержание:

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

Цель проведения нагрузочного тестирования

Гарантировать технологическое качество информационной системы после развертывания информационной системы и обеспечение соответствия заявленным технологическим требованиям в процессе эксплуатации информационной системы.

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

Основные положения

Под технологическим качеством информационной системы подразумевается:
1. Доступность
2. Стабильность
3. Устойчивость
4. Работоспособность
5. Производительность
6. Масштабируемость
7. Не ухудшение технологических показателей при внесении изменений в информационную систему

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

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

Под изменениями рабочей системы подразумеваются любые изменения программного, аппаратного, организационного или инфраструктурного уровней системы, включая, но не ограничиваясь, следующими изменениями:
1. Любые изменения кода конфигурации системы (в том числе связанные с доработками функционала или исправлением ошибок)
2. Изменения версии 1С:Предприятия, настроек кластера 1С:Предприятия, настроек информационной базы
3. Изменения типа СУБД, версии СУБД, настроек СУБД
4. Изменение состава, технических характеристик или настроек оборудования или ОС любого сервера, участвующего в работе системы сервер СУБД и рабочие сервера кластера 1С:Предприятия.
5. Расширение состава операций, выполняемых пользователями системы
6. Значительное увеличение количества пользователей системы

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

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

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

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

Основные этапы организации нагрузочного тестирования

Основные этапы организации проведения нагрузочного тестирования информационной системы включают, но не ограничиваются следующими этапами.
1. Сбор требований
2. Анализ текущей ситуации, если эталонная информационная система уже существует
3. Подготовка тестовой системы
4. Расчет требований к оборудованию
5. Подготовка тестовой среды
6. Обеспечение технологического качества ИС на тестовой площадке
7. Формирование технологических требований и изменений по результатам проведенного нагрузочного тестирования
8. Переход к этапу внедрения информационной системы в рабочую зону

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

Сбор требований

Основной задачей этапа является сбор технологических требований и формулирование технического задания.

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

Можно выделить следующие основные шаги этапа.
1. Получение информации о требованиях к информационной системе
2. Формулирование технологических требований
3. Формулирование основных профилей нагрузки
4. Формирование списка ключевых операций
5. Составление сценариев нагрузочного тестирования
6. Согласование требований для выбранных сценариев

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

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

Составление точных сценариев нагрузочного тестирования на этом этапе не всегда возможно, т.к. в процессе сбора требований может оказаться, что потребуется провести более полный анализ эталонной информационной системы. Тем не менее, в конце этого этапа мы должны точно понимать и уметь отвечать на вопросы:
• Какая версия технологической платформы будет использоваться?
• Какая СУБД (и версия СУБД) будет использоваться?
• Какое число пользователей будет в пике работать в информационных базах системы?
• Какие блоки операций (по-крупному) будут выполняться пользователями?
• Будет ли изменяться характер нагрузки на информационную систему в зависимости от периода?
• Имеются ли лицензии в достаточном количестве для обеспечения работы пользователей?
• Имеется ли серверное оборудования, которое возможно использовать для работы с информационной системой?
• Будет ли значительно изменяться версия информационной системы? Ведется ли разработка сейчас? Существует ли календарный план?
• Какие технологические требования предъявляются к новой информационной системе?
• Какие сроки возможны?

Анализ текущей ситуации, если эталонная информационная система уже существует

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

Можно выделить следующие основные шаги этапа.
1. Встраивание подсистемы БСП ОценкаПроизводительности
2. Анализ журнала регистрации
3. Анализ статистики работы реальных пользователей в информационной системе
4. Уточнение сценариев и профилей нагрузки
5. Анализ загруженности оборудования с текущими профилями
6. Выявление технологических проблем, которые могут оказать влияние на качество работы

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

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

Подготовка тестовой системы

Можно выделить следующие основные шаги этапа.
1. Подготовка информационной базы
a. Встраивание ТестЦентра (конфигурация ТестЦентр входит в пакете КИП)
b. Встраивание подсистемы БСП ОценкаПроизводительности
c. Создание ролевой структуры с учетом профилей нагрузки (фиксируем основные роли пользователей информационной системы).
d. Все роли из сценариев обязательно должны быть реализованы в информационной базе (требуется проверить и убедиться в этом).
e. Наполнение базы тестовыми данными в объеме на момент внедрения информационной системы плюс несколько месяцев работы
2. Написание тестовых обработок
3. Проверка корректности выполнения тестовых обработок
4. Подготовка ролевого наполнения тестовыми обработками
5. Подготовка сценария нагрузочного тестирования.

Результатом этого этапа является подготовленная наполненная тестовыми данными информационная база с внедренной конфигурацией ТестЦентра и подготовленными тестовыми обработками.

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

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

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

Расчет требований к оборудованию

Методика расчета параметров серверного оборудования изложена в статье.

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

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

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

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

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

Подготовка тестовой среды

Можно выделить следующие основные шаги этапа.
1. Развертывание и настройка оборудования
a. Оборудование настраивается с учетом полученных требований
2. Настройка среды виртуализации
a. При необходимости
b. С учетом архитектуры оборудования
3. Настройка СУБД
4. Настройка кластера серверов 1С
a. В том числе и отказоустойчивого кластера серверов
5. Развертывание подготовленной информационной базы
6. Настройка веб серверов (если они используются в информационной системе).
7. Настройка нагрузчиков
a. Собственно, серверы, с которых будет генерироваться тестовая нагрузка на информационную систему

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

После развертывания оборудования, следует настроить сервер СУБД и кластер серверов 1С Предприятия так, как планируется для работы на рабочей системе. Если же рабочая эталонная система уже существует, может оказаться проще получить снимки виртуальных машин. В этом случае следует обеспокоиться получением и активацией лицензий, а также запрещением доступа с тестовой площадки "наружу" во избежании "случайных" рассылок, синхронизаций, писем и т.п. с тестовой системы (при настроенным аналогичных процедурах в рабочей системе).
После развертывания серверов и тестовой информационной базы может потребовать скорректировать подготовленные сценарии. Для этого вы можете воспользоваться обработкой ТЦПреобразованиеСценариев, которая входит в состав ТестЦентра.

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

Обеспечение технологического качества ИС на тестовой площадке

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

1. Выявление и устранение проблем стабильности
2. Выявление и устранение проблем работоспособности
3. Выявление и устранение проблем производительности

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

1. Поэтапное увеличение нагрузки до требуемого уровня
2. Тестирование в течение длительного времени
3. Контроль технологических параметров информационной системы на всем протяжении тестирования
4. Выявление и устранение проблем стабильности
5. Выявление и устранение проблем работоспособности
6. Выявление и устранение проблем производительности

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

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

Формирование технологических требований и изменений по результатам проведенного нагрузочного тестирования

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

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

Результатом этого этапа является документ, необходимый к применению в рабочей системе клиента, который содержит (для каждой проблемы):
1. описание проблемы (симптом)
2. описание того, как можно зафиксировать проблему (проверить наличие этой проблемы)
3. изменения
4. оценку, как было до исправления
5. оценку, как стало после исправления
6. трудозатраты в тестовой зоне по исправлению проблемы

Если рабочая система уже существует, то сформулированные требования формируются в check-list либо перечень доработок к предлагаемому решению.

Переход к этапу внедрения информационной системы в рабочую зону


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

Результатом этого этапа является применение всех сформулированных на предыдущем этапе требований.

Анализ пользовательских сценариев работы

Анализ представляет исследование по получению всех возможных сценариев работы с требуемыми профилями нагрузки с механизмами, реализованными в конфигурации.

В результате проведенного анализа и сбора данных получаем таблицу, в которой сведены
• Роль – название роли пользователя
• Количество – это количество пользователей данной роли
• Операция – название ключевой операции из таблицы Apdex, которую выполняет пользователь
• Интенсивность – количество выполнений данной операции в единицу времени

Ниже приведен пример сценария работы. На практике, такие сценарии могут быть достаточно большие (сотни строк и десятки ролей). Оптимальным подходом при формировании сценария может быть составление 20% операций, создающих 80% нагрузки на информационную систему. Не требуется приводить в сценарии все возможные использования всех операций в информационной системе, если их использование не вытекает из требований бизнеса клиента.
РольКоличествоОперацияИнтенсивность (оп./час)оп./мес
"Управление денежными средствами"10Проведение документа «Платежное поручение входящее»4485
Проведение документа «Платежное поручение исходящее»4311
Проведение документа «Платежный ордер на списание денежных средств»135
Проведение документа «Расходный кассовый ордер»385
"Управление закупками"15Открытие формы документа «Поступление товаров и услуг»30988
Проведение документа «Поступление товаров и услуг»27898
"Управление затратами"10Проведение документа «Требование-накладная»10750
Проведение документа «Реализация товаров и услуг»12763
Проведение документа «Счет-фактура выданный»15228
"Управление производством"10Проведение документа «Акт об оказании производственных услуг»10400
Проведение документа «Отчет производства за смену»119

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

Условия успешного выполнения нагрузочного теста


Целевое качество работы ИС

Условия успешного выполнения нагрузочного теста могут быть сформулированы следующим образом:
1. Отсутствие ошибок стабильности (система ведет себя стабильно и предсказуемо)
a. информационная система в течение всего теста соответствует требуемому коэффициенту устойчивости работы
2. Отсутствие ошибок работоспособности (система решает поставленные задачи при заданном характере нагрузки)
a. информационная система в течение всего теста соответствует требуемому коэффициенту устойчивости работы
3. Отсутствие проблем производительности (скорость реакции системы определяется поставленными технологическими требованиями)
a. хороший или отличный Apdex по всем ключевым операциям
b. информационная система в течение всего теста соответствует требуемому коэффициенту производительности
4. Информационная система соответствует всем сформулированным требованиям на момент начала испытаний.
Целью работ является достижение следующих значений показателей качества и устойчивости работы системы:
1. Коэффициент производительности не ниже 0.85 по всем ключевым операциям в течение всего нагрузочного теста на каждом из выбранных профилей нагрузки при условии соблюдения всех согласованных технологических требований.
2. Коэффициент устойчивости работы системы не выше 0, что соответствует отсутствию падений или зависаний кластера серверов 1С:Предприятия в течение всего нагрузочного теста на каждом из выбранных профилей нагрузки при условии соблюдения всех согласованных технологических требований.
3. Все операции сценария выбранного профиля нагрузки выполнились в течение всего нагрузочного теста с заданной частотой
4. Не было виртуальных пользователей в течение всего теста, которые получили бы какую-либо ошибку, в результате которой виртуальные пользователи не смогли бы продолжить тестирование и завершить назначенный им сценарий.

Коэффициент производительности

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

Ключевая операция Целевое время Т (сек.)
Проведение документа «Платежное поручение входящее» 1
Открытие формы документа «Поступление товаров и услуг» 0,5
Проведение документа «Поступление товаров и услуг» 2
Проведение документа «Отчет производства за смену» 4

Методика вычисления коэффициента производительности

1. Коэффициент производительности вычисляется отдельно по каждой ключевой операции.
2. Значение коэффициента производительности по данной операции на данный момент времени вычисляется по 100 последним замерам времени выполнения этой операции, предшествующим моменту оценки.
3. Коэффициент производительности вычисляется по формуле (NS + NF/2)/N, где:
a. N: общее количество выполненных операций;
b. NS: количество операций, выполненных за время, меньшее или равное T;
c. NF: количество операций, выполненных за время, меньшее или равное 4T.
Методика подробно приведена в статье.

Требования к списку ключевых операций

1. Название операции должно отвечать на вопрос: что именно выполняется?
a. ОткрытиеФормыДокументаРеализацияТоваровИУслуг
b. ПроведениеДокументаРеализацияТоваровИУслуг
c. СозданиеДокументаРеализацияТоваровИУслуг
d. ОткрытиеФормыСпискаДокументовРеализацияТоваровИУслуг
2. Все операции имеют уникальный приоритет. Это необходимо для того, чтобы упорядочить список ключевых операций знать точно, в какой последовательности наиболее важно исправлять ошибки.
3. Должно быть указанно целевое время, назначенное экспертами совместно с клиентом. При этом выбранное целевое время не должно меняться в худшую (большую) сторону.

Коэффициент устойчивости работы системы

Устойчивость системы определяется количеством падений и зависаний кластера серверов 1С:Предприятия в единицу времени.
Падение кластера серверов 1С:Предприятия

Падением кластера серверов 1С:Предприятия называется самопроизвольная выгрузка любого процесса кластера серверов 1С:Предприятия или всех его процессов одновременно.

Зависание кластера серверов 1С:Предприятия

Зависанием кластера серверов 1С:Предприятия называется состояние кластера, при котором он не отвечает на запросы пользователей, не позволяет создать новое клиентское подключение и т.п., но при этом остается загруженным в память рабочего сервера.
Методика вычисления коэффициента устойчивости работы системы
Коэффициент устойчивости работы системы вычисляется за период времени равный одной календарной неделе.
Коэффициент устойчивости работы системы вычисляется по формуле (NС + NH)/7, где:
• NC: количество падений кластера серверов 1С:Предприятия за тест (или за период);
• NH: количество зависаний кластера серверов 1С:Предприятия за тест (или за период).

Обеспечение технологического качества новой версии информационной системы

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

Тестовый стенд должен соответствовать (но не ограничивается этими требованиями) рабочей системе по следующим параметрам:
1. Код конфигурации
2. Версия и вариант использования 1С:Предприятия
3. Тип и версия СУБД
4. Тип и версия ОС на всех серверах
5. Пользовательские данные
6. Настройки приложений

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

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

Положение тестового стенда в эксплуатации рабочей системы


Предлагается следующая классификация серверов и зон при развертывании тестовой системы.
1. Продукционные серверы
a. Запрещена отладка
b. Пользовательские данные
c. Обновление только с использованием check-листов по заранее согласованному плану
d. Настроен мониторинг
e. Полный доступ только у администраторов эксплуатирующей организации
2. Тестовые (подготовительные) серверы
a. Разрешена отладка
b. Пользовательские данные
c. Подготовка check-листов
d. Настроен мониторинг
e. Полный доступ только у администраторов эксплуатирующей организации
3. Серверы разработки
a. Разрешена отладка
b. Тестовые данные
c. Изменения вносятся постоянно
d. Мониторинг может отсутствовать
e. Полный доступ у разработчиков

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

Организация тестового стенда

Можно выделить следующие этапы организации тестового стенда.
1. Анализ схемы доступа к внутренним серверам продукционной площадки
2. Выбор схем резервирования инженерных систем
3. Выбор способа синхронизации с рабочей площадкой
4. Анализ требований к оборудованию тестовой площадки
5. Организация адресации
6. Получение копий
7. Запуск синхронизации с рабочей площадкой
8. Организация внесения изменений на подготовительной и рабочей площадке

Анализ схемы доступа к внутренним серверам продукционной площадки

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

Результатам анализа является документ, включающий в себя:
1. Описание сетей рабочей площадки, адресацию
2. Имена серверов рабочей площадки, их адреса
3. Роли серверов
4. ПО, используемое для доступа к серверам
5. Список лиц, имеющих доступ

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Время создания страницы: 0.060 секунд