Подписаться
Читать в телеграм
Как правило, остановить бизнес-приложение на время обновления можно далеко не всегда. Приложения уровня mission critical эксплуатируются в круглосуточном режиме, и любая их остановка зачастую ведет к прямым потерям. Именно поэтому важно, чтобы обновления выполнялись, что называется, «с первого раза», но, к сожалению, обновления прикладных систем, выпускаемые разработчиками, часто приносят с собой новые ошибки.
Иногда контролю качества обновлений бизнес-приложений не придают должного внимания ни заказчик, ни разработчик ПО. Заказчику, как правило, обновление нужно «еще вчера»: ему необходимо либо новый бизнес-процесс запустить, либо «дыру» в соответствиях требованиям регулятора срочно закрыть. Разработчик ПО зачастую физически не в состоянии проверить влияние выпускаемого обновления на весь остальной функционал, да еще и с учетом специфики конкретного заказчика. В итоге до внимательной и кропотливой проверки руки не доходят. Поэтому на рынке востребована услуга независимого контроля качества бизнес-приложений.
Наша задача как поставщика, отвечающего за качество «приклада», – сделать так, чтобы обновления устанавливались с минимальными простоями и не приносили с собой новых ошибок. По сути, мы гарантируем качество работы бизнес-приложения. Мы отвечаем перед заказчиком в соответствии с SLA: в качестве определяющей метрики SLA для такой услуги мы указываем количество инцидентов, возникающих при работе бизнес-приложения после установки нами очередного обновления. Так, например, в контракте на эксплуатацию системы электронной коммерции для крупного ритейлера указано, что количество инцидентов классов blocker и critical, возникших по причине не выявленных нами ошибок в бизнес-логике прикладного ПО, не может превышать четырех. Особо отметим, что в контексте отношений «заказчик – производитель ПО – наша компания» мы являемся независимой стороной, отвечающей за качество прикладного ПО, причем мы не являемся его производителем. Такое положение дел позволяет заказчику быть уверенным в том, что наши проверки будут максимально объективны.
Сам механизм оказания услуги довольно прост. Рассмотрим его на примере уже упомянутого проекта. Есть 2 вида обновлений:
- сервис-фиксы – обновления, оперативно устраняющие какую-либо ошибку либо привносящие незначительные изменения в функционал. Они могут выполняться разработчиками ПО достаточно быстро (иногда в течение нескольких часов);
- релизы – обновления, привносящие серьезные изменения в существующий функционал и/или добавляющие значительный объем нового функционала. Релизы планируются разработчиками ПО на год вперед и устанавливаются достаточно редко – раз в месяц.
Потребность в разработке сервис-фикса возникает при решении инцидента, возникшего в процессе эксплуатации прикладного ПО. Так как время решения инцидента весьма ограничено, то и времени на тестирование функционала бизнес-приложения после установки сервис-фикса у нас тоже очень мало. Поэтому для тестирования мы применяем отработанную схему.
Сервис-фикс устанавливается на непродуктивную среду. Она должна быть полностью идентичной продуктиву, иначе мы не сможем проводить на ней тестирование. Для поддержки непродуктивной среды в актуальном состоянии мы 2 раза в неделю выполняем клонирование продуктивной среды на непродуктивную.
На непродуктивной среде проверяется функционал, напрямую затрагиваемый сервис-фиксом. Мы тестируем факт устранения ошибки, для которой был создан сервис-фикс.
На непродуктивной среде тестируем основной функционал бизнес-приложения. Проще говоря, проверяем, что после установки обновления прикладное ПО продолжает выполнять свои основные функции. На этом же этапе тестируем те функции ПО, на необходимость проверки которых разработчик указал нам при выпуске сервис-фикса. Несмотря на кажущуюся масштабность задачи, мы выполняем тестирование сервис-фикса быстро – в течение нескольких часов.
После того как тесты на непродуктивной среде пройдены, выполняется установка обновления на продуктив. Это происходит таким образом, чтобы либо исключить, либо минимизировать время простоя прикладного ПО.
Разработка, тестирование и установка релизов, в отличие от сервис-фиксов, поддаются планированию. Для контроля качества выпускаемых релизов мы действуем по отлаженному сценарию.
Заказчик и разработчик прикладного ПО формируют план релизов на ближайший год. В плане фиксируют даты выхода релизов и набор функционала, реализуемый в каждом из них.
За определенное время до выхода релиза мы вместе с заказчиком разрабатываем тестовые сценарии. Они основываются на функциональных требованиях, сформулированных бизнес-пользователями, и согласуются с ними.
После цикла разработки (в строго фиксированное время до установки нового релиза) разработчики прикладного ПО выдают нам готовый к тестированию релиз. Мы готовим среду под его проверку, при этом учитываем не только требования ПО, но и рекомендации к его интеграции со смежными бизнес-приложениями. Так, в нашем примере мы должны обеспечить интеграцию тестируемой версии интернет-магазина с тестовыми средами SAP ERP.
Релиз устанавливается на специально подготовленную для него среду. Происходит тестирование в соответствии с разработанными для него сценариями. Кроме того, идет проверка по базовым тестовым сценариям, которые в обязательном порядке используются перед установкой любого релиза.
Параллельно с тестированием вместе с заказчиком и разработчиком ПО готовятся план установки релиза в продуктив и план отката на случай неудачи. Планы мы тестируем на отдельной среде. Это нужно для того, чтобы в час Х все наши действия были предсказуемы и отлажены.
После завершения цикла тестирования мы передаем заказчику и разработчику прикладного ПО отчет о его результатах. После этого, как правило, разработчик выполняет устранение выявленных ошибок, и цикл тестирования повторяется еще несколько раз, пока качество доработок не будет удовлетворять как заказчика, так и нас.
В предварительно согласованный срок мы устанавливаем протестированный релиз в продуктив. В это время продуктивная система не работает, нам необходимо уложиться в выделенное под процедуру обновления технологическое окно. Если что-то пойдёт не так, мы обязаны ввести в действие план отката и вовремя отдать заказчику работающую систему. Установка релиза занимает от 3 до 5 часов.
Отметим, что процессы и процедуры, разработанные нами для контроля качества обновлений эксплуатируемых бизнес-приложений, не зависят от архитектуры и «природы» этих систем и могут одинаково успешно использоваться для любого прикладного ПО.
