Error budget это

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

Книга Google о SRE, статьи экспертов, документация и обучающие курсы дают исчерпывающие знания о том, как в идеале должен работать SRE в компаниях. Правда, ключевое здесь – «в идеале». Работа с метриками и управление инцидентами в командах может сильно различаться по ряду причин: количество людей в команде, скорость выкатки нового функционала, число микросервисов, распределение компетенций и тд.

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

Как работает бюджет ошибок

Error budget (бюджет ошибок) – четкая и объективная метрика, которая рассчитывается на основе SLO (Service-Level Objective, внутренний показатель качества работы сервиса). Она определяет, насколько ненадежным может быть ваш сервис в течение одного квартала и помогает разработчикам договариваться с SRE при принятии решения о допустимом уровне риска.

Другими словами, бюджет ошибок (как его иногда называют, «право на ошибку») – это количество ошибок, которые ваш сервис может накопить за определенный период времени, прежде чем ваши пользователи станут недовольны. Вы можете думать об этом как о терпимости к боли для ваших пользователей, но применительно к определенному параметру вашего сервиса: доступности, задержке и так далее. 

У компании может быть очень много сервисов и у каждого из них свой собственный error budget, который определяется по степени критичности сервиса. То есть, чем критичнее сервис, тем жестче бюджет ошибок.  

Измерение надежности сервисов

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

  • По времени: один из популярных вариантов подсчета, когда оценивается сколько времени доступен или недоступен сервис. Например, если бюджет на ошибки содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже был недоступен, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски. Как вариант, остановить выпуск фич и сосредоточиться на баг-фиксах. 

  • Per request (по запросу): подходит для контроля надежности именно внутри сервисов. Каждый запрос отмечается, как успешный или неуспешный. Соблюдено SLO или нет, уложился ли сервис в те критерии, которые в него вложили? Если сервис не отвечает, значит он не соблюдает свои SLO, следовательно, запрос считается ошибочным. В этом случае одинаково выглядит, отвечает сервис слишком долго либо отвечает ошибкой. После рассчитывается соотношение «хороших» и «плохих» запросов. 

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

Что ставить в SLO на первых порах

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

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

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

Когда нужно пересматривать SLO

Пересмотр SLO – регулярный процесс. На старте SLO можно пересматривать раз в две недели, потом раз в месяц. Что-то менять придется до тех пор, пока SLO не стабилизируется и не будет согласован с командами разработки и стейкхолдерами, которым этот сервис принципиален. 

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

Пересматривать метрики придется в любом случае. Во время разбора инцидента проверяется, как стригерились метрики бюджета ошибок, как вели себя метрики SLO, соблюдались они или нет, показали ли они проблему или не показали, пробило ли это бюджет. Если бюджеты исчерпались, значит где-то что-то не так считалось. Каждый раз вам нужно обосновывать, ожидаем ли был инцидент или нужно пересматривать метрики. 

Если error budget исчерпывается каждую неделю

Вот вы дошли до настройки метрик и заложили бюджет ошибок на 1-2 недели. А потом бюджет начал не соблюдаться каждую неделю. Что делать? Застопить всю разработку и выкатку релизов? Получается не очень реалистичная картинка. 

Когда вы только начали внедрять error budget, расходовать месячный бюджет за пять дней – это нормально. Эти границы ставятся не для того, чтобы шокировать команду разработки, а чтобы менеджмент понимал, что что-то идет не так. На первых порах бюджет ошибок нужно регулярно пересматривать: 98% за неделю было слишком жестко, поставьте 97% или 96%. Двигайте границы до тех пор, пока они не соприкоснуться с реальным отражением вашей системы. Только тогда начинайте улучшать. 

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

Как еще измерить стабильность системы

Помимо стандартного подсчета девяток или какой-то другой метрики можно совместно с бюджетом ошибок просчитывать ABDEX по всем сервисам, критичным и конечным точкам. 

ABDEX (Application Performance Index) – это числовая мера удовлетворенности пользователей производительностью приложений. Для расчета Apdex используются статистические данные с программных счетчиков, содержащие: наименование операций, время начала каждой операции, и длительность исполнения каждой операции приложением. 

Далее эти данные за период (например, сутки) компонуются по наименованию/операции, затем для каждой операции: производится агрегация всех значений длительности выполнения этой операции, относительно целевого времени, на три зоны «отзывчивости» по отношению к пользователю: довольны, удовлетворены, разочарованы. 

Application Performance Index дает более полную картину и показывает явную деградацию сервиса, если она присутствует. Какой толк от четырех девяток, если эндпоинт сервиса отвечает по 500+мс. Классический подсчет по бюджету ошибок этого не учитывает, а нам все-таки нужно не только отдать 200, но и достаточно быстро это делать.  

Должен ли SRE коммитить в код

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

Как еще может быть: 

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

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

  • SRE может вносить правки в код сервиса игнорируя правила и пуша напрямую в мастер, если произошел глобальный инцидент или того требуют обстоятельства. Также он может вывести из-под нагрузки элемент инфраструктуры или перебалансировать трафик. Зачастую команда SRE не видит этот код ежедневно, поэтому ей понадобится больше времени в нем разобраться во время инцидента. Поэтому компании гораздо дешевле и быстрее позвать разработчика. 

Резюмируем: SRE-инженерам не всегда нужно лезть в код, но они могут это сделать, если того требуют обстоятельства или их должность в компании совмещена с разработкой. Кроме того, SRE-инженеры могут сами писать тулинги, обвязки и все то, что позволит добавлять более глубокие автоматизации.

Немного про дежурства и мониторинг

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

Как может выглядеть дежурство: 

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

Если говорить про мониторинг и реакцию не него, то, обычно, есть первая линия поддержки. Она реагирует, если пришло оповещение о проблеме. SRE – это вторая или третья линия поддержки, которая, как правило, не занимается круглосуточным наблюдением за мониторингом. 

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

Старт практического курса SRE: data-driven подход к управлению надёжностью систем 28 февраля.

Итог

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

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

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

  • Пересматривать метрики придется в любом случае. Во время разбора инцидента проверяйте, как повел себя бюджет ошибок, как вели себя метрики SLO, соблюдались они или нет, показали ли они проблему или не показали, пробило ли это бюджет. Каждый раз вам нужно все обосновать. 

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

  • И хотя в книге Google SRE-инженеры – в первую очередь разработчики, в реальности существует гораздо больше вариаций. Однако SRE-инженера, который как-то взаимодействует с кодом, вы встретите чаще, чем SRE-инженера, который с ним вообще не работает.

Как грамотно внедрять практики SRE

28 февраля стартует новый поток обновленного курса «Site Reliability Engineering: data-driven подход к управлению надежности систем». Будем учиться три недели, за которые вы разберете современные практики SRE и инструменты для повышения доступности и надежности ваших IT-систем, включая мониторинг, автоматизацию, оптимизацию процессов и управление инцидентами.

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

На курсе вы

  • узнаете, как снизить ущерб от отказов в будущем;

  • внедрите правки прямо в прод;

  • узнаете, как решать конкретные проблемы, связанные с надежностью сервиса;

  • поймете, какие метрики собирать и как это делать правильно;

  • научитесь быстро поднимать продакшн силами команды.

Помимо того, что учиться будет интересно, благодаря новым знаниям и практике вы сможете настроить:

  • мониторинг SRE-метрик (SLO, SLI, error budget) для своего сервиса. Поймете как эти метрики выбрать;

  • мониторинг SRE-инфраструктурных сервисов. Сможете опознавать и решать проблемы с инфраструктурой;

  • alerting и healthcheck;

  • разные методы деплоймента и будете знать, какие инструменты для этого существуют.

  • пожарную команду в случае инцидента, раздать роли коллегам и выступить лидером.

  • надежные коммуникации между сервисами retry, timeout, circuit breaker.

Вас ждут теория и AMA-cессии в течении недели,  а также субботние 4-часовые практики, чтобы спокойно погрузиться в профессию и потрогать инструменты.

Для команд от 5 человек у нас хорошие скидки, а для тех, кто оплачивает не от компании — рассрочка, и возможность вернуть 13% 

Количество мест ограниченно. Подать заявку и узнать подробности.

Источник

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

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

Даже крупнейшие компании с самыми талантливыми сотрудниками, известные своей почти 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, должны всегда учитывать такие проблемы, как задержки на стороне клиента.

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

Источник

DevOps, Системное администрирование, Микросервисы, Kubernetes, Блог компании Proto

Рекомендация: подборка платных и бесплатных курсов Python — https://katalog-kursov.ru/

Сегодня мы хотим обсудить практическую сторону внедрения концепций Service Level Objectives и Service Level Indicators. Рассмотреть, что входит в понятия SLI, SLO и Error budget, как рассчитывать эти показатели, как за 7 шагов внедрить их отслеживание и как в последствии контролировать эти показатели на примере инструмента Instana.

Определимся с терминологией

Service Level Indicator (SLI) – это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее – это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % — означает отличный пользовательский опыт, а 0% — ужасный.

Service Level Objectives (SLO) – это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.

Также важно понимать, что SLO – это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.

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

В концепции SLI и SLO присутствует индикатор Error Budget или, как его иногда называют, «право на ошибку». Error Budget – это степень невыполнения наших SLO. Например, если наш SLO учитывает доступность, то error budget – это максимальное время, в течение которого наша система может быть недоступной без последствий для нас и нашей команды.

