Если вы уже выкатываете релизы автоматически и в процессе выкатки есть стадия нагрузочного тестирования, то этот рецепт – для вас.

В нашем релизном процессе был шаг выкатки на тестовый стенд, на который выкатывается сборка и нагружается трафиком. Чтобы сильно не задерживать релизный процесс, мы выставили довольно высокое стартовое значение нагрузки по принципу «ну, столько наш бэкенд точно выдержит всегда». Затем система плавно увеличивала трафик. По мере его повышения стенд переставал отвечать на запросы, тестирование завершалось, а последнее успешное значение трафика принималось за результат нагрузочного тестирования. Если результат был допустим, то релиз выкатывался дальше в продакшн.

Долгое время наш результат тестирования был более-менее стабильным. Потом добавили немного логики, потом еще немного, потом еще… А он продолжал оставаться таким же, и релизы выкатывались в продакшн. Пока кто-то не пошел зачем-то посмотреть результаты тестирования своими глазами…

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

Как стоило бы поступить:

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

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

– считать тестирование успешным в случае, если финальное значение трафика отличается от стартового

– вычислять долю успешных и неуспешных ответов от стенда

Одним из основных принципов SRE является проактивное управление системами, что означает создание автоматических систем для защиты от инцидентов и поломок разного рода.

Вот несколько примеров таких автоматик:

– включение фильтрации трафика при срабатывании каких-то условий

– автоскейлинг ресурсов при росте нагрузки

– подключение кеширующих прокси

– отключение незначимых компонентов системы при пиковой нагрузке

– снижение скорости передачи данных

– увеличение времени ответа

– …

Список вариантов большой, но смысл понятен.

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

Всю такую автоматику необходимо регулярно проверять! Составьте себе расписание учений и протоколы проверки всех автоматик, на которые вы полагаетесь для обеспечения высокого качества своего сервиса в критических ситуациях.

В ходе этих регулярных проверок вы сможете обнаружить:

– изъяны или слабые места до того, как они проявятся в результате реальных инцидентов;

– изменения окружающей среды: по мере развития сервисов и инфраструктуры защитные механизмы могут потребовать корректировки или вообще перестать работать;

– несоответствия требованиям аудита;

– неполадки в работе системы мониторинга и оповещений;

– отсутствие необходимых доступов

– … и еще много всего.

Кроме того, участие в тестировании автоматики – это хороший способ онбординга новичков в команде.

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

Деньги:

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

– проанализировать систему на предмет основных рисков

– оценить потери в результате реализации рисков

– спроектировать средства защиты

– оценить стоимость их реализации и поддержки

– применить здравый смысл и выбрать, куда потратить свои деньги

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

У любых учений есть два недостатка. Первый, главный: они далеки от реальной катастрофы. Второй: они проводятся по протоколу.

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

Вносите разнообразие в учения. Регулярно меняйте протоколы и форматы.

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

Вот несколько способов внести разнообразие:

– использовать генератор случайных чисел, где это применимо

– применять вариации: например, проводить учебные проверки в разное время суток

– вместо одного сценария представлять варианты, когда различные компоненты выходят из строя в разном порядке или возникают несколько проблем одновременно

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

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

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

Сделайте визуальную схему всей системы и спроектируйте меры повышения надежности.

Деньги:

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

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

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

Мониторинг трафика важен по нескольким причинам:

– ранняя диагностика проблем

– контроль использования ресурсов

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

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

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

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

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

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