SRE. Рецепты выживания в продакшне для инженера по надежности - страница 8

Шрифт
Интервал


Поэтому рецепт такой: трендовый мониторинг делать для нахождения отклонений в типичном поведении, а пороговый – для крайних случаев, когда трендовый не способен определить отклонения. То есть мониторить следует не только рост трафика, но и падение.

11. Мониторинг среднего и min/max

В системах, где много серверов / узлов / нод (выберите любую единицу своей системы), невозможно мониторить каждую единицу. Поэтому для мониторинга значений создают агрегаты: перцентили, медианы и т. п. То есть некоторое «среднее по больнице». Это разумный подход, но есть нюанс: обычно имеются единичные отклонения, которые в агрегате будут незаметны.

Проблема может быть на одном хосте из сотни, но вы о ее существовании не узнаете. «Это же всего один хост», – скажут многие. Какая разница – он может быть не «одним», а «первым» в череде выхода из строя целой группы. Это совершенно разные ситуации.

Для такого случая полезно иметь мониторинг хотя бы на минимальное и на максимальное значения, либо использовать 95-ю, 99-ю перцентиль и ее другие виды.

Например, если вы мониторите среднее время ответа и используете его для управления масштабированием, то имейте в виду: половина запросов будет работать дольше этого среднего. Тут возникает очень важный вопрос: а насколько дольше?

В общем, вот что нужно сделать для улучшения ситуации:

– разобраться с перцентилями: что это такое, о чем они говорят

– проанализировать различные значения перцентилей в своей системе

– решить, какую информацию вы хотите получать о системе

– выбрать правильные значения перцентилей для мониторинга

12. Не сажайте слона и моську в одну базу

Мир IT продолжает развиваться быстро. Более того, эта скорость набирает обороты. Чем оперативнее вы покажете свою идею в виде продукта, тем больше шансов выиграть в гонке. Здесь менеджеры продукта в прямом смысле соревнуются с инженерами: кто же выиграет – скорость запуска или архитектура? Некоторые называют этот период «эпохой MVP».

При появлении очередного проекта, который надо создать быстро-быстро, первое, что приходит в голову, это: «Хмм, у нас уже есть в продакшне монга-постгря-мускуль-чтоугодно, подселим новую базу для проекта туда!»

Не стоит так делать, или же осознавайте последствия и риски. Получается связанность критических компонентов двух совершенно разных проектов: накосячите и сломаете оба, когда пойдете обновлять базу.