Использование данного показателя упрощает командам процесс контроля времени недоступности приложений/сервисов посредством ввода наглядного индикатора. Устанавливая Error Budget, мы ставим для себя цель – не выйти за рамки разрешенного нам самим downtime.

Например, если в качестве SLI для одного из наших приложений у нас указана метрика Availability, а в качестве SLO для этого SLI мы указали значение 99,95% в месяц, то наш Error Budget за месяц (30 дней) составит 21 минуту 54 секунды. Конкретную цифру Error Budget можно не рассчитывать самостоятельно, а воспользоваться готовым калькулятором.

Для анализа текущего положения дел с Error Budget с учетом установленного SLO/SLA и среднего показателя Availability на момент расчета, можно использовать вот такой калькулятор.

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

7 последовательных шагов по имплементации SLO

  1. Определяем сервисы, критичные с точки зрения пользовательского опыта.

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

  2. Для выбранных сервисов определяем набор метрик, которые войдут в наш SLI.

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

  3. Определяем текущее распределение значений выбранных метрик.

    Если вы используете промышленное APM решение, то скорей всего вам уже доступно определение baseline метрик. Например, мы видим, что у транзакции чекаута время исполнения по 90-му перцентилю равняется 110 мс за последние две недели.

  4. Определяем SLO, учитывая нормальное поведение выбранных метрик или данных по baseline и устанавливаем Error Budget.

    Использовать «в лоб» текущие значения производительности как целевые — не совсем корректная практика, ведь SLO – это цель, к которой нужно стремиться, и она может и должна формироваться не только исходя из технических критериев и текущей ситуации. Но на практике проще оттолкнуться от измеренного значения и подкорректировать целевое, с учетом тех действий, которые позволят достичь этой цели.

    Например, можно установить порог 110 мс по 90-му перцентилю и SLO в 95%. Это будет означать, что мы допускаем 5% времени, в которое время исполнения транзакции по 90-му перцентилю будет выше 110 мс.

  5. Прописываем процедуру действий на случай истощения Error Budget

    Важно заранее продумать, что мы будем делать в случае истощения Error Budget. В процедуру реагирования можно включить следующие действия:

    1. Оповещение при превышении Error Budget

    2. Повышение приоритета для команд разработки и DevOps у работ по восстановлению доступности сервиса перед работами по выкатке новых фич на определенный период времени.

    3. Lessons learned, post mortem и другие документы – фиксация причин превышения Error Budget в каждом конкретном случае в базу знаний и работа над ошибками.

  6. Отслеживаем выполнение установленных нами SLO для соответствующих SLIs во времени.

  7. Оцениваем результаты внедрения SLI SLO, как и с любым процессом, следующим логике Plan-Do-Check-Act. Лучше начать с небольшого количества SLO, определить достижимые цели, научиться отслеживать показатели и проводить улучшения постепенно.

 А теперь давайте посмотрим, как концепция SLI SLO реализована в инструменте Instana. 

Реализация концепции SLO и SLI в Instana

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

В Instana определить пути пользователя по приложению можно с помощью функции Application Perspective. Подробнее о том, как еще использовать Application Perspective, можно прочитать в нашем посте — Observability система для микросервисов на примере Instana, часть 1 

Для создания Application Perspective перейдем в интерфейсе Instana к разделу Application, кликнем на «New Application Perspective».

 В появившемся окне будут предложены варианты Application Perspective. Выбрав «a critical user journey», мы укажем, какие сервисы и эндпоинты входят в «путь пользователя». А если говорить проще – то мы определили какие сервисы и эндпоинты входят в одну из бизнес-транзакций, по которой необходимо определить SLO.

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

Конфигурация SLI

Создадим новый кастомный дашборд. 

На котором добавим SLO виджет и выберем созданное ранее Application Perspective. 

Кликнув на «Manage SLI» перейдем к списку всех доступных индикаторов для выбранного Application Perspective.  

Выбрав «Create SLI», мы перейдем к созданию SLI.

Для создания индикатора:

  1. Укажем имя индикатора.

  2. Определим тип индикатора: Time-Based или Event-Based.

  3. Определим границы для вызовов: Inbound Calls или All Calls. 

    1. Inbound calls: Все входящие вызовы в рамках сервисов входящих в Application Perspective.

    2. All calls: Все входящие вызовы в рамках Application Perspective и исходящие вызовы из Application Perspective.

  4. Укажем необходимую конфигурацию в зависимости от выбранного типа индикатора. 

  5. Сохраним SLI кликнув на “Create”.

Time Based SLI

Time-Based индикатор – основывается на значениях выбранной метрики (временного ряда). Среди доступных метрик: 

  • Latency – время исполнения вызовов;

  • Call Count – количество вызовов;

  • Error Rate – процент ошибок;

  • Erroneous Calls – количество вызовов, содержащих ошибку.

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

В процессе установки SLI мы:

  • Определяем область действия этого индикатора — можем выбрать как конкретный сервис, так и использоваться все сервисы входящие в Application Perspective. Для более детального определения можем указать конкретный эндпоинт сервиса. 

  • Выбираем метрику, которая войдет в  SLI.  Это может быть — Latency, Call Count, Error Rate, Erroneous Calls.

  • Определяем, как будем агрегировать значение метрики: по перцентилям (90, 50, 99 и т.д.), по среднему значению, по минимальному или максимальному значению.

  • Определяем пороговое значение метрики.

 
После того, как мы указали метрику и ее пороговое значение, SLI рассчитается по формуле: 

