很荣幸加入 IDCF 组织的第 6 期 DevOps 案例深度钻研，咱们小组的分享主题为《牛转乾坤继续运维》，之所以定这样一个主题，是因为咱们在讲 DevOps 的时候往往更多侧重于软件研发的过程，咱们心愿通过本次案例钻研，带给大家更多对于运维的出现和理解。
置信大家听得比拟多的是“运维”、“IT 服务”，而“继续运维”算是个新词儿，每个人对这个词都有不同的了解，所以咱们首先要了解“继续运维”的定义，并达成共识，而后进而深入研究继续运维要解决好的三个阶段与档次：继续部署、继续运行、继续反馈与改良。
一、如何定义“继续运维”
咱们无妨将“继续运维”拆开来看，先从运维的角度看其关注的内容与软件开发过程有哪些异同，而后谈谈咱们对于“运维的继续”的了解，最初再尝试给出“继续运维”的定义。
1.1 当谈运维时谈些什么？
1.1.1 你眼中的运维
每个人看到的角度不一样，对运维也有不同的印象。在业务人员眼中运维是修电脑、装网线的，没有两把刷子干不了；运维人员认为本人就像救火队员、敢死队员，上游挖的坑，上游来填，妥妥的背锅侠。
运维圈还风行一句话“零碎失常是失常的，零碎不失常是不失常的”，怎么了解呢？就是说零碎不失常也是一种失常，就像一个人不可能不生病，要害是咱们如何去面对和医治。延长到零碎，要害就在于咱们如何发现和面对故障，改良才是最须要的，敢于面对失败，从中吸取教训，这也是 DevOps 提倡的。
1.1.2 运维的产生
先有 IT 建设，因为管理学上的专业化分工，业余的人做业余的事，运维逐步从建设团队中独立进去成为独自的一拨人，造成运维部门。对于一些甲方单位，大部分须要内部 IT 部门进行建设，逐步造成了甲方的 IT 部门，而这个部门次要承当的就是建设 + 运维的治理性能，具体的事务性工作由承建单位负责。
运维和开发是同样重要的，一个负责生，一个负责养，缺一不可，并不是说开发部署完就高枕无忧了。
传统的我的项目个别是交付当前就进入运维期，运维次要是保障建设的内容可能继续地提供价值。当初很多互联网类的产品型公司，在某个业务畛域进行产品型的迭代降级，运维也是一样，保障所有建设的内容都可能不衰减。
如上图所示，IT 建设里不只是有软件研发，还有基础设施建设。IT 建设是从 0 - 1 的过程，IT 运维是保障 1 -∞的过程，运维能够依据建设的目标让建设的内容起到料想的作用。
1.1.3 IT 建设内容 → IT 运维资产 → IT 服务资产
IT 建设内容包含系统软件（机房）、环境能源硬件设施、操作系统、虚拟机、软件撑持零碎等；到终端和用户这块，还包含各种灾备环境。到互联网时代用了云环境，很多工作可能就交给云服务商来做。
IT 建设的目标是什么呢？当然是为了应用，而且心愿能好用，于是咱们建设的内容就成了须要 IT 运维去保护的资产。
上图列出了不少软件开发人员平时可能不太关注的 CI（在运维中，CI 是指配置项）。他们个别是由基础设施团队、集成团队来施行装置的。正所谓：千里之堤溃于蝼蚁，这些基础设施就如同大厦的地基一样，地基牢固了，能力建更高的楼。
再晋升一个高度来看，这些内容能够作为 IT 服务资产，通过与人员、流程、工具等的整合，独特作为一种服务能力，保障业务的连续性。
1.1.4 运维的倒退
IT 技术的倒退突飞猛进，从基础架构、运维形式及软件架构方面都有了飞跃式的倒退，不能说哪个好哪个不好，每个倒退都是适应了时代的需要。
一方面开发的技术和治理办法在倒退。逐步从瀑布到迭代麻利型的开发，还有 MVP 等实践推动的精益守业这样先进的治理办法得以采纳。
咱们能够看到运维经验了从繁多技术到服务治理的倒退，从原来被动救火到被动通过人工智能伎俩进步解决问题的能力，工具也从传统的手工为主到当初的自动化智能化数字化，运维工作更高效无力，运维人员更轻松，运维部门也缓缓从老本核心向盈利核心转变。
原来的治理只须要管好单机、机房，当初要治理的是分布式、云架构等简单多态的环境，为适应这种变动，运维治理的方法论也在一直地降级。多种方法论的交融与实用，给运维部门提出了挑战和参考。
治理方法的倒退脉络：
- 第一次 IT 故障：1968 年圣诞节，阿波罗 8 号正在执行盘绕月球航行工作，三个宇航员中的罗威尔无心中触动 P01 键，导致所有导航数据将清零，零碎行将解体。软件部长期任命玛格丽特. 汉密尔顿为组长，她率领一支 20 人的小分队前去“灭火”。之前编写的程序派上了用途，间断奋战 9 小时后，错误信息被纠正，零碎复原运行。这是一次大的故障，也正是因为这次故障，运维被提上日程。
- ITIL 概念呈现于上世纪 80 年代，过后英国政府认为向他们提供的 IT 服务质量程度不够。由地方计算机和电信局（Central Computer and Telecommunications Agency，简称 CCTA），现称为政府商业办公室开发一个 IT 服务框架，以在英国政府和私营部门内高效经济地应用 IT 资源。（ITSM：技术治理：技术是基本，技术是管理手段，更是治理的对象。）这是 ITIL V1 的公布。
- ITIL V2：用流程驱动人、用过程治理后果。
- ITIL V3：生命周期、继续改良。联合了 COBIT 等思维。
- ITIL 4：服务价值零碎，联合了 DevOps、麻利精益等思维。
- 2003 年，Google 成立了 Google SRE 小组，是其外部运维的实际。
- 2009 年，DevOps 理念产生，至 2015 年 11 月倒退成为一种文化、静止或实际，它强调软件开发人员和其余信息技术人员的合作和沟通，同时强调自动化软件交付和基础设施变更的过程。当初 DevOps 越来越宏大和宏观，从开发运维延长到整个开发的全流程，包含业务、开发、平安、测试、运维等各个环节的合作。
1.1.5 ITIL-ITSM 的最佳实际
说到 IT 服务治理，不能不提 ITSM 的最佳实际——ITIL。
ITIL V3 是 2007 年公布的，排汇了 V2 的精髓，从服务的生命周期看整个 IT 组织须要做的内容，包含 26 个流程和 4 个职能。原来的运维更多局限于被动操作，ITIL V3 定义了运维须要更早地进入业务。
- 服务策略：能够认为是从甲方的视角看，首先有一个业务策略需要制订，而后有本人的 IT 需要治理，同时做服务组合，比方要做哪些业务类的事件、须要哪些 IT 撑持。服务策略是从业务策略到 IT 策略的转换。
- 服务设计和转换：首先是各种后期治理，而后是对运维环境进行容量连续性思考，同时须要做从开发到运维的常识治理，如何交接、如何做激励计划，再之后还有公布和变更的治理。
- 服务经营：包含监控和运行中的问题如何解决、如何解决，如何从根本上杜绝这一类故障。
- 继续服务改良：即如何改良整个 IT 服务质量，次要包含两大块：服务测量和服务报告。这里引进了七步改进法，当初的状况是什么样的？如何改良？通过哪些数据去度量？
前文介绍过，这一方法论的提出者是英国政府商务部，它是一个甲方部门，更多是从甲方的交付思考问题，比方在服务设计里有供应商治理，包含如何与供应商合作、整个过程设计和转化的时候须要思考容量连续性等。
ITIL V4 联合了数字化转型等理念，从价值体系的角度登程进行论述，并把 ITIL V3 的流程整合到 34 个实际中，次要包含以下 5 个维度：
- 创立、交付与反对
- 驱动利益相关者价值
- 高速 IT
- 领导、打算与改良
- 数字化与 IT 策略
1.1.6 服务与产品的个性比照
在学习 DevOps 时，不晓得大家是否关注过一个问题：开发和运维在工作时，解决问题的办法、工具都有很大的差异。即便应用同样的工具，其用法也可能存在差别。开发更多面向产品，要保障产品是否被人所须要，是不是合乎品质要求，次要是对事；而运维更多是要将产品或者服务提供给人，次要是对人。
咱们要把运维做好，决不能单单从产品的角度思考问题，更应该重视服务的特点。想想海底捞为什么大家违心为它买单，应该不只是其产品做得好，很重要的一点是它提供了优质的服务体验。
（服务与产品的个性比照）
从上表的比照中咱们能够看出，服务是有形的，在服务里生产和生产是同步的，服务的过程治理更难度量和评估，而运维就是一个提供服务的过程。
1.2 当谈继续时谈些什么？
1.2.1 什么是继续运维？
说到继续，大家可能会想到继续集成、继续部署，咱们无妨将视线放大一些，看看其它可继续倒退指标，比方联合国制订了 17 个寰球倒退指标。
扯远了，说回到继续运维，其实很难和上图进行类比联想，毕竟咱们认为的运维就是保证系统运行不出事就行了，而不是一个阶段一个阶段去晋升，就像晋升人类的物质精神文明。
咱们来看从 DevOps 常识体系如何定义继续运维。
（图片起源：EXIN DevOps 白皮书 – 企业 DevOps 的成功之路）
如图所示，DevOps 常识体系包含几个过程：麻利治理、继续交付、IT 服务治理，独特保障业务联系性。由此咱们能够晓得继续运维不是指标，而是一种伎俩。
说到这里仿佛还不能得出继续运维的定义，咱们换个角度，试着通过是与否的问题来找答案。运维不是什么？运维相对不是饮鸩止渴、竭泽而渔，而是心愿可能防患未然、防患于未然，就是要更早地解决问题，让隐患没有机会产生。
咱们查找了 CI/CD/CT 的定义：
工厂里的装配线以疾速、自动化、可反复的形式从原材料生产出消费品。同样，软件交付管道以疾速、自动化和可反复的形式从源代码生成公布版本。如何实现这项工作的总体设计称为“继续交付”（CD）。启动装配线的过程称为“继续集成”（CI）。确保品质的过程称为“继续测试”（CT），将最终产品提供给用户的过程称为“继续部署”。一些专家让这所有简略、顺畅、高效地运行，这些人被称为运维开发 DevOps 践行者。
至此，咱们尝试给继续运维（CO）下一个定义：
为晋升业务继续倒退，对 IT 服务治理的总体设计，称为“继续运维”。
（内容起源：《什么是 CI/CD？(继续集成 / 继续交付)》https://blog.csdn.net/guofang…）
1.2.2 继续运维的三个档次
咱们认为应该以服务为核心，开发整个运维的流动。运维作为服务最终用户的第一责任人，承当起把价值源源不断地交付给客户的工作。
因而咱们定义了如下三个继续运维的档次：
- 作为与开发的接口，可能一直地转换新的服务到最终用户。——继续公布；
- 可能让最终用户称心地应用提供的服务、性能和效用。——继续运行；
- 须要建设业务开发的被动连贯，可能依据运行中的反馈，继续反馈给整个服务组织，并进行继续改良。——继续反馈与改良。
二、继续部署
2.1 继续部署定义
从上图咱们能够看出软件研发的几个阶段别离是继续集成、继续交付和继续部署，继续部署是继续交付的下一步或者说更高阶段，指的是代码通过评审当前（或者是通过自动化测试当前）主动部署到生产环境。继续部署是继续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改变都将主动部署到生产环境。
2.2 继续部署反模式
咱们在实际继续部署的时候，会遇到很多反模式的存在，介绍两个典型的继续部署反模式：手工部署软件、开发实现后才向类生产环境部署。
2.2.1 手工部署软件
通常咱们会有一份很详尽的文档，相似葵花宝典，而后通过人工验证、手工部署环境，而后烧香祷告，而后果往往是不得不回滚，或遇到不可预感的问题。
2.2.2 开发实现后才向类生产环境部署
研发阶段开发裹足不前，上类生产前一时刻将个性交接给运维人员，开发人员认为就是个小个性，不会出问题，失常上班后回家，而运维人员拿到变更需要，一脸懵，安装程序和配置文件不匹配，数据库没有回退脚本，部署文档少写了依赖，一连串的问题，导致无奈失常上线。从此友情的小船翻了~
2.3 继续部署中的重大问题
在很多优良的企业中，从部署到生产环境都遇到很多问题。
- 第一个案例来自驰名的代码资源托管平台 GitLab，2017 年 2 月 1 日，GitLab 的一位工程师在保护数据时不慎删除约 300GB 的数据，当天凌晨，闹事系统管理员通宵加班工作，当他疲倦不堪地进行数据库保护时，不慎用 rm -rf 命令对 300GB 生产环境数据执行了删除操作，当他清醒过来按下 ctrl + c 来进行删除操作时，却只挽留了 4.5G 的数据，其余所有数据隐没殆尽。
- 第二个案例来自英国的 TSB 银行，数据大规模迁徙至新的软件平台，造成了数周的大规模中断，激怒了该银行的 500 万客户，最终导致其首席执行官辞职。
- 最初一个案例来自谷歌公司，2020 年 12 月 14 日晚间，Google 服务器又一次寰球宕机。这是近 5 个月来第 3 次寰球宕机。Google 旗下的 YouTube、Gmail、Google Drive、Google Search 等服务呈现死机，用户无奈失常应用，寰球多个国家及地区用户均受到影响。Google 随后发推文确认，因为外部存储配额问题，Google 身份验证零碎中断。
这三个血淋淋的案例带给咱们的警示，代码诚可贵，个性价更高，若引生产倒，两者都不要~
2.4 如何做到继续部署
为什么总是临门一脚却射不中呢？如何能力做到继续部署？我认为有三个方向能够致力：
- 更疾速的交付，能够通过制品内容标准化，生产过程清晰化，上线过程轻量化来实现，也就是配置管理；
- 更平安的交付，通过代码平安、过程平安、制品平安和环境平安等平安管理手段实现；
- 更频繁的交付，意味着变更要流程化，工具要自动化，过程要可视化，也就是变更治理，通过配置管理、平安治理和变更治理，实现效率、平安、性能的指标，买通继续交付到继续部署的最初一公里。
2.4.1 配置管理
配置管理是指将所有与我的项目相干的产物，及它们之间的关系都被惟一定义、批改、存储和检索的过程。
它包含四个方面的工作：版本控制、依赖管制、软件治理和环境配置。
1）版本控制
也就是团队在写作开发代码的状况下，记录下代码每一次变更状况。这里以 Git 为例，要对所有的内容进行版本控制（源码、测试代码、构建脚本、部署脚本、数据库脚本），保持频繁地提交代码到骨干，并应用意义显著的提交正文。
2）依赖管制
就是记录利用依赖的二方、三方包，并进行治理，包含 maven\npm\pip\gradle 都是不同语言的依赖管理工具，在依赖治理中要做到在编译阶段创立二进制部署包，并上传到制品库；保障一致性，要依照 GAV 三元组（groupId/artifactId/version）惟一标识和援用一个对象；制品库能够按用处分为长期制品库和正式制品库。
3）软件治理
指配置中心化，配置与利用隔离，对立治理，优雅地解决了配置的动静变更、权限治理、长久化等问题。
软件配置有三种实现形式，别离是打包时注入、部署时注入和运行时拉取。
- 打包时注入是在打包的时候，构建脚本能够将配置信息与二进制文件一起注入到部署包中，通过不同的制品包部署到不同的环境上，这种模式的场景是在大量动态配置文件，或者配置每次随二进制程序变更；长处是打包和部署的过程比较简单，不同环境应用特定的部署包；毛病是环境、利用、配置紧耦合，灵活性低。
- 部署时注入是在进行部署时，部署脚本获取根底配置以及不同环境特定的配置项，动静生成每个环境所需的配置信息。相当于基于配置模板文件，在部署时再实例化为将要部署利用的具体环境的配置。这种模式的场景是大量的配置项，一些配置项在不同环境中存在差别；长处是能够应用部署脚本或工具，动静生成特定环境配置信息；毛病是须要保护利用与配置版本的匹配关系，减少了复杂度。
- 运行时拉取就是在利用启动或运行时，通过内部的配置服务拉取利用配置（如通过 REST 格调的接口）。当初很多应用容器部署的微服务架构零碎，配置核心或配置服务都是其十分外围的组件之一。这种模式的场景是频繁变更配置项，或者须要动静加载利用配置；长处是部署包与配置彻底解耦，具备较高的灵活性；毛病是须要思考配置核心的高可用性和配置变更的原子性。
(内容起源：张乐老师 https://blog.csdn.net/weixin_…)
（图片起源：QCon 北京 2017）
这两位老哥 1984 年在 IEEE 上发表了一篇论文，论文的题目就是《分布式系统的动静配置》。过后他们对分布式系统的了解可能还没有达到明天这个档次，他们可能也设想不到分布式系统起初倒退到明天这么宏大，这么简单。但他们对动静配置这个畛域的问题看得比较清楚，就是在一个大型的分布式系统中，你没有方法把整个分布式系统停下来，去做一个软件、硬件或者零碎的降级。
接下来介绍几个阿里的实际案例。
（图片起源：QCon 北京 2017）
咱们晓得，当你的零碎同时涌进来超过一亿人并发拜访的时候，这个零碎肯定是扛不住的，肯定会挂掉，在这个过程中咱们讲大促有 3 大法宝：弹性、限流、降级。零碎的限流和降级实质上来讲就是从日常的运行态切换到大促态的一个行为的动静调整，这个自身人造就是配置起到作用的一个相应的场景。
随着大促工夫点的邻近，这些分布式系统中，每个子系统会有大大小小的预案，这些预案其实都是以配置的模式存在的。配置核心会在这个时间轴上，定时地安顿执行预案，每个零碎哪些性能降级，在什么时候降级，什么时候凋谢哪些专门为大促存在的一些性能，在大促之前的工夫点，整个利用发布会封盘，被禁止掉了，曾经不容许做任何线上公布了，那在这个时候要切换零碎的行为，就是靠配置核心发挥作用。
（图片起源：QCon 北京 2017）
最早淘宝配置核心产生的起因之一就是要解决大规模数据容灾的问题。
一般来说，为了高可用，业务可能部署在 2 个机房，当初个别同城双机房是标配。数据存储，比方像 MySQL，在生产上为了高可用，可能会装备一主几备，主库是可写的，备库可能是只读的。在生产上可能有几台机器坏了或者甚至一个机房坏了，出问题、故障了，根底设置（infrastructure）这块可能有一些事件冒泡到软件平台 PaaS 这一层，这个事件冒泡个别会到 DBA 团队的一些数据库高可用基础设施，DBA 会依据整个业务零碎在机房的部署拓扑，找到这个坏掉的机房里的所有的主库，做一个主备库的切换，把备库切成可写。
在这个过程中，配置核心的作用就是跟 DBA 的高可用切换工具放弃联动，DBA 工具负责数据库切换，产生数据源配置变更，所有利用基于配置核心监听各自的数据源配置变更，当产生主备库切换，配置核心会将数据源配置变更推送到利用，整个过程对利用是通明无感知的。
（图片起源：QCon 北京 2017）
当初一些大型的互联网零碎，CDN 前面会有一个对立接入层，包含 PC 和挪动端的流量可能都是从这个对立接入层进入到生产的机房。在这个过程中，对立接入层负责依据前端用户的属性，去调配用户的流量到后端不同的单元。当一个单元挂了之后，这些流量须要无缝地切到其它的业务单元里去，这个单元糅合了机房及业务域的一些划分，在这个过程中，配置核心要起到一个要害的作用：在对立接入的机器上，让它们对于全局的流量规定达成一个分布式共识，这实际上是分布式一致性的要求。
4）环境配置 CMDB
咱们运维的对象分两大类：一类是基础设施，包含机房、机架、服务器、网络设备、安全设备等；另一类是构建在基础设施之上的服务，包含应用程序、中间件、域名等等。
（图片起源：https://www.infoq.cn/article/…）
上图具体介绍了运维所面临的资源模型，包含根底属性、配置属性、运行状态、关联关系等。
环境配置的实现形式有两种：Agent 形式和 ssh 类。
Agent 形式
（图片起源：https://www.cnblogs.com/xueca…）
Agent 形式其本质上就是在各个服务器上执行 subprocess.getoutput()命令，将每台机器上执行的后果通过 request 模块返回给主机 API，主机 API 收到这些数据后放入到数据库中，而后通过 web 界面将数据展示给用户。
- 场景：服务器比拟多。
- 长处：速度快。
- 毛病：须要为每一台服务器部署一个 Agent 程序。
ssh 类
（图片起源：https://www.cnblogs.com/xueca…）
CMDB 管理员录入资产后，API 从数据库中获取到未采集的机器列表，发送到中控机服务器中，中控机服务器通过 paramiko 模块登录到服务器上进行信息的采集，服务器采集完后再将后果返回给中控机，而后将从服务器中失去的信息通过 request 模块发送给 API，API 通过主机名和 SN 作为惟一标识，将信息录入到数据中，再通过 web 界面将数据展示给用户。
- 场景：服务器较少。
- 毛病：依赖于网络，速度慢。
- 长处：没有 Agent，不须要为每一台服务器部署一个 Agent 程序。
介绍一个腾讯的实际案例。
（图片起源：https://www.bookstack.cn/read…）
腾讯的蓝鲸配置平台（CC）是一款面向利用的 CMDB，在 ITIL 体系里，配置管理数据库（CMDB）是构建其它流程的根底，配置平台做为面向业务层面的 CMDB，为蓝鲸体系的其它平台提供了各类运维场景的配置数据服务，存储与治理企业 IT 架构中设施的各类配置信息，它与全副服务反对和服务交付流程都紧密相联，反对这些流程的运行、施展配置信息的价值，同时依赖于相干流程保证数据的准确性。
它将整个环境配置分成了四层：
- 资源层（store）。提供零碎所需的资源存储、音讯队列以及缓存零碎服务。
- 服务层(service layer)。服务层划分为两大模块：资源管理模块，在配置平台中把资源类型进行了形象，目前划分为主机、过程、通用对象三大类，反对横向扩大，每一类资源由一类微服务过程来治理；业务场景模块，业务场景模块是基于资源管理模块的原子接口对利用场景的封装，基于操作的相关度，目前划分出 admin、event、host、topo、process、datacollection 几个微服务。
- 接口层(api)。这一层是零碎的 API 服务网关。
- web 层(web)。web 层是零碎提供的 web 服务。通过配置平台提供的 web 服务界面，用户能够进行资源的操作。
2.4.2 平安治理
1）平安现状
去年 GitLab 发动对于平安的年度考察，有 29% 的考察人员反馈平安和大家非亲非故，那平安场景下的运维模式是怎么的呢？
（图片起源：GitLab 于 2020 年 1 月至 2 月 29 日对寰球 21 个国家的 3650 多名软件专业人士进行了考察）
DevSecOps 是 DevOps 的另一种实际，它将信息技术安全性作为软件开发所有阶段的一个基本点。安全性不仅波及各种档次的隔离和合规性查看，还波及从技术层面确保业务连续性。
（图片起源：DevSecOps（Development Security Operations））
2）DevSecOps
DevSecOps 由 Gartner 征询公司研究员 David Cearley 在 2012 年首次提出，它是一种糅合了开发、平安及经营理念的全新平安管理模式。
DevSecOps 九大实际因素，其中“黄带”代表如何应答常见威逼来保护客户与品牌，“绿带”代表软件、网络、系统管理员、数据库管理员。其中的安全意识、团队工作协定、同业人员评审和平安评估均在强调企业组织对于 DevSecOps 的接受程度，以及整个企业文化中的安全意识，是影响 DevSecOps 实际的重要因素。技术能让平安融入 DevOps 过程，但人、流程以及文化能力推动 DevSecOps 常态化。
（图片起源：https://www.secrss.com/articl…）
DevSecOps 施行难点：
- 安全性被认为是 DevOps 灵活性的一种妨碍。
- 企业安全意识不足。
- 开发和经营人员平安技能有余。
- 业务流程与平安工具的对接艰难。
看一个小米的实际案例。
（图片起源：https://www.infoq.cn/article/…）
小米通过组织层面成立平安 BP 工作组，来强化平安团队和业务团队的沟通。基于平安 BP，让平安更加深刻到业务中，更理解业务的流程和制订对应的平安计划，让业务真正感触到平安在帮忙业务。
在指标和考核上，他们会关注破绽按时修复率。为不同危险等级破绽定义不同的修复周期，当破绽呈现须要对应工程师在修复周期内实现修复，而不是用破绽数量等指标来考核，心愿可能和业务站在一起，有助于晋升安全意识和能力。
在安全意识宣传和平安培训方面，他们也做了很多工作，不仅有面向整体员工的根底培训，而且还有针对不同业务或不同角色的专项培训。
在技术上，他们为业务提供了多种自动化的零碎或工具、平安 SDK，还会和业务的流程联合起来，让平安融入到业务流程中，同时防止人工适度参加妨碍业务流程。
2.4.3 变更治理
变更不仅仅是广义的上线新版本代码，也应该蕴含配置变更、数据变更、操作系统变更、网络变更、基础设施变更等方面。变更是运维人员的次要工作内容，同时也是导致服务故障的次要起因。
据 Google SRE 统计，线上 70% 的故障都是由某种变更而触发的。变更与所有运维人员是严密相干的，运维背的所有锅也都与此有关。
为什么要做变更治理？因为要管制影响，包含范畴、进度、老本、品质、危险、资源等，个别我的项目管理系统中都包含我的项目管理信息系统、配置管理系统，以及最重要的变更管理系统。
- 变更管理系统个别包含范畴变更、进度变更、老本变更、合同变更等控制系统，同时还会成立一个专门的变更管制委员会。
- 范畴变更控制系统定义我的项目范畴变更的无关流程。它包含必要的书面文件（如变更申请单）、跟踪零碎和受权变更的批准等级。
- 进度变更控制系统规定我的项目进度变更所应遵循的手续，包含书面申请、追踪零碎以及核准变更的审批级别。
- 老本变更控制系统是一种我的项目老本管制的程序性办法，次要通过建设我的项目老本变更管制体系，对我的项目老本进行管制。该零碎次要包含三个局部：老本变更申请、批准老本变更申请和变更我的项目老本估算。
- 合同变更控制系统包含四个组成部分：文书工作、跟踪零碎、争议解决程序、审批档次。
- 变更管制委员会（Change Control Board, CCB）组成：我的项目单方项目管理人员（部门领导、高层经理、项目经理）、技术人员（开发人员、测试负责人、质量保证负责人 QA）、商务人员。其次要工作：负责评估那些被提交上来的变更申请，针对这些变更的目标、要求和影响来决策：批准施行一项变更申请，并且在会议上安顿相干的变更施行负责人和相关联的合作组织；回绝某一项变更申请，给出回绝理由。
（图片起源：https://www.ffeeii.com/1793.html）
看一个唯品会的实际案例。
唯品会提出了危险矩阵，他们做了一个 SDK，这个矩阵用一句话形容就是“把原有的变更危险从对象和技术危险两个维度进行了拆分。”
（图片起源：王俊峰在 GOPS 寰球运维大会 2018 深圳站演讲）
对象是指一个业务零碎，可能是外围零碎，也可能是重要零碎，也可能是不重要的零碎，能够对它进行画像和打分。这两者联合在一起，能够对所有变更有一个精准的打分。
规范变更模版库是指专家针对每个组件进行变更模板设计，组件基于专家设计的模板进行变更，不可天马行空地想变更计划。
对于生态买通方面，一开始的思路是比拟巨大的，原来想的是设计一个完满的流程，把相干生态齐全买通，前面发现很难把运维相干的工具体系买通。唯品会的思路是逐渐实现这种能力，比方 ABCD 零碎之间，先买通 AB，而后买通 CD，从而建设了非常灵活的自动化变更零碎。
但这也是一把双刃剑，可能导致 DevOps 变更失控，变更流程得不到严格遵守，危险评估不精确，效率升高流程抵触、变更的品质管制也变得比拟艰难等问题。
真正要实现的变更买通设计思路：
- 首先，流程零碎提供 SDK 给各自动化工具，提供变更的管控能力、变更的收集能力和 SDK 的自治能力；
- 第二，自动化能力平台，梳理变更危险矩阵集成 SDK，上报变更危险矩阵；
- 第三，执行变更时，传入变更内容，SDK 依据无效的规定配置进行计算，断定变更是否能够执行，审批后果的回调接口，对于局部变更可能会有后盾流程配合。
（图片起源：王俊峰在 GOPS 寰球运维大会 2018 深圳站演讲）
上图是唯品会的整体架构，两头是一个规范模版库，技术专家组设计了一套规范变更，SDK 跟右边的关联是从负载平衡治理平台、定时工作治理平台、云平台、运维平台以及买通这些平台给开发人员赋能。
当初开发人员如果想做简略的线上业务配置，只须要在 tools 平台上提交一个申请，地方管控认为危险非常低就能够间接做完了。这一架构带来的收益也很显著：固话规范变更，简化流程，无效管制变更危险，同时赋能开发，提高效率。
2.5 最初一公里
在实现继续交付到继续部署的最初一公里时，
- 通过配置管理，实现制品内容标准化、生产过程清晰化、上线过程轻量化，让继续部署更快！
- 通过平安治理，实现代码平安、过程平安、制品平安、环境平安，让继续部署更平安！
- 通过变更治理，实现变更流程化、工具自动化、过程可视化，让继续部署更频繁！
三、继续运行
业务服务上线后就交给了运维，运维须要保障系统和服务健康成长，为社会发明价值，这就是继续运行。
3.1 SRE
为确保服务继续运行，即进步服务的可靠性，咱们借鉴了谷歌提出的 SRE 工程体系。接下来开展介绍 Mikey 金字塔的可靠性层次结构。
Mikey 七层金字塔围绕着沟通设计，每一层都建设在前一层的根底之上。它被沟通所突围，因为每一层都须要沟通能力胜利。
- 第一层是监控。确保洞察零碎、跟踪零碎的衰弱状态、可用性，以及零碎外部产生的事件。
- 第二层是事变响应。如果呈现故障，该如何揭示大家并做出回应？
- 第三层是预先回顾。一旦产生服务中断，如何确保问题不会再次发生？
- 第四层是测试和公布软件。这个层级是 Mikey 金字塔中第一个专一于预防而不是预先解决的层级。预防是指尝试限度产生的事变数量，并确保在公布新代码时基础架构和服务可能保持稳定。
- 第五层是容量布局。这是对于预测将来和发现零碎极限的。容量布局也是为了确保零碎能够随着工夫的推移失去欠缺和加强。
- 第六层是开发新工具和服务。SRE 不仅波及运维，还波及软件开发，心愿 SRE 工程师将破费大概一半的工夫来开发新的工具和服务。咱们晓得对运维而言，尤其是在散布零碎里，要做到高可用和高牢靠，须要实现零碎自动化，而自动化不能仅仅只靠开发人员和软件架构来实现，还须要运维可能有自主开发代码和工具的能力。
- 最初一层是用户体验，即确保用户取得良好的体验。
3.1.1 监控
监控是继续运行的基石。打个比方，咱们个别都会通过体检采集各项身材指标来判断一个人是否衰弱，同样，对于部署到生产的利用零碎，须要通过监控采集相干运行数据，判断零碎是否处于失常衰弱的运行状态。
监控的目标个别分为两类：体检、急诊。
- 体检包含对系统进行容量和性能治理。容器治理，提供一个全局的零碎运行时数据的展现，能够让工程师团队晓得是否须要减少机器或其余资源。性能治理，能够通过查看大盘，找到零碎瓶颈，并有针对性地优化零碎和相应代码。
- 急诊包含对系统存在的问题进行定位和性能剖析。定位问题，能够疾速裸露并找到问题的产生点，帮忙技术人员诊断问题；性能剖析，当呈现非预期的流量晋升时，能够疾速找到零碎的瓶颈，帮忙开发人员深刻代码，找到并疾速修复异样。
要实现对利用的可观测性和监控能力，须要采集和剖析三个局部的数据：指标、利用跟踪、日志。
- 指标包含系统监控（USE）、利用监控（RED），通过零碎的使用率、饱和度和谬误数，利用的申请数、错误率和响应工夫，看以后零碎和利用，包含操作系统、中间件等，运行是否失常，是否存在瓶颈或异样。
- 利用跟踪包含利用过程的资源应用状况、程序之间的调用状况、程序外部外围逻辑的运行状况等，比方过程占用的 CPU、内存、磁盘 I/O、网络等，应用过多的系统资源，导致应用程序响应迟缓或者谬误数升高，是一个最常见的性能问题；程序间调用的频率、谬误数、延时等，因为应用程序并不是孤立的，如果其依赖的其余利用呈现了性能问题，利用本身性能也会受到影响。还包含关键环节的耗时、执行过程中的谬误等，因为这是应用程序外部的状态，从内部通常无奈间接获取到具体的性能数据，更须要在利用外部进行埋点把逻辑执行的状况裸露进去。
- 日志包含流水日志和利用日志。流水日志个别就是整个交易的状况，通过对不同维度指标的聚合，能够对整个零碎和业务的运行状况进行多维和下钻剖析，当出现异常时，还能够进行具体的业务影响剖析；利用日志记录业务或利用零碎的运行状况，包含裸露的谬误等，能够进行含糊查问，出现异常时，可能依据日志疾速定位故障点。
再来看监控体系。
- 最上层是根底监控设施，包含根底服务、网络、机房。
- 往上一层是零碎利用监控，包含过程、容量、性能等。
- 再往上是服务端和客户端业务监控，包含业务指标、端监控。
- 最下面是用户反馈系统，比方以后是否有大量客户投诉，是否存在舆情。
整个监控体系从上往下，下层是业务监控，上层是根底监控，依据教训统计，90% 的根底监控发现约 30% 的问题，10% 的业务监控发现约 70% 的问题。阿里的监控指标：1 分钟发现问题，5 分钟定位问题，10 分钟复原服务。
上图展现了如何利用开源工具和产品实现利用可观测性。
- 日志次要用 ElasticSearch 框架来做。Filebeat 采集后通过 Kafka 传入 LogStash 里去做聚合和解析，而后放到 ES 里进行存储，并通过 Kibana 展现。
- 对于指标数据，当初比拟风行的是用 Prometheus 或 Jenkins 来进行零碎 / 利用根本指标数据采集。
- 对于跟踪数据，用 Skywalking 部署一个 agent，对外部调用状况进行采集。
后面介绍了这么多监控到的数据维度，最终如何掂量一个零碎是否稳固呢？以前是通过用异样工夫除以总体工夫得出一个值，比方 4 个 9 或 5 个 9，也就是常说的 SLO。当初来看以工夫作为指标，粒度比拟粗，不便于统计，比方一段时间之内发现了一些偶发性的谬误，这个时间段到底算不算曾经出现异常或故障的工夫？
比拟现实的指标是申请成功率。比方一个 API 被调用 1 万次，胜利了 9999 次，能够认为它的 SLO 值是 4 个 9，这样粒度更细也更精准。还能够依据 SLO 制订谬误估算，即一个周期内（如 4 周）如果超过谬误估算将不容许减少新性能，阐明零碎不稳固，应该优先解决生产问题，防止雪上加霜。
监控的目标是将问题通过告警的形式裸露进去。咱们通过采集日志、指标等信息，并对每个信息设置阈值或关键字生成告警，告警的信息量很大，CPU、内存、关键字等每个点都是一个监控的危险点，并不是每个危险点裸露进去都是故障或问题，须要对告警信息进行剖析和压缩，最初告诉到工作人员对告警的问题进行解决和修复。
3.1.2 事变响应
收到告警即代表这时可能曾经呈现问题，咱们须要对整个事变进行响应。
（图片起源：赵成《SRE 实战手册》）
在 SRE 里，将整个运行周期分为两大部分，MTBF、MTTR。
- MTBF：Mean Time Between Failure，均匀故障工夫距离，示意零碎失常运行。
- MTTR：Mean Time To Repair，故障均匀修复工夫，示意零碎产生故障。
咱们的指标是晋升 MTBF，升高 MTTR。
MTTR 能够进行流的拆分：
- MTTI：Mean Time To Identify，均匀故障发现工夫。
- MTTK：Mean Time To Know，均匀故障认知工夫。
- MTTF：Mean Time To Fix，均匀故障解决工夫
- MTTV：Mean Time To Verify，均匀故障修复验证工夫。
现实状态是产生即发现，发现即定位，定位即复原。
典型的故障排查过程：
- 最开始咱们通过各式各样的预设报警发现异常（通常是 Metrics/Logging）。
- 发现异常后，关上监控大盘查找异样的曲线，并通过各种查问 / 统计找到异样的模块（Metrics）。
- 对这个模块以及关联的日志进行查问 / 统计分析，找到外围的报错信息（Logging）。
- 最初通过具体的调用链数据定位到引起问题的代码（Tracing）。
（图片起源：Grafana Loki）
上图展现的是排查思路，首先有告警，而后看大盘上显示哪个中央可能有红色报警点或曲线异样，针对异样曲线和报警点查问具体报错日志，再依据追踪深刻代码，最初修复问题。当然这是一个比拟现实的状态。
上图所示为整个事变的响应流程。通过舆情感知、监控告警、AIOps 对海量数据进行异样检测发现故障；利用日志剖析、链路跟踪、根因定位进行故障定位；采纳容灾切换、服务降级、限流、熔断、重启扩容等伎俩，疾速进行故障复原；通过故障复盘、改良验收、故障模拟、混沌工程、容量压测等实现故障改良。
3.1.3 预先回顾
咱们须要借助预先回顾来发现、解决、躲避危险。经典的复盘黄金三问：
- 第一问：故障起因有哪些？
- 第二问：咱们做什么，怎么做能力确保下次不会再呈现相似故障？
- 第三问：过后如果咱们做了什么，能够用更短的工夫复原业务？
通过复盘总结的教训，能够作为后续的应急预案，也能够和告警进行关联，匹配对应场景，通过自动化平台实现故障自愈。
3.1.4 预防
要保障系统的继续运行，还须要做到预防。但故障是零碎运行的常态，没有异样才是非凡状态。真正要做到预防也不是件容易的事，须要开发人员在设计架构时留神做到：
- Design For Failure。亚马逊提出的概念，即面向失败去设计，在架构设计的时候要思考网络产生抖动或提早等状况。
- 架构高可用。要避免出现单点故障（比方某个过程或服务器出现异常）导致整个服务不可用的状况。
- 监控可观测性。通过内部可观测零碎外部具体运行的状况。
- 可运维性是利用零碎的外围性能
- 非性能需要 != 非必要的性能需要
3.2 混沌工程
混沌工程：将故障注入零碎以测试系统对其的响应。通过故障演练验证零碎是否高可用。其益处是使公司可能为宕机做筹备，并在宕机产生之前将其影响降至最低。
故障演练：指标是积淀通用的故障模式，以可控老本在线上重放，以持续性的演练和回归形式来裸露问题，一直推动零碎、工具、流程、人员能力的不断前进，进步继续运行的能力。
3.2.1 故障注入
（图片起源：@我吃印度飞饼）
故障注入与业务零碎的架构是贴合的，当初故障注入的能力越来越强，能够从网络层面，模仿网络抖动和丢包等；从存储的层面，模仿磁盘打满；从虚拟化的层面，间接把服务器宕机；还能够从操作系统层面、中间件层面、利用的 runtime 层面，注入相应故障，检测零碎在这些状况下是否可用。
（阿里的 ChaosBlade 架构 图片起源：知乎 @Java 钢铁侠 - 马克 5）
四、继续反馈与改良
4.1 反馈是什么
在狭义概念上来讲，反馈是零碎与环境相互作用的一种模式。在零碎与环境相互作用过程中，零碎的输入成为输出的局部，反过来作用于零碎自身，从而影响零碎的输入。
这句话听起来有点拗口，咱们来举个活泼的例子。看过《天龙八部》的同学肯定晓得“北乔峰、南慕容”，“以彼之道还施彼身”是慕容复的武学心得。也就是把你的文治绝学（输出）通过排汇学习后为我所用（输入）。
咱们在生活中也随时感触着反馈。比方在京东或天猫等电商平台上买货色的时候，平台个别会给你优惠券或返减折扣，这也是反馈。
同时，依据反馈对输入产生影响的性质，可分为正反馈和负反馈。前者加强零碎的输入；后者削弱零碎的输入。
比方费曼学习法，就是利用试讲者与凝听者的交换反馈机制，在每次交换反馈后及时对下一次试讲的内容进行语言条理的优化、简化和精炼讲述，以达到在最短时间内深刻了解知识点和增进学习的成果。
理解了什么是反馈后，咱们来看反馈有哪些分类。
咱们对于反馈分类的了解是基于不同视角和角色的。以互联网企业和软件产品的日常反馈举例：日常生活接触到的反馈场景，包含部门外部反馈、企业外部反馈，企业内部反馈及用户反馈等等。
通常，一个运维部门外部的日常反馈模式是：通过系统监控的报警、正告、Log 日志等进行问题剖析；通过系统日志和正告信息，剖析排查问题产生的起因，从而对问题进行定位和修复。
企业的外部反馈较为卓有成效的是借助监控平台和 DevOps 办法的落地实际，能够将用户故事通过正当的产品及性能点拆分，内置到系统配置、部署和构建运行的流水线中，以达到零碎能够时时自动化公布，反对企业业务连续性的目标。
当然，企业除了外部的失常运行，还肩负社会价值和对外的价值输入，如股价、非凡日期的销售量，大家最相熟的应该就是双十一和 618 的电商销量了。
用户反馈波及到数据分析中的反馈收集。在数据分析中，行为剖析是大家热衷的焦点之一。从久远来看，用户行为剖析的次要目标是心愿通过找到一些法则来预测用户将来的行为，比方咱们找到了用户某种个性和用户散失之间的关系，就能够通过监控这一个性的变动及时挽留用户。
还能够通过用户行为剖析来积淀用户视角下的测试 Case。咱们收集的大量用户行为 Case，其应用场景不仅仅是对新性能进行自动化测试，还能够针对用户进行标签化匹配。
4.2 不反馈的问题！
不反馈会产生的问题包含：闭门造车、反馈不及时、造成人员和资源的节约、反复的需要、过期的需要、客户需要的频繁改变，与客户预期的生产零碎不统一、零碎紧急任务和突发危险成几何基数增长，大量用户问题特定工夫内集中暴发等。
不及时反馈和数据的关系：数据谬误的呈现数量和频率与数据传递的门路长度和传递时长成正比。
说到底，不反馈、有效反馈或者回绝反馈，是负反馈放大的开始，它最终将导致企业和集体的价值散失和升值。
4.3 如何建设反馈
4.3.1 建设反馈价值流动的闭环
对于软件公司来说，研发侧和经营侧的指标是对立的，就是为企业更加疾速而高效地发明价值，同时晋升客户的满意度和认可度。
如何无效达到反馈的目标呢？这里的“效”涵盖了两方面的含意：成果、效率。
- 进步成果侧重于如何使传播的信息被正确承受和执行。
- 提高效率侧重于如何用起码的工夫和资源来传播信息。
咱们认为的继续反馈是在品质、效率、平安、老本、翻新价值的价值流动治理，外围是人与人的无效沟通，让反馈能够进行继续的流动。
上图可看到，左侧研发价值流转，从影响地图开始接触用户进行商业剖析，到用户故事，包含产品精益画布设计，到 CI/CI 继续集成和继续交付，再到自动化流水线公布到正式环境；右侧是业务价值的监控剖析，包含客户起源剖析、老本管制治理、数据品质剖析、平安性能监控，以及将来联合经营侧进行 AI 智能化经营，还能够联合用户应用时长零碎，提出好的创意和想法，利用服务和利润，回到左侧的研发价值流，实现价值的闭环流动。
4.4 继续改善
继续改善（Kaizen）办法最后是一个日本治理概念，指逐步、间断地减少改善。继续改善波及每一个人每个环节连续不断地改良，从最高的治理部门到管理人员到工人。
PDCA 戴明环也是支流的反馈改良领导方法论，如图服务 7 步法，更好地展示了螺旋回升的反馈过程。
反馈是一个继续优化的链路，包含从数据埋点到数字化运维到 DevOps 再到 AIOps 的全链路。
4.5 反馈的案例及工具
接下来介绍传统的运维反馈工具，包含《IT 运维服务报告》、可视化的监控大屏以及被动反馈和混动工程的回报。
4.5.1 反馈工具 -《IT 运维服务报告》
咱们常见的运维反馈工具，如《IT 运费服务报告》，是 PDCA 外面的 C -Check，次要作用是从品质、效率、平安、老本四个维度进行的运维状况查看、扫视与成绩汇报。
它个别会蕴含多厂商、多协定和面向各种利用的体系结构，须要解决各类设施、子系统间的接口、协定、零碎平台、应用软件等与子系统、机房环境、施工配合、组织治理和人员配备相干的面向集成的问题，通过运维报告进行状况阐明。
如上图，运维的价值、反馈价值、用户端的价值是继续流动改良优化的。
DevOps 有三个准则，别离是流动准则，即从业务侧向运维侧的交付流动；反馈准则，即从运维侧向业务侧反馈问题或异样；继续学习与试验准则，即继续试错、继续翻新和继续学习，改善和晋升组织效率。
继续反馈是 DevOps 的第二个准则，是建设各个环节的反馈机制。通过埋点、监控，将部署、测试、公布、运维、平安等环节须要监测的内容进行可视化展示，或者进行自动化关联剖析，目标是为了可能让故障或问题在被用户发现之前被本人人发现。相干的指标如均匀故障复原工夫（MTTR）、均匀无故障工夫（MTBF）。
运维对外价值次要体现为客户业务价值反馈。
比方基于特定我的项目和销售日的反馈：天猫双 11 和京东 618。2020 年是“双 11”的第 12 个年头，受疫情影响生产习惯产生大幅扭转以及直播电商的疾速倒退，双十一人们生产激情空前低落。数据显示，2020 年“双十一”全网销售额曾经达到 2673.65 亿元。2020 年的 618 大促落下帷幕时，天猫和京东累计下单金额别离达到 6982 亿元和 2692 亿元，双双创下新纪录。
4.5.2 继续反馈工具 - 监控大屏
运维另一种更加直观无效的工具就是监控大屏，直观可见各个运维参数指标，通过运维的数据进行指标度量和监控指标剖析；可出现社会价值和经营价值，如某县 GDP 和经济总产值、人口产业分部、累计生产总值、电子商务倒退指数等；在疫情等非凡期间，民众能够在百度上查问获取疫情实时大数据报告。让每个人都能够随时理解身边的疫情状况，追溯和理解确诊人数、高风险地区和人群散布状况等。
4.5.3《DevOps Handbook》反馈实际
继续反馈实际，次要是监控和告警能力的建设。继续反馈的非技术因素包含：组织、人员等软文化因素。
继续反馈三步工作法：首先从抉择价值流入手；流动准则，打造继续部署流水线的根底；反馈准则，建设监控发现和解决问题；继续学习和试验准则，注入学习到日常工作中；最初要解决的就是集成平安、变更治理和合规性的技术实际。
4.5.4 被动反馈和混沌工程
前文提到的玛格丽特·汉密尔顿，是最早提出软件工程这一概念的人，也能够说是第一代的 SRE 工程师。汉密尔顿在阿波罗登月打算中负责软件系统的开发。有一次她女儿在模仿仓游玩时不小心错按了按键。这让她开始思考，既然故障总是会产生，那么咱们就有必要提前进行故障演练的场景测试。
在阿波罗 8 号之后，汉密尔顿开启了最早的故障场景模仿测试，咱们能够了解为是混沌工程最早的雏形。
阿波罗 13 号的登月失败就是因为细节和故障的产生不可控、且非线性，简直将三名宇航员困在太空，这一事件引发了历史上最雄心勃勃的救济工作。这里我想要强调的是咱们生存的世界存在着非线性的危险和突发事件，咱们必须具备面对和解决它的办法与技巧。混动工程就是一个很好的计划。
（图片起源见图上标识）
咱们再看一下被动式 IT 运维服务和主动式 IT 运维服务的区别。从监控伎俩、异样呈现的应答、异样信息的历史记录参考、运维有规范化的制度、运维人员从救火队员向急救员的转变；业余的运维报告、具备连续性和指导意义，工作可量化防止对运维专家的强依赖，这都是从被动运维向被动 IT 运维服务带来的益处。
混沌工程的回报
对于混沌成熟度模型，Netflix 总结了两个维度：复杂度和接受度。前者示意的是混沌工程能有多简单，而后者则示意的是混沌工程被团队的接受程度。
咱们来看 Netflix 2018 年应用混沌工程的投入产出比。
- 2018 年混沌工程提前发现了 2 次重大事故跟 8 次小事变，防止了整个组织大概 70 万美金的损失。
- 混沌工程团队，总共 3 个成员，薪水收入 15 万美金 / 人。
通过计算，得出其投资回报率 52.17%，这是一个相当令人兴奋的后果，它的要害是危险提前发现和解决。
（图片起源：Netflix 报告：The Business Case for Chaos Engineering.2018）
4.6 AIOps（智能运维）
4.6.1 什么是智能运维？AIOps
AIOps 这一概念是在 2017 年由 Gartner 从基于大数据及算法裁减为基于人工智能的，2018 年举办的 GOPS 大会上，AIOps 还处于刚起步的阶段。
（图片起源：GOPS 寰球运维大会 2018 年. 深圳站《亿级用户百 TB 级数据的 AIOps 实际之路》周荣 - 华为消费者 BG 云运维部）
那么从传统运维到 AIOps 有哪些变动呢？
（图片起源：GOPS 寰球运维大会 2018 年. 深圳站《亿级用户百 TB 级数据的 AIOps 实际之路》周荣 - 华为消费者 BG 云运维部）
上图展现了运维的倒退，从晚期的传统运维，逐步进步零碎执行及决策的能力，到 AIOps 时代，大略要达到百分百零碎执行，95% 零碎决策，仅有 5% 须要人工决策。AIOps 次要实现的性能包含：性能监控预警和自应用调整，故障诊断和主动复原，性能趋势剖析和自扩大，问题诊断和要害因子分析，异样告警等趋势和辅助决策分析等等。所以我了解的 AIOps 理论是在自动化运维的根底上，收集各种监控数据，基于数据规定研发算法，达到自适应、主动复原、自扩大的目标。
4.6.2 AIOps 落地挑战
AIOps 落地面临一系列挑战，包含：数据获取、烦扰数据过滤、算法准确性及性能、暗藏危险、研发投入与收益等。
4.6.3 AIOps 金字塔
DevOps 实现端到端的研发过程系统化，基于 DevOps、Iaas 平台等做全链路监控，对监控预警做进一步的降级提炼，实现故障主动解决、容量主动优化、弹性扩缩容等；所有的运维监数据，做数据分析、梳理事件主动解决策略，而后通过机器学习赋能运维。
总结这样一个金字塔，是为了清晰地展现 AIOps 须要有肯定的根底能力做，就像盖房子要有地基一样。
最现实的自动化状态是机器齐全自动化剖析和运行，如华伦·贝尼斯所说：将来的工程里只有一个人，一条狗。人是要喂狗，狗是要看住人，不让他碰机器。
五、总结
5.1 PDCA 的继续运维
PDCA 继续运维是一个价值流动的闭环：继续部署包含配置管理、平安治理、变更治理；继续运行包含 SRE、监控、混沌工程，保证系统稳定性、高可用和反软弱；继续反馈案例和工具包含 AIOps、监控看板、度量等；继续改良环节包含被动反馈、复盘和 OnCall 等。
5.2 ITIL 与 DevOps 的继续运维
ITIL V4 是在需要输出和价值输入之间有一个闭环的改良过程。DevOps 的三步工作法，第一步是从左到右疾速的流动；第二步开始有从右到左的疾速反馈；第三步是把整个继续的过程一直迭代。
最初用两个词对本次分享进行总结：简略、连贯。
- 用简略的继续运维服务。防止繁琐的流程和简单的架构带来不必要的影响和耗费。
- 去连贯人、资源、产品。继续运维须要放弃人、资源、产品的高效沟通和稳固运行。
参考资料
- EXIN DevOps 白皮书 – 企业 DevOps 的成功之路
- 《什么是 CI/CD？(继续集成 / 继续交付)》：https://blog.csdn.net/guofang…
- 张乐老师 https://blog.csdn.net/weixin_…
- QCon 北京 2017
- https://www.infoq.cn/article/…
- https://www.cnblogs.com/xueca…
- https://www.bookstack.cn/read…
- GitLab 于 2020 年 1 月至 2 月 29 日对寰球 21 个国家的 3650 多名软件专业人士进行了考察
- DevSecOps（Development Security Operations）
- https://www.secrss.com/articl…
- https://www.infoq.cn/article/…
- https://www.ffeeii.com/1793.html
- 王俊峰在 GOPS 寰球运维大会 2018 深圳站演讲
- 赵成《SRE 实战手册》
- Grafana Loki
- Netflix 报告：The Business Case for Chaos Engineering.2018
- GOPS 寰球运维大会 2018 年. 深圳站《亿级用户百 TB 级数据的 AIOps 实际之路》周荣 - 华为消费者 BG 云运维部
内容起源：DevOps 案例深度钻研第 6 期——继续运维实际钻研战队
本案例内容贡献者：陈一梦、董殿清、冀利斌、李博、刘威、刘扬清、康连波、米永鹏、王艳、张扬