运维工作与持续进阶

最近在总结2010年来的公司的运维进展，顺便拜读了冯大辉 前辈关于网站运维方面的文章。运维是对当前互联网中一个较为特殊的领域(其实每个领域都有特殊的地方)，套用前辈的话就是“运维的工作包括(但不限于) 软硬件部署、网络管理、应用程序维护、安全、容量规划、故障修复等等 ”。可能有人觉得和传统的公司IT管理员没啥区别，其实最大的区别就是你面临的用户群体不同，数量不同，服务质量的等级不同。所以，若想做好运维工作，对涉及的领域要尽可能的精通，善于应变，快速解决问题，同时做好大量的预防工作。

 

如何衡量运维的工作质量？系统的可用性和系统的实效时长成反比，是对运维工作的最重要指标。可用性不能单纯用某一天去衡量，而应该使用年作为单位，甚至有可能需要过好几年，才能评论这个员工的工作质量。为什么这么说呢？打个比方，一个公司刚上线一套新的服务，那么运维工作人员可能采用了新的服务器(性能很好，容量评估过大)。新的服务可能访问量很少，那么也许在很长一段时间内整套系统的负载很小，由于硬件得到了很好的保证，所以在很长一段时间内可能是运行良好的(甚至出来问题也没有人发现)。至少上面的假设说明，短短的一段时间不能说明一个团队的运维工作如何。

 

以下是我根据实际工作中得到改善运维工作的一些见解。

 

系统结构的合理化

调整系统结构(硬件、软件部署结构)，在合理的人力支出情况下，提高系统的可用性是一个非常重要的手段，也是提高可用性的根本之源。

• 建立合理的冗余，并加强自动化工作。冗余是系统组件发生故障时得到快速切换，提供无中断服务是重要基础，处于各种原因，系统服务和质量可能会持续性的发生变化，应付这些变化，也需要持续合理的对系统结构进行调整(比如添加硬盘也是一种)。例如数据库的冗余，简单的Master/Slave方案也是提高信心的手段，甚至还可以使用Slave来缓解Master查询的压力。当前我所负责的平台虽然在很多组件的部署上有这方面的意识，但合理性还有待改善，同时也需要提供一定的测试演练来完善。尤其是一些游戏服务组件中，当前仅仅是提供了冗余的设备，但冗余的服务组件以及更智能的自动化切换一直没有完善。web平台这边由于设备有限，虽然在各个组件上都实现了冗余，但还缺乏自动化切换。

• 提高系统的稳定性，这点需要从设计、开发方面着手。系统的设计应该朝着能够提供部分停机维护、升级、切换发展；从系统结构、代码上提供系统的稳定性，减少因为某类异常导致影响到其他组件。我曾经发现一个核心系统总的积分排行功能设计缺陷导致数据库长时间锁，从而又导致整个核心无法提供服务。

• 整套系统还需要考虑Qos，避免带宽被非核心的服务占用过多。为此，从设计、部署上就要把那些大量占用带宽的服务和核心服务进行区分。例如对于网站，将图片、大文件等使用另外的域名提供服务，并在网络上进行区分，可以让核心网站得到更多的带宽保障，另外使用不同的域名存图片、样式文件等可以让客户有更快的并发，并减少客户端因为cookie等无用信息占用的带宽。

• 备份(甚至是尽可能实时的)，对各类应用数据，尤其是不可恢复的信息做好备份，避免单点失效，所以备份需要存放到其他设备上，备份策略需要不断的完善，并进行合理的演练。不同的服务组件有不同的备份形式，例如用户的图片(以及其他一些文件)，可以使用rsync定期备份到另外的存储服务器，利用dump/restore这组程序实现全量、增量的备份，当然结合lvm snapshot以及一些合理的定期脚本，就能实现开源高可靠的容灾方案了(数据库的物理备份也可以用这招)。

监控

 

监控是测试系统可用性的手段，甚至能在灾难扩大前解决问题。监控的目标包括

• 对操作系统的一些重要指标进行监控，例如CPU、内存、存储、进程状态、网络状态。你可以使用nagios轻松的实现这类监控，当然你还需要对其阀值的合理性进行全面评估。

• 对业务组件、中间件的监控，例如mysql的健康状态(连接数、锁)，tomcat的线程数。这类监控能告诉我们业务组件的健康状态，需要不断完善这类监控，但这类的监控也是很难顾全的，因为这类组件容易出现”部分异常”，或者因为应用程序导致一些异常，甚至是必须在特定的业务流程中才重现。

• 业务流程监控，俗称业务拨测，模拟用户、客户端的业务来进行业务完整性测试。如果你的运营系统只是一个普通的web服务，根据你当前的一些业务采集几个核心的url，还是能大体知道整个web服务是否正常运行的。但是如何运营系统了有一些特殊服务，比如游戏服务平台，那你可能需要开发与之对应的一些业务模拟程序(厄，机器人)来进行测试了，当然，也可以通过各种办法采集服务组件的信息来监控，但这毕竟不是最终用户的感受(或实际操作结果)。

