澳门新萄京:流程应用平台推行之路,转型后的
分类:澳门新萄京

导读:阿里巴巴DevOps转型之后,运维平台是如何建设的?阿里巴巴高级技术专家陈喻结合运维自身的理解,业务场景的分析和业界方法论的一些思考,得出来一些最佳实践分享给大家。

欢迎大家前往腾讯云技术社区,获取更多腾讯海量技术实践干货哦~

前言

GOPS全球运维大会暨首届金牌运维峰会于11月17日-18日在上海圆满举行。国信证券负责运维平台建设,具有此类丰富经验的讲师张浩水受邀出席大会,并在DevOps道法术器专场带来针对证券及金融行业的精彩分享《证券行业DevOps第一步:IT资源自动化管理》。本文根据此分享整理而来。

GOPS现场

 

作者:梁定安,腾讯织云负责人,目前就职于腾讯社交网络运营部,任运维技术总监,开放运维联盟委员,腾讯云布道师,腾讯课堂运维讲师,EXIN DevOps Master讲师,凤凰项目沙盘教练,复旦大学客座讲师。

券商行业DevOps三步走

DevOps在我们证券业其实才刚刚起步。我们内部经过大量的研习和讨论,结合自身特点,把DevOps称为三个阶段:

  1. 需求管理阶段;

  2. 持续交付阶段,这个阶段与研发相关;

  3. 运维管理阶段;

前言

澳门新萄京 1

两个运维对外核心能力

基础资源交付是一个基础,如果脱离基础单纯讲应用交付能力,实际上也没有办法进入到应用全周期管理这个能力圈:

  1. 基础资源的交付能力;

  2. 应用的交付能力;

 

导语:8月23日,腾讯 云 未来峰会在北京盛大开幕。在开发者专场,腾讯织云负责人梁定安为大家解读了腾讯DevOps流水线的系统组成,以及如何在平台的实践中实现持续部署能力,帮助企业创造更大的价值。

讲师自我介绍

自我介绍一下。我08年在中科院自动化研究所毕业,08年到15年做了招商银行系统运维及基础设施运维,2015年至今是在国信证券做运维架构师,负责运维平台建设。

“我是这个应用的 Owner”是阿里巴巴DevOps转型的重要策略,运维有了这个策略以后,PE大量的日常工作就可以释放出来,会有更多的时间去思考沉淀,去做编码,去做以前不曾做的事情。

前言

国家的“互联网 ”战略开启了一个企业业务与互联网相结合的新业务形态,有越来越多的企业将自己的业务以互联网为媒介对外输出。任何一款互联网产品都会经历从产品的规划与设计、开发的功能实现、测试的度量验收、运维的发布交付,也是常常被成为企业的IT价值链的全流程,将产品输出个最终的用户,以产生商业价值。

证券行业的特点

可能上海的小伙伴对国信证券不是很了解,国信证券是一个立足于深圳的券商,有158家营业部分布在112个城市。在业务创新这块也有很多突出贡献,比如我们金太阳手机是券商行业第一家推出的手机APP,同时我们也推出了内存交易系统,专门为量化的客户做服务。

总结来说,国信证券业务创新应该是处于整个券商行业的前列。这种业务创新就需要我们IT运维能力给以支持,这也是现在我们IT运维能力迫切需要提升的一个重要原因。

我们现在最重要的待办内容就是整合运维平台,因为我们既有传统运维管理平台,也有新理念下的运维管理平台。怎么将它们整合交给我们IT人员使用,已经是我们现在面对一个很重要的课题。

 

腾讯的DevOps实践

在DevOps的理念中,企业的IT价值链流转的速度越快,意味着企业的互联网产品的交付能力越强,这也意味着企业在同行业的竞争中,凭借IT能力的优势,能够收获更大的竞争优势。

澳门新萄京 2

腾讯公司诞生于互联网行业,以海量用户规模和设备规模著称社交网络业务,其DevOps的技术实践,主要由四大平台系统组成。

澳门新萄京 3

四个系统共同组成DevOps流水线,腾讯的海量业务使用这套流水线系统可以轻松完成从需求设计、代码管理、开发测试、发布&运维的各阶段工作。

澳门新萄京 4

TAPD支持敏捷项目管理,实现产品需求与开发分支关联;TGit支持代码管理,通过webhook钩子触发持续集成系统的能力;CIS负责自动化完成编译、测试等任务,以输出制品库:软件包或docker镜像;织云对接CIS获取制品,以自动化的方式完成业务的发布/变更任务。

澳门新萄京 5

证券行业有它自己的特点:

1. 跟金融行业很像,是稳态和敏态的并存。因为证券行业有114家券商,所以对业务的创新非常迫切,所以我们在敏态上对证券行业是有要求的,但是我们在稳态上还要满足证监会的合规的要求。

2. 证券行业它的运维组织架构已经做到了双纬度,更进一步说,就是基础架构和应用运维的双纬度管理。

