Как я научился не волноваться и полюбил пейджер

Google SRE: взгляд изнутри.
Владимир Рычев, Google

Митап на тему "DevOps vs SRE", 04-04-2018

Transcript

1. Вступление • Как докладчик попал в SRE и что он там теперь делает • 10 лет SWE, mission control, video processing SRE и вот это всё
2. SRE и DevOps • Что за DevOps и какие проблемы оно решает? • class SRE implements DevOps • общие подробности про как SRE работает в Гугле ◦ ~10% инженеров ◦ типичный размер: 8 или 6+6 ◦ SWE/SE опыт ◦ не больше 50% Ops
3. Чем занимаются SRE? • Разработка и администрирование ◦ Автоматизация всего что можно ◦ Дизайн ревью (история про модели) ◦ Продвинутый мониторинг • Решаем проблемы ◦ Диагностировать проблему ◦ Найти баг ◦ И починить его
4. Чем занимаются SRE? • Сотрудничаем с девелоперами ◦ Предотвращаем наступление на продакшн-грабли на стадии дизайна ◦ Советуем проверенные и надёжные решения ◦ Помогаем с имплементацией • Пишем код ◦ помогающий нашим пользователям ◦ повышающий надёжность наших сервисов ◦ повышающий производительность наших сервисов ◦ облегчающий поддержку наших сервисов
5. Чем занимаются SRE? • Отвечаем за сервисы ◦ Помогаем разработчикам довести их сервис до поддерживабельного состояния ◦ После чего принимаем ответственность за этот сервис на себя • Дежурим ◦ Следим за SLO ◦ Обычно полтора месяца между дежурствами ◦ Обычно только днём ◦ Чиним проблемы, решения которых пока не автоматизированы ◦ Предотвращаем пожары
6. Чем занимаются SRE? • Тем же, что и разработчики ◦ юнит-тесты ◦ ревью ◦ стайлгайды ◦ конфиги -- тоже код ◦ разработка, тесты, запуски ◦ документация • Учимся на ошибках ◦ Постмортемы после каждого существенного инцидента
7. Структура SRE • Общий хедкаунт с командами разработчиков • Поддержка одного или семейства похожих сервисов • Совместная ответственность за сервис • Обе стороны могут решить расширить или прекратить сотрудничество
8. В чём отличие от SWE? • Обычно не про фичи • Обычно не про фронтенд • Обычно больше разнообразия
9. Dev и Ops • Разные цели у Dev и Ops: ◦ Dev: выкатывать новые фичи и запускать продукты ◦ Ops: стабильность, надёжность и постепенность
10. Конфликт неизбежен? Вот и нет :) • SRE не пытается оценивать риски • или предотвращать все инциденты • или навязывать расписание релизов
11. А как тогда? • Бюджет на ошибки • Для этого и нужны SLO
12. SLI, SLO, SLA • Примеры: latency, пропускная способность, процент ошибок • Пример: ◦ SLI: 95% upload latency меньше порогового значения ◦ SLO: SLI выполняется 99% времени ◦ SLA: про контракты и последствия ◦ Нетривиальные подробности про определение ◦ Почему не 100% (дорого, часто невозможно, часто бессмысленно)
13. Примеры SLO Доступность % Downtime в год Downtime в месяц Downtime в неделю Downtime в день 90% (одна 9) 36.5 дней 72 часа 16.8 часов 2.4 часа 99% (две 9) 3.65 дней 7.20 часов 1.68 часов 14.4 минут 99.9% (три 9) 8.76 часов 43.8 минут 10.1 минут 1.44 минут 99.99% (четыре 9) 52.56 минут 4.38 минут 1.01 минут 8.66 секунд 99.999% (пять 9) 5.26 минут 25.9 секунд 6.05 секунд 864.3 миллисекунд
14. Бюджет ошибок • Определяется SLO • Пример ◦ SLO: 99.9% ◦ Бюджет: 100% - 99.9% = 0.1% ◦ Можно тратить с чистой совестью ◦ Сервис с миллиардом запросов в месяц ▪ может "потратить" миллион ошибок в месяц
15. На что тратить бюджет • Основной источник инцидентов -- изменения • Например, запуски • Давайте тратить бюджет ошибок на запуски ◦ ...или на нестабильность сервиса
16. Правило • Есть бюджет -- запускайте на здоровье. ◦ разработчики молодцы • Нет бюджета -- никаких запусков ◦ пока SLO не наладятся
17. Чем хороши бюджеты ошибок 1. Никаких SRE-Dev конфликтов a. вопрос бюджета -- математический, а не субъективно-спорный. 2. Разработчики сами решают, на что тратить
18. Трудовые будни • Плохо работающую систему обычно можно держать на плаву достаточными коллективными усилиями • Но удовольствия в этом мало ◦ Поэтому SRE так не делают
19. Но что если очень хочется? • Разработчики хотят делать и запускать фичи • Ops-часть им не видна • Хочется пилить фичи, а не мониторинг • Известно шесть решений, и мы используем их все:
20. 1. Общий хедкаунт • Плюс один SRE => минус один SWE • Чем больше приходится делать Ops-работы... ◦ ...тем меньше ресурсов остаётся на фичи • Очевидная обратная связь
21. 2. SRE -- те же инженеры • Говорят на том же языке • Той же квалификации, что SWE • Не нанимались делать скучную работу
22. 3: Не больше 50% Ops-работы • Больше трафика -- больше работы • Кодинг уменьшает пропорцию работа/трафик • Оставляйте SRE время на серьёзные проекты
23. 4: Разработчики и продакшн • “С глаз долой -- из сердца вон” • Разработчики должны представлять, как ведёт себя их сервис • Бессонные ночи помогают приоритизировать баги • В разных обстоятельствах бывают разные варианты сотрудничества
24. 5: И снова про Dev и Ops • Излишки Ops-работы (баги, тикеты, ручной труд) перенаправляются разработчикам • ещё одна саморегулирующаяся система
25. 6: Добби свободен • Никто не заставляет людей работать над конкретным проектом ◦ ...да и вообще в SRE • Хороший проект приятно поддерживать ◦ ...а от плохого вам отдадут пейджер обратно • Происходит редко, но мотивирует
26. Несчастные случаи на стройке • SLO < 100% означает, что инциденты всегда будут ◦ Это нормально. Не особо приятно, но нормально. • Две цели при каждом инциденте: ◦ Минимизировать ущерб ◦ Предотвратить повторение
27. Минимизация ущерба • Нейтрализовать инцидент как можно скорее ◦ быстрое обнаружение и реагирование ◦ всё что нужно для отладки и диагностирования ◦ много тренировки
28. Кстати о тренировках • wheel of misfortune • DiRT • keeptalkinggame
29. Чтобы не повторялось 1. потушить пожар 2. написать постмортем
30. Постмортемы • Не про поиск виноватого • Все участники разумны и благонамеренны • Вопрос про процессы и инструменты • Создать таймлайн • Собрать все факты • Зафайлить баги
31. Итого • Нанимать инженеров и давать им свободу действий • Определить SLO и измерять, насколько они выполняются • Бюджет ошибок как критерий запусков • Общий хедкаунт • 5% Ops-работы достаётся девелоперам • Не больше 50% Ops-работы для SRE (обычно ~30%) • Дежурства: 8 человек, 1-2 инцидента за смену • Тренировки • Конструктивные постмортемы
32. Книжка O'Reilly • Site Reliability Engineering • How Google Runs Production Systems • Вышла в марте 2016 года • https://landing.google.com/sre/book.html • Русский перевод: июнь 2018
33. И другие ссылки • https://www.google.com/sre ◦ множество текстов и видео • https://www.youtube.com/googlecloudplatform ◦ плейлист class SRE implements DevOps • докладчик @rychev / v@rychev.com
34. Вопросы?