Как строить надежные, стабильные и отказоустойчивые IT-системы: главное об SRE и SLO

e3f2b4df5430e2bc2571b03ca0e261ce.png

К современным IT-системам предъявляются очень жесткие требования — они должны быть доступны практически 24/7, чтобы выдерживать конкуренцию на рынке. Для обеспечения такой надежности и доступности существует особый подход — SRE, Site Reliability Engineering.

Меня зовут Иван Круглов, я работаю в компании Databricks и уже несколько лет занимаюсь построением и поддержкой сложных и крупных IT-систем. Хочу рассказать, что такое подход SRE, зачем он нужен, какие критерии надежности существуют и как их определять.

Что такое SRE

Все в команде: программисты, админы, тестировщики и системные инженеры, работают над одной системной целью — создавать продукт, который приносит пользу клиентам. Есть множество инструментов, подходов и принципов для достижения этой цели: Agile в управлении проектами, DevOps в построении инфраструктуры и взаимодействии и т.п. 

Одним из таких подходов является SRE — Site Reliability Engineering. Его суть в том, что вся инфраструктура должна быть построена по определенным стандартам, которые обеспечивают ее максимальную надежность и доступность. При этом над инфраструктурой должна работать вся команда вместе, так что это история не только про технологии, но и про коммуникации внутри комманды.

SRE — тема не очень новая, впервые об этом подходе заговорили в 2016 году. Но сейчас в индустрии нет четкого определения этого понятия, поэтому я буду говорить о своем опыте, который я вынес из практики и чтения книг и материалов на эту тему.

Что входит в SRE

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

c1d28f34ce58979708aca6bfe5cea8ce.jpg

Поговорим про каждый аспект отдельно.

Культура. Это в первую очередь общие принципы работы — не технические, а именно управленческие. Для SRE они такие:

  • Совместное владение — все команды, которые работают над продуктом, трудятся вместе над одной целью.

  • Blame-less культура — при ошибке не ищут виноватых, а вместе разбираются над проблемой.

  • Постоянное измерение результатов. В SRE есть четкий алгоритм принятия решений на основе данных, а значит, эти данные следует постоянно замерять.

  • Инкрементальные изменения. Мы стараемся выкатывать все как можно быстрее, дробить работу на мелкие итерации и создавать стабильные промежуточные результаты. Это пришло из Agile.

  • Автоматизация. Все, что можно автоматизировать, нужно автоматизировать.

Техника. Это приемы и подходы по построению operation, поддержки, мониторинга и алертинга. Об этом много говорит Google в своих архитектурных докладах: например, о том, как построить высоконадежную систему из набора низконадежных систем.

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

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

На мой взгляд, классический DevOps — это более общая вещь. По сути это agile like framework, который говорит, куда именно двигаться, но не объясняет, как и что для этого сделать. То есть «Давайте делать хорошее и тогда все будет хорошо».

Подход SRE вырос из DevOps, но он уже гораздо более конкретизированный. У нас есть четкий алгоритм действий, конкретные подходы и инструкции, описанные в конкретных книгах. То есть это как раз ответ на вопрос «как и что делать, чтобы все было хорошо». 

Главные книги по теме SRE — это «Site Reliability Engineering. Надежность и безотказность как в Google» и «Site Reliability Workbook: практическое применение»

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

Главный аспект SRE, который мы рассмотрим — это SLO, Service Level Objective.

Что такое SLO

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

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

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

Как определять SLO на практике

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

В первую очередь для этого нужно включить в процесс не только инженеров, но и клиентов. Лучший способ для этого — выписать не только те метрики, которые интересны вам, но и те, которые важны для пользователей. Например, вам важно, чтобы сервис не падал. А что важно клиенту? Может быть, время отклика? Или скорость работы? Узнайте это с помощью опросов.

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

Что значит бесперебойно?

Бесперебойно — это работа в 100% случаев? Однозначно нет. Построить систему, которая работает вообще без сбоев, просто невозможно по нескольким причинам:

  • Всегда есть «последняя миля» — ноутбук пользователя, его интернет, электричество в розетке. И электричество на ваших серверах. Вы за это не отвечаете, но на работу вашего сервиса это влияет.

  • 100% надежности не гарантирует идеальный клиентский опыт. Клиентам может быть нужно другое, и концентрируясь на надежности, вы это упустите.

  • Если вы построите на 100% надежную систему, вы уже не сможете ее изменить. Потому что любое изменение снизит надежность. А в нашем постоянно меняющемся мире это равносильно смерти сервиса.

