本次勒索病毒事件可谓是影响之广，规模之大，是近年来为数不多的病毒事件。这件事慢慢的在淡出人们的视野，但是本次事件带给我们的思考却非常深远。我们都知道，现在的IT可以说就是软件的天下，没有软件，诸多想法就得不到实现。但我们还要从另一个方面考虑，是软件就会有bug，如果被坏人利用了，那影响可想而知。当然软件不是我们编写的，我们决定不了代码的质量和成熟度。但是我们可以从运维的一个层面考虑问题：补丁管理

本次活动得到了得到了社区会员的广泛参与，大家积极讨论了目前在补丁管理这一块的企业现状和管理方式，深入讨论了企业如何更进一步在补丁管理方面加强：补丁更新的工具选择，补丁的更新基线，策略，周期以及在更新的异常处理。

本次活动主要涉及OS补丁管理相关工组，至于业务系统补丁管理工作，后期再针对讨论。

1．概念

补丁是什么，来自百科的解释：
补丁是指衣服、被褥上为遮掩破洞而钉补上的小布块。现在也指对于大型软件系统(如微软操作系统)在使用过程中暴露的问题（一般由黑客或病毒设计者发现）而发布的解决问题的小程序。就像衣服烂了就要打补丁一样，人编写程序不可能十全十美的，所以软件也免不了会出现BUG，而补丁是专门修复这些BUG做的因为原来发布的软件存在缺陷，发现之后另外编制一个小程序使其完善，这种小程序俗称补丁。

2. 补丁更新现状

补丁在系统软件运行的工作当中如此的重要，是不是我们现在的企业在实际运行中都能够严格的及时更新补丁呢? 下面我们介绍一下目前有关补丁更新方面的主要的几类情况：

• 裸奔或者说几乎是裸奔
• 偶尔更新一次或者遇到重大补丁问题集中更新一次
• 只是更新与安全有关的补丁
• 更新内核补丁
• 更新所有的补丁

上面的是简单的分类，至于在企业内部真正执行的情况也不是完全按照一个标准和分类去执行的。企业的管理员大多数认为为系统打安全补丁还是需要的，是应该做到的工作；而对内核或系统升级，则一般是在有业务需求的时候才进行的。不过，即使仅仅是给系统打安全补丁，也没有那么简单，无论是Linux、Windows还是Unix，都有仅仅是打安全补丁就造成系统重启不正常的情况出现过。再到了系统需要升级的情况，也往往不仅仅是OS或应用升级那么简单。

3. 更新策略

企业要提高IT 架构的效率、安全性和对业务的贡献率，就必须首先解决补丁升级过程中的诸多问题。这些问题的解决都指向一点：制定并实施理想的补丁管理策略

这里引用几个社区会员有关补丁更新的策略与考虑：

会员A：

1.监控
2.检查与评估
3.风险评估与测试
4.告示及时间表
5.部署
6.审核，评估以及验证
Windows建议你使用Windows Updates Downloader，该软件能给微软的所有产品快速地打补丁，一次即可将需要的各种补丁全部载下来，而且还能让你选择安装某个特定的补丁。
linux建议使用APT,APT使得零停机时间升级成为现实。使用Connectiva进行改装后的Debian的apt软件包管理工具，它可以对Red Hat的RPM格式进行管理。它可以为持续的安全升级提供一个非常好的机制。可以定时更新系统软件，弥补网络和系统的安全漏洞。Linux服务器运行的软件主要包括：Samba，Ftp，Telnet，Ssh，Mysql，Php，Apache，Mozilla等，这些软件，大都是开源软件，而且都在不停升级，稳定版和测试版交替出现

会员B：

通過這次事件，我們也是重新思考的打補丁問題。由於我們有很多域外的機器，所以使用sccm去推送補丁部署上有一定麻煩，但是單純通過wsus服務器配置自動更新又無法控制客戶端的更新頻率和重啓情況，服務器倒是還好辦，如果用戶的終端機就比較麻煩。
後來經過思考，決定寫了一個非常小的程序目的就是調用winapi去運行windowsupdate，然後通過zabbix和wsus配合去監控補丁的更新情況，並且也是通過zabbix遠程發送命令下去開始執行更新。不知道最終實際效果怎麼樣，正在測試中

会员C：

