Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-03-10

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

2 <h2>Принятие рисков</h2>

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

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

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

5 <h2>Закрепление уровня обслуживания</h2>

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

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

8 <h2>Мониторинг</h2>

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

10 <h2>Отказ от рутины и автоматизация</h2>

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

12 <h2>Релиз-инжиниринг</h2>

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

14 <p>Хотите знать больше? Вот вам<a>первоисточники</a>от Google.</p>

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