Основные принципы SRE

Концепция SRE включает в себя довольно много конкретных практик. Но в их основе все равно лежат базовые принципы. О них и поговорим.

Принятие рисков

Если рассуждать с точки зрения бытовой логики, то корпорации типа Google должны стремиться к созданию сервисов со 100%-ной надежностью. Однако на самом деле в компании Google уверены, что такое стремление -- это в большей степени вред, чем польза. Почему? Потому что оно недостижимо на практике и, по сути, серьезно ограничивает число новых возможностей, а также скорость, с которой эти возможности реализуются. Ну и, понятное дело, при таком положении дел кратно увеличивается цена сервисов для конечных пользователей.

"Надейся на лучшее, однако готовься к худшему" -- говорят в Google. С этим сложно спорить, ведь предусмотреть все невозможно, как невозможно все взять под контроль. От случайностей мы не застрахованы: люди периодически ошибаются, а экскаваторы повреждают кабели. Но надежда стратегией не является, а вот учет рисков и готовность к неблагоприятному развитию обстоятельств -- это уже гораздо лучше.

Закрепление уровня обслуживания

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

И вот тут-то на сцену выходит SLO — внутренний документ, причем метрики, в нем отмеченные, должны быть максимально близки к пользователю, не говоря уже о том, что они должны быть максимально конкретны. На практике команда применяет SLO для оценки своей работы и приоритизации задач. Как раз таки на основании SLO и определяют Error budget -- бюджет на ошибки.

Мониторинг

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

Отказ от рутины и автоматизация

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

Релиз-инжиниринг

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

Хотите знать больше? Вот вам первоисточники от Google.

По материалам https://rb.ru/opinion/SRE-for-what/.