操作系统的补丁更新，最大的问题是对生产的影响较大，例如，内核的更新、glibc、openssl的更新都需要重启服务器，这就会带来业务停机（大家不要跟我讨论互联网的分布式架构，传统企业中大部分业务系统还是单机或者HA模式在跑，再说了，就算是分布式架构，你试试所有服务器都重启一遍啥感受）。而一个关键的漏洞，例如脏牛、心脏滴血，都是需要更新这些包的。
就是这个原因，我们经常看到在很多客户机房里，2015、2016年的关键补丁迄今还没有进行更新，这样系统风险还是很大的，特别是对公众提供服务的服务器。
所以，近几年，LInux的内核热补丁技术开始发展，例如Oracle Linux的KSplice，Red Hat Enterprise Linux的KPatch。 这些都可以不重启便给内核的运行态进行升级。
相比来说，Oracle Linux的 KSplice年头比较长，比较稳定，并且，和其他相比的最大优势就是，ksplice还能提供针对用户态关键程序的热补丁，例如我们所说到的openssl，只有ksplice才能实现热补丁。其他的目前还不可以。

针对以上情况和会员的实际工作当中的补丁管理策略基本上可以得到一下几个方面的内容：
（1）补丁是否需要安装
这个问题不能一概而论，尤其是对内提供服务，安全措施相对完善，系统和应用几乎不变的情况看下，不联外网的环境或者更新一次风险很大的老系统，不更新不升级不失为一种稳妥的办法，其他环境还是建议进行相关升级。
（2）更新的方式选择
对于大企业和小企业，补丁更新的方式是基本上认为是完全不同的，小企业由于没有技术储备，企业可能选择云的方式或者少量设备的场景，为了稳妥起见，打开自动升级定期更新就好，然而对于大企业来说这种方式往往是不可接受的，大企业都选择性的进行更新，更新选择更为细致和贴合企业需求。
（3）更新的频率
更新周期的大多回收补丁更新的周期和业务场景的限制，有一定规模的企业在业务是否繁忙，是否需要重启，更新时间窗口，每次更新内容大小，以及重要更新重要程度几个方面做参考制定最适合企业自身的策略。
（4） 更新工具的选择
对自动化程度要求较高的企业大多对会选择自成型产品或工具配合系统独有的补丁安装工具，批量灵活部署补丁，对于中小企业大多会采用一款产品进行综合的补丁管理，但是时候由于产品兼容性或灵活性的方面会选择1,到2种工具配合完成综合部署。。
比如很多中小企业选择使用360作为补丁管理工具来管理windows服务器，简单高效。

（5）基础设施支持
对于打补丁异常问题，大企业往往有比较完善的基础平台环境支撑，能够在应用高可用，设备冗余和者恢复重建方面相对其他企业做的充分，从而消除和减小由于异常所带来的影响。

每个企业的情况都有自己的特点，根据实际情况进行相关策略的设定和执行，但是可以参考同类行业的执行标准和相应的补丁管理流程。

4. 工具选择

针对企业当中众多的操作系统版本，补丁管理工具的选择是否合适再很大程度上影响着补丁管理和更新的效果，那么下面我们就针对目前市场上主流的补丁更新解决方案进行一个梳理。
这里我们按操作系统来进行梳理，其中包括了商业产品或系统独有的补丁更新方法。

同时我们在这里也介绍一些商业和开源产品：sccm，360，ibm endpoint mt，KPatch ，KSplice ，ansible，puppet，也有配合脚本完成的补丁更新等
我们的会员在补丁管理方面分享了很多工具，并且突出强调了在补丁管理当中应该关注的几点。

• 补丁筛选 那些补丁要打，那些不用打，而不是直接yum update。
• 风险分级
• 提前测试
• 验证
• 补丁信息库和自动补丁检查(这一点也是最重要的一点，就是补丁信息库的建设和定期检查)

有关最后一点的解释：
先说补丁信息库，我们在企业中linux的版本可能有很多，例如Oracle 6.3 Oracle 7.2 Oracle 6.8，这个通常来说叫做“基线”，那么我们在做完补丁筛选后，需要清晰的知道，针对每一个基线，需要打的补丁时什么，举例来说，可能是下面的一个表格：

这样，每当有新部署系统的时候，就可以通过这张表知道，都有哪些补丁要打。然后就是补丁检查，要基于这张表经常性的对系统中的所有系统进行补丁检查，这也是很重要的一个环节，吹牛逼的说法是，这是DevOps理念中的“操作闭环”

这些几点在补丁管理方面有很重要的指导意义。

5. 补丁更新构想

通过对补丁管理的现状了解和目前企业当中实际补丁管理执行效果来看，我们的会员对未来有关补丁管理和更新的几点想法，希望能够让补丁管理更加便捷高效,下面主要是描述一下社区会员针对这方面的考虑：

以后的补丁或者说是系统的应用方式可不可以像DOCKER那种类型呢。硬件上的平台类似虚拟化一样。，在这至上的系统层，应用层类似DOCKER，每次更新补丁都在现有的环境基础上产生新的DOCKER或者说快照，缘由的环境不便，新环境没有问题。则可以删除旧的DOCKER。如果新环境有问题。则旧环境保持不变

