图片 34

实战:阿里巴巴 DevOps 转型后的运维平台建设

1.高可用

图片 1

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

 

一、DevOps的起源和发展历程在过去的几十年里,为了按时交付软件产品和服务,大家越来越意识到,对于传统把开发和运营割裂开的做法,不适合现代产品和服务开发的需求。于是,把开发和运营作为整体来看待的DevOps工程思想逐步深入人心,随之也逐步有了对DevOps系统的需求,希望能有个平台或工具来统一支持开发和运营的交付工作及之后的环境管理工作,即需要一系列的持续集成,持续交付,自动化部署,自动化测试监控,自动化伸缩,自动化恢复系统,以提升开发测试运营过程中的部署效率,简化开发测试运维过程的管理,降低交付风险,降低沟通成本及运营成本。从广义来讲,不管是云管理平台工具(比如RightScale),还是各种PaaS平台(CloudFoundry,Heroku
etc.),还是自动化部署工具比如Chef、Puppet和Ansible等,其本质上都是DevOps系统的一部分,都是为了解决在开发过程的交付环节问题和交付后的运营管理问题,即在开发和测试过程中,帮助开发测试人员搭建和管理环境,以便在变更后部署变更以测试;在运营和支持过程中,帮助运营支持人员升级系统,扩展重建恢复系统,在升级后能够持续地掌握系统整体和各个栈的状态,从各个层面监控系统,伸缩系统,恢复系统。这些年,随着云计算和容器技术的进步,以及产品业务对IT能力的需求推动,DevOps系统发展越来越快,其角色和概念也越来越清晰和独立。回顾其发展的路径和变迁的过程,我们认为基本可以分为三代:基于物理机或独立虚拟机的部署时代,基于IaaS可编程资源的部署时代和基于容器的部署时代。随着这三代的改进,DevOps系统的整体能力越来越强。下面我们首先看一下各代DevOps系统的特点和能力,之后再对DevOps系统进行更进一步的分类,以帮助我们选择合适的DevOps系统。二、DevOps的变迁及其关键使能技术1.基于物理机/独立虚机的部署时代这是第一代DevOps系统,特点是静态配置

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

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

  • 人工协调 +
    仅应用部分自动部署。在搭建整个应用系统的过程中,首先需要在DevOps系统外创建运行应用所需的资源环境(如主机,网络,存储等),DevOps系统对这部分没有控制,只负责在资源环境搭建好后自动化部署应用,资源环境的搭建与之后的应用部署过程是割裂开来的,需要人为的手工协调控制,即等资源环境搭建好后,由人控制时机,等待资源环境准备好后再手工修改配置,然后手工运行自动化脚本工具,如Shell,Python,Ruby脚本,进行应用的安装部署升级,而且之后当增加或减少节点后,也由人来手工运行自动化脚本来配置系统,不能实现包括资源环境创建或节点变更到应用部署的整个过程的一键部署,即集群感知
  • 自动协调控制 + 动态配置 +
    全栈自动化。目前,可以说大多数的DevOps系统仍然停留在这个阶段,由于DevOps系统没有实现资源环境创建的自动化与基于集群感知的协调自动化,那么这个阶段的DevOps系统的能力会造成以下几个影响和后果:创建系统资源环境效率低、耗时、风险高,特别是创建复杂的系统组件多结构复杂时;创建系统资源环境过程需要专门的网络工程师、系统工程师,不能够实现开发测试运维人员自助服务,系统越复杂,沟通成本越大,开发运维过程管理也越复杂;创建整个系统需要网络工程师,系统工程师,开发人员的共同参与和合作,系统组件越多结构越复杂,沟通成本越大,开发运维过程管理也越复杂,费时费力,协调麻烦,风险高且易出错;当系统资源环境变更时,如在增加减少主机后,由人来手工协调控制,人为手工静态配置部署升级所需IP,登陆密码或Key等信息,造成变更过程风险高且效率低,特别是系统庞大和复杂时;交付过程风险高,开发测试产品各个环境不统一,经常出现在一个环境里运行正常,另外一个环境不正常的现象这里需要提的一点就是,尽管很多组织已经在使用IaaS创建虚拟机搭建应用系统所需资源环境,但是并没有实现集群感知,系统整套环境创建的自动化,仍然停留在半自动化的阶段,所以这种方式仍然属于第一代的DevOps系统。同时,这也是国内大多数组织DevOps的现状,其自动化和效率的改进空间巨大。2.基于IaaS的部署时代这是第二代DevOps系统,特点是集群感知
  • 自动协调控制 + 动态配置 +
    全栈自动化。借助于云计算IaaS资源的可编程特性,这一代的DevOps系统实现了集群感知,自动协调控制,动态配置,全栈自动化,即实现了从创建环境到部署安装应用组件整个过程的一键创建和部署,并且在创建后的阶段,能够实现集群感知(Cluster-Aware),即自动根据环境的变更,自动部署和配置系统。举个例子,某网站业务量增长需要扩容时,当人为添加Web计算节点后,能够自动在新添加Web虚拟机启动后安装Web组件,并将各个虚拟机Web服务注册配置到负载均衡服务中,当收缩时,自动移除,这个过程不需要人为的协调控制,DevOps系统能够根据集群的变化自动地配置集群。目前,做到这个层面DevOps系统还是比较少的,由于这个阶段的DevOps系统自动化管理覆盖了环境的创建变更,应用组件部署自动化,以及环境创建,集群感知和应用组件部署的各个过程自动化协调控制,那么这个阶段的DevOps系统相比第一代会给开发和运维工作带来以下非常巨大的改进:开发测试运维人员能够自助创建环境和部署系统,系统越复杂,沟通成本减少越多,开发运维过程管理复杂性风险减少越多,比如只能由有专门知识的工程师做,如果工程师在需要的时候不可用,就很麻烦;创建环境和部署效率高,自动化,快速,所需时间少,风险低;当系统资源环境变更时,如伸缩时,在增加减少主机后,能够实现集群感知,动态配置集群,提高变更过程效率且降低风险,特别是系统组件多庞大和复杂时;能够按需快速创建环境满足各种测试,演示,上线扩容需要能够按需创建启动关闭开发测试环境,节约成本能够提高开发测试和交付的效率3.
    基于容器的部署时代
    这是第三代DevOps系统,特点是在第二代基础上,又增加了应用跨云可迁移性。(基于容器技术)。借助于云计算IaaS资源的可编程特性以及Linux容器技术,不仅实现了集群感知,自动化协调,动态配置和全栈自动化,而且实现了应用跨云可迁移性和弹性伸缩,消除了开发,测试,生产环境的不一致,使应用不会被锁定在某个IaaS上,让所有的基础设施服务IaaS及物理机都变成通用的资源池,还可以提高资源利用率,这给IT的开发建设和运营带来了更多更大的想象空间,这也是Docker,Kubernetes现在很火的原因。举个例子:
    如果我们想把一套服务从AWS迁移到Azure上,那么,我们将不得不从头开始创建一组虚拟机镜像及虚拟机,并配置安装系统或应用的组件,如果系统复杂庞大的话,这个过程仍然会耗费很多的时间和人工,并且依赖于某些具备这个知识的工程师,但是如果有容器技术及相关容器工具的支持,那么这个过程会变成一个非常快速简单的过程,变成在目标云如Azure上自动启动需要的标准虚拟机,然后下载容器镜像,配置启动容器,配置相关DNS等,真正实现方便的跨云迁移,和弹性动态的伸缩服务。再举个例子,目前Google开源的容器管理系统Kubernetes可以说得到了工业界的广泛认同和支持,当我们已经做好应用系统的Docker
    images后,那么只要在各个不同的IaaS上有支持Docker的环境,如Kubernetes集群,那么我们就能在不同的IaaS上快速方便的迁移应用系统,或者扩容,下图展示了基于FIT2CLOUD的跨云部署和管理解决方案,我们希望未来用户可以使用FIT2CLOUD在多个不同的IaaS上创建Kubernetes集群,通过Kubernetes管理和部署应用系统。之后,我们会有新文章来分享FIT2CLOUD是如何创建和运维Kunerbetes集群的。上面这一节中我们介绍了不同时代的DevOps系统的特点和能力,那么是不是我们直接选择能力最强的第三代DevOps系统就可以了吗?
    是不是选一种DevOps系统就通杀了呢?
    答案是否定的,每种DevOps系统都不是银弹,都需要我们根据要管理的系统的需求来选择合适的DevOps系统或工具,在接下来的一节,我们来回答这个问题。三、如何选择适合自己的DevOps系统?目前DevOps系统可以说五花八门非常多,功能上差别大,适用场景也不同,那么我们究竟该如何选择合适的DevOps系统呢?
    这里我们建议一种基于目标系统分类的选择方法。我们根据要管理的目标应用或系统类型来分类,对于目标系统,我们可以将其首先分为三大类,即IaaS服务系统,PaaS服务系统,应用系统,应用系统又可以分为简单的Web应用系统,复杂的分布式系统,那么有了这个分类,我们选择DevOps系统和工具就会相对容易和明确一些。1.
    IaaS服务系统
    由于IaaS系统的创建,本身就是基于物理机创建的,所以对于这类的系统,其适用的DevOps系统或工具就是Shell,Chef,
    Puppet及IaaS服务提供商自身开发的自动化运维管理系统,只能选用第一代的基于物理机的DevOps系统。2.
    PaaS服务系统
    如果一个PaaS不是部署在IaaS之上,从本质上说这不是一个PaaS,因为其不具备弹性和自动伸缩。真正的PaaS系统是部署在IaaS上,为开发测试运维人员来提供服务,那么其适用的DevOps工具就可以选用RightScale,Scalr,Cloudformation,Opsworks和FIT2CLOUD这类第二代基于IaaS可编程资源的DevOps系统,当然也可以选择第三代基于容器的DevOps系统,只是第三代的目前还在发展中,还不如第二代成熟。3.
    简单的Web应用系统
    对于简单的Web应用系统,突出的特点就是应用的结构简单,比如只包含一个Web组件及数据库,缓存,或一些常见的中间件服务等,没有包含非常多的分布式组件,那么对于这类的系统可以选择容器类的传统PaaS,即CloudFoundry,Heroku,OpenShift等。4.
    复杂的分布式应用系统
    对于复杂的分布式应用系统,无法使用容器类PaaS来管理,只能通过自定义的DevOps工具或系统,或者使用云管理RightScale,Scalr,Cloudformation,Opsworks,FIT2CLOUD这类工具的某种或某种组合,即第二代基于IaaS可编程资源的DevOps系统,也可以选择第三代基于容器的DevOps系统。因为这类工具给用户提供了对IaaS主机更大的控制权,且提供了各个部署过程中的回调接口,实现了集群感知及各个部署过程的自动协调控制,即全栈自动化。文章来自:
    Jason @ FIT2CLOUD

