ГОСТ Р ИСО/МЭК 20000-2—2010
c) обеспечить уверенность в том. что информация о конфигурациях является точной, управляе
мой идоступнойдля обозрения.
d) гарантировать, что изменение, релиз, система или окружающая средаудовлетворяют контрак
тным или заданным требованиям ичтозаписи о конфигурацияхсоответствуютдействительности.
Аудит конфигурации следует проводить регулярно, до и после серьезных изменений, поело раз
личного рода бедствий ичерез случайные промежутки времени.
Выявленные недостатки и несоответствия следует регистрировать и оценивать. Для их устране
ния необходимо инициировать корректирующие действия, о чем следует извещать соответствующие
стороны ипланировать совершенствование услуг.
П р и м е ч а й и в — Обычно проводят аудиты конфигурацийдвух видов.
a) аудит функциональной конфигурации: официальная проверка, позволяющая удостовериться, что эле
мент конфигурации обеспечивает эксплуатационные и функциональные характеристики, установленные в доку
ментации на конфигурацию.
b
) аудит физической конфигурации, официальнаяпроверка элемента конфигурации в том виде,в котором он
создан (произведен), позволяющая удостовериться, что данный элемент соответствует производственной доку
ментации для данной конфигурации.
9.2 Менеджмент изменений
Цель: Гарантировать, чтовсе изменения оцениваются, утверждаются, реализуются иподвергают
ся ревизиям контролируемым образом.
9.2.1 Планирование и реализация
Необходимо, чтобы процессы ипроцедуры менеджмента изменений гарантировали, что:
a) изменения имеют четко определенную идокументированную область распространения;
b
) утверждаются только те изменения, которые приносят пользу в сфере деловой деятельности,
например коммерческой, правовой, регулирующей, установленной законодательно.
c) изменения проводятся в соответствии с календарными планами на основе приоритетов и
рисков;
d) изменения в конфигурациях могутбыть верифицированы в процессе реализации изменений;
e) сроки реализации изменений контролируются и уточняются при необходимости;
f) можно продемонстрировать, каким образом каждое изменение:
1) инициируется, регистрируется иклассифицируется (соссылками на исходныедокументы);
2) оцениваетсяна предметего влияния, срочности, затрат, полезностии связанногос ним рис
ка для услуг, заказчика и плановпроведения релизов;
3) осуществляется полностью или корректируется в случае, если онооказалосьнеудачным;
4) документируется, например заявка на изменение привязывается к соответствующему эле
ментуконфигурации, к обновленной версии реализации ик плану проведения релиза:
5) утверждается или отклоняется именно тем сотрудником, который уполномочен принимать
подобные решения по изменениям в зависимости оттипа, размера и рискадля такого изменения:
6) выполняется назначенным сотрудником из состава группы, ответственной за изменяемые
компоненты;
7) тестируется, проверяется изавершается;
8) закрывается и пересматривается:
9) проводится через календарные планы, контролируется иотражается в отчетах:
10) привязывается к инциденту, проблеме, другому изменению и записям по элементам кон
фигурации. если это необходимо.
Статус изменений и сроки их реализации, указанные в календарных планах изменений, следует
использовать как основание для проведения каждого изменения и составления календарных планов
релизов.
Информацию, содержащуюся в календарных планах, следуетделать доступной для лиц. на кото
рых может воздействоватьэто изменение.
В тех случаях, когда может возникнуть простой во время установленных часов предоставления
услуги, лицам, на которых этот простой будет оказывать влияние, следует согласовать изменение
прежде, чем оно будет реализовано.
9.2.2 Закрытие и ревизии заявок на изменение
Все изменения после реализации или каких-либо зафиксированных улучшений следует подвер
гать специальномуанализу с целью определения их успешности или неудачи. Ревизии после выполне
ния серьезных измененийследует проводить для проверки того, что:
а) в результате изменения былидостигнуты поставленные цели;
22