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

Если у вас масштабирование устроено по принципу “жмём кнопку, платим сколько угодно, через минуту получаем мощности”, то у вас нет этой проблемы.

Если ваше масштабирование устроено иначе, то запас какой-то иметь придётся, хотя бы на выживание во время масштабирования.

Что включить в расчеты:

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

– Выход из строя части инфраструктуры. У любого поставщика услуг есть какие-то гарантии, ознакомьтесь с ними.

– Сломанная часть продакшена в результате неудачного релиза. Здесь всё зависит от вашей процедуры релиза.

– Ещё какие-то особые локальные сценарии.

То есть, нужно понимать, как обслуживать высокий уровень трафика при частично потерянной инфраструктуре из-за провайдера и во время релиза. Вы можете сказать: “Если у нас не будет работать часть инфраструктуры или будет высокий трафик, мы не будем катить релиз”. Обязательно произойдет ситуация, когда это будет необходимо.

Нужно ли запасать мощности на случай DDoS? Я считаю, что в этом нет смысла – всё равно не хватит.

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

30. Считайте запас критического пути

Снова про запасы.

Обработка запроса пользователя состоит из трёх основных стадий:

– получение запроса по сети

– обработка бэкендом

– выдача ответа по сети

В стадии "обработка бэкендом" может скрываться бездна этапов: походы в базы данных, сотню других микро- и немикро- сервисов, кэши и тп.

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

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

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

31.