SLI = (1 - #minutes_where_threshold_is_violated / #minutes_in_time_window) * 100% 

Посмотрим на пример настройки Time-Based индикатора. 

 Все вызовы сервиса proto.group должны исполняться в среднем не более чем за 25мс.  

Event-Based SLI

Event-Based индикатор основывается на «хороших» и «плохих» событиях.

«Хорошие» события — это набор вызовов, которые указывают на положительное качество работы сервиса, например, 2хх HTTP статус коды.

«Плохие» события – это набор вызовов, которые указывают на отрицательное качество работы сервиса, например, 5хх HTTP статус коды. 

В ходе настройки Event-Based SLI мы: 

  • С помощью фильтров определим, какие вызовы указывают на положительное качество работы сервиса;

  • С помощью фильтров, определим, какие вызовы указывают на отрицательное качество работы сервиса.

SLI в таком случае рассчитывается по формуле: 

SLI = #good_events / (#good_events + #bad_events) * 100%  

Рассмотрим пример настройки Event-Based индикатора. 

 Мы определили, что «хорошие» события – это все вызовы с 2хх HTTP статус кодом, а «плохие» — все вызовы с 5хх HTTP статус кодом. 

SLO отчет

В Instana SLO отчет предоставляется в виде «виджетов», которые можно добавить на свои кастомные дашборды. Виджеты позволяют проанализировать качество работы предоставляемого нами приложения/сервиса за определенный период времени.  

На представленном примере виджета – Robot Shop SLO. Мы используем метрику времени исполнения транзакции добавлении товара в корзину, как ключевой индикатор SLI, значение метрики должно не превышать 20мс. 

SLO рассматриваем за выбранный промежуток времени – 24 часа, и нам доступно 72 минуты на простой нашего сервиса (Error Budget). На дашборде выше мы видим, что SLO нарушался 116 минут за выбранный промежуток времени, наш Error Budget превышен на 44 минуты.  

Еще пример SLO отчета для Event-Based SLI:

Конфигурация SLO виджета 

 В этом разделе мы расскажем, как создать SLO Widget для любого Application Perspective. 

 Перейдем на свой кастомный дашборд и добавим SLO виджет, просто кликнув на “Add Widget”:

 В открывшемся окне перейдем на вкладку SLO и для настройки сделаем следующее:

  1. Укажем имя виджета.

  2. Выберем Application Perspective/критически важный пользовательский путь, по которому нужно задать SLO 

  3. Выберем заранее созданный целевой индикатор SLI для выбранного Application Perspective.  

  4. Определим цель SLO которую нужно достичь 

  5. Выберем временной период, за который будет рассчитываться SLO: 

    1. Dynamic time window – SLO будет рассчитываться за период, который указан в тайм пикере. Тайм пикер доступен в правом верхнем углу интерфейса Instana, в нем мы выбираем период времени, за который будут отображаться данные.  

    2. Rolling Time Window – SLO будет рассчитываться за выбранный период времени, где конечная дата периода указана в тайм пикере. Например, мы всегда можем посмотреть данные за предыдущую неделю, без необходимости изменять период времени в тайм пикере. 

    3. Fixed time interval – SLO будет рассчитываться за фиксированный период времени с определенной датой начала и длительностью. Например, ежемесячно начиная с 2020-01-01. 

  6. Убедимся, что мы заполнили все необходимые поля конфигурации. Нажав на «Highlight missing configuration» нам подсветятся все не заполненные поля. 

  7. Сохраним виджет, нажав на «Create» 

Итоги

Мы рассмотрели, что такое SLI и SLO, как они соотносятся с пользовательским опытом, какие метрики обычно входят в SLI и как внедрить концепцию SLO на практике.

Также с помощью Instana мы настроили SLI и SLO для сервисов, начали с выбора критичного пути пользователя по сайту, определили какие метрики использовать для SLI, указали error budget и настроили виджет, визуализирующий текущий статус SLO. Метрики приложений мы собрали автоматически, путем установки агента, реализующего инструментацию приложений — метрики не потребовалось описывать вручную.

Подробнее про основные возможности observability системы Instana можно почитать в нашем обзоре продукта.

Также приглашаем на наш вебинар, посвященный использованию Instana для мониторинга Kubernetes и снижения MTTR.

Источник

«Ребята из Google не знали о DevOps и просто придумали то же колесо сами» — конспект митапа по SRE

Зачем нужно SRE, когда есть DevOps, что такое SLO и бюджет на ошибки, каким компаниям точно не надо внедрять новую методологию, существуют ли джуниор-инженеры по SRE и сколько платят опытным. Об этом и не только говорили на митапе Слёрма «Профессия SRE: практика и мифы».

На YouTube можно посмотреть видеозапись встречи, а здесь мы приводим текстовую версию разговора с некоторыми сокращениями.

Участники митапа:

  • Павел Селиванов — DevOps Engineer в Mail.ru Cloud Solutions. Строит DevOps, CI/CD-процессы.
  • Артём Артемьев — Lead SRE в компании Inspectorio. Помогает девопсам жить хорошо.
  • Марсель Ибраев — CTO «Слёрм».

Заметка на полях: Site Reliability Engineering (SRE) произносится на русском как «эс-эр-и».

Что такое SRE и чем отличается от DevOps


Марсель Ибраев (МИ): Что такое SRE: это технология, методология или профессия? Что такое SRE простыми словами?

Поисковик мне выдал прекрасные статьи, где объясняется, что это набор методов, показателей и предписывающих способов обеспечения надёжности систем. На вики-словаре есть не менее интересное определение: это обеспечение надежной работы систем, обеспечение бесперебойной доступности сервисов. После такого объяснения я, разумеется, всё понял и проникся, но всё-таки, что такое SRE простыми словами?

Артём Артемьев (АА): Ты давно читал про DevOps? Забей в поиске, прочтёшь почти то же самое. На самом деле SRE — это то, как в Google в своё время увидели DevOps. Получилось немного по-другому, но нечто очень похожее на DevOps.

Павел Селиванов (ПС): Тут я соглашусь. Google пишет, что SRE — это практическая имплементация методологии DevOps. И мне правда кажется, что это так.

АА: Проблема только в том, что у нас нет нормального определения DevOps. У каждого DevOps сильно свой. SRE — одна из разновидностей DevOps.

МИ: В Google, получается, взяли на себя смелость опубликовать своё видение.

АА: Кстати, интересно, что у Facebook тоже есть своё видение DevOps, просто Facebook об этом не написал книжку. Не рассказал, как у них это получилось. Но у них DevOps нет. У них operations отдается всем инженерам, все инженеры так или иначе занимаются operations. Но есть люди, которые занимаются инфраструктурой, и они называются продакшн-инженерами.

П: У меня даже есть идея, почему Google написал такую книжку, а Facebook нет. Потому что Facebook делает сервисы для себя по большей части, а Google — для других. И когда Google надоело, что пользователи их хают, когда сервисы работают нормально, они попытались объясниться.

М: Получается, Google переварил DevOps, в итоге у них родился Site Reliability Engineering. Но почему тогда концепция стала такой популярной? Просто бренд сыграл, или эта штука действительно хорошо показывает себя на практике?

АА: Многие конторы ищут Святой Грааль: «вот у нас всё плохо, но сейчас мы наймём DevOps и всё полетит». С DevOps не получилось, давай теперь переименуем его в SRE.

МИ: Звучит логично.

АА: Насколько популярно, не знаю. Думаю, если собрать статистику, в скольких компаниях есть SRE… У вас в Mail.ru есть SRE?

ПС: Да.

АА: Больше, чем DevOps?

ПС: Скорее всего, да. Больше ли, чем админов — я не уверен. Mail.ru придумала, как работать хорошо, задолго до появления Docker, SRE, DevOps и всего прочего. А так как компания большая, смысла менять своё на новое и хайповое нет. Это огромные усилия. Поэтому мы по многим, особенно глобальным вещам живём на наших внутренних регламентах и инструментах. А ими занимаются сисадмины.

МИ: Непопулярно.

ПС: Зато работает.

АА: Я ещё вижу в реалиях русскоговорящего рынка, что у нас есть проблема — никто не понимает (по крайней мере, мало кто понимает), что есть проблема с DevOps. Что мы должны получить от внедрения DevOps? Как правило, все говорят про Continuous delivery, сбор метрик.

МИ: Ну да, построили пайплайны, и у нас как будто построен DevOps.

АА: Но по факту выходит, что метрики все зеленые, а пользователи жалуются. Инженеры говорят: «всё хорошо, всё работает».

В Google придумали, что нужно подойти к пользователю как можно ближе, и важны не показатели, а SLO, которое получает пользователь. В итоге в компаниях возникает необходимость нанять еще девопсов, которые будут делать похожую работу, но по-другому. И как их назвать? О, давай назовём SRE.
МИ: Получается, SRE — это реинкарнация, нечто, что получило физическую оболочку в рамках Google. Был некий DevOps, который все понимали по-своему, и Google не исключение, они тоже поняли это по-своему, набили кучу шишек и пришли к подходу, который назвали Site Reliability Engineering.

АА: Когда Google начал выдумывать SRE, ещё DevOps не был объявлен (хотя о нём впервые заговорили в 2000 году где-то во Франции, но это было ещё не широко). Ребята из Google не знали о DevOps, просто придумали то же колесо сами.

ПC: Мне тоже кажется, что DevOps был придуман в рамках каких-то встреч и конференций (как и Agile манифест в своё время), когда люди собрались и начали думать, как сделать так, чтобы всем стало хорошо. Собрались, придумали, и кто-то дальше эту идею развивал. А Google к этому подходил иначе, с точки зрения своих внутренних проблем. Они решали конкретную задачу, да, возможно, ту же самую задачу, что и комьюнити, и очень похожими средствами, но задача была полностью практическая. Нужно было решать конкретные вещи в конкретные сроки и конкретными действиями.

МИ: Означает ли это, что концепция SRE и весь его инструментарий подойдут далеко не всем? Если заработало у Google, не факт, что заработает у других?

АА: Аналогично и для DevOps. Но смотря про что говорить. Если про то, что надо мерить SLO со стороны пользователя, наверное, это почти всем подойдет. Если про подход «катись как можно чаще», а ты запускаешь космические корабли, то катиться как можно чаще — дорого и непонятно, надо тестировать больше.

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

Кто такой SRE-инженер? Почему это больше разработчик, чем админ

МИ: SRE называют концепцией или методологией, а это, я бы сказал, слова-паразиты, потому что сейчас так называют что ни попадя. Если мы говорим, что SRE — это ряд конкретных практик и решений, придуманных в Google, было бы интересно послушать, чем конкретно должен заниматься SRE-инженер. Можно описать типовой день или неделю. Что он должен делать, какие у него обязанности?

АА: Google приводит сравнение SRE и DevOps. Там перечисляются все эти пункты и оказывается, что всё матчится друг в друга. Но самая большая разница, о которой говорит Google, — они не нанимают operations или админов.
Они решили везде нанимать software engineer, которые умеют программировать которые очень ленивые, ничего не любят делать руками и чуть что пишут код. Но Google может себе позволить найти software-инженера, который очень хорошо разбирается в сети, системе, производительности и т. д.

В масштабах Google очень важно автоматизировать всё, что можно автоматизировать. Когда у тебя десять серверов — можно сделать всё руками, а когда миллион — тут уже не выйдет. Плюс человек умеет ошибаться, а робот нет. Так что принципиальная разница заключается в том, что мы нанимаем инженеров, которые пишут программы, чтобы те менеджирили operation-задачи.

МИ: То есть глобально SRE-инженер занимается автоматизацией?

АА: Старается заниматься. Ну и DevOps тоже. Большая задача SRE — уметь падать и быстро чиниться. Та самая концепция Error budget.

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

Концепция Error budget, когда сказано, что твой сервис 5% в месяц может быть сломанным, позволяет убедиться, что команда этого сервиса не замедлилась и бежит быстро. «Move fast and break things» — не бояться немного сломать, но в то же время экспериментировать и доносить нужные ценности. Это второй аспект. Возможно, он важен только компаниям размера Google. Когда у тебя небольшая компания, вы и так все мотивированы и бежите вперёд. Error budget вас сильно не спасёт.

ПС: Прикол именно в том, что SRE — это по большому счёту разработчик. Да, разрабатывать, естественно, это не единственная его функция, но именно майндсет разработчика, способность к разработке и реальный опыт программирования — одна из ключевых вещей в этой профессии.

Марсель, ты говоришь, что SRE-engineer — это человек, который должен заниматься автоматизацией. Мне кажется, это может вводить в заблуждение, потому что под словом «автоматизация» мы часто понимаем набор скриптов, который сделает grep в логи, положит в такой-то файлик, а дальше этот файлик по TCP отправит туда-то — вот это автоматизация. Однострочник на Bash, скриптик на Python и так далее. Просто с этой точки зрения любой разработчик тоже занимается автоматизацией, но почему-то его работу мы автоматизацией не называем.

SRE — все-таки такой автоматизатор, который не скриптики пишет (не только их, потому что для любого админа тоже никогда не было проблемой написать скриптик), но имеет майндсет разработчика и рассматривает проблемы инфраструктуры как софтварные проблемы, которые можно и нужно решать с помощью кода.
Все эти инфраструктурные инструменты, которых за последние лет пять появилось огромное количество, — начиная от Kubernetes, системы мониторинга, кучи экспортеров того же Prometheus — они гораздо сложнее, чем просто скрипт автоматизации. И вот эти все системы, мне кажется, появляются в том числе благодаря развитию SRE как направления и тому, что инфраструктурными задачами начинает заниматься разработчик.

Странно было бы заопенсорсить свой набор из миллиона bash-скриптов, zabbix-шаблонов и прочего. Вывалить это всё на гитхаб и сказать: «вот, ребят, мы за десять лет существования компании накопили вот такую кучу — нате». Понятно, что это ни у кого бы не взлетело. А вот инструменты, которые делают разработчики для поддержки инфраструктуры, они действительно новые и полезные.

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

МИ: То есть SRE-инженер, как правило, из разработки. Появляется проблема, и он смотрит не на то, как это закостылить, а на то, как автоматизировать, и может написать программу или приложение, которое всё это будет обрабатывать. Ещё я слышал, что с SRE связаны системы мониторинга доступности, чтобы у нас приложение было доступно и соответствовало неким метрикам. Это тоже задача SRE-инженера? Его задача эти метрики настраивать, отслеживать — как он с ними работает?

АА: Метрики отслеживать — не задача инженера SRE. Моя задача как инженера SRE — сделать инструменты для команд, чтобы они понимали, сколько у них осталось SLO, почему он уменьшается и как выглядит работа их приложения, конкретного сервиса этой команды для конечного пользователя: какой был latency, сколько было ошибок и как это всё выглядело.

Они ко мне обращаются за помощью, когда видят, что тает их SLO и они не понимают почему. На авторизации логины стали длиннее на пару секунд, и они считают это нормальным, но это выпало из SLO, начинает выпадать из допустимого latency. Ко мне прям прибегали ребята из сервиса авторизации и спрашивали: почему у нас SLO тает, «вчера было 3 секунды, а сегодня 3,5 секунды — ничего страшного же». Но если вы договорились, что должно быть 3 секунды, то, ребят, извините.

Что такое SLO, SLA и Error Budget


МИ: А можешь расшифровать, что значат SLO, SLA, SLI?

АА: Думаю, все слышали про SLA (Service Level Agreement) — это договор с любой компанией об уровне предоставления услуг, где компания обязуется, что 99% времени некий сервис будет работать.

МИ: Например, сервер на хостинге? То, что мы берём в аренду.

АА: Например, строка поиска в Google. Забиваешь, что нужно найти, а он тебе ищет. SLA там 99%. То есть Google сам говорит: зуб даю, что 99% будет.

При этом инженеры боятся, что они могут ошибиться и не попасть в эти 99%, и будет совсем больно. Поэтому внутри, у себя в команде, они договариваются: вот мы хотим, чтобы было 99.9%, тогда у нас есть в запасе 0,9%, и мы точно попадём. И вот этот их внутренний договор называется SLO.

МИ: Значит, SLA — для внешних, а SLO — внутри.

АА: И считается SLO по запросам от пользователя, как правило. Чем ближе к пользователю подошел, тем лучше. Идеально, если в java-скрипте тусуются отдельные элементы в браузере, и этот скрипт репортит куда-то о том, что не удалось аджаксом скачать какой-то кусочек элемента. Потому что часто, если у нас упал самый главный nginx, то это у нас в nginx логов нет, значит запросов нет, latency хорошие, всё хорошо. А тут java-скрипт начнет говорить, что есть ошибка. Либо, если это мобильный клиент, он прямо с мобилки сыплет свои ошибки, это просто идеально: мы всё знаем и считаем.

И есть ещё SLI (Service Level Indicator) — это те параметры, о которых мы говорим. Например, задержка для клиента, как быстро он скачал страницу — это один SLI. Либо количество ошибок, сколько клиентов у нас получили пятисотый статус ответа вместо двухсотого — это второй SLI. Вот два очень распространенных SLI: latency и количество ошибок.

М: Ну и про Error budget расскажи. Я так понимаю, это некий бюджет, который закладывается на ошибки, на простой. Если команда разработки и в целом проект его превышает, то что-то происходит. Правильно ли я понимаю?

АА: Когда мы зафиксировали SLO и сказали, что обязуемся, чтобы 99.9% запросов валидно ответили пользователю, то у нас остались 0.01% запросов к сервису, которые могут пофейлиться. Если у нас там миллион запросов, то 0.01 от миллиона считаем. Это и есть наш Error budget или бюджет на ошибки.

Когда у нас есть в запасе эта цифра, мы в некоторых ситуациях можем не думать, что написали код, который не очень протестирован. Если у нас полно Error budget, мы можем не тратить ещё неделю на тестирование кода, а прямо сейчас выкатить его, потому что нам очень надо посмотреть, как он работает (понятно, что при этом мы должны уметь быстро откатываться и выкатывать код не на всех пользователей, а на 5%). Если код начал валиться, мы его откатили, перестали вести на него трафик и немного потратили своего Error budget. Но это позволило нам очень быстро проверить гипотезы и доставить ценности.

С другой стороны, если мы полностью потратили свой Error budget, нам нужно очень хорошо тестировать код и смотреть, на что мы его потратили: если у нас часто отваливалась база данных, то самое время отложить бэклог и заняться автоматическим переключением баз данных на slave.

ПС: Мне кажется, Error budget ещё очень полезен для оценки, какие решения сейчас нужно внедрять, в каких решениях назрела необходимость. Предположим, у нас есть сервис, который в теории доступен 100% времени. Он работает без ошибок, мы его не разрабатываем или нечасто деплоим, новые ошибки туда не приезжают. А когда мы его деплоим, у нас нет никакого rolling updates и вот этих всех модных штук, мы просто выключаем и включаем заново. И смотрим, что, например, генерируем таким образом энное количество ошибок.

При этом мы понимаем, что если деплоим раз в какое-то количество времени, то, даже несмотря на то, что никакой системы rolling updates нет, такие деплои за рамки Error budget не выходят. И это такой прекрасный показатель — сказать, когда команде нужно задумываться о технических вещах. Вот сейчас назрел момент, мы начали выходить за Error budget, давайте его пофиксим хотя быть тем, что начнём выкатываться без простоя. Или мы действительно можем выкатываться с простоем.

SRE-инженер — это клей, а SRE — это хайп?


МИ: Если всё сложить, то получается, что SRE-инженер — это некий человек, который мыслит одновременно и в плоскости инфраструктуры, доступности приложений и в плоскости разработки. Некий «клей», который связывает эти два дела и думает больше о конечном клиенте и доступности, чем о написании кода или настройке Terraform и подобных вещах. Он вне рутины и визионирует эти процессы.

ПС: С точки зрения DevOps мы стремимся сделать некую инфраструктуру и создать такую ситуацию, в которой за свои приложения, в том числе и в продакшене, отвечает команда разработки. Команда сопровождения в таком случае поддерживает инфраструктуру и какие-то общие вещи, типа кластеров баз данных, кластеров очередей. Отдельная команда в виде девопсов или сама команда сопровождения реализует способы максимально автоматической работы для разработчика: доставлять свой код до продакшена, тестировать и так далее.

То есть, в DevOps команда разработки уже отвечает не только за то, чтобы код написать, кинуть админам и сказать, «нате, деплойте», админы там подеплоят, поймут, что ничего не деплоится, вернут разработчикам; разработчик скажет: «у меня работает, у вас не работает, идите разбирайтесь» — классический конфликт. В рамках философии DevOps разработчик отвечает за свой код: и написание, и его работу в продакшене.

В таком случае SRE-инженер — никакой не клей, а админ, который теперь отвечает не только за работу в продакшене, но в том числе и разбирается в коде. И нет никаких разных целей у отдела сопровождения и отдела разработки. Есть одна цель — рабочий продукт, который нужно сделать. Это не тот продукт, который никогда не падает (сервер, отключённый от питания, тоже никогда не падает) рабочий продукт — это штука, которая приносит деньги компании. А для этого он: а) должен работать, б) должен обновляться. Так что отделы разработки и SRE реализуют одну цель.

