CMMI-SVC. Пример процессной области

Записаться

1. Процессная область ARP и управление доступностью

Процессная область ARP (Availability, Resolution and Prevention; доступность, разрешение и предупреждение) объединяет управление инцидентами и управление доступностью.

Управление доступностью можно рассматривать шире. Его цель — сделать услугу доступной в соответствии с соглашением об уровне услуги (SLA, Service Level Agreement). Это достигается разными способами:

• быстрым разрешением инцидентов;
• резервированием мощностей;
• копированием данных;
• восстановлением сохранённых копий для продолжения работы.

Поэтому управление доступностью — более общая задача, чем управление инцидентами.

2. Цели и практики

Цель области — своевременное и продуктивное разрешение инцидентов и предупреждение их появления.

Специфические цели:

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

3. Подготовка к разрешению и предупреждению инцидентов

Нужно разработать и поддерживать подход к своевременному и продуктивному разрешению и предупреждению инцидентов. Это конструирование процесса управления инцидентами.

Подход описывает:

• организационные функции: службу поддержки (Service Desk) и группы специалистов — постоянные или виртуальные;
• коммуникации между группами;
• процедуры, инструменты и распределение ответственности;
• критерии инцидента и способы диагностики;
• категории инцидентов и правила категоризации;
• уведомление заказчиков и конечных пользователей.

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

4. Управление инцидентами

После создания системы выявляют, контролируют и рассматривают отдельные инциденты:

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

5. Анализ отобранных инцидентов и решения

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

Различают:

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

Корневые причины выявляет управление проблемами (Problem Management). Даже при установлении непосредственной причины можно предусматривать шаги для предупреждения ситуации.

Практика включает:

1. Анализ отобранных инцидентов.
2. Разработку решений для реакции.
3. Планирование работ.
4. Тестирование и верификацию решения.
5. Информирование заинтересованных сторон.
6. Применение решения.

Краткие итоги

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

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

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

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