В статье разбираемся, зачем компании 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-инженеров. Обучение проходит в группах. Можно отправиться на тренинг одному или с командой. Несколько слов о курсе Курс на 80% состоит из практических кейсов, с которыми SRE-инженеры встречаются в реальности. Участники поймут основы SRE и пощупают руками систему. После обучения полученные навыки и знания можно адаптировать и внедрить в любую сферу.Узнать подробнее.