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

– управление производительностью

– потребности в локальном масштабировании

– планирование будущего роста

– контроль затрат

Это не полный список причин.

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

Для таких случаев используется комплексный мониторинг: по абсолютам и по тренду. У них разный принцип работы.

Мониторинг по абсолютному значению

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

Важно понимать, что если случится внезапный рост трафика в дни, когда он обычно низкий, то из-за ширины диапазона этого можно не увидеть, ведь значения останутся в зоне нормы. Для этого нужен другой мониторинг.

Мониторинг по тренду

Этот вид мониторинга предполагает некоторое накопление данных, и есть множество алгоритмов его работы: сравнение текущего уровня трафика с типичным для этого дня недели, накопление пятиминутных значений и сравнение их между собой… Здесь каждый сам выбирает нужный ему алгоритм, исходя из доступных технических средств и ситуации.

Важно понимать: если трафик растет или, наоборот, падает достаточно медленно (в течение суток или недели, например), то мониторинг по тренду может не сработать – рост или падение будет слишком плавным. Здесь как раз поможет мониторинг по абсолютным значениям, который может сработать не так быстро, но лучше когда-нибудь, чем никогда.

К сожалению, обычно мониторят только рост трафика, потому что боятся за нагрузку и работоспособность системы, но его падение не менее важно: без трафика нет пользователей, а без них – нет денег. Его спад может указывать на проблему с доступом, в частности связанную с DNS, истекший срок действия SSL-сертификатов или неработающая функциональность интерфейса, которая не позволяет пользователям выполнять запросы и решать свои задачи, выпуск новой версии и еще куча разных причин. Но обычно падение трафика не говорит вообще ни о чем хорошем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже – еще несколько очевидных проблем, связанных с такой практикой.

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

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

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

Возьмите себе за правило: один проект – одна база данных.