Jan. 5th, 2011

metaclass: (Default)
Все началось с того, что в одной территориально распределенной опердени не прошла проверка на корректность репликации баз и на меня повесили задание разобраться с этим. Т.е., просто формальный критерий - сумма проводок "сколько опердень отдала товара на сторону" не совпала с суммой "сколько опердень получила товара со стороны".
Как известно, репликация распределенных баз данных это адское вуду, которое, как оказалось, до сих пор служит темой для теоретических работ, стимулом для использования NoSQL и тому подобного. Когда я делал эту хрень 5 лет назад, я еще не настолько поехал крышей на почве computer science, чтобы месяцами читать теоретические работы, прежде чем делать. Поэтому система уже сделана и давно работает, но изредка возникают проблемы требующие ручного вмешательства.
Ну с задачей я разобрался, там мелочь, но в процессе решил упростить себе решение подобных задач и сделать небольшой sql запрос для проверки подобного. В процессе создания запроса обнаружил что моя копия рабочей базы устарела и нужно бы скачать с клиентов новую копию. Полез на сервер бэкапов и обнаружил что бэкапов там уже неделю как нет.
Оказывается, местные админы опять "воевали с кидо" и, видимо, отключили планировщик заданий, после чего бэкапы отгнили. Я бы, конечно, предложил вырвать им сердце, но мой начальник человек умеющий сглаживать углы, поэтому мне никто не разрешит высказать админам все что я думаю о деструктивном вмешательстве в работу системы, ни у кого не спрашивая и никого не предупреждая, а так же о том, какие деструктивные вмешательства в работу внутренних и внешних органов этих админов я бы произвел, будь на то моя воля.

Обсуждение сей ситуации привело к всплытию старой темы про адекватный мониторинг наших производственных серверов. Я давно про это думаю, но есть особенность что эти сервера разбросаны по всей РБ и за ее пределами, количество вариаций подключения серверов между собой, клиентскими рабочими местами и интернетом достаточно невменяемое (что нибудь типа "сервер 1 видит сервер 2, сервер 3 видит видит сервер 2, но сервер 1 и 3 друг друга не видят, причем выход в интернет есть только на сервере 1 и только через анальный VPN находящийся у черта на рогах на сервере 4 и на котором админы в припадках биполярного аффективного расстройства постоянно рулят правилами файрволла в зависимости от фаз луны")
Кроме того, тема мониторинга серверов при размышлении превращается в адово вуду типа "мониторинг наличия соединений, мониторинг наличия свободного места, мониторинг работоспособности софта, мониторинг наличия регулярно создаваемых бэкапов, и прочая и прочая".

Ребе [livejournal.com profile] belnetmon с ходу предложил несколько вариантов простого мониторинга, но я их все отверг, потому что уже давно их все перебрал и понял, что реальный мониторинг, а не самоуспокоение - это как "безопасность, которая процесс а не продукт". Т.е. мало того, что написанной за день софтиной "проверяем состояние сервера раз в час и пишем в базу данных" не обойдешься никак - за этим нужно постоянно присматривать, а софт всего лишь упрощает работу тому, кто будет присматривать.
Т.е. суть в том, что писать подобного рода программы запрещено - единственное что они могут дать - это самоуспокоение, а на самом деле там админ в припадке психоза напишет прогу, которая будет отсылать уведомление "все хорошо", ничего не проверяя, а бэкапы отключит, потому что они мешают ему спать, "винчестер шуршит и излучает астральных вшей в радиусе 10 метров". Поэтому написать качественную софтину подобного назначения - это слишком долго и дорого (полноценный промышленный продукт как бэ), а писать некачественную наколенную поделку запрещает паук, который страдает перфекционизмом и люто ненавидит половинчатые решения.

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 9th, 2025 06:58 pm
Powered by Dreamwidth Studios