1 设施运维管理目标该如何设定?
　　
　　如何设定设施运维管理目标是数据中心业主或管理者首先应该考虑的问题,合理的目标是激励运维团队进步、确保数据中心整体目标达成的关键因素。过高的运维管理目标,会使运维团队背负过大的压力,从而造成人员流失、运维保障能力下降;过低的运维管理目标,不利于运维团队的进步和成长,也会影响数据中心整体目标的实现。比如:现在很多数据中心的运维目标是零故障,也就是说比可用性100%还严格。这就是不科学、不合理的目标。没有哪个人能确保数据中心成千上万的设备不出故障,今年没有故障,也不确保以后不出故障,设备、系统都会老化、变化,怎么能不发生故障呢?
　　
　　因此,数据中心管理者在设定运维管理目标时,需要和相关业务需求部门、运维管理部门进行沟通,哪些指标是不可妥协的?哪些是可以商量的?数据中心的设施系统,是支撑和服务业务的,并不是所有的业务都是24h不间断运行,也不是全年都全负荷运行。比如:证券行业的核心保障时间段是交易时间,节假日就是非重点保障时间。银行业务虽然全年连续,但夜间的交易量远小于高峰时段,也可以提前公告暂停服务。针对这些特点,可以给运维管理团队设定不同的保障目标。也要允许其有合理的停机检修时间。
　　
　　运维管理目标也应是多维的,互相制约的。可用性或安全目标,无疑是运维管理的最重要目标,但能效、费效比等,也是数据中心业主和运维管理方都应该讨论的关键目标。俗话说:有多少钱办多少事,没有免费的午餐。数据中心是一个能耗集中中心,每年的能源开支是巨大的成本,如何在确保可用性的基础上,尽可能降低能耗?有很多文章可以做,也是考验运维管理质量和责任心的。设施运维,每年该花多少钱?也是大家都关心的问题,中科仙络程小丹董事长专门收集整理了外国资料,在2018年数据中心设施论坛上海站分享给了大家。这个数据仅供大家参考,国内数据中心运维模式、人力成本、能源价格都极大地不同于美国。
　　
　　运维管理目标的设定,和数据中心的硬件设施等级有一定的关联,但不是完全的一致。国标A级或TIER4级数据中心,在硬件系统配置上比其他等级有更高的可用性,但不是说其故障率就一定低于后者。可用性是指某设备发生故障时,系统的功能和性能没有受到根本的影响,业务没有受到影响,这是通过隔离、旁路故障设备实现的,是设备系统的冗余部分起了作用。可用性不代表故障率,反之亦然。高可用性的系统,或许因为设备之间更复杂的关系、更多的设备,发生故障的次数会更多、几率会更高。因此,如果要求国标A或TIER4等级数据中心的设施可用性达到99.999%是合理的,那要求设备可靠性也是99.999%(故障率10万分之一)就是不合理的。他们之间不是线性关系。
　　
　　对于本身条件不好的数据中心,比如C级或更低的机房,也可以通过良好的运维管理来提升其可用性。人可以笨鸟先飞、勤能补拙,数据中心也一样。更频繁、更细致的巡检可以提前发现故障隐患,及时消除。反之,对于无人值守数据中心,可以通过建设高等级的冗余、容错来确保一定的可用性。因此,不必A等级数据中心就得要A等级的运维管理,C等级的数据中心就只配C等级的运维管理。
　　
　　鞋合不合脚?只有脚知道。同样,数据中心设施运维管理目标设定得是否合适,也只有你自己知道,但没有目标肯定是不合适的。
　　
　　2 运维管理边界在哪呢?
　　
　　确定了运维管理目标后,运维管理团队需要确定管理的边界在哪儿?管理范围是哪些?有些运维管理者抱着多一事不如少一事的心态,该管的没有管到,留下隐患;有些运维团队喜欢大包大揽,管了不该管的,制造了矛盾,吃力不讨好。找准自己的管理边界,且双方或多方有效确认,并不是一件容易的事。
　　
　　首先我们看看对外的边界,数据中心运行离不开电力,那首先应该确认供电的界面。大体上讲,市电进入后的第一个连接点之后,都是数据中心的范围。那高压部分的接入柜、补偿柜、计量柜、馈电柜就都是数据中心需要管理的。10kV及以上的高压,各地供电部门有严格的运维要求,必须按其规范执行,甚至要求用电单位必须配置专门的高压运维班组,必须持有供电部门颁发的上岗证、操作证。甚至,有些在数据中心园区内的高压电缆也需要用电单位来巡检,高压电缆资产可能也是用电单位的。因此,需要理清和供电单位的资产界面和维护界面。
　　
　　数据中心运行也离不开水,即使没有使用水制冷系统,数据中心的生活用水也是必须的。供水的界面和排水的界面都需要理清,甚至还有洪涝排泄的界面。对于一些建筑在江河湖边的数据中心,排水与防洪的界面更是重要。排水管理不当可能被水务部门和环保部门处罚,防洪管理不当可能招致灭顶之灾。有些数据中心还有燃气供应、市政供热、燃油供应的界面需要理清。
　　
　　其次是数据中心的对内服务边界,这个也大体上统一,基本是到IT设备的供电端,即IT机柜上的PDU插排。但有些数据中心的IT部门和设施管理部门的分界点在IT机房,设施运维人员不能进入到IT机房,这时就无法负责到PDU,只能到UPS(高压直流)输出配电柜的输出端。那从输出端到PDU的中间电缆,成为两不管地带,成为以后的安全隐患。以机房为分界点的,空调制冷温度控制的管理也相对较差,能效低。因为空调管理人员无法知晓机房内的负载情况,气流情况、温湿度情况,只能把空调设备全开,设置一个自认为合理的参数。同样,对于机房内的消防设施、监控设施、地板、吊顶等,也是无法做到充分的运维管理责任。因此,内部以机房为分界点的做法是弊多于利。
　　
　　数据中心的运维横向边界可能有时更复杂,取决于数据中心的规模、建设和运维模式、应用模式。超大规模的数据中心,有时在内部按专业划分运维界面,比如分为:暖通部分、电气部分,分别是不同的运维团队。这可能会产生一些问题,比如:空调的供电系统是谁负责运维?谁来保障暖通系统的供电?有些数据中心是联合建设,其运维管理的模式也是多样。有些数据中心是部分出租,或出租给多个客户,这些用户的要求不一样,导致的管理界面也不一样。
　　
　　非独立建筑内的数据中心,其运维管理可能涉及到物业管理单位、安保单位、行政管理单位等,特别是供电系统、制冷系统与建筑其他部分共用时,管理界面更复杂。如何监督、检查上级部分的运维质量,如何确保不影响数据中心的供电和制冷,是非常考验运维团队的。
　　
　　有些数据中心的部分运维工作外包,工作外包了,但管理和责任不能外包,也应该在管理范围内。
　　
　　图1是管理边界的参考图,划分和确认管理边界是运维管理的首要工作。
　　
　　3 运维跨前管理如何实现呢?
　　
　　运维团队接手数据中心,绝不是等数据中心建设完成后才开始,应该尽早参与到数据中心的前期建设全过程中,包括规划、设计、供应商和产品选型、建造部署、验证测试和移交。需要提前请各相关方面把运维的需求在各个关键环节考虑进去,并落实在建设过程中。一旦数据中心建设完成,若再为运维需求增补、改造,既增加了投资成本,也大大延误了投产时间,给业主带来较大损失。因此,数据中心业主方也应该在建设前期就要组建有经验的运维团队,要求其参加到建设过程中来。运维团队的组建、培养、训练需要一定的时间,参与建设全过程也是锻炼运维团队的最佳方式。
　　
　　(1)参与规划设计
　　
　　规划设计是数据中心诞生过程中最重要的时期,运维团队应该在此阶段提出运维需求,并仔细核实每个细节。提出运维需求一方面是从降低运维难度,提高运维便利性出发,更多是从降低运维费用、提高运营效率出发。比如:出于高等级的安全设计考虑,两个区域有物理分割,运维人员巡检时不能直接穿过,需要绕行较大区域。如果这里有一个安全门,运维人员可以借助这个安全门通行,则可以方便很多,节省时间。
　　
　　数据中心运营成本中,很大一部分是电费,由于数据中心投产初期,负载并不多,导致PUE值较高,能耗高。从降低运营费用看,系统设计应考虑小负载运行情况,并有所体现。比如,冷水机组中有一台是变频的,那初期的设备系统投运就不一样,会节省大量电费。
　　
　　系统的可用性更多是设计出来的,运维团队可以根据运维经验提出合理化建议和要求。比如:冷水管路中某处增加一个阀门,可以有效分离故障管路,便于检修。增加的成本是微乎其微的。
　　
　　(2)参与供应商的遴选
　　
　　选择产品、设备、系统的供应商,运维团队需要更多的调查供应商的质量口碑、产品可用性、可维护性、服务能力,这些比产品功能、性能、价格更能影响到后期的运维和运营。采购部门对产品的关注点通常不会太多在后期,他们考虑性价比,而那些影响运维的东西很难包括在性价比的分子中。运维团队需要将产品的质量、可用性、维护性、服务能力都量化,并增加到产品的性价比的“性“中,才能全面、公平的体现性价比。
　　
　　运维团队不仅是对供应商的选择提供参考意见,更多是需要了解不同产品的关键差别,并且参与到产品的安装和调试过程,对后续的运维要求详细询问和做好准备。
　　
　　(3)参与建造过程
　　
　　数据中心的建造过程非常复杂,影响后续运维的因素也最多。比如:电缆的路径,如果不清楚,以后排查故障、检修就非常困难。比如:管路阀门安装的位置、操作盘的方向,是否利于操作。因此,运维团队在建造过程中,多到现场实地考察,多考虑是否便于运维,及时提出要求和建议,是非常有好处的。
　　
　　数据中心的建造工艺也不断革新,运维人员也需要不断学习和了解,以便在以后的维修、改造中能正确应用。
　　
　　总之,你现在跨前得越深入,以后的运维越得心应手。
　　
　　4 验证测试应主导
　　
　　验证测试是数据中心建设过程中的一个必要环节,已经为广大数据中心从业者认可,在数据中心建成投产前,或多或少都进行了验证测试。但各数据中心对验证测试的重视程度、实施方式还是有很大的差别。
　　
　　首先,验证测试的主导方,应该是建设团队、运维团队,还是独立第三方?笔者认为应该是运维团队或使用方。毕竟运维团队最终接手数据中心的后期管理和运营,前期的建设结果如何?直接影响到后期运行和管理,运维团队是最终的利益相关方,因此,运维团队有理由和责任来主导验证测试。尽管通常有独立第三方参与和实施验证测试,那应该是在运维团队的主导下进行,第三方提供了验证测试中的人员、设备、服务的保障,也一定程度确认了验证结果的公正性。至于验证测试的大方向、关键流程、节点、方案、结果,运维团队都应该把控,避免缺漏。对于为客户定制建设的数据中心,客户无疑是验证测试的主导方,对建设结果进行检验。
　　
　　其次,数据中心业主或建设方,应该给验证测试留够必要的时间和预算。实际操作中,为了赶工期,验证测试的时间经常得不到保证,本该30天的验证测试被压缩到10天,本该10步流程被缩减到3、4步,致使验证不充分,问题隐患不能充分发现,验证测试的意义和成果严重打折。验证测试不仅需要充分了时间保证,也需要充分的预算经费保
障。过低的价格招标来的第三方,必然在验证时间、验证投入人力、人才方面打折扣,也使得验证结果严重打折。
　　
　　再有,运维团队不仅应该是验证测试的主导方,也应该是验证测试参与方和被测试方。运维团队在建设和验证测试过程中,可以充分操作和理解设备、系统,过了这个环节,运维人员基本不再能自主操作设备了。因此运维团队必须充分利用这样的时间节点,实际操作、吃透每台设备。验证测试,也是对运维团队实际操作能力的检验,这点常被忽视。特别是系统的整体联合测试,运维团队必须亲自操作,不要依赖设备厂商和集成商,才能真正得到检验。裁判员也得参加体能测试。
　　
　　最后,运维团队只有充分参与了数据中心的规划设计,对设计理念、设计逻辑有充分的理解,才能在验证测试环节对相关设计理念和逻辑进行验证,才能对测试验证项目和方案的完整性进行把关,才能对验证结果有正确的评判。所以,我们一直倡导运维团队尽可能早地组建和参与到数据中心的建设过程。
　　
　　对于接手已经运行中的数据中心运维,运维团队应该进行充分的健康评估和风险评估,这既是对自己负责,也是对业主方负责。应该和委托方就数据中心已知的问题和风险进行沟通交流,双方明确各自的责任。能够整改的问题,应该在整改后完全移交;不能整改的问题,双方应制定合理、必要的预防和应急方案。比如:对某高温区域增加人工巡检频次。然而,有些数据中心频繁更换运维外包团队,看似压缩节省了运维外包的费用,实际给自己增加了巨大的风险。每个新接手的运维团队,都不可完全、充分地发现和识别出问题和风险。其对数据中心的了解和熟悉需要一定的时间,刚有些熟悉就被更换了,是最大的浪费。

　　编辑：Harris