Обновить
29
Сергей Козлов@gunya

DevOps Engineer

12
Подписчики
Отправить сообщение
В большинстве случаев можно снять post mortem и выяснить примерную причину, почему легла машина.
Если в результате выясняется, что причина проблемы в радиусе кривизны рук пользователя — окей, за работы платит кост центр его отдела.
В целом, могу согласиться с обоими пунктами. Просто тюленей старались не брать, но Local Admins был в том числе и у бухгалтерии.
Достаточно SLA, по которому в такой сети сохранность данных предоставляется как Best Effort.
Хотим, чтобы хранилось надежно — окей, NFS с версионированием файлов, резервным копированием и резервированием.
> Но тогда никаких жалоб, что «Ось не грузиццо» — сам сломал, сам чини
У меня вылетел жесткий диск — ехать в магазин за новым, да?

> А то получается — права у программиста на установку, обновление софта и ОС, а обязанности устранять неполадки и отвечать за это — у администратора.
Взяли, развернули вчерашний бекап машины из образа, пошли играть в доту дальше.
Бог миловал, я избежал работы в компаниях, в которых требуется жестко ограничивать пользователя, чтобы он не дай бог не уложил себе машину. При этом я ни разу не видел, чтобы наличие пользователя в Local Admins как-либо вредило безопасности среды.
Системный администратор, если пострадали данные за пределами машины разработчика.

1. Отсутствие антивирусной защиты на прокси/почте, позволившие пронести вирус. Если вирус пришел на флешке, то:
2. Несвежие базы антивируса на машине разработчика, пропустившие шифровальщик. Если антивирус был отключен, то:
3. Некорректно настроены политики безопасности домена — разработчик смог отключить антивирус.

В любом случае — на машине разработчика не должно храниться ценной информации, плюс должна быть резервная копия его данных.
Потом к вам придет сначала разработчик, потом DevOps из его отдела, потом руководители по цепочке, потому что ребята не могут поднять Vagrant для разработки, надо доставить пару пакетов, нужна свежая версия библиотек, вышла свежая версия интерпретатора и npm не работает с корпоративным прокси.
Если программист своими действиями убил свой компьютер, то это означает, что с вашей подачи компания потеряла несколько часов его работы на переустановку операционной системы и приложений. Задача системного администратора — организовать бесперебойную работу и обеспечить сохранность данных у всех пользователей, включая разработчиков.


Вашей задачей должна быть минимизация и автоматизация действий для приведения компьютера сотрудника в готовое к бою состояние, а также минимизация времени и потерь при гибели машины. Если разработчик уложит себе систему без особой надобности — это событие в любом случае должно пройти через его руководителя, и это не должно быть проблемами системного администратора.
> какие еще алалоги есть для индивидуальной установки?
veaam

>А как проверять бекабы акрониса?
Разворачивать на виртуальной машине из бекапа — это по поводу проверки образа, но это не решает архитектурной проблемы с тем, что важные данные хранятся на компьютерах сотрудников.
Правильно в такой ситуации использовать nfs/samba шары для любой сколь угодно ценной информации.
Это не должно быть проблемой системного администратора. Это должно быть проблемой непосредственного руководителя человека, который сидит все рабочее время в соцсетях.

Так дойдет до того, что для SMO-отдела придется отдельные правила в фаерволле делать.
Единственное, при split brain такая схема войдет в состояние stonith deathmatch, когда оба сервера будут пытаться фенсить друг друга. Но это гораздо лучше, чем порча данных при split brain.
К использованию stonith надо применять немного другой подход. Он должен применяться в ситуациях, когда ресурс должен гарантированно обслуживаться или использоваться только одним сервером в кластере. Необходимость применения не зависит от конфигурации серверов, будь то виртуалки в разных ДЦ или физические машины в одной стойке.
В случае shared storage — необходимо убедиться, что ни один другой сервер не использует том (иначе крайне вероятно разрушение ФС) — в данной ситуации должен использоваться STONITH.
В случае shared ip — опять же, если два сервера подцепят один IP, будут проблемы (здесь хотя бы руками можно откатиться на рабочий вариант).
С другой стороны, если фенсинг не нужен, как правило, можно обойтись вообще без pacemaker.
На физическом железе это тоже не редкость — если моргнет сеть/дернется сетевой провод/случайно добавится правило в FW, получится split-brain. Так как раздел с базой подключается, судя по всему, через SAS, то обеим машинам ничего не помешает подмонтировать раздел на запись и начать крушить ФС.
Две машины, shared storage и
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

Данная конструкция продержится до первого split-brain, при котором она радостно рухнет вместе с WAL-логами Postgres или ФС/LVM.
Я его намеренно оставил, чтобы сразу огрести проблем на, казалось бы, синтаксически корректном примере.
C++ в такой ситуации гораздо понятнее бьет по рукам с ошибкой «redeclaration of 'int a'», но в плюсах нет оператора множественного присваивания.
Окей, я осознал всю боль. Доработал пример, чтобы все стало еще больнее play.golang.org/p/U4Xm5dDf52
Этот пример вообще дико странный, потому что является наглядной демонстрации областей видимости.
В C++ все точно также, один в один. Если ты открываешь блок { }, то значит, определяешь новую область видимости, значит, если ты определяешь новую переменную — старая не перезапишется. В чем несовершенство языка, скажите мне, пожалуйста?
Только после последних апдейтов по нему ездить невозможно. Приехать по яндекс-навигатору за время, которое он обещает, можно только в час ночи. Все стало совсем печально после последнего обновления пару дней назад.
С гуглом таких проблем нет, по пробкам он ведет гораздо лучше яндекса, но по голосовому сопровождению и интерфейсу сливает.
У стрелки длительность импульсов составляет порядка 30 нс, поэтому напрямую ее сигнал детектировать не удается.
Во всех радарах, которые обеспечивают детектирование, используется отдельная плата со своей схемотехникой.
Погуглил схему — вероятнее всего, это krankenstein.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность