SRE. Рецепты выживания в продакшне для инженера по надежности
Шрифт:
К сожалению, если на учениях выявилась какая-то проблема у какого-то сервиса, то ее устранение означает только то, что сервис научился переживать сценарий учений. Это вовсе не значит, что если начать отключать что-то в другом порядке, то все будет хорошо. И уж тем более – что авария будет проходить по сценарию учений.
Вносите разнообразие в учения. Регулярно меняйте протоколы и форматы.
Изменение последовательности действий во время учений повышает шансы того, что отдельные люди и команды действительно понимают лежащие в основе
Вот несколько способов внести разнообразие:
– использовать генератор случайных чисел, где это применимо
– применять вариации: например, проводить учебные проверки в разное время суток
– вместо одного сценария представлять варианты, когда различные компоненты выходят из строя в разном порядке или возникают несколько проблем одновременно
– менять членов команды ролями во время учений, это не только изменит динамику, но и покажет проблемы в навыках
– менять порядок шагов в сценарии учений, чтобы увидеть, как участники адаптируются, смогут ли они по-прежнему эффективно решать возникающие проблемы, и каким будет поведение всей системы
9. Проектируй failover смолоду
Если у сервиса есть хоть какой-то шанс получить статус «должен работать примерно всегда», то лучше начинать думать о надежности сразу. Сами процессы стоит проектировать реентерабельными – рассчитанными на перезапуск, параллельный запуск и какой угодно другой запуск и работу. Лучше сразу предполагать, что любая часть проекта может выйти из строя, и резервировать ее, если без нее нельзя обойтись. Во-первых, система сразу будет более-менее устойчивой, а во-вторых – более масштабируемой.
Сделайте визуальную схему всей системы и спроектируйте меры повышения надежности.
Деньги:
Резервирование системы увеличивает ее стоимость не в два раза, а существенно больше, так как для управления резервными схемами требуются инструменты координации.
Как и в случае с рецептом про автоматику, здесь целесообразно оценить последствия отказа конкретных компонентов, посчитать стоимость их резервирования и систем координации. Только после этого принимать решение о создании запасного варианта.
10. Мониторинг трафика в диапазоне
Каждый раз, когда пользователь взаимодействует с приложением / веб-сайтом, отправляя данные или выполняя поиск, сервер получает запросы для обработки этих действий и предоставления информации. Это то, что мы в быту называем словом «трафик».
Мониторинг трафика важен по нескольким причинам:
– ранняя диагностика проблем
– контроль использования ресурсов
– управление производительностью
– потребности в локальном масштабировании
– планирование будущего роста
– контроль затрат
Это не полный список причин.
Трафик может количественно меняться двумя способами: резко и плавно. Также он зависит от сезона, дня недели, времени
Для таких случаев используется комплексный мониторинг: по абсолютам и по тренду. У них разный принцип работы.
Мониторинг по абсолютному значению
Нужен мониторинг абсолютного значения и сверху, и снизу. Это может быть очень широкий диапазон, потому что верх определяют по максимуму, в дни высокого трафика, а низ – по минимуму, в дни низкого. Необходимо изучить свою динамику трафика за достаточно большой период и на основании нее выбрать абсолютные значения.
Важно понимать, что если случится внезапный рост трафика в дни, когда он обычно низкий, то из-за ширины диапазона этого можно не увидеть, ведь значения останутся в зоне нормы. Для этого нужен другой мониторинг.
Мониторинг по тренду
Этот вид мониторинга предполагает некоторое накопление данных, и есть множество алгоритмов его работы: сравнение текущего уровня трафика с типичным для этого дня недели, накопление пятиминутных значений и сравнение их между собой… Здесь каждый сам выбирает нужный ему алгоритм, исходя из доступных технических средств и ситуации.
Важно понимать: если трафик растет или, наоборот, падает достаточно медленно (в течение суток или недели, например), то мониторинг по тренду может не сработать – рост или падение будет слишком плавным. Здесь как раз поможет мониторинг по абсолютным значениям, который может сработать не так быстро, но лучше когда-нибудь, чем никогда.
К сожалению, обычно мониторят только рост трафика, потому что боятся за нагрузку и работоспособность системы, но его падение не менее важно: без трафика нет пользователей, а без них – нет денег. Его спад может указывать на проблему с доступом, в частности связанную с DNS, истекший срок действия SSL-сертификатов или неработающая функциональность интерфейса, которая не позволяет пользователям выполнять запросы и решать свои задачи, выпуск новой версии и еще куча разных причин. Но обычно падение трафика не говорит вообще ни о чем хорошем.
Поэтому рецепт такой: трендовый мониторинг делать для нахождения отклонений в типичном поведении, а пороговый – для крайних случаев, когда трендовый не способен определить отклонения. То есть мониторить следует не только рост трафика, но и падение.
11. Мониторинг среднего и min/max
В системах, где много серверов / узлов / нод (выберите любую единицу своей системы), невозможно мониторить каждую единицу. Поэтому для мониторинга значений создают агрегаты: перцентили, медианы и т. п. То есть некоторое «среднее по больнице». Это разумный подход, но есть нюанс: обычно имеются единичные отклонения, которые в агрегате будут незаметны.