Вопросы на собеседовании: SRE-инженер

Site Reliability Engineering применяет методы программной инженерии для поддержания надёжности и масштабируемости сервисов.

• SRE рассматривает операционные проблемы как инженерные задачи, которые часто можно измерить и автоматизировать.
• Его цель состоит в том, чтобы обеспечить нужную пользователям надёжность, не останавливая полезное развитие продукта.
• Работа SRE обычно охватывает цели уровня сервиса, наблюдаемость, автоматизацию, ресурсы и безопасную эксплуатацию.
• Эта дисциплина формирует общую ответственность разработки и эксплуатации за надёжность.

Доступность является одной из составляющих надёжности, а надёжность охватывает все аспекты качества сервиса, которые пользователи ощущают со временем.

• Доступность показывает, может ли сервис успешно обработать запрос, когда это требуется.
• Надёжность также может включать задержку, корректность, долговечность данных и согласованность.
• Сервис может быть доступным, но ненадёжным, если возвращает неверные данные или отвечает слишком медленно.

Автоматизация превращает повторяемую операционную работу в единообразные процессы, которые можно проверять.

• Скрипты на Python или Bash устраняют небольшие ручные действия, которые регулярно повторяются.
• Terraform и Ansible описывают инфраструктуру или конфигурацию как версионируемый код.
• Автоматизированная работа лучше масштабируется, меньше зависит от исполнителя и реже приводит к случайным ошибкам.
• Безопасной автоматизации всё равно нужны тесты, идемпотентность, контроль доступа и способ восстановления.

SLI представляет собой количественный показатель поведения сервиса, важного для его пользователей.

• Распространенные SLI измеряют долю успешных запросов, задержку запросов, пропускную способность или свежесть данных.
• Для SLI нужно точно определить событие, условие успеха, источник данных и способ агрегации.
• Хорошие SLI описывают видимые пользователю результаты, а не только использование внутренних ресурсов.

SLO задаёт целевое значение или диапазон SLI в течение заданного окна измерения.

• Например, SLO может требовать не менее 99,9% успешных запросов в скользящем 30-дневном окне.
• Целевое значение определяет уровень надёжности, который команда намерена обеспечивать.
• Окно задает, какие данные участвуют в оценке.
• SLO помогают принимать решения о работе над надёжностью и допустимом риске релизов.

SLA представляет собой формальное обязательство перед клиентом об уровне сервиса и последствиях его нарушения.

• Оно может обещать минимальную доступность или время ответа за расчетный период.
• Последствия могут включать сервисные кредиты, возврат средств или другие договорные компенсации.
• SLA обычно устанавливают менее строгим, чем внутренний SLO, чтобы у команды оставался запас.

SLI дает измерение, SLO задает его целевое значение, а SLA превращает обещание уровня сервиса в формальное соглашение.

• SLI определяет, что измеряется, например доля успешных запросов.
• SLO может требовать, чтобы эта доля была не ниже 99,9% в течение 30 дней.
• SLA может использовать связанный клиентский порог и определять компенсации при его нарушении.
• Определения должны быть согласованы, чтобы каждая цель опиралась на одинаково понимаемое поведение сервиса.

SLI доступности измеряет долю допустимых взаимодействий с сервисом, которые завершились успешно.

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

SLI задержки измеряет, сколько времени занимает допустимая операция сервиса с точки зрения пользователя.

• Его можно выразить распределением или долей запросов, уложившихся в порог.
• Для разных операций часто нужны отдельные SLI задержки, потому что их ожидаемая длительность различается.
• Неудачные запросы нужно классифицировать единообразно, чтобы быстрые отказы не создавали видимость хорошей задержки.
• Сквозное измерение обычно лучше отражает пользовательский опыт, чем время одного внутреннего компонента.

Показатель пропускной способности измеряет объем полезной работы, которую сервис обрабатывает за единицу времени.

• Примеры включают запросы в секунду, сообщения в минуту или байты в секунду.
• Пропускная способность дает контекст нагрузки для показателей задержки и ошибок.
• Большее значение не всегда лучше, если растет число ошибок или очереди задач.

Показатель ошибок отслеживает явно неудачные операции, а показатель корректности проверяет, действительно ли результаты верны.

