Что такое эксплуатация информационной системы
Организация процессов производства информационных систем. Часть 4. Внедрение информационной системы
IX Внедрение информационной системы
Нет ничего труднее, опаснее и неопределённее, чем руководить введением нового порядка вещей, потому что у каждого нововведения есть ярые враги, которым хорошо жилось по старому, и вялые сторонники, которые не уверены, смогут ли они жить по новому.
Н. Макиавелли
И вот интересная и насыщенная творчеством, прожектерством, креативом и созиданием часть в проекте подходит к концу. Начинаются суровые будни защиты своего решения в реальной атмосфере конкретного предприятия, и что не мало важно, все также в рамках действующего законодательства.
Для начала реализованный продукт необходимо развернуть на оборудовании, уготовленном для организации его опытной эксплуатации.
1. Развертывание системы на площадке опытной эксплуатации
В соответствии с спроектированной технологической архитектурой, отраженной в документации, закупается серверное, коммуникационное и прочее оборудование, а также системное ПО. Компоненты информационной системы монтируются в единый программно-аппаратный комплекс, на площадках, на которых планируется его промышленное использование.
Ввиду того, что в крупных проектах, задействовано большое количество оборудования на котором ПО разбросано по нодам, узлам и даже облакам, то этот процесс необходимо сопровождать полномасштабным документированием. Например, в техдокументацию включаются таблицы с адресами серверов, рабочих мест, способов доступа и т.п. Для визуального представления используются диаграммы компонентов, дающие понимание расположения узлов сети, распределения компонентов их взаимодействия и т.п. А ведь еще должны быть определены мероприятия, регламентирующие всевозможные изменения в инфраструктуре, позволяющие устранить последствия отказов различных элементов системы.
Рисунок 19. – Пример технического описания этапа внедрения
Это все чрезвычайно важно, поскольку следующим этапом на этих эксплуатационных площадках начнет толкаться множество специалистов команды внедрения и поддержки, и они не должны каждый раз выуживать необходимую для работы информацию из разных, пускай даже информированных источников. А потому, документация должна поддерживаться в актуальном состоянии и меняться одновременно с изменениями в настройках системы, изменениями архитектурного решения и т.п.
Нелишне на «боевых» площадках для промышленной эксплуатации системы, разворачивать и тестовые стенды, имитирующие работу, приближенную к реальной. Ну вдруг еще будут замечания, требующие выпуска новых релизов. Все конечно профессионалы, ответственные люди и всякое такое, но все же обновления лучше сперва погонять на тестовом стенде. Так на всякий случай.
Между тем 90% времени уже пролетело…
2. Обучение персонала заказчика работе с информационной системой
Как уже неоднократно упоминалось, в больших проектах особое внимание уделяется качеству документации, включая и инструкции пользователей системы. Чаще всего инструкции пользователей делятся на сегменты по видам деятельности, специализации и т.п. Это позволяет акцентировать внимание в документе на важные моменты и не грузить пользователей ненужной для них информацией.
Поскольку в обучении может быть задействовано значительное количество различных сотрудников заказчика, которые в свою очередь, для обеспечения непрерывности деловых процессов не могут обучаться в одно и то же время, которые должны обучаться различным функциональным обязанностям и по прочим уважительным причинам, необходимо тщательно планировать процесс подготовки персонала. Также полезно разбивать обучающихся на группы по категориям, требующим использование различных подходов и глубины обучения, исходя из уровня их первоначальной подготовленности. В итоге, составленный план-график обучения должен быть согласован со всеми заинтересованными лицами, и утвержден руководством заказчика, как обязательный к исполнению.
А мы на этапе проектирования предупреждали, что обучение персонала заказчика не только очень ответственная задача, но еще и очень трудоемкая…
3. Выявление недостатков и дефектов информационной системы
Очень часто в больших проектах, тестирование финального релиза не позволяет выявить все проблемные места решения. Причиной тому могут быть: огромные объемы данных на деле в «боевых» условиях, проявление уникальных сочетаний бизнес правил в реальных деловых процессах, особенности работы конкретного оборудования, специфические сочетания компонентов системы, балансирование нагрузки между распределенными узлами и т.п.
Зачастую ситуация еще осложняется тем, что внедрение новых систем на начальных стадиях ни в коей мере не отменяет необходимость производить работы на старых системах. То есть пользователи дублируют данные в обоих системах. Иногда требуется миграция существующих актуальных данных из устаревших хранилищ в новые, а структура и формат информации обычно весьма и весьма отличаются. Например, если в новой структуре данных не хватает информации для заполнения обязательных реквизитов, они заполняются какими-то данными назначенными «по умолчанию», а потом уже корректируются вручную пользователями. И это только малая толика того, с чем приходится сталкиваться в реальных проектах.
Отдельная тема — интеграционные решения, в которых может происходить сбои в цепочке, использующей различные компоненты, разработанные двумя, тремя и больше командами. Найти виноватых в этой ситуации крайне сложно, поскольку дефекты чаще всего возникают на стыке интеграционных элементов, из-за выявленных в ходе внедрения несоответствий. И тут важно не искать виновных для наказания, а быстро и конструктивно договориться о совместных уступках разработчиков стыкуемых компонентов, и эффективно решить проблему.
Учитывая все вышеперечисленное, этап опытной эксплуатации, чаще всего, насыщен эмоциональными всплесками и взаимными претензиями, как между командами разработчиков, так и с заказчиками. В этом случае очень важна роль архитекторов и системных аналитиков, которые должны оперативно локализовать проблему, предложить ее решение и согласовать его со всеми заинтересованными лицами. Для выполнения подобных работ требуется помимо основных профессиональных навыков, еще и обладание талантом переговорщика, и знанием основ менеджмента.
А тем временем мы достигли дна, отведенного для проекта времени…
4. Согласование изменений в процессе внедрения информационной системы
Если работа некоторых функциональных модулей информационной системы критически не соответствует потребностям и ожиданиям заказчика, и найдены решения по преодолению этих проблем, то необходимо их зафиксировать и согласовать с заказчиком.
Этап согласования нового решения очень важен, как минимум по двум причинам.
Во-первых, если объем реализации изменений превысит суммы, заложенные на подобные риски в плане проекта, то необходимо либо заключать дополнительные соглашения, либо команда исполнителей будет работать в убыток. Зачастую исполнителей призывают по-быстрому сделать изменения, а мол учтем их и рассчитаемся за работы по ним потом, одним пакетом. Но по факту же такие случаи, обычно приводят, к тому, что заказчик опосля напрочь забывает свои обещания, а выполненные работы объявляет — исправлением исполнителями своих собственных ошибок.
Во-вторых, любые изменения одних компонентов системы могут повлечь за собой неизбежное изменение взаимозависимых компонентов, что требует тщательного анализа и, возможно, перепроектирования целой цепочки подсистем. В противном случае неизбежно возникновение дефектов в работе системы в целом. Проявляться это может например, в отказе работы модуля смежной команды исполнителей, и заказчик уже их объявляет халтурщиками и бракоделами. Правда конечно всплывет, но осадчик останется.
Поскольку время просрочено, необходимо договариваться с заказчиком, и убеждать его, что он в проекте тоже был не подарок, и часть вины лежит именно на нем.
5. Доработка информационной системы по итогам опытной эксплуатации
Если в ходе опытной эксплуатации принимаются и согласуются решения о внесении изменений в разработанный программно-аппаратный комплекс, то на основании их выставляются задачи исполнителям по их реализации. Процесс, описанный в разделе Часть 3. Реализация проектного решения повторяется. Но…
Если на стадии проектирования системы мы обсуждали отрицательное влияние полномасштабного использования методологии Scrum (1) в больших проектах, то на данном этапе она подходит как нельзя лучше. Особенно это ощутимо в проектах в которых продукт, переданный заказчику, не устраивает его по большей части показателей. Иными словами, пора поддаться панике и очень быстро, «сломя голову» вносить изменения в продукт, который уже эксплуатируют.
Собственно говоря, наступил момент, когда актуальны следующие условия:
Рисунок 20. – Этап внедрения информационной системы
6. Передача информационной системы в промышленную эксплуатацию
Когда в ходе опытной эксплуатации решены все спорные вопросы и недоразумения по поводу того как должна функционировать внедренная система, и насколько она соответствует договору на ее разработку, стороны подписывают акты о выполнении контракта. Заказчик осуществляет полный расчет за выполненные работы. Договор на разработку и внедрение информационной системы может считаться выполненным.
Внедрение переходит в фазу промышленной эксплуатации. Эти взаимоотношения чаще всего юридически регулируются уже отдельным договором или дополнительным соглашением на сопровождение промышленной эксплуатацией системы. В рамках этого контракта могут происходить профилактические работы по диагностике работы компонентов системы, их взаимодействия, устранение мелких сбоев и т.п.
7. Резюме раздела
Этап внедрения информационной системы, являет собой момент истины всего процесса ее производства и ознаменует старт самого тяжелого периода для всех участников проекта. Он может включать в себя следующие активности:
Статьи по теме: «Информационная безопасность»
Сопровождение и эксплуатация системы информационной безопасности (часть 1)
Содержание:
Регламентация
По итогам внедрения СИБ осуществляется ее ввод в эксплуатацию: подписывается акт передачи системы в промышленную эксплуатацию, которым также утверждаются регламент эксплуатации и регламент вывода из эксплуатации.
Регламент эксплуатации определяет состав планируемых мероприятий по эксплуатации в отношении СИБ и содержит следующие сведения:
Регламент вывода из эксплуатации определяет состав планируемых мероприятий по выводу из эксплуатации СИБ и содержит следующие сведения:
Сама же стадия эксплуатации СИБ включает в себя:
Гарантийное обслуживание и техподдержка производителей средств защиты
Некорректная работа или незапланированный простой СИБ может привести к серьезным негативным последствиям: нарушению функционирования ИТ-инфраструктуры, остановке рабочего процесса, нарушению конфиденциальности, целостности или доступности служебной информации и др. Несмотря на то что часть средств защиты может быть реализована в отказоустойчивой кластерной архитектуре, риск сбоев остается, особенно в случае отсутствия квалифицированного технического обслуживания. При отказе любого из узлов кластера система переводится в аварийный режим, и в этот период требуется особое внимание со стороны службы эксплуатации для поддержания ее работоспособности.
Вот несколько примеров возможных последствий инцидентов работоспособности внедряемых систем:
С целью минимизации рисков незапланированных простоев СИБ и, как следствие, описанных выше негативных последствий, необходимо осуществлять квалифицированное сервисное обслуживание внедряемой ИБ-инфраструктуры (в том числе, на основе заключенных договоров с компаниями-производителями оборудования и ПО), непрерывный контроль состояния средств защиты, своевременные профилактические работы и оперативное восстановление работоспособности в случае сбоя.
С целью своевременного предоставления компонентов для замены, обновлений ПО и программных коррекций обязательно заключение договоров с компаниями-производителями обслуживаемого оборудования и программного обеспечения. Поддержка, оказываемая производителем, обеспечивает:
Отсутствие договоров с производителями обслуживаемых средств защиты может увеличить сроки устранения критичной для работоспособности всей ИБ- и ИТ-инфраструктуры аварии и продлить срок недоступности систем организации.
Уже на старте комплектации СИБ средствами защиты необходимо подумать о технической поддержке, а именно, о ее оптимальных параметрах (рисунок 1).
Немаловажно то, каким является официальный язык технической поддержки. Если производитель иностранный, нужно понимать, что существует риск не получить своевременную поддержку в нужном объеме, когда у производителя нет своего представительства в России и русскоговорящих инженеров. В этом случае стоит обратиться за сервисной поддержкой к российскому интегратору и организовать общение с технической поддержкой производителя через него.
У многих производителей техническая поддержка делится на два основных типа:
Выбор второго типа поддержки дает ряд преимуществ:
Организации обязательно должны отслеживать сроки технической поддержки производителя и вовремя ее продлевать. Иначе это может привести к негативным последствиям для ее бизнес-процессов.
Пример 1. Поддержка, ограниченная по времени
В организации ночью случился инцидент с системой защиты от таргетированных (целенаправленных) атак: система начала обрабатывать файлы в 24 раза медленнее. Пришлось отключить сервер и открыть заявку в техническую поддержку производителя. По причине того, что приобретена была поддержка 8х5, производитель отказался приступать к решению проблемы до наступления рабочего дня. В итоге восстановительные работы проводились в рабочее время, а вывод сервера из эксплуатации сказался на скорости передачи данных в сети организации.
Пример 2. Поддержка с неэффективной схемой замены оборудования
Пример 3. Опоздание с подпиской
Организация своевременно не продлила подписку на систему защиты от спама, из-за чего серверы стали пропускать весь трафик без фильтрации спама. В итоге корпоративная почтовая система была заполнена огромным количеством нежелательных писем.
Эксплуатация СИБ
Эксплуатация СИБ осуществляется в соответствии с эксплуатационной документацией, организационно-распорядительными документами по защите информации, и в том числе включает:
В ходе администрирования компонентов СИБ осуществляется:
В ходе выявления инцидентов и реагирования на них осуществляются следующие действия:
В ходе управления конфигурацией СИБ осуществляются:
В ходе контроля (мониторинга) уровня защищенности информации, содержащейся в информационной системе, осуществляются:
Для контроля событий безопасности и действий пользователей все чаще в организации используют системы мониторинга и корреляции событий ИБ. Это класс средств защиты, задача которых заключается в агрегации информации о событиях ИБ, получаемых из различных источников, для последующего анализа с целью идентификации инцидентов ИБ.
Данное решение обеспечивает:
Для контроля (анализа) защищенности информации, содержащейся в информационной системе, в организациях чаще всего используют сканеры уязвимостей – программное обеспечение, позволяющее обнаруживать известные уязвимости в элементах ИТ-инфраструктуры и/или приложений.
Данное решение помогает:
В ходе эксплуатации СИБ осуществляется регулярное взаимодействие с производителями оборудования и программного обеспечения по вопросам доработки и исправления ошибок в средствах защиты. Сотрудники, эксплуатирующие СИБ, регулярно формируют отчетность о работоспособности компонентов системы и о критичных инцидентах.
Техническое сопровождение средств защиты можно осуществлять как силами собственной службы эксплуатации, так и с привлечением внешней специализированной организации.
Передавать внешней специализированной организации в рамках договоров на сервис и аутсорсинг целесообразно ресурсоемкие задачи, которые имеют понятный состав работ и результат. Такие задачи легко зафиксировать в договоре, разграничить при этом зоны ответственности, согласовать метрики, также удобно контролировать их исполнение.
При заключении контракта на услуги договаривающиеся стороны должны:
При этом стоит заранее продумать, как будут на регулярной основе измеряться выбранные метрики, иначе они могут оказаться полностью бесполезными.
Авторы:
Андрей Янкин, заместитель директора ЦИБ, компания «Инфосистемы Джет»,
Ольга Елисеева, эксперт ЦИБ, компания «Инфосистемы Джет».
Организация эксплуатации крупной информационной системы
Общие вопросы
Эксплуатация крупной информационной системы
Это отдельный вид деятельности, который невозможно не учитывать, и который гарантированно будет показывать обратную связь:
В качестве примера будем рассматривать некоторую систему, в которой одновременно работают от 200 (в ночное время) до 1000 пользователей (днем) онлайн. При этом число реально зарегистрированных пользователей может оказаться значительно больше.
Основной задачей специалистов будет обеспечение непрерывной технологически качественной работы информационной системы с учетом необходимого развития информационной системы для соответствия бизнес-требованиям пользователей.
Технологическое качество
Задачи
В задачи эксплуатации входят :
В задачи администрирования входят :
В задачи разработки входят :
Планирование
Зоны системы
Зоны информационной системы :
Отличия зоны тестирования продукта от подготовительной зоны информационной системы:
Важно отметить, что в зависимости от того, насколько клиент готов нести затраты на обслуживание системы, зависит то, насколько указанная выше схема «ложится» на реальную систему клиента.
Например, могут рассматриваться варианты совмещения зон.
Здесь объединяется подготовительная и тестовая зона, при этом качество тестирования непосредственно перед обновлением в продуктиве напрямую зависит от качества соответствия подготовительной зоны рабочей зоне.
При этом зона разработки продукта, например, может вообще отсутствовать, если продукт не изменяется и не разрабатывается специалистами клиента. Т.е. процесс разработки продукта полностью отделен от рабочей информационной системы.
Такой вариант может применяться в случае, когда доработка продукта носит незначительный характер и практически не изменяет поведение и характеристики продукта. Тем не менее, разработка не происходит в информационной системе в рабочих или подготовительных зонах.
Что не следует делать
Совершенно точно не следует совмещать рабочую зону с подготовительной зоной, т.к. по сути новая версия системы будет «собираться» именно в продуктиве. Такой подход имеет повышенный риск сбоев в результате обновлений.
Не стоит совмещать подготовительную зону и зону разработки. В этом случае появляется риск утечки данных, т.к. доступ к данным пользователей появляется у разработчиков.
Не следует совсем отказываться от использования тестовой и подготовительной зоны, т.к. в этом случае тестирование, отладка, расследование проблем будет происходить на пользователях.
В этом случае страдает бизнес клиента, а от пользователей постоянно поступает негатив. Также стоит отметить, что после каждого такого обновления, нужного бизнесу, без тестирования в тестовой и подготовительной зонах, происходит период нестабильной работы системы, т.к. по сути это и является периодом опытно-промышленной эксплуатации, в котором тестирование происходит на пользователях.
Что имеет смысл сделать
Сначала стоит обновить наиболее маленькую часть. Затем, если система после обновления в продуктиве работает без сбоев, имеет смысл приступить к обновлению всей рабочей зоны.
Подготовительную зону имеет смысл развертывать скриптами, которые применяются для целей автоматизации, из бэкапов с рабочей зоны. Таким образом будет гарантироваться, что подготовительная зона максимально приближена к рабочей зоне.
Имеет смысл также организовать и иметь полный удаленный доступ в рабочую и подготовительную зоны. При этом такой доступ:
Удаленного доступа может не быть к зоне разработки и тестирования продукта. Продукт может нести особенную ценность для организации, в т.ч. с точки зрения обеспечения безопасности, а открытие доступа создает риск не только утечки исходного кода, но и открывает дополнительные возможности злоумышленникам в тех системах, где продукт используется. (Не раскрываем эту тему в текущей статье). К тому же как правило нет задачи поддерживать, например, uptime серверов разработки на уровне 99% и выше удаленно, разработчики обычно сами в состоянии это сделать со своих рабочих мест. В некоторых случаях (например, географической удаленности) существует задача обеспечения доступности системы сборки и тестирования, тогда такой доступ может быть организован.
Автоматизация
Такие шаблоны в минимальном виде могут быть:
Но только шаблонов не достаточно для решения задачи быстрого развертывания единиц масштабирования информационной системы. Существенной частью этой задачи является автоматизация.
Особое внимание можно обратить на подготовку следующих «механизмов»:
Организация эксплуатации
Регламенты, необходимые для организации процесса эксплуатации :
Ниже приводится схема (рисунок можно открыть в отдельном окне, либо на нее можно нажать левой кнопкой мыши) с принципиальным общим видом организации крупной информационной системы.
Схема не учитывает специфику организации бизнеса конкретного клиента.
Схему можно применять для того, чтобы понять, какие стороны вопроса эксплуатации действительно хорошо проработаны в вашей организации на вашем проекте, а какие стороны вопросы не проработаны совсем (как следствие, возможны риски).
Важно учитывать, что построение эксплуатации крупной информационной системы не возможно без выращивания команды специалистов, которые думают в одном направлении, заинтересованы.
Команда должна понимать одинаково, что команда должна получить от информационной системы в будущем.
Под проблемами качества работы системы подразумеваются проблемы работоспособности, устойчивости и производительности системы.
Под изменениями рабочей системы подразумеваются любые изменения программного, аппаратного, организационного или инфраструктурного уровней системы, включая, но не ограничиваясь, следующими изменениями:
Версия системы имеет уникальный номер и описание: дату публикации и перечень новых значений всех параметров системы, изменившихся по сравнению с предыдущей версией. Версии системы нумеруются по возрастанию – более поздние версии имеют большие номера.
Версии публикуются в соответствии с календарным планом. Внесение изменений в рабочую систему вне процедуры публикации версии не допускается. Иначе говоря, любые изменения могут быть внесены только в одну из следующих запланированных версий.
Версия по сути описывает совокупное состояние системы, которое имеет смысл сравнивать с другим состоянием, используемым при следующем обновлении.
Основные этапы процедуры публикации новой версии информационной системы :
Подготовительный стенд должен содержать полную копию рабочих информационных баз на момент начала подготовки перевода на новую версию.
Сотрудники группы эксплуатации проводят на тестовой версии ряд тестов, включая функциональные и нагрузочные (многопользовательские) тесты. Выполняются все тесты, которые выполнялись перед публикацией предыдущей версии. Тесты могут быть доработаны (расширены) по решению группы эксплуатации на основании анализа состава планируемых изменений, а также проблем, возникших в рабочей зоне системы за прошедшее время.
Организация подготовительного стенда информационной системы
Положение подготовительного стенда информационной системы в эксплуатации рабочей системы
Можно выделить следующие этапы организации подготовительного стенда
Организация автоматического развертывания бэкапов с рабочей системы также позволяет быть уверенными, что бэкапы действительно есть, они собираются, а также могут быть развернуты за определенное время. Кроме того важно, что специалисты группы эксплуатации периодически (по необходимости) восстанавливают из бэкапов подготовительный стенд, таким образом тренируются, что окажется существенным с точки зрения экономии времени в момент возможных пожарных работ в рабочей системе.
Синхронизация с рабочей площадкой должна проходить в автоматическом режиме и не должна отличаться от механики восстановления данных на продукционной системе в случае аварии.
Анализ схемы доступа к внутренним серверам продукционной площадки
Например, в информационной системе можно обеспечить сегментацию на виртуальные сети
Также доступ в интернет с подготовительного стенда следует закрывать, чтобы не было случайных рассылок реальным пользователям о возможных недоступностях, о регламентных работах или о нововведениях в подготовительной зоне сервиса.
Организация рабочего стенда информационной системы
Сheck-list по настройке рабочих серверов в продукционной зоне
При организации рабочей зоны очень важно не получить систему с сотнями тайных связей
Очень важно, чтобы конфигурация рабочей системы была максимально типовой, строилась из очень простых единиц масштабирования с минимизацией связей с другими единицами.
В процессе эксплуатации могут возникать желания доработки и развития системы. Очень важно в процессе таких доработок сознательно стремиться к упрощению существующей конфигурации.
Какие важные ключевые особенности здесь можно выделить:
Регламенты
Организация внесения изменений на подготовительной и рабочей площадке
Вводится правило: все изменения в рабочую систему вносятся через подготовительную площадку информационной системы.
Сначала изменения попадают на подготовительный стенд, затем на рабочий стенд.
Существует только одно исключение из этого правила: изменения в рабочую систему могут вноситься, минуя подготовительный стенд только в экстренных случаях.
По окончанию аварийных работ в ночное время стенд должен быть синхронизирован с рабочей зоной, чтобы устранить разницу в привнесенных изменениях.
Изменяться состояние подготовительного стенда может следующими способами:
Перед применением изменений на рабочей площадке check-листы распечатываются и передаются каждому участнику плановых работ.
Синхронизация участников выполняется оперативно по телефону или чату.
Журнал регистрации проведенных работ – специальный документ, который ведут все участники эксплуатации рабочий и подготовительной системы. В бортовой журнал попадают записи, отражающие все изменения в очень сжатой форме. Цель бортового журнала – в случае аварии быстро определить, кто и когда вносил изменения.
Пример записи в журнале регистрации проведенных работ:
— поправил com connector, выполнив команду из rdp сеанса C:\1C\current\regsvr32 comcntr.dll
Контроль качества работы подготовительного стенда
Во время тестирования разработчики контролируют показатели качества работы системы и сравнивают их с аналогичными показателями, полученными при тестировании предыдущей версии. Если показатели новой версии ухудшились по сравнению с предыдущей версией, то принимается согласованное решение о дальнейших действиях. Ответственные за эксплуатацию информационной системы договариваются либо отложить выпуск до исправления проблем качества, либо опубликовать версию, не смотря на наличие проблем.
После исправления проблемы необходимо провести повторное контрольное тестирование.
Публикация в рабочей зоне
Версия, успешно прошедшая тестирование в подготовительной зоне, публикуется в рабочей системе в соответствии с планом публикации версий и check-листами, которые были подготовлены на подготовительном стенде.
Время выполнения обновления, а также особенности обновления фиксируются и сравниваются с результатами полученными в подготовительной среде.
Отличия в поведении систем в подготовительной и рабочей зонах фиксируются и расследуются с целью устранения.
Версия, не прошедшая процедуру тестирования не может быть опубликована в рабочей зоне.
В случае внесения исправлений в версию, номер версии поднимается.
Контроль качества рабочей системы
Группа эксплуатации ведет постоянный контроль качества рабочей системы. Если какие-либо показатели качества работы текущей версии оказываются хуже, чем у предыдущей версии, то принимается согласованное решение об устранении проблемы. Стороны договариваются либо об отказе использования текущей версии и откате на предыдущую версию, либо о продолжении работы не смотря на существующие проблемы.
При выявлении проблем в рабочей системе может быть принято решение о доработке тестов таким образом, чтобы в следующий раз подобная ошибка была выявлена на стадии тестирования.
Для качественного контроля за рабочей системой необходимо настраивать мониторинг.
Также инструкция по настройке мониторинга с помощью Центр Контроля Качества.