Значит, от идеи построить систему с доступностью 100% мы отказываемся. Но сколько процентов тогда выставлять? Есть вот такая табличка:

30b0277362c9afe42b7374680b70c812.jpg

Здесь показано, что при доступности на одну девятку вы можете себе позволить 2,5 часа даунтайма в день, то есть 10% дневного времени сервис может быть недоступен. Три девятки — это 1,44 минуты, а 5 девяток — уже меньше, чем секунда. То есть при добавлении каждой девятки показатель вырастает очень сильно.

Теперь представим, что вам нужно что-то сделать, например, переключиться между репликами. С одной девяткой у вас есть на это 2,5 часа — можно все сделать руками. С тремя девятками у вас только 1 минута 44 секунды — уже точно понадобится скрипт. А все, что выше — это уже полная автоматизация.

Как на надежность влияет число микросервисов

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

169500b02c780e6f692d99e8c91e60ea.jpg

То есть, если у каждого компонента доступность 95% то у системы из 10 компонентов она будет уже 70%.И чтобы добиться трех девяток, нужно либо снижать количество компонентов, либо делать каждый сервис высокодоступным. 

Какие цифры надежности обычно задают на практике

В своей практике я встречают с тремя, либо с тремя с половиной девятками. То есть надежностью на 99,9% или 99,95%. Четыре девятки тоже встречал — например, у нас в Booking это был сервис, который отвечал за хранение важных данных. Там нужна была доступность 99,99%.

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

Ответ за одну секунду — это быстро?

Здесь мы говорим о скорости работы. Нам важно понять, «быстро» — это как? Ответ зависит от того, что именно ожидают наши пользователи.

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

Плюс при оценке скорости отклика важно понимать, где именно мы ее оцениваем. Обычно у нас есть API, за ним стоит балансер нагрузки, например, Ingress, и уже за ним клиент. И время отклика везде будет разное:

ec9223ff3570632923383a929d146361.jpg

Поэтому то время ответа, которое вы видите на стороне сервера — далеко не показатель. Вам нужно попытаться «надеть тапки» пользователя и посмотреть на систему его глазами.

Для примера, случай из практики. Есть два графика:

32881bcebed1bb27d25a9b3e2095158b.jpg

Сверху у нас клиентский опыт ошибок, снизу — серверный. Как видите, на сервере ошибок нет вообще, а вот у клиента их достаточно. И если бы мониторинга алертов на клиентской стороне не было, ошибок мы бы просто не заметили. Ведь на сервере все работает идеально.

Что делать с плохими данными

Представим, что пользователь прислал невалидный ID на сеанс. Или к примеру пытается забронировать в отеле место, которого не существует. Понятно, что хранить эти данные смысла нет, но как учитывать их в SLO?

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

Данные, которые невалидны изначально, учитывать не стоит. Если пользователь неправильно прочел спецификацию или что-то сделал не так, это не наша ошибка. И к SLO точно не относится.

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

Кратко: самое главное об SRE

  1. SRE — это подход, который задает стандарты работы внутри команды для построения надежной, стабильной и высокодоступной инфраструктуры. 

  2. SRE объединяет конкретные технологии, особую культуру работы и организационные процессы.

  3. В отличие от DevOps, SRE предлагает не только общее направление, но и конкретные инструменты для достижения целей.

  4. Для SRE очень важно SLO — конкретные измеримые характеристики доступности системы.

  5. Обычно «стандартно» SLO можно определить так — сервис должен работать быстро, бесперебойно и хранить и предоставлять достоверные данные.

9 июня в 19:00 бесплатный вебинар по SRE

На вебинаре:

  • Поговорим, что такое SRE и с чем его едят, в чем ценность.

  • Нужны ли эти внедрения вам и вашей компании, каких результатов можно достичь, а каких — нет. 

  • Обсудим опыт внедрения SRE в компаниях участников прошлых интенсивов, поговорим про показатели.

  • Ответим на ваши вопросы и разыграем 5 бесплатных мест на интенсив.

В результате вебинара:

Инженеры, разработчики: поймут как этот интенсив встраивается в их карьерный путь, что важно для компании и менеджмента, и как продать идею внедрения SRE в своем отделе / компании.

Представили компании: узнают какой профит получит компания, если отправит к нам на курс 2–3, 10 или 50 человек.

Зарегистрироваться на вебинар.

Курс по SRE.

© Habrahabr.ru