3. 流程上绝大部分券商都实现了流程落地,这两个实际上和运维规模有关系,一般规模达到四五十亿以上都会会有人员的操作规范化等都要求这样。

  1. 物理机和虚拟化的并存,这个就不多解释了。

=

运维的三个阶段

应用架构的可运维性

对于互联网产品而言,发布仅仅只是开始,在持续为用户输出价值的运营过程,由运维团队和系统来保障服务的稳定可靠。以腾讯的应用架构实践案例,我们来看下腾讯业务对可运维性的定义
DevOps持续交付的八大原则对可运维性给出了这样的定义,在企业中研发和运维体系必然需要相互配合,开发团队负责功能性需求实现的同时,在架构和编码上注重非功能性需求的实现,测试团队与运维团队将围绕着各自职能的需求,规划与建设DevOps流水线中对应的工具系统,加速企业IT价值链的流转,以为企业创造更大的商业价值。

澳门新萄京 6

有了持续交付方法论的支撑,我们认为要实现可运维性的过程可分为4个阶段:统一架构、运维规范、标准操作、运维自动化。

澳门新萄京 7

将互联网的业务架构抽象成为三层:接入层、逻辑层、数据层。

澳门新萄京 8

并在业务架构的技术选型与规划时,遵循四个原则:框架化、组件化、无状态、分布式。

澳门新萄京 9

框架化的引入,可以有效的降低开发的工作量,通过有限的编码即可实现快速业务功能需求。如下图所述,对于常见的socket通讯型的C/S架构,由框架实现了网络的通讯,业务逻辑由动态库的方式加载到框架中,快速拼装出满足业务功能需求的软件程序。得益于框架的支持,可运维性诉求的非功能性的规范亦可被纳入框架中实现,如数据上报、统一日志、管理工具等。

澳门新萄京 10

组件可以将共性的服务统一化,如腾讯内部大量应用的软件路由服务,帮助业务轻松实现负载均衡、名字服务、容错、过载保护、流量调度的功能特性。除了为业务解决了路由的难题,也使日常的运维管理变得更加简单高效。

澳门新萄京 11

通过对可运维性的思考,在统一规划与标准化的持续推进实践中,保障了腾讯的业务架构有序的发展,架构的演变从千人千面进化成千人一面。结合框架与组件的非功能规范的落地实现,将运维保障业务质量与效率的规划落实。

澳门新萄京 12

券商们的挑战

在这种场景下我们在未来的几年都会看到我们的稳态业务继续保持这个态势,这样的情况下,对运维管理来说就很难做到统一管理,也就是很难用统一平台管理所有IT资源。

我们说什么叫稳态业务?就是我们的业务需求变更比较少,开发周期比较长的就是属于稳态业务。在国信来说为什么说稳态业务同质化严重呢?这个说起来很复杂,至少说明我们证券行业开发商很少,大概也就是三到五家,主要就是两家。新进来的这些竞争对手很难在这个行业里面立足,所以就会发生稳态业务ITSM同质化非常严重。以纯流程管理为主,这样就有一个问题,就是我们线上和线下的流程是脱节的,运维的效率低是因为本身只要做线下就可以了,现在还要专门做线上的填表和填单。其次我们以GUI的操作为主,这张图是我们以前的图,大家可以看到这是填的所有的内容,这个里面所有的内容跟我们监控都没有做任何对接,所以这个最后的用途只是用于审计。这样就会产生一个问题:人员的产出和收入是不一致,也就是说我们运维的人费了半天劲做出来这个单,最后没有和自动化对接。导致产出非常低下。

稳态

什么叫敏态业务呢?就是有点偏向互联网的业务,我们说到Fintech,证券创新Fintech推动运维也要同步创新,现在我们的直接竞争对手有xx、xxxx,所以这块对我们的创新要求非常高。敏态业务的特点就是开发周期在两周到一个月之内,这里就有一个问题了,如果我是传统运维,我这个时候就会说你等我三个月,我去买一个物理机回来……这个就很危险了,因为我这个业务等你三个月,别的竞争对手就起来了,所以这个时候运维怎么支撑这个敏态业务就变得非常重要了,要思考下运维以什么方式去支撑它做到快速交付。国信证券每两年业务规模会增长一倍,包括主机规模和发布数量,所以在这种情况下完全依靠人去堆,去作流程非常不现实。券商行业还是用鼠标点,到最后出现事故都没有办法做审计。

敏态

传统CMDB有什么局限,为什么不足以支撑运维体系构建?首先最近十年由于IT的推广,传统CMDB通用性不是很好,也没有针对性,就造成了运维人员还是喜欢用Excel表去维护,因为你IPE,让你去配,肯定不如Excel来的方便。其二,数据中心以基础资源管理为主,就是我们这个CMDB是以优先服务我自己,但是没有想到过CMDB要对运维进行服务,要对开发进行服务,结果做出来的CMDB也只有我来用,可能大的公司还可以,基础架构有50个人还能用起来,小的公司基础架构也就是五个人,十个人,二十个人,平常我们都是靠吼的,那还需要这个东西吗?不需要。其三,资源维护自动发现能力严重匮乏,维护成本高,效率低。最后就是系统运维的建设碎片,因为我CMDB从来没有考虑跟自动化对接,跟其他的对接,造成数据永远就是在小范围流转,没有给其他平台用。最后发现我们做出来这套东西很难支撑我们现有的运维管理平台了。

