Этапы эксплуатации информационной системы

Этапы эксплуатации информационной системы

Приобретение информации

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

Термин «Приобретение» может толковаться двояко:

1 вариант. Приобрести – значит получить то, чего не было

2 вариант. Приобрести = купить

В одной и той же информационной системе часть информации может быть приобретена по 1 варианту, часть по второму. Например, в ИС «Общепит» начальный перечень поставщиков и продуктов может быть взять из прайс-листов фирм, с которыми работает ресторан, а перечень рецептов может потребоваться приобрести за деньги.

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

Первоначальный сбор собственной информации

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

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

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

Обновление информации, ее анализ и распространение

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

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

Анализ этапа эксплуатации ИС

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

5. Корректировка планов на следующий этап

Доработка ИС

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

После этого, или параллельно, начинается новый 6-ти месячный этап эксплуатации ИС

Какие этапы эксплуатации АИС существуют?

На какие моменты необходимо обратить внимание при вводе собственной информации?

Предложите свои меры оптимизации работ на 2-3 этапах работы.

Составить план эксплуатации АИС «Общепит» на 6 месяцев.

Какие этапы эксплуатации АИС существуют?

• первоначальный сбор собственной информации

• обновление информации, ее анализ и распространение

• анализ этапа эксплуатации ИС

• корректировка планов на следующий этап, доработка ИС

Этапы эксплуатации информационной системы

Приобретение информации

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

Термин «Приобретение» может толковаться двояко:

1 вариант. Приобрести – значит получить то, чего не было

2 вариант. Приобрести = купить

В одной и той же информационной системе часть информации может быть приобретена по 1 варианту, часть по второму. Например, в ИС «Общепит» начальный перечень поставщиков и продуктов может быть взять из прайс-листов фирм, с которыми работает ресторан, а перечень рецептов может потребоваться приобрести за деньги.

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

Источник

Статьи по теме: «Информационная безопасность»

Сопровождение и эксплуатация системы информационной безопасности (часть 1)

Содержание:

Регламентация

По итогам внедрения СИБ осуществляется ее ввод в эксплуатацию: подписывается акт передачи системы в промышленную эксплуатацию, которым также утверждаются регламент эксплуатации и регламент вывода из эксплуатации.

Регламент эксплуатации определяет состав планируемых мероприятий по эксплуатации в отношении СИБ и содержит следующие сведения:

Регламент вывода из эксплуатации определяет состав планируемых мероприятий по выводу из эксплуатации СИБ и содержит следующие сведения:

Сама же стадия эксплуатации СИБ включает в себя:

Гарантийное обслуживание и техподдержка производителей средств защиты

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

Вот несколько примеров возможных последствий инцидентов работоспособности внедряемых систем:

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

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

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

Уже на старте комплектации СИБ средствами защиты необходимо подумать о технической поддержке, а именно, о ее оптимальных параметрах (рисунок 1).

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

У многих производителей техническая поддержка делится на два основных типа:

Выбор второго типа поддержки дает ряд преимуществ:

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

Пример 1. Поддержка, ограниченная по времени

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

Пример 2. Поддержка с неэффективной схемой замены оборудования

Пример 3. Опоздание с подпиской

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

Эксплуатация СИБ

Эксплуатация СИБ осуществляется в соответствии с эксплуатационной документацией, организационно-распорядительными документами по защите информации, и в том числе включает:

В ходе администрирования компонентов СИБ осуществляется:

В ходе выявления инцидентов и реагирования на них осуществляются следующие действия:

В ходе управления конфигурацией СИБ осуществляются:

В ходе контроля (мониторинга) уровня защищенности информации, содержащейся в информационной системе, осуществляются:

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

Данное решение обеспечивает:

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

Данное решение помогает:

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

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

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

При заключении контракта на услуги договаривающиеся стороны должны:

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

Авторы:
Андрей Янкин, заместитель директора ЦИБ, компания «Инфосистемы Джет»,
Ольга Елисеева, эксперт ЦИБ, компания «Инфосистемы Джет».

Источник

Эксплуатация, обслуживание и развитие информационной системы

Рис. Классификация видов износа

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

Наряду с физическим имеет место и моральный износ, также I и II рода. Износ I рода проявляется тогда, когда себестоимость производства такого же изделия снижается и оно может быть приобретено дешевле, чем используемое в настоящее время (см. динамику цен на микропроцессоры в главе 9). Моральный износ II рода обусловлен научно-техническим прогрессом и появлением новых, более производительных и совершенных средств, имеющих лучшие пользовательские качества. Это приводит к изменениям в технике, технологии производства работ и в организации использования СИ. В последние годы во всех новых поколениях средств ОИ существенно улучшается показатель «цена/производительность». В связи с этим использование морально устаревших средств невыгодно.

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

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

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

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

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

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

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