• Частоту ошибок обычно рассчитывают как число неудачных допустимых запросов, деленное на число всех допустимых запросов.
• Ответы HTTP 5xx и неудачные задания служат примерами явных ошибок.
• Ответ с HTTP 200 все равно может быть некорректным, если данные отсутствуют, устарели или неверны.
• Поэтому для проверки корректности нужны правила предметной области, например ожидаемые поля, значения или инварианты.

Задержка p99 обозначает значение, за которое укладывается 99% измеренных запросов.

• Если p99 равен 800 мс, то 99% запросов заняли не более 800 мс, а 1% занял больше.
• Процентили показывают медленный хвост распределения, который может быть скрыт средним значением.
• P50 представляет типичный запрос, а p95 и p99 описывают все более медленные части трафика.

Окно измерения задает период событий, по которым определяется выполнение SLO.

• Скользящее окно всегда оценивает последний период, например последние 30 дней.
• Календарное окно сбрасывается на фиксированных границах, например в первый день каждого месяца.
• Короткие окна быстро реагируют, но могут резко меняться при малом числе событий.
• Длинные окна сглаживают краткие изменения, но медленнее показывают устойчивое ухудшение.

Ориентированный на пользователя SLI измеряет, могут ли пользователи выполнить значимое действие в сервисе с приемлемым качеством.

• По возможности его измеряют рядом с точкой взаимодействия с пользователем, например на входе API или в клиенте.
• Он охватывает всю операцию, а не один сервер, контейнер или зависимость.
• Загрузка CPU может объяснить поведение, но напрямую не показывает, добились ли пользователи успеха.

Бюджет ошибок показывает объём ненадёжности, который допускает SLO в течение окна измерения.

• Он равен разнице между идеальной надёжностью и целевым значением SLO.
• SLO 99,9% допускает 0,1% неуспешных событий.
• Оставшийся бюджет показывает, какой риск для надёжности еще приемлем.
• Команды используют его, чтобы балансировать изменения продукта и работу по защите надёжности.

Для расчёта бюджета допустимую долю ненадёжности умножают на число событий или длительность временного окна.

• Для 1 000 000 допустимых запросов и SLO 99,9% бюджет равен 0,1%, или 1 000 неуспешных запросов.
• Для 30-дневного SLO 99,9% по времени допустимая недоступность составляет около 43,2 минуты.
• Расчет должен использовать те же правила допустимости и успеха, что и базовый SLI.

Скорость расходования показывает, насколько быстро сервис тратит бюджет ошибок относительно допустимого темпа.

• Скорость 1 израсходует весь бюджет ровно за полное окно SLO.
• Скорость 2 расходует бюджет вдвое быстрее, чем допускает SLO.
• Скорость расходования связывает текущий уровень ошибок с остатком бюджета и оставшимся временем.
• Несколько окон наблюдения позволяют отличать краткие всплески от устойчивого расходования бюджета.

Цель надёжности 100% обычно непрактична и может стоить больше, чем приносит пользователям дополнительной пользы.

• Сети, оборудование, зависимости и программы могут отказывать, поэтому устранить все сбои нереалистично.
• Приближение к 100% требует все более дорогих мер и может сильно замедлить развитие продукта.
• Пользователи могут не заметить надёжность выше определенного уровня, поскольку их устройства и сети тоже дают сбои.
• Подходящий SLO задает минимальный уровень надёжности, который все еще отвечает потребностям пользователей и бизнеса.

MTTR описывает среднее время восстановления после сбоя, а MTBF описывает среднее время работы между сбоями.

• MTTR нужно определять единообразно, потому что последняя R в разных организациях может означать repair, recovery или restore.
• Меньший MTTR означает, что сервис в среднем восстанавливается быстрее.
• Больший MTBF означает, что сбои в среднем происходят реже.
• Для ремонтируемой системы доступность примерно равна MTBF, деленному на сумму MTBF и MTTR.

RTO ограничивает допустимое время восстановления, а RPO ограничивает допустимую потерю данных, выраженную во времени.

• RTO отвечает на вопрос, как долго сервис может оставаться недоступным после серьезного нарушения.
• RPO отвечает на вопрос, насколько восстановленные данные могут отставать от момента нарушения.
• RTO в один час требует восстановить сервис в течение часа.
• RPO в пять минут допускает потерю не более примерно пяти минут последних данных.