Я управляю примерно 20 серверами, многие из них виртуальные. Почти все они разного назначения, и ни одна из них не сгруппирована. У меня есть распределенный стек LAMP, несколько серверов приложений, несколько серверов сборки, несколько хостов KVM. Это CentOS 6.3 в основном с небольшим количеством Ubuntu (к сожалению). У меня нет ресурсов для настройки промежуточной среды, в которой я могу иметь дубликаты моих компьютеров и тестировать обновления перед их развертыванием. Беру резервные копии файлов. Я хочу знать, как вы подходите к резервному копированию своих систем Linux. Я предполагаю, что вы не просто обновляете yum, но как тогда вы выбираете пакеты, которые стоит обновить? Когда (если когда-либо) вы обновляете ядро и т. Д. Как вы тестируете обновления без промежуточной среды? Снимок и надежда на лучшее?
Это довольно часто встречается на серверах, домашние животные, а не домашний скот.
Если вы действительно не можете тестировать обновления, вы:
yum history undo).Я предполагаю, что вы не знали, что можете отменить обновления с помощью одной команды. Проверить yum страницу руководства и прочтите ее history раздел, чтобы узнать, что еще вы можете с ним сделать. Например, вам не нужно отменять обновления в том порядке, в котором вы их применили.
И перестань так волноваться. Большинство обновлений устраняют проблемы, которые необходимо исправить; введение новых проблем встречается гораздо реже (хотя может и случается).
Есть плагин безопасности yum (yum install yum-plugin-security), который выбирает только обновления, связанные с безопасностью. Теоретически это меньший риск, чем обновления, которые исправляют другие ошибки и / или добавляют функции. Затем просто обновите свои другие пакеты по мере необходимости, чтобы исправить любые обнаруженные вами ошибки или любые новые функции, которыми вы должны воспользоваться.
На самом деле, нет другого способа быть уверенным, кроме как с помощью тестовой среды и хорошего набора тестов. Ни одно программное обеспечение не лишено ошибок, все разработчики могут совершать человеческие ошибки, даже Red Hat ошибается и время от времени вносит регрессии в кодовую базу EL.
Без тестовой среды это, вероятно, не случай «если» вы столкнетесь с проблемой, которая влияет на способность вашего бизнеса получать доход с этими серверами, а «когда». Не обязательно из обновлений, просто потому, что каждая мелочь, которую вы делаете, делается в прямом эфире на продукте.
Что, если вас как администратора попросят реализовать что-то, чего вы никогда раньше не делали? Как узнать об этом и убедиться, что он работает должным образом, перед тем, как развернуть? Судя по тому, что вы говорите, вы не можете.
Сделайте бизнес-аргумент для своего босса. Рассчитайте влияние на бизнес (т. Е. Потерю дохода) из-за того, что все ваши системы будут недоступны на время, необходимое вам для полного восстановления среды с нуля и восстановления данных из резервной копии.
Если эта потеря дохода дешевле, чем затраты на создание промежуточной среды, то у вас есть хорошее экономическое обоснование для создания такой среды. В таком случае правильная постановка и тестирование становятся не расходами или инвестициями, а удивительно дешевым страховым полисом.