МИ: Окей, с задачами SRE разобрались. Теперь другой вопрос: шумиха вокруг SRE — это хайп, или все-таки у подхода есть реальное будущее? Второй Kubernetes или временное явление?

АА: Сложно сказать, DevOps — это хайп или уже не хайп? Наверное, уже не хайп. Но если SRE — это случай DevOps, то кто-то будет его использовать, а кто-то нет.

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

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

МИ: Меня пугает, что компании ищут людей, которые на все руки мастера. Могут и код написать, и инфраструктуру поднять, и винду настроить, и принтер починить. Просто сисадмины уже теряют актуальность. Возможно, в будущем просто разработчики тоже будут терять актуальность? Или нет?

АА: Тут сложно говорить, потому что компаниям нужна стабильная работа, а как называются те, кто умеет делать твой сервис стабильным, неважно. Просто в какой-то момент сисадмины поссорились с разработчиками, зависели друг от друга, но не договаривались. Тогда придумали DevOps, чтобы подружить их, и для бизнеса DevOps стал очень выгоден: со всех сторон бенефиты.

В какой-то момент DevOps чуть-чуть изменил свой курс от того, что ребята придумывали, и теперь он больше про деливери и измерения, инженерный аспект разработки. Он ушёл далеко от ощущений самих пользователей.

