Close

Путь к успешному управлению инцидентами начинается здесь

Просмотр тем

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

Каждая команда разработки, операционный отдел и ИТ-команда знает, что инциденты иногда случаются.

Даже крупнейшие компании с самыми талантливыми сотрудниками, известные своей почти 100-процентной бесперебойной работой, иногда сталкиваются с выходом систем из строя. Просто посмотрите на Apple, Delta или Facebook: им всем приходилось терпеть убытки в десятки миллионов долларов в результате инцидентов за последние пять лет.

На самом деле соглашение об уровне обслуживания (SLA) никогда не должно обещать 100-процентной безотказной работы. Потому что ни одна компания не может сдержать такое обещание.

Если ваша компания очень хорошо избегает инцидентов или разрешает их, возможно, вам удается стабильно превосходить свой целевой показатель времени безотказной работы. Например, вы обещаете 99-процентную бесперебойность вашей работы, а в действительности близки к 99,5 %. Либо вы обещаете 99,5 % времени безотказной работы, а на самом деле обычно достигаете 99,99 % в течение месяца.

Однако когда так происходит, отраслевые эксперты не рекомендуют формировать у пользователей слишком высокие ожидания и постоянно увеличивать свои обещания. Вместо этого необходимо считать дополнительные 0,99 % бюджетом ошибок, т. е. временем, которое компенсирует возможные риски вашей команды.

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

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

Например, если соглашение об уровне обслуживания (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 % допустимого времени простоя. Ниже приведены распространенные целевые показатели.

цель SLA

Ежегодно допустимый простой

Ежемесячно допустимый простой

99.99% uptime

Ежегодно допустимый простой

52 минуты, 35 секунд

Ежемесячно допустимый простой

4 минуты, 23 секунды

99,95% безотказной работы

Ежегодно допустимый простой

4 часа, 22 минуты, 48 секунд

Ежемесячно допустимый простой

21 минута, 54 секунды

99,9% безотказной работы

Ежегодно допустимый простой

8 часов, 45 минут, 57 секунд

Ежемесячно допустимый простой

43 минуты, 50 секунд

99,5% безотказной работы

Ежегодно допустимый простой

43 часа, 49 минут, 45 секунд

Ежемесячно допустимый простой

3 часа, 39 минут

99% безотказной работы

Ежегодно допустимый простой

87 часов, 39 минут

Ежемесячно допустимый простой

7 часов, 18 минут

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

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

продолжение темы
DevOps