Понятие SRE прочно закрепилось в современном ИТ. В свое время подход Site Reliability Engineering произвел революцию в отношении организаций к надежности и производительности систем. Зародившись в Google, SRE позволяет преодолеть разрыв между разработкой и эксплуатацией, обеспечивая надежную, масштабируемую инфраструктуру, которая соответствует ожиданиям пользователей. По сути, SRE — это не просто поддержание систем в рабочем состоянии, это создание интеллектуальной, самовосстанавливающейся инфраструктуры, которая сводит к минимуму ручное вмешательство. Внедряя стратегические практики SRE, организации могут превратить свои технические операции из реактивного устранения неполадок в проактивную оптимизацию.
SRE и DevOps
Здесь сразу хотелось бы сравнить SRE и DevOps, так как эти оба подхода имеют много общего и может возникнуть непонимание отличий одного подхода от другого. Подход DevOps больше нацелен на быструю разработку и доставку программного обеспечения, взаимное сотрудничество между командами и повышение качества выпускаемого продукта в целом.
В свою очередь, SRE больше фокусируется на обеспечении надёжности и доступности сервисов, минимизации простоев и оптимизации операционных процессов. SRE уделяет особое внимание количественной оценке надёжности, использованию инженерных подходов для решения операционных задач сопровождения и внедрению практик, которые обеспечивают устойчивость систем.
Что касается инструментария, то DevOps использует различные инструменты для автоматизации процессов, мониторинга и управления конфигурациями, например Jenkins, Terraform, Ansible, Docker и Kubernetes. SRE также использует инструменты для мониторинга и автоматизации, но особое внимание уделяет практикам, связанным с надёжностью, таким как бюджеты на сбои, ошибки и их анализ.
Подводя итог теме отличий DevOps от SRE стоит отметить, что эти подходы не противостоят друг другу — они дополняют и усиливают IT‑процессы. Подход DevOps задаёт скорость и гибкость, а SRE добавляет контроль над надёжностью.
Теперь давайте перейдем непосредственно к теме тех сложностей, с которыми можно столкнуться при переходе к SRE.
Пять культурных изменений
Переход к SRE задача непростая и на пути вы можете столкнуться с множеством сложностей. Для того чтобы выполнить успешный переход к SRE, ваша организация должна принять эти пять культурных изменений:
Очень важна заинтересованность в изменениях. Это должна быть работа всей команды.
Надежность должна быть главным приоритетом при работе
Смиритесь с тем, что будут сбои. 100-процентная надежность не является целью
Неудача — это возможность учиться и расти как организация
Культура отсутствия вины позволяет каждому быть более эффективным в своей роли
Хотя смысл этих аспектов может показаться очевидным, давайте рассмотрим каждое изменение немного подробнее.
Заинтересованность в изменениях
Изменение культуры SRE носит многоуровневый характер, начиная с инженеров и заканчивая владельцами продуктов и руководителями. Между этими сторонами должно быть согласовано определение надежности и того, что произойдет, если согласованные стандарты не будут соблюдены. Это начало изменения культуры SRE. Все должны согласиться с тем, что это тот путь, по которому вы хотите идти, и ожидать, что результат улучшит ваш продукт.
Здесь по аналогии с DevOps не должно быть изоляции одних подразделений от других. Понятие надежности должно быть согласовано со всеми командами. Не должно быть такого, что для разработчиков надежность это 80%, а для поддерживающих подразделений 99%.
Надежность vs. Функционал
Методология SRE ставит надежность на первое место. Наличие крутых функций может привлечь клиентов, но если надежность слишком низкая, то никакие звонки и свистки не удержат клиентов от поиска альтернативы. Если существует альтернатива вашему продукту, которая работает в большем проценте случаев, люди, которых привлекают ваши «колокольчики и свистки», поймут, что им лучше использовать более простой, но надежный вариант, чем тот, который делает больше, чем им нужно, но не всегда доступен.
Так что пришло время приложить усилия и выделить дополнительные этапы при разработке вашего программного продукта для повышения его надежности. Например, дополнить этап тестирования дополнительными тестами надежности. Да, это больше относится к разработке и DevOps, но SRE необходимо уметь договариваться. Ну и естественно на этапе Operations & Maintenance необходимо настроить инструменты для обеспечения большей надежности.
Возможно, это означает отложить новые функции на второй план или работать над ними одновременно, если у вас есть ресурсы, то не откладывайте повышение надежности, чтобы добавить функцию, которая есть (или которой нет) у всех остальных. Возможно, работа над добавлением новой захватывающей функции принесет больше удовольствия, но убедитесь, что ваш продукт будет готов к тому моменту, когда он понадобится вашему клиенту.
Shit happens: Сбои будут случаться
При определении надежности необходимо понимать, что 100-процентная безотказность невозможна и требует больших затрат. Для повышения надежности по мере приближения к 100% требуется все больше времени и усилий, что отнимает больше времени от разработки функций. Это означает, что нужно принять отказ как норму. В какой‑то момент клиенты не заметят постепенного повышения надежности и не оценят отдачу, если она будет достигнута за счет скорости разработки новых функций. Удовлетворенность пользователей — лучший индикатор того, где нужно установить цель по надежности.
Как только вы определились с целью надежности, вы можете использовать ее для определения бюджета ошибок. Бюджет ошибок — это объективная метрика того, насколько ненадежным может быть ваш сервис. Это позволит вам узнать, насколько вы близки к достижению своей цели по надежности в любой момент времени. Это также подтверждает, что сбои в работе вашего сервиса будут происходить, и вы это предусмотрели.
Напомним, что бюджет ошибок — это понятие, которое определяет допустимое количество сбоев или ошибок, которые допустимы для системы в течение определенного периода времени, прежде чем это повлияет на удовлетворенность пользователей или нарушит целевой уровень надежности (SLO). По сути, это количественная оценка «риска», на который команда готова пойти в отношении надежности сервиса, чтобы обеспечить возможность внедрения инноваций и разработки новых функций.
Неудача — это возможность научиться
Обучение лежит в основе SRE. Поскольку неудачи неизбежны, не просто устраняйте проблему, а используйте ее как шанс для обучения. Когда что‑то выводит ваш сервис из строя, это может быть непредвиденное событие или что‑то, о чем вы знали, но считали маловероятным. В первом случае вы узнаете о неизвестных слабых местах в вашем сервисе и сможете найти способы предотвратить повторение. Во втором случае вы, скорее всего, обнаружите, что это не такое уж редкое явление, как вы предполагали. В обоих случаях вы узнаете больше о своем сервисе и о том, как повысить его надежность. Культура обучения — это культура совершенствования.
Лучше всего этого можно добиться, используя формализованный подход. В SRE используется практика разборов, проводимых после инцидента. Во время разбора важно сосредоточиться на изучении причин инцидента и на том, как предотвратить его в будущем. То есть это не поиск виновных. Это лишь отвлекает от цели встречи и может помешать открытости участников. SRE предлагает сосредоточиться на более важных областях, чем поиск виноватого — причинах и предотвращении.
Культура отсутствия вины способствует открытому общению
Культура отсутствия вины (blameless culture) обеспечивают психологическую безопасность для каждого, позволяя раскрыть информацию, которую ему, возможно, не очень удобно раскрывать, если он чувствует, что это повлияет на его карьеру. Если предполагается человеческая ошибка, поиск системной причины может не проводиться. Даже если причиной является человеческая ошибка, разбор может устранить недостаток информации, которая могла бы предотвратить инцидент.
Когда никто не боится, что его обвинят, и никто не ищет, на кого бы свалить вину, все могут работать над выяснением причины инцидента и пытаться узнать, как предотвратить его в будущем. Мотивация скрывать информацию в целях самозащиты будет не так сильна.
Здесь понятна ирония многих читателей, привыкших, что в случае сбоев руководству всегда нужен конкретный виновный, однако подход SRE предлагает иной взгляд на проблему.
Простой пример: в случае падения продуктива плохой практикой будет поиск ответа на вопрос: «Кто сломал прод?». Вместо этого практики SRE рекомендуют ответить на вопрос «Почему система позволила человеку сломать прод?»
Внедрение этих культурных изменений значительно повысит вероятность успеха любого перехода на технологию SRE
Заключение
Надежность проекта — это поддержка его функционирования на всех этапах разработки, а не только на этапе выполнения кода. Ответственность за надежность смещается влево и охватывает всех участников процесса. Как уже говорилось, это и инженеры, и владельцы проектов, и руководители. Когда это происходит, можно добиться согласованности в понимании ценности надежности, прокладывая путь к конечной цели — удовлетворению потребностей заказчика. С помощью подхода SRE можно существенно увеличить надежность и стабильность работы решения в целом.
В заключение рекомендую два открытых урока, которые проведут мои коллеги в Otus:
DevOps и SRE: конкуренты или союзники в борьбе за надёжность? — 3 июля в 20:00
Мониторинг распределенных систем — 14 июля в 20:00
Узнайте, как внедрять передовые практики для повышения надежности сервисов, оптимизации процессов и балансировки между функциональностью и доступностью. На уроках вы также получите полезные инструменты для автоматизации и улучшения устойчивости систем.
Кроме того, предлагаю пройти бесплатный тест для оценки знаний в области SRE и DevOps. Пройдите тестирование и получите доступ ко всем записям открытых уроков!