Зажимаем права пользователя, усиливаем разрешения.
Антивирус после этого нужен только для автоматической зачистки всякой ерунды.
Хорошее решение, но после того как количество разнообразных сервисов переваливает некоторую критическую массу работа администратора превращается в постоянное ковыряние в правах и диагностику «каких прав не хватает, почему перестало работать».
ПДФ лечится очень просто — суматра пдф вьювер и никакого агробата от абобе.
Тоже решение, но опять же подходит не везде: некоторые используют специфические особенности формата, которые не реализованы/плохо реализованы в альтернативных просмотрщиках формата.
Запуск под УЗ с правами Администратора Домена уязвимых служб (распространённое явление, когда лень разбираться с выдачей прав)
Работа администратора на контроллере как на терминальном сервере (не менее распространённое явление в небольших конторах. Видел ситуации, когда администратор физически сидит и работает за DC)
Совмещение роли DC с другими ролями при экономии на оборудовании (Запросто на DC сервер 1С, RDP, MS SQL, IIS, Apache )
Работа под Администратором домена «девочки», заводящей пользователей (это уже в конторах побольше, потому, что администратору было лениво разобраться с делегированием управления)
И это не фантазии — это только то, что я реально видел.
Узкий специалист может написать одну-две-три статьи, которые будут интересны хотя бы 20% аудитории.
Позволю себе с Вами не согласиться: некоторые «мотивированные» встречей первой статьи прекращают писать, даже если в заготовках есть вторая.
В работе приходится сталкиваться и разбираться до конца с многими интересными моментами. После таких моментов материала набирается на хорошую статью.
P.S. Вы, кстати, тоже поднимали тему «узких» специалистов на Хабре ещё в 2010-м. Ваша точка зрения на проблему изменилась?
Может и так. Но при занижении общей планки аудитории неизбежно будет потеряна та ее часть, которая ориентирована на качаственный специализированный контент. Решать какая аудитория нужна — владельцу ресурса.
Просто отсутствие условий для появления качаственного специализированного контента и при этом попытки привлечь его авторов неколько сбивает с толку…
К сожалению — здесь речь не о «топе» (понятно, что узкоспециальные статьи в топ не пойдут, да они там и не нужны). Тут уже речь о выживании этих статей, когда и их процент и их количество сокращаются…
Не тот случай.
Сливают сразу при публикации статьи, так что автор не может больше писать. Но при этом если посмотреть профили агрессивно критикующих — у них в публикациях ничего, кроме перепечатанных новостей как правило нет…
Особый случай, когда начинают сливать статью, при этом в комментариях только положительные отзывы и вопросы по-существу.
Исправить ситуацию могло бы обязательное коментирование кнопки «минус» у топика что бы отдельные граждане с синдромом вахтера не минусовали просто потому что им кажется, что автор не прав. Но лишь в том случае, когда четко могут объяснить в чем именно не прав.
Второй вариант: разделение кармы по хабам: если автора слили в DIY, но при этом у него высокая карма в Системном администрировании — у него есть возможность писать и голосовать в Системном администрировании.
И в то же время у автора, заработавшего карму на обзоре телефона — нет возможности слить карму автору из хаба о программировании.
Как думаете, эти рекомендации спасут? Если, например, антивирь захочет сожрать ряд системных сервисов? А если их в исключения вписать, то уже вирь сможет их сожрать.
У Вас весьма специфичные представления о работе антивирусного ПО…
1) Обычно обновления спускают сразу, после минимального тестирования. По крайней мере такое я вижу вокруг.
2) Надо тестировать на препрод среде с идентичным patch level, что и прод. В идеале — просто склонировать имеющиеся виртуалки, развернуть в отдельном периметре. Иначе тестирование теряет смысл — свежые вирусные базы могут сожрать к примеру только вышедшие апдейты ОС или ПО.
… опять кто-то кого-то «жрёт» прям жуть…
У нас обновления от MS и новые базы антивируса тестируются на одной ферме вместе.
С момента внедрения такого тестирования (больше трёх лет прошло) был только один случай проблемы. Причина была в человеческой ошибке — не добавили в тестовый макет новую ОС.
Вероятно, надо просто дать возможность сосуществовать и тем и другим. А если человек специалист в какой то узкой области, это отнюдь не значит, что он знает всё, и вполне возможно, с большим удовольствием прочтёт популярную статью в другой тематике. Может даже стоит выделять отдельные хабы научно-популярные.
Действительно, эта тема давно избита. Но если кому-то Ваша статья может понравится, то ее все таки стоит написать
Я в общем не о своих статьях… Я вообще о тенденции. Досадно когда автор пишет интересную специализированную статью — его «забивают» в комментариях, статью минусуют — и больще от этого автора ничего не видно.
Впрочем, видимо, как здесь выше пишут — я попал не на тот ресурс.
Оказывается, люди будут делать всё что угодно ради придуманных очков в интернете.
Оказываются занятые люди отвечают не вопросы других людей не «ради каких-то очков в интернете», а ради получения обратной связи по своим идеям, мыслям наблюдениям, которыми они поделились с другими. Ради того, что в этих комментариях могут быть ценные замечания…
К сожалению, грамотно поставить задачу очень часто некому. Мы некоторые «постановки задачи» под пиво вместо анекдотов обсуждаем ;)
Тут выход один: самообразование (этому раньше учили в высших и средних учебных заведениях), самоорганизация и самоконтроль.
(Плюс развитие экстрасенсорных способностей… Шутка ;) )
У нас не один ЦОД.
Системы задублированы.
Батарей хватает для миграции на резерв.
Тушение нужно только для корректного выключения ОС серверов (для минимизации проблем при включении) и для выключения не критичных сервисов (как правило тестовые макеты), чтобы батарей на дольше хватило.
1) Алярма дежурному инженеру или админу об этом — это не штатная ситуация, сервера тушат вручную с контролем корректного завершения, а то подвисла БД при остановке и после появления питания начнутся танцы с бубном и проверка бэкапов.
Не спорю. В достаточно однородной среде, когда есть возможность обеспечить дежурство инженеров, способных грамотно выключить сервера и проконтролировать корректный останов служб — можно обойтись и без авто тушения.
Лучшее решение — решение выработанное под конкретную ситуацию с учётом местной специфики.
2) Систематическая проверка работы ДГУ с записями в журнал, кто когда и как проверял под нагрузкой, дальше вариант 1, если все же так случилось.
3) После пропадания питания у нас есть около 10 минут на старт ДГУ руками, не допускать бардака при работе с критичным оборудованием, дальше вариант 1.
То, что ДГУ должны периодически проверяться — это аксиома!
Был свидетелем случая, когда ДГУ был заглушен заправщиком (случайно нажал аварийный останов в процессе заправки бака соляркой), а дежурные инженера не смогли его запустить (после аварийного останова в контроллере остаётся блокирующая запуск ошибка, которую прежде необходимо сбросить)
Я знаю как это называется ;)
Это я к тому, что человеческий фактор нельзя исключать из расчётов.
Но в целом в Вашей конкретной ситуации вполне вероятно автоматическое выключение серверов и не нужно, т.к. эта автоматика замещена комплексом организационных мер.
Кейсы тушим скриптом очень специфичны, сегодня тушится, завтра добавили какую-то службу и уже не тушится.
надо стараться делать правильно, а не велосипеды.
Ну… как бы внесение каких либо изменений в production систему должно по-хорошему сопровождаться анализом влияния этих изменений на сопряжённые системы.
Например (грубый): если сервер тушился при остатке заряда батарей на 5 минут, а после добавления на него новой службы ему потребуется на тушение 7 минут, то стоит вместе с добавлением службы изменить порядок тушения сервера (выключать его за 10 минут до конца заряда батарей).
1) Самая большая нагрузка на все подсистемы сервера возникает в момент старта, по статистике именно в это время происходит большая часть аппаратных сбоев.
2) После перезапуска не все узлы системы могут стартовать корректно, особенно это касается распределенных систем, в это время возникает наибольшее количество программных сбоев и недочетов, особенно это касается массового выключения и включения инфраструктуры.
4) Из специфического, если мы делаем также автоматическое включение, то не предусмотрев поочередный плавный запуск всех серверов, мы получаем одномоментно очень большую нагрузку на электросеть, стабилизаторы, ONLINE UPS и т.д. не все выдерживают, понятно что надо предусматривать, но откуда системы плавного пуска у предприятий, не позволяющих себе резервирование по питанию.
Поэтому включение происходит уже в присутствии администраторов. У них есть время на проснуться и добраться до работы пока инженера устраняют проблемы с питанием, вызвавшие разрядку батарей ИБП.
3) Не все службы могут завершиться правильно при получении сигнала о выключении, некоторые могут просто не успеть — большая вероятность получения проблем с данными, особенно на больших базах и особенно реплицируемых внутри той-же выключаемой инфраструктуры.
Это уже проблемы подготовки и проектирования авто выключения серверов. В любом случае если одна из ста служб не успеет остановиться до пропадания питания — риски будут меньше чем при некорректной остановке всех ста служб по пропаданию питания.
Ответ должен быть — внедрение ДГУ, а не shutdown c сигнала upsd/nut/системы_мониторинга именно так и можете считать что угодно, ибо это организационная проблема.
Внедрения ДГУ никто не отменял (там где это оправдано здравым смыслом), но:
1) ДГУ может не запуститься
2) На ДГУ могут нажать на аварийный останов (в нормальных ДГУ он есть)
3) Электрики могут забыть переключить АВР ДГУ из ручного режима, после проведения работ
4) строители могут перебить кабель с ДГУ
5) При длительном отключении могут не успеть подвезти новую партию солярки
Так что даже наличие ДГУ в инфраструктуре не исключает ситуации, когда сервера окажутся на питании от батарей и батареи будут разряжаться, а значит всё равно необходимо подготавливать план аварийного корректного тушения серверов.
Если есть возможность обеспечить наличие 24/7 инженера, способного по необходимости корректно потушить ЦОД — можно обойтись и без автоматического выключения.
Хорошее решение, но после того как количество разнообразных сервисов переваливает некоторую критическую массу работа администратора превращается в постоянное ковыряние в правах и диагностику «каких прав не хватает, почему перестало работать».
Тоже решение, но опять же подходит не везде: некоторые используют специфические особенности формата, которые не реализованы/плохо реализованы в альтернативных просмотрщиках формата.
И это не фантазии — это только то, что я реально видел.
Позволю себе с Вами не согласиться: некоторые «мотивированные» встречей первой статьи прекращают писать, даже если в заготовках есть вторая.
В работе приходится сталкиваться и разбираться до конца с многими интересными моментами. После таких моментов материала набирается на хорошую статью.
P.S. Вы, кстати, тоже поднимали тему «узких» специалистов на Хабре ещё в 2010-м. Ваша точка зрения на проблему изменилась?
Просто отсутствие условий для появления качаственного специализированного контента и при этом попытки привлечь его авторов неколько сбивает с толку…
Сливают сразу при публикации статьи, так что автор не может больше писать. Но при этом если посмотреть профили агрессивно критикующих — у них в публикациях ничего, кроме перепечатанных новостей как правило нет…
Особый случай, когда начинают сливать статью, при этом в комментариях только положительные отзывы и вопросы по-существу.
Второй вариант: разделение кармы по хабам: если автора слили в DIY, но при этом у него высокая карма в Системном администрировании — у него есть возможность писать и голосовать в Системном администрировании.
И в то же время у автора, заработавшего карму на обзоре телефона — нет возможности слить карму автору из хаба о программировании.
У Вас весьма специфичные представления о работе антивирусного ПО…
… опять кто-то кого-то «жрёт» прям жуть…
У нас обновления от MS и новые базы антивируса тестируются на одной ферме вместе.
С момента внедрения такого тестирования (больше трёх лет прошло) был только один случай проблемы. Причина была в человеческой ошибке — не добавили в тестовый макет новую ОС.
Я, как бы, об этом и написал…
Я в общем не о своих статьях… Я вообще о тенденции. Досадно когда автор пишет интересную специализированную статью — его «забивают» в комментариях, статью минусуют — и больще от этого автора ничего не видно.
Впрочем, видимо, как здесь выше пишут — я попал не на тот ресурс.
Оказываются занятые люди отвечают не вопросы других людей не «ради каких-то очков в интернете», а ради получения обратной связи по своим идеям, мыслям наблюдениям, которыми они поделились с другими. Ради того, что в этих комментариях могут быть ценные замечания…
К сожалению, грамотно поставить задачу очень часто некому. Мы некоторые «постановки задачи» под пиво вместо анекдотов обсуждаем ;)
Тут выход один: самообразование (этому раньше учили в высших и средних учебных заведениях), самоорганизация и самоконтроль.
(Плюс развитие экстрасенсорных способностей… Шутка ;) )
Системы задублированы.
Батарей хватает для миграции на резерв.
Тушение нужно только для корректного выключения ОС серверов (для минимизации проблем при включении) и для выключения не критичных сервисов (как правило тестовые макеты), чтобы батарей на дольше хватило.
Не спорю. В достаточно однородной среде, когда есть возможность обеспечить дежурство инженеров, способных грамотно выключить сервера и проконтролировать корректный останов служб — можно обойтись и без авто тушения.
Лучшее решение — решение выработанное под конкретную ситуацию с учётом местной специфики.
То, что ДГУ должны периодически проверяться — это аксиома!
Был свидетелем случая, когда ДГУ был заглушен заправщиком (случайно нажал аварийный останов в процессе заправки бака соляркой), а дежурные инженера не смогли его запустить (после аварийного останова в контроллере остаётся блокирующая запуск ошибка, которую прежде необходимо сбросить)
Я знаю как это называется ;)
Это я к тому, что человеческий фактор нельзя исключать из расчётов.
Но в целом в Вашей конкретной ситуации вполне вероятно автоматическое выключение серверов и не нужно, т.к. эта автоматика замещена комплексом организационных мер.
Ну… как бы внесение каких либо изменений в production систему должно по-хорошему сопровождаться анализом влияния этих изменений на сопряжённые системы.
Например (грубый): если сервер тушился при остатке заряда батарей на 5 минут, а после добавления на него новой службы ему потребуется на тушение 7 минут, то стоит вместе с добавлением службы изменить порядок тушения сервера (выключать его за 10 минут до конца заряда батарей).
Поэтому включение происходит уже в присутствии администраторов. У них есть время на проснуться и добраться до работы пока инженера устраняют проблемы с питанием, вызвавшие разрядку батарей ИБП.
Это уже проблемы подготовки и проектирования авто выключения серверов. В любом случае если одна из ста служб не успеет остановиться до пропадания питания — риски будут меньше чем при некорректной остановке всех ста служб по пропаданию питания.
Внедрения ДГУ никто не отменял (там где это оправдано здравым смыслом), но:
1) ДГУ может не запуститься
2) На ДГУ могут нажать на аварийный останов (в нормальных ДГУ он есть)
3) Электрики могут забыть переключить АВР ДГУ из ручного режима, после проведения работ
4) строители могут перебить кабель с ДГУ
5) При длительном отключении могут не успеть подвезти новую партию солярки
Так что даже наличие ДГУ в инфраструктуре не исключает ситуации, когда сервера окажутся на питании от батарей и батареи будут разряжаться, а значит всё равно необходимо подготавливать план аварийного корректного тушения серверов.
Если есть возможность обеспечить наличие 24/7 инженера, способного по необходимости корректно потушить ЦОД — можно обойтись и без автоматического выключения.