补丁是什么，说到底还是为了弥补以前的缺陷和不足。那么，这么想，补丁就是不可避免的，因为编程永远考虑的不会全面。
参考解决方案：

1. 流程
2. 技术
   分布式和可插拔应该是未来的主流，通过流程控制补丁逐步安装。尤其是在linux 4.0 内核以后，redhat和suses 已经有相应的不停机安装内核补丁的能力，但是还不是全面支持，随着技术的发展，安装补丁真的可能不用熬夜重启了。

更新迭代
现在虚拟化管理技术都支持快照或者克隆，可以把虚拟机转换成IMAGE或者模板，然后用这个东西去部署新的虚拟机，在新的虚拟机中进行补丁更新，并投入生产，如果打补丁失败，立即启用原虚拟机，升级成功，则等稳定运行一段时间之后，将原虚拟机删除。不断这样更新迭代下去。

升级规划考虑
1 风险分级 操作系统打补丁的时候，对应用的影响，会因为应用系统的类型有大有小，例如，JAVA应用几乎无影响，但C程序影响较大，Oracle DB的话，需要同时升级asm等等。做了风险分级后，就能够有个大概的预判
2 升级内容确定 Linux中不是所有的补丁都要打的，主要就是更新内核、glibc、openssl等核心补丁即可，所以，根据所公布的CVE信息，筛选出“必须要更新的补丁”。
3 升级测试 针对风险分级为高的系统，提前进行补丁测试
4采用快照等手段时间回滚,有些包升级后，很难回滚，所以，如果是虚拟机，可以做个快照然后升级。

总结：
我们的运维管理人员一直在思考如何从流程和技术两个主要的方面，在未来不久的时间里能够灵活自如的进行补丁的更新管理操作，远离加班，远离异常。

6. 企业补丁管理经验分享
   这里我就不说企业的名字了，下面我主要来解释一下该企业在OS补丁管理方面是如何做的。

企业现状

服务器数量将近800-900台。

Ubuntu: 约400台
Suse：约200台
Redhat：约30台
Windows：100多台

补丁存放

由于该企业设备数量总多，同时在线安装补丁网络几乎就是灾难，所以企业内部分别针对ubuntu，suse和widows 均架设内部源，内部源和官方源定期的同步，主要同步的与安全相关的补丁，当然也有内核方面的补丁。

补丁监控

该企业的运维小组每周都会关注的企业使用操作系统各个版本的补丁更新，涉及到对系统安全和内核管理方面的补丁对会相对比较重视，使用漏洞扫描攻击定期的不同网段进行漏扫，根据实际情况进行相关的测试评估工作，后期制定生产环境补丁更新的具体策略。

更新策略

前期：
由于企业在补丁更新方面也走过不少弯路，以前由于每次更新的内容很多，包括内核与安全等其他方面的补丁，造成了很多时候更新完毕后系统异常，导致很多次熬夜加班处理问题。
真是让人痛苦难当。

后期：
企业吸取了很多经验教训，慢慢地补丁更新策略主要是以安全方面的补丁为主，除非当内核补丁到一定级别时才考虑一起更新，每次更新补丁大小在百兆左右，每个月更新一次，总体更新计划相对平稳，没有了那么多异常现象。也不再用吐血加班处理问题。

后期策略主要表现几个方面：
1.主要更新与安全有关的补丁
2.更新周期稳定
3.每次更新内容不太大，异常现象不多
4.更新前做相关测试评估
5.协调业务窗口，更新分为重启或不重启操作，对业务影响较小

异常处理

补丁更新谁也保不齐会出异常现象，由于企业技术储备比较厚实，基本上可以解决绝大多数问题，对于个别问题，由于在和业务商定既定时间内不能完成的现象，企业会选择安装使用网络安装或快照等方式快速恢复系统，业务应用安装固定模板快速的恢复业务。这个对基础设施要求的比较高。需要企业内能够有这种能力支撑快速的恢复或重建方案。这种环境因企业而异。

关注点：

1.企业技术储备和异常处理能力
2.企业可以快速恢复的基础平台环境支持：如网络安装，快照功能，模板制定等
3.业务应用配置的流程自动化，能够在短时间内恢复业务能力

更新工具选择

企业初期选择一个统一平台安装补丁工具，由于对几个版本的支持的力度不是很好，后期企业针对不同的系统选择了不同的更新工具，配合ansible 完成补丁更新工作 。下面介绍一下针对不同系统选择的工作
Suse: zipper
Redhat:yum
Ubuntu: apt-get
Windows:sccm

总结 ：该企业只从选择了这种补丁管理和更新方式，总体运行平稳，效果良好 。

再次感谢社区会员积极参与交流分享经验！！！