Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Xp days 2019 - Why startups need SRE practices

•
•
A
Alexey Andreev

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 of 43
Download to read offline
Почему стартапу нужны SRE-практики Алексей Андреев Prisma Labs 2019
Prisma Lensa
Почему это важно?
Почему это важно?
SRE в небольших компаниях ● Не нужно нанимать отдельного специалиста ● Этим может заниматься backend-разработчик ● Использовать managed-решения
SRE и разработчики backend ● Команда backend и SRE в prisma - 2 человека ● Backend-разработчику нужно знать SRE ● На внедрение SRE-практик не нужно отнимать много времени от разработки
Как было? ● Self-hosted k8s кластер ● Self-hosted PostgreSQL ● NewRelic интегрирован только в один сервис ● Отсутствие метрик от приложений ● Проверки доступности проводились через pingdom ● Эндпоинты для проверок, которые не проверяют работоспособность приложения
Как было? С таким набором тулов нельзя определить: ● Когда сервис слушает порт и принимает http- соединения, но запросы не обрабатывает ● Работоспособность background tasks ● Self-hosted-решения занимают много времени разработчиков и мешают скейлить нагрузку
Трудности troubleshooting ● Сложно понять момент начала проблемы ● Приходится много грепать логи ● Иногда сообщения о проблемах приходили от пользователей, хотя это можно бы было определить с помощью мониторинга
SRE-практики ● Monitoring
Monitoring ● Можно понять, когда что-то сломалось ● Эндпоинты для проверок ● Метрики ● Красивые дашборды ● Трейсинг
RED
RED (Rate)
RED (Errors)
RED (Duration)
Alerting ● Понятные алерты ● Отсутствие ложных алертов ● Отбрасывание пиковых значений Пример эндпоинта /stats requests{“code”=200} 200 requests{“code”=500} 5
SRE-практики ● Monitoring ● Error budgets
Error budgets ● SLA —service level agreement ● SLI — service level indicator ● SLO — service level objective ● Если SLO = 99,9 — бюджет ошибок 0,1% ● 0,1% за месяц — примерно 40 минут
Использование бюджетов ошибок ● Был недоступен cloud storage ● MTTA - 1 час ● MTTR - 1,5 часа ● Бюджет ошибок - 40 минут ● Вышли за бюджет ошибок и переделали систему хранения
SRE-практики ● Monitoring ● Error budgets ● Postmortems
Postmortems ● Заводить после каждого инцидента ● Должен содержать всю доступную информацию ● Способы предотвращения повторения инцидента
SRE-практики ● Monitoring ● Error budgets ● Postmortems ● SRE Teams (toil elimination)
SRE teams (toil elimination) ● Менее 50% времени отводится на рутинные задачи Например: ● Хранить логи в graylog ● Использовать понятные метрики ● Красивые дашборды
Внедрение SRE-практик в Prisma Labs
Что нужно было сделать ● Мониторить не только работоспособность http- соединения ● Мониторить время ответа ● Мониторить количество ошибок ● Мониторить background tasks ● Мониторить все сервисы, а не только избранные ● Создать механизм отката версий
Как стало? ● Managed k8s-кластер (DigitalOcean) ● Managed PostgreSQL (DigitalOcean) ● Интеграция NewRelic во все сервисы ● Проверки через datadog и pingdom (с проверкой времени ответа) ● Эндпоинты для проверок проверяют важные для приложения вещи (postgresql, gcp storage, redis)
Как стало? ● Приложения отдают метрики в prometheus ● Интеграция datadog (APM — application performance monitoring) ● Логи сыпятся в graylog ● CI/CD pipeline (Jenkins) ● Увеличилась частота релизов ● OpsGenie
Troubleshooting сейчас ● Момент начала проблемы можно понять с помощью APM и алертов ● Логи легко ищутся с помощью Graylog ● Методология RED помогает определить проблему (увеличение времени ответа, увеличение количества ошибок, резкое изменение количества запросов) и вовремя среагировать на неё
Финансы (в месяц) ● Managed postgresql = ... ● Managed k8s от DigitalOcean = ... Datadog XXX$ Prometheus XX$ Graylog XX$ OpsGenie XX$ Pingdom XXX$
Это просто!
Prometheus vs Datadog Prometheus: ➕ Дешевле ➕ Удобнее мониторить background tasks ➕ Более гибкое конфигурирование алертов ➕ Находится во внутренней сети ➖ Нужно поддерживать ➖ Нельзя класть трейсы
Prometheus vs Datadog Datadog: ➕ Просто внедрить ➕ Не нужно поддерживать ➕ Можно хранить трейсы ➕ Находится во внешней сети ➖ Дороже
Это просто!
Это просто!
Это просто!
Это просто!
Финансы (в месяц) ● Managed postgresql = self-hosted postgresql X 1.5 ● Managed k8s от DigitalOcean = self-hosted k8s Datadog 350$ Prometheus 80$ Graylog 80$ OpsGenie 33$ Pingdom 100$
850$ Цена всех тулов и сервисов
Что дальше? ● Добавить метрики в хандлеры эндопоинтов и повесить мониторинг в prometheus ● Настроить мониторинг PostgreSQL ● Добавить span для трейсинга в сервисы для упрощения troubleshooting
Трейсинг
Что дальше? Собираемся вводить: ● SLO from user side ● Capacity planning Пока думаем: ● Fail sanely ● Progressive rollouts ● Overloads and failure
Выводы SRE-практики необходимы, так как: ● Снижается время даунтайма ● Проще расставлять приоритеты ● Снижается нагрузка на команду ● Небольшой прайс
Всем красивых дашбордов! github.com/tochk me@tochk.ru

