>> Например, даже малейшее обновление php приводит к тому, что многие важные сайты
>> (которые писал другой отдел) перестают работать. Виноват, конечно же буду я.
> Имея за плечами 100+ серверов и тысячи сайтов, скажу, что сказаное вами
> - вранье. Обновление в рамках одной ветки, очень редко приводит к
> тому, что какой-то код перестает работать, хотя и такое бывало, но
> это исключение, а не правило.Нет, не враньё, буквально две недели назад поднял минорную (!) версию php на 3 единицы, и сразу перестал работать очень важный сайт для внутренних нужд. Я ведь не придумываю, а говорю причины за которые уже получал втык.
Меня вообще возмущает Ваше отношение. Что значит вранье? Я лгу тут по-Вашему? Или не понимаю что происходит? Вы сами то понимаете, что речь не про хостинг, где крутятся сайты, среди которых 95% какие-то CMS-ки, а о что ни есть само-кривописных монструозных сайтах, где никому не было дела до рекомендаций и warning-ов, где критически необходимо сохранять работоспособность _всего_ функционала.
>> А есть ресурсы, где просто слишком много пользователей, чтобы позволять себе _частую_
>> профилактику.
> у меня слишком много пользователей и это не мешает обновляться регулярно.
Ну, тут много проблем. Во-первых ровно та же, что и объяснялась для сайтов для внутренних нужд. Во-вторых, вам прямо _никогда_ не требуется останавливать ненадолго работу систему при обновлении, так что ли? Есть например проект федеральных масштабов. Софт там морально давно устаревший, там систему нужно обновлять весьма кардинально, о чём я неоднократно высказывал своё мнение. Но "заказчики" по этому проекту, считают, что его лучше не трогать, ибо в следующем году проект заканчивает своё существование.
Но даже если абстрагироваться об этих федеральных проектах о которых я просто не могу ничего толком конкретного говорить (ибо NDA), то можно спутиться до обычного ftp.ru.debian.org. Безопасные обновления проводить - пожалуйста, а требующие хотя бы минутной остановки сервисов пытаемся избегать насколько это возможно.
Ещё пример, давай посмотрим на yandex:
[xaionaro@imperium ~]$ telnet mirror.yandex.ru 80
[...]
<hr><center>nginx/1.1.8</center>
[...]
Что-то не похоже это на ежемесячное обновление. А знаете почему? Потому что не подвержено уязвимостям и _работает_!
>> Есть ресурсы непубличные (неглючные и невзламываемые), которые работают и трогать которые вообще не за чем.
> Распространенное заблуждение, оставим это на вашей совести.
Ну млин, есть, например, ресурс с картой коммутаторов и mrtg-шными графиками, где по IP-адресу разрешён доступ только из нашего управления + где закрыто всё что только можно и вход всё-равно по паролю. В чём заблуждение? Как я сказал, когда находится какая-то жёсткая уязвимость (которая даже такую систему подвергает опасности), то проводятся обязательные обновления (даже таких систем).
>> Есть, например, у нас расчётный кластер, где задачи считаются по несколько месяцев.
>> Там проводить профилактику раз в месяц, это значит просто убить всю
>> работу на кластере.
> Выводи из кластера, для обновления, можно не все машины разом, а по
> одной.
Вы издеваетесь? Вы вообще знаете что такое HPC? Вы понимаете к чему там приводит гетерогенность систем? Да и даже если обновлять кластер по узлам по-штучно, то всё-равно большинство узлов не будут обновляться по несколько месяцев, ибо считаемые задачи. Что приводит по сути к той схеме обновления, о которой я сказал вначале.
P.S.: По поводу первого пункта, я ради любопытства решил вспомнить с какой версии PHP на какую было обновление. Ошибся, не на 3, а на 5 отличается минорная версия — 5.4.5 VS 5.4.0. Витоге появился баг, в результате которого получил втык начальник отдела разработок, из-за чего потом получил втык я.
P.P.S.: Даже в моей предыдущей конторе (которая уже жила не на бюджетные деньги) были пример систем, которые обычно лучше не трогать. Например СУБД биллинга. Учитывая древность компании, биллинг там очень запутанный, и работает на базе большого количества пакетов, некоторые из которых писались людьми, которые давно недоступны (и исходный код тоже). И опять же, биллингом занимаются другие люди, что всё ещё сильнее усложняло. Дак вот там, насколько я помню, год потратили, чтобы перевести этот биллинг на новую версию СУБД на новом сервере с новой системой. Не стоит забывать, что там ещё СУБД проприетарная+закрытая и завязана на конкретные бинарные библиотеки. Т.е. просто обновить конкретно всю остальную систему представляет достаточно проблематичным (тем более то было на solaris, откуда очень хотелось вообще съехать), если только, конечно, не создавать отдельное локальное окружение для СУБД, что частично лишено смысла, ибо уязвимости старых библиотек будут проявлять себя через СУБД... А теперь подумайте. С данным СУБД работает только какой-то набор программ, который не менялся годами и ничего плохого не происходило. Доступ открыт только для конкретного DMZ из которого работают эти программы. Неужели Вы считаете, что подобную систему стоит обновлять чаще, чем раз в год? Меня вообще удивляет, что я это Вам рассказываю и Вы сами не в курсе про существование подобных проблем.
P.P.P.S: И вообще. Изначальной моей мыслью было то, что не каждый ресурс можно сидеть и обновлять каждый день. Намёк на то, что надо всегда всё настраивать так, чтобы и без этого подобная мелочь так не сказывалась. У меня например все сервера синхронизируются через собственный NTP-сервер, который на данный момент использует большой pool других серверов, а в скоре собираемся приделать к нему GPS и получить stratum 1. Витоге несмотря на то, что некоторые сервера не удаётся постоянно обновлять, данной атаке они не подвержены.
