Записаться

Жизненный цикл услуги и место проектирования и разработки

1. Общая логика жизненного цикла

На схеме показан жизненный цикл услуги (service lifecycle). Верхние пунктирные стрелки — этапы: проектирование и разработка (Design and Development), переход (Transition, транзишн), ранняя поддержка / опытно-промышленная эксплуатация (Early Life Support, ELS), живая эксплуатация (Live Operations).

Нижние тёмно-фиолетовые стрелки — фазы или области процессов из ITIL 2011: стратегия (Strategy), дизайн (Design), переход (Transition), операция (Operation), непрерывное улучшение услуг (Continual Service Improvement).

2. Проект и текущая деятельность

Проектная команда (Project Team) работает до начала живой эксплуатации (Live Operations). После перехода услуги в нормальный режим проекта больше нет — начинается текущая деятельность (ongoing activity). Белые прямоугольники между проектной командой и процессами показывают, какие группы процессов действуют на соответствующем интервале.

3. Что делается в ключевых фазах

• Стратегия: документировать и согласовать бизнес-требования к услуге. Связана с управлением портфелем, финансами и взаимоотношениями.
• Дизайн: проектирование и разработка ИТ-решения для услуги. Блоки Design Service Solution идут один за другим: проектирование может повторяться, пока услуга не будет готова к развёртыванию.
• Переход: перенос услуги в рабочую, или боевую, среду. В лаборатории услугу разрабатывают, тестируют и отлаживают на небольшом числе пользователей, а в эксплуатации — тысячи пользователей, другое оборудование, общие серверы, возможные перегрузки и сбои.
• Операция: оказание услуги.
• Улучшение: деятельность по улучшению услуги, которая продолжается всё время её существования.

4. Пересечение перехода и операции

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

5. Ключевые артефакты

Пакет проектирования услуги (Service Design Package, SDP) создаётся по окончании проектирования и разработки. Это совокупность программных средств, тестов, инструкций, настроечных скриптов и иных материалов, необходимых для переноса решения из лабораторной или тестовой среды в боевую.

Критерии приёмки услуги (Acceptance Criteria; в схеме — SC) возникают на разных этапах, иногда несколько раз. Пользователь или заказчик проверяет по ним качество. Критерии берутся из соглашения об уровне обслуживания.

Требования уровня услуги (Service Level Requirements; в схеме — SL) означают, что на каждой фазе пользователь может менять требования, выдвигать новые или предлагать идеи. Это учитывается до начала опытно-промышленной эксплуатации.

6. Формирование SLA

Перед опытно-промышленной эксплуатацией накопленные и изменённые требования собирают в соглашение об уровне обслуживания (Service Level Agreement, SLA). Во время опытно-промышленной эксплуатации действует пилотное SLA (Pilot SLA). После её окончания формируется рабочее, или актуальное, SLA (Live SLA), и услуга переходит в нормальный режим. Этими вопросами занимается управление уровнем обслуживания (Service Level Management, SLM).

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

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

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

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