downtime

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

Частая ошибка — считать временем простоя любую неудобную ситуацию для пользователей. Если ИТ-услуга доступна, но работает медленно или с ограниченной функциональностью, это может быть инцидентом, но не обязательно временем простоя, если недоступность не определена в правилах измерения доступности. Ещё одна типичная путаница связана с «согласованным временем услуги»: простои вне этого окна (например, ночью при режиме 8×5) не должны автоматически попадать в расчёт доступности, иначе показатели будут искажены и начнут конфликтовать с SLA. На практике также путают время простоя ИТ-услуги с простоем отдельной конфигурационной единицы: отказ одной конфигурационной единицы не всегда приводит к простою ИТ-услуги при наличии резервирования или обходного решения. Важно заранее согласовать, как измеряется начало и конец простоя (по мониторингу, по подтверждению пользователя, по восстановлению ключевых транзакций), иначе разные команды будут «закрывать» простои в разное время, и отчётность станет недостоверной. Наконец, не следует смешивать время простоя с плановыми окнами обслуживания: плановые работы могут быть изменениями, но не обязательно являются временем простоя, если они укладываются в согласованные условия предоставления услуги.