问题描述
我经常登录生产Web /db /tools框，并看到典型的消息：
可以更新30个软件包。 16个更新是安全更新。
我的问题是，你们所有人如何处理生产Ubuntu机器上的更新？您会自动执行这些更新吗？您为他们设置停机时间吗？问题是，您永远不知道更新何时会破坏某些内容，例如现有的配置文件等。
这个问题的另一部分是，与补丁保持同步是“一件好事”，但是补丁几乎每天都会发布。如果每天都有新的安全补丁可用，则必须进行多少次计划内停机？
我认为回答有关如何管理更新的线程将非常有用。
最佳思路
修补Ubuntu与Windows，RHEL，CentOS，SuSE，debian等补丁并没有什么特别的。
设计补丁程序时，您需要保持的基本心态是假设某些东西会损坏。
在设计补丁程序设置时，我倾向于使用一些基本准则：
-
始终使用本地系统在内部集中安装补丁程序的网络
这可能包括使用WSUS或<your_os_here>的镜像到内部补丁程序管理计算机。最好是可以集中查询并让您知道各个计算机上安装的修补程序状态的软件。
-
在机器上尽可能进行预安装。
在可能的情况下，随着补丁的出现，中央服务器将它们复制到单独的计算机上。这实际上只是节省时间，因此您不必等待他们下载并安装，只需在补丁程序窗口中开始安装即可。
-
获取中断窗口以安装修补程序，您可能必须重新启动，并且可能会损坏某些内容。确保这些系统的利益相关者知道有正在部署的补丁程序。为”this”不起作用的电话做好准备。
按照我的基本理论，即补丁会破坏性能，请确保您有一个停机窗口，可以应用补丁足够长的时间来解决关键问题，甚至可能回滚补丁。您不需要一定要让人们坐在补丁后进行测试。我个人非常依赖我的监视系统，让我知道一切都在我们可以逃脱的最低限度的水平上运行。但也要做好准备，以防人们上班时遇到一些小麻烦。您应该总是安排一个人在那里准备接听电话-最好不要等到凌晨3点为盒子打补丁的那个人。
-
尽可能自动化
像IT中的其他所有内容一样，脚本，脚本再编写更多脚本。脚本脚本包下载，安装开始，镜像。基本上，您希望将拼装窗口变成婴儿看护任务，以防万一事情破裂了。
-
每月有多个窗口
如果由于某种原因无法在“指定的夜晚”对某些服务器进行修补，则可以不对某些服务器进行修补。如果您无法在晚上1进行操作，则要求它们在晚上2空闲。另外，还可以使同时打补丁的服务器数量保持理智。
最重要的是紧跟补丁！如果don’t you’ll发现自己必须做10个小时以上的大型补丁程序窗口才能回到被困的地步。在可能出现问题的地方引入更多点，并使得造成问题的补丁更加复杂。
The other part of this problem is, keeping up with patches is ‘a good thing’, but patches are released almost daily. How many scheduled outages does one have to make if there is a new security patch available every single day?
恕我直言，每月一次或每隔一个月对服务器打补丁是一个非常可实现且可以接受的目标。不仅如此，而且您将不断为服务器打补丁，而更少的话，您将开始遇到需要为每个服务器应用数百个补丁的情况。
至于一个月需要多少个窗户？这取决于您的环境。您有几台服务器？您的服务器所需的正常运行时间是多少？
较小的9×5环境可能每个月只有一个补丁程序窗口就可以摆脱。大型24×7的商店可能需要两个。大型24x7x365每周可能需要滚动窗口，才能每周修补一组不同的服务器。
找到适合您和您的环境的频率。
要记住的一件事是，达到100％的最新状态是不可能实现的目标-请勿让您的安全部门告诉您。尽力而为，不要落在后面。
次佳思路
要做的事情：
-
备份
-
确保它是可还原的备份(尽管这是两个基本要点)
-
升级时，尝试将流量从生产包装箱中引开。
-
万一出了错，请尝试使用out-of-band访问方法，KVM，串行控制台，本地访问或remote-hands。
-
在将更新部署到更多服务器上之前，在一台服务器上进行测试，然后确保一切正常
-
如果可以确保多个服务器上的版本号相同，请使用puppet。 (您也可以使用它来强制升级)
-
在测试服务器上，将配置文件的版本与新的(已安装更新的)配置文件进行比较，并确保不会严重破坏配置文件。我似乎记得dpkg在安装不同于当前安装的新版本之前询问。
避免的事情：
-
在一天当中或周一早上09:00或星期五下午5pm进行更新！ (感谢@ 3influence！)
-
在大型数据库服务器上升级MySQL(重新启动可能需要很长时间)
-
一次处理所有服务器(尤其是内核)
-
做任何可能改变/etc /networks的事情(因为可能会失去连接)
-
无需您检查所有内容即可进行上述操作的自动更新也可以。
第三种思路
值得一提的另一点是：如果您习惯使用Windows，您会惊讶于大多数Linux更新不需要停机或重新启动。有些功能，例如内核更新。但是，通常需要将此类更新标记为需要重启或停机，并且可以按单独的时间表进行处理。
第四种思路
我们的Ubuntu计算机都运行LTS版本。
我们只是自动安装所有更新-确保它不是”best practice”，但是我们是一家相对较小的商店，没有针对每个服务的测试/开发/生产环境。 LTS更新通常都经过了很好的测试，并且无论如何都是微创的。
升级到新版本显然要花更多的时间。