网站运维

网站运维之道

 

关于可用性

什么是网站运维(Web operations) ？运维，绝不是某些人眼中安装系统、做几根网线那么简单? 除去应用开发和业务运营之外的保障网站能运转的事儿都可能是运维工作的职责范围。运维的工作包括(但不限于) 软硬件部署、网络管理、应用程序维护、安全、容量规划、故障修复等等。

运维，有别于"运营"。在中文的语境中，运营更多和业务结合在一起的。而运维，则是偏向技术层面。

任何一个成功的站点都离不开一只优秀的运维团队，尽管他们更多时候隐身在网站背后不为人知。

网站可用性

所谓网站可用性(availability)也即网站正常运行时间的百分比，这是每个运营团队最主要的 KPI (Key Performance Indicators ，关键业绩指标)。对于 Web 站点来说，传统的那个 24x7 的说法已经不是很适用了，现在业界更倾向用 N 个9 来量化可用性， 最常说的就是类似 "4个9(也就是99.99%)" 的可用性。看一下表 1 能更为直观一些。

描述         通俗叫法         可用性级别     年度停机时间

基本可用性     2个9       99%             87.6小时

较高可用性     3个9       99.9%          8.8小时

具有故障自动恢复能力的可用性         4个9       99.99%     53分钟

极高可用性     5个9       99.999%  5分钟

根据墨菲定理的推论，世界上没有 100% 可靠的 Web站点(除非不运行)。业界网站的可用性都是多少？引人注目的 Web 新贵 Twitter (http://twitter.com)， 2008 年前四个月的可用性只有 98.72%，有 37小时 16分钟不能提供服务，连2个9 都达不到，甚至还没达到"基本可用"状态。电子商务巨头 eBay 2007 年的可用性是 99.94%，考虑到 eBay 站点的规模与应用的复杂程度，这是个很不错可用性指标了。Web 应用类型决定了不同的站点对可用性的依赖性是不同的。 要知道 4 个 9 的可用性实际上是很难实现的目标。至于 5 个9 的 Web 站点，一半靠内功，另一半恐怕是要靠点运气。

多数情况下，网站可用性会是 SLA （Service Level Agreement, 服务水平协议) 中的一个重要度量指标，也是运维团队向自己的客户(更多是公司老板)的正式承诺。可用性是能够持续改进的东西，KPI 制定者切不可狮子大开口，企图一步登天，拍拍脑袋提一些不太切实的指标。运维团队对可用性的承诺也不能开些空头支票，到头来两头难看。值得强调的是，如果是做第三方托管，更需要明确 SLA，明了第三方的服务能力，否则，费尽了九牛二虎之力终于保证了软硬件网络等环节都没问题了，IDC 却频繁断电或者IDC 出口网络不可用，这也绝对做不到预期的高可用性。

提高可用性的一些常规策略有消除单点，部署冗余设备(或集群)，配置带外管理网络等，对可用性要求不高的网站这些可能足够了。如果要提供更高的可用性，比如 4 个 9 甚至 5 个9，就不是简单靠硬件就能做到的事情，还需要建立完善的流程制度、建立变更机制、提升事故响应速度等。正所谓是"没有最高可用，只有更高可用性"。

一般来说，所有的网站运维人员都在追求网站的更高级别的高可用性，但是必须注意，这是以额外的软硬件投入、更多的人力成本为代价的。成本与可用性之间也请做到良好的平衡，盲目追求高可用性是不可取的。

(补充：Twitter 的可用性现在已经有了很大提升，但是可以看到，可用性不佳并非一个网站的杀手，只要产品对用户足够友好，足够有粘度，足够不可或缺，那么可用性并非是第一要追求的运维目标。有些运维人员被 Amazon 的某年圣诞节期间宕机所造成的影响埋下心理阴影，其实没那么可怕，如果真的觉得可怕，那么你可能被一些厂商销售人员洗脑了。)

 

网站运维之道监控与报警机制

监控机制

定义了网站可用性指标，如何获取网站的可用值?监控工具该粉墨登场了。

多数网站都会倾向于利用开源软件自行搭建监控平台。笔者一向认为，即使网站有一台服务器，也应该搭建监控工具，这是保障网站能持续改进的基石。常见的开源监控工具有Nagios（www.nagios.org）、monit（www.tildeslash.com/monit）等。Nagios也可能是当前国内最被广泛采用的监控软件了，根据官方描述，Nagios是开源的主机、网络、服务监控程序，从这个描述能看出，Nagios的设计目标是很庞大的。依赖其强大的扩展性，通过分布式监控模式，管理上千台甚至更多的服务器也不在话下。而对于大型集群环境，Ganglia (http://ganglia.info/)是个不错的选择。

另外商业化运作的比较好的开源监控工具或框架还有 Zenoss (http://www.zenoss.com/)、Zabbix(http://www.zabbix.com/)、Hyperic (http://www.hyperic.com/)、OpenNMS(http://opennms.org/)等。这几个的定位都是"企业级"监控平台。当然，功能的确不比 Nagios差，也有的弥补了 Nagios的一些不足之处(比如 Zenoss增强了对 Windows服务器的监控能力)。但出于种种原因，在国内的流行程度并不广泛。

(图2: Nagios分布监控示意图

图片来源: http://nagios.sourceforge.net/docs/3_0/images/distributed.png)

如果要满足日趋灵活的 Web 监控需要就不得不提 Nagios 灵活的插件机制，最简单只需要几行 Shell代码就能实现基本的插件功能。多数情况下，脚本捕获系统日志中的特定事件，通过 NSCA Client发送给中心监控服务器即可。灵活性是衡量监控软件的一个重要标准，从这一点说，多数传统的商业网管软件怕是都不如 Nagios这样胜任现在日趋复杂的网站环境。

提到网管监控，必然要谈到 SNMP。跨平台或者针对专有设备的监控离不开SNMP，但有的时候 SNMP的安全性也的确会带来严重问题。这就需要运维团队中的安全专家对监控系统机制的安全性做整体评估，或是提升运维团队的安全意识以避免在监控过程中引入更多的安全问题。

有些公司的运维团队喜欢自己写监控工具而不是利用已有的第三方开源工具。这种重复发明轮子的做法笔者认为是不可取的。这样做最明显的一个缺点是软件本身的维护成本可能会更高，而且团队人员变动的时候后续代码维护也是个潜在的问题。至于商业工具的选择，这里不作评价。

报警机制

光有监控而报警机制跟不上，不能及时把紧急情况下的信息传递给运维技术人员，那么监控形同虚设。现在报警信息发送途径主要有邮件、IM<