Как внедрить Site Reliability Engineering (SRE) в компании

В статье разбираемся, зачем компании Site Reliability Engineering (SRE) и когда его применять. Также здесь расписаны шаги, которые помогут обычному инженеру или разработчику внедрить SRE в своей компании.

Материал подготовлен по вебинару «SRE как профессиональный рост для специалиста и прорыв для компании».

Site Reliability Engineering (SRE) — не о том, чтобы сделать по-особенному. SRE — это про понимание своей системы:

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

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

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

SRE-подход позволяет быстрее реагировать на проблемы системы, из-за которых уходят пользователи; предотвращать большинство из них; а также использовать фидбек для улучшения сервиса и User Experience.

Что делать компании, чтобы перейти на SRE? Разберём три шага, которые помогут внедрить подход у себя.

Первый вопрос, который следует себе задать, прежде чем внедрять SRE: «Соответствует ли уровень доступности сервиса бизнес-целям?» Для ответа на этот вопрос стоит внутри своей команды или компании определить показатели доступности (SLI) с конкретными числовыми показателями (SLO). Затем соотнести ожидания и реальность.

Подробнее метрики SRE описаны в статье «Цель SRE — надёжная система».

Если ответ на вопрос «да, соответствует», то в целом всё хорошо и, наверное, делать ничего не стоит.

— Бывает, приходит компания и говорит: «Мы хотим SRE». Начинаешь смотреть и понимаешь, что там некоторые практики уже внедрены, просто об этом не знают. У них всё хорошо: великолепные девяточки доступности, прекрасные отзывы пользователей, даунтайм 15 минут в неделю и так далее. В этом случае на вопрос: «Что мы можем улучшить?» я отвечаю: «Зачем? У вас всё отлично. Дальнейшие улучшения не дадут ощутимого эффекта, а обойдутся дорого». Правда, такое бывает редко. Зачастую приходят компании в ужасном состоянии. Приходится неделями разбираться, чтобы понять, как им помочь минимальными затратами, — Максим Гусев, Tech Lead SRE, спикер Слёрма.

Если система не соответствует желаемому уровню доступности, стоит задать себе следующий вопрос: «Какие процессы из Site Reliability Engineering мы можем реализовать здесь и сейчас с максимальным эффектом?»

— Некоторые думают, что SRE — это что-то странное. Необязательно использовать эту аббревиатуру. Можно просто брать конкретные практики, и шаг за шагом внедрять их. Только нужно знать, что и в какой последовательности применять. Для этого сначала надо понять, что проще и быстрее всего сделать именно для вашей системы, — Владимир Федорков, спикер конференций и Слёрма, более 15 лет специализируется на высоких нагрузках.

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

Чтобы выбрать из всего многообразия остальных практик, нужно оценивать влияние каждой на систему и внедрять самые результативные. Например, один из основных инструментов SRE — это Kubernetes. Нужно ли в таком случае немедленно разворачивать кластер K8s? Если мы понимаем, что в текущей ситуации пользы от этого будет ноль, то лучше разобраться с другими вещами, а не бежать внедрять Kubernetes.

Нет универсального чек-листа, по которому можно проверить надёжность любого сервиса. Такой чек-лист варьируется от компании к компании. Есть девять часто встречающихся ошибок, исправив которые можно повысить отказоустойчивость своей системы. Владимир Федорков рассказывал о них в докладе «Как готовиться к подъёму нагрузки в условиях 2022» на Highload++ 2022.

Шаг №3 можно пропустить, если инициатива внедрения SRE исходит от менеджмента. В этом случае переход будет максимально быстрым и безболезненным.

Но что делать, если перевести свою компанию на SRE хочет рядовой инженер или разработчик, которому больно, что сервис постоянно падает, а он узнаёт об этом от техподдержки?

Есть два варианта.

Первый вариант — пойти к руководству и объяснить, что изменится, если внедрить конкретные инструменты или практики. Например, мы предлагаем использовать APM из разряда Sentry, Jaeger и т. д. Зачем это бизнесу? Это поможет собирать ошибки со стороны клиентов и улучшать сервис. Чем выше качество приложения, тем больше денег оно приносит.

Стоит подкрепить своё предложение фактами и цифрами из мира бизнеса — это увеличит шансы на то, что менеджмент поддержит идею. К примеру, можно посчитать профит от исправления ошибок и сказать руководителю, что устранение багов увеличит прибыль, допустим, на 30% в квартал.

Второй вариант — внедрение практики «с низов». Это когда два-три человека начинают использовать инструмент, и постепенно на него переходит вся компания.

— У меня такое происходило несколько раз. Например, я перешёл на Grafana, потом показал её одному коллеге, второму, третьему, и она разлетелась на весь отдел, хотя до этого был только Zabbix. Правда, таким способом редко получается внедрить инструмент во всей компании. Я бы сразу шёл к руководителю, — Максим Гусев.

Владимир Федорков считает, что поговорить с менеджером — самый эффективный, но не самый лёгкий путь.

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

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

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

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

— Site Reliability Engineering — не должность. Это подход и образ мышления, поэтому специализация людей в SRE-команде не важна. Главное, чтобы они хорошо разбирались в системе и понимали, как работает продакшн на высоком уровне — на уровне приложения, — Владимир Федорков.

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

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

Site Reliability Engineering — это про надёжность, стабильность и производительность системы. Необязательно использовать аббревиатуру SRE, чтобы применять подход для своего сервиса.

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

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

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

Подробнее: https://slurm.club/3OQOgwJ