Основная цель функционирования процессов разработки и эксплуатации ИТ в части надежности – это предсказуемость результатов.
Когда вопрос касается повышения надежности сложных систем, надо учитывать, что такие вопросы как производительность, скорость обработки и т.п., должны быть отложены на вторую очередь.
На первую очередь выходит стабильность работы каждой отдельной итерации, ожидаемый результат работы каждого шага. Особенно это касается операций в продуктивной среде.
Из всех процессов эксплуатации ИТ (по последней версии ITIL их насчитывается около 30) только четыре имеют доступ к продуктивной среде.

• Управление Изменениями;
• Управление Плановыми Работами;
• Управление Инцидентами;
• Управление Запросами на Обслуживание.

Управление Изменениями. Через этот процесс проходят все Запросы на Изменения, которые потом внедряются в продуктивную среду.
Для максимально оптимальной обработки запросов на изменение (RFC), желательно разделить классический процесс Управления Изменениями на два отдельных.
Выделить основной процесс Управления Изменениями, который отвечает за прием, обработку и согласование потребностей в изменениях. Часто такой процесс выделяется в процесс «Управления бизнес-потребностями».
Второй процесс будет непосредственно процессом Внедрения Изменений в продуктивную среду. Часто на эту функцию (внедрение в продуктивную среду) ставится процесс Управления Релизами и Внедрением (Release and Deployment). Но для повышения надежности и здесь лучше сделать разделение ответственности.
В рамках первого процесса будет проходить взаимодействие между Заказчиками и исполнителями, определяться сроки, проводиться согласование и визирование, разделение Запросов на изменение на релизы и т.п. вопросы. Доступа в промышленную среду у процесса нет.
В рамках же второго процесса производится непосредственное внедрение в продуктивную среду уже подготовленных изменений.
Теперь о том, как такой подход повышает надежность систем. Надежность повышается путем снижения сложности процесса, работающего непосредственно с продуктивной средой. Изменение может долго согласовываться, может выбираться архитектура и технологии, может проводиться разработка или закупка, тестирование, подготовка дистрибутива. При этом работоспособность продуктивной среды в этом никак не участвует.
Подготовленное изменение для внедрения в продуктивную среду, проходит короткий «предвнедренческий» контроль на корректность заполнения и конфликты с другими работами, после чего вносится в «календарь работ в продуктивной среде», где уже находятся регулярные и плановые работы, другие изменения и все остальные отметки о том, какое время допустимо для внедрения изменения.
Управление плановыми работами. Это отдельный процесс, который управляет различными работами, которые необходимо регулярно проводить для обеспечения работоспособности ИТ-систем.
Управление Инцидентами. Данный процесс отличается тем, что для скорейшего восстановления работоспособности, доступ в продуктивную среду нужен быстрый, и не всегда согласованный. Особенно если касается ночных инцидентов, когда для доступа приходится вскрывать заранее приготовленные конверты с паролями. В этих случаях риск нарушения работы систем крайне велик.
Управление Запросами на Обслуживание. Данный процесс отличается по типу доступа от всех остальных, и в некоторых случаях вообще не считается процессом с прямым доступом в продуктивную среду. В «идеальной картине мира» Запросами на обслуживание должны являться операции, которые по тем или иным причинам продолжают выполняться сотрудниками ИТ, хотя должны быть встроены в функционал ИТ-системы. Для выполнения этих операций в ИТ-системе должны быть предусмотрены штатные средства, которые подразумевают достаточный уровень безопасности и невозможность навредить функционалу системы.
На практике же дела обычно обстоят проще – скрипты, командная строка и прямой консольный доступ к базам данных повышают уровень риска. Именно по этой причине этот процесс нельзя сбрасывать со счетов, когда вопрос качается проектирования надежных процессов.

Соответственно, желателен общий календарь с учетом RFC, регламентных работ и Запросов на обслуживание. Этот общий календарь предназначен для:
1) Оценки взаимного влияния работ. В основном оценивать взаимное влияние необходимо по времени и ИТ-услуге. Можно и по ИТ-системе.
2) Для анализа текущей ситуации при решении Инцидентов.
3) Для мониторинга и процесса Управления Событиями — позволяет сопоставлять нетипичные профили поведения систем и плановые перерывы.

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