Часто слышу аббревиатуру SLA. Причем в контексте "у нас есть SLA, а значит есть облако".
Нет, мои дорогие. В большинстве случаев (90%+) то, что у вас есть - это даже не SLA.
Давайте разберемся с терминологией:
SLO (Service Level Objective) - заданный уровень качества сервиса. Зачастую выражается в девятках, иногда в простоях в год (равнозначно). Что же такое девятки и их количество? Пять девяток, известные как "офигеть как круто", означают, что сервис доступен 99,999% времени (допускается простой пять с половиной минут в год).
Но в большинстве случаев путают SLA и SLO. В чем же принципиальная разница между ними?
SLA (Service Level Agreement) = SLO + штрафные санкции. В случае отсутствия четко прописанных штрафных санкций не может идти речи ни о как каком SLA. Это не более, чем SLO с обещанием "честное слово, постараемся".
С другой стороны наблюдается проблема неспособности бизнес-подразделений сформулировать хоть сколько-нибудь внятные цифры SLO. Архитектор приходит к бизнесу и спрашивает - а сколько для компании будет стоить потеря данных за последний час, и сколько будет стоить один час простоя сервиса? И бизнес потерялся. Их никогда не спрашивали об этом, никто никогда даже не задумывался.
Зачем это спрашивает архитектор? Затем, что при вопросе какие вы хотите увидеть в SLO показатели RPO (Recovery Point Objective) и RTO (Recovery Time Objective), следует ответ - конечно же ноль. Архитектор проектирует систему с простоем, стремящимся к нулю, и нулевой потерей данных. У бизнес-подразделения глаза лезут на лоб от стоимости.
Мало назначить RPO(RTO), надо обосновать почему именно такая цифра должна стоять. Исполнение заданных в SLO цифр несет определенные расходы на внедрение и поддержку, и это тоже нужно учитывать. Лишь после можно говорить что-то о штрафных санкциях и SLA.
В большинстве случаев же штрафные санкции за неисполнение будут заключаться в "генеральный намылил часть тела CIO прямо на собрании директоров". За что ему намылили? За то, что "система из говна и палок не шмагла..."
Нет, ну серьезно, какие тут SLA и облака, если из говна и палок?
Нет, мои дорогие. В большинстве случаев (90%+) то, что у вас есть - это даже не SLA.
Давайте разберемся с терминологией:
SLO (Service Level Objective) - заданный уровень качества сервиса. Зачастую выражается в девятках, иногда в простоях в год (равнозначно). Что же такое девятки и их количество? Пять девяток, известные как "офигеть как круто", означают, что сервис доступен 99,999% времени (допускается простой пять с половиной минут в год).
Но в большинстве случаев путают SLA и SLO. В чем же принципиальная разница между ними?
SLA (Service Level Agreement) = SLO + штрафные санкции. В случае отсутствия четко прописанных штрафных санкций не может идти речи ни о как каком SLA. Это не более, чем SLO с обещанием "честное слово, постараемся".
С другой стороны наблюдается проблема неспособности бизнес-подразделений сформулировать хоть сколько-нибудь внятные цифры SLO. Архитектор приходит к бизнесу и спрашивает - а сколько для компании будет стоить потеря данных за последний час, и сколько будет стоить один час простоя сервиса? И бизнес потерялся. Их никогда не спрашивали об этом, никто никогда даже не задумывался.
Зачем это спрашивает архитектор? Затем, что при вопросе какие вы хотите увидеть в SLO показатели RPO (Recovery Point Objective) и RTO (Recovery Time Objective), следует ответ - конечно же ноль. Архитектор проектирует систему с простоем, стремящимся к нулю, и нулевой потерей данных. У бизнес-подразделения глаза лезут на лоб от стоимости.
Мало назначить RPO(RTO), надо обосновать почему именно такая цифра должна стоять. Исполнение заданных в SLO цифр несет определенные расходы на внедрение и поддержку, и это тоже нужно учитывать. Лишь после можно говорить что-то о штрафных санкциях и SLA.
В большинстве случаев же штрафные санкции за неисполнение будут заключаться в "генеральный намылил часть тела CIO прямо на собрании директоров". За что ему намылили? За то, что "система из говна и палок не шмагла..."
Нет, ну серьезно, какие тут SLA и облака, если из говна и палок?
Сообщения
