【IT168 专稿】2012年9月13日，由盛拓传媒旗下的IT168、ChinaUnix、ITPUB联合主办为期三天(2012年9月13日~2012年9月15日)的第四届中国系统架构师大会于在北京永泰福朋喜来登酒店隆重召开。来自百度、淘宝、腾讯、IBM、新浪、网易、奇虎360等IT巨头的讲师分享了业界非常先进的技术经验与趋势。

▲更多信息尽在IT168现场报道。另，您可以微博关注#SACC 2012#了解信息。

　　9月14日上午，PPTV架构师 ITPUB元老版主 资深DBA专家诸超在会场向大家分享了PPTV在平台部署和运维方面的经验。

　　诸超谈到，PPTV和新浪淘宝不一样，没有极其强大的研发体系，有能力自己编写独有的分布式文件系统，所以PPTV在运维技术选择上的一个原则是拿来主义。当然PPTV在选择技术方向的时候始终坚持了一个原则：不选择小众的技术，倾向于选择更为大众且成熟的技术。基本上PPTV的后台技术大部分都应用了主流的开源技术平台，这些技术在Web 2.0平台中都已经应用广泛，得到验证。

▲PPTV架构师 ITPUB元老版主 资深DBA专家诸超

　　一个公司要做大，研发和部署体系都必须实现标准化、流程化。PPTV在公司层面统一运维系统规范和支持研发平台，包括控制研发技术使用，需要经过和架构师的讨论才能决定新技术的引用。同时从整体系统的层面简化技术平台，有利于网站稳定和技术共享。在系统内部，应用软件往往会在维护一个稳定版的基础上，同时推进一个更新版。

　　在研发体系标准化之后，PPTV开始考虑运维与部署的流程化与标准化。首先开始的是操作系统统一标准化。诸超谈到，他当时做的第一件事情就是取消操作系统的光盘安装，所有操作系统全部从Cobber安装。PPTV花费了半年的时间设计了统一的Cobber服务器，只需要点一下服务器，就可以通过Cobber服务器实现操作系统统一安装。

　　根据诸超的介绍，实际上，PPTV内部有很多的OS和Package，号称都是针对某项特定应用进行优化的，然而诸超认为，不要因为单个的应用在性能体验上大约有5%左右的差异，而导致整体的OS差异性。只有大部分的OS、Puppet控制系统和CDN应用都统一了(包括服务器命名的统一和统一LB配置)，才不会在系统运行和运维中出现一些诡异的问题。

▲诸超在系统架构师现场介绍PPTV分布式运维架构经验

　　如今，PPTV包括各类应用基础架构，如日志格式、路径、空间管理、日志删除、配置参数文件方面，都有了统一的规范。例如以前PPTV有10多个IDC，PPTV与IDC之间都是VPN互联，但实际上，VPN经常会超载，后来PPTV取消了绝大部分IDC，只保留4个主要的IDC，从而技术运维的难度大幅度降低。此外，PPTV内部制定了严格的技术管理制度，绝对不允许跨IDC调用，PPTV认为，只有统一了，才能实现自动化部署、分析与排障。

　　PPTV提到了运维基础服务化的问题，向服务化转型的原因是希望避免重复开发与部署、加快项目部署速度;同时可以更好的积累经验，用精技术，不用每个业务都有自己的Solution;同时也可以避免单点故障，部分服务可以复用;还简化了系统架构，能够更简单的进行故障排查。诸超认为，正因为做的东西少了，所以有精力可以把现有的东西做的更好。

　　PPTV基础运维组件包括：Kickstart/Cobber/Puppet/CMDB/Zabbit等。其中诸超强调：Puppet是运维的利器，通过Puppet可以实现OS初始化、App环境初始化、LDAP、SSH等安全加固、全网/部分推送配置变化、以及应用直接部署的功能。如今，PPTV内部几千台服务器全部用Puppet控制，包括几个大的Puppet模块。诸超认为Puppet最关键的一点是，因为Puppet是大规模控制，所以不成熟的时候最好分阶段、分步骤部署应用，否则某个应用部署出错，而Puppet开始大规模部署的话，就形成了较大的运维失误。

　　PPTV通过Zabbit进行系统监控，诸超谈到选择监控系统的原则：必须基于数据库，有数据库之后就可以做各种各样的分析，第二是可以装Agent，跑不同的任务。而这两点正是诸超眼中Zabbit的优势。尽管有些人可能并不喜欢Agent，但实际上Agent非常灵活。不过诸超热网内Zabbix非常适合的还是基础监控，系统监控方面并不十分强大，系统层面的监控代码大多数都是PPTV自己写的程序。

　　此外，诸超介绍了PPTV用于资产管理的CMDB软件，通过CMDB可以了解多少机房、带宽、IP段、服务器、各自的型号分布、IDC分布、过保分布、基础运维服务透明化，和其他的运维监控、分析软件结合，可以全面的了解，每个应用实际上占用了多少服务器，哪些需要优化，是否有过保的情况，业务负责人是谁，并可以给相关的业务负责人抄送告警邮件。

　　目前PPTV还可以提供一些日志的分析服务，但诸超坦言PPTV内部的这部分工作还需要进一步强化，也是他下一阶段的工作重点。日志分析服务包括App日志接收平台，而接收日志之后，PPTV日志收集的系统目前为止也非常不统一，每个应用都自己写自己的收集平台，最后建立了Hadoop日志收集平台Rsync。

▲PPTV App日志接收平台系统示意

　　此外，PPTV应用MongoDB进行实时日志分析平台，7认为是自动化运维和监控的基础。目前运营的非常稳定。同时诸超提到运维告警方面的一些经验：监控容易告警难。据介绍，PPTV内部告警系统也进行了多次的反复调整，如果告警级别设定过低，任何一些小故障就会告警，但告警级别设定过高的时候，往往会出现大量的告警信息。PPTV对告警信息进行了及时的处理，通常发生的情况是，这些处理和分析会消除一部分告警信息，但很快也会在系统中设定新的告警。

▲基于MongoDB的实时日志分析平台

　　现场诸超还谈到了系统优化层面以及文档分享的问题，诸超认为，事故并非一定是坏事，出现事故才有了优化和改进系统的机会。在出现事故之前，尽管运维人员希望对系统进行优化，但往往研发或者技术人员并不十分重视，因而事故往往是系统优化的非常好的机会。对运维人员而言，事故分析与经验积累都至关重要!