• 对监控服务器的监控，才能最大可能保证监控是顺利的。例如，你可以建立两套nagios监控，双方相互监控对方。

 

• 对于监控的完善，我们应尽可能使用成熟的方案，流行的开源工具实现监控，尽量避免自己编写(脚本、代码)，经验告诉我们，自己编写的东西往往是不完善的，有时候会带来更大的问题，甚至影响被监控的对象。

日常工作中需要不定期的检查系统、中间件等各个监控点，以确保他们实际中没有出现问题，并且能根据各种人工检查和总结来完善监控系统。除了这些常规监控外，安全性检查，日志分析，补丁，入侵监控，漏洞扫描等也是日常需要完成的工作。

 

报警、应急处理

如何能得到快速的报警：

• 短信，有一定的延迟性，依赖于短信提供商。比如当前我们使用飞信(非官方)，那么飞信的客户端组件、飞信服务器、短信服务器都是我们无法控制的。缓解、解决办法：每日发送测试短信；监控发送短信的返回码，如果不正确，则再发送到139邮箱(也依赖于网络的健康)。更加改善的办法，购买短信发送客户端。

• IM，一些IM支持报警，比如使用XMPP开放的客户端，也依赖于网络的健康。

• 邮件，也依赖于网络的健康，及时性不强。

• 定期订阅，firefox的插件支持查阅nagios的状态接口来获取各个监控项的报警。

故障处理流程和速度，监控内容的增多，意味着可能需要更多的人力去处理应急故障，明确的故障处理流程和责任人，以及经验的积累有助于快速解决故障。另外，演习也是一个加快故障处理，积累经验的好办法。尤其是对大灾难，我们需要通过演习来完善应付方案，比如数据库的损害、硬件的损害。

 

测试、容量规划、分析预测

面对不断的变化和发展，对于系统未来一段时间内的状态和反应需要有合理的 评估。评估的基础有以下两方面提供：

• 测试，搭建合理的测试模型，能监测到系统在预估的测试模型下的表现。

• 基线建立，基线的建立在网络质量、服务器性能这方面尤为重要，从基线的发展中能了解到系统对服务质量的演变，并为容量规划提供依据，开源中cacti、ganglia是一些很好软件。

流程规范

流程规范是对长远的保障，也是避免人为故障的手段。运维面对的流程规范主要有两方面

• 业务应用程序维护、升级带来的变化。为了保证可用性，发生这些变化时最好有明确的文档指导，甚至是需要使用文档指导在测试环境下进行模拟变更，以减少在生产环境下变更时带来的问题。

• 服务系统、环境、结构等的修改。比如服务的搬迁，我们需要详细的搬迁方案和模拟演练，对修改需要进行归档，以备查阅。

知识积累管理

运维涉及大量的知识，不单单是技术性的知识，也有和业务系统相关的业务知识。只有保管好这些知识，才能不断的在团队中流传和使用，使团队人员能快速解决问题。当前众多互联网技术团队使用wiki管理这些知识，wiki能很好的维护这些文档的变更，也提供良好的查阅方式。

 

团队人员还需要对外界的资讯进行收集和吸收，尤其是各类漏洞的公布，补丁的修改，这类信息对运维至关重要。同时需要不断吸收新知识，以改善运维工作。

 

团队建设和管理、工作安排

总得来说，运维工作需要团队成员有强烈的责任心，高度自觉和技术敏感度。网络上众多人反映自己公司的运维工作人员，闲，每天就是喝茶。运维工作是一个可多可少的活，也是容易让人偷懒的活。
根据以往经验总结，可以从以下方面提高成员的工作质量：

• 工作的划分。工作的划分可以分为纵向切割和横向切割，纵向切割较为简单，需要成员具备足够的实力，把系统按物理设备、按服务组件切割任务，使每个成员负责一部分，相互间干扰较小。横向切割可以理解为技术等级划分工作，技术能力较弱的负责有完善模型的工作，比如已经有良好的监控系统，技术若者进行例行检查，技术强者在出现故障做后盾提供援助。

• 责任制，责任制和工作划分有密切的关系。如果作为横向切割，负责例行检查的人对于那些可预知、可发现的问题，因人为的忽略，最终导致系统故障，那么负责检查的人需要对此负责任。纵向切割时，负责人需要解决自己所负责的任务，不能及时处理时需要申请援助。人的责任心、积极性也可以从故障发生的频度，可预防性，应急速度、总结经验等过程中得到反馈。

• 技术性监工，也称技术型考核。对于成员所负责的任务，做出的技术性方案、实现进行分析评审，以查找可能存在的漏洞和弊端，减少人为失误。