传统CMDB已不堪重负

 

腾讯织云的持续部署实践

要满足企业的长期发展,仅靠堆砌运维工具是不够的,必须体系化的、全局的考虑标准化、配置化、自动化、智能化的一体化运维管理系统。下图是腾讯运维平台——织云的功能规划,我们以此管理着腾讯社交网络海量的服务。

澳门新萄京 13

在运维的过程中,我们要面对很多复杂的运维对象,结合可运维性与非功能规范的要求可以很好的防止业务架构失控,但倘若要更好的管理这些运维对象,我们必须要做好配置管理。
织云平台实践中,我们将标准化的运维对象配置化,以下图为例,每个微服务集群在织云CMDB中被定义成不同的模块名。模块可被划分为两大类配置属性:基础配置与应用配置。

澳门新萄京 14

基础配置中的资产配置,可被用做资产核算、预算规划等;硬件配置可被用于虚拟化和机型规划等方面;分布信息会记录设备的上联交换机与IDC等信息,在优化机房穿越、网络设备故障的智能分析场景,可以提供很好的数据支持。

应用配置中的资源配置,可对接镜像仓库或制品库,实现与发布/变更相关的运维对象关联,为自动化提供支撑数据;流程配置将工具或接口通过自定义编排实现操作流或工具链,让运维的工具收敛复用;变更记录提供了运维操作审计与联动监控数据的配置信息。

我们将运维日常关联生产环境的操作提炼如图:对资源的传输与执行。

澳门新萄京 15

从统一规划、标准化、配置化、自动化到联动监控,用持续部署的流水线工具串行起来,我们将得到一个体系化的运维能力模型,基于此模型,运维团队能够全局规划持续部署的能力与工具系统。

澳门新萄京 16

通过工具编排功能,自定义运维操作流程、工单审批流程、服务请求流程。并与CMDB的业务、负责人、状态等数据接口联动,解决运维操作与配置数据状态的协同的难题,实现从ITIL离线流程到线上自动化流程的技术升级。

澳门新萄京 17

以织云的自动化扩容流程为例,将原子运维工具或系统接口以运维的最优操作流程组织起来,自动化的完成扩容操作,并且保证每个步骤都会被严格执行到位,不会受个人的经验深浅或文档的新旧影响。从而解决运维团队“文档即过期,离职即消失”的难题。

澳门新萄京 18

基于统一规划的运维体系,不仅能提升运维效率,同时对服务质量的保障也能有很多好处。如下案例是进程自愈的场景,结合CMDB的业务属性,通过自动化的流程完成配置注册,从而实现进程监控的自愈。

澳门新萄京 19

国信证券怎样迈向DevOps

这张是技术架构,涉及的技术债务多,缺乏端到端的高效IT价值流,上面的红色部分就是我们总结出来的运维和发布两个阶段的问题,在前面的原因,下面是一定的解决的手段。

缺乏端到端高效IT价值流

整个券商基本上都是这样,缺乏面向DevOps端到端的IT流程,交付流动效率低下。整个IT标准化、持续交付过程规范,工具能力建设,系统架构,组织协作,监管体系等能力都需要全面的建设和提升。有这么多问题需要解决,所有券商都在考虑向DevOps转型,尤其是敏态业务。

那么,第一个该试点什么?就拿某一个敏态业务吧!国信也是这样想的,所以国信拿金太阳手机APP作为试点,希望它成功之后再一个一个推广。

我们一共两块,配套两个服务:微服务架构改造和业务监控。这样才能把整个体系全部做起来。

从我们的运维角度来看DevOps IT自动化的本质应该是两个层面:

  1. 资源的交付层面,就是类似于Laas和Paas层自动化。

2. 应用交付平台,就是我们常说的持续交付、配置管理,端到端交付等,是利用DevOps做的。

两层交付

这两个都很重要,现在它们是独立割裂的流程。我们怎样把这两个流程整合到一起去?其实就要做一个囊括两者的CMDB,这是我们的想法。

2015年,我们画了一张架构图,当时就讨论先做哪一块,很多内容,云管,持续交付,自动化、监控,一些大数据,各种各样的,到底做哪块。最后我们讨论决定,还是做基础:先把CMDB做起来,然后做消费场景,然后再做一些登录统一,流程统一,最后再做一个事件统一。因为我们金融工具非常多,传统的像各类监控系统等等这个渠道非常多,很多监控工具没有办法发挥效用,必须要做集中平台,把所有的工具统一起来,统一起来之后再用CMDB做比如事件告警。

