Why Is My App SLOw? Defining Reliability in Platform Engineering • Jez Humble • YOW! 2023
Крутое выступление от Jez Humble про то, как определять, что проблемы есть у платформы, а не у потребителей, которые ей пользуются. Jez сейчас работает SRE в serverless платформе Google, у которой большое количество клиентов с разным профилем нагрузки, разными показателями latency и так далее. В такой конфигурации есть проблема в отделении проблем клиентских нагрузок от проблем самой платформы. Но ребята в Google справились с этим, используя знания математической статистики. Если формулировать точнее, то цель была такая
A metric that represents the customer experience
- Combinable across projects / cells / regions
- Can be used to detect anomalies affecting multiple customers (likely platform issues)
- Computationally cheap (high QPS)
- Principle-based Дальше автор говорит про три столпа reliability:
- Availability - здесь основа в том, чтобы посчитать количество (долю) неуспешных запросов. Ситуация осложняется тем, что есть некая субъективность в ошибках (куча 400х и 500х ошибок, которые задаются самими владельцами пользовательских нагрузок), возможны ошибки из-за нарушенных deadlines, могут просто с ошибками плохо сформированные запросы от клиентов, retries могут усиливать количество ошибок
- Performance - здесь автор говорит про установку P99 latency SLO и создании проберов. Но есть проблемы с зависимостями между нагрузками и тем, что проберы могут быть слишком узкими
- Correctness - здесь есть много тестов и анализ канареечных развертываний, но проблема с тем, что покрытие ограничено
Дальше автор говорит, что можно попробовать построить функцию распределения для пользовательских нагрузок (например, log-normal), а дальше можно представить, что пользовательские нагрузки можно считать стационарными. И следом использовать метод двух сигм и сформулировать гипотезу
Hypothesis: Self-Similar Workloads Should Have Consistent Performance Technique Overview:
- Partition workloads into Cohorts ← Approximate Intent via Workload Features
- Build Performance Baselines ← Estimate Distributional Form (e.g. Normal)
- Estimate Likelihood of Delivered Performance ← Test For Stationary Result:
- Set of Events with Predicted Likelihoods
- Time-series of summary statistics describing concentration of extreme outliers А дальше стратегия использования в том, чтобы
- Рассчитать z-scores среди нагрузок по кагортам, где z-scores = (observed-workloads - baseline-mean) / baseline-std
- Отслеживать долю нагрузок, у которых z-score ≥ 2 в выбранном временном окне
- Считать, что 2-5% процентов нагрузок с 2𝜎 отклонениями нормой
- Тригерриться, когда этот показатель будет выше 10%
В самом докладе есть еще много интересных моментов о том, как это работает и почему, но важен вывод, что такой подход позволяет надежно детектировать и измерять влияние на пользовательские нагрузки проблем на самой платформе.
P.S. Мне нравятся материалы Джеза, которые бывают как в печатном виде, так и в виде докладов. Раньше я уже рассказывал про
- Книгу "Accelerate" 2018 года, где Jez выступал в качестве соавтора (подробнее в постах 1, 2, 3)
- Книгу "Continuous Delivery" 2010 года, которая была важной вехой в развитии CI/CD (подробнее в посте)
- Этот же доклад, но на конференции goto в 2023 году
- Доклад Expert Talk: The Current State of Software Engineering"
- Доклад "How to Improve Developer Productivity"
#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Math #ContinuousDelivery