SRE. Рецепты выживания в продакшне для инженера по надежности
Шрифт:
Если запасными средствами не пользоваться, то рано или поздно они перестанут работать. Такова их судьба. Поэтому важно регулярно проверять, что они до сих пор функционируют и могут быть использованы в критической ситуации.
Например, можно сделать себе напоминание – раз в две недели «проверить резервные средства» и там описать все, что нужно проверить: резервный интернет оплачен и работает, резервный ноутбук загружается, и с него можно зайти во все необходимые системы, и так далее.
5. Ходить на чужие разборы полезно
Во многих
Если у вас в компании есть такое мероприятие – ходите туда и учитесь на кейсах своих коллег. Не надо ждать, когда случится инцидент именно у вас. Уникальных проблем поистине мало, а способов их предотвращения еще меньше. Изучайте, что случилось у других, анализируйте свою систему и выбирайте то, что разумно реализовать в ней заранее.
Если такого процесса не существует, то подумайте над тем, чтобы он появился.
6. Если результаты нагрузочного тестирования всегда одинаковые – это плохо
Если вы уже выкатываете релизы автоматически и в процессе выкатки есть стадия нагрузочного тестирования, то этот рецепт – для вас.
В нашем релизном процессе был шаг выкатки на тестовый стенд, на который выкатывается сборка и нагружается трафиком. Чтобы сильно не задерживать релизный процесс, мы выставили довольно высокое стартовое значение нагрузки по принципу «ну, столько наш бэкенд точно выдержит всегда». Затем система плавно увеличивала трафик. По мере его повышения стенд переставал отвечать на запросы, тестирование завершалось, а последнее успешное значение трафика принималось за результат нагрузочного тестирования. Если результат был допустим, то релиз выкатывался дальше в продакшн.
Долгое время наш результат тестирования был более-менее стабильным. Потом добавили немного логики, потом еще немного, потом еще… А он продолжал оставаться таким же, и релизы выкатывались в продакшн. Пока кто-то не пошел зачем-то посмотреть результаты тестирования своими глазами…
Что произошло на самом деле: по мере добавления новой функциональности и деградации производительности уровень допустимого трафика на стенд постепенно падал и упал ниже заданного стартового значения. В итоге тестирование заканчивалось сразу же, как только начиналось, потому что стенд обслуживал несколько запросов и сразу же отваливался, а в результаты просто записывалось то самое стартовое значение. За это время производительность бэкенда снизилась на 50%, но об этом никто не знал.
Как стоило бы поступить:
– начинать нагрузку трафиком с нулевого значения, но это сильно замедляет процесс релиза, и для кого-то это может быть принципиально
– создать параллельный процесс полного нагрузочного тестирования, чтобы не задерживать релизы
– считать тестирование успешным в случае, если финальное значение трафика отличается от стартового
–
7. Регулярно проверяй всю редко используемую автоматику
Одним из основных принципов SRE является проактивное управление системами, что означает создание автоматических систем для защиты от инцидентов и поломок разного рода.
Вот несколько примеров таких автоматик:
– включение фильтрации трафика при срабатывании каких-то условий
– автоскейлинг ресурсов при росте нагрузки
– подключение кеширующих прокси
– отключение незначимых компонентов системы при пиковой нагрузке
– снижение скорости передачи данных
– увеличение времени ответа
– …
Список вариантов большой, но смысл понятен.
Что важно: речь идет об автоматике, включающейся при некоторых условиях. То есть речь идет о редких ситуациях. И это означает, что механизмы должны работать безотказно. Как огнетушитель в вашем деревянном загородном доме с дровяной печью: если случится так, что он пригодится, то лучше, если он будет исправен.
Всю такую автоматику необходимо регулярно проверять! Составьте себе расписание учений и протоколы проверки всех автоматик, на которые вы полагаетесь для обеспечения высокого качества своего сервиса в критических ситуациях.
В ходе этих регулярных проверок вы сможете обнаружить:
– изъяны или слабые места до того, как они проявятся в результате реальных инцидентов;
– изменения окружающей среды: по мере развития сервисов и инфраструктуры защитные механизмы могут потребовать корректировки или вообще перестать работать;
– несоответствия требованиям аудита;
– неполадки в работе системы мониторинга и оповещений;
– отсутствие необходимых доступов
– … и еще много всего.
Кроме того, участие в тестировании автоматики – это хороший способ онбординга новичков в команде.
Каждая проверка – это возможность узнать больше о системе и о том, как она ведет себя в различных условиях, что в итоге помогает усовершенствовать защитные механизмы.
Деньги:
Тут крайне важно соблюдать баланс между «давайте подготовимся заранее к чему угодно и будем оберегать наш хрустальный дворец» и «не делаем вообще ничего». Если вы не создаете систему жизнеобеспечения, не управляете ракетами и прочими критическими системами, то будет достаточно:
– проанализировать систему на предмет основных рисков
– оценить потери в результате реализации рисков
– спроектировать средства защиты
– оценить стоимость их реализации и поддержки
– применить здравый смысл и выбрать, куда потратить свои деньги
8. Рандомизируй учения
В прошлой главе было много слов про важность проверки систем и про соответствующие протоколы. Так вот, назовем эти проверки учениями.
У любых учений есть два недостатка. Первый, главный: они далеки от реальной катастрофы. Второй: они проводятся по протоколу.