Срочно, безотлагательно, экстренно… Все эти синонимы с точки зрения англо-русских словарей могут быть использованы для перевода слова “emergency”, которое в ITIL используется для именования особой группы изменений. Изменения этой группы должны внедряться “как можно скорее”. Формулировка, на первый взгляд, несколько размытая и не дающая чётких указаний, в каких конкретно случаях изменение следует обрабатывать в соответствии с некой специальной процедурой. Но в ITIL эта формулировка сопровождается чётким ограничением охвата и соответствующими примерами. В частности, там сказано, что “процедура обработки emergency-изменений должна применяться только для изменений, направленных на устранение ошибок в ИТ-сервисах, которые серьёзно влияют на бизнес”. А в разделе, посвящённом типам запросов на изменение (change request), приведены два примера “emergency”-изменений:

• изменение, необходимое для устранения массового инцидента;
• патч, устраняющий “дыры” в безопасности.

При этом слово “emergency” и контекст ситуации не предполагают какой-либо градации по уровню. Нужно безотлагательно, а не “слегка безотлагательно” или “сверх-безотлагательно”. Безотлагательно – значит, всё бросили и занимаемся только этим.

А к слову “срочное” мозг заботливо подбирает ассоциации, связанные с его корнем. “Насколько срочное?” – вполне закономерный вопрос в нашем контексте. Отсюда возникает довольно распространённая в нашем отечестве практика вводить в карточке запроса на изменение поле “Срочность” с типовым набором значений. Примерно таких:

• низкая;
• средняя;
• высокая.

Что интересно, если внимательно посмотреть на правила обоснования этих значений, становится понятно, что вкладываемый смысл коррелирует либо с влиянием изменения (его важностью для бизнеса), либо с требованиями к сроку реализации. То есть либо бизнес говорит “мне надо завтра”, что даёт нам сразу конкретные требования к сроку, либо “это крайне необходимо”, в результате чего мы, вполне вероятно, отодвигаем все прочие задачи. Так или иначе мы действительно определяем “срочность”, но по факту она выражается в более конкретных понятиях. Абстрактная, на мой взгляд, классификация “срочностей”, приведённая выше, не информативна. Её применение часто приводит к путанице и злоупотреблениям “сверх-срочностью”. Бизнес в большинстве случаев тяготеет к установке максимальной “срочности” по практически каждому запросу на изменение. Вернуть заказчика в конструктивное русло помогает именно конкретизация требований к сроку с одновременной оценкой влияния изменения на бизнес, что позволяет нам объективно установить приоритет изменения, то есть последовательность реализации относительно других изменений. И в ITIL не зря рекомендуется именно такой подход.

При этом для “emergency”-изменений, которые, как мы увидели выше, не используются для реализации запросов от бизнеса, лучше применять термин “экстренное”, так как он лучше отражает смысл написанного в ITIL. Важно помнить, что “срочность” в управлении изменениями не тождественна “экстренности”.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

Повысить долю успешных изменений, снизить риски, знать всё про конфигурации