S – Rb, Sn 18 страница

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

· Определить объем усилий, требуемых для осуществления отмены.

· Выяснить влияние отмены на другие изменения (запланированные или уже развернутые).

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

В последнем случае может оказаться более приемлемым решение инициировать принятие новых RFC для исправления проблемы, как описано ниже, в разделе “Подготовка дополнительных RFC”.

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

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

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

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

· Была ли проблема правильно проанализирована?

· Проверено ли должным образом предложенное средство исправления ситуации?

· Правильно ли реализовано принятое решение?

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

Выбор инструментальных средств и технологий, используемых для отмены изменения, зависит от типа и характера изменения. Например, программные приложения, развернутые с использованием Systems Management Server, обычно можно снять с эксплуатации с помощью опции Uninstall или параметров Group Policy, позволяющих перевести в неактивное состояние или отменить соответствующий объект Group Policy.

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

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

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

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

Дата добавления: 2015-01-03