В статье разбираемся, зачем компании Site Reliability Engineering (SRE) и когда его применять. Также здесь расписаны шаги, которые помогут обычному инженеру или разработчику внедрить SRE в своей компании.
Материал подготовлен по вебинару «SRE как профессиональный рост для специалиста и прорыв для компании».
Зачем компании SRE и когда внедрять этот подход
Site Reliability Engineering (SRE) — не о том, чтобы сделать по-особенному. SRE — это про понимание своей системы:
чтобы успешно её контролировать;
обеспечить необходимый уровень доступности;
внедрять те инженерные практики, которые уменьшают число инцидентов;
если инциденты случаются, вытаскивать из них максимум знаний о системе;
отслеживать пользовательский опыт, который конвертируется в бизнес-прибыль.
Практики SRE применяют не из-за хайпа или крутости, а чтобы получить реальную пользу. Этот подход помогает бизнесу сохранить деньги и экономит время и силы инженеров, которые обслуживают приложение. В компаниях с SRE специалисты поддержки могут спать спокойно — они знают, что им не придётся среди ночи экстренно поднимать продакшн.
Внедрять SRE-практики стоит тогда, когда компания выкатывает сервис в прод и у него появляются пользователи. Люди привыкли к качественным приложениям. Они не любят, когда сервис часто падает и лежит часами. Если такое происходит, клиенты выбирают конкурентов и бизнес теряет деньги.
SRE-подход позволяет быстрее реагировать на проблемы системы, из-за которых уходят пользователи; предотвращать большинство из них; а также использовать фидбек для улучшения сервиса и User Experience.
Что делать компании, чтобы перейти на SRE? Разберём три шага, которые помогут внедрить подход у себя.
Переход на SRE. Шаг №1: понять, а нужен ли вам Site Reliability Engineering
Первый вопрос, который следует себе задать, прежде чем внедрять SRE: «Соответствует ли уровень доступности сервиса бизнес-целям?» Для ответа на этот вопрос стоит внутри своей команды или компании определить показатели доступности (SLI) с конкретными числовыми показателями (SLO). Затем соотнести ожидания и реальность.
Подробнее метрики SRE описаны в статье «Цель SRE — надёжная система».
Если ответ на вопрос «да, соответствует», то в целом всё хорошо и, наверное, делать ничего не стоит.
— Бывает, приходит компания и говорит: «Мы хотим SRE». Начинаешь смотреть и понимаешь, что там некоторые практики уже внедрены, просто об этом не знают. У них всё хорошо: великолепные девяточки доступности, прекрасные отзывы пользователей, даунтайм 15 минут в неделю и так далее. В этом случае на вопрос: «Что мы можем улучшить?» я отвечаю: «Зачем? У вас всё отлично. Дальнейшие улучшения не дадут ощутимого эффекта, а обойдутся дорого». Правда, такое бывает редко. Зачастую приходят компании в ужасном состоянии. Приходится неделями разбираться, чтобы понять, как им помочь минимальными затратами, — Максим Гусев, Tech Lead SRE, спикер Слёрма.
Переход на SRE. Шаг №2: выбрать инструменты
Если система не соответствует желаемому уровню доступности, стоит задать себе следующий вопрос: «Какие процессы из Site Reliability Engineering мы можем реализовать здесь и сейчас с максимальным эффектом?»
— Некоторые думают, что SRE — это что-то странное. Необязательно использовать эту аббревиатуру. Можно просто брать конкретные практики, и шаг за шагом внедрять их. Только нужно знать, что и в какой последовательности применять. Для этого сначала надо понять, что проще и быстрее всего сделать именно для вашей системы, — Владимир Федорков, спикер конференций и Слёрма, более 15 лет специализируется на высоких нагрузках.
Вопрос «быстрой эффективности» очень важен, потому что в SRE много основных инструментов. Некоторые из них следует внедрить в первую очередь, например, мониторинг и инцидент-менеджмент. Они залог и реактивной, и проактивной работы. Без мониторинга и инцидент-менеджмента нет понимания, что происходит в системе.
Чтобы выбрать из всего многообразия остальных практик, нужно оценивать влияние каждой на систему и внедрять самые результативные. Например, один из основных инструментов SRE — это Kubernetes. Нужно ли в таком случае немедленно разворачивать кластер K8s? Если мы понимаем, что в текущей ситуации пользы от этого будет ноль, то лучше разобраться с другими вещами, а не бежать внедрять Kubernetes.
Нет универсального чек-листа, по которому можно проверить надёжность любого сервиса. Такой чек-лист варьируется от компании к компании. Есть девять часто встречающихся ошибок, исправив которые можно повысить отказоустойчивость своей системы. Владимир Федорков рассказывал о них в докладе «Как готовиться к подъёму нагрузки в условиях 2022» на Highload++ 2022.
Переход на SRE. Шаг №3: выбрать стратегию внедрения
Шаг №3 можно пропустить, если инициатива внедрения SRE исходит от менеджмента. В этом случае переход будет максимально быстрым и безболезненным.
Но что делать, если перевести свою компанию на SRE хочет рядовой инженер или разработчик, которому больно, что сервис постоянно падает, а он узнаёт об этом от техподдержки?
Есть два варианта.
Первый вариант — пойти к руководству и объяснить, что изменится, если внедрить конкретные инструменты или практики. Например, мы предлагаем использовать APM из разряда Sentry, Jaeger и т. д. Зачем это бизнесу? Это поможет собирать ошибки со стороны клиентов и улучшать сервис. Чем выше качество приложения, тем больше денег оно приносит.
Стоит подкрепить своё предложение фактами и цифрами из мира бизнеса — это увеличит шансы на то, что менеджмент поддержит идею. К примеру, можно посчитать профит от исправления ошибок и сказать руководителю, что устранение багов увеличит прибыль, допустим, на 30% в квартал.
Второй вариант — внедрение практики «с низов». Это когда два-три человека начинают использовать инструмент, и постепенно на него переходит вся компания.
— У меня такое происходило несколько раз. Например, я перешёл на Grafana, потом показал её одному коллеге, второму, третьему, и она разлетелась на весь отдел, хотя до этого был только Zabbix. Правда, таким способом редко получается внедрить инструмент во всей компании. Я бы сразу шёл к руководителю, — Максим Гусев.
Владимир Федорков считает, что поговорить с менеджером — самый эффективный, но не самый лёгкий путь.
— Проще начать самому использовать инструмент, «заразить» им коллег и после этого идти к руководителю. Сказать, что вы попробовали такую штуку, и она действительно упрощает работу, уменьшает количество отказов, увеличивает общую стабильность системы. А общая стабильность системы — это деньги, — Владимир Федорков.
Ещё можно предложить руководителю потестить практику на одной команде и посмотреть результаты. В этом случае лучше начинать внедрение с самой стабильной и спокойной команды. Желательно, чтобы у неё была минимальная загруженность бизнес-задачами, иначе можно не вклиниться в её рабочий график.
Бывают начальники, которые доверяют хайпу и внешней экспертизе, а не мнению своих сотрудников. Таких руководителей можно попробовать убедить, показав им доклад с известной конференции, где рассказывают о нужном инструменте.
Команда SRE-инженеров
Из кого составлять команду SRE-инженеров? Должны ли в неё входить девопсы, разработчики, админы, тестировщики? Приведём мнения наших экспертов.
— Site Reliability Engineering — не должность. Это подход и образ мышления, поэтому специализация людей в SRE-команде не важна. Главное, чтобы они хорошо разбирались в системе и понимали, как работает продакшн на высоком уровне — на уровне приложения, — Владимир Федорков.
— Я чаще сталкивался с ситуацией, когда в компании внедряют SRE-практики, и на основе этого сначала формируется методология, а потом — команда. Как правило, она состоит из сотрудников, которые поддерживают подход и им интересно развиваться в этом направлении. Они становятся SRE-инженерами и глубже погружаются в методологию.
Представим, что хочется наоборот — сначала собрать команду SRE-инженеров, а потом применять методологию. Я бы создавал такую команду с сотрудника, который наиболее чётко понимает, как работает продукт, что нужно для стабильности системы и в чём сейчас проблема. Такой человек станет лидером SRE-подхода в компании и будет развивать его, — Максим Гусев.
Резюме
Site Reliability Engineering — это про надёжность, стабильность и производительность системы. Необязательно использовать аббревиатуру SRE, чтобы применять подход для своего сервиса.
Прежде чем внедрять SRE, сначала следует определить желаемый уровень отказоустойчивости системы, потом сравнить ожидания и реальность и после этого принимать решение.
Начинать стоит с тех практик SRE, реализация которых займёт меньше всего времени, но принесёт максимальный эффект.
Можно сначала внедрить SRE, а потом сформировать под эти задачи команду. Или сделать наоборот. По какому бы пути ни пошла ваша компания, вам будет полезен наш курс по SRE. На нём участники примерят роль SRE-инженеров. Обучение проходит в группах. Можно отправиться на тренинг одному или с командой.
Несколько слов о курсе
Курс на 80% состоит из практических кейсов, с которыми SRE-инженеры встречаются в реальности. Участники поймут основы SRE и пощупают руками систему. После обучения полученные навыки и знания можно адаптировать и внедрить в любую сферу.
Узнать подробнее.