图片 2

 

PS:现场 PPT 干货请移步腾讯云技术社区查看及下载哦!

 

结束语

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

图片 3

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

应用架构的可运维性

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

图片 4

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

图片 5

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

图片 6

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

图片 7

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

图片 8

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

图片 9

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

图片 10

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

前言

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

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

腾讯的DevOps实践

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

图片 11

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

图片 12

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

图片 13

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

图片 14

 

腾讯织云的持续部署实践

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

图片 15

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

图片 16

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

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

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

图片 17

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

图片 18

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

图片 19

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

图片 20

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

图片 21

图片 22

相关阅读

腾讯云 GAME-TECH
沙龙干货回顾:与腾讯云携手出海

物理计算云服务需求强烈,腾讯云将推多款黑石新品抢占市场

运维的难题 : 800 万用户,救 or
不救?


 

此文已由作者授权腾讯云技术社区发布,转载请注明文章出处

原文链接:

 

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

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

 

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

嘉宾介绍

图片 23

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

 

 

 

 

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

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

 

 

 

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

第三:CMDB

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

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

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

 

前言

运维的三个阶段

 

运维系统的重要特性

图片 24

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

 

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

图片 25

批量腾挪工具

2.幂等性

图片 26

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

精益发现价值

 

 

 

4.高效率

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

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

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

 

第四:高效的CI/CD/CD

 

 

 

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

 

3.可回滚

 

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

 

弹性伸缩工具

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

 

 

 

 

为什么是配置驱动变更?

实施效果

应用运维平台ATOM

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

 

 

 

 

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

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

 

图片 27

图片 28

 

 

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

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

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

 

 

 

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

 

 

 

自动化运维基础

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

图片 29

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

第一:运维标准与规范

运维工具与方法论

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

 

 

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

 

 

 

 

图片 30

 

 

 

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

 

 

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

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

 

图片 31

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

图片 32

阅读原文

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

 

 

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

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

 

 

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

 

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

 

 

第三块,数据化运营

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

 

 

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

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

图片 33

 

 

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

 

 

 

 

 

OODA环

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

第二块,应用管理

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

图片 34

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

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

 

 

为什么是研发定义运维?

敏捷交付价值

 

 

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