Основные принципы и методы SRE: действенные циклы
Если это действительно правда, что в некотором смысле "вы делаете то, что вы делаете", то мы пришли в сердце этого модуля. В этом уроке мы рассмотрим две методики, которые часто считаются основными в практике SRE. Оба исходят из принципа, что важно создать "добродетельные циклы". В этом контексте виртуозные циклы представляют собой методики, которые создают циклы обратной связи в организации, которая помогает организации постоянно улучшиться. У нас есть все последующие модули в точности эти две методики, поэтому мы собираемся только пропустить поверхность с обзором каждого из них здесь.
Действенный цикл № 1: SLI и SLO
Ранее в этом модуле мы подчеркнули нашу точку в отношении "соответствующего уровня надежности". В этом разделе именно место, где эта концепция привезена к медведю.
Предположим, у вас есть новая служба, которую вы планируете перенести в рабочую среду (созданную или созданную или которая все еще находится в процессе планирования). В рамках этого процесса важно принять некоторые решения о требуемой надежности. Если вы не пишете весь код самостоятельно, эти решения принимаются (и это важно) в сотрудничестве с разработчиками.
Первое решение заключается в том, что мы должны использовать в качестве индикаторов работоспособности службы (индикатор уровня обслуживания или SLI)? Другой способ задать этот вопрос: "Как вы знаете, когда это работает и работает хорошо?". Существует множество способов отслеживания SLI, и мы подробно рассмотрим некоторые более подробно позже. Но, как правило, эти показатели:
- Меры успешного выполнения и сбоя: успешно ли служба завершает операцию в процентах от времени?
- Меры времени: возвращали ли мы ответ в течение определенного порога времени?
- Меры пропускной способности: обрабатывается ли определенный объем данных?
Или, некоторые сочетания всех этих мер.
Проще говоря, индикатор SLI для нашей службы заключается в том, как часто она возвращала успешный результат, обозначенный кодом HTTP 200 (в отличие от кода 500 или какого-либо другого).
Теперь, когда у нас есть четкий индикатор, который сообщает нам, как работает служба, мы хотим решить, какой уровень надежности мы ожидаем или хотим от него. Например, мы ожидаем, что в течение дня скорость сбоя составляет 20 % от службы? Здесь мы используем большие и круглые числа, так как ими легче оперировать в самом начале. В последующих модулях мы увеличиваем сложность и точность инструкций, таких как это ("какие пользователи видят эту частоту ошибок? некоторые из них? большинство из них?" и так далее). Это предположение, выработанное совместно с разработчиком службы, называется целевым уровнем обслуживания (SLO).
В качестве показателя SLO следует использовать то, что можно точно измерить и представить в вашей системе мониторинга. Это должна быть цель, хорошо понятная цель для надежности службы. Что такое достаточно хорошее число? Здесь не должно быть никаких неопределенностей, таких как "ну, кажется, на прошлой неделе служба работала прекрасно, но точно сказать трудно". Либо служба встречает свой SLO, либо это не так. Данные должны быть четкими. Если SLO не выполняется (особенно многократно за определенный период времени), значит что-то пошло не так, и этим нужно заняться.
Запас по ошибке
Мы можем понять, что организация может привязаться к действию, если служба не соответствует его SLO. Однако SRE принимает эту концепцию еще один шаг вперед для случаев, когда SLO выполняется или превышается. Некоторые организации используют показатели SLO для формирования так называемого "запаса по ошибке".
Чтобы продемонстрировать эту идею, давайте возьмем для примера рассматриваемую службу и ее показатель SLO в 80 % успеха (воспринимайте это примерно как "служба должна работать 80 % времени"). При использовании SLO от 80% времени простоя мы объявили, что наша служба должна быть до 80 % времени. Но что же с остальными 20 %? Если служба не работает эти оставшиеся 20 % времени, нас это не волнует, так как мы решили, что эти 20 % не важны для нашей цели по обслуживанию.
Если мы не заботимся о том, что происходит в течение этого времени, что мы можем сделать с службой? Вне всяких сомнений, мы можем вмешаться в работу службы, обновив ее, например, до нового выпуска, добавляющего некоторые функции. Если этот новый выпуск работает нормально и не увеличивает время простоя, просто замечательно. Если этот новый выпуск приводит к тому, что служба будет менее стабильной и возвращает ошибки еще на 10 % времени по мере его отладки, по-прежнему хорошо. Мы находимся в рамках допустимого запаса по уровню ненадежности.
Запас по ошибке — это разница между потенциальной идеальной надежностью службы и ее требуемой надежностью (100 % – 80 % = 20 %). В этом случае бюджет ошибок дает нам фонд 20% ненадежности 20 % времени, когда мы "не заботимся о том, стоит ли это или нет, потому что это все еще в спецификации". Мы можем опираться и тратить, что 20% времени любой способ мы хотели бы (возможно, с большими выпусками) до тех пор, пока он не исчерпан так же, как любой другой бюджет.
В некоторых организациях запас по ошибке также применяется в менее благоприятном случае, когда не соблюдается SLO. В этом случае вы можете сделать что-то немного более строгое, чем просто "принять меры". Предположим, в нашей службе возникли некоторые проблемы и она работает всего 60 % времени, что определяется по выбранному ранее SLI. Мы не выполняем поставленную цель (SLO). Наша служба полностью использовала свой запас по ошибке. Организация может отказаться от запланированного выпуска, так как знает, что возмущение системы еще дальше на этом этапе, скорее всего, усугубит только ситуацию с надежностью. Обычно бюджеты ошибок вычисляются в течение заданного периода времени; месяц, четверть и т. д. Это вычисляется на последовательной основе, поэтому в конечном итоге, если надежность службы улучшается, этот бюджет возвращается.
В течение этого времени воротных выпусков организация может выбрать сводку некоторых инженерных ресурсов от разработки функций в сторону обеспечения надежности. С целью помочь выявить и улучшить источник проблем, которые заставили службу ударить свой SLO.
Мы говорим "некоторые организации", когда разговор заходит о запасе по ошибке, так как его реализация, особенно в случаях, когда он используется для пропуска выпусков, требует некоторого коллективного участия. Когда столкнулась с решением о выпуске, организация должна быть готова отложить выпуск, если надежность службы на сегодняшний день не была в состоянии заглушить. Это решение не является одним из того, что все организации готовы принять. Это решение также не является единственным возможным ответом на истощенный бюджет ошибок, но это один из самых разговоров.
В отдельном модуле мы подробно поговорим о соглашениях об уровне обслуживания, соглашениях об уровне обслуживания и бюджетах ошибок. Тем не менее, стоит здесь подчеркнуть виртуозный аспект этих практик. В теории это позволяет организации описывать, общаться и действовать над надежностью службы. Хотя это делается таким образом, чтобы все работали в направлении повышения надежности. Этот контур обратной связи может быть чрезвычайно важен.
Действенный цикл № 2: безобвинительное рассмотрение ситуации
Идея посмертного анализа — ретроспективного анализа значительного, как правило, нежелательного события, не является даже удаленной для инженерии надежности сайта. Она даже не является уникальной для операционной среды. Одной действительно отличительной чертой является настойчивое требование SRE того, чтобы рассмотрение ситуации было именно безобвинительным. Одни должны быть посвящены сбою процедуры или технологии, составляющему инцидент, но не действиям конкретных людей. "А как поступить с использовавшейся процедурой, которая позволила X выполнить операцию, ставшую причиной сбоя? Какие сведения были недоступны либо даже очевидны этому человеку, из-за которых он пришел к неправильному заключению? Какие охранники должны были быть на месте, чтобы было невозможно иметь такой катастрофический сбой?" Эти вопросы сортируются в безвинном постморте.
Тон и направленность этих вопросов имеет значение. Мы ищем способы улучшения систем или процессов, а не способов наказать лиц, чьи использование этих систем или процессов в доброй вере способствовали сбою. Важно помнить: "Вы не можете запустить свой путь к надежности". В нашем опыте организация, которая пожарит человека каждый раз, когда есть производственный инцидент (с несколькими исключениями), не учится на этих инцидентах. Вместо этого, они остаются с одним человеком, трясясь в углу, боясь внести любые изменения в что-либо вообще.
Однако налаженный процесс безобвинительного рассмотрения ситуации в организации формирует действенный цикл. Она позволяет организации учиться на своих сбоях и постоянно улучшать свои системы (обеспечивая надлежащий анализ и дальнейшие действия выполняется).
Такое отношение к сбоям и ошибкам, которые организация рассматривает как возможности для расширения опыта и совершенствования, является ключевым принципом обеспечения надежности информационных систем. Другим является создание действенных циклов, позволяющих использовать подобные возможности и направляющих организацию к повышению уровня надежности.
Давайте рассмотрим некоторые другие принципы и методики, сосредоточенные на человеческой стороне SRE, в следующем уроке.