Это расшифровка эпизода. Посетите веб-сайт подкастов, чтобы посмотреть записи, показать заметки и получить бесплатные подарки.
Индикаторы уровня обслуживания, цели уровня обслуживания и соглашения об уровне обслуживания создают иерархию. Индикаторы уровня обслуживания определяют номер. Цели уровня обслуживания устанавливают цель для числа. Соглашения об уровне обслуживания определяют правила и ожидания относительно того, когда цель достигнута или не достигнута.
Это мощные инструменты для согласования заинтересованных сторон и определения приоритетов. Каждый основан на другом, поэтому давайте работать снизу вверх, начиная с индикаторов уровня обслуживания.
SLI, или индикаторы уровня обслуживания, количественно определяют аспекты предоставляемой услуги. Примеры включают задержку, время безотказной работы и частоту ошибок. Используйте этот шаблон для определения SLI: пустой, измеренный пустым. Вот пример: показатель успешности, измеряемый количеством успешных HTTP-запросов, разделенным на общее количество HTTP-запросов. Выразите SLI как отношение общего количества товаров к общему количеству событий. Это обеспечивает скользящую шкалу между нулем и сотней.
Существует бесконечное количество вариантов SLI, поэтому их следует выбирать тщательно, чтобы измерить ценность предоставляемой услуги. Задайте этот вопрос в качестве внутренней проверки при рассмотрении SLI: «Не потеряет ли сервис пользователей, если на этот показатель повлияет негативное влияние?»
Так какой правильный номер? Это число является SLO или целью уровня обслуживания. Ясно, что 0 — это неправильное число, потому что это означает, что все сломано. С другой стороны, 100% — неправильный ответ, потому что это означает, что ничего не ломается. Это невозможно. Реальный ответ заключается в том, что это просто зависит от бизнеса.
SLO находится на пересечении продукта и разработки. Заинтересованные стороны должны согласиться с тем, что если SLO падает ниже порогового значения, то стоит перераспределить приоритеты работы для достижения SLO. Означает, что ответственная сторона может взяться за новую работу или отказаться от существующей работы, чтобы сохранить ее. С другой стороны, это означает, что необходимо работать таким образом, чтобы поддерживать надежность таким образом, чтобы SLO не опускался ниже порогового значения.
Как только SLO определен, заинтересованные стороны могут заключить соглашение о том, как поддерживать SLO и что делать, если он пропущен. Это соглашение об уровне обслуживания или SLA. Обычно они принимают форму финансовых санкций или других негативных последствий, прописанных в договоре. Эти соглашения заключаются между потребителем и поставщиком.
Однако я сосредоточен на соглашении между теми, кто отвечает за поддержание СРБ. В литературе по проектированию надежности площадок рекомендуется использовать для этого бюджет ошибок.
Вот пример. Скажем, SLO составляет 99% в квартал. Это обеспечивает бюджет ошибки 1%. Таким образом, если проблема вызывает частоту отказов 0,5%, то используется 50% бюджета ошибок.
Бюджет ошибок — это объективный способ управления рисками в отношении SLO. Команда может принять решение о рискованной миграции базы данных, когда бюджет ошибок будет заполнен. С другой стороны, команда может быть более консервативной, когда бюджет невелик, сосредоточившись на релизах с низким уровнем риска. Бюджет ошибок позволяет командам сбалансировать риск, инновации и надежность. Это предполагает, что все заинтересованные стороны принимают бюджет ошибок как средство планирования и поддержания SLO. Другими словами, если бюджет ошибок исчерпан, выпуски могут быть невозможны. Согласны ли с этим заинтересованные стороны?
Вот тут-то друзья и есть трудная проблема. Измерить что-либо — простая задача. Предоставление СРБ права менять приоритеты — трудная задача. Вот почему так важно, и я не могу переоценить это, что SLO напрямую связан с успехом в бизнесе. Ему нужны зубы!
Многие команды не решают трудную задачу. В результате SLO представляют собой театр кабуки или относятся к какой-либо электронной таблице KPI. В основном это был мой опыт. Однако у меня есть положительный опыт работы с хорошо разработанными SLO и соглашением об их соблюдении.
Наконец, я хочу вернуться к доставке программного обеспечения и трем способам DevOps.
SLI и SLO обеспечивают обратную связь с процессом доставки программного обеспечения. Обратная связь — это второй способ DevOps. Команды не могут оценить свой прогресс без обратной связи с производством. SLO обеспечивают обратную связь со всеми заинтересованными сторонами, будь то инженеры, руководители предприятий или менеджеры по продуктам. Обратная связь — это вторая половина цикла непрерывной доставки. Быстрый поток — А.К.А. непрерывная доставка — происходит только при быстрой обратной связи.
SLO также не статичны. Они будут меняться по мере изменения бизнеса. Предприятия на ранней стадии могут брать на себя больший риск, чем устоявшиеся предприятия. Со временем системы могут измениться до такой степени, что сохранение SLO негативно скажется на бизнесе. Поддержание SLO — это бесконечный процесс балансировки, требующий обратной связи от заинтересованных сторон и гибкости для их улучшения с течением времени. Это акт постоянного улучшения — также известный как третий путь DevOps.
Многие темы, связанные с доставкой программного обеспечения, проектированием выпуска или обеспечением надежности сайта, связаны с SLO, поэтому не забывайте о них. Они обязательны для восхождения по иерархии потребностей SRE. Обратитесь к книге SRE и книге SRE за примерами определения, определения и реализации всего, что обсуждалось в этом эпизоде.
