Возможно, мы уже живем с этой системой около года и для нас всё выглядит очевидно, поэтому, возможно, что-то не дораскрыто в достаточной мере. Да, мы используем метрики/индикаторы - SLI. Да, мы используем базовые метрики - Success Rate для анализа доступности/отзакоустойчивости, ResponseTime - как индикатор производительности. И мы анализируем их отдельно в разных случаях, поэтому почти все графики имеют как отображение кумулятивной метрики, так и каждого индикатора по отдельности. Да, есть какие-то общие практики, но стандарта, который бы описывал что вот в таких вот системах должны быть вот такие индикаторы, они должны расцениваться так-то, и цели (Objectives) должны быть такими-то. Мы учли эти рекомендации, но для себя поняли, что нам нужен еще один индикатор, который можно называть по разному (и мы для себя выбрали название Reliability), отражающий состояние системы как в плоскости отказоустойчивости, так и плоскости производительности. И нашем случае мы решили что это будет функция "И" от состояния каждого из индикаторов в эталонный при нашей нагрузке интервал в 2 минуты. Можно назвать его "показателем здоровья", который описывает комплексное состояние как отдельно взято сервиса, так и системы в этот интервал. И для нас это показательно. А в качестве SLO мы себе ставим цель в 99.9 - что значит что в 99.9% наших "двухминуток" наша система должна находится в "зеленом" состоянии, т.е. валиться с ошибками (ну, с заданным допущением) и отвечать в рамках заданного целевого уровня скорости ответа. В этой статье мы поделились своим опытом, и рассказали какую методику выбрали для себя, почему, и как к ней пришли. Вы так же можете поделиться своим опытом - и мы можем учесть его в дальнейших итерациях по улучшению нашей системы.
Возможно, мы уже живем с этой системой около года и для нас всё выглядит очевидно, поэтому, возможно, что-то не дораскрыто в достаточной мере.
Да, мы используем метрики/индикаторы - SLI.
Да, мы используем базовые метрики - Success Rate для анализа доступности/отзакоустойчивости, ResponseTime - как индикатор производительности. И мы анализируем их отдельно в разных случаях, поэтому почти все графики имеют как отображение кумулятивной метрики, так и каждого индикатора по отдельности.
Да, есть какие-то общие практики, но стандарта, который бы описывал что вот в таких вот системах должны быть вот такие индикаторы, они должны расцениваться так-то, и цели (Objectives) должны быть такими-то. Мы учли эти рекомендации, но для себя поняли, что нам нужен еще один индикатор, который можно называть по разному (и мы для себя выбрали название Reliability), отражающий состояние системы как в плоскости отказоустойчивости, так и плоскости производительности. И нашем случае мы решили что это будет функция "И" от состояния каждого из индикаторов в эталонный при нашей нагрузке интервал в 2 минуты. Можно назвать его "показателем здоровья", который описывает комплексное состояние как отдельно взято сервиса, так и системы в этот интервал. И для нас это показательно.
А в качестве SLO мы себе ставим цель в 99.9 - что значит что в 99.9% наших "двухминуток" наша система должна находится в "зеленом" состоянии, т.е. валиться с ошибками (ну, с заданным допущением) и отвечать в рамках заданного целевого уровня скорости ответа.
В этой статье мы поделились своим опытом, и рассказали какую методику выбрали для себя, почему, и как к ней пришли. Вы так же можете поделиться своим опытом - и мы можем учесть его в дальнейших итерациях по улучшению нашей системы.
А выдержит ли конструкция работу зимой при температуре -30-35, и летом при +35-40?