Site Reliability Engineering
Все объяснения, задачи и лабораторная в одном месте.
Можно сохранить страницу в PDF через печать браузера. Для печати разборы ответов раскрываются автоматически.
1. Надёжность как свойство системы
Объяснение
SLI измеряет свойство сервиса, SLO задаёт целевое значение за окно. Доступность лучше определять через успешные пользовательские операции. SLA — внешнее обязательство и может отличаться от внутреннего SLO.
Задача для самостоятельного решения
SLO 99,9% на 1 000 000 запросов: сколько неуспешных допустимо?
Показать разбор ответа
1000 за это окно при таком определении SLI. Не смешивайте процент запросов с минутами доступности без отдельного определения.
2. SLI, SLO и error budget
Объяснение
Error budget — допустимая доля неуспеха. Burn rate показывает скорость его расходования относительно нормы. Короткое и длинное окна помогают отличать краткий всплеск от устойчивой деградации.
Задача для самостоятельного решения
Если ошибки идут в 10 раз быстрее бюджета, что это означает?
Показать разбор ответа
При сохранении темпа бюджет окна закончится за одну десятую его длительности. Решение о релизах должно учитывать оставшийся запас и причину деградации.
3. Monitoring, alert quality и on-call
Объяснение
Насыщение возникает при приближении нагрузки к пропускной способности. Очередь увеличивает latency до полного отказа. Capacity planning учитывает отказ части мощности и время расширения.
Задача для самостоятельного решения
Достаточна ли загрузка каждого из двух узлов на 70%?
Показать разбор ответа
При потере одного оставшийся должен принять примерно 140% своей мощности. Нужен запас, снижение нагрузки или быстрый масштабируемый резерв.
4. Incident command и postmortem
Объяснение
Incident response распределяет координацию, диагностику и коммуникацию. Первая цель — восстановить сервис. Timeline фиксирует наблюдения отдельно от гипотез; безобвинительный разбор ищет системные причины.
Задача для самостоятельного решения
Нужно ли во время аварии сразу переписывать компонент?
Показать разбор ответа
Обычно безопаснее ограниченное восстановительное действие с проверкой. Глубокое исправление выполняют после стабилизации и сохранения диагностических данных.
5. Capacity planning и load testing
Объяснение
Toil — повторяемая ручная работа, растущая с сервисом и не создающая долгосрочной ценности. Автоматизация должна учитывать исключения и безопасный отказ. Плохой процесс, ускоренный скриптом, остаётся плохим.
Задача для самостоятельного решения
Что автоматизировать в ручной выдаче доступа?
Показать разбор ответа
Проверяемое правило, ограничение срока, аудит и отзыв. Одно ускорение создания аккаунта без проверки права увеличивает риск.
6. Automation, toil и resilience engineering
Объяснение
Надёжность проверяют учениями и контролируемыми отказами. Runbook содержит симптомы, диагностику, действие и проверку восстановления. Сложная процедура, известная одному человеку, — операционный риск.
Задача для самостоятельного решения
Как проверить runbook?
Показать разбор ответа
Дать его другому инженеру в учебном окружении, измерить время и записать недостающие шаги. Успех автора не доказывает воспроизводимость.
Лабораторная работа
Подготовка
Калькулятор или Python; синтетические данные.
Учебный пример
requests = 1_000_000
slo = 0.999
budget = requests * (1-slo)
failures = 600
remaining = budget-failures
print(round(budget),round(remaining))Как работает пример и что ожидать
Бюджет 1000 неуспешных запросов, остаток 400. Это request-based SLI, не количество минут простоя. Из определения нужно исключить или включить классы ошибок по понятному правилу, а не подгонять его после аварии.
Итоговая работа
Задайте SLI/SLO своего сервиса, два окна alert и runbook. Проведите учебную потерю зависимости, измерьте восстановление и создайте timeline. Предложите одно изменение, уменьшающее повторяемую ручную работу.
Проверка результата
1. Опишите исходные данные и условия запуска, чтобы другой человек мог повторить работу.
2. Приложите результат обычного сценария и сравните его с ожидаемым.
3. Проверьте неверный вход, граничный случай и отказ зависимости, если она есть.
4. Объясните выбранное решение и известное ограничение.
5. Сохраните исправления после самопроверки вместе с примером, который раньше не работал.
Как оценить работу
По каждому пункту поставьте 0 (не выполнено), 1 (выполнено с пробелами) или 2 (результат воспроизводим и объяснён). Если обязательный сценарий не работает, вернитесь к нему независимо от общей суммы. Это рубрика самопроверки: сайт не исполняет присланный код и не выдаёт автоматическую оценку проекта.