SRE объединяет группы разработчиков программного обеспечения и эксплуатации, которые помогают создавать надежные, отказоустойчивые и масштабируемые системы. Некоторые из преимуществ этой методологии:
Улучшаются коммуникации в команде
Совершенствуется культура
Уменьшается доля ручного труда
Клиенты чаще остаются довольны
Что такое SRE?
Подход Site Reliability Engineering (SRE) разработали в Google в 2003 году. Он стал популярен в 2017 году, когда вышла книга «Site Reliability Engineering». Этот набор практик, инструментов и культурных принципов, направленных на повышение надежности ваших услуг. «Надежность» здесь определяется как субъективная метрика, которая отражает не только доступность услуг, но и то, насколько они важны для пользователей. Таким образом, SRE объединяет усилия команды разработки и эксплуатации для повышения удовлетворенности клиентов.
Основные практики SRE включают:
Принятие рисков
Постановка цели по уровню обслуживания
Избавление от тяжелого труда
Мониторинг
Разработка релиза
Автоматизация
Простота
У SRE как культуры есть свои ценности:
Принимать неудачи как нормальное явления и принимать безупречный подход
Нужно создавать сильные команды и отношения
Нужно нанимать командных игроков и постоянно их обучать
Совместно командно владеть продуктом
Балансировать между отказоустойчивостью и с принятием риска
Надежность сервисов становится очень важной, поэтому компании всех размеров используют SRE, чтобы дать клиенту надежный сервис. Мы объясним, почему SRE — лучший способ повысить удовлетворенность клиентов и сплоченность команды.
Цели SRE
Предугадывать инциденты
Вы никогда не сможете полностью предотвратить возникновение новых инцидентов, но вы можете смягчить их последствия, если как следует подготовитесь. SRE предоставляет инструменты для отслеживания закономерностей и позволяет прогнозировать наиболее важные или распространенные из них. Вы можете подготовить сборники сценариев и провести обучение специалистов, чтобы минимизировать последствия таких инцидентов.
SRE также помогает понять истинное влияние инцидентов. Такие инструменты, как SLI и SLO, учитывают клиентский опыт и показывают, как инциденты влияют на типичное использование сервиса. Это позволяет согласовывать и расставлять приоритеты в зависимости от удовлетворенности клиентов.
Анализировать и улучшать свой процесс DevOps
Когда вы отслеживаете, как команда реагировала на инциденты, вы выявляете сложности и узкие места. Потребовалось много времени, чтобы сообщить о некоторых типах инцидентов? Инструменты диагностики не дают полезных результатов? Долго принимаются решения при попытке развертывания в рабочей среде? SRE высвечивает такие проблемы.
Учиться на каждом инциденте с помощью ретроспективы инцидентов
Помимо статистики и шаблонов, которые вы можете собрать по инцидентам, SRE также позволяет изучить факторы каждого инцидента. Ретроспективы инцидентов — это документы, которые вы создаете для каждого инцидента и в которых рассказывается о том, как он был обнаружен, диагностирован и решен. Эти документы могут служить источником важной информации для решения будущих инцидентов и для диагностики.
Делайте клиентов счастливыми!
Конечная цель SRE и вашей организации в целом — довольные клиенты. Но сложно расставлять приоритеты исходя из удовлетворенности клиентов. Как узнать, когда нужно жать на газ и предоставить желаемые функции как можно скорее, а когда нужно замедлить разработку и убедиться, что ваш сервис надежно обеспечивает то, что ожидают клиенты? Ответ на этот вопрос лежит в основе SRE. Error-бюджет — это инструмент, который может привести вас к идеальному балансу скорости и надежности. Стремление SRE к эффективному управлению инцидентами сводит к минимуму влияние неизбежных инцидентов на удовлетворенность клиентов.
Преимущества SRE
Объединение команд на основе понимания пользовательского опыта
SRE выступает за использование индикаторов и целей уровня обслуживания (SLI и SLO) для измерения работоспособности сервисов. Это не просто показатели доступности, это ещё и путь пользователя. Превратите в метрики то, как клиенты используют ваши услуги и что делает их счастливыми.
Как только вы превратите удовлетворенность пользователей в метрики, вы сможете использовать их для понимания реального влияния решений и инцидентов. Чем лучше вы поймете ваших пользователей, тем больше вы сможете расставить приоритетов. SRE выступает за динамические и итеративные выпуски. Вместо нечастых больших выпусков команды SRE выпускают небольшие обновления в ответ на потребности пользователей.
Вашим командам будет легче работать, если у них есть согласованность по поводу удовлетворенности пользователей. Конечно, иногда трудно понять, когда следует отдавать приоритет увеличению скорости разработки, а когда — повышению надежности вашего сервиса. SRE помогает командам прийти к единому мнению, уменьшить разрозненность и разногласия, а также делиться знаниями, ставя во главу угла удовлетворение пользователей.
Минимизировать боли пользователей и дежурных за счет лучшего реагирования на инциденты
Один из ключевых уроков SRE заключается в том, что неудачи неизбежны. Вы можете смягчить последствия инцидентов и уменьшить их частоту, но никогда не можете рассчитывать на их полное устранение. Поэтому нужно улучшать реагирование на инциденты. Это важный компонент SRE.
SRE использует преимущества инструментов и автоматизации, чтобы упростить реагирование на инциденты. Имея набор документированных инцидентов вы можете отсортировать их, например, по тому как они повлияли на удовлетворенность пользователей. Затем вы можете связать автоматизированные модули Runbook для работы с общими решениями без ручного вмешательства. Это позволяет инженерам сосредоточиться на более творческом решении проблем. Ретроспективы инцидента гарантируют, что вы узнали все, что могли.
Улучшение реагирования на инциденты приносит пользу вашим клиентам за счет сокращения времени простоя служб, на которые они полагаются. Когда что-то критичное для них выйдет из строя, вы сможете уделить этому должное внимание. Эти улучшения также принесут пользу вашим командам. Если сократить ручной труд по реагированию на инциденты, дежурные инженеры будут меньше подвержены стрессу и выгоранию.
Расширять возможности команд благодаря культурным и практическим изменениям
Внедрение SLO и инструментов реагирования на инциденты дает большие преимущества вашим командам и пользователям, но самые важные преимущества SRE проявляются благодаря культурным изменениям. Все, за что выступает SRE, основано на культуре. Поэтому, если вы сможете привить эти культурные ценности, лучшие практики SRE будут развиваться естественным образом.
В основе культурного сдвига SRE лежит идея безупречности. Когда что-то идет не так, вместо того, чтобы пытаться найти виноватого, используйте это как шанс внести системные изменения для улучшения системы. Например, если кто-то случайно отправил код в производство до его проверки, что вызвало ошибку, не вините этого человека. Вместо этого задавайте такие вопросы:
Какие ручные проверки можно использовать, чтобы предотвратить это?
Может ли процесс развертывания требовал наличия индикатора проверки кода?
Какой коммуникации или образования не хватило, чтобы инженер поверил, что код можно протолкнуть?
Так вы обнаружите, как можно повысить надежность вашей системы. Вашей команде понравится возможность делать значимую работу, а не быть виноватыми. Безукоризненность дает инженерам психологически безопасное пространство и возможность экспериментировать, что ведет к улучшению работы. Ваши пользователи также выиграют от этой культурной эволюции. Трата времени на обвинения и наказания ничего для них не дает, а системные изменения означают для них более надежные услуги.
Внедрение SRE
Теперь, когда мы обсудили некоторые преимущества SRE, давайте рассмотрим, как лучше всего интегрировать эту практику в вашу организацию. SRE может вписаться в модель любой организации. Это не требует крупных вложений сразу — вам не нужно сразу же нанимать специальную команду SRE.
Вместо этого вы можете создавать свою практику SRE по частям в зависимости от ваших потребностей. Если вам сложно быстро реагировать на инциденты, начните создавать модули Runbook. Если ваши команды расходятся во мнениях по поводу приоритетов, согласуйте их с SLO. Культурные изменения всегда принесут пользу организациям без каких-либо крупных инвестиций. Принятие точки зрения SRE в том, что вы делаете, постепенно окажется полезным, что приведет к дальнейшему принятию.
По мере развития вашей практики SRE вы можете больше инвестировать в найм и инструменты, чтобы вывести свою практику на новый уровень.
SRE против DevOps
SRE и DevOps имеют много общих целей. Они в основном различаются тем, как они рекомендуют их достигать. Однако это не делает их несовместимыми. SRE можно рассматривать как метод реализации принципов DevOps. Если вы внедрили DevOps, у вас есть все шансы добраться до SRE. Каждая добавленная вами практика SRE будет поддерживаться структурами DevOps, которые вы уже создали.
Начинать с SRE может быть пугающе, но преимущества того стоят. Если вы хотите научиться этим практикам приходите в Слёрм на курс «SRE: data-driven подход к управлению надежностью систем».
Вы получите практические знания, на которые наши эксперты потратили годы. Можете посчитать, сколько времени потребуется специалисту, чтобы изучить технологии, например, Canary Deploy, провести первые эксперименты и внедрить их с учетом стоимости часа его работы. У нас инженер потрогает это решение руками, получит пример готового кода и сможет внедрить его в продакшене.
Для команд от 5 человек у нас действуют особые условия участия - 65 000 ₽ за 1 сотрудника, вместо 90 000 Р.
Ознакомиться с программой и записаться на курс можно на нашем сайте.