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

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

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

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

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

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

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

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

– …

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

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

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

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

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

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

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

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

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

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

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

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

Деньги:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Деньги:

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

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

10. Мониторинг трафика в диапазоне

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

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

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

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