![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программировать запрещено
Все началось с того, что в одной территориально распределенной опердени не прошла проверка на корректность репликации баз и на меня повесили задание разобраться с этим. Т.е., просто формальный критерий - сумма проводок "сколько опердень отдала товара на сторону" не совпала с суммой "сколько опердень получила товара со стороны".
Как известно, репликация распределенных баз данных это адское вуду, которое, как оказалось, до сих пор служит темой для теоретических работ, стимулом для использования NoSQL и тому подобного. Когда я делал эту хрень 5 лет назад, я еще не настолько поехал крышей на почве computer science, чтобы месяцами читать теоретические работы, прежде чем делать. Поэтому система уже сделана и давно работает, но изредка возникают проблемы требующие ручного вмешательства.
Ну с задачей я разобрался, там мелочь, но в процессе решил упростить себе решение подобных задач и сделать небольшой sql запрос для проверки подобного. В процессе создания запроса обнаружил что моя копия рабочей базы устарела и нужно бы скачать с клиентов новую копию. Полез на сервер бэкапов и обнаружил что бэкапов там уже неделю как нет.
Оказывается, местные админы опять "воевали с кидо" и, видимо, отключили планировщик заданий, после чего бэкапы отгнили. Я бы, конечно, предложил вырвать им сердце, но мой начальник человек умеющий сглаживать углы, поэтому мне никто не разрешит высказать админам все что я думаю о деструктивном вмешательстве в работу системы, ни у кого не спрашивая и никого не предупреждая, а так же о том, какие деструктивные вмешательства в работу внутренних и внешних органов этих админов я бы произвел, будь на то моя воля.
Обсуждение сей ситуации привело к всплытию старой темы про адекватный мониторинг наших производственных серверов. Я давно про это думаю, но есть особенность что эти сервера разбросаны по всей РБ и за ее пределами, количество вариаций подключения серверов между собой, клиентскими рабочими местами и интернетом достаточно невменяемое (что нибудь типа "сервер 1 видит сервер 2, сервер 3 видит видит сервер 2, но сервер 1 и 3 друг друга не видят, причем выход в интернет есть только на сервере 1 и только через анальный VPN находящийся у черта на рогах на сервере 4 и на котором админы в припадках биполярного аффективного расстройства постоянно рулят правилами файрволла в зависимости от фаз луны")
Кроме того, тема мониторинга серверов при размышлении превращается в адово вуду типа "мониторинг наличия соединений, мониторинг наличия свободного места, мониторинг работоспособности софта, мониторинг наличия регулярно создаваемых бэкапов, и прочая и прочая".
Ребе![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
belnetmon с ходу предложил несколько вариантов простого мониторинга, но я их все отверг, потому что уже давно их все перебрал и понял, что реальный мониторинг, а не самоуспокоение - это как "безопасность, которая процесс а не продукт". Т.е. мало того, что написанной за день софтиной "проверяем состояние сервера раз в час и пишем в базу данных" не обойдешься никак - за этим нужно постоянно присматривать, а софт всего лишь упрощает работу тому, кто будет присматривать.
Т.е. суть в том, что писать подобного рода программы запрещено - единственное что они могут дать - это самоуспокоение, а на самом деле там админ в припадке психоза напишет прогу, которая будет отсылать уведомление "все хорошо", ничего не проверяя, а бэкапы отключит, потому что они мешают ему спать, "винчестер шуршит и излучает астральных вшей в радиусе 10 метров". Поэтому написать качественную софтину подобного назначения - это слишком долго и дорого (полноценный промышленный продукт как бэ), а писать некачественную наколенную поделку запрещает паук, который страдает перфекционизмом и люто ненавидит половинчатые решения.
Как известно, репликация распределенных баз данных это адское вуду, которое, как оказалось, до сих пор служит темой для теоретических работ, стимулом для использования NoSQL и тому подобного. Когда я делал эту хрень 5 лет назад, я еще не настолько поехал крышей на почве computer science, чтобы месяцами читать теоретические работы, прежде чем делать. Поэтому система уже сделана и давно работает, но изредка возникают проблемы требующие ручного вмешательства.
Ну с задачей я разобрался, там мелочь, но в процессе решил упростить себе решение подобных задач и сделать небольшой sql запрос для проверки подобного. В процессе создания запроса обнаружил что моя копия рабочей базы устарела и нужно бы скачать с клиентов новую копию. Полез на сервер бэкапов и обнаружил что бэкапов там уже неделю как нет.
Оказывается, местные админы опять "воевали с кидо" и, видимо, отключили планировщик заданий, после чего бэкапы отгнили. Я бы, конечно, предложил вырвать им сердце, но мой начальник человек умеющий сглаживать углы, поэтому мне никто не разрешит высказать админам все что я думаю о деструктивном вмешательстве в работу системы, ни у кого не спрашивая и никого не предупреждая, а так же о том, какие деструктивные вмешательства в работу внутренних и внешних органов этих админов я бы произвел, будь на то моя воля.
Обсуждение сей ситуации привело к всплытию старой темы про адекватный мониторинг наших производственных серверов. Я давно про это думаю, но есть особенность что эти сервера разбросаны по всей РБ и за ее пределами, количество вариаций подключения серверов между собой, клиентскими рабочими местами и интернетом достаточно невменяемое (что нибудь типа "сервер 1 видит сервер 2, сервер 3 видит видит сервер 2, но сервер 1 и 3 друг друга не видят, причем выход в интернет есть только на сервере 1 и только через анальный VPN находящийся у черта на рогах на сервере 4 и на котором админы в припадках биполярного аффективного расстройства постоянно рулят правилами файрволла в зависимости от фаз луны")
Кроме того, тема мониторинга серверов при размышлении превращается в адово вуду типа "мониторинг наличия соединений, мониторинг наличия свободного места, мониторинг работоспособности софта, мониторинг наличия регулярно создаваемых бэкапов, и прочая и прочая".
Ребе
belnetmon с ходу предложил несколько вариантов простого мониторинга, но я их все отверг, потому что уже давно их все перебрал и понял, что реальный мониторинг, а не самоуспокоение - это как "безопасность, которая процесс а не продукт". Т.е. мало того, что написанной за день софтиной "проверяем состояние сервера раз в час и пишем в базу данных" не обойдешься никак - за этим нужно постоянно присматривать, а софт всего лишь упрощает работу тому, кто будет присматривать.Т.е. суть в том, что писать подобного рода программы запрещено - единственное что они могут дать - это самоуспокоение, а на самом деле там админ в припадке психоза напишет прогу, которая будет отсылать уведомление "все хорошо", ничего не проверяя, а бэкапы отключит, потому что они мешают ему спать, "винчестер шуршит и излучает астральных вшей в радиусе 10 метров". Поэтому написать качественную софтину подобного назначения - это слишком долго и дорого (полноценный промышленный продукт как бэ), а писать некачественную наколенную поделку запрещает паук, который страдает перфекционизмом и люто ненавидит половинчатые решения.
no subject
no subject
no subject
Дарю идею
У вас (на хорошем канале) стоит zabbix (говорю его для примера, ибо у нас используется активно, а в детали я не копался; возможно, подойдут более другие решения), где для клиента заведено 100500 типовых метрик и алертов.
А у клиента стоит ваша софтина, которая помимо прочего по "каналу в конский волос" рапортует серверу мониторинга своё состояние по 100500 параметрам. Непоступление метрики A в течение B часов также является аварийной ситуацией и генерит алерт.
Схема алертов красиво настраивается на то, чтобы слать СМС админам заказчика в случае срочной жопы, почтовые уведомления им же в случае обычной жопы, поднимать приоритет и слать увеждомления в почту/на телефон руководству заказчика если жопа не устранена в течение N часов (N настраивается в зависимости от типа жопы).
При этом вы снимаете с клиента копейку за пусконаладку, и ежемесячную копейку за работу сервера мониторинга с набором настроек под этого клиента. Подозреваю, что первый десяток пусконаладок позволит выработать типовое решение, которое потом будет тиражироваться за 10 минут и работать у вас "из коробки".
В такой схеме все счастливы, кроме админов (но могут быть счастливы и они, если грамотно все продумать).
Re: Дарю идею
Re: Дарю идею
Продаваемо ли оно 90% клиентов или 10% и на каких условиях, судить не могу, не знаю рынка :)
Re: Дарю идею
Причём, по етой политике, меня в енторнет выпускало, а сервера, которые я обслуживал, не выпускало.
Причём, попытки исправить ситуацию наталкивались на _монологи_ начальства по поводу -
"Знаешь же, что такое безопасность, что такое политика безопасности, а она директором доработана и утверждена, и нельзя такие вещи разрешить, ведь ты сам специалист-компьютерщик, но почему вопросы задаёшь такие глупые?"
С директором (тот ещё "компьютерщик") поговорить не удавалось.
Его и видели-то большинство людей по разу в год - при новогоднем поздравлении.
И приходилось, для удобства, таки через свой ноут всё пускать.
Одно время, делал и OpenVPN через этот прокси на управляемый мною сервак.
Весело было, даже жалею, что ушёл, где ж ещё столько веселья-то будет...
Всякия программки интересные легаси, работающие со старыми RedHat или CentOS не старше 4.7 и специальным подбором библиотек совместимости...
Столько интересного было...
Зарплата маленькая была, правда, но много свободного времени и большая свобода в расписании работы.
Надеюсь, было смешно. До встречи.
Re: Дарю идею
Re: Дарю идею
Собственно софтину для мониторинга разрабатывать с нуля не надо, только опытным путём ее конфигурацию.
Хотя если они не могут ничего выпускать наружу сети, и не могут самостоятельно ничего поддерживать внутри, а их пауки и черви неприкасаемы, -- тогда смысла нет вообще ни с чем дергаться.