SLA – это соглашение об уровне обслуживания
Фактически, это договоренность между клиентом и разработчиками (в широком смысле), которая определяет:
1. Какие сервисы предоставляют поставщики ПО
2. Какой уровень доступности у этих сервисов
3. Что будет происходить, если сбой случится
Но более узкое восприятие понятия SLA включает в себя часто только один пункт из перечисленных - "Какой уровень доступности у этих сервисов". Часто доступность определяется количеством "девяток". "Две девятки" - доступность 99%, "четыре девятки" - 99,99%
Многие крупные компании в РФ сейчас целят в "три девятки" доступности (99,9%) на своих основных сервисах. Уверен, что у IT-гигантов РФ, Европы и Америки есть сервисы, для которых закреплен SLA и 99,99% (В одной компании вполне могут быть сервисы на "одну девятку" и четыре одновременно)
Неочевидность значений SLA заключается в том, что для бизнеса важен показатель в процентах, тогда как для разработчиков часто становится важен показатель "Сколько приложение может не работать в рамках дня\недели\месяца\года". Проблема только в том, что эти показатели тяжело приводить друг к другу.
Так, если бизнес захотел увеличить SLA с "двух девяток" до "трех девяток", то изменение в численном выражении получается менее 1%, тогда как время "простоя приложения" сокращается в 10 раз (с 14 минут до 104 секунд). Связано это с тем, что разработчикам важен именно тот самый 1%, который позволяет приложению "не отвечать", а увеличение SLA до 99,9% приводит к тому, что "один процент сокращается в 10 раз и превращается в 0,1%"
Это я к чему?
Имея 3 разных SLA (две девятки, три девятки, четыре девятки), вы можете получить 3 разных архитектуры вашей системы. Как минимум, система с SLA 99% будет слабо похожа на систему с SLA 99,99%, а ведь разница менее процента. Учитывайте это как при проектировании ваших приложений и сервисов, так и при участии в игре под название "Спроектируй мне Инстаграм за 60 минут" aka System-design interview