识别运维平台的边界在哪儿，才能更好的构建平台，从而协助运维的日常工作。
在之前的文章中，谈到过【运维的本质--可视化】，在可视化的篇幅中，着重介绍自动化的可视化和数据的可视化；在后续的篇章中又介绍了【互联网运维的价值体系】，里面分解了几个维度：质量、成本、效率、安全等。以上都是为了清楚的梳理运维的内容边界，基于这个边界，我们再考虑如何进行平台支撑。可以说前两篇文章都是为今天这篇文章作为铺垫，用理念先行，然后在考虑平台落地，最后在细化其中每个内容。我更习惯用如下的方式来整体表达运维的工作方法和思路；
首先，价值导向。找到一个价值方向来牵引整个团队很难，但又必须找到，因这个牵引力就决定了团队的气质及后续的工作方法；之前的【运维价值体系】有详述，在此不细谈。
其次先要有一个分而治之的系统，最后面向业务集成，此时便能帮忙实现更好、更快、更省的交付价值。平台的建设需遵循一些的方法（自底向上、先后顺序）等等，先建设各个运维专业子系统，通过api的方式对上暴露服务，最后不同的业务平台去调用这些服务接口即可。缺少平台的支持，运维的质量、成本、效率都会直接受到影响。就拿服务器成本控制来说，需要一个平台来处理服务器资源（CPU、内存、磁盘、网络）的状态数据，并生成可视化数据报表，共享到所有团队中，在一致理解下，真正驱动成本优化；一个好的持续集成平台，能够不断把我们的产品新特性快速、高质量的交付给用户。
但最好的平台是直接基于业务的技术栈来构建的。这地方有一个非常好的例子，在12年左右，了解到Google有一个非常强大的资源管理平台---Borg（后面叫Omega），设计目标“把数据中心看成一个芯片”。Google研发人员开发的服务交给Borg，后续的服务生命周期（扩容、缩容、调度）都由Borg统一接管，服务被Borg部署到哪个IDC、哪个服务器，研发人员不用关心。后来Twitter根据Borg的思想，也开源实现了一个平台---Mesos，不过Mesos对LongTime的服务调度（如Nginx）支持不是太好，更适合MapReduce的事务调度。这两个资源管理平台背后的思想都值得深究，建议看看。Mesos的MR运行原理图如下：
第三，基于平台，提供透明服务，确保服务提供者和服务交互者之间的交互越少越好。有了整合性的平台，透明提供服务也成为可能。平台整合之后，避免服务被碎片化，成本便可降低、质量便是一个稳定态。不同的人、不同的时间执行相同的事务流程都能取得一致的执行结果。
最后，数据驱动。因所有线上和线下的服务都有状态，需数据平台提供服务状态数据的采集、处理、分析处理能力，最后还能让运维人员自定义分析报表。技术运营数据和产品数据的一个很大的区别是在数据挖掘的能力要求很少。这个地方有个建议，把线上服务的数据驱动作为重点（80%），把运维内部服务的数据驱动为辅（20%）。因为线上服务的状态会反作用于运维内部事务的优化。比如说从数据中发现现网的服务有一个故障，需要紧急发布版本，此时就会直接检验运维的变更部署流程、平台的完备性。
在平台体系部分，我采用逐级构建的方法，不断去细化其中的内容，因此会有一级视图和二级视图，在这个地方，我不敢到三级的模块级别，基本上不可看（这个是参照的eTOM模型构建方法）。分别如下：
继续往下，可以分解出二级视图：
有了整体的平台体系视图，让我们来一个一个的过一下每一部分到底是干什么的。
1、工作流引擎、权限管理。这两者都是基本的功能，因为其中会涉及到工作流，所以需要统一的流程引擎平台。另外需要部门、角色、用户的权限管理统一管理，不同业务只需要配置不同的使用策略即可。
2、基础设施物理层。这个视角和我们之前有些不同，在基础设施物理层这块，已经把云端资源看着一个底层基础设施来看待，因为后续的资源获取完全不同，其他的资源对象依然没有变化，依然是机房、机柜、网络、服务器等等。
3、配置及服务，把配置当作服务来看待。在ITIL中叫CMDB，Configuration Management Database，说实话第一次从ITIL书中看到CMDB觉得很诧异，怎么取名叫Database，一时很难和实际的数据库区分开来，因此我更愿意用电信领域里面的SID来理解。电信系统MBOSS系统特别复杂，对于一些共性数据或者元数据来说，也存在这个问题，因此他们提出SID（统一实例数据），SID就是存储所有共性数据或者元数据的地方，比如说客户信息、地址信息等等，其他系统需要用到这类信息的时候，只能通过接口去获取，自己保存只是一个镜像。CMDB也可以理解成统一的元数据库，比如说机房信息、服务器信息、人员信息、服务信息、业务信息等等，上层的所有系统都只能link到CMDB，变更后的信息并且必须实时反馈到CMDB中，确保其他系统能同步这份变化。因此大家都把CMDB系统看着运维的核心系统来对待，便于后续各个系统之间的互通。
在我的经验中，CMDB建设还是非常多的坑。如果你把iTop或者oneCMDB的产品当着标杆（都是开源，没见过商业的），那你的CMDB建设肯定就玩不转。之前在一家传统企业，他们把文档都放到CMDB中管理，不建议这么做。在我的经验，CMDB管理的数据一定要为了业务管理，业务管理上不需要的东西，就果断舍弃，比如说文档，和业务没有任何关系，就可以直接不考虑纳入。
我把CMDB资源分成三类：物理资源、逻辑资源、关联资源。具体的在后续CMDB篇章中再详细解释。
4、ITIL服务--基础、ITIL服务--高级。在早期的文章中把DevOps和ITIL做了对比，ITIL的是面向流程的，这个可以在运维平台建设中不做重点，不要主动去构建流程，会影响运维的敏捷性。基础部分实现一个事件和HelpDesk即可，事件管理在告警转换成事件之后，可以完整的记录便于我们事后的原因分析，能挖掘一些问题，比如说是否某个业务、某个人、某类机器经常性故障，那就需要重点关注下。高级服务的部分，大家需关注一下，它是可以带来价值的，比如说可用性管理、能力管理和连续性管理。可用性直接的导向就是业务的质量；能力管理直接的导向就是成本管理；连续性管理也是和质量戚戚相关，如业务的容灾、备份管理等等。但这些管理都不要在流程层面上去看，需要在一个平台中来进行全面的可视化管理。后续的篇章也会有相应的介绍。
5、基础设施及服务。把底层运维资源封装成一个一个的服务，供业务自动化平台使用。个人把DNS、LVS（或者F5）甚至OS上的配置管理都看着基础设施部分，适当的向上延伸了一下。简单的划分原则，在业务架构之外的，都可当着基础架构部分了。很多运维团队的建设重点都在这块。
6、架构及服务。把业务架构中的共性需求都剥离出来，抽象成一个一个的服务，最终让研发只需要关注自己的业务代码即可。这块对运维的质量、效率、能力等影响最大，在之前的文章中【如何化解研发和产品之间的矛盾】中有重点阐述过服务公共化是唯一的解决之道。现实中如果有研发开发了一个公共组件交给运维，而他不提供完整的webadmin或者api的话，你也就可以认为他是在耍流氓了，运维必须严格要求完整性交付。
7、数据及服务。只要有线上服务在运行,服务数据流经过的一切节点产生的数据，你都要采集、存储和分析起来，供不同的运维场景使用。比如说自动化调度，可以根据业务所涉及的基础节点资源使用情况，制定对应的自动化调度策略。和之前【数据驱动运维】介绍过的，我做了一个数据的分层体系。
8、监控及服务，有数据的地方才有监控。脱离这个原则，你做的都是告警。个人观点：所有的监控视图都是来源于我们对数据的采集以及我们到底有多少经验来看待数据。
9、持续集成。这条线是把一个一个的程序包交付到各个环境，在【持续部署】之上的部分可以通过和持续集成工具jenkins或者go作对接即可。持续反馈目前还没有见过运维实践是这么干过，而我觉得应该这么做。如果持续部署平台化之后，真正的执行部署工作会不断前移，甚至可能直接交付给研发。此时生成一个状态报告，更是有必要，这个地方更是和【数据及服务】的能力关联很大，没有前者数据报告根本无法生成。
10.面向业务的运维平台。不同的业务会有不同的调度策略和服务使用策略，需要在更上层完成面向业务的统一调度，这个是全应用的视角，和持续集成是有一些区别的。
11、运维统一门户。每个运维系统都有任务或者信息与自己相关，如果运维人员每天要去面对那么多的运维系统，会非常痛苦。在统一门户里面分成两个部分，一部分是任务中心，把底层所有的事务状态都同步到任务中心中，表示我要做什么；信息中心，就是让运维人平时关注的业务状态dashboard直接推送到信息中心中，表示我要关注什么。
平台的目标就是自动化和数据化一切，从而确保质量、效率和成本几者之间的平衡。但对于这么一个庞大的复杂体系来说，不可能一蹴而就，有些经验可以借鉴：
1、自底向上。一定要把握这个原则，这就相当于我们造车一样，把各个零件造好了，最后就是组装。
2、加强跨团队之间的合作与沟通。很多事情一旦研发、测试和运维彼此合作，事半功倍。在合作的过程中，把大家的经验都放到平台中，这样有利于后续的推广。
3、平台建设先后有序，优先级顺序如下：
P1(最高）：CMDB、基础架构及服务、数据及服务、监控及服务
P2(次高）：持续集成、面向业务的运维平台
P3(低)：ITIL相关、运维统一门户
以上所有供参考和讨论！
