Всем привет! Меня зовут Марина Калетурина, я SRE-инженер маркетинговой платформы. Мои продукты — истории, офферы, подкасты, персонализации и прочие вещи, которые отвлекают людей от пользования банковскими услугами. 

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

Как мы считаем надежность

SLI — индикатором является выражение из метрик error_count / request_count × 100;

SLO — граница, после которой мы считаем поведение сервиса проблемным: error_count / request_count × 100 < 1;

SLA — коэффициент, определяющий бюджет ошибок и толерантность к риску: error_count / request_count × 100 < 1 в течение 99% времени.

Есть некий индикатор, обычно это какие-то метрики. Кто-то берет долю успешных ответов, кто-то абсолютное выражение, все что угодно. Например, я для своих соглашений хочу, чтобы доля ошибок была меньше 1%. 

В качестве метрик-индикаторов мы используем «золотые» сигналы: задержку, размер трафика, количество ошибок, очень редко — насыщенность (saturation). Мы задаем, сколько времени должны выдерживать этот критерий, допустим 99%. Затем собираем метрики-индикаторы в одно соглашение и получаем некоторый бюджет. 

Наши услуги ранжируются по степени важности для бизнеса. Скажем, моя зона ответственности считается критически важной, то есть вместо 91% должно быть не меньше 99,8%. А согласно последним исследованиям, переход к 99,9 в 10 раз дороже по стоимости оперирования и разработки. То есть можете примерно оценить, сколько нужно потратить денег, чтобы сделать 99,8 из 91.

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

Я всегда удивлялась, почему все показывают 100% или целевые значения, а я прихожу каждый раз с 91, 85, 94. Поэтому выработала пять способов казаться надежнее.

Способ «Меньше — больше»

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

Поэтому нужно уменьшать количество индикаторов. Вот пример из нашей внутренней системы:

Мы не учитываем ни входящий трафик, ни долю ошибок. Сейчас уже соглашение не такое скромное, потому что был сбой, который мы не заметили по этим индикаторам.

Другой пример, с лишь одним уровнем задержки:

Неважно, отвечаем мы или нет, главное — быстро. Думаю, многие используют такой подход: не добавляют индикаторы входящего трафика.

Способ «Оттягивание неизбежного»

Под «неизбежным» я имею в виду SLO. Рассмотрим пример:

Это количество пятисотых ошибок. Кажется, что система работает просто огненно. А ведь все наши системы очень высоконагруженные, и границу в 10—15 ошибок в минуту очень легко преодолеть. Но давайте посмотрим на входящий трафик:

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

Способ «Расширение окна усреднения SLI»

Я часто замечаю этот способ у других. Называется он «Расширение окна усреднения SLI». Вот доля пустых ответов относительно запросов:

Около 22 часов произошел всплеск. Хотелось бы, чтобы он не вычел две минуты из бюджета ошибок, их и так мало. Особенно если всплеск происходит каждую ночь. Так как у нас бюджет по времени, хорошим тоном будет рассчитывать все подобные индикаторы в окне размером одна минута. И если мы начнем это усреднять, то за час всплеск окажется уже меньше. Хотя все равно потратит часть бюджета:

Расширим окно до шести часов — и вот уже в рамках SLO мы не тратим бюджет:

Если вас вдруг спалят, можете говорить так: «Это наш способ сделать так, чтобы оповещения не шумели, а бюджет не тратить». Поменяйте тему, и вам поверят.

Способ «Ставки понижены»

«Ставки понижены», или «Перцентили понижены». Я фанат перцентилей в задержке и люблю смотреть на максимум. Вообще не признаю 95-й и ниже. Но многим боязно добавлять в свои соглашения максимум среди 99-х перцентилей. Люди называют это шумом или как-нибудь иначе.

Допустим, у нас есть метод, который должен отвечать за 5 секунд, но, как мы видим, он работает даже 250 миллисекунд. То есть что-то очень прекрасное. Назовем этот индикатор «Максимальное время ответа». Божественный уровень надежности и производительности. Но давайте посмотрим, как построен запрос:

Оказывается, внутри не максимальное, а среднее время ответа. То есть назвать индикатор можно как угодно, а внутри использовать среднее или какие-либо низкие перцентили, и тогда будут очень хорошие результаты. И если не упоминать перцентиль в названии, то никто и не подумает.

Способ «Все врут»

«Все врут», или «По нашим метрикам все хорошо». Это один из самых сложных случаев, который мне встречался.

Есть индикатор session_info — один из ключевых внутренних методов. Выше — его график во время очень большого сбоя, когда пользователи не могли залогиниться, ничего не загружалось. При этом, судя по графику, метод работал прекрасно. 

Естественно, возникли вопросы, потому что системы, которые работали с этим методом, работали достаточно плохо. Знаете, в медицине бывает так: врачу нужно измерить какие-то показатели, а он не может этого сделать по каким-то причинам — тогда он начинает брать кровь, хотя она не покажет того, что нужно. Так и индикаторы можно сделать такими, чтобы они не показывали то, что не нужно. 

В описанном примере работа метода измерялась внутри приложения. Но чтобы это выяснить, нам пришлось пройти по цепочке балансировщиков и веб-серверов. А когда построили график на входе, получилось вот что:

Любопытно, что в момент сбоя метод на самом деле работал хорошо. Но вне времени сбоя он выходил за пределы SLO.

Вы можете изменять свои индикаторы и их отчеты, меняя место измерения. Можно прямо в коде сэмплировать количество ошибок, срезать задержку, задать какие-нибудь максимальные значения. Конечно, со временем вы начнете путаться и ваша система станет и вас обманывать. Но если все делать правильно, возможно, это поможет сделать отчеты красивее.

Что делать с этими знаниями

Вы спросите: «Получается, если я хочу завтра начать показывать в отчетах 99,8, мне нужно выкинуть сбойные индикаторы, остальным поднять SLO, начать все усреднять, понижать percentage latency и измерять все максимально далеко от пользователя?» Как вы думаете, сколько из компаний, которые гордо показывают девятки, достигают этого честно?

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

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

Нельзя по подобным отчетам сравнивать команды и услуги, кто более успешный, классный, продвинутый, если нет каких-то общих регламентов. Потому что у кого-то могут быть 95%, или 99%, или 1%, или 15%. Для описания ситуации нужно иметь дополнительные измерения, такие как доля ошибок. Еще рекомендую сделать request-based SLA, когда бюджет ошибок — это не время, а запросы. 

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

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