Предоставление услуг

Записаться

Услуга и её ценность

Речь идёт о предоставлении услуг (service provision) в управлении ИТ. Это та же область, что и в ITIL v2: управление инцидентами, проблемами и другими процессами. Но взгляд на услугу становится сложнее.

Услуга должна не просто работать. Ожидается, что она будет оказываться в соответствии с бюджетом и планами по возврату инвестиций (Return on Investment, ROI). Как именно оценивать возврат инвестиций, не сказано. Но идея понятна и полезна: можно накапливать статистику оказания услуги за длительный период и на её основе делать обобщения. Например, отвечать на вопросы: стоило ли вводить услугу? Принесла ли она ожидаемую пользу?

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

Процессы предоставления услуг

Процессы предоставления услуг похожи на процессы ITIL v2. Однако есть отличия:

• управление инцидентами устроено иначе;
• управление запросами отделено;
• появилось управление событиями;
• управление доступом выделено отдельно;
• управление проблемами сохраняется.

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

В ITIL v2 были линии поддержки (support lines): первая, вторая, третья. Маршруты переводили инцидент с первой линии на вторую и далее. В рассматриваемой модели таких линий нет.

Вместо них используются модель инцидента (incident model) и сценарий обработки (processing scenario). Для каждого заранее запланированного или прогнозируемого инцидента существует свой сценарий, который запускается при наступлении события.

Выполнение запросов

Выполнение запросов (Request Fulfillment) отделено от управления инцидентами. В ITIL v2 некоторые запросы, например запрос на изменение (Request for Change) или запрос информации (Request for Information), относились к инцидентам. Это не всегда понятно, потому что инцидент — это внештатная ситуация. В новой модели запросы выведены в отдельный процесс.

Управление событиями

Появился процесс управления событиями (Event Management), которого не было в ITIL v2. Его идея: часто существуют сигналы, говорящие о приближении инцидента, когда инцидент ещё не наступил. Если своевременно перехватывать такие сигналы и реагировать, инцидент может не наступить.

Пример: уменьшается доступная память для обмена с СУБД (система управления базами данных, DBMS). Свободная память снижается: 90%, 80%, 60%. Если процесс продолжится, сервер базы данных перестанет отвечать на запросы. Нужно быстро принять меры.

Где взять информацию? Можно установить цифровые датчики или программное обеспечение, которое в цикле опрашивает состояние конфигурационных единиц (Configuration Items, CI) и сообщает в управление событиями. Можно делать массовые запросы для контроля статуса конфигурационных единиц, подверженных таким эффектам. Опрос может выполняться каждый час, день или неделю. Способы разные, но идея полезная.

Управление доступом

Управление доступом (Access Management) — отдельный процесс. Его не следует путать с обеспечением доступности. Он управляет тем, как распределяются и организуются полномочия пользователей по доступу к ИТ-ресурсам.

Например: кто, почему и когда имеет доступ к конфиденциальной информации; кто, почему и когда имеет право изменять данные в справочниках. Синонимы: управление идентификацией (Identity Management) и управление правами (Rights Management). Есть и другие термины.

Управление проблемами

Управление проблемами (Problem Management) остаётся таким же, как и было.

Общий итог

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

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

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

Разделение потоков работ снижает путаницу. Аварийные ситуации требуют одного режима управления, а плановые обращения — другого. Когда запросы на изменение или информацию относят к инцидентам, теряется приоритизация и искажается статистика. Выделение выполнения запросов позволяет стандартизировать типовые операции, а управление инцидентами сосредоточить на восстановлении сервиса. Это практично: уменьшается смешение критериев срочности, понятнее ответственность, проще автоматизировать сценарии.

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

Управление событиями — это переход к проактивности. Сигналы о деградации, например снижение доступной памяти для обмена с СУБД, позволяют вмешаться до отказа. На практике ценность такого подхода зависит от качества мониторинга: датчики, опросы конфигурационных единиц и пороги должны быть настроены так, чтобы не создавать шум. Если сигналов слишком много, внимание теряется; если мало — инциденты остаются внезапными. Значит, нужен баланс между чувствительностью и устойчивостью.

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

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