之前我们看到有一些公司他们做事件告警,他说我今天排班,每一个组排一个人。现在银行经常这样做,因为你的监控不能精确到人,就只能靠人值班去做。

我们现在第一个阶段以CMDB为基础,建的内容第一个是统一事件平台、运维大数据平台,混合云管平台等。

IT运营管理平台

国信的DevOps有三步走策略:

1. 资源自动化管理。为什么要做这一步?因为这是基础,如果不做这一步下面两步做完了,效果大打折扣。

2. 持续部署和运维自动化管理。这也是我们现在的痛点,因为整个券商行业都是手工操作,包括我们现在的很多运维人员就是手工操作,这样我们就要把人从这种人工模式中解放出来,让人去做二线工作。

3. 持续集成和持续交付。通过流水线打破开发、测试、运维的壁垒这个部门墙的问题,通过工具将这个交付能力建设成为一种可靠、可重复的,可持续的交付能力。

这是国信的思路。我们这个平台命名叫磐石系统,希望以它为基础,有一个坚实可靠的基础,然后在这个上面再做其他的业务场景。我们建设目标基本上就是这些思路,这些在两年前我们就开始做规划做设计,这里就不细说了。

基于CMDB的一体化运营管理平台

然后我们系统有一个理念就是我们要面向业务去设计,为什么要这么做?因为我这个平台不能只给技术架构用,要给开发用,给运维人员用,他们看问题的不是像我们这样,他们看的视角是这个应用部署在哪里。所以最后你看这里有三个纬度:

1.基础资源;

2.动作;

3.职能监控;

第三个就是数据分析这块,最后要做成面向应用管理的场景。

应用CMDB建设七原则

  1. CMDB设计得面向应用。既然面向应用,就要有下面两部分。

  2. 面向基础的CMDB和面向技术的CMDB。

  3. 面向LaaS和PaaS设计,能够管理底层的一切资源。

  4. 状态控制借助运维流程自动化完成。

  5. CI的维护要深度使用自动发现,而不是人工维护。

  6. 资源信息必须能为上层应用提供服务。就是以前说的面向应用的CMDB。

7. CI的颗粒度,必须要符合未来的场景设计,假如我们公司有一些监控的场景,有一些变更装机的场景,那我的CMDB就必须要满足它才可以。

这是应用CMDB的建设七个原则。这里有一个方法论在里面,就是我做应用CMDB,我要看我的场景有哪些。对我们国信来说有两大场景,监控和持续交付场景。既然我知道了这两个场景之后,我再去做CMDB的建设就相对简单了,也更清楚。

磐石系统的资源模型框架

这是我们的模型框架。从这条线来看往下都是基础CMDB,大家可以看到跟Laas层和PaaS都是一样的,我们管的内容基本要到机房、机柜等这些物理信息都要有。现在的敏态业务基本上都是采用这种方式去做。

基础的CMDB之上我们又开始了将CMDB和应用的这些内容做整合,我们应用包括哪些?包括证书和发布版本、配置信息,甚至包括镜像在里面。这两个整合之后就会生成业务和应用系统出来,相当于描述了我们整个CMDB的模型架构。

还有一个比较独立的一块,就是人员信息、部门信息等,这块为什么要加进去呢?是因为CMDB对外是服务了很多平台,这些平台都可能有采集人员信息的需求,所以这个时候既然已经在我CMDB统一拿到了数据,那就干脆把这块数据也纳入进来。其实CMDB本身也会用到这块信息,因为CMDB本身的业务属于谁负责,我的网络设备属于谁负责都要填写关联。

磐石系统的资源层次模型分解

这块基本上是对应用怎么拆分,也有个方法论,我们拆分成部署资源和服务资源。部署资源就是安装资源,我们需要哪些资源;还有服务资源,就是说我运维的时候需要采用监控哪些资源,这些资源可能影响到我的业务可能性。这两部分资源通过一个场景动作再去做关联,建立应用交付动作和应用维护动作,这基本上是我们模型的一个思想。

澳门新萄京 20

结束语

在腾讯多年的海量运营经验中,DevOps是贯穿整个应用软件生命周期的,发布完成并非终点,我们要全局思考、统一规划,为业务的健康发展打造一个标准有序的业务架构,和为业务提供一套完整体系化的运维解决方案。

澳门新萄京 21

PS:现场 PPT 干货请移步澳门新萄京:流程应用平台推行之路,转型后的运转平台建设。腾讯云技术社区澳门新萄京:流程应用平台推行之路,转型后的运转平台建设。查看及下载哦!

磐石系统技术架构特点

整个磐石系统技术上的架构有几个特点:

1. 自动采集层。这个应用包括了很多协议,这些协议包括像agent、私有协议,ssh等等;

2. 资源对象层。我们采用的有OpenStoc,公有云,私有云,服务器、网络,存储,机房等等;

3. 开放式的API接口。因为我的CMDB要服务很多消费场景,这些场景不可能只在一个平台之上,就会需要给每个系统都要放统一且一致的API,去保证能够消费数据;

