Аргументация установки апдейтов на ОС

Question

[Николай Турнавиотов]

Приветствую.

Вопрос, собственно в том, как красиво и правильно аргументировать не ИТ-специалисту — клиенту, менеджеру надобность установки обновлений как на рабочие станции, так и на внутренние сервера.
Я администратор и понимаю зачем это надо, но красивых убедительных формулировок пока создать не могу — даже мой ИТ-подкованный шеф на установку апдейтов на внутренние сервера игнорирует мотивируя это правилом «работает — не трожь».
Спасибо за помощь.

Answer 1

[Iliapan]

Если вы задаете такие вопросы — вы просто адово некомпетентны. Попросите ваше руководство записать вас на курсы эникейщиков

Comments

[Николай Турнавиотов]

О моей компетентности надо судить моему работодателю и моя не-компетеность позволяет мне совместно с сотрудником поддержки поддерживать работу внутренних сетей компании, распределённых по всей стране.
Вопрос стоит именно в помощи красиво сформулировать для не технических специалистов и руководства.

Answer 2

[Archet]

А может и правда «работает — не трогай»? По крайней мере в тех случаях, когда дело не касается критичных дыр в безопасности, надежности и т.п. — в этих случаях, кстати, и аргументацию придумывать не надо.

Comments

[Николай Турнавиотов]

В нормальной инфраструктуре идет дублирование систем — один сервак обновляется и ребутается когда нагрузка спадает, второй под нагрузкой, потом повторяется на втором, но вот Exchange и SQL с 1С меня, допустим, напрягают. Но получить какуюнить бяку с клиентской машины — не особо хочется, поэтому я сторонник обновлять регулярно

Answer 3

[lair]

Ваш шеф прав.

Вы тестируете все устанавливаемые на сервера обновления на совместимость с существующим ПО? У вас Exchange никогда от апдейтов не падал так, что приходилось откатывать?

Comments

[Николай Турнавиотов]

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

[lair]

Вот именно потому, что тестировать негде, апдейты без крайней необходимости накатывать не надо.

[Николай Турнавиотов]

С другой стороны, Exchange и RRAS машинки торчат наружу, и игнорирование апдейтов на них чревато дырками в безопасности периметра. Клиентские машинки меня в данной ситуации вообще не волнуют — отрезанные права, антивирус и автоматическое обновление

[lair]

Ну так вы следите, и security critical — накатывайте.

[Николай Турнавиотов]

Вопрос, собственно и стоял — как эти даунтайны красиво аргументировать и сформалировать шефу и не ИТ професссионалам

[lair]

Очень просто: показав расчетное время даунтайма конторы в случае прорыва безопасности.

[Николай Турнавиотов]

А как его считать то? И таки что будет означать «прорыв периметра». В любом случае даунтайм сервиса равняется либо времени восстановления из бекапа — и не факт, что в бекапе все хорошо и бекап поможет, либо же полной переустановке сервера и сервисов + смена паролей

[lair]

Прорыв периметра — это, собственно, использование дырки, которую закрывает апдейт. А считать надо не даунтайм сервиса, а даунтайм конторы, потому что если вы словите, скажем, червя, то он может разползтись с сервера куда угодно.

Answer 4

[nApoBo3]

Работает не трогай это абсолютно правильно. Плюс если система находиться внутри периметра безопасности апдейты ее вообщем-то не нужны.
Если система является уязвимой, то необходима политика развертывания обновлений, которая предусматривает действия по тестированию обновлений, развертыванию и откату в случае необходимости.
Но для начала надо себе ответить на вопрос "а зачем", и не на первый вопрос по обновления, а на все остальные ответы. Только тогда станет понятно, зачем нужны обновления в данном конкретном случае.