识别运维平台的边界在哪儿,才能更好地构建平台,从而协助运维的日常工作。
在之前的文章中,谈到过“运维的本质——可视化”,在可视化的篇幅中,着重介绍自动化的可视化和数据的可视化;在后续的篇章中又介绍了“互联网运维的价值体系”,里面分解了几个维度:质量、成本、效率、安全等。以上都是为了清楚地梳理运维的内容边界,基于这个边界,我们再考虑如何进行平台支撑。可以说前两篇文章都是为今天这篇文章作为铺垫,用理念先行,然后再考虑平台落地,最后再细化其中每个内容。我更习惯用如下的方式来整体表达运维的工作方法和思路。
首先, 价值导向 。找到一个价值方向来牵引整个团队很难,但又必须找到,因这个牵引力就决定了团队的气质及后续的工作方法;之前的文章“运维价值体系”有详述,在此不细谈。
其次要有一个分而治之的系统 ,最后面向业务自底向上的集成,此时便能帮忙实现 更好、更快、更省的交付价值 。平台的建设需遵循一些的方法(自底向上、先后顺序等),先建设各个运维专业子系统,通过API的方式对上暴露服务,最后不同的业务平台去调用这些服务接口即可。缺少平台的支持,运维的质量、成本、效率都会直接受到影响。
如果要做好服务器精细化成本控制,此时需要一个平台来处理从服务器资源上采集的资源使用状态数据,并生成可视化数据报表,共享到所有团队中,在一致理解下,去驱动成本优化,越海量的业务对这个平台的要求就越高,从采集、处理、模型算法等都有很高的要求。
不要忘了这个平台还包含面向业务技术栈构建的平台 。这地方有一个非常好的例子,在2012年左右,我了解到Google有一个非常强大的资源管理平台Borg(后面叫Omega),它的设计目标是“把数据中心看成一个芯片”。Google研发人员将开发的服务交给Borg,后续的服务生命周期(扩容、缩容、调度)都由Borg统一接管,服务被Borg部署到哪个IDC、哪个服务器,研发人员不用关心。后来Twitter根据Borg的思想,也开源实现了一个平台——Mesos,不过Mesos对LongTime的服务调度(如Nginx)支持不是太好,更适合MapReduce的事务调度。这两个资源管理平台背后的思想都值得深究,建议看看。
第三,基于平台,提供透明服务,确保服务提供者和服务交互者之间的交互越少越好 。有了整合性的平台,透明提供服务也成为可能。平台整合就是避免服务被碎片化,从而让使用的用户看到的不是一个一个工具或者孤立系统,而是面向业务的整合服务。此时成本便可降低、变更的质量也会变成一个稳定态。不同的人、不同的时间执行相同的事务流程都能取得一致的执行结果。
最后,数据驱动 。因所有线上业务服务和线下运维服务都有状态,需数据平台提供服务状态数据的采集、处理、分析处理能力,最后还能让运维人员自定义分析报表。技术运营数据和产品数据的一个很大的区别是,前者在数据挖掘方面的能力要求很少。这个地方有个建议,把线上服务的数据驱动作为重点(80%),把运维内部服务的数据驱动为辅(20%)。因为线上服务的状态会反作用于运维内部事务的优化。比如说从数据中发现现网的服务有一个故障,需要紧急发布版本,此时就会直接检验运维的变更部署流程、平台的完备性。
在平台体系部分,我采用逐级构建的方法,不断去细化其中的内容,因此会有一级视图和二级视图,在这个地方,我不敢到三级的模块级别,基本上不可看,下图是参照的是eTOM模型构建方法。
继续往下,可以分解出二级视图。
有了整体的平台体系视图,接下来看看每一部分到底是干什么的。
在ITIL中叫CMDB,Configuration Management Database, CMDB也可以理解成统一的元数据库,比如说机房信息、服务器信息、人员信息、服务信息、业务信息以及他们之间的物理和业务拓扑关系等,上层的所有系统都应该关联到CMDB,变更后的信息必须实时反馈到CMDB中,确保其他系统能同步这份变化。因此大家都把CMDB系统当作运维的核心系统来对待,便于后续各个系统之间的互通。
在我的经验中,CMDB建设还是有非常多的坑。如果你把iTop或者oneCMDB的产品当着标杆(都是开源,没见过商业的),那你的CMDB建设就完了。之前在一家传统企业,他们把文档都放到CMDB中管理,不建议这么做,文档就是SCM的事情。CMDB建设的核心准则:CMDB管理的数据一定要为了业务管理,业务管理上不需要的东西,就果断舍弃,比如说文档,和业务没有任何关系,就可以不考虑纳入,后续会有专门的文章介绍。
平台的目标就是自动化和数据化一切,并且最终可视化,从而确保质量、效率和成本几者之间的平衡 。但对于这么一个庞大的复杂体系来说,不可能一蹴而就,可以借鉴一下经验。
王津银,07年进入腾讯公司接触运维,先后在YY和UC参与不同业务形态的运维,对运维有一些理解。极力倡导互联网价值运维理念,即面向用户的价值是由自动化平台交付传递,同时由数据化来提炼和衡量。微信公众号:互联网运维杂谈。
感谢丁晓昀对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流。