1、最近这一两年,中国的数据中心还是发生了不少事情。有些是好的,更多是不好的。当不好的消息传来,第一反应是心痛:又有一堆同行要被老板点名了(尽管他们一直盼着被老板点名)。数据中心这么小众的领域,这么小的圈子,很可能倒霉的就是你熟识的朋友,他们辛苦半生,有可能因为一次故障而改变人生的步幅,甚至方向。
　　
　　回过神来,又不免悻悻然,甚至暗地里飘飘然。毕竟不是自己的阵地失守,别人丢了阵地,那不是反衬了我的阵地守得好吗?这是非常要不得的想法。春光乍泄就打住,千万别再往下得意了。不要等墨菲找上你的时候,前一个笑容还没来得及僵硬。
　　
　　2、人生充满了偶然。人生又暗含定数,写着必然。以及,偶然堆积而成的必然,和必然之外不能承受的偶然……
　　
　　数据中心也不例外。在高新科技园靠着深南大道的南侧,有一栋不高也不低、不算漂亮也不丑的建筑,叫飞亚达大厦。顾名思义就是飞亚达拿地并盖成了商业楼宇,不过除了一间小小的钟表展厅以及高圆圆的大幅海报还昭示着飞亚达的存在,更为人熟知的,是腾讯曾经并还在这里办公。
　　
　　飞亚达的五楼,有一间历史算得上悠久的数据中心。说悠久也不过十年出头的光景,但它毕竟接待了许多当年盛极一时的鹅厂业务,比如QQlive,后来才转为IT功能。机房不大,针头线脑却不少,在不同时期不同应急场景下增添的飞线,后来是没人敢碰了;加上假双路市电,一台残破的柴油发电机还只给分配300A的容量,硬件上连Tier3都达不到。
　　
　　按理说这样一个低可用性的机房,随时出点什么事都是可以接受的现实。偏偏十几年光阴裹挟着台风雷暴呼啸而过,机房稳得一比,竟然连个像样的故障都没有,业务更是从来没有中断过。更多时候,所有人都遗忘了在人来人往的大厦中间,还有它的存在。是概率论失效了吗(凑巧)?还是因为人品太好(宿命)?反过来看最近这些年发生的多起重大故障,数据中心规模都是大型甚至超大型,硬件条件不是Tier4-至少也是Tier3+,偏偏就一头往小概率事件上撞
　　
　　上了……而且,是好几个小概率事件凑巧撞在了一起。但凡有一个小概率事件不发生,也许就解救了这次危机;概率论在这里同样失效,因为它们偏偏就扎堆儿发生了。每次重大故障复盘,这样的申冤之辞最为常见:其实这个(引发故障的)问题我们早就看到了,优化方案也评审完成了,预算也申请了,可刚做了一半就……你说我冤不冤!当故障发生,你费尽心血搞到的MO认证,你保持了1024天的无故障运行纪录,你引以为傲的业界最低PUE……这些亮闪闪的光辉,都变得毫无意义。你只想说:墨菲,我信你个鬼,你这个糟老头子坏得很。
　　
　　3、1941年,美国一名安全工程师海因里希通过分析工伤事故的发生概率,为保险公司的经营提出了一条300:29:1法则,这就是著名的海因里希法则(Heinrich'sLaw)。这些年数据中心领域广泛引用这条法则,并引申为:每一个重大事故背后,一定有29起轻微故障,以及300项潜在的故障隐患。
　　
　　我们总以为是毫无道理的偶然,很可能其中就有我们不甚关注的必然。偶然是无法预知也无法控制的,我们所能努力的,都在可见可预期的必然里。把300的问题解决了,29可能就变为2,而最上面的1也就变成了0。用广东话说,“做就要做到尽”。只有这样,哪怕最终故障还是发生了,但既然该做的都已经全部做到位了,君子坦荡荡,小人常戚戚;而不是一复盘钻出来好多人为因素。
　　
　　在数据中心全生命周期的不同环节,我们能做哪些事情,做得如何,具有必然性。这也是数据中心团队之间拉开差距的地方。
　　
　　首先是设计阶段。
　　
　　十年前中国的数据中心还很土的时候,我们会为了一个复杂而炫目的系统架构欣喜若狂,到今天谁都知道了最简单的架构才是最稳定的。
　　
　　一个简单的2N架构,区别只在于用交流还是直流,用冷冻水还是间接蒸发,即便是微模块,内行的设计师也只需在人群中多看她一眼就可以画出图来。
　　
　　因此,设计上的差别到今天已经没那么大了。除非是跨界团队的粗制滥造之作,通常重大的设计缺陷是不大会有的了;小缺陷则不然,因为大多会跟具体的运营细节挂钩,因此小缺陷一大堆,或是个别几个,这里是有大差距的。有时候看到一幅考虑周全、干干净净、绝不打架的综合管线设计,就能从中窥出设计师的美貌来。
　　
　　然后是设备选型和招标。
　　
　　要不要白名单,白名单要严控到什么程度,这也是业界讨论较多的话题。好比把一台吉利汽车和一台奔驰车放在一起,排量、马力、扭矩等重要参数都基本一致,外形相似度70%以上,吉利的油耗指标甚至还要胜出,更别说价格,那么你还有什么理由选择奔驰呢?
　　
　　技术要求(参数、指标)往往不能反映工艺和口碑,拉不开差距。而一旦吉利进入白名单跟奔驰平起平坐,由于招标准则的低价中标原则,等于是宣判了奔驰的死刑。该坚持的,还得坚持。
　　
　　到了建设阶段,金木水火土各工种齐齐上阵,总包分包设备厂商天天你来我往,与甲方代表、项目管理轮番交战,不亦热闹乎。永远不要小看工程队创造意外惊喜的能力,当你觉得你的底线遭到挑战的时候,一定会有人再一次突破它。隐蔽工程,一旦真的隐蔽起来,就啥也说不清了;一个小小的虚焊点,有可能酿成两年后的一次重大故障;奇葩如斯夫可以连配电相序都接错,要不是测试验证之前的检查,通电的后果不堪设想……必须先默认施工队伍是一定会犯错误的,然后再反向精准打击,不给其犯错的机会,或者减小概率。除了工艺质量,进度则往往是业务部门强势介入的突破口。随着建设周期的一再缩短,业界奇迹被一次次地刷新,一个个奖杯发下来。殊不知一个个坑就在那些夜深人静的疲劳施工中埋下了,不过不要紧,反正那些坑至少也得三五年后才会暴露出来,不影响咱这一波操作的光环……
　　
　　尊重客观规律,严控质量关。这是每一个项目管理人员应该多加思考的地方;差距往往也在这里。监理和项目管理作为代甲方的角色是可以起到关键作用的。当然,前提是要确保裁判员没有被运动员收买。
　　
　　前面提到的测试验证,是运营团队的终极大杀器,最后一道关卡。
　　
　　早些年的多方联合验收其实就是走个过场,验收主要基于观感。最近几年第三方测试验证成为标配后,一下子较起真来,让厂商们恨不得三呼万岁。
　　
　　假负载打到100%实测4小时以上,测到兴头上就再往上打到110%看看;吃不太准的就重测一遍。20天测下来,隐患或不合格项至少150项起,跟海因里希的300遥相呼应,其中的十多项,很可能就是未来将要发展为重大故障或超级大坑的好苗子。
　　
　　测试方案是否完备,测试过程是否严谨,测试分析是否专业,也是容易拉开差距的地方。测试过程打了折扣,效果自然也就甩卖了。
　　
　　这时候该运营团队全员上阵了,几十双眼睛盯着。他们将在今后长治久安的过程中越来越深刻地体会到,在这里投入重兵,是值得的。
　　
　　于是数据中心投产,进入漫长的运营期。
　　
　　凑巧还是宿命,运营团队是直接演绎者,最佳男主角的光环却永远不会套到他们头上。运营的很多事情,是可以反哺的,这里又可以拉出一个小长篇了;罢了,还是先按下不表吧。
　　
　　我们经常说金融类的数据中心综合可用性高,稳定,并不完全因为它的建设标准有多高,
　　
　　更多时候得益于其运营团队的谨小慎微,如履薄冰。
　　
　　4、设计的错漏,关键基础设施的质量缺陷,施工工艺挖下的坑,测试验证的马虎大意,都不是立马兑现的,有的甚至要到五六年之后,才从你做梦也想不到的方位,钻出来猛咬你一口。于是,处于生命周期大后方的运维,成为了勇敢的背锅侠。
　　
　　反之,如果前面几个环节的工作都“做到尽”了,就可以给运营团队省下大量填坑的精力,可以用来细化、优化运维,反向弥补可用性的短板;这样,也就不怕“偶然的凑巧”,也不会在凑巧之夜无能为力地归咎于“宿命的必然”了。这个世界哪里装得下那么多的宿命,大多数好的结果都是靠“认真”二字来改写的。

　　
　　编辑：Harris