4. 模型资产管理能力。这个就不多讲了,我们在功能框架里面主要是模型管理这块的落地实践;

5. 拓扑管理。对运维来说我们初期关注的是一个点,比如我一台机器的属性,但是我们到后期就会有一个需求,我们要关注到两个机器之间关系的属性,这个属性怎么建立?我们就要采集这一层的关系,采集了这个关系之后,机器和机器的关系就要必须抽象成应用和应用的关系,当然你用的方式就很多了,像互联网的应用就要用交换机做,或者可能借助一些操作系统的命令去做。就是说我做这个拓扑图要分几个层次,有应用架构拓扑、应用部署拓扑,应用实例拓扑,基础架构拓扑,还有机房。

技术架构

 

相关阅读

腾讯云 GAME-TECH 沙龙干货回顾:与腾讯云携手出海
物理计算云服务需求强烈,腾讯云将推多款黑石新品抢占市场
运维的难题 : 800 万用户,救 or 不救?


此文已由作者授权腾讯云技术社区发布,转载请注明文章出处
原文链接:https://www.qcloud.com/community/article/921658

磐石系统的场景化规划

场景化规划

如果CMDB系统做完之后没有跟其他平台对接,实际上这个数据的价值非常有限。所以说我们这个时候在做CMDB的同时就要考虑到它有哪些场景设计。比如有一些各种流程、交付、监控平台,像统一事件平台,变更平台,分析平台的(流程),这些都要考虑进去。

这里重点讲一条,人员的逻辑。其实这块并不是说能够自动采集到,是有些信息不是通过自动采集回来,但作为CMDB系统来说,这个时候这块信息别的系统要用,那怎么办?一定要采集回来!确保别的平台对你平台有一个重度依赖。如果做不到这一点,其他平台在你平台拿不到这个数据,就会到其他平台拿,这样就会慢慢造成数据失控,统一数据的目标就完不成了。

第一阶段:黑屏,三角形是代表整个运维给用户的一些体感或者给研发的体感,人工运维,目前很多企业可能还是这样。

磐石系统的建设成果

整个系统的落地实施跟一般项目差不多,现状评估、项目启动、CMDB实例化、数据校验,最后数据场景消费。一般是到数据校验就结束了。在国信做完这一步,就立刻做了周边运维平台与CMDB平台的对接,然后还有后面的与自动化平台的对接,和持续交付的平台对接,因为这些平台的数据变更相对准确。

整个平台的建设是从2016年启动,项目成员一共10个人,其实也不止10个人,因为咱们整个基本运维这块的人都要参与进去。

落地实施框架

 

项目建设实录

2016年9月份开始建设和脚本开发;

2016年10月份CMDB平台上线;

2016年12月份流程平台开发,因为我CMDB维护不能光靠自动采集,还要靠流程去记录我的变更状态,所以我们当时启动了物理机上架流程,也对接了FID、自动装机平台,以及监控等工具所有都对接了;

2017年1月启动了东莞数据中心的上线……第一个100%的对接IT资源管理平台。

这个机房有一个强项优势,从物理资源开始,从机柜、网络设备就开始标准化,然后从操作系统,从数据库等等也做了标准化,做完之后,也就非常标准化之后,你会发现脚本开发就变得非常容易了,很容易能够实现100%的对接,这个机房也是整个证券行业标准化的机房。

第二阶段:白屏,自动化运维,以前把脚本做成工具去弄,有什么特征,人push机器去干活,自助运维。

平台建设成果

再总结下一下我们的平台建设成果,俗话说好马配鞍,如果没有好的平台我们也做不到这些好的功能出来。

1. 平台特点就是从资产管理到资源的管理升级。我们以前的CMDB很多是静态的资产管理的系统,大家把这个定位定的都比较局限。我们现在要把这个功能扩大,但是我并不是一切的IT资源都要管进来,因为CMDB要数据准确性,所以能够纳入CMDB管理的资源应该是那些可以自动采集的资源、可以流程控制住的资源。如果资源处于失控状态,不能采集到,也不能管控,这时候就不能把这些数据跟准确数据捆在一起,只能够单独建一个表。因为一旦CMDB数据准确性不能保证,其他平台的数据就都不能得到保证。

2. 第二个就是动态资源模型秒级完成。这个在数据量大的时候按照以往方式做调整会非常耗费时间,而且也很难实现。所以我们要让现在的模型调整得能秒级之内完成。这是用的图数据库,应该是两个数据都用了。

3. 资源的自动发现。做这个其实说起来真的很简单,就是每个公司有运维研发岗位,对接一些协议,包括SNMP的协议,包括API都可以,还有网络设备还是SNMP的方式,但是过几年SDN的发展,API也非常成熟了,其他的就不用说了。CMDB这个项目不是项目做完,CMDB就做完可以撂挑子放手了。CMDB本身是一个持续优化、持续改进、持续完善的项目。因为我们公司买设备都是低价竞标,几次下来的中标商可能都不一样,那就得一直做对接,这样我如果有自己的运维研发岗,就能持续保证我的采集能够百分之百覆盖。这是我们的一个持久策略,大概是这么多。

