Site reliability engineering что это
Обязанности SRE-инженера в зарубежных вакансиях
Введение
В 2016 году Google выпустила ту самую книгу о SRE (Site Reliability Engineering). Эта практика решала важную задачу компании — поддержание высокой надёжности сервисов Google. За годы практика широко распространилась среди разработчиков по всему миру. Теперь во многих стартапах и крупных корпорациях есть должность SRE-инженера.
Так менялся интерес работодателей к SRE-инженерам с течением времени.
Тренд поиска SRE-инженеров
Практика относительно новая, так что пока не совсем понятно, что конкретно должны делать SRE-инженеры. Можно, конечно, почитать книжки или посмотреть видео, но полный список должностных обязанностей по ним не составишь.
Результаты аналитики
Мы выделили несколько основных обязанностей:
Деплой и обслуживание инфраструктуры (84% объявлений).
Определение и контроль SLO, SLI и бюджетов на ошибки (34% объявлений).
Настройка мониторинга и алертов (47% объявлений).
Дежурство, реагирование на инциденты, постмортемы (47% объявлений).
Создание инструментов и автоматизация (56% объявлений).
Комментарий Евгения Бутырина, технического редактора Слёрм
В вакансиях Российских компаний эти обязанности также присутствуют, в тех или иных формулировках. С упоминанием обязанностей в процентом соотношении всё не так прозрачно. Зачастую в вакансиях пишут где-нибудь в требованиях: уметь в мониторинг. А в обязанностях ни слова, но мы понимаем, что раз нужно знать, значит понадобится. Та же история с SLO и бюджетом на ошибки, будучи одними из основных практик, по умолчанию подразумевается, что это надо знать и уметь. А про дежурства может быть написано: обеспечивать работоспособность сервисов 24/7.
Деплой и обслуживание инфраструктуры
Одна из главных задач SRE-инженера — проектировать, создавать и обслуживать инфраструктуру, в которой работают продукты и сервисы компании. Это может быть частное облако, но все чаще публичное, например AWS или Google Cloud. Сейчас популярно писать инфраструктуру как код (IaC), используя синтаксис YAML и HCL (для продуктов Hashicorp, вроде Terraform).
Чтобы принимать правильные решения об инфраструктуре, SRE-инженер должен участвовать в планировании ресурсов для новых и существующих продуктов, в том числе обсуждать с командами по продуктам и другими инженерами примерную нагрузку, требования к задержкам и т. д.
Иногда SRE-инженер отвечает за комплаенс инфраструктуры, особенно за соблюдение GDPR и SOC2. Наконец, большинство компаний стараются оптимизировать расходы на инфраструктуру, и этим тоже должен заниматься SRE.
Определение и контроль SLO, SLI и бюджетов на ошибки
Поддерживать надёжность производственных систем — важная обязанность SRE-инженера. Все-таки R в SRE означает reliability. Нужно понимать, как достичь корректной работы сервиса и соблюсти внутренние стандарты.
Для этого SRE-инженер определяет SLO и SLI. SLO — это показатели целевого уровня обслуживания для сервиса, а SLI — индикаторы, которые измеряют эти уровни. SLO можно определить вместе с коллегами на основе ожиданий клиентов и обязательств перед клиентами, сформулированных в виде SLA.
Когда SLO определены, их можно использовать как основу бюджетов на ошибки, то есть допустимого периода, когда сервис может работать ниже целевых уровней. В любой системе сбои неизбежны, и командам SRE и разработчиков нужен этот запас в виде бюджета на ошибки. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным.
Комментарий Павла Селиванова, Архитектора VK Cloud Solutions, спикера Слёрм
Ещё с помощью бюджета можно понимать когда нужно работать над новыми фичами, а когда стоит поработать над стабильностью продукта.
Настройка мониторинга и алертов
Когда SLO определены, можно следить за их соблюдением с помощью SLI и мониторинга. Обычно мониторинг охватывает инфраструктуру (пики использования процессора и памяти), аптайм сервиса (веб-сайта или API), производительность (скорость загрузки страницы) и т. д. Можно использовать локальные инструменты, вроде Prometheus и Grafana, или популярные SaaS, например Datadog и Sentry.
Настройка мониторинга и алертов — это первый шаг. Нужно установить адекватные пороги, чтобы на команду не хлынул поток несущественных алертов. Алерты должны быть связаны с конкретными действиями, причем лучше заранее узнавать о симптомах, чтобы принимать меры, а не получать уведомления об уже случившихся сбоях.
Дежурство, реагирование на инциденты, постмортемы
Мы настроили мониторинг и получаем алерты, а теперь надо составить график дежурств и распределить обязанности по реагированию среди членов команды. Лучше использовать платформу управления инцидентами, чтобы все инциденты и алерты были собраны в одном месте, причём у каждого инцидента должен быть чётко определён ответственный сотрудник. Это поможет рассчитать важные метрики, вроде MTTA (среднее время реагирования) и MTTR (среднее время восстановления).
Ещё одна задача SRE-инженера — писать постмортемы, чтобы объяснить внешним и внутренним стейкхолдерам, какая цепочка событий привела к инциденту, какие меры были приняты и что было сделано, чтобы такого не повторилось.
Комментарий Павла Селиванова, Архитектора VK Cloud Solutions, спикера Слёрм
Создание инструментов и автоматизация
Один из принципов SRE — устранение ручного труда. Google SRE определяет тяжелый труд как выполняемые вручную, повторяющиеся и нетактические задачи, которые можно автоматизировать. Эти задачи отнимают время разработчиков и SRE и мешают другим важным проектам. Автоматизировать повторяющиеся задачи — одна из важных обязанностей SRE-инженера. Это может быть автоматическое реагирование на распространённые алерты, настройка процесса CI/CD, чтобы команда работала быстрее, или создание продуктов, с помощью которых разработчики могут сами выполнять рутинные запросы.
Другие обязанности
В некоторых компаниях SRE-инженеры могут выполнять и другие задачи:
Отладка проблем в продакшене. Может затрагивать все уровни стека.
Разработка мультиоблачной стратегии. Сейчас всё больше рабочих нагрузок мигрирует в публичное облако, но стоит избегать зависимости от вендора — так дешевле и надёжнее. Поэтому сейчас многие компании стараются приспособить свои продукты к разным облачным платформам.
Хаос-инжиниринг. Впервые применен Netflix, а сейчас внедряется и в других компаниях. Это метод, при котором мы стараемся сломать систему изощрёнными способами, чтобы проверить ее устойчивость.
Заключение
Как видите, SRE-инженер должен не просто обслуживать инфраструктуру или помогать с CI/CD. Поддержание нормальной работы сервисов затрагивает разные области эксплуатации и разработки программного обеспечения.
Евгений Бутырин
Над материалом работала команда курса «SRE: внедряем DevOps от Google». Учебный центр Слёрм работу не обещает, но спикеры могут кое-чему научить.
Site Reliability Engineering: антология мудрости Google или новое слово в DevOps
Здравствуйте, уважаемые читатели!
Полагаем, не только нас заинтересовала книга «Site Reliability Engineering», написанная большим коллективом авторов из Google. Мало того, что она продолжает занимать первые строчки всевозможных рейтингов Amazon; самое интересное, что в ней дается действительно доступная и исчерпывающая информация о безупречной эксплуатации систем любой сложности.
Более того, нас в перспективе интересует и более общая обзорная книга по методологии DevOps, выхода которой мы с нетерпением дожидаемся:
Поскольку мы практически убеждены, что варан с быком составят идеальную пару, остается надеяться на не меньший читательский интерес к SRE и DevOps. Предлагаем изучить немного сокращенный обзор книги «Site Reliability Engineering». Автор статьи Майк Догерти — один из соавторов книги, частично ее вычитывавший.
Около 2 лет компания Google работала над книгой «Site Reliability Engineering». Это особая дисциплина и организация рабочих процессов, при помощи которой Google обеспечивает гладкую и бесперебойную работу всех своих колоссальных систем. Эта книга только что вышла в оригинале. Ее объем составляет более 500 страниц, а на ее страницах подробно рассказано, как именно работает Google. Авторы пишут на редкость открыто, не скрывают названий проектов и систем, объясняют, как функционируют эти системы. Да, вы не найдете на страницах исходного кода, зато сможете взять на вооружение массу приемов, которые пригодятся отнюдь не только в Google. Книга будет очень интересна сотрудникам стартапов, мечтающим вырастить большую компанию, а также работникам средних и небольших технологических компаний, желающих повысить надежность своих сервисов.
Сразу признаюсь, что работал SRE-инженером в Google и участвовал в написании небольшого фрагмента главы 33, где рассказывается, как принципы SRE можно применять в нетехнической области.
Разумеется, мне эта книга Америку не открыла, ведь я работал в той самой организации, в недрах которой она родилась. Но я интересуюсь тем, что Google пытается донести до остальной части технического сообщества. Google уже давно старается четко описать, что же такое SRE. Именно такая неопределенность озадачила меня, когда я устраивался на работу в Google по этой специальности. Но Google исключительно хорошо справляется с эксплуатацией гигантских систем, а SRE – набор практик и методов, позволивших сформировать такую технологическую культуру, которая обеспечивает подобную эффективность.
Спешу вас порадовать: даже если у вас нет систем вроде Borg или Chubby, вы все равно можете делать многие вещи, которыми занимаются SRE-инженеры в Google. Книга содержит массу практических советов о том, как правильно построить такую работу, что делать и чего не делать (кстати, книга приятно удивляет тем, как здраво в ней рассматриваются допускавшиеся ошибки).
Насколько мне известно, все технологии, упоминаемые в книге, уже засветились в открытых источниках. В последние годы появились статьи и лекции по Piper, Borg, Maglev и т.п., поэтому авторы также свободно рассуждают о них. Конкретные технологии интересны как материал для кейсовых ситуаций, но наиболее интересны не отдельные продукты или системы как таковые, а информация о том, как Google реализовал эти проекты в соответствии с принципами SRE. Итак, это книга о SRE, а не о конкретных системах. Большая часть материала в книге посвящена не готовым системам, а принципам и практикам, которыми может воспользоваться читатель. Правда, эти принципы и практики лучше работают не по отдельности, а как единое согласованное целое. К счастью, в книге найдутся дельные советы для самых разных читателей, целевую аудиторию я подробнее опишу в заключительной части этого обзора.
Книга делится на пять частей: Введение, Принципы, Практики (самый объемный раздел, на него приходится около 60% объема книги), Менеджмент и Заключение. Я хотел вкратце рассказать об отдельных главах, которые считаю особенно интересными или ценными для читателя. Если эта часть вас не интересует, можете ее пропустить и сразу перейти к разделу «Немного размышлений», где я рассуждаю, чем книга о SRE может быть полезна конкретному читателю.
«Введение» важно прочитать, так как в нем задается контекст для обсуждения всех дальнейших тем, поэтому настоятельно рекомендую его не пропускать. В первой главе рассказывается, что такое SRE, а также указываются различия между SRE, системным администрированием и DevOps. Во второй главе в общих чертах описано, как построена рабочая среда Google – от Borg до хранилищ данных, сетей и сред разработки.
Раздел «Принципы» базируется на материале главы 1 и начинается с темы управления рисками. Этот материал крайне важен, чтобы понять прочность и упругость систем SRE. Если бы мы хотели 100% стабильности, то просто не позволили бы разработчикам что-либо менять. Но это убивает бизнес. В действительности же мы учимся управлять уровнем риска, который на себя принимаем, и работать максимально быстро. При этом, поломки не исключены, главное, чтобы они укладывались в наш ремонтный бюджет.
Далее упомяну о главах 6 и 10, где подробно объясняется, как Google отслеживает работу своих колоссальных систем, и как мы получаем оповещения о возникающих проблемах (здесь также объясняется смысл понятия «неправильно», что очень важно). Вероятно, проблема мониторинга не менее сложна, чем монтаж тех самых систем, которые придется отслеживать, и решение этой задачи – искусство (системных) программистов.
В главе 7 рассмотрено, как велика роль автоматизации при SRE. В столь масштабных системах как наши ценность автоматизации невозможно переоценить, но, поскольку Google продолжает расти, мы стремимся создавать новые системы, чьи возможности выходят далеко за рамки автоматизации. Только так мы можем надеяться, что справимся с эксплуатацией наших крупнейших нынешних систем, а также тех систем, что появятся в будущем.
Один из важнейших аспектов SRE – соответствующая культура. Эта тема эпизодически затрагивается во всей книге, но наиболее важна в данном контексте «культура анатомирования». В главе 15 объясняется, что это такое, и почему анатомирование должно быть безупречным.
В главе 17 обсуждается тестирование надежности. Это одна из немногих глав, обманувших мои ожидания. Хотя в ней и рассматриваются такие важные темы, как нагрузочное тестирование и «звоночки», эти темы не обсуждаются в деталях. Может быть, авторы просто не хотели вдаваться в подробности, либо материал пришлось сократить (если так, то я лучше сократил бы какой-нибудь другой фрагмент), но, так или иначе, осадок остался.
Далее следуют четыре главы, в которых объясняется, как в Google организуют балансировку нагрузки на различных уровнях (главы 19 и 20), как справляются с перегрузками и избегают каскадирующих отказов (главы 21 и 22). Все эти темы сильно взаимосвязаны, они, безусловно, заслуживают уделенных им 60 страниц. У нас есть стандартные серверные и клиентские реализации обратного воздействия (backpressure), взвешенная балансировка нагрузки по принципу карусели, частичный бэкап баз данных (subsetting), приоритет и критичность запросов, а также сегментация нагрузки, стоимость запросов и многое другое. Все эти механизмы важны для избегания перегрузки и каскадирующих отказов, поэтому лучше разобрать их по такой книге, чем учиться на собственных ошибках.
В следующих двух главах, 23 и 24, рассмотрены распределенно-согласуемые системы и Borgcron – распределенная cron-служба Google, работающая по принципу такого согласования. Работать с распределенным cron сложнее чем кажется, поэтому читателю предстоит поучительная экскурсия по многоуровневой структуре, при выстраивании которой cron с единственной машины превращается в Borgcron.
Часть 4 посвящена управлению SRE-командами. Поскольку этот материал был мне не так интересен как техническая часть книги, сразу перейду к главе 32 «Разработка развивающихся сервисов: фреймворки и платформа SRE». МЫ считаем, что подобная работа по стандартизации платформы критически важна для масштабирования SRE, а, следовательно, и систем Google.
В части 5 излагаются истории о том, как достигается высокая надежность в других отраслях промышленности. Именно эту главу меня попросили просмотреть перед публикацией. Не уверен, насколько она обогащает книгу, но все-таки важно проследить общие черты в обеспечении надежности самых разных систем – тем самым авторы доказывают, что Google SRE развивается в верном направлении.
Итак, после достаточно беглого обзора важнейших частей книги я хотел бы поговорить о том, чем она особенно ценна. Может быть, Google просто бахвалится, либо читатель все-таки что-то вынесет из этой книги? Будут ли описанные в книге приемы полезны для сотрудников небольших компаний? Полагаю, да. Здесь вы найдете массу дельных советов для ведения open source-проектов, для работы в маленьких и больших технологических компаниях, где еще нет такой зрелой системы SRE, как в Google.
Многие приемы разработки и тестирования, описанные в книге, легко реализуемы в свободных проектах. Системы нужно проектировать с учетом обратного воздействия и изящной деградации, прозрачного мониторинга, обширного тестирования, не ограниченного модульными тестами и т.д.
Чем может быть полезна такая книга в небольших компаниях, где за эксплуатацию систем отвечают всего несколько инженеров, типичные сисадмины? Во-первых, она может показать иной путь. Речь не о том, чтобы реализовывать все эти возможности, мне такая задача кажется неподъемной. Но важно усвоить сами принципы. Наем и обучение сисадминов следует модифицировать, чтобы эти сотрудники стали дописывать те элементы программ, которых может недоставать. Сисадмин должен безупречно анатомировать ошибки, а также исправлять все действующие элементы, которые могли не сработать при отказе системы. Когда бюджет на исправление ошибок начинает исчерпываться, последовательность релизов нужно замедлить. В частности, обратите внимание на главу 30 «Берем на вооружение SRE для сглаживания эксплуатационной перегрузки». Также посмотрите главы 1 и 28.
В более крупных компаниях, где хватает талантливых инженеров, но процесс SRE как следует не организован, книга может быть полезна в разных отношениях; все зависит от того, в чем, н ваш взгляд, организация не дотягивает с инженерной точки зрения. Может быть, у вас по-прежнему существует специальный эксплуатационный отдел, может быть, вы уже занимаетесь DevOps, но всегда может наступить время, когда назреет необходимость изменить инженерную структуру организации. Допустим, у вас нет стандартов по борьбе с перегрузками и каскадирующими отказами — тогда вложите средства в создание таких циклов разработки, которые позволят создать такую инфраструктуру. Если возникают проблемы с балансировкой нагрузки — почитайте, как это делается в Google.
Наконец, должен упомянуть, что книга читается очень легко.
Настоятельно рекомендую эту книгу всем специалистам по DevOps, поддержке, обеспечению надежности и разработке масштабных программных проектов. Книга помогает не только взглянуть за кулисы Google, что само по себе бесценно, но и содержит дельные советы от специалистов Google, буквально из первых рук. Поверьте, все изложенные в ней идеи абсолютно реализуемы.
Цели уровня обслуживания — опыт Google (перевод главы книги Google SRE)
SRE (Site Reliability Engineering) — подход к обеспечению доступности веб-проектов. Считается фреймворком для DevOps и говорит как добиться успеха в применение DevOps-практик. В этой статье перевод Главы 4 Service Level Objectives книги Site Reliability Engineering от Google. Этот перевод я готовил самостоятельно и полагался на собственный опыт понимания процессов мониторинга. В телеграм-канале monitorim_it и прошлом посте на Хабре я публиковал также перевод 6 главы этой же книги о мониторинге распределённых систем.
Перевод по катом. Приятного чтения!
Невозможно управлять сервисом, если нет понимания о том, какие показатели на самом деле имеют значение и как их измерять и оценивать. С этой целью мы определяем и предоставляем определенный уровень обслуживания нашим пользователям, независимо от того, используют ли они один из наших внутренних API или публичный продукт.
Мы используем свои интуицию, опыт и осознаём желание пользователей иметь представление об индикаторах уровня обслуживания (SLI), целях уровня обслуживания (SLO) и соглашении об уровне обслуживания (SLA). Эти измерения описывают основные метрики, которые мы хотим контролировать и на которые будем реагировать, если не сможем предоставить ожидаемое качество сервиса. В конечном счете, выбор подходящих показателей помогает управлять правильными действиями, если что-то пойдет не так, а также дает уверенность команде SRE в здоровье сервиса.
В этой главе описывается подход, который мы используем для борьбы с проблемами метрического моделирования, метрического отбора и метрического анализа. Большая часть объяснений будет без примеров, поэтому мы будем использовать сервис Шекспир, описанный в примере его реализации (поиск по произведениям Шекспира), чтобы проиллюстрировать основные моменты.
Терминология уровня обслуживания
Многие читатели, вероятно, знакомы с концепцией SLA, но термины SLI и SLO заслуживают тщательного определения, поскольку в общем случае термин SLA перегружен и имеет ряд значений в зависимости от контекста. Для ясности, мы хотим отделить эти значения.
Индикаторы
SLI является индикатором уровня обслуживания — тщательно определенной количественной мерой одного из аспектов предоставляемого уровня обслуживания.
Для большинства сервисов в качестве ключевого SLI считают задержку запроса — сколько времени требуется для возврата ответа на запрос. Другие распространенные SLI включают частоту ошибок, часто выражаемую как долю всех полученных запросов, и пропускную способность системы, обычно измеряемую в запросах в секунду. Измерения часто агрегируются: сырые данные сначала собираются, а затем преобразуются в скорость изменения, среднее значение или процентиль.
В идеале, SLI непосредственно измеряет уровень обслуживания, представляющий интерес, но иногда для измерения доступна только связанная метрика, потому что первоначальную трудно получить или интерпретировать. Например, задержки на стороне клиента часто является более подходящей метрикой, но бывает, что измерение задержки возможно только на сервере.
Другим видом SLI, важным для SRE, является доступность или часть времени, в течение которого сервисом можно пользоваться. Часто определяется как доля успешных запросов, иногда называемых выработкой. (Продолжительность срока службы — вероятность того, что данные будут храниться в течение длительного периода времени, ещё важна и для систем хранения данных.) Хотя доступность на 100% невозможна, доступность близкая к 100% часто достижима, значения доступности выражаются в виде количества «девяток» процента доступности. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток». Текущая заявленная цель доступности Google Compute Engine — «три с половиной девятки» или 99,95%.
SLO — это цель уровня обслуживания: целевое значение или диапазон значений для уровня обслуживания, который измеряется SLI. Нормальным значением для SLO является «SLI ≤ целевого значения» или «нижняя граница ≤ SLI ≤ верхняя граница». Например, мы можем решить, что мы вернем результаты поиска по произведениям Шекспира «быстро», приняв в виде SLO значение средней задержки запроса поиска меньшее 100 миллисекунд.
Выбор подходящего SLO — сложный процесс. Во-первых, вы не всегда можете выбрать конкретное значение. Для внешних входящих HTTP-запросов к вашему сервису метрика количества запросов в секунду (QPS) в основном определяется желанием ваших пользователей посетить ваш сервис, и вы не можете установить SLO для этого.
С другой стороны, вы можете сказать, что хотите, чтобы средняя задержка для каждого запроса составляла менее 100 миллисекунд. Постановка такой цели может заставить вас писать свой фронтэнд с малой задержкой или покупать оборудование обеспечивающее такую задержку. (100 миллисекунд, очевидно, является произвольной величиной, но лучше иметь ещё более низкие показатели задержки. Есть основания полагать, что высокая скорость лучше, чем медленная, и что задержка обработки пользовательских запросов выше определенных значений фактически вынуждает людей держаться подальше от вашего сервиса.)
Опять же, это более неоднозначно, чем может показаться на первый взгляд: совсем выбрасывать QPS из расчёта не стоит. Дело в том, что связка QPS и задержка сильно связаны друг с другом: более высокий QPS часто приводит к большим задержкам, и обычно сервисы испытывают резкое снижение производительности при достижении определенного порога нагрузки.
Выбор и публикация SLO задаёт пользовательские ожидания о том, как будет работать сервис. Эта стратегия может уменьшить необоснованные жалобы на владельца сервиса, например, на его медленную работу. Без явного SLO пользователи часто создают свои собственные ожидания относительно желаемой производительности, которые могут быть никак не связаны с мнением людей, проектирующих и управляющих сервисом. Такой расклад может привести к завышенным ожиданиям от сервиса, когда пользователи ошибочно полагают, что сервис будет более доступным, чем он есть на самом деле и вызывать недоверие, когда пользователи считают, что система менее надежная, чем она есть на самом деле.
Соглашения
Cоглашение об уровне обслуживания — это явный или неявный контракт с вашими пользователями, который включает в себя последствия наступления (или отсутствия) SLO, которые в них содержатся. Последствия наиболее легко распознаются, когда они являются финансовыми — скидка или штраф, — но они могут принимать другие формы. Легкий способ рассказать о разнице между SLO и SLA заключается в том, чтобы спросить «что произойдет, если SLO не будут выполнены?». Если нет явных последствий, вы почти наверняка смотрите на SLO.
SRE обычно не участвует в создании SLA, поскольку SLA тесно связаны с решениями для бизнеса и продуктов. SRE, однако, участвует в оказании помощи при предотвращении последствий неудачных SLO. Они также могут помочь определить SLI: очевидно, должен быть объективный способ измерения SLO в соглашении или возникнут разногласия.
Google Search — пример важного сервиса, который не имеет SLA для общественности: мы хотим, чтобы все пользовались Поиском как можно более эффективно, но мы не подписали контракт со всем миром. Тем не менее, все еще есть последствия, если поиск недоступен — недоступность приводит к падению нашей репутации, а также к снижению доходов от рекламы. У многих других сервисов Google, таких как Google for Work, есть явные соглашения об уровне обслуживания с пользователями. Независимо от того, имеет ли конкретная услуга SLA, важно определить SLI и SLO и использовать их для управления службой.
Так много теории — теперь к опыту.
Индикаторы на практике
Учитывая, что мы сделали вывод, что важно выбрать подходящие показатели для измерения уровня обслуживания, как вы теперь узнаете, какие показатели имеют значение для сервиса или системы?
О чем вы и ваши пользователи заботитесь
Не нужно использовать каждый показатель в качестве SLI, который вы можете отслеживать в системе мониторинга; понимание того, что пользователи хотят от системы, поможет выбрать несколько показателей. Выбор слишком большого количества индикаторов затрудняет должный уровень внимания к важным показателям, в то время как выбор небольшого количества может оставить значительные куски вашей системы без внимания. Обычно мы используем несколько ключевых индикаторов для оценки и понимания состояния системы.
Сервисы, как правило, можно разбить на несколько частей с точки зрения SLI, которые являются для них актуальными:
Сбор индикаторов
Многие индикаторы уровня сервиса наиболее естественно собирать на стороне сервера, используя систему мониторинга, такую как Borgmon (см. Главу 10 Практика оповещений по данным временных рядов) или Prometheus, или просто периодически анализируя логи, выявляя HTTP ответы со статусом 500. Тем не менее, некоторые системы должны быть снабжены сбором метрик на стороне клиента, так как отсутствие мониторинга на стороне клиента может привести к пропуску ряда проблем, которые затрагивают пользователей, но не влияют на показатели на стороне сервера. Например, сосредоточенность на задержке ответа бэкэнда нашего тестового приложения с поиском по произведениям Шекспира может привести к задержке обработки запросов на стороне пользователя из-за проблем с JavaScript: в этом случае измерение того, сколько времени займет обработка страницы в браузере, является лучшим показателем.
Агрегация
Для простоты и удобства использования мы часто агрегируем сырые измерения. Это необходимо делать осторожно.
Некоторые показатели кажутся простыми, например, количество запросов в секунду, но даже это, очевидное, прямое измерение неявно агрегирует данные по времени. Является ли измерение полученным конкретно один раз в секунду или это измерение усреднено по количеству запросов в течение минуты? Последний вариант может скрыть гораздо более высокое мгновенное количество запросов, которые сохраняются всего на несколько секунд. Рассмотрим систему, которая обслуживает 200 запросов в секунду с четными номерами и 0 в остальное время. Константа в виде среднего значения в 100 запросов в секунду и вдвое большая мгновенная нагрузка — совсем не одно и то же. Точно так же усреднение задержек запросов может показаться привлекательным, но скрывает важную деталь: вполне возможно, что большинство запросов будут быстрыми, но среди них окажется много запросов, которые будут медленными.
Большинство показателей лучше рассматривать как распределения, а не средние. Например, для SLI задержки некоторые запросы будут обрабатываться быстро, в то время как некоторые всегда будут занимать больше времени, иногда намного больше. Простое среднее может скрывать эти длительные задержки. На рисунке приведен пример: хотя типичный запрос обслуживается примерно 50 мс, 5% запросов в 20 раз медленнее! Мониторинг и оповещения, основанные только на средней задержке, не показывают изменений в поведении в течение дня, когда на самом деле существуют заметные изменения в длительности обработки некоторых запросов (самая верхняя строка).
50, 85, 95, и 99 процентили задержки системы. Ось Y приведена в логарифмическом формате.
Использование процентилей для индикаторов позволяет увидеть форму распределения и его характеристики: высокий уровень процентиля, такой как 99 или 99,9, показывает наихудшее значение, а на 50 процентиле (также известном как медиана) можно увидеть наиболее частое состояние метрики. Чем больше дисперсия времени отклика, тем сильнее длительные запросы влияют на пользовательский опыт. Эффект усиливается при высокой нагрузке при наличии очередей. Исследования пользовательского опыта показали, что люди обычно предпочитают более медленную систему с высокой дисперсией времени отклика, поэтому некоторые команды SRE сосредотачиваются только на высоких процентильных значениях, исходя из того, что если поведение метрики на 99,9 процентиле является хорошим — большинство пользователей не будут испытывать проблем.
Примечание по статистическим ошибкам
Обычно мы предпочитаем работать с процентилями, а не со средним (средним арифметическим) набором значений. Это позволяет рассматривать более дисперсные значения, которые часто имеют существенно отличающиеся (и более интересные) характеристики, чем среднее. Из-за искусственного характера вычислительных систем значения метрик часто искажаются, например, ни один запрос не может получить ответ менее чем за 0 мс, а тайм-аут в 1000 мс означает, что успешных ответов со значениями, превышающими таймаут, не может быть. В результате мы не можем принять, что среднее и медианы могут быть одинаковы или близки друг к другу!
Без предварительной проверки и если некоторые стандартные предположения и аппроксимации не выполняются, мы стараемся не делать выводов, что наши данные нормально распределены. Если распределение не соответствует ожидаемому, процесс автоматизации, который устраняет проблему (например, когда видит выбросы за граничные значения, он перезапускает сервер с высокими задержками обработки запроса), может делать это слишком часто или недостаточно часто (оба варианта не очень-то хороши).
Стандартизировать индикаторы
Мы рекомендуем стандартизировать общие характеристики для SLI, чтобы не приходилось рассуждать о них каждый раз. Любая функция, которая удовлетворяет стандартным шаблонам, может быть исключена из спецификации отдельного SLI, например:
Цели на практике
Начните с размышлений (или узнайте!), о чем заботятся ваши пользователи, а не о том, что вы можете измерить. Часто то, что беспокоит ваших пользователей, трудно или невозможно измерить, так что в итоге вы приблизитесь к их потребностям. Однако, если вы просто начнете с того, что легко измерить, вы получите менее полезные SLO. В результате мы иногда обнаруживали, что первоначальное определение желаемых целей и дальнейшая работа с конкретными индикаторами работает лучше, чем выбор индикаторов, а затем достижение целей.
Определите цели
Для максимальной ясности, должно быть определено как измеряются SLO и условия, при которых они действительны. Например, мы можем сказать следующее (вторая строка такая же, как первая, но использует SLI-значения по умолчанию):