作者：程小丹 等
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
从运维菜鸟到大咖，你还有多远：数据中心设施运维指南试读：
前言
数据中心设施运维，经常被与数据中心IT系统运维混为一谈。实际上，两者的工作虽然都以保证IT系统的可用性为最终目标，但在工作对象上，却是截然不同的。IT运维本质上是和比特（bit）打交道，设施运维则主要和瓦特（Watt）打交道。
工作对象的不同，决定了工作方式也不可能完全一样。鉴于机电系统的复杂性，数据中心设施运维更像是一门经验性的学科。所谓经验性学科，就是很难坐在计算机前，靠科学计算就能找到所有的解决方案。传统的设施运维更多地依赖于久病成医，即犯了足够的错误以后，就可以把运维做得好些了。
当然，如果大家都愿意把自己犯的错误共享出来，就可以让整个行业受益，毕竟，不是所有的雷都需要靠自己蹚出来的。但是，要让行业的从业者分享自己经历过的事故是很难的，因为每位数据中心的领导都希望外部认为自己的运维是完美无缺的。所以，我们很少看到对于一个数据中心事故的深度分析，更多地是看到莺歌燕舞的正面报道。
本书首次突破这一行业习惯，这是第一部由行业运维精英们共同分享的真实运维经历，其中记录了很多成功经验，但更多的是对挫折和教训的反思，以及惊心动魄的数据中心火灾救援过程。这种第一手的经验，是很难通过传统的教科书获得的。
本书还是第一部以小说体写成的运维经理人手记。当我们决定一起写这本书时，大家都希望写一本能够让读者有阅读乐趣的书。记得多年之前看过一本书叫作《一分钟经理人》，这本书与其他的管理书相比较，最大的特点就是可读性强。为什么数据中心运维不可以有点乐趣呢？所以，本书第一部分以小说体的方式，来讲述运维经理和运维工程师在数据中心运维过程中可能会经历的一些事情和过程。我们设置了两个人物：Tom和Peter，在这两个人物身上，可以看到所有运维人的影子。当然，应该给他们这么洋的名字，还是更加本土化的“小明”和“小军”呢，这个我们写作组也有争论，但我们最终还是觉得小学学数学的时候，已经受够了小明和小军了，所以还是选择了Tom和Peter。
华为的喻茂萍总主动担纲第一章的写作，并且很快就写出了既充满专业知识又具满满人文情怀的第一章，为整个第一部分的文风定了调。来自招商银行、中国联通、中国移动、中国电信等二十多家数据中心的其他专家们也都奉献了自己宝贵的运维经验和感悟。我发觉，很多平日里非常严谨的理工男女们，其实都有一颗文学青年的心。
本书第二部分是请数据中心核心设备供应商从他们的角度来讲述数据中心的主要设备在运维过程中需要注意的要点。我们给出的场景设定如下：如果你交付你的设备给运维团队，你希望给他们什么样的建议来更好地运维，以保持你的设备拥有最佳的运行状态，并延长设备的生命周期。非常感谢伊顿、施耐德、中达、康明斯、南都等设备厂商的领导们可以站在用户角度看问题，重视设备的运维，积极参与本书的写作。来自工商银行的李崇辉老师和德拓天全的曹洁老师负责第二部分的总体编审，做了大量的工作。浙江电信的叶明哲老师贡献了水冷空调的维护指南。我们的微信群“数据中心设施运维百人会”中的群友互动讨论帮助澄清了我们写作中的很多技术困惑。
还要特别感谢我中科仙络的同事们，尤其是负责本书排版编辑的王彤，文字汇总编辑的闵谦，他们的辛勤工作使得本书能够如期完成。还有毕业于清华美院的插画作者顾众，她的作品为本书添色不少。最后要感谢我太太及两位女儿，她们给予了我牵头写作本书极大的精神支持。因为两位女儿都各自出了书，背后还有我太太作为编辑给予支持，我才有信心启动这本书的写作工作。
数据中心运维是一项非常关键但又枯燥、重复性很高的工作。在我们接触过的运维团队中，见过不断挑战自我，追求精进的主动性运维组织；也见过把运维看作出了问题再进行修补的被动性运维组织。从短期来看，两种工作方式的结果并无大的不同；但从长期来看，我们相信主动性组织一定会取得更加高可用、高效率的运维结果。希望本书有助于让数据中心高层管理者更加重视运维，也希望数据中心运维的执行者能够从同业者的经验教训中获得一些收益。程小丹中科仙络咨询服务有限公司董事长2016年1月31日作者群参与单位运维人说
运维是一项需要长期坚持、耐得住寂寞的工作。数据中心运维更需要有一颗像大海一样宽阔包容，却又如镜湖一样平静淡定的心。台上一分钟，台下十年功。作为IT生产环境的守护者，日常需要细心识风险、排隐患，一次次化解危机于无形；节假日宝贵的时间窗，更要争分夺秒、通宵达旦实施变更或整改优化。数据中心运维推行的是风险管理和预防性维护策略，做到极致的结果是：她就在那里，无处不在，却没人感觉到她的存在。莫非这就是运维人追求的最高境界？是的。运维工作从未走到前台，观众看不到他们，甚至不知道他们，但他们却学会了自娱自乐。时而巡查、时而检修，时而测试演练、时而又应急抢修，时而暗流涌动、时而又风平浪静。没有一颗坚强的、冷静的、热爱的心，运维人不会坚守到今天。Part 1运维经理人手记位于成都的万达云基地有望成为国内第一个通过Uptime Tier IV建造认证（TCCF）的数据中心Chapter 1 接手运维1 初来乍到
在北京城难得的蓝天下，Tom抬头望着眼前这座宏伟的建筑，心里不由得赞叹：这就是传说中的“数据中心！”这座单体建筑，从外表看不出里面有几层楼，但Tom的直觉告诉他这个建筑的面积得有2万～3万平方米。比起Tom同学之前在一家国企负责的300平方米机房，这个建筑就是“巨无霸”了。
300平方米的机房可以说是麻雀虽小，五脏俱全。UPS、配电、空调、高架地板、监控，各种专业的设备该有的也都有了。一手负责建设了个300平方米的机房、还运行了5年的Tom同学，觉得自己也算是半个机房专家了。但不知道从哪天起，周围的人都开始管机房叫数据中心了，Tom原来一直感觉数据中心比起机房，就是换汤不换药的时髦叫法，纯属某些厂商忽悠出来的概念。但今天看着这大型数据中心外面的专用变电站，Tom开始感觉到这数据中心确实和自己负责的机房有点不一样。自己要干好这大型数据中心运维的活，还真有不少新知识需要学习。
Tom是上个月决定跳槽到这家数据中心来做运维的。其实Tom对于自己一手建设运行的机房还是很有感情。只是这几年公司的业务发展很快，除了国内的业务，还有不少国际业务，这就对他们IT支撑部门提出了24小时不间断运行的要求。Tom带领着一个小团队，负责公司唯一的数据机房的运维，从基础设施日常维护，到服务器上架和配置、故障处理，都得亲自上阵。尽管没日没夜、兢兢业业地忙碌，却还是免不了出各种状况。Tom原来的老板是科技部总经理，搞软件出身，对业务开发非常关注，但对运维却不太重视，总觉得运维就是简单重复的事情，没有太多价值。因此，老板在Tom团队的人员编制上卡得很紧，又不让请外包。Tom就经常捉襟见肘，疲于应付。终于有一天，积重难返，各种问题集中爆发。一方面，工作量大得让他们晕头转向；另一方面，他们因为手忙脚乱地满足业务的需求，疏于质量流程管理，机房掉了一次电，影响了业务连续性。因此，他们部门被业务投诉，被领导“修理”。Tom感觉再也坚持不下去了。他想改变，立即改变，一刻也不要等！
人生最幸福的事情，莫过于：你想睡觉时，刚好有人送来一个松软的枕头，还有一个温暖的被窝。这天晚上，已经很晚了，Tom没有收到枕头，却收到了一条微信。发微信的人是Peter。
Tom是去年在一次研讨会上认识Peter的。Peter是数据中心的前辈，当时正在负责一个大型绿色数据中心的规划，讲起PPT来两眼放光、口若悬河，号称他正在设计的数据中心是国内领先，国际也领先。Tom在下面听着，对Peter先生的敬仰如滔滔江水连绵不绝。休息时赶紧主动递了张名片，聊了一会儿，越发地佩服这位言谈中时不时带着几个英文单词的专家。而Peter也很欣赏有着丰富一线经验的Tom。两人聊得甚是投机，加了微信，常有联系。
却说Peter在IT和通信行业干了十多年了。国企干过，外企也干过，最大的优点就是英语好，还爱学习，肯钻研，知识面特别广。所以，行业里每次有啥新浪潮，他总是弄潮儿。虽然Peter是做IT出身的，但自从美国人开始聊绿色数据中心、PUE啥的，他就开始在国内发表文章，纵论绿色数据中心设施的各种趋势。所以，各家办研讨会也经常请他去给露个脸、讲个话，因此Peter也在行业里积累了不少粉丝。有一天，他所在的单位要建一个新数据中心，英语好又懂数据中心的Peter就陪着领导去美国溜达了一圈。在回国的路上，领导语重心长地对Peter说：“我们的目标是要建设一个二十年不落后的数据中心，这件事就交给你了！”
很快，Peter被正式任命为数据中心总经理，负责这个数据中心的建设和运行。这一年多下来，Peter又是找人规划设计，进行各种论证，又是招标走流程，过五关斩六将，时不时还得亲自盯着建设现场，确保质量。眼看着机房建设得差不多了，他忽然想起后期得找人帮着看好运维这摊子事啊，于是就想起了Tom。
毕竟Peter自己之前没有做过一线的机房运维工作，他需要Tom这样有着丰富实战经验的人来帮他管好运维。于是他拿起了手机，给Tom发了条微信。Peter发微信时想起乔布斯那句著名的“你想卖一辈子糖水，还是跟我一起改变世界？”就来了一句：“你想一辈子守着300平方米的机房，还是跟我一起运行最高端的数据中心？”这边Tom本来已经是穷途思变，还有啥可多想的？于是，就有了今天Tom正式入职的日子。
走进这座高大且装修精致的建筑楼，前台的接待人员礼貌地接待了Tom，然后替他呼叫了Peter。转眼间，戴着安全帽的Peter如一阵风似地出现，手里还替Tom拿了一顶安全帽。没有太多寒暄，Peter直截了当地告诉Tom：“这几天机房一期的建设到了最后的测试验证阶段，你一起参加一下吧。”“测试验证？”这个对于Tom很新鲜，当年他负责建设那个300平方米的机房时，没做过啥测试验证，顶多是给UPS接上假负载，看看电池的时间是否够。
Peter拍拍他的肩膀说“数据中心工程建设就是一个设备集成过程，即使每个单个设备都是好的，但集成在一起，未必就会按照设计时预想的目标来运行。只有通过测试验证，才可以发现设计或者建造过程中的问题，确保机房达到运行的目标。现在国外所有数据中心的建设，都已经把最终的第三方测试验证（Testing and Commissioning）当成建设的标准步骤。就拿汽车组装为例，假设你的车架、发动机、方向盘、轮胎，每个部件都是用奔驰最牛的部件，但是我随便找个组装厂给你组装好了，还没有试车，直接就交给你了，你敢开吗？”
Tom有点明白了。脑子里闪过某马大侠说的淘宝上可以买到所有零件来组装一辆兰博基尼的故事。马大侠充分说明了淘宝上货品的丰富性，不过要是直接在杭州谁家车库里把这车组装好了，估计马大侠自己肯定不会坐的。
Peter继续说道：“国内很多领导还没有意识到测试验证的重要性，经常因为项目工期紧，或者前期没有申请预算，就把这个重要的步骤给忽略了。这样，建设和设计过程中的疏漏就很容易留下来，成为后期运维的重大隐患。这些都有很多血的教训，所以我们说测试验证是数据中心运维的起点。”2 冷却系统验证
说着话，Peter已经带着Tom走进机房，穿过走廊，他们首先来到的是DCIM（Data Center Infrastructure Management）监控室。大部分的数据中心机房参观，都是从监控室开始。因为监控室里一般都有大屏幕，那上面的各种数字、图表、视频很容易让人感受到科技的震撼。Peter很得意地介绍了这套象征着他们“鸟枪换炮”、从此步入自动化运行新时代的监控系统。他逐一展示了EPMS（工程业务管理系统）、ITMS（智能监控管理系统）、BMS（楼宇管理系统）、CCTV（视频监控系统）、ACCESS system（门禁管理系统）、Fire system（消防监控系统）。尽管这些系统还没有完全调试完，屏幕上时不时闪烁着红色的、黄色的、绿色的字符或者标识，提示着一个个不太安分的存在。从监控室展示的系统架构图上可以看出这是一个高等级的数据中心，T3和T4级别的模块混合部署，部分模块采用的是业界较为先进的三母线架构设计，中温和低温冷冻水。其中，T4模块还采用了双冷源精密空调。Peter为了实现绿色数据中心的梦想，让PUE合理性最高，采用了多项节能技术，也选用了高效节能的设备。
这时候，对讲机有人呼叫Peter，冷水机组的群控系统调试验证马上就要开始了。
来到安装冷水系统的房间，里面一屋子人。Peter快速给Tom介绍了来自第三方测试验证公司的王工、总包的项目经理，还有冷冻水机组厂家和安装公司的人员。王工是今天测试验证工作的总指挥。按行规，做验证的时候，第三方测试公司的职责是提出测试方案，在甲方认可后负责协调实施。实际测试的时候，测试公司负责给出需要做的操作指令并记录数据，具体操作则由设备供应商或者原厂商派技术人员来执行，这样做的好处，是可以规避操作过程中万一设备出问题时责任不好认定的尴尬。
此前，冷水系统在安装施工阶段，已经对水管进行了分段吹扫和清洗。安装完成后，又整体进行了清洗和打压、保压，符合验收标准后，再对管道补刷了防锈漆和面漆，并按设计要求进行了保温。验收前，管道正式充水，同时通过水处理加药系统按要求投加缓蚀剂、阻垢剂、灭藻剂等药物进行预膜，以防止管道腐蚀生锈。冷却水泵和冷冻水泵也通电进行检查和试运行。试运行期间，要及时对压力表进行检查，根据压差判断系统是否有脏堵，特别是Y型过滤器，在系统投入初期，要特别进行关注，及时清理。随后逐个对离心式制冷主机、精密空调、新风机组、排风机组、冷却塔、板式换热器、连续制冷蓄冷罐、电动阀、平衡阀等分别进行加电检查，并做好单机调试记录，以备验收接管时作为原始资料移交给业主存档备案。之前所有的单机调试已经完成了，最后的环节就是今天的群控联调。
所有相关人员均已到场了，王工看了Peter一眼，Peter点头示意可以开始。然后王工就开始给出今天验证的场景指令。
首先验证的是场景一：机房环境温度偏高，冷水主机正常启机。系统先对各辅助设备及制冷主机进行自检，正常后，按顺序开启1#冷却水电动阀、冷却水泵、冷却塔风扇、冷冻水电动阀、冷冻水泵，然后开启1#冷水主机，机房内精密空调也按一定延时，顺序逐台开启，检查各项运行参数是否在工艺标准范围内。人为调高机房温度检测探头显示温度至设定阈值，2#冷水主机系统也按正常顺序开启；依次对3#、4#冷水主机系统进行测试，一切正常。开局不错，大家都非常兴奋。
马上开始第二个场景：机房环境温度偏低，冷水主机自动停机。运行一段时间后，机房温度逐渐下降到20℃以下，精密空调先依次进入怠机状态，冷水主机电流百分比逐渐下降到30%左右，自动卸载停机，约5分钟后，冷却水泵和冷冻水泵自动停机，冷却塔风扇停止，电动阀也关闭。一切都按预想的进行，“No surprise”，Peter对自己说了一句。同时也为自己当初力主公司花高价钱买的这些一线品牌设备暗暗点赞，产品质量就是过硬，关键时候没有掉链子。冷水机组检测
下面这个场景是检验Peter的绿色数据中心概念的重要环节。
场景三：室外温度低于10℃，切换到free cooling系统。1套冷水主机长时间低负载运行，测定室外温度低于设定温度，系统切换到free cooling，已经停止的冷却塔风扇开启，板式换热器前后端阀门打开，换热器开始通水工作，几分钟后冷冻水泵停止工作，电动阀关闭，制冷主机停机。系统平稳切换到free cooling系统。逐渐提高室外温度，系统又回切到制冷主机工作模式，一切尽在掌握，顺利得没有朋友。
接下来，还得把蓄冷罐的充放冷逻辑确定下来。首先，由设计师将冷冻水系统蓄冷罐的充放冷逻辑思路给参加联调的人员讲解一遍，并将几个关键的设定值同现场团队作了确认。负责弱电安装的供应商和制冷机厂家代表分别提出了几个优化建议，现场立即进行了变更并将最终的逻辑进行了存档，同时作了备份。
上面几个场景只是模拟了冷水机组相对正常的运行状态，但是验证的另一个重要功能就是要做故障模拟。软件系统要做压力测试，设施也是一样。数据中心机房的测试验证就是要给数据中心出各种难题，挑战其抗风险的能力。现在，模拟故障的第四个场景开始了：运行设备故障，备用设备自动开启。人为模拟现场阀门关闭，导致正在运行的1#机组冷却水中断，1#冷冻机因冷却水中断自动保护停机。系统自动开启备用的2#冷却水泵和电动阀给1#冷水主机供冷却水，但1#主机开不起来，这时2#主机及配套的辅助设备逐台开启，2#制冷主机系统正常运行。依次测试3#和4#也均能自动开启。
但对4#测试完，模拟关停4#机组的冷冻水泵后，这时所有制冷主机均停止，尽管冷却水和冷冻水均供应正常，压力正常，但没有一台制冷主机能自动启动。现场先是一阵沉默，大家你看看我，我看看你，接着开始躁动起来，刚才还得意淡定的Peter也hold不住了，不知道哪里出了差错。
过了好一会儿，王工突然发话了：“是不是冷冻机设定的停机保护时间还是出厂设置的30分钟，没有修改？”真是一语点醒梦中人。刚才大家都关注设备操作，竟然忘记了设备出厂设定值没有根据实际应用场景进行核对验证。幸亏在模拟调试阶段及时发现了，要是在业务运行时发生此类问题，没能及时处理并恢复冷冻水供应的话，短时间则可能导致高温告警，服务器宕机；如果高温长时间得不到及时消除，则可能触发消防系统启动，一场灾难将无法避免。特别是现在数据中心中高热密度机柜越来越多，单位时间升温比原来快多了。
经历了这一趟折腾，大家的紧张度又提升了。Tom也深切感受到测试验证的必要性。3 配电系统验证
后面几天是供配电系统的联调验证。供配电系统可以说是数据中心第一大潜在杀手，大部分的数据中心故障——导致IT系统中断的事件，都是由供配电系统引起的。所以，Peter对供配电系统的验证特别重视。
这次供配电系统的联调分三个大的场景：A路停电、B路停电、双路停电。测试团队按事先的分工，各自穿戴好EHS装备，各就各位，并带上提前打印好的check list（工作清单）和对讲机，由总指挥和指挥组按check list下达指令，操作组逐项实施。所有的高、低压设备操作均由合格电工严格按双重检查（double check）原则，一人唱票，一人确认并完成实施，同时将操作结果用对讲机及时汇报给指挥组。
场景一：A路停电。各小组人员就位，穿戴完整，操作组组长向总指挥汇报准备工作完成，等待指令。总指挥下令：A路断电。2位高压电工都是具备20多年经验的老搭档了，他们技术精湛，分工明确，配合默契。尽管戴着防护眼镜，但透过厚厚的镜片，仍然只需要一个眼神，都能彼此心领神会，分头行动。A路开关断开，按设定的逻辑，高压母联迅速合上，检查确认末端双路供电正常，无任何告警；手动将高压母联断开，大约几秒钟，低压母联合上，末端仍然是双路供电，无任何告警，验证合格。供配电系统的联调
场景二：B路停电。按同样的流程，对B路进行停电测试验证也正常。
场景三：双路停电。将A、B两路市电都断开，这时发电机启动。先启动1台，很快其他发电机顺序开启，十多秒后，并机完成，开关开始依次动作，给负载送电。同时对并机时间和开关动作顺序做好记录，验证控制逻辑是否准确，同时供今后应急故障处理作参考。恢复市电供电：按操作规程进行检查，确认符合送电要求，开始A、B路分别送电。开关依次动作，双路供电正常，发电机卸载，约5分钟后，各发电机自动停机。人员确认系统各设备运行正常后顺序撤离。
配电系统的综合测试没有出什么大的问题，只是在局部测试的时候，发现了线缆接口螺丝没有拧紧，接触不良，在负载加大的时候产生温升，这是做带负载测试中最常发现的问题，也是需要用假负载进行测试验证的重要原因之一。4 消防和安防系统验证
数据中心两大关键系统——供配电和制冷系统联调顺利完成，Peter心里的两块巨石总算落地了，但联调工作还没有完。紧接着是消防系统和安全监控系统的联调。最先测试的VESDA系统，即极早期烟雾报警系统。顾名思义，这个系统是为了在不可见烟阶段，及早探测到微量烟雾，更快发出报警，一改传统点式探测系统等烟雾飘散到探测器再进行探测的方式，主动对空气进行采样探测，使保护区内的空气样品被设备内部的吸气泵吸入采样管，送到探测器进行分析，如果发现烟雾颗粒，即发出报警。测试人员带着烟雾发生器分别来到事先确定的采样点，覆盖了最远端、天花板、地板下、设备走廊等各种场景，分区进行测试。同时对各控制器的告警阈值进行了再次确认并记录存档。紧接着，测试人员对烟感、温感也分别进行了再次抽检，一切正常。确认各消防系统正常并置于自动状态，有专人负责手动关闭预作用水喷淋系统的主阀并挂上警示牌，正式开始测试消防系统联动。这时，人为对着一个烟感探头吹入烟雾，同时，将温感探头置于一杯高于68℃的热水中，对预作用末端管网手动迅速排出压缩空气。这时，火灾警铃响起，消防广播开始播报火警，要求人员紧急疏散，电梯迫降，消防卷帘门关闭，门禁释放，消防水泵立即启动，预作用系统按预期的程序动作，除了因人为手动关闭喷淋水主阀，一切正常，测试达到预期目的。将所有系统检查并复位到正常状态后，手动开启主阀，并挂牌：“阀门常开，不得关闭”。
快到最后一关了，Peter有些小激动，眼看一年多的设计建设“马拉松长跑”就快到终点了。他与Tom对了一个眼色，宣布正式进入安全监控系统的测试。
因为都是即时设定的场景，事先并没有通知任何值班人员，而且是多个场景连续测试，顺便也把现场安保团队的应急反应能力做了一次完整的测试和演练。尽管把有限的几个值班的消防、安保人员折腾得够呛，看着他们一会儿调监控视频，一会儿对讲机确认，一会儿又飞奔到现场检查和复位，还好没有出现大的纰漏，看来前期辛苦的培训和演练都没有白费。
Peter有些暗自得意。成功总是留给有准备的人，这真是句大大大大的实话啊！今天是个值得纪念的日子，也是众人举杯相庆的日子。辛苦了那么久，付出了那么多个日夜，总算对公司有个交代，可以准备正式移交进入运维阶段了。为什么说是准备呢？因为，从建设移交给运维，就像皇帝嫁女儿一样，仪式是不能怠慢的，丰厚的嫁妆也是一点也不能马虎的。数据中心移交运维也如此，有一大波流程要走，当然，还有少不了的图纸、记录、报告、手册、证明等文件资料。还有钥匙、随机备件、配套工具……想想都让人头大。所以由专人来负责文档的造册、管理是必不可少的。如果交接的时候有一丝马虎，真到了后期运维的时候，就后患无穷。所谓“人无远虑，必有近忧”，很多运维的问题，都是在建设阶段留下的。所以，磨刀不误砍柴工，该慢的时候还是要慢下来。百度阳泉云计算中心——首个全预制模块化数据中心，100%整机柜部署；首个高温运行的数据中心，全年96%时间利用自然冷源；首个通过设计、运营双5A认证Chapter 2 人员与组织1 管理目标
眼看着测试验证进入尾声，数据中心即将投产，Peter更着急运维团队的组建问题。之前就有人建议他应该在建设后期就把运维团队组建好，这样就可以利用测试验证的机会让整个团队有机会参与部分操作，毕竟测试阶段本来就没有带真实负载，即使操作错误，也不会有和业务相关的后果，所以这也是运维团队演练的好机会。但领导和财务部门都希望他控制人员成本，分步增加人手而不是一次到位。所以，到了测试验证的后期，到岗的也只有几位关键的人员。
下周就该向领导提交他的运维团队的编制计划了。该如何搭建运维团队的组织架构、确定合适的人员配置？对人员应该有什么样的要求？Peter还是没有彻底想明白。
这天晚饭后，他带着Tom，约了两位他认为的行业高人：来自某运营商的薛先生和在某著名外企管理数据中心的吴先生一起来到酒吧街，找了个安静的酒吧，几杯啤酒下肚后，哥儿几个话就多了起来。
薛先生正在业余攻读哲学博士，所以说话都带哲学味：“搞数据中心运维什么最重要？人才啊！”Tom觉得这句话不太像哲学家说的，倒像葛优说的。但薛先生后面的话就充满哲学思辨：“最不可靠的人，却是最重要的！因为人有持续改进的意愿，人可以不断修正手段的不足，人可以完善制度流程的缺陷。总之，人是可以动态地面对整个数据中心的核心！”“数据中心是动态的，对吧？数据中心虽然放在那里不会跑，可里面的上千套设备，几万个接头，各种电子器件，随时随刻都在发生变化。更何况还有时刻可能中断的外电供应、异常高温的天气、不请自来的雷电、饥饿的小动物、莫名其妙的漏水、悄然起火的易燃物。俗话说人吃五谷杂粮，哪能不生病呀？数据中心也是人建的，哪能不生病？这些设备，不会说、不会讲，病了、痛了，如果没有人平时主动维护，故障时及时修复，最终系统出事是必然的，不出事是偶然的。”
Tom一边景仰地点着头，一边问道：“听说现在国外的数据中心自动化程度很高，是不是以后可以用自动化手段降低或者完全取消对运维人员的要求呢？”
旁边的吴先生笑了一声，说道：“Tom，其实国外数据中心里面的运维人员配置也还是不少的。而且所谓的DCIM，或者国内叫动力环境监控这些手段虽然已经很先进，但还是有可能误报和漏报。因此，机房的安全运维依然少不了运维人员的巡检。美国的Uptime Institute去年主要针对欧美数据中心的调查统计结论是：大约50%的机房风险是由监控系统发现的，还有50%是由运维人员在巡检时发现的。如果在这些国家都是这样，就不用说咱们国内了。老外的人员那么贵，但凡能用自动化的人家早用了，对吧？所以说，用自动化运维手段替代人员，恐怕还需要相当长的时间。”
吴先生是新加坡人，在新加坡有着丰富的数据中心管理经验，还给新加坡政府做过IT顾问，算是资深人士。虽然在北京已经住了多年，但说起话来，还是带着点新加坡的“胡建”口音。
他转头对Peter说道：“我认为规划运维团队的时候，最主要的是要考虑两个因素：① SLA，就是你的服务水平承诺；②成本预算。这两个目标是互相矛盾的，你的SLA目标越高，需要的人员配置就越多，相应的成本当然就高；如果预算没有那么多，你就需要控制人员，相应的SLA就会降低。所以，你就是要在这两个目标之间找寻平衡。最终就看你们的领导能够接受的平衡点在哪里。”
吴先生继续说道：“如果你的服务水平承诺不高，那5×8的服务就可以了。但如果你的服务承诺要求到99.99%，甚至有的单位领导直接要求100%，那你的团队配置就完全不同了。”
从科学的角度说，任何系统都不可能100%没有故障。数据中心即使达到T4的建设和运维标准，也不可能做到100%不间断运行。但很多领导对故障零容忍的心情，也是可以理解的。毕竟，现在很多企业的业务系统都依赖于信息系统的支撑，如果数据中心出现故障，导致业务系统中断，无论是从经济效益还是社会效益角度来看，负面影响都太大，作为主要的责任领导，也必然要承担责任。所以，负责运维的领导，每天都是如履薄冰。2 人员配置
Peter一边挥手让服务员再加几瓶啤酒，一边问道：“哥儿几个说得都有道理，那我到底需要配多少人呢？”
薛先生点着一根烟，说道：“我们的做法是：①首先进行设施资产的盘点，先数数你有多少台备用发电机组、多少台冷水机组、多少台UPS……这些资产就是你们要管理和维护的对象。每个设备每次维护总有一个大约的工时估计吧。把这些工时计算汇总，就知道在维护保养方面共需要的人天。②运维团队另一项重要工作就是巡检。你的巡检频次如果确定，比如4小时一次，或者6小时一次，或者一天两次，然后每次巡检需要花的时间大致也知道，那就能计算出巡检需要的时间。③再考虑设施运维团队日常培训需要的时间，还有接待或者陪同领导、客户参观讲解的时间。数据中心一般都是领导感觉特别自豪的地方，所以经常要接待上级领导、兄弟单位或者潜在客户，有时候还应准备PPT讲解，别小看了这些事务性工作，也是要用掉运维团队不少的时间。对了，还别忘了留够培训时长哦，看您的团队基础了，每个月总得留出4～6个小时的培训时间吧。把这几块时间加在一起，就是运维团队有效工作需要的时间。当然，人不可能到岗之后不停地工作，总要吃个饭打个尖，取个0.8～0.7的有效工作时间系数，把有效工作时间除以这个系数，就大致可以得出总的工作时间了。”
Peter听了觉得颇有道理，自己还从来没有这么去思考过运维需要的时间，他赶紧叮嘱Tom之后好好做个计算统计。
吴先生插嘴道：“这种工时算法很有道理，但并非决定人员配置的唯一因素，因为这种算法并没有考虑到值班人员的最低配置因素。”
Tom觉得这又是他第一次听到的新概念。“什么是值班人员的最低配置因素？”
吴先生说道：“最低配置因素决定了你在任何一个时间点对于事件的处理能力。首先，基于行业数据的统计，事件发生并没有特别集中的时间点，就是说24小时任何一个时间发生事件的概率其实是一样的。我自己把人员配置定义了三个等级。如果你只有5×8的人员值守配置，同时又没有很好的监控远程报警功能，意味着你在上班时间外对于数据中心发生的事件有可能完全不知，这就是C级配置；如果你没有7×24人员值守，但是有很完善的监控及远程报警功能，那么如果事件发生，至少你会知道，我们也可以定义为“即时报警”，这个定义为B级配置。当然，从你得到报警信号，到派人赶到现场进行处置，这个过程一定会有时间的耽搁，就有可能加大事件转化为故障的可能性。如果有7×24人员值守，而且这些人员又具备了现场处置问题的能力，那么就可以达到对于事件“即时处置”的能力，这样就是最理想的A级配置。考虑到电力、暖通、弱电专业的技术复杂程度，一个技术人员很难做到全才，所以，对于要求SLA在99.99%以上的数据中心，比较理想的配置是每一个值班组至少同时拥有这三个专业的人。这样当事件发生时，特定专业都有专业人士来制定应急措施。从人数上看，这种配置可以在事件发生时，安排两个人到现场处置，另外一个人留守在监控室。两个人同时到现场处置是从安全角度考虑，这点在电力行业都是这样要求的。而在监控室的人，一方面可以监视是否有其他并发事件发生，另一方面还可以起到与其他相关部门沟通的作用。基于不同等级的事件定义，运维人员有不同的告知义务。比较严重的事件，需要尽快向领导汇报，并及时告知可能受到影响的IT部门或者客户。”
Tom问道：“我们以前的机房上班时间是我们自己管理，下班后都委托给大楼物业人员来帮我们监控，这样算哪个级别呢？”
吴先生道：“你说的这种情况在中小机房的运维中确实很常见。我们可以这么分析：如果夜间机房有事件发生，你的监控系统报警，大楼物业人员收到报警信息。这时候他需要判定是否要介入事件的处置。一般你们也会事先定义事件的级别及他们相对应的处置权限。如果相对复杂些的事件，一般来说都不会授权给他们处置的。因为如果处置不当，很有可能把事件扩大。好，对于他们不能处置的事件，他们可以做的事情只能是通知你们的技术人员，由你们安排人员到现场处置。而你们安排的人员到场，同样也有时间滞后。所以，这种情况和我们刚才讲的B级配置，没有本质区别。”
吴先生喝了口啤酒，继续说道：“值守人员配置等级越高，系统的可靠性当然就越高。Uptime Institute的统计数据表明，配备7×24值守的数据中心的故障概率，是没有配置的数据中心的50%。当然，值守人员配置等级越高，运维人员成本必然越高。那么是否有必要提升这个配置等级，最终取决于业务上的要求。例如，有家单位做了仔细的测算分析，一个小时业务中断的损失可以达到800万美元，这样的数据中心，当然就值得提升值守的配置等级。有些业主外包数据中心运维的时候，为了节省成本，一味压低运维人员配置的要求，这样必然导致机房故障概率提升，最终很有可能得不偿失。”3 组织架构
听了吴先生的话，Peter掐指一算，自己这机房规模这么大，设备这么多，运行的业务这么重要，值守人员的配置怎么也得按A级，每个班组得配3～4个人。“好，我就安排每组4个人，4组轮班。整个团队的架构应该怎么设置呢？”
薛先生拍了拍Tom的肩膀，“你这位兄弟就可以做你的运维经理，帮你整体管着运维的事情。他下面招几个技术好的二线支持人员。这些人平时主要是上白班，负责提供技术支持、编写操作流程、设定运维保养计划，当然，有必要的时候也得值班。然后就是你的一线值守团队。要说起来也不复杂。”
吴先生摇了摇头，对于薛先生这种简明扼要的回答表示不赞同：“没那么简单。团队的组织架构，包括每个岗位的职责，必须非常清晰地定义好，而且要确保全员都非常了解。这样做的目的是当遇到问题的时候，大家都非常清楚自己的工作是什么，各司其职，不会手忙脚乱。而且岗位职责定义的时候，要考虑某人不在的时候，谁来顶替他的职责。就像打仗一样，如果一个连长受伤了，那后面谁来接他的领导位置来指挥部队？这事先都要界定好。我就见过一个机房出事的时候，本来所有事情都要请示一位总监的，可是总监恰巧出国无法联系上，大家就都不知道该怎么办了。所以A－B角的事先设定，很有必要。”
Peter听完几轮谈话，已经对于自己将来的运维组织架构胸有成竹了，Tom也对于自己将要领导一个兵强马壮的运维团队，感到十分兴奋。明天就开始招人，可是招什么样的人合适呢？4 人员资质要求
哲学家薛先生说话了：“数据中心维护团队中有这么几种角色，是不可或缺的，就如唐僧的取经团队，需要目标明确的组织者，他的作用是围绕着数据中心的整体目标，把各种资源进行有机的整合，持续改进维护体系，绝不放弃。”说这话时，他瞟了一眼Tom，Tom顿时觉得自己离唐僧的境界还有比较大的差距，后续担子还不轻。
薛先生继续发表高论：“除了组织者以外，还必须有对技术的执着追求者。根据海恩法则——每一起严重事故的背后，必然有29起轻微事故和300起未遂先兆，以及1000起事故隐患。面对各种莫名的问题，一定要有一个刨根问底、不找到原因绝不放弃的技术管理专家，因为只有这样才能把隐患消灭于无形。默默无闻的执行者，行百里者半九十，西天取经挑担子的人是多么重要，恐怕只有孙悟空最清楚。如果让他去每天完成千篇一律的日常工作，恐怕激情早已磨灭，半路就要回家了。”
Peter说：“我准备从国企挖来的那几位电工师傅倒真的很符合这种标准，有点啥事非要刨根问底，特别认真。老一代革命同志确实不一样。现在年轻人能够沉下心来做工作的不多啊。”
薛先生还没说完：“这几种人你必须得放对位置了，如果让技术狂人总体负责，那么犀利的语言、对技术的不懈追求，往往让整个团队内耗不停，累呀！如果让一位只顾低头拉车的老好人全面负责，大家每天都高高兴兴，因为看得见的工作他已经都干了，看不见的工作无人理会。根据墨菲定律，只要有隐患没有解决，那么一定会出事的，只是早晚的问题。”
Peter对薛先生笑道：“你这一晚上给我们说了几个定律了？好了，赶紧给我点实用的。我招一线值守人员需要他们有点啥资质吧？”
薛先生被从哲学境界拉回来，感觉意犹未尽。他又点了根烟，说：“如果从技术能力上谈，那就是最基本的三证：电工证、暖通证、高压操作证。没有这几项证，是不能上岗的。但话说回来，现在有些认证机构给证是很任性的，所以有证的人是否真正具备了相应的能力，还需要实际评估，这个你懂得。”
Tom问道：“这些人需不需要分专业呢？能否让他们做到一专多能呢？我以前就是既管IT，又管UPS和空调。”
吴先生笑道：“你这个一专多能，就看你专到什么程度。你们原来的机房小，UPS无非几台小功率的，超不过200kVA，对吧？空调也是很简单的风冷空调。整个机房系统都比较简单。而且你们也不承担真正意义上的运维保养，有什么事就把UPS、空调的供应商叫来，对吧？”
Tom点了点头，在他原来管理300平方米机房时，给他们供UPS、空调的代理商进他们机房，就跟进自己家一样，熟门熟路，通行无阻。实际上这些人都已经成了他的外围运维资源。他是不给他们费用的，但是作为回报，Tom也会照顾他们的生意。买硬件送服务的习惯，导致大家都没有采购服务的概念，都把这部分成本摊到设备采购的隐形费用中。
中国人以前的习惯是搬家找朋友帮忙；装台电脑，找周围朋友帮忙；做个机房规划，找周围懂行的人帮忙；做个设计，也找周围懂行的人帮忙。作为回报，当然会请人吃饭。但其实这些被拉去帮忙的人的心里话是：给我折现了吧！
这些年随着专业服务商的出现，这种习惯有所转变，尤其在大城市，大家的时间成本都很高，对于专业服务能力的价值也都比较认可。但在很多二三线城市，专业服务依然还没有被充分认可。
吴先生继续说道：“对于大型数据中心，尤其你们这么大规模的数据中心，在电力上已经配备了10kVA中高压设备，这方面的操作就牵涉非常严肃的电力设备的专业知识了。如果专业知识不够，轻则导致系统中断，重则可能导致人员安全问题。你看人家电力行业，对这方面就有非常严谨的要求。所以，我的建议是你们应该按专业配备人员。尤其刚才你们讲了，你们希望值守的级别是A级，就是一旦有问题当时就能处置，那么现场人员如果不具备一定的技能和经验，怎么能做出处置方案呢？即使事先设定了很多运行时的应急预案，也需要专业人士来判定哪种预案更合适。更何况有些事件表现出来的状态未必100%是按照你们的预案描写的。所以，需要按专业技能分工，要求他们达到一定的技能。二线人员就更需要按专业了，他们必须成为自己专业的专家。”
看看表，时间已晚，虽然都是好兄弟，但Peter也不好意思再占用两位专家的时间。连连对两位专家拱手，感谢兄弟们的宝贵时间。而且感觉多和行业里的同行交流很有必要，尤其在人员配置这种让老板花钱的事情上，光靠自己说不行，必须和老板聊别人家的“最佳实践”。别让老板光看到“别人家的机房”好，看不到别人家的投入。宝德（深圳观澜）云计算数据中心——中国领先的中立数据中心及云服务提供商Chapter 3 网络运维1 网络设计
如果把数据中心设施想象成一个黑盒子，这个盒子有两根与外界连接的重要线：一根是负责输送电力的电力线，另一根是负责通信的网络线。如果比较这两根线的重要性，那么网络线似乎更加重要。因为电力线如果中断了，还可以靠设施自带的发电机来弥补动力供给；而网络线如果中断，数据中心就成了名副其实的信息孤岛。之前发生过某宝的数据中心被挖掘机铲断了网络线，就导致了影响业务运行的重大故障。
Peter深知网络对于数据中心的利害关系。所以，他手下还有一位毕业于某邮电学院的强将Jack。Jack和Tom：一个管网络，一个管设施，是Peter的左膀右臂。
设计网络系统时，Peter组织了一群网络技术专家，邀请了多家国内外知名厂商一起参与设计，加上Jack手下的网络运维骨干，经过多轮讨论，大到网络架构、设备选型，小到路由协议、端口配比都进行了详细的论证。“传统网络架构稳定成熟，”Jack说道，“个人认为应该切合业务构建大二层网络，至于是VPC还是VXLAN，技术问题都不大”。网络设备厂家的技术人员也提出了很多见解和建议，会议室热闹非凡，大家都表达了各自的意见，并最终达成了共识。“非常感谢大家，经过讨论，出口路由器双平面+核心接入交换机大二层组网是最适合咱们数据中心的核心网络架构，既能保证出口的冗余安全，又能保证业务层对大二层组网的需求；出口路由器还是用400GB平台的高端产品，核心交换机采用堆叠方式与接入交换机VXLAN大二层组网。” Peter在设计初审会上敲定了网络设计方案。
这高大上的数据中心将有两个核心网络机房，并且两个核心网络机房物理隔离、供电冗余配备，核心网络设备自然平均安装到了这两个机房里，保证即使一个机房发生火灾、断电等情况也不会阻断互联网络出口。如果有了冗余的网络路由，就不会轻易地被挖掘机的一铲子把业务都中断了。2 网络割接
接下来便是新网络系统割接入网的重要环节了，割接入网小组迅速成立，Peter责无旁贷地担任总指挥，入网方案之前已经过多次审核，直到细节无一点疏漏，设备已提前加电、拷机、刷系统、打补丁，确保稳定运行，包括入网环境也在入网当天认真检查，确保凌晨的入网万无一失。晚上11点，数据中心核心机房里灯火通明，Peter身边已围了一圈人，有今晚负责割接入网小组组长Jack，还有运维骨干工程师Tim，若干经验丰富的设备厂家工程师和施工人员。Jack发令道：“请最后检查各自负责的部分，如无问题新网络系统将于凌晨准时入网”。随即大家各司其职，检查设备运行情况、传输链路情况、网络设备配置调试情况、入网环境情况等，30分钟后回报一切正常可以按计划入网。随着时间逼近，大家心里都不免有点激动和紧张。
凌晨到了，大家精神抖擞，第一步先进行最重要的出口路由器入网工作，随着链路的放通，BGP协议邻居已建立正常。“收全球路由”，
试读结束[说明：试读内容隐藏了图片]