Одной из основных проблем менеджмента данных, если вообще не ключевой, является обеспечение защищенности данных, которое вписывается в проблему обеспечения комплексной защищенности ИС (см. разд. 1.2). Понятие «защита данных», принятое в отечественной практике (и в литературе) как основное, является весьма емким и нуждается в детализации. Необходимо также рассматривать в контексте защищенности данных все технические и технологические мероприятия, препятствующие потере, порче, искажению данных, несанкционированному доступу к ним и их недозволенной передаче куда-либо и кому-либо.

На предприятии эти мероприятия служат, прежде всего, целям охраны его «фирменных» секретов.

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

Для отечественной практики затруднительно даже приблизительно оценить стойкость предприятия при катастрофах. В среднем по стране предприятие могло тогда «прожить» при тотальном выходе из строя ИС только 4,8 дня. Этот весьма короткий срок свидетельствует о том, что ИТ и ОИ играют на предприятиях ФРГ значительную роль. По-видимому, эта роль на предприятиях нашей страны менее значительна, поэтому их стойкость по отношению к тяжелым происшествиям с ИС должна оказаться выше.

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

Источник

Организация эксплуатации крупной информационной системы

Общие вопросы

Эксплуатация крупной информационной системы

Это отдельный вид деятельности, который невозможно не учитывать, и который гарантированно будет показывать обратную связь:

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

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

Технологическое качество

Задачи

В задачи эксплуатации входят :

В задачи администрирования входят :

В задачи разработки входят :

Планирование

Зоны системы

Зоны информационной системы :

Отличия зоны тестирования продукта от подготовительной зоны информационной системы:

Важно отметить, что в зависимости от того, насколько клиент готов нести затраты на обслуживание системы, зависит то, насколько указанная выше схема «ложится» на реальную систему клиента.

Например, могут рассматриваться варианты совмещения зон.

Здесь объединяется подготовительная и тестовая зона, при этом качество тестирования непосредственно перед обновлением в продуктиве напрямую зависит от качества соответствия подготовительной зоны рабочей зоне.

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

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

Что не следует делать

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

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

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

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

Что имеет смысл сделать

Сначала стоит обновить наиболее маленькую часть. Затем, если система после обновления в продуктиве работает без сбоев, имеет смысл приступить к обновлению всей рабочей зоны.

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

Имеет смысл также организовать и иметь полный удаленный доступ в рабочую и подготовительную зоны. При этом такой доступ:

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

Автоматизация

Такие шаблоны в минимальном виде могут быть:

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

Особое внимание можно обратить на подготовку следующих «механизмов»:

Организация эксплуатации

Регламенты, необходимые для организации процесса эксплуатации :

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

Схема не учитывает специфику организации бизнеса конкретного клиента.

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

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

Команда должна понимать одинаково, что команда должна получить от информационной системы в будущем.

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

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

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

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

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

Основные этапы процедуры публикации новой версии информационной системы :

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

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

Организация подготовительного стенда информационной системы

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

Можно выделить следующие этапы организации подготовительного стенда

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

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

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

Например, в информационной системе можно обеспечить сегментацию на виртуальные сети

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

Организация рабочего стенда информационной системы

Сheck-list по настройке рабочих серверов в продукционной зоне

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

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

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

Какие важные ключевые особенности здесь можно выделить:

Регламенты

Организация внесения изменений на подготовительной и рабочей площадке

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

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

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

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

Изменяться состояние подготовительного стенда может следующими способами:

Перед применением изменений на рабочей площадке check-листы распечатываются и передаются каждому участнику плановых работ.

Синхронизация участников выполняется оперативно по телефону или чату.

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

Пример записи в журнале регистрации проведенных работ:

— поправил com connector, выполнив команду из rdp сеанса C:\1C\current\regsvr32 comcntr.dll

Контроль качества работы подготовительного стенда

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

После исправления проблемы необходимо провести повторное контрольное тестирование.

Публикация в рабочей зоне

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

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

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

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

В случае внесения исправлений в версию, номер версии поднимается.

Контроль качества рабочей системы

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

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

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

Также инструкция по настройке мониторинга с помощью Центр Контроля Качества.

Источник