4. 是面向应用的CMDB。我们之前最初做CMDB的时候,做的是基础资源到底属于哪个应用的环节,结果做完之后发现对机器特别友好,写代码特别容易。但这个对于应用管理人员和开发来说,这个不是他的视角,所以他们不会用这个东西……所以后面的建设中我们就改成这个应用到底管了多少,用了多少资源的思路,这样让应用管理人员从应用角度看待这个问题,于是CMDB就可以给应用开发广泛使用,实际上他们也非常喜欢。

总结一下这个特点:全开放式的API接口、全开源技术栈、与流程平台深度集成、面向集中管理。

技术特点总结

 

国信的IT资源自动化管理建设成果

下面是基于磐石的IT资源自动化管理建设成果。我们做的相关流程是30多个,这些流程都跟自动化相关,不是纯流程,最后落地的是通过自动化要维护和CMDB关系的流程,这个是有关联了4个系统,分运维监控、IT管理、资源系统三大类。业务系统梳理需要领导大力支持,这块是全覆盖,组件也实现了全覆盖。

可能你想问,当时我们怎么做到的全覆盖?就是做了覆盖之后,要把每个时间去关联每个业务。如果做不到,就立马去找相关人员,问为什么没有关联起来,然后一直做到业务系统全覆盖。最后是一个实例信息,这我们一些核心资产,我们大概规模是应该X万台的机器。

第三阶段:用户对运维体感很少,但是运维这个领域是不变的。最重要的是人机交互变少了,无屏虽说是不可能的,非常极端,但是个趋势,少量的人机交互,它有自决策、自驱动。

澳门新萄京,可落地的经验总结

最后做一个总结,我们券商的案例应该对一些传统行业和泛金融行业有一些参考和借鉴的意义。

这是我们现在的一个实时情况,黄色部分就是已经实施完毕的情况,蓝色是还没有做完(正在做)的内容。大家可以看到其中有几大块吧,因为这属于规划,我们就是在这个里面填东西,一直在填。

我们现在趋向于监控系统,因为我们原来用的网络用得不是太好。我们所有的平台在选型时就已经定了一套标准,是要和CMDB去做对接。这个要求很基础实际了,否则运维平台就会失控,底层数据不统一,比如网络数据不统一,这些问题都非常严重。

首先做数据统一;然后到流程,应该说是流程统一,把整个公司运维流程做了一套出来,所有平台都要和它对接。所有的集中事件都要通过这个平台做事件告警;接着做运维大数据分析,统一容量数据分析。

 

平台搭建成果

我们觉得这个平台搭建的成果主要是这几点:管理,支撑,优化:

1. 从管理角度来看实际上是降低了资源维护的成本,通过流程自动化去实现了轻量级的管理平台,然后也实现了资源全生命周期的管理。

2. 数据支撑方面,我们第一阶段就已经和很多平台做了对接,建立了周边的场景消费,确保了数据的准确性和鲜活性。

  1. 优化部分,这个CMDB实现了IT变更服务流程能力再造,体现变更的能力。

自动化运维基础

平台实施经验

实施的经验部分重点讲两个,因为后面都是做技术的内容,就不用说了,因为跟这个项目经理或者项目成员的能力有关系。

1. 领导支持。这不是说我奉承我们领导,如果运营团队到50人以上,研发团队到350人的时候,实际上很多事情就不是一个运维人员能控制的,如果没有一个领导的大力支持,CMDB项目就很难能够落地。

2. 理念和意识先行。大家知道金融行业是很传统的行业,无论是银行还是证券,很多运维人员还是习惯于做手工操作。我们现在做备份平台,思想保守一些的老干部说不定做了一辈子快退休了,他说不定就接受不了你做的备份自动化管理平台……所以在前期的培训、宣讲和咨询这块都必须要下力度,而且这也不是由一个研发或运维人员就能可以推动的事情。剩下与平台对接、持续交付这些都是纯技术内容,也没有什么大的实施难度。

 

受认可的创新点

整个系统的创新归纳如下:

1. 自动化采集。CMDB整个系统是以自动化采集为主的,以流程自动化为辅的。因为我们前期是这样的,自动化采集为主,人工验证为辅。

2. 复杂业务访问关系的拓扑图动态展示。大屏对运维来说并不是很实用,但我们要做的是一个业务访问关系的自动采集,动态展示。

  1. 以应用为中心的资源管理全视图。

4. 以CMDB为核心的运维生态圈。就是说我的运维工具很多,可能有50个人,但是有20个运维工具,尤其是基础运维就更复杂了。我要做一个生态圈,以CMDB为基础,把这些资源全部整合起来。

