运维工做与持续进阶

最近在总结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能很好的维护这些文档的变动，也提供良好的查阅方式。

 

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

 

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

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

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

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

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