По сути, DevOps может делать и работу SRE — измерять значения максимально близко к пользователю и знать, как часто сервис падает. Но в текущих реалиях DevOps немного не про это. Случилось культурное изменение. И тут на сцену выходит SRE, и компании понимают, что им нужен ещё один DevOps, но он будет не DevOps, а SRE. Очень часто люди, работающие над DevOps и SRE могут быть взаимозаменяемыми.
ПС: Вот ты Марсель говоришь, «человек, который умеет всё». Но я не согласен. Артём, как ты думаешь, бывают ли джуниор SRE-инженеры?

АА: Думаю, даже бывают SRE-интерны.

ПС: Наверное, бывают разных способностей люди. Если есть какая-то система обучения SRE, то интерна можно себе представить. Но по моему опыту, SRE-инженер — это такой человек, который видел разработку (если он со стороны разработчика, то минимум стал мидлом), который занимался многими вещами в компании, в том числе видел администрирование и сопровождение — представляет, что там ребята делают.

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

Как внедрить SRE в компании


МИ: Внедрение SRE, как и DevOps, — это революция или эволюция? Стоит ли пушить решение о том, что нам нужен SRE или DevOps в компании?

ПC: SRE — это всё-таки конкретная, понятная методология, и в ней должна быть потребность. Поэтому путь внедрения SRE эволюционный. Cделать SRE из состояния «мы классическая компания, у нас половина на железных серверах, половина на ноутбуке под столом» я боюсь, что не выйдет. Потому что будут люди, которые скажут, что это абсолютная фигня от смузи-админов, разработчиков в узких джинсах и т. д.

Мне понравился доклад на одной из конференций. Там был тезис, что DevOps нельзя внедрить насильственно. Единственный вариант — разогнать всю команду и набрать другую из людей, которые с DevOps знакомы. А чтобы никого не разгонять, надо взять несколько админов и послать на DevOps-конференцию. Пусть они послушают, поплюются, расскажут всем, что это фигня. Взять потом других админов или разработчиков, отправить туда. И постепенно за годик-два компания начнёт гореть идеями DevOps — и со стороны разработки, и со стороны администрирования. Тогда команды сами придут к бизнесу и скажут: «Чуваки, мы тут такую штуку знаем, давайте мы её внедрим». Из такого состояния SRE можно, пожалуй, считать революционным. Но когда нет никакого движения, никакой основы, то ничего не получится.

АА: Я вполне согласен с Павлом. Ещё часто SRE, как и DevOps, могут заносить сами владельцы бизнеса, которые хотят стабильности. Но насильно в инженера не занесёшь, надо продать, а продать тяжело, если кто-то упирается.

ММ: Мы сейчас по большей части поговорили про инженеров-разработчиков. Есть ли у вас представления, на какие аспекты работы проекта стоит обратить внимание с бизнесовой части? Как бизнес может понять, что им нужен SRE или какой-то другой подход в управлении проектами?

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

ПС: В целом да.

SRE — это же одно из возможных решений. Если есть проблема с доступностью сервиса, стабильностью, можно задуматься об SRE. Или в то же время задуматься о введении каких-нибудь KPI, кнутов на входе, и начать разработчиков бить за баги. Тоже как вариант, наверное, тоже может работать. SRE точно не будет серебряной пулей, которая спасёт от всего. Но вот проблему стабильности, проблемы в организации IT-команды, когда есть классический конфликт между администрированием и разработкой, решить поможет.

Что должен знать SRE-инженер и сколько может зарабатывать


МИ: Как вообще вот этим мифическим SRE-инженером стать? Что нужно сделать? Какими скиллами обладать, чтобы претендовать на такую позицию?

ПС: Я недавно размышлял над этим вопросом. Думаю, особенно у нас, в России, есть проблема. Вот если бы конкретный живой человек спросил у меня, я бы ему рассказал об определённых вещах, на которые нужно посмотреть. Он бы пришёл в первую попавшуюся компанию, где нужен SRE, а ему бы начали задавать вопросы о рейдах, например, или еще каких-то странных вещах. И тут вопрос: когда вы в современной компании последний раз видели живой рейд и зачем? Наверное, это полезно знать, но честно — мне это сейчас не нужно в моей работе, и я на эти вопросы не отвечу. В большинстве случаев это не задача SRE. Есть, конечно, системщики, которые этим занимаются. Но у большинства компаний не железные сервера, а есть какое-то облако, купленное или свое, и приложение нужно эксплуатировать в рамках этого облака.

Программирование нужно при собеседовании точно. Я вот недавно общался с коллегами из Тинькова, и они сказали, что админы приходит на позицию SRE, их начинают спрашивать про какие-нибудь бинарные деревья, и они прям обижаются — я же админ, зачем меня по программированию гонять?

Современные DevOps-инструменты типа infrastructure as code, инструменты оркестрации, как Kubernetes, инструменты мониторинга — Prometheus, Grafana, возможно, и Zabbix всё еще бывает полезен. Docker. Это основной технологический список. Но очень важно то, в какую компанию вы придёте. Если ей нужны настоящие SRE, то с этим списком, скорее всего, получится пройти. Если нужны переименованные админы, то у вас начнут спрашивать про рейды и так далее.

АА: Я бы добавил, что Network тоже важен для SRE, потому что твои сервисы включаются по сети. И она, возможно, не ARP.

МИ: Да, есть такое. Я про это даже как-то рассказывал, что ездил в EPAM в гости, и мне жаловались, что сейчас растёт поколение девопсов, которые делают банальные ошибки, связанные с сетью.

МИ: Требуется ли делать упор на умение программировать как таковое или всё-таки надо знать какой-то конкретный язык?

ПС: Программирование как таковое — это когда вам объяснили на Паскале в институте общие принципы программирования, циклы, операторы, ветвления? Нет, этого будет недостаточно. Но я знаю, что нормальный программист довольно легко переходит с одного языка на другой. Особых требований к языкам нет. Есть более популярные и менее популярные.

МИ: Стоит ли учиться программированию по книгам?

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

ПС: Я думаю, про языки проще найти готовые курсы, туториалы и документацию, если язык не первый. Книжки — это скорее основы, которые в институте проходят. Но они довольно медленно устаревают. Тот же «Чистый код» читать — это хорошо.

МИ: Что конкретно должен уметь «кодить» SRE? В какую сторону смотреть?

ПС: Я могу дать конкретный пример. Prometheus работает по следующему принципу: у него есть экспортеры (штуки, которые собирают данные систем и предоставляют их в формате, понятном для Prometheus), он приходит к экспортерам и собирает данные. Такая нормальная задача SRE была бы — взять какую-нибудь часть системы, у которой всё еще нет опенсорсного решения, и сделать для неё один из экспортеров в Prometheus, к примеру. Или сказать разработчикам: «Ребята, у нас там система сбора логов такая-то, а давайте вы все будете собирать логи и писать их вот в опредёленном виде, и вот вам для этого библиотека. Встройте её во все свои приложения». Библиотека для таких системных вещей типа логи, трейсинг и так далее. Тоже вполне нормальная задача для SRE-инженера.

МИ: Сколько зарабатывает SRE в России? У меня под рукой нет данных, но думаю, зависит от компании и требуемых скиллов.

ПС: Я тоже без понятия, но в целом про зарплату могу сказать так: когда я только начинал заниматься сопровождением, админы чаще всего получали меньше, чем разработчики на одинаковой позиции. Сейчас DevOps, SRE получают или так же, как разработчики, или больше, потому что и скилла нужно больше. Так что посмотрите на Хедхантере, сколько в среднем получают разработчики, и делайте выводы. Мне кажется, от 120-150 тысяч. Разумная верхняя граница, думаю, 250-300. Но границ, в принципе, нет.

Вакансии SRE на Headhunter

Что будет на интенсиве по SRE?

МИ: SRE — это про практику. И как раз об этом мы будем говорить на нашем интенсиве, который пройдет 11-13 декабря. Будет много кейсов, с которыми сталкивается SRE-инженер.
Там же мы рассмотрим на практике построение метрик, проблемы с доступностью и прочее, прямо своими руками, реальными инструментами. Павел уже упомянул экспортеры, Prometheus, графики. Будем всё это щупать, со всем этим разбираться.

ПС: Я еще про интенсив добавлю чуть-чуть. Мы пытаемся за три дня дать людям понять, что такое — быть SRE-инженером, пропустить это через себя. Показать три дня такой работы. Практику.

Мы дадим вам систему и будем её ломать и заставлять вас её чинить в коде, в инфраструктуре, смотреть на метрики, на логи, объясняться с пользователями и так далее. Мы показываем то, что написано в книгах Google об SRE через призму реальной работы.

МИ: Именно так. Там будут и Павел, и Артём. Еще к нам присоединится Иван Круглов. И мы все вместе будем во всем этом разбираться.

Блиц по вопросам из чата

SRE должен быть свой у каждой команды?

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

Что, если сервис зависит от другого сервиса? Например, авторизации. Сервис авторизации падает сильно и надолго, это приводит к исчерпанию Error budget.