最后,国信证券这边,我们券商其实氛围好,老板好,待遇好,假期多,不熬夜,不背锅……因为我在一些其他公司也接触过,略有了解,不背锅这一点能满足就很好了。为什么不熬夜?因为券商主要是5×7的工作特点,晚上没有什么变更,我们基本下午三点半做变更,最晚八点就下班了。出事时候领导很好,宽容,不会让我们背锅的。不像其他“传统”团队,锅都在员工背上。

实际上券商这个案例,我个人觉得对一些传统行业还是有一些借鉴意义。像证券这个行业没有垄断,大家都知道114家券商,这么多券商在这里竞争都非常激烈,业务创新真的不停在做。我们每年都在讲业务创新这个事情,尤其是交易类的产品。我们的运维怎样支撑这个业务创新?肯定是快速交付,稳定运维这方面。我们也希望在座的各位大家共同努力,对自己的行业尽自己能力做好支撑,做好行业内的创新工作。谢谢大家!


文中图片来自分享PPT,如需PPT,请在优维科技微信公众号回复“金融PPT”

做自动化运维,我认为有四大基础。

 

第一:运维标准与规范

 

我们的标准有什么好处,让研发 follow 这个标准,标准会在工具里固化。

 

第二:泛监控,运行时,静态,数据化,可视化

 

泛监控,不是说传统的监控,是把线上想知道的一切都数据化,最终数据不是给人看的,是给机器去消费的,数据是我们的生产资料,不是可视化,那不是我们的目标。

 

第三:CMDB

 

1.CMDB 应该放什么,一般放服务器相关的、网络相关的、应用相关的这三个维度的相关信息。

 

2.经常有人会说 CMDB 不准,数据不准是因为没有把数据生产和数据消费形成闭环,如果形成了闭环数据不准,那是因为你不用这个数据,所以不准。

 

第四:高效的CI/CD/CD

 

我们一定要具备快速的交付能力,主要体现这两个方面:第一,新开发的能力能不能快速上线,第二,想扩容一台机器能不能快速扩出来。这两个能力抽象出来是三块。

  • 持续集成(CI),很多人说持续集成工具不好用,效率低,其实持续集成的本质是要自动化测试。如果研发部不具备自动化测试的能力,持续集成怎么做都是失败的。
  • 持续集成里最重要的一点就是要推行单元测试、集成测试还有系统测试,单测是保证自己没问题,集成测试是保证跟上下游没问题,系统测试是保证整个系统没问题。
  • 持续交付(CD),有很多人说持续交付本质是一个 Pipeline,CI的目标是什么?快速正确打一个包出来。CD的目标是什么?能够快速把一个包在不同的环境验证它是ok的,可以放到线上去,这就是持续交付要干的事。持续交付里很关键的一点我们要解决,就是它的环境一致性、配置一致性。环境一致性可以用Docker解决,Docker 本身就是一种标准化的东西。所以说第一条用 Docker,肯定是标准化的,另外一个问题,配置是不是一致性,是不是动静分离。
  • 持续部署(CD),是一种能力,这种能力非常重要,就是把一个包快速部署在你想要的地方。

PS:持续部署的几个痛点。

 

1.对包的文件的分发,阿里有一个叫蜻蜓的产品,是做了 SP2P,在 P2P 的基础上加了一个 Super。

 

2.应用启动,很多应用启动的时候要两三分钟,这是很有问题的。

 

3.部署起来以后这个业务是不是正确的,大家一定要做一个 HealthCheck,不是运维做,是PE做,一定要把这个要求说出来,执行 HealthCheck 这个脚本。

 

运维系统的重要特性

 

中间件研发首先关注稳定性,其次是效率,然后是易扩展。运维研发里面的六个重要特征,每一个都非常重要,以下是我感触比较深的几个。

 

澳门新萄京 22

 

1.高可用

在做同城容灾演练的时候,我把关一切,结果发现运维系统挂了,救命的东西没有了怎么办?所以说运维系统一定要是高可用,不一定是高并发。

 

2.幂等性

幂等性是分布式系统设计中十分重要的概念,这个也非常重要。

 

3.可回滚

这个是做运维最基本的一个 sense,你做的任何操作是不是可控的。如果真正做可回滚,其实事情没有这么复杂。

 

4.高效率

如果你的企业发展非常快速,你的规模性效应已经来了,你的运维系统一定要具备很高效率,快速扩容、快速部署这个效率我们要追求极致。

 

研发定义运维,配置驱动变更

 

澳门新萄京 23

2015年11月4日设想的架构图

 

从最下面看,是我们的基础设施,提供三种能力,包括集散、存储、网络。从右下角的位置看,画的是一个泛监控,它会知道系统、应用等,在旁边标了一个字,现状,我要通过这个现状把线上的系统全部数据化,然后放到决策中心。

 

左上角有 CMDB,现在很多变更系统,很多强调流程。我本人是做研发出身,非常抵触流程,流程不是一个效率工具,它是阻碍效率的。

 

比如故障搞完以后就是一堆的流程,非常阻碍效率,是质量控制的一个工具。流程不是不要,是把流程做到系统里面去,让系统帮人做决策,而不是人在那里点。

 

