Comments 18
Спасибо за пост. Что вы думаете о https://github.com/dataegret/pgcompacttable? pgcompacttable не сильно нагружает БД.
С точки зрения метрик вы сделали офигенно. -60% нагрузки. С точки зрения понятности архитектуры: теперь есть cron скрипт, после смерти которого нагрузка вырастет на 166% и никто (без его пересоздания посредством повторения исследования из этого поста) ничего не сможет сделать. Т.е. это классический админский костыль на которых всё и держится. Они очень хорошо работают, но не очень хорошо сопровождаются.
Каким образом и когда вы узнаете, что он сломался? И как человек, который "что-то заподозрит" поймёт, что дело в нём?
Навскидку, в данном примере, резкое увеличение количества одновременных автовакуумов в течение суток явно укажет на этот скрипт.
А если оно «вдруг упадет», то система не станет мгновенно работать в разы хуже — то есть запас по времени на устранение последствий достаточен.
Программерский костыль ещё хуже админского, потому что зарыт глубже. Но, не всё, что пишут программисты и админы — костыли.
Я к тому, что если у вас есть критическое улучшение инфраструктуры (рост утилизации ресурсов СУБД на 166% — это вполне близко к "критическое" при указанных нагрузках), то оно должно быть отражено в описании инфраструктуры. То есть есть два сервера: на одном поправлено, на другом нет. Чем они отличаются, кроме "последствий"?
Ответ должен включать какую-то инструментацию: тесты, декларативное описание, доказательства работы (кроме быстрой производительности).
Кстати, почему крон, а не таймер systemd? Вот я таймера я адекватную инфраструктуру проверки работы могу себе представить, а вот для крона — только если несколько слоёв баша намазать...
В цепочке контроля обычно всё заканчивается на тестах. Вот меня сейчас попросили для продукта, который мы предоставляем (попользоваться) дать запросы в пром на простейшие метрики (для показа в UI). Вместо того, чтобы отдать примеры запросов и забыть про задачу, у нас есть задача "проверять запросы". CI, который тестирует продукт, теперь (когда задачу сделают) будет проверять, что каждый запрос отдаёт то, что ожидается. Во-первых мы уверены тогда в смысле запросов, во-вторых, если что-то поменяют (например, номер порта прома) без учёта в остальной инфраструктуре, оно обсыпется с грохотом.
Т.е. в нашем случае тесты являются финальным якорем для решений (и костылей). Что-то поменяли и сломали костыль? Оно просто не попадёт в мастер.
И если «админский костыль» (а чем он хуже программерского?) — часть инфраструктуры, то и мониториться он должен по аналогичным правилам.В этом контексте под «мониториться» надо понимать и весь CI-цикл.
Я немного про другое. Если есть проверка, которая следит за таймером и соответствующим сервисом (не крон. пожалуйста, не крон!), то она работает на слепой вере. 99.9% времени она работает хорошо (сообщает, что проблемы нет), в оставшийся 0.1% она работает плохо (не сообщает о том, что проблема есть). Откуда вы знаете, что ваша проверка ловит проблему?
Хотя мы лезем в детали реализации. В хорошей инфраструктуре наличие этого таймера и его проверки будет частью маленькой и хорошо проверенной сущности, а не всего проекта. У этой сущности должно быть своё название и понимание, что вы используете её, а не что-то другое.
99.9% времени она работает хорошо (сообщает, что проблемы нет), в оставшийся 0.1% она работает плохо (не сообщает о том, что проблема есть). Откуда вы знаете, что ваша проверка ловит проблему?А откуда мы знаем, что остальные 99.9% она работает действительно хорошо? Ах, это нам сообщил непогрешимый проверочный скрипт?.. Или таки проверочный скрипт тоже надо проверять?
Ровно про это я и говорю, что количество степеней проверки определяется ценностью проверяемой операции.
Ну, достоверно сломать проще, чем сделать достоверно работающее. В соответствующем скрипте у нас написано:
- проверить, что работает
- сломать
- проверить, что срабатывает
- починить
- проверить, что работает
Вот эта часть "сломать" — она чаще всего тривиальна, и в сочетании "проверить, что срабатывает" верифицируется в силу маловероятности синхронных двух одновременных багов в обоих проверках ("маловероятность" тут следует читать в одном ряду с "маловероятной коллизией рандомных uuid'ов").
Для совсем параноиков есть мутационное тестирование. Хотя в целом, в модели тестов говорится, что тесты должны быть такими простыми, что их можно верифицировать "глазами".
Я не знаю что у проекта "снизу" (как всё развёртывается/тестируется), так что не могу сказать достаточно этого или нет. Если просто добавлен руками алерт в мониторинг с ссылкой на статью, то это ещё один костыль, который подпирает предыдущий костыль.
Документированный костыль, который работает, нормальная фича любой реальной системы.
Бартунов, Сигаев. Как устроить хайлоад на ровном месте
DBA: Ночной Дозор