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

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

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

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

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

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

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

7. Регулярно проверяй всю редко используемую автоматику

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

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

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

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

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

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

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

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

– …

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

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

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

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

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

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

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

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

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

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

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

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

Деньги:

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

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

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

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

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

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

8. Рандомизируй учения

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

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

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

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

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

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

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

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

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

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

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

9. Проектируй failover смолоду