CMDB 定义了我刚才说的目标,现状通过监控拿到了,目标也知道了,这个时候还觉得这个事情很复杂吗?我认为这看你怎么去做。想做成人工还是做成自动或者做成智能,都取决于这个地方。所以智能里一定要有数据。

 

举个例子,通过智能分析出目标状态是使这个应用有100个VM,但是现在状态只有80个,一看这两个不一样,要扩容20台,如果系统做得更智能一点,通过图上左边的事件中心提示我20台负载较轻的放在哪,可以调度过去,然后去做执行变更。

 

基于这些东西得出来两个结论,“研发定义运维”,“配置驱动变更”。

 

为什么是研发定义运维?

 

研发定义运维(DDO),研发最贴近业务,最应该清楚这个业务应该具备什么样的能力,只有研发才知道这个业务KPS是多少。

 

为什么是配置驱动变更?

 

配置就是把目标改变一下,你跟我说一个运维场景,我可以在这个图里面 run 起来,配置只需要改你的目标状态,比如把你的状态10VM 变成15个VM。

 

这就是“研发定义运维,配置驱动变更”前因后果的思考。

 

运维工具与方法论

 

澳门新萄京 24

 

精益发现价值

 

价值来源于用户的需求,而不是自己的YY,我们的价值来源于用户。

 

精益对我最大的感触就是要发现价值。精益思想,什么东西是有价值的,能够对用户带来物质上的或者身体上的愉悦的东西就是有价值的。

 

今天也有人问,DevOps 团队是该拆还是该合,我想他应该首先弄清楚面对的是什么样的问题,问题的优先级是什么?如果只解决一个问题,也许并不是DevOps 团队拆不拆的问题。

 

敏捷交付价值

 

敏捷也是对我影响很多的。很多人谈敏捷,我们团队里也搞敏捷,敏捷是要快速交付价值,它是一系列的方法论。但是在引入的时候千万注意,别人行的东西你不一定行,你需要的东西并不一定是敏捷,要因团队而异,形成一个环,持续反馈。

 

OODA环

 

OODA 环,就是形成闭环,让价值快速流动。

 

应用运维平台ATOM

 

应用运维平台的基础设施是一层,二层是运维中台,最上面一块是要做的 PaaS 平台,这个平台分几步。

 

澳门新萄京 25

 

第一块,预算、容量、资源、弹性

这个是PaaS 平台上非常重要的一块,目的就是让资源快速流动起来,流向正确的方向来产生价值。资源如果常年不增不减,是有问题的。

 

第二块,应用管理

这是日常要做的操作,规模化,要快速对一个单元建站、扩容、缩容。

 

第三块,数据化运营

一定要讲数据,数据不是可视化出来一些报表,是要给结论,告诉用户这个数据完了以后应该是什么,规则中心是什么,是所有运维同学日常的运维经验沉淀。

 

批量腾挪工具

 

澳门新萄京 26

 

这个工具不是所有人都需要,可以解决机房的搬迁,凑框迁移。

 

澳门新萄京 27

 

单机闭环,这是腾挪工具的关键,如果企业有一定规模,这个是需要的。

 

澳门新萄京 28

 

弹性伸缩工具

 

澳门新萄京 29

 

弹性伸缩是我们的决策中心。它决定你的资源往哪个地方流,非常关键。

 

澳门新萄京 30

 

最后,这里是运维领域技术含量最深的一个地方,要搞机器学习、深度学习、强化学习、算法等。

 

澳门新萄京 31

 

弹性伸缩架构,这个平台不一定很多企业都需要,这里主要介绍在双11的时候是怎么用的。

 

澳门新萄京 32

 

建一个站点起来只有5000的交易能力,可以通过10分钟时间让它具有30000万的能力,快速决策,快速调动起来。弹性里面是一个 OODA 环,拿它的数据和应用极限做比较,得出来一个策略中心。

 

弹性一般有水平伸缩、垂直伸缩,对线上做管理,当然我们有额度,这是比较精细化的管理。弹性有观察者模式还有自动化执行,每次弹性完以后有一个控制台,双11做全年压测的时候一般情况下不看这个。

 

实施效果

 

澳门新萄京 33

 

嘉宾介绍

 

陈喻(亚松),阿里巴巴高级技术专家。2014年入职阿里负责持续集成持续交付平台研发团队,2015年调入运维团队,负责交易运维、无线运维2个团队,带领团队保障日常运维及双11大促运维。2016年开始负责Sigma弹性&资源运营团队,主要领域为集群弹性,应用弹性,资源运营,规模化运维,支撑双11,在2016,2017连续2年获得双11卓越贡献奖。

阅读原文

本文由澳门新萄京发布于澳门新萄京,转载请注明出处:澳门新萄京:流程应用平台推行之路,转型后的

上一篇:澳门新萄京创建图标标记,创建上下文菜单项 下一篇:澳门新萄京绘制基础,中自定义View
猜你喜欢
热门排行
精彩图文