Привет! Меня зовут Кирилл Юрков, я SRE Team Lead в Samokat.tech. Уже более десяти лет занимаюсь ускорением и проблемами производительности, а также нагрузочным тестированием. 

Отвечая на вопрос, что делает SRE в Samokat.tech, скажу, что это те, кто занимается инцидентами и проблемами на всём их жизненном цикле, от этапа архитектуры и разработки до postmortem'а после инцидента.

В этом посте я хочу рассказать, как из нагрузочного тестировщика превратиться в SRE-инженера. Поделюсь, как этот путь проходил я сам, с какими сложностями сталкивался и что случалось на каждом этапе. Также раскрою в деталях саму роль SRE-инженера, чем он занимается и чем полезен. Возможно, после этого вы в команде решите, что вам такая роль тоже нужна (если у вас её ещё нет).

Отправная точка 

Почему начинаем именно с нагрузочника? Всё просто — это моя выдуманная карьерная лестница, которую я считаю интересной.

Первый уровень в начале описываемого профессионального пути – это нагрузочный тестировщик. Чтобы показать его, я воспользовался нейросетью, и она сгенерировала мне типичного джуниора-тестировщика.

Среда обитания этого персонажа — чаще всего тестовый стенд, а основные задачи таковы: 

• написание нагрузочных скриптов и заглушек 

• проверять соответствие результатов тестов и требований

• автоматизация;

• запуск тестов и их документирование. 

Не будем долго рассуждать о роли и функциональности этого персонажа, тем более он многим знаком, а сразу пойдём дальше.

Расширение контекста

Следующая возможная роль для нагрузочного тестировщика — инженер производительности. 

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

• локализация проблем производительности помимо проверки требований — это когда что-то пошло не так в ходе нагрузочного теста, или есть какая-то проблема, и нужно понять, в чём она заключается: высокое потребление CPU, утечки памяти, 500-е ошибки и т. д.;

• тюнинг производительности — с помощью кода или изменения конфигурации, реже архитектурные фиксы;

• умная автоматизация и работа с инструментарием — написание скриптов, автоматизирующих работу. 

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

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

Итоговый список основных задач инженера производительности выглядит так:

• локализация проблем производительности и её тюнинг;

• умная автоматизация и работа с инструментарием;

• скрипты и запуски;

• документация тестов;

• проверка требований от заказчика;

• написание заглушек;

• работа с проблемами прода (иногда);

• совсем редко испытания на проде (редко)

А теперь перейдём к тому, как нам превратиться из такого инженера производительности в SRE-инженера.

SRE-инженер и его starter pack

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

На этом этапе в голову приходят мысли: «Надо почитать, чем вообще должен заниматься SRE». И про это есть масса книг и подходов, которые легко гуглятся. Четыре вещи, которые можно найти с ходу – это performance, stability, availability и reliability. Собственно, это четыре базовых вещи, на которых строится SRE. 

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

По ходу дела может возникнуть вопрос: «А нужно ли нагрузочное тестирование, в этом вашем SRE? Или знания о JMeter, LoadRunner и Gatling, которые я копил, можно выкинуть?». На это я отвечу, что не нужно ничего выкидывать, ведь нагрузочное тестирование – это в том числе, инструментарий для SRE. Хорошее тому подтверждение – популярный инструмент k6, который прямо на главной странице своего сайта заявляет, что это средство нагрузочного тестирования для SRE.

Производительность

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

Для того чтобы оценить capacity этой всей инфраструктуры, надо её как-то релевантно нагрузить — подумают бывалые нагрузочные тестировщики. И это задача, которая потребует очень много ресурсов.

Здесь советую идти от простого, и в самые популярные практики внедрять какие-то определённые триггеры. Например, мы в Samokat.tech живём в Kubernetes-среде на «железных» машинах. У нас есть определённый набор триггеров, который помогает соблюдать практику capacity planning.

Когда наш кластер утилизирован на 70%, мы понимаем то, что нам нужно закупать новые машины. Набор таких правил и будет являться практикой capacity planning. Основная её цель — предотвратить ресурсное исчерпание и делать его более прогнозируемым. И уже не нужно никаких супернагрузочных тестов. 

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

Стабильность

Стабильность системы означает её способность работать без каких-либо падений максимально длительное время.

Как этого достичь? Есть очень популярная практика, которая называется incident management, описанная, например, в классном подходе документации ITIL. Заключается она в том, что мы должны реагировать на текущие проблемы и убирать их влияние на нашу систему, тем самым предотвращая новые проблемы. Звучит просто, но за этим скрывается коммуникация большого количества команд и много действий. Одно радует — эти процессы хотя бы понятно описаны. 

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

