Обновление хостов с прикладом: альтернативное мнение. Пришёл комментарий от подписчика к VM-ной задачке про 2 подразделения и обновление хостов с развёрнутыми приложениями. С любезного разрешения выкладываю текст полностью. 🙂
"Имея опыт работы с обоих сторон ("общей инфры" и админа приклада — как раз того самого Postgres), хотел бы заметить следующее. Всё же обновлением ОС должна заниматься команда, которая заведует ОС и обще-инфраструктурными сервисами, крутящимися на хостах. А админы прикладного ПО — должны следить за своим ПО.
Но все вместе они — должны согласовывать свои действия.
На хосте, помимо условного постгреса, может крутиться много всякого другого. О чём "прикладные админы" могут знать, но не факт, что могут этим грамотно управлять и правильно оценить последствия обновления пакетов. Пример навскидку — на хосте наверняка будут установлены агенты систем мониторинга — как ИТ-шного, так и ИБ-шного. И передать на админов условного постгреса ответственность за обновление хоста со всем этим набором… А "прикладники" точно должны этим заниматься? 😊 Тогда как мимо линуксовых админов установка, настройка и эксплуатация всех этих дополнительных сервисов на хостах с прикладом точно не пройдёт.
По опыту банка, в котором я работал — хосты обновляли линуксовые админы, а "прикладные" — только тот приклад, который в их зоне ответственности. Пакеты, относящиеся к прикладу, ставились на hold сразу при установке приклада, и их обновление было невозможно при обновлении хоста.
Ну и само собой, обновления сначала выполнялись на тестовых средах, чтобы понять, не приедут ли какие-то обновы зависимостей, которые могут сломать приклад. Если не приедут — хост смело обновлялся отдельно, а приклад — отдельно. Если зависимости ломали приклад — либо пакеты зависимостей дополнительно замораживались, либо, если это ломало остальное обновление — обновление откладывалось до ̶л̶у̶ч̶ш̶и̶х̶ ̶в̶р̶е̶м̶ё̶н̶ тех пор, пока приклад не сможет это поддержать. В тестировании, само собой, участвовали обе команды — и "хостовая" и "прикладная". Но на проде, при использовании этой схемы, их работы по обновлению, по большей части происходили независимо."
У такой схемы, безусловно, есть свои преимущества. И она весьма удобна админам, т.к. они занимаются профильными задачками, а непонятной им фигнёй не заморачиваются. Но вот VM-щику такая совместная работа и размытие ответственности невыгодны, т.к. ему придётся частенько "тыкать палочкой" две (а возможно и более) команды, которые будут показывать друг на друга. 😑 Критичные уязвимости не будут устраняться с формулировкой "обновление отложено". А кто будет нести ответственность в случае, если уязвимость будет проэксплуатирована в течение этого "отложенного" периода непонятно. Видимо предполагается, что нести ответственность будет сам VM-щик. 😏 Так что VM-щикам топить за такую схему я бы не советовал.
Но если в организации такая схема устоялась и успешно работает, то рушить её, естественно, тоже не следует. Следует аккуратненько описывать регламенты решения спорных вопросов, чтобы всегда был однозначный крайний, на которого будет направлен пушинг. Ну и кары в случае инцидента.
В любом случае, главное, чтобы обновления ставились и уязвимости устранялись (желательно с соблюдением SLA). А как именно это происходит и чьими силами не так уж важно. 😉