GOPS全球运维大会由高效运维社区（GreatOPS）和开放运维联盟（OOPSA）联合主办，指导单位为工信部信通院数据中心联盟（DCA）。全球运维大会是国内第一个运维行业大会，面向互联网及传统行业、广大运维技术人员，传播先进技术思想和理念，分享业内最佳实践。

一、蓝鲸智云及云计算运维平台参考框架标准
云计算运维平台参考框架标准是基于腾讯的蓝鲸智云的开源项目总结归纳的，这个标准是一个全面的云计算运维平台系统的框架标准，规定了一个面向云计算运维环境的运维平台功能模块和能力要求。
有开源项目了，为什么还要做标准？
开源和标准其实都是一种标准化的模式，开源是代码的事实标准，提炼成文档形式的标准框架，是因为代码是给开发人员看的，但是对于我们的 CIO 或者客户需求方，当他在建设或者选择一个产品的时候，不看代码，只看标准，什么样的平台才是好的云计算时代的运维平台？
一起来看下标准。
1.1、云时代——运维变迁
运维对象的变革
从 VM、容器到应用，随着运维对象的改变，我们可以看到云时代已经来临，运维的环境非常复杂，不再是单一的环境，要管理多种复杂的环境。
所以，现在很多行业客户在云的环境下，它的原始运维系统要发生变化。传统环境下，企业在建设运维系统的时候，大部分模块是自己拼凑的，采购一些工具，各个运维工具之间存在重叠或者不互通的问题。
那么在云的环境下如果还是这样，成本就非常大了。包括政府行业、金融行业在内的传统企业客户，都希望有一套整体运维平台的标准，能够帮他们整体规划运维平台。
传统 IT 运维 VS 云运维
我们可以看到云时代的运维是很复杂的，已经不像以前一样，形式单一、范围局限，跟传统的 IT 相比，云时代的运维不管是从人员的成本，自动化的程度，还有工作模式都是不一样的，以前传统的运维是响应式的，救火式的，现在运维都应该是自发主动式的，动态感知、发现问题等等。
1.2、蓝鲸智云
蓝鲸的挑战
大家都知道腾讯的游戏的需求量非常大，上线很快，尤其是移动互联网的游戏，而所有的腾讯游戏的运维平台都是基于腾讯的蓝鲸项目，蓝鲸因为沉淀多年的技术运营支撑体系,承担着数百款业务线上的运营，包括线上海量运维、大规模并发，以及游戏不断的升级、变更等等。
兼容各种复杂的系统架构，运维能力是比较强的，所以在这种运维环境下的蓝鲸智云运维平台，先天的优势就是可以应对规模大，技术栈复杂，流量大，变更频发的需求。
所以这套平台可以满足这种环境的要求，而这种环境恰恰也是目前很多传统行业在转型过程中面临的云计算环境的需要。
比如说银行业或者金融行业，很多互联网金融产品也要很快地上线，这种应用开发也需要微服务架构的，同时也会面临高并发的情况。
互联网以前面临的很多应用需求，对平台的要求，传统行业现在都在面临，甚至工业智能智造也会面临这样的问题，包括工控系统能力的要求。
所以我们认为在这种环境下成长起来的蓝鲸平台，在面临云计算环境的运维，具有一定的先进性的。
蓝鲸智云的发展历程
蓝鲸的发展道路就是越来越智能化。在2009年，蓝鲸只是一个具有简单能力的远程读写和配置集中的系统，到2011年的作业时代，就能够实现操作作业化和页面操作智能化。
再到2013年的场景自动化，不仅能够做到跨系统调度的自动化、工具平台自动化、服务自动化，初步做到无人值守，到今天的智能运维，做到智能服务理论、智能系统、运维智能化及运营智能化，真正做到无人值守。
智能化主要表现在：
系统本身的智能化，系统决定是否发起需求，比如资源不够用了。
运维沉淀的很多数据，可以支撑运营，哪款业务比较好，哪款游戏在什么时间段受欢迎，以及支撑运营的规划等等。
蓝鲸生态圈
蓝鲸是开源的，大家可以下载它的源代码。
蓝鲸用户数据
可以看到蓝鲸从合作伙伴到企业用户都是非常多的。
所以为什么选择蓝鲸平台作为标准的基础蓝本。
根据我们对国内所有运维平台的考察，认为腾讯基于游戏商长出来的蓝鲸智云平台，具有功能完备性、技术运营、自动化和智能化的先进性，比较符合目前互联网环境下的云计算的很多特点。
第二，它是开源的，从代码程度已经做到了代码的标准化，有自己的生态管理体系。这个标准既可以作为蓝鲸自身的开发商管理标准，也可以作为业界的参考。在标准过程当中除了蓝鲸以外，还有很多运维厂商，包括客户都加入其中一起探讨出来的。参考框架里的很多要求，可能蓝鲸目前没有做到，但是是它们努力的方向。
1.3、云计算运维平台参考框架标准
那么一个面向云计算环境的运维平台要具备哪些功能模块的完备性呢？
从底层到上层，整个平台包含了运营保障，运营工具和运营决策三大块。
运营保障是最基础的基础资源运维层，包括 IaaS 管控，要满足私有云、公有云和混合云多种云计算场景。
运营工具是中间层，包括原子平台层和集成平台。原子平台是运维能力的核心模块，包括作业、配置、数据、容器和 AI。集成平台是在原子平台的基础上，进一步的能力综合框架，包括定制化桌面、开发、服务总线等等。
运营决策是最能体现智能化的应用层，可以只是简单的运维场景，也可以包括智能扩缩容、辅助运营等。
这里我们是非常先进的采用了运营的词，是因为很多运维的有识之士认为运维的发展方向应该是技术运营，而不仅仅是简单的工具能力，应该从技术方面能够支撑业务运营。
具体功能点
而每一个模块所具备的细分功能，可以从这个图上看出，这里不一一列举，大家可以下载标准详细看每个功能点。
需要注意这是完整和开放的框架，每个模块都是一个单独的工具。
1.3.1、运营保障
我们每一层再细看下流程。
运营保障层以解放运维为目标导向。
整个运维平台的理念，就是从运维到技术运营。
运营保障跟传统的运维平台本质需求没有太大改变，但是由于和很多新技术的结合，比如服务总线和微服务和容器结合，具备了更多的灵活性和可扩展性，解放了很多复杂的配置操作，更便于管理。
1.3.2、运营工具
运营工具层以 DevOps 理念推动工具文化落地。
运营工具在 DevOps 里面每个环节会提到，它包括 PaaS 平台的接口工具和自动部署工具等等。
1.3.3 、运营决策
运营决策层是数据驱动运营分析, 实现智能决策。
大数据智能化把各个平台的数据收集起来，供运营的决策者做一些参考。
接下来我们再看每一层中的几个关键模块。
1.3.4、IAAS 管控层
管控层可以管控不管是公有云、私有云还是混合云等等异构化的资源池。包括网络、CPU、存储、各种操作系统、各种小型机 X86等等的管控，而且是一个跨云的，可以实现跨数据中心的管控。
1.3.5 、原子平台层
原子平台层面向的是服务器和技术资源的管理能力，包括作业平台、数据平台、容器管理还有 AI 的管理。
原子平台层是所有 IT 运维系统的核心，这里面增加的容器管理模块和智能运维模块。容器管理模块，刚才所有的 CICD 也好，自动化运营也好，都离不开容器的模块。
智能运维，就是 ETL、存储、读写等数据初步的搜集和处理，供运维场景层分析决策。
1.3.6、集成平台层
集成平台层给开发人员看的，比如企业里的不同运营系统，可能一个产品线有自己的运营系统，是给不同的产品运营系统看的是集成平台层。
可以用调用底下任何模块的功能，这种集成平台层的展现包括像定制化的桌面、开发平台、开发框架、服务总线的方式。这一层是每个产品线的运营可以看到的。通过这个部署每个产品线的业务，在顶层的平台上。
集成平台层有点类似于微服务架构。我们可以看到它有一个 APP Engine，在微服务里面就是服务注册的地址。它把运维的环境通过集成平台层开发出来以后，我们不同产品线的人可以基于它来开发部署。
1.3.7 、运维场景层
从集成平台到往下所有能力，它可以实现的体现提炼出来的抽象的平台功能，包括基础的运维、CI/CD、智能决策、辅助运营等等。
1.3.8 、标准进展情况
我们的标准从今年的3月份开始的，到7月份就已经做完了。
在这里我代表我们整个编写组，也是非常感谢我们所有参与的人员，包括高效运维社区，腾讯等等，这个标准已经完成，并在 CCSA WG5 工作组立项。