来源:玉工讲技术 接着上一篇中的“从案例中找到规律和原则”话题,如下为个人总结的数据中心运维工作中需要遵循的主要规律和原则。 1、数据中心运维管理基本规律与原则 作为一个数据中心运维小白或入门者,结合自己过去的技术储备和实践经验,以下只是初步体会及总结。 1)运维管理基本规律 数据中心基础设施虽然看似庞大而复杂,但就运维而言没有特别深奥和无法理解的疑难技术,重点还是实践实践
来源:玉工讲技术
接着上一篇中的“从案例中找到规律和原则”话题,如下为个人总结的数据中心运维工作中需要遵循的主要规律和原则。
1、数据中心运维管理基本规律与原则
作为一个数据中心运维小白或入门者,结合自己过去的技术储备和实践经验,以下只是初步体会及总结。
1)运维管理基本规律
数据中心基础设施虽然看似庞大而复杂,但就运维而言没有特别深奥和无法理解的疑难技术,重点还是实践实践再实践;
一个实践经验丰富,动手能力强的工程师可以顶替几个人工作量,关键看有没有责任心、专研和团队精神;
认真履行巡检和定期演练,就像“量子力学引入的双缝干涉实验”所描述一样,设备正常运行也许会受到这些看不见“量子”等未知因素的影响;
高质量的应急文档可以弥补人数不够或缺AB角色等(即人员2N或N+1架构)问题,在文档建设方面分配足够的时间、人力、精力还是值得的。
2)运维管理基本原则
一切以服务协议级别(Service Level Agreement)为主从实际出发原则;
定期梳理机房内IT设备、管理好其生命周期,及时对其进行下电(拔掉设备电源线)或整改原则;
安全可靠经济性之间找到最佳平衡点原则;
善用工具并充分挖掘辅助设施所采集数据价值的原则;
善待运维人员,不要把电工暖通工看成脏活粗活儿原则。
数据中心运维工作需要循序渐进,结合实际场景和人员配置会产生不同的运维组织架构。只要做好以上
4条规律和5条原则,相信数据中心运维质量差不到哪儿去。好比托尔斯泰所说的:“幸福的家庭都是相似的,不幸的家庭各有各的不幸。”一样,我们也可以说:“好的运维都是相似的,不好的运维各有各的理由或借口。”
也许有人对“定期梳理机房内IT设备、管理好其生命周期,及时对其进行下电或整改原则”不太认同,说基础设施和IT设施运维应该分离,这个总结是本人结合最近的实践经验得出的。最近我们对两个老机房的IT设备进行重新梳理及下电操作,梳理过程中,我们从业务和应用(应用上线时间,是否还在使用,能否停止下电老旧设备等)角度对服务器、存储、交换机等IT设备进行了整顿,大致下电近30多台IT设备,相当于15000W负荷的下电(每年所节省电费一度电按0.55元算大约72270元左右),如下图1所示。
意思是,做任何事情,请不要忽视最终的服务对象(对IDC来说IT设备)。这个也是我为什么提出“善待运维人员的原则”原因,你不善待不尊重,那么他们凭什么操那么多心清理老旧设备进行下电省钱呢?业务原因没法断电理由有的是...
2、运维模型“适配”方法
我们说
数据中心运维
关键是搞清楚数据中心运维管理所涉及的具体工作内容和相关
设施关联
关系,我们继续讨论运维模型“适配”的具体方法。
首先收集数据中心
的供电回路数量、机柜数量、变压器数量、冷水机组数量、冷却塔数量、柴油发电机数量、UPS数量、蓄电池数量、末端精密空调数量数量等指标。接下来,除了这些指标覆盖的工作量因素外,还需按不同区域或机房楼列出如下表格所示的清单列表,以便充分考虑环境和外围因素:
图2 多个机房覆盖内容信息清单
如果没有考虑以上因素,那么我们人员平时的巡检和运维工作质量会受到影响。比如,数据中心公共区域及消防设施的清洁、巡检、检测等。这些都需要一定人员或预算的支撑。
最后,结合现有运维人员和IT负载所需的服务可用性指标或SLA指标,开始适配并构建运维团队组织架构。接下来举个具体例子来讨论另一个案例的“适配”过程。
3、实际案例的“适配”过程
某某数据中心基础设施建设完成后进入了运维初期,该阶段因没有大规模业务上线原因,需要结合现有人员和机柜投产使用情况,初步计划配置13人,产权方具体有数据中心经理1人,基础设施运维工程师7人(电气/暖通/弱电智能化工程师),云平台运维工程师2人。其中自建团队组织架构如图3所示。
图3 基础运维初期自建团队织架构图
该阶段需要各专业工程师结合建设过程中实践和积累细化分工,充分熟悉电气、暖通、弱电智能化等各个系统并归档各类基础资料,编制操作手册,为转型成数据中心基础设施运维团队正规军做好运维人员资质、专业能力培养、各项巡检和运维流程制度建设完善等方面的准备。
因数据中心投产(就算带少量业务)该阶段仍需要配置7*24小时值班和巡检岗位。原则上白夜休休方式分的四组(每组两人)的倒班配置,但试运行过程中出现现有人数不够,白天除了巡检以外,其他工作或机房没人维护或处理的情况(甲方的工作实际上不仅仅是运维本身的工作量),因此,该团队为了解决白班缺乏人手的难题,内部组织了讨论(讨论内容涉及到劳动法和特种作业操作安全等),结合现有人员与现场情况,对排班计划进行了优化,其中一年个轻成员提出了三组六人动态倒班制度。具体说将六名基础设施运维工程师平衡专业分成三组,A组两人实行“上五休二行政班”制度,B、C两组四人实行“四班两倒”制度(见下表)。轮换周期为两周,两周后B组行政班,A、C两组实行倒班制度,以此类推。
图4 基础设施运维三组六人动态倒班制
这样我们基本解决了中大型数据中心投入初期仅靠产权方的运维方案的适配过程。从这个案例讨论和试错过程中,本人也直接体会到“管理”也能产生生产力的道理。因为,技术人普遍讨厌写资料、开会、汇报等看似对实际工作没有多大“意义”的任务。从该案例中我领会到,作为技术人也应该把“管理”当“技术”的态度来学习必要性。如果充分利用IT技术和数据中心架构思想,好好培养运维团队成员,把压力和责任逐步下沉,让运维团队高效并行和分布式运行起来说不定更加提高运维效率,逐步达到事半功倍效果。运维过程中,我们得尊重动手能力和经验,同时也应该力求创新思维与过度经验主义之间的平衡,即一切从实际出发,将理论结合实践的原则不断尝试创新才对。
因为降本增效,可以尝试基础设施运维和云平台运维团队结合的混合扁平化模式。这种方式在中压电气关键切换操作时,既能确保至少3人(1个暖通+1个机电+1个IT工程师)现场操作的最基本要求,也能达到通过专业驻场(或外包)团队来培养甲方各专业程师的目的。
结合上一篇讲述的实际案例,一般中大型数据中心从专业化的分工角度,基础设施运维应至少配20人左右,考虑数据中心所带业务较少,为确保数据中心团队运维动手和操作能力的培养,可以考虑引入第三方承接单位,增加运维经验丰富的专业工程师2-3人(下图承接方红色文字区域所示),同时,如果数据中心大楼有消防控制室也得配备具有消防资质的消防人员来7*24小时值班,这样运维团队架构大致架构如下图5所示:
图5 基础运维混合扁平化织架构图
从上图5可以看出,为了减少运维成本,该组织架构既考虑了检修和维护的融合,又尝试了IT和弱电专业的融合。这里让IT运维融合弱电专业的主要原因之一是动环、BA等辅助设施的设备及系统几乎属于IT系统范畴,其数据备份与恢复、系统镜像、系统主备切换等实际上IT人员擅长的技术。在没有考虑消防、保洁等因素的前提下,只有13个人基本能承担数据中心L1和L2层的整体运维。
关于数据中心更多更专业的内容,建议大家除了实践,也不要忘记多看专业书籍。比如,《新基建:数据中心规划与设计》,这本书让我喜欢原因是从模型角度讲解数据中心。
玉工最近几年来最喜欢的两字就是“模型”,在我看来模型是事物本质描述的高度抽象和概括。只要我们脑海里建立了数据中心完整的模型,那么我们遇到什么场景,能够“适配”所需的必要团队及其他资源。
基础设施运维专业性比较强
且属于特种作业
,运行过程不允许出现操作失误。特别是涉及到10KV中压电气切换和故障处置,危险性较强,必须严格执行电力高压操作规程,相关操作和处置人员通过电力高压电工培训和认证考试,持证上岗。电气、暖通两个专业任何一个专业出现问题都可能造成整个数据中心停机
。
团队建设中这些因素必须要足够重视,不得有侥幸心理。
4、数据中心的服务对象
数据中心运维是重于实践和动手的新型基础设施工程,所涉专业和技术极为广泛。一个人能够快速掌握这些技术有效途径之一就是一开始结合某个具体(比如自己所维护的)数据中心建设和运维过程,聚焦学习和实践自己数据中心相关技术内容即可。这个阶段不必扩散学习范围,也不必学习数据中心更多的其他的技术,学以致用就够了。如果想学得更深或更广,那么需要学好相关的物理学、通信与计算机基础理论知识(虽然这些基础理论是硬骨头,但克服了我们会具备模型思维)才能快速建立数据中心技术体系,一步一步熟练电气、暖通、消防、弱电等专业设备操作步骤,在此基础上建立属于自己所运维数据中心的4P文档,确保数据中心安全可靠性和经济合理性之间的平衡即可。
如果再往后学,那就是涉及到数据中心的服务对象:IT设备与设施、云计算、网络、数据库等(即所谓的L2层)。数据中心中,L2层资源合理布局和生命周期的有效管理不仅降低数据中心电费“负担”,而且达到节能减排的目的(PUE值的降低)。如果这些内容都掌握了,下一步重点就是将数据中心产品化和服务化。拿破仑说过:“不想当将军的士兵不是好士兵”,作为技术人,我们时刻保持一颗上进之心和好奇心,不安于技术本身,要敢于跳出技术的边界,敢于接受营销、产品、管理等技术之外的另一种思维模式。既然将最难的技术搞懂了,只要我们愿意转变思维,我们会发现我们掌握的内容开始收敛,开始变“少”,在我看来,不同领域知识的本质和模型几乎都是相同,只是应用在不同实物或载体上而已。如果我们能够从服务和产品的角度思考运维管理模型,也许更加完善并优化图5中组织架构。
5、结束语
以上只是个人观点和实践中的体会到初步总结,若存在不足之处,望批评指正。当然玉工也在尝试不断实践中,结合自己过去IT和数据库领域的技术储备,尝试着跨领域知识的融合贯通。比如,玉工最近出版的著作“联动Oracle:设计思想、架构实现与AWR报告”也是以模型思维对数据库领域的专业技术进行融合和串联,对IT技术感兴趣的同仁们可以选读,领会其中架构思想、技术实现与理论融合的精粹。在数据中心建设与运维过程中,我惊讶的发现数据库80%的架构思想和理念,在数据中心领域几乎都能碰到或遇见。这也是我为什么喜欢“模型”两字的原因。