АА: Если ты зависишь от другого сервиса, ты не можешь написать сервис надежнее того, от которого зависишь. Но тут есть нюансы, потому что ты можешь ретраить некоторые запросы в рамках таймаута. Посылать сразу несколько запросов. То есть, если у тебя есть сервис, от которого ты зависишь, можно в него послать одновременно три запроса. И, возможно, один из них с большей вероятностью выполнится, чем просто один отправленный запрос. Либо ты можешь договориться с бизнесом и своими пользователями, 500-я ошибка — это точно ошибка. А 403-405 могут считаться не полноценной ошибкой, а в рамках предоставления сервиса. И когда недоступен сервис, от которого ты зависишь, ты своему клиенту отдаешь код ошибки, чтобы он знал, что нужно зайти позже. И это может считаться в рамках SLO, если договориться об этом.

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

Когда сервисы общаются между собой, они же все клиенты друг друга. Поэтому все эти вещи про SLO и Error budget распространяются не только на конечного пользователя. По сути, мы для каждого сервиса компании можем объявить свои SLO и Error budget, и каждый сервис обязуется для всех своих клиентов предоставлять этот определенный уровень доступности. Причем, можно говорить не только про сами приложения и про их метрики. Мы можем говорить и про другие системы компании с теми же уровнями. Если есть команда, которая занимается сопровождением баз данных, то она может объявить свои уровни и поддерживать их. Мы внутри компании постоянно этим всем пользуемся.

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

Имеет ли место SRE в компании с редкими релизами (раз в пару лет, например)?

А: Всё-таки это сделано в Google, и тут больше вопрос про надежность, а не про релизы как таковые. С редкими релизами имеет смысл собирать статистику, знать, насколько ты надежен, где что ломается и как это чинить. Можно просто два года подставлять костыли, чтобы через три года зарелизиться. Вопрос — зачем это надо, если мы все равно не можем починить быстро? Ну, можно чинить не быстро — тоже вариант, какие-то прослоечки делать.

Какие знания нужны, чтобы принять участие в интенсиве с пользой? Для начинающих или опытных?

МИ: Отличный вопрос. Крайне желательно иметь бэкграунд разработки. У нас приложение будет на Python и, если вы админ и кодили, и делали скрипты, наверное, вы тоже разберётесь. Но, как мы уже выяснили, все-таки SRE-инженеру нужен бэкграунд разработчика. Наши приложения будут работать в Kubernetes и крайне желательно с ним тоже уметь работать. Будем использовать Grafana, Prometheus.

Источник

Известно: нельзя управлять тем, что не измеряешь. В контексте IT-проектов это означает необходимость мониторинга всех частей проекта: от утилизации CPU до бизнес-показателей вроде количества заказов в интернет магазине или показов баннеров на сайте.

Чтобы сервис работал стабильно и техническая поддержка могла в режиме 24/7 быть эффективной, нужно: собирать метрики, визуализировать их динамику (в дашбордах и графиках), анализировать результаты и работать с инцидентами — желательно до того, как они стали инцидентами. Однако мониторинг мониторингу рознь. Чтобы он выполнял свою функцию, система должна быть «адекватной» и удовлетворять двум принципам: 

1) отслеживать метрики, которые нужны для принятия решений, и не мониторить лишнее;
2) уведомлять, когда ещё можно что-то сделать без последствий для работоспособности сервиса, но не спамить ложной тревогой. 

Звучит просто и логично, но на практике найти баланс не всегда легко.

Эта статья будет первой в серии заметок о том, как мы организуем мониторинг у наших 400+ клиентов. Расскажем, какие метрики снимаем, каких методологий придерживаемся и какие алерты видим каждый день.

Методологии сбора метрик

Существует три основных подхода к сбору метрик: USE (Tom Wilkie), RED (Brendan Gregg), LTES (Google SRE). Они отличаются по целям мониторинга и, естественно, включают разный набор метрик (но «E» везде отвечает за ошибки). Давайте разберем каждый из них отдельно.

В методологии USE для каждого ресурса (CPU, дисковая подсистема, память и т.д.) рекомендуется снимать следующие метрики:

  • Utilization — время или процент использования ресурса, занятого «полезной работой»;

  • Saturation — насыщенность, то есть количество отложенной или поставленной в очередь «работы»;

  • Errors — количество ошибок в работе компонента.

RED предлагает мониторить:

  • Rate — количество запросов в единицу времени (например, rps на микросервис или сервер);

  • Errors — количество ошибок;

  • Duration (оно же latency) — время обработки одного запроса.

В LTES по аналогии с двумя предыдущими методологиями отслеживают:

  • Latency — время на обработку одного запроса (с разделением на успешные и ошибочные запросы);

  • Traffic — количество запросов к компоненту (для веб-сервера это могут http-запросы, для базы данных — транзакции и т.п.);

  • Errors — количество ошибок;

  • Saturation — здесь это количественная метрика, отражающая, насколько компонент использует свои ресурсы и сколько у него «работы в очереди».

Нельзя сказать, что какая-то из этих методологий «правильная». Каждый отдельный компонент системы нужно мониторить, основываясь на здравом смысле. Для веб- или application-сервера лучше подходят RED и LTES, для шины данных или обработчиков очередей задач — USE.

Концепции алертинга

Построение алертинга — системы автоматического оповещения о том, что метрика достигла порогового значения, — основывается на концепциях SLI, SLA и SLO. 

SLI (Service level indicators) — набор ключевых метрик, по которым можно определить жизненный статус сервиса, его производительность, «удовлетворенность» конечных пользователей работой сервиса. Например, в SLI может входить количество 500-х ошибок или количество активных пользователей.

SLA (Service level agreement) — так называемое «соглашение об уровне доступности сервиса», которое определяется как ВНЕШНЕЕ обязательство перед конечным пользователем или клиентом. Например, SLA нашей круглосуточной техподдержки обычно составляет 15 минут — за это время мы обязуемся отреагировать на запрос или инцидент клиента, и это не зависит от внутренних обстоятельств. 

SLO (Service level objectives) — набор целевых, «желаемых» значений SLI, выход за пределы которых может привести к нарушению SLA конкретного сервиса или компонента. Максимально допустимое отклонение от «идеальных» показателей в данной концепции называется Error Budget (право на ошибку). Как пример, это может быть: максимальное количество 500-х ошибок за 5 минут, максимальное время недоступности веб-страницы, максимально допустимая нагрузка на процессор и т д.

Казалось бы, SLO и есть тот порог, на который надо установить алерты. Но SLO — это «желаемое» состояние, и не всё, что от него отличается, обязательно является нештатной ситуацией. Если настроить алерты на отклонение от SLO, то, с одной стороны, возрастает вероятность появления так называемого «алертного шума» — большого количества оповещений при вполне адекватной работе системы, с другой — есть риск получить алерт только в момент нарушения SLA. 

Простыми словами: алерт должен срабатывать не тогда, когда «всё уже очень плохо», и не от каждой «помехи», а тогда, когда возникла проблема, но ещё можно что-то исправить. 

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

Метрики и пороговые значения

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

CPU. Для мониторинга использования процессорного времени на сервере мы обычно выставляем два базовых алерта:

  • CPU idle < 10% в течение 10 минут;

  • CPU Load Average превышает количество доступных процессоров и не равно 0 в течение 5 минут.

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

Оперативная память. В большинстве случаев для определения высокой загруженности данной подсистемы и возможного начала деградации мы выставляем следующие алерты:

  • заполнение SWAP > 90% (актуально для версий ядра Linux младше третей);

  • активная запись в SWAP (swapin > 1 Мбайт/с) в течение 2-5 минут (актуально для новых версий ядра Linux)

  • используемая оперативная память > 85%.

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

Дисковая подсистема. Основные алерты по метрикам в дисковой подсистеме, которые мы настраиваем практически всем клиентам, это:

  • нагрузка на диск (iostat) > 95% в течение 1 часа;

  • Free inodes (по каждому разделу) <10%;

  • Свободное место на диске (по каждому разделу) <10% + дополнительный алерт < 5%.

Слишком высокая нагрузка на дисковую подсистему чревата полной деградацией всей системы. Например, если снизится скорость чтения/записи данных на диск, то это может повлиять на скорость формирования кеша и работы с БД. А если кончится место или свободные inodes, то запись на диск полностью остановится, что приведёт к блокировке работы всего сервиса или потере чувствительных данных. А в некоторых случаях к «битым» базам данных, которые админы будут долго и мучительно пытаться восстановить. 

Однако, конфигурируя алерты на процент свободного места, стоит учесть, какое ПО на сервере. Например, если этот сервер делает бэкапы, т.е. бывает периодическое резкое увеличение объема данных, или на нём работает ElasticSearch, то лучше иметь свободными 15% от большого диска. Если же ничего подобного там нет или объем дисковой подсистемы измеряется десятками терабайт, то скорее всего алерт на 10% — избыточная перестраховка, и порог срабатывания можно смело снизить до 3−5%.

Также, с точки зрения мониторинга файловой системы, мы рекомендуем следить за состоянием маунтов (сетевых дисков) и настроить алерты, во-первых, на наличие самого маунта, во-вторых, на корректность работы подмонтированной файловой системы.

Дополнительный мониторинг дисков:

  • результат SMART-теста диска отличается от passed — если тест не пройден (статус failed), диск может быть неисправен, и есть риск потерять данные;

  • количество поврежденных (переназначенных) секторов HDD > 1;

  • процент износа SSD — < 10% от полезного срока службы. Как правило производитель определяет порог, после которого диск переходит в read-only режим;

  • процент использования NVMe > 90%;

  • объем резервной области NVMe < 15%;

  • ошибки целостности данных NVMe > 1.