More Related Content

Xp days 2019 - Why startups need SRE practices

  • 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 ● Сложно понять момент начала проблемы ● Приходится много грепать логи ● Иногда сообщения о проблемах приходили от пользователей, хотя это можно бы было определить с помощью мониторинга
  • 11. Monitoring ● Можно понять, когда что-то сломалось ● Эндпоинты для проверок ● Метрики ● Красивые дашборды ● Трейсинг
  • 12. RED
  • 16. Alerting ● Понятные алерты ● Отсутствие ложных алертов ● Отбрасывание пиковых значений Пример эндпоинта /stats requests{“code”=200} 200 requests{“code”=500} 5
  • 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 минут ● Вышли за бюджет ошибок и переделали систему хранения
  • 21. Postmortems ● Заводить после каждого инцидента ● Должен содержать всю доступную информацию ● Способы предотвращения повторения инцидента
  • 22. SRE-практики ● Monitoring ● Error budgets ● Postmortems ● SRE Teams (toil elimination)
  • 23. SRE teams (toil elimination) ● Менее 50% времени отводится на рутинные задачи Например: ● Хранить логи в graylog ● Использовать понятные метрики ● Красивые дашборды
  • 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$
  • 31. Prometheus vs Datadog Prometheus: ➕ Дешевле ➕ Удобнее мониторить background tasks ➕ Более гибкое конфигурирование алертов ➕ Находится во внутренней сети ➖ Нужно поддерживать ➖ Нельзя класть трейсы
  • 32. Prometheus vs Datadog Datadog: ➕ Просто внедрить ➕ Не нужно поддерживать ➕ Можно хранить трейсы ➕ Находится во внешней сети ➖ Дороже
  • 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
  • 41. Что дальше? Собираемся вводить: ● SLO from user side ● Capacity planning Пока думаем: ● Fail sanely ● Progressive rollouts ● Overloads and failure
  • 42. Выводы SRE-практики необходимы, так как: ● Снижается время даунтайма ● Проще расставлять приоритеты ● Снижается нагрузка на команду ● Небольшой прайс