Практики стабильности очень тесно связаны с требованиями, которые мы предъявляем. Например, у нас есть требования к Deployment и Runtime. Давайте посмотрим, что это за требования и как они выглядят: 

• настроены endpoints для Readiness/ Liveness probes;

• минимально развёртывание сервиса осуществляется в два инстанса;

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

• сервис не хранит состояние и умеет запускаться в нескольких экземплярах (позволяет горизонтально масштабироваться и обеспечивать отказоустойчивость);

• сервис пишет лог в stdout;

• выставлены целочисленные значения CPU requests (>=1);

• JVM | CPU requests =< 1 приводит к использованию SerialGC; 

• JVM | в сервисе используется JDK 11+ версии;

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

Возникает вопрос: как это всё проверять? Особенно если у нас в приложении может быть 5 тысяч сервисов в продакшене.

Чтобы решить эту задачу — мы можем влиять на производственный процесс, например, сказать тестировщикам: «Ребята, с сегодняшнего дня вы каждый релиз проверяете на вот эти требования таким-то образом», т.е рассказываем им, на какие пункты надо смотреть. 

У нас проверка идёт через валидацию манифестов - Kyverno (автоматизированный валидатор манифестов). Этот инструмент умеет проверить манифест на наличие пунктов, указанных выше. И если они не подходят под требования, которые вы укажите в Kyverno, то ваш деплой просто не пройдёт и вы увидите, в чём была проблема. Исправите и поедете на прод уже с хорошим приложением, которое соответствует требованиям. 

Надёжность

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

• Retryier;

• Burst/Rate Limiter;

• Circuit breaker;

• Balancer;

• Graceful degradation/fallback.

Здесь важно понять то, что эти паттерны в первую очередь влияют на слой приложения. 

Для того чтобы посмотреть, как эти паттерны работают в совокупности и понять, обеспечивают ли они нужную степень отказоустойчивости, нужны особенные тесты, например, Chaos engineering и испытания в проде (да-да).

Самый простой тест Chaos engineering выглядит следующим образом: запускаем нагрузочный тест и во время него у нас каким-то образом уничтожается под или инстанс нашего приложения. Без одного инстанса и при его падении наши приложения должны отвечать ровно тем нефункциональным требованиям, что и в полном составе.

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

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

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

Chaos engineering вместе с тестами в проде хорошо влияет на нашу надёжность. Вместе с этими практиками у нас появляются целые ворота в прод, вместо той двери, о которой мы говорили на уровне инженера по производительности.

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

Доступность

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

Часто можно нагуглить, что SRE-инженеры занимаются SLA/SLI/SLO, это обратная практика бюджету ошибок и про неё можно делать отдельную статью. Поэтому я лучше напишу про бюджет ошибок. Условно он показывает, сколько мы были недоступны для пользователей в каком-то временном эквиваленте. 

Давайте на коленке сделаем такой бюджет ошибок и разберём каждый пункт: 

• недоступность входных точек в бизнес-процессы;

• недоступность главного процесса, который приносит прибыль и каждого его этапа;

• потраченный бюджет == приоритезация задач отказоустойчивости.

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

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

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

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

Давайте сначала попробуем описать входную точку. Берём главную страницу, с которой выполняются 5-10 запросов в наш бэкенд при её загрузке. Запросы могут быть как блокирующие синхронные, так и не блокирующие асинхронные. 

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

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

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

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

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

Есть достаточно примеров таких бюджетов ошибок и этой доступности. Если зайти, например, на сайт AWS, то там написано, что их доступность 99,999%. Это тот процент времени внутри какого-то интервала, в который ребята гарантируют, что вы сможете зайти к ним  и что-нибудь сделать. В нашем случае мы стартанули с 99%, и смотрели, как мы тратим бюджет ошибок в месяц для этой величины. 

За всеми этими цифрами нужно не забывать, что бюджет ошибок – это про доступность для конкретной аудитории. Поэтому у нас в Samokat.tech есть две аудитории и два бюджета ошибок для каждой:

• основные клиенты — люди, которые в «Самокате» делают заказы и получают домой какие-то классные продукты очень быстро;

•  курьеры-партнёры и сборщики-партнёры, собирающие и доставляющие заказы, а также их руководители.

Индивидуальный бюджет ошибок для каждой из этих аудиторий это 7 часов 20 минут в месяц (1% времени в месяц). Именно столько времени мы можем «потратить» на ошибки исходя из наших же гарантий.

Итоговый портрет SRE-инженера

Теперь мы сложим всё то, что у нас получилось, и посмотрим на этого SRE-человека.

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

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

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

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