service maintenance objective

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

Частая ошибка — трактовать время плановой недоступности услуги как общий допустимый простой услуги. На практике оно покрывает только недоступность из-за планового обслуживания, тогда как сбои, ошибки, инциденты и их восстановление должны учитываться отдельно и управляться через управление инцидентами и управление проблемами. Также этот показатель нередко путают с целевым временем восстановления: целевое время восстановления применяется к восстановлению после нарушения, а время плановой недоступности услуги — к заранее согласованному окну, где само «восстановление» не является целью, потому что прекращение предоставления услуги запланировано. Важно помнить, что в определении речь идёт о КЕ: недоступность одной КЕ не всегда означает недоступность услуги, если сервисная архитектура предусматривает резервирование или деградацию с сохранением полезности. Обратная ошибка — считать, что если окно согласовано, то коммуникации и контроль рисков не нужны: даже плановое обслуживание требует оценки риска, контроля изменений, проверки зависимостей в CMDB и готовности обходных решений, иначе плановая активность легко превращается в крупный инцидент.