Чтение онлайн

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

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

Деньги:

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

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

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

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

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

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

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

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

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

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

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

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

Для таких случаев используется комплексный мониторинг: по абсолютам и по тренду. У них разный принцип работы.

Мониторинг по абсолютному значению

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

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

Мониторинг по тренду

Этот вид мониторинга предполагает некоторое накопление данных, и есть множество алгоритмов его работы: сравнение текущего уровня трафика с типичным для этого дня недели, накопление пятиминутных значений и сравнение их между собой… Здесь каждый сам выбирает нужный ему алгоритм, исходя из доступных технических средств и ситуации.

Важно понимать: если трафик растет или, наоборот, падает достаточно медленно (в течение суток или недели, например), то мониторинг по тренду может не сработать – рост или падение будет слишком плавным. Здесь как раз поможет мониторинг по абсолютным значениям, который может сработать не так быстро, но лучше когда-нибудь, чем никогда.

К сожалению, обычно мониторят только рост трафика, потому что боятся за нагрузку и работоспособность системы, но его падение не менее важно: без трафика нет пользователей, а без них – нет денег. Его спад может указывать на проблему с доступом, в частности связанную с DNS, истекший срок действия SSL-сертификатов или неработающая функциональность интерфейса, которая не позволяет пользователям выполнять запросы и решать свои задачи, выпуск новой версии и еще куча разных причин. Но обычно падение трафика не говорит вообще ни о чем хорошем.

Поэтому рецепт такой: трендовый мониторинг делать для нахождения отклонений в типичном поведении, а пороговый – для крайних случаев, когда трендовый не способен определить отклонения. То есть мониторить следует не только рост трафика, но и падение.

В системах, где много серверов / узлов / нод (выберите любую единицу своей системы), невозможно мониторить каждую единицу. Поэтому для мониторинга значений создают агрегаты: перцентили, медианы и т. п. То есть некоторое «среднее по больнице». Это разумный подход, но есть нюанс: обычно имеются единичные отклонения, которые в агрегате будут незаметны.

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

Для такого случая полезно иметь мониторинг хотя бы на минимальное и на максимальное значения, либо использовать 95-ю, 99-ю перцентиль и ее другие виды.

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

В общем, вот что нужно сделать для улучшения ситуации:

– разобраться с перцентилями: что это такое, о чем они говорят

– проанализировать различные значения перцентилей в своей системе

– решить, какую информацию вы хотите получать о системе

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

Мир IT продолжает развиваться быстро. Более того, эта скорость набирает обороты. Чем оперативнее вы покажете свою идею в виде продукта, тем больше шансов выиграть в гонке. Здесь менеджеры продукта в прямом смысле соревнуются с инженерами: кто же выиграет – скорость запуска или архитектура? Некоторые называют этот период «эпохой MVP».

При появлении очередного проекта, который надо создать быстро-быстро, первое, что приходит в голову, это: «Хмм, у нас уже есть в продакшне монга-постгря-мускуль-чтоугодно, подселим новую базу для проекта туда!»

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

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

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