In Prisma we process more than 500k photos per day on the server. I would like to present why SRE practices are needed in a small company, how to implement them without pain, why it pays off, and how we reduced the number of incidents.

1. Почему стартапу
нужны SRE-практики
Алексей Андреев
Prisma Labs
2019

2. Prisma Lensa

3. Почему это важно?

4. Почему это важно?

5. SRE в небольших компаниях
● Не нужно нанимать отдельного специалиста
● Этим может заниматься backend-разработчик
● Использовать managed-решения

6. SRE и разработчики backend
● Команда backend и SRE в prisma - 2 человека
● Backend-разработчику нужно знать SRE
● На внедрение SRE-практик не нужно отнимать много
времени от разработки

7. Как было?
● Self-hosted k8s кластер
● Self-hosted PostgreSQL
● NewRelic интегрирован только в один сервис
● Отсутствие метрик от приложений
● Проверки доступности проводились через pingdom
● Эндпоинты для проверок, которые не проверяют
работоспособность приложения

8. Как было?
С таким набором тулов нельзя определить:
● Когда сервис слушает порт и принимает http-
соединения, но запросы не обрабатывает
● Работоспособность background tasks
● Self-hosted-решения занимают много времени
разработчиков и мешают скейлить нагрузку

9. Трудности troubleshooting
● Сложно понять момент начала проблемы
● Приходится много грепать логи
● Иногда сообщения о проблемах приходили от
пользователей, хотя это можно бы было определить
с помощью мониторинга

10. SRE-практики
● Monitoring

11. Monitoring
● Можно понять, когда что-то сломалось
● Эндпоинты для проверок
● Метрики
● Красивые дашборды
● Трейсинг

12. RED

13. RED (Rate)

14. RED (Errors)

15. RED (Duration)

16. Alerting
● Понятные алерты
● Отсутствие ложных алертов
● Отбрасывание пиковых значений
Пример эндпоинта /stats
requests{“code”=200} 200
requests{“code”=500} 5

17. SRE-практики
● Monitoring
● Error budgets

18. Error budgets
● SLA —service level agreement
● SLI — service level indicator
● SLO — service level objective
● Если SLO = 99,9 — бюджет ошибок 0,1%
● 0,1% за месяц — примерно 40 минут

19. Использование бюджетов ошибок
● Был недоступен cloud storage
● MTTA - 1 час
● MTTR - 1,5 часа
● Бюджет ошибок - 40 минут
● Вышли за бюджет ошибок и переделали систему
хранения

20. SRE-практики
● Monitoring
● Error budgets
● Postmortems

21. Postmortems
● Заводить после каждого инцидента
● Должен содержать всю доступную информацию
● Способы предотвращения повторения инцидента

22. SRE-практики
● Monitoring
● Error budgets
● Postmortems
● SRE Teams (toil elimination)

23. SRE teams (toil elimination)
● Менее 50% времени отводится на рутинные задачи
Например:
● Хранить логи в graylog
● Использовать понятные метрики
● Красивые дашборды

24. Внедрение SRE-практик в Prisma Labs

25. Что нужно было сделать
● Мониторить не только работоспособность http-
соединения
● Мониторить время ответа
● Мониторить количество ошибок
● Мониторить background tasks
● Мониторить все сервисы, а не только избранные
● Создать механизм отката версий

26. Как стало?
● Managed k8s-кластер (DigitalOcean)
● Managed PostgreSQL (DigitalOcean)
● Интеграция NewRelic во все сервисы
● Проверки через datadog и pingdom (с проверкой
времени ответа)
● Эндпоинты для проверок проверяют важные для
приложения вещи (postgresql, gcp storage, redis)

27. Как стало?
● Приложения отдают метрики в prometheus
● Интеграция datadog (APM — application performance
monitoring)
● Логи сыпятся в graylog
● CI/CD pipeline (Jenkins)
● Увеличилась частота релизов
● OpsGenie

28. Troubleshooting сейчас
● Момент начала проблемы можно понять с помощью
APM и алертов
● Логи легко ищутся с помощью Graylog
● Методология RED помогает определить проблему
(увеличение времени ответа, увеличение
количества ошибок, резкое изменение количества
запросов) и вовремя среагировать на неё

29. Финансы (в месяц)
● Managed postgresql = ...
● Managed k8s от DigitalOcean = ...
Datadog XXX$
Prometheus XX$
Graylog XX$
OpsGenie XX$
Pingdom XXX$

30. Это просто!

31. Prometheus vs Datadog
Prometheus:
➕ Дешевле
➕ Удобнее мониторить background tasks
➕ Более гибкое конфигурирование алертов
➕ Находится во внутренней сети
➖ Нужно поддерживать
➖ Нельзя класть трейсы

32. Prometheus vs Datadog
Datadog:
➕ Просто внедрить
➕ Не нужно поддерживать
➕ Можно хранить трейсы
➕ Находится во внешней сети
➖ Дороже

33. Это просто!

34. Это просто!

35. Это просто!

36. Это просто!

37. Финансы (в месяц)
● Managed postgresql = self-hosted postgresql X 1.5
● Managed k8s от DigitalOcean = self-hosted k8s
Datadog 350$
Prometheus 80$
Graylog 80$
OpsGenie 33$
Pingdom 100$

38. 850$
Цена всех тулов и сервисов

39. Что дальше?
● Добавить метрики в хандлеры эндопоинтов и
повесить мониторинг в prometheus
● Настроить мониторинг PostgreSQL
● Добавить span для трейсинга в сервисы для
упрощения troubleshooting

40. Трейсинг

41. Что дальше?
Собираемся вводить:
● SLO from user side
● Capacity planning
Пока думаем:
● Fail sanely
● Progressive rollouts
● Overloads and failure

42. Выводы
SRE-практики необходимы, так как:
● Снижается время даунтайма
● Проще расставлять приоритеты
● Снижается нагрузка на команду
● Небольшой прайс

43. Всем красивых
дашбордов!
github.com/tochk
me@tochk.ru