RAID. Мониторинг RAID-массивов зависит от наличия контроллера, но необходимый минимум, который позволяет обеспечить целостность данных, для обоих случаев один и, на наш взгляд, состоит из трёх пунктов: 

  • алерт на «вылет» диска из рейда;

  • алерт, срабатывающий в начале проверки/синхронизации после восстановления диска в массиве (помогает понять, что резкие скачки в нагрузке на CPU или память временные и не являются проблемой);

  • количество битых дисков > 1.

Если контроллер имеется, то дополнительно имеет смысл поставить алерты на различные ошибки, здоровье, кеш, состояние батареи и т.д.

Синхронизация времени на сервере с эталонным. Рассинхронизация времени иногда приводит к сложнодиагностируемым ошибкам как в серверном ПО, так и в клиентских приложениях. Поэтому мы мониторим ее, запрашивая статус используемых на сервере утилит синхронизации времени, например, ntpd, chronyd или systemd-timesyncd, и используем алерты следующего вида:

  • > 500 миллисекунд в течение 5 минут;

  • < 500 миллисекунд в течение 5 минут.

Большая рассинхронизация иногда приводит к интересным последствиям. Например, нам встречались ошибки в репликации данных между двумя базами (как в схеме мастер-слейв так и мастер-мастер) или получение логов «из будущего». Также отставание времени на сервере может неприятно повлиять на работу интернет-магазинов: например крон-задание, которое должно запускаться ровно в полночь, из-за рассинхрона времени запустится раньше или позже обычного и нарушит формирование отчетов — как внутренних, так и внешних, скажем, для налоговой.

Сетевые интерфейсы. Мониторить объем входящего и исходящего трафика может быть необходимо из-за специфики тарификации трафика или когда заведомо известно о проблемах с сетевым каналом. Кроме того, если сервер используется для раздачи контента, резкие скачки нагрузки на канал могут сигнализировать о какой-либо аномалии, например, DDoS-атаке. В нашей практике алерты на сетевые интерфейсы чаще всего устанавливаются по просьбе клиентов и отслеживают следующее:

  • входящая нагрузка >75% или >90% от лимита;

  • исходящая нагрузка >75% или >90% от лимита;

  • алерт на резкий (и нехарактерный при этом) скачок входящего или исходящего трафика.

Это, на наш взгляд, «прожиточный минимум», база, с которой мы начинаем конфигурировать мониторинг у наших клиентов и которая полезна для 99% серверов и виртуальных машин. Конечно, в каждую из перечисленных областей мониторинга можно добавить ещё большее количество алертов: в зависимости от того, как используется сервер, какое ПО на нем работает и.т.д. Например, частая практика — мониторинг и настройка алертов на работу кулеров, температуру процессора для железных серверов. Но, как мы говорили в начале, важно не переборщить. 

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

В следующих статьях поговорим о мониторинге системного ПО, application-уровня, системах виртуализации и контейнеризации.

Поделиться:

Мы используем cookies для быстрой и удобной работы сайта. Продолжая пользоваться сайтом, вы даёте согласие и принимаете политику
обработки персональных данных
×

Источник

Everything fails, that’s a fact. Not even the best system has 100% reliability, right? But then, how many times have you seen Google being unavailable? I’ve never seen that, or if for some reason Google wouldn’t load, I’d blame that on my internet connection. There’s no way it’s Google’s fault. Believe it or not, but Google doesn’t have 100% reliability, either. And if even they embrace it, you should too. Just use your error budget wisely.

What is an error budget?

You already know that 100% reliability is not something achievable, but you may still want to strive for perfection. There’s no point in that, to be honest. Extreme reliability slows down the pace of delivering features. On one hand, you may want your system to be as reliable as possible, but on the other hand, you will clearly see more value in features that contribute to your business. And honestly, a lot of technical work often doesn’t have that clear business value, so it may sometimes get pushed aside by the product owner who wants new features delivered ASAP.

But let’s get back to numbers. If 100% reliability is not doable, then maybe 99.999% is?

It may be, but keep in mind that most users are limited to the reliability of their cellular network or the device they’re using. If they’re using a device with 99% reliability, they really won’t notice a difference between 99.99% and 99.999% service reliability. High reliability is a must, extreme reliability isn’t. Instead of focusing on being as close to 100% as possible, you can think about how to recover from failure. It is known that systems often fail when there are changes but not changing anything isn’t the answer, either. Your users need some updates. What you need to know, though, is when to change.

In Google’s Site Reliability Engineering (SRE), they suggest balancing the risk of unavailability with the goals of rapid innovation and efficient service operations which further translates into service optimization and user satisfaction.

Ok, but what is this error budget thing?

When you measure service risk, you need to somehow assess the performance of the system and track improvements – and the focus is usually on unplanned downtime.

In the Site Reliability Engineering book, unplanned downtime is defined as follows:

Unplanned downtime is captured by the desired level of service availability, usually expressed in terms of the number of “nines” we would like to provide: 99.9%, 99.99%, or 99.999% availability

The usual way of calculating service availability is by observing its uptime and unplanned downtime:

availability = uptime / (uptime + downtime)

However, in the SRE book, Google suggests to use a different metric and define availability in terms of request success rate:

availability: availability = successful requests / total requests

Measuring availability this way, you should define your Service Level Objectives (SLOs). The SLO is a number that defines how big a portion of the requests you allow to fail. This means that is you set your SLO at 99.9%, your error budget is 0.01%.

Why do you need an error budget?

In a perfect world, you shouldn’t have to make a choice between uptime and innovation. In reality, however, you just need to find a balance between those two. During the development of the product, there may be some tension between the development and SRE teams. Both of these teams are evaluated with different metrics: product development performance relies on product velocity, while SRE is measured with the reliability of a service. When one group wants to push new code as quickly as possible and the other pushes against the rate of change, it’s hard to find understanding. How to find the right balance if different perspectives mean different expectations?

The error budget is supposed to solve this issue:

The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter. This metric removes the politics from negotiations between the SREs and the product developers when deciding how much risk to allow.

There are also many companies that do NOT have an SRE team. Does that mean that there’s no tension there? There sure is, but on the line of the dev team and the product owner.  The development team is held accountable for their work and wants to have enough time to do their job properly and deliver reliable services, while the product owner usually pushes to have more features in an even shorter time.

So what are the steps of working with an error budget? Google describes their practices:

  • Product Management defines an SLO, which sets an expectation of how much uptime the service should have per quarter.
  • The actual uptime is measured by a neutral third party: our monitoring system.
  • The difference between these two numbers is the “budget” of how much “unreliability” is remaining for the quarter.
  • As long as the uptime measured is above the SLO—in other words, as long as there is error budget remaining—new releases can be pushed.

What are the benefits of the error budget?

The main advantage is that it helps to find the balance between reliability and innovation. And this is not easy! When there are clear conditions defined, everybody working with the service knows what to do. If the SLOs are met, new releases can be pushed. Are you close to exhausting your budget? In such a case, resources will be invested into making the system more resilient and improve its performance. It seems like you still have to choose… Can you really only have one thing or the other? Reliability or innovation? No. The error budget doesn’t have to work as an on/off technique. You can slow down new releases or roll them back when the error budget is close to being used up and then when service performance is improved, get back on track with pushing new releases at a pace you’re comfortable with.

The error budget guides decisions: if the error budget is full, the team can take more risks, but if it’s drained, the team won’t be risking as much. It’s not a strict rule that you have to obey by all means – it is a guideline that helps all team members see how the service is doing.

outsourced team

Источник

So, you’ve started down the site reliability engineering (SRE) path at your organization. You have set up your service. You have analyzed how your users interact with it, which helped you identify some key metrics that correlate with user happiness. You set your service-level objectives, which in turn gives you an error budget. Great work!

Now, the next consideration is that your organization maintains a schedule of maintenance windows that bring your service down. Should this downtime count toward your error budget? Let’s analyze it!

Error budget

In a nutshell, an error budget is the amount of error that your service can accumulate over a certain period of time before your users start being unhappy. You can think of it as the pain tolerance for your users, but applied to a certain dimension of your service: availability, latency, and so forth.

If you followed our recommendation for defining an SLI, you’re likely using this SLI equation:

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_7Tpr8mj.max-1200x1200.jpg

Your SLI is then expressed as a percentage, and once you define an objective for each of those SLIs—that is, your service-level objective (SLO)—the error budget is the remainder, up to 100.

Here’s an example. Imagine that you’re measuring the availability of your home page. The availability is measured by the amount of requests responded with an error, divided by all the valid requests the home page receives, expressed as a percentage. If you decide that the objective of that availability is 99.9%, the error budget is 0.1%. You can serve up to 0.1% of errors (preferably a bit less than 0.1%), and users will happily continue using the service.

Remember that selecting the value for your objectives is not just an engineering decision, but a business decision made with input from many stakeholders. It requires an analysis of your users’ behavior, your business needs, and your product roadmap.

Maintenance windows

In the world of SRE practices, a maintenance window is a period of time designated in advance by the technical staff, during which preventive maintenance that could cause disruption of service may be performed.

