Что такое бюджет ошибок и почему он важен?

Что такое бюджет ошибок?

Бюджет ошибок — это максимальное время, в течение которого техническая система может выходить из строя без оговоренных в соглашении последствий.

Например, если соглашение об уровне обслуживания (SLA) указывает, что системы будут работать 99,99 % времени, а при нарушении этого обязательства компания должна будет компенсировать клиентам убытки из-за сбоя работы, то это означает, что ваш бюджет ошибок (или время, на которое ваши системы могут выходить из эксплуатации без последствий) составляет 52 минуты и 35 секунд в год.

Если в соглашении SLA обещается 99,95 % времени безотказной работы, бюджет ошибок составляет 4 часа, 22 минуты и 48 секунд. Если в соглашении SLA обещается 99,9 % времени безотказной работы, бюджет ошибок составляет 8 часов, 46 минут и 12 секунд.

Зачем техническим командам нужны бюджеты ошибок?

На первый взгляд, бюджеты ошибок не так уж важны. Разве это не просто еще одна метрика для ИТ-специалистов и DevOps, которую нужно отслеживать, чтобы убедиться, что все работает правильно?

Ответ, к счастью, «нет». Бюджеты ошибок — это не просто хороший способ убедиться, что вы выполняете договорные обязательства. Они также дают возможность командам разработчиков внедрять инновации и рисковать.

В нашей статье по SRE мы объясняем:

«Команда разработчиков может потратить этот бюджет ошибок, как ей захочется. Если продукт в настоящее время работает безупречно, с небольшим количеством ошибок или вовсе без них, разработчики могут запускать в любой момент все, что захотят. И наоборот, если они потратили или превысили бюджет ошибок и работают на уровне, определенном в SLA (или ниже его), то запуск любых новых возможностей замораживается до тех пор, пока команда не уменьшит количество ошибок до уровня, позволяющего продолжить запуск».

Преимущество этого подхода заключается в том, что он побуждает команды минимизировать реальные инциденты и максимизировать инновации, принимая на себя риски в разумных пределах. Он также устраняет разрыв между командами разработчиков, целями которых являются инновации и гибкость, и операционным отделом, который занимается стабильностью и безопасностью. До тех пор, пока время сбоев работы остается маленьким, разработчики могут сохранять свою гибкость и продвигать изменения, не затрудняя работу операционного отдела.

Как использовать бюджет ошибок

Во-первых, вам нужно свериться с соглашением об уровне обслуживания (SLA) и целевыми показателями уровня обслуживания (SLO). Какие цели вы уже поставили перед собой в отношении безотказной работы или успешного выполнения системных запросов? Какие обещания ваша компания дала клиентам? Все это будет определять ваш бюджет ошибок.

Бюджеты ошибок на основе времени безотказной работы

Большинство команд отслеживают время безотказной работы на ежемесячной основе. Если время доступности больше времени, обещанного в SLA или SLO, команда может выпустить новые возможности и принять на себя связанный с этим риск. Если оно меньше целевого показателя, обновления функциональности останавливаются до тех пор, пока целевые показатели не вернутся в нужное русло.

Чтобы эффективно использовать этот метод, вам нужно будет перевести цель SLO (обычно процент) в реальное время, в течение которого смогут работать ваши разработчики, т. е. вычислить количество часов и минут, на которое фактически приходится 1 %, 0,5 % или 0,1 % допустимого времени простоя. Ниже приведены распространенные целевые показатели.

Бюджеты ошибок на основе успешных запросов

Соглашения SLO вызывают меньше неодобрения, чем SLA, но могут создать не меньше проблем, если будут расплывчатыми, излишне усложненными или не поддающимися измерению. По мнению инженеров, главная черта хороших соглашений SLO — простота и ясность. Претендовать на статус SLO могут только самые важные показатели. Цели должны быть изложены простым языком и, как и в случае SLA, должны всегда учитывать такие проблемы, как задержки на стороне клиента.

Соблюдайте SLA с помощью Jira Service Management: решайте запросы на основе приоритетов, используйте правила автоматической эскалации, чтобы отправлять уведомления нужным участникам команды и предотвращать нарушения SLA.