SRE. Рецепты выживания в продакшене для инженера по надежности. Наталья Савенкова
потому что боятся за нагрузку и работоспособность системы, но падение трафика не менее важно: нет трафика = нет пользователей. Нет пользователей = нет денег. Спад трафика может указывать на проблему с доступом пользователей, такую как проблемы с DNS, истек срок действия SSL-сертификатов или неработающая функциональность интерфейса, которая не позволяет пользователям выполнять запросы и решать свои задачи, выпуск новой версии и ещё целая куча разных причин. Но обычно падение трафика не говорит вообще ни о чём хорошем.
Поэтому рецепт такой: трендовый мониторинг делать для нахождения отклонений в типичном поведении, а пороговый мониторинг для крайних случаев, когда трендовый не способен определить отклонения. Мониторить не только рост трафика, но и падение.
11. Мониторинг среднего и min/max
В системах, где много серверов / узлов / нод (выберите любую единицу своей системы), невозможно мониторить каждую единицу. Поэтому для мониторинга значений делают агрегаты: перцентили, медианы и тп. То есть, некоторое среднее по больнице. Это разумный подход, но есть нюанс: обычно есть единичные отклонения, которые в агрегате будут не заметны.
Проблема может быть на одном хосте из сотни, но вы не узнаете об этом. «Но это же всего один хост» скажут многие. Какая разница – он может быть не «одним», а «первым» в череде выхода из строя целой группы. Это совершенно разные ситуации.
Для этого случая полезно иметь мониторинг хотя бы на минимальное значение и на максимальное значение, либо использовать 95ю, 99ю перцентиль и другие виды перцентилей.
Например, если вы мониторите среднее время ответа и используете его для управления масштабированием, то имейте ввиду: половина запросов будет работь дольше этого среднего. Тут возникает очень важный вопрос: а насколько дольше?
В общем, вот что нужно сделать для улучшения ситуации:
– разобраться с перцентилями: что это такое, о чем они говорят
– проанализировать различные значения перцентилей в своей системе
– решить, какую информацию вы хотите получать о системе
– выбрать правильные значения перцентилей для мониторинга
12. Не сажайте слона и моську в одну базу
Мир IT продолжает развиваться быстро. Более того, эта скорость набирает обороты. Чем быстрее вы покажете свою идею в виде продукта, тем больше шансов выиграть в гонке. Здесь менеджеры продукта в прямом смысле соревнуются с инженерами: кто же выиграет – скорость запуска или архитектура?
При появлении очередного проекта, который надо сделать быстро-быстро, первое приходящее в голову звучит так: "Хмм, у нас уже есть в продакшене монга-постгря-мускуль-чтоугодно, подселим новую базу для проекта туда!"
Не стоит так делать. А если делаете, то осознавайте последствия и риски. Получается связанность критических компонентов двух совершенно разных проектов. Пойдёте базу обновлять – накосячите и сломаете оба проекта. Придёт большой трафик обновления в один проект, база начнёт тормозить и сломает второй проект.
Вот