Maintenance windows are traditionally used by service providers to perform a variety of activities. Some systems require a homogeneous environment—for example, where you need to update the operating system of terminals in bulk. You may need to perform updates that introduce incompatible API/ABI changes. Some financial solutions need the database server and client software to be version-compatible, which means that major software upgrades require all the systems to be upgraded at the same time. Other examples of traditional maintenance windows are the ones required during database migrations to allow the synchronization of the data tables between the old and the new release during the downtime, and physical moves when computers are shut down to allow physical relocation of the devices.

Similar to deciding your SLO, scheduling a maintenance window is a business decision that requires taking into account the agreements you may have with your users, the technical limitations of your system, and the wellbeing of the people responsible for those systems. It’s inevitably a compromise.

The type of maintenance window that we are discussing in the rest of this post is the one that you, as a service provider, may perform and that affects your users directly, effectively causing a degradation of your service, or even a full outage.

How to choose your maintenance windows

In recent years, technologies like multithreaded processors, virtualization, and containerization have emerged. Using these paired with microservice architectures and good software development practices helps to reduce or completely eliminate the use of maintenance windows.

However, while almost all business owners and product managers seek to minimize downtime, sometimes that is not possible. Usage of legacy software, regulations that apply to your business, or simply working in an environment in which the decision makers believe that the best way of maintaining the service is having a regular, scheduled downtime, forces us to bring our service down for a certain amount of time. 

So, in any of these situations, how should these maintenance windows affect your error budget? Let’s analyze some different scenarios where maintenance windows are necessary.

Business hours

Imagine you work at a company that serves a market with a trading window, like a Wall Street exchange. Every day your service starts operating at 9:30am and closes at 4:00pm sharp. No delays are permitted, either at the start or the end of the window.

You can assume in this case that you have a maintenance window of ~15 hours a day. Should it burn through your error budget, then?

Let’s remember the purpose of your error budget: It is a tool that helps identify when the reliability metrics for user journeys (your SLIs) have performed, over a period of time, at levels that are hurting your users.

In this scenario, users are not able to use the service outside of business hours. In fact, users most likely should not be able to interact with the service at all. So, effectively, there is no harm in having this service down, and over this period of time, the error budget should not be affected at all.

Burning your error budget in saw shapes

Let’s move on to a different type of service, one that is extremely localized in space, serving only users in a single country. Think of a retailer with presence only in a small region. Your service may have a traffic pattern like this one:

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_DOv6dg1.max-900x900.jpg

There are easily identifiable lows of traffic, where your users are probably sleeping, but even over those valley periods, you still receive a non-zero amount of requests. If you plan your maintenance windows during these periods, you have plenty of time to recover from errors, but at the risk of running into rising traffic if your maintenance overruns.

For these saw-shape cases, let’s analyze a few strategies:

Traffic projection

For this approach, you’ll look at your past data and extrapolate the amount of valid traffic you’ll receive during the period of time your service will be unavailable by analyzing previous traffic and calculating what you expect to receive. Even if you have limited data to work with, use whatever data you have collected to calculate your traffic pattern.

An important factor you have to take into account for this approach is that it is based on past performance, and it does not account for unforeseen events. To make sure the traffic that your site receives during a downtime window is not out of the ordinary, set up a captive portal that registers the incoming requests and redirects all traffic (including deep links) to a maintenance page. From those requests, you can easily analyze the traffic logs and count the valid ones. This way, you are not measuring the actual traffic, but the traffic pattern. Correlating this pattern with the actual missed traffic, using a reasonable multiplier, allows you to calculate the number of errors you are serving, and thus the error budget you are burning.

Treat maintenance as downtime

When burning through the error budget associated with the availability of a service, it is usually done by counting the errors produced by the service. But when the service is down, you can also do it by measuring the time the service is down in relation to the total downtime your SLO allows you, as a percentage.

Say that the SLO on availability for your service is 99%. Over a period of 28 days (measured using a rolling window) your service can be down a total of about seven hours and 20 minutes. If your maintenance window stretches for a period of two hours, that means you have consumed 27% of your error budget. That means that for the rest of the 28 days of your rolling window, your service can only throw (100 — 27) * 0.01 = 0.73% of errors, down from the initial 1% of total errors. Once your maintenance is finished, you can go back to using the SLI equation, and knowing how much traffic you are receiving (your valid requests) and how many errors you are returning to your users, you can calculate how much error budget you are burning over time.

This approach has the disadvantage of treating all the traffic received as equal, both in size and in importance. A maintenance window occurring in the middle of the day when you are having a peak of traffic will burn the same amount of error budget as one happening in the middle of the night when traffic is low. So this approach should be used cautiously for traffic shapes that change wildly throughout the day.

Considering the edge case

In the situations described above, you need to take into account a small detail about the error budget. Say that you have an outage that burns a big chunk of your error budget, enough to bring the remaining budget close to zero (or even below), and the upcoming planned maintenance window is scheduled to happen inside the time window you use to calculate that error budget. If that scheduled downtime risks depleting your error budget, what are you supposed to do? 

We approach these situations by defining a number of “silver bullets”: a very small number of exceptions for truly business-critical emergency launches, despite the budget maintenance window freeze. Assuming the service still needs to be brought down, even for small updates, the use of a silver bullet lets you perform a short, very targeted maintenance window, during which only critical bug fixes can be released.

In general, we don’t recommend looking for other types of exceptions, since these will most likely create a culture in which failure to maintain the reliability of the service is accepted. That nullifies the incentive to work on the reliability of your service, as the consequences of outages can simply be bypassed by escalating the problem.

The curious case of not burning your error budget

Let’s, once more, remember how the error budget is used. As defined, the error budget is a tool to balance how you prioritize the time engineering teams spend between feature development and reliability improvements. It assumes that exhausting your error budget is a result of low availability, high latency, or other low score in any metric used to represent the reliability of your service.

If you burn part of your error budget during maintenance windows, but you aren’t planning to get rid of them altogether (or at least reduce the length of those windows), there is no reliability work targeted at reducing your maintenance windows that you may need to prioritize as a result of burning through the budget. You are implicitly accepting a recurring error budget burn, without a plan to eliminate the maintenance window that is causing it. You have no consequences defined in your error budget policy that will prioritize work to stop your maintenance windows from consuming error budget in the future.

So the lesson here is that the decision to burn through your error budget during your maintenance windows should be made only if you consider those downtime periods as part of your reliability work, and you plan to work on reducing them to minimize that downtime.

If you decide to assume the risk of having a period of time when your service is down and the business owners have agreed that they are OK with scheduled downtime, with no plans in place to change the status quo, you probably don’t want it to count it toward your error budget. This acceptance of risk has some very strong implications for your business, as your maintenance windows need to:

  • be as short as possible, to cause as little disruption as possible

  • be clearly and properly communicated to your users/customers, well in advance, using channels that reach as many as possible

  • be internally communicated to avoid disrupting other parts of your business

  • have a clearly defined plan of execution, exit criteria, expected results, and rollback action plan

  • be scheduled during expected low traffic hours

  • be executed according to its planned time slot

  • have well-defined (and in some cases, severe) consequences for your error budget when the windows go over time

Remember, according to the way the error budget is defined: During a maintenance window that does not count toward that error budget, you are taking a free pass for having your service down—possibly hurting your users but not accounting for it.

Flat(ish) profile in global services

In a global service, things are quite different. While your traffic profile may have valleys of traffic, they are likely less pronounced than those deep valleys of traffic you see in a localized service, when you can bring your service down and only affect a relatively small number of users.

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_oLrFwDV.max-900x900.jpg

But at the same time, due to the global nature of the service, you will probably require multi-regional presence. It’s in this situation where you can take advantage of the multi-region architecture and work to avoid localized maintenance windows by diverting traffic from the low-traffic areas to others.

Our recommendation for this case is to take advantage of the distributed nature of your architecture and design your service to allow for regions to be disconnected at any given time, if you still need to bring some of your systems down for maintenance. This approach should, of course, take into account your capacity needs, so that your remaining serving capacity will be able to respond to all the active requests previously served from the disconnected regions. Additionally, you should design circuit breakers that trip whenever there is a need to blackhole some of the overflowing traffic in order to avoid creating a cascading outage.

If this is your long-term goal, and assuming that your global service has no defined times of operation (like in our first scenario), any request that is not served (or served with an error) should be accounted for, and count toward your error budget burn.

Putting it all together

Although no single recommendation will fit all services, you can make informed decisions for your service once you examine maintenance windows in the context of SLOs and error budgets. You and your product owners are best positioned to know both your service and your users, understand their behavior, and make a decision that works best for your business.

The most important analysis you need to make is how your maintenance windows affect your users (if at all), and whether depleting your error budget is going to imply a change in your reliability focus to reduce the impact of your maintenance windows.

If you are considering introducing maintenance windows for your service, evaluate the pros and cons against the criteria outlined here. And if you already have them, check to see if you should change how you do them, or when you do them.

Further reading

If you want to learn more about the SRE operational practices, how to analyze a service, identify SLIs, and define SLOs for your application, you can find more information in our SRE books. You can also find our Measuring and Managing Reliability course on Coursera, which is a more thorough, self-paced dive into the world of SLIs, SLOs, and error budgets.

Posted in

  • Management Tools
  • Google Cloud
Источник

Понравилась статья? Поделить с друзьями:
  • Error break outside switch or loop
  • Error break not allowed
  • Error braces around scalar initializer
  • Error bp fileid 0x00006c 464
  • Error box tkinter