Расскажу о такой прикольной штуке, как SLA - Service Level Agreement.

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

Были типовые проблемы, например, отказ БД. Поскольку у нас имелась резервная площадка и робот контроллер, проверяющий состояние всех систем, время на реакцию было 5 минут, а также 10 минут на «решение» - робот сам переключал приложение на работу с резервной базой.

Были и нетиповые проблемы, такие как проседание производительности. Вот обычный кейс - банк проводит закрытие операционного дня. Максимально допустимое время на это - полчаса. Если по каким-то причинам времени требовалось больше, нужно было садиться вместе с разработчиками и дружно ковыряться в коде приложения и структуре таблиц. На такого рода проблемы я выставлял от недели до трех.

Сейчас понятие SLA упростили донельзя (хотя в классическом ITIL используют тот же принцип, что и ранее) и его теперь обозначают в процентах.

Проще говоря, SLA это какой процент времени в году (с точностью до секунд) приложение или сервис работают бесперебойно.

То есть SLA в 99.9% означает, что приложение будет лежать не больше, чем 9 часов в году.

Звучит не так уж много, но представьте себе, какие издержки понесет Valve, если Steam - крупнейшая в мире система цифровой дистрибьюции - будет лежать 9 часов. Даже раз в году.
Про всякие Twitch, Google или Яндекс.ру я вообще молчу.