相信大家听得比较多的是“运维”、“IT服务”，而“持续运维”算是个新词儿，每个人对这个词都有不同的理解，所以我们首先要理解“持续运维”的定义，并达成共识，然后进而深入研究持续运维要处理好的三个阶段与层次：持续部署、持续运行、持续反馈与改进。
每个人看到的角度不一样，对运维也有不同的印象。在业务人员眼中运维是修电脑、装网线的，没有两把刷子干不了；运维人员认为自己就像救火队员、敢死队员，上游挖的坑，下游来填，妥妥的背锅侠。
运维圈还流行一句话“系统正常是正常的，系统不正常是不正常的”，怎么理解呢？就是说系统不正常也是一种正常，就像一个人不可能不生病，关键是我们如何去面对和治疗。延伸到系统，关键就在于我们如何发现和面对故障，改进才是最需要的，敢于面对失败，从中吸取教训，这也是DevOps提倡的。
先有IT建设，由于管理学上的专业化分工，专业的人做专业的事，运维逐渐从建设团队中独立出来成为单独的一拨人，形成运维部门。对于一些甲方单位，大部分需要外部IT部门进行建设，逐渐形成了甲方的IT部门，而这个部门主要承担的就是建设+运维的管理功能，具体的事务性工作由承建单位负责。
运维和开发是同样重要的，一个负责生，一个负责养，缺一不可，并不是说开发部署完就万事大吉了。
传统的项目一般是交付以后就进入运维期，运维主要是保证建设的内容能够持续地提供价值。现在很多互联网类的产品型公司，在某个业务领域进行产品型的迭代升级，运维也是一样，保证所有建设的内容都能够不衰减。
如上图所示，IT建设里不只是有软件研发，还有基础设施建设。IT建设是从0-1的过程，IT运维是保障1-∞的过程，运维可以根据建设的目的让建设的内容起到预想的作用。
IT建设内容包括系统软件（机房）、环境动力硬件设备、操作系统、虚拟机、软件支撑系统等；到终端和用户这块，还包括各种灾备环境。到互联网时代用了云环境，很多工作可能就交给云服务商来做。
IT建设的目的是什么呢？当然是为了使用，而且希望能好用，于是我们建设的内容就成了需要IT运维去维护的资产。
再提升一个高度来看，这些内容可以作为IT服务资产，通过与人员、流程、工具等的整合，共同作为一种服务能力，保障业务的连续性。
IT技术的发展日新月异，从基础架构、运维方式及软件架构方面都有了飞跃式的发展，不能说哪个好哪个不好，每个发展都是适应了时代的需求。
一方面开发的技术和管理方法在发展。逐渐从瀑布到迭代敏捷型的开发，还有MVP等理论推动的精益创业这样先进的管理方法得以采用。
我们可以看到运维经历了从单一技术到服务管理的发展，从原来被动救火到主动通过人工智能手段提高解决问题的能力，工具也从传统的手工为主到现在的自动化智能化数字化，运维工作更高效有力，运维人员更轻松，运维部门也慢慢从成本中心向盈利中心转变。
原来的管理只需要管好单机、机房，现在要管理的是分布式、云架构等复杂多态的环境，为顺应这种变化，运维管理的方法论也在不断地升级。多种方法论的融合与实用，给运维部门提出了挑战和参考。
管理办法的发展脉络：
说到IT服务管理，不能不提ITSM的最佳实践——ITIL。
ITILV3是2007年发布的，吸收了V2的精华，从服务的生命周期看整个IT组织需要做的内容，包括26个流程和4个职能。原来的运维更多局限于被动操作，ITILV3定义了运维需要更早地进入业务。
前文介绍过，这一方法论的提出者是英国政府商务部，它是一个甲方部门，更多是从甲方的交付考虑问题，比如在服务设计里有供应商管理，包括如何与供应商协作、整个过程设计和转化的时候需要考虑容量连续性等。
ITILV4结合了数字化转型等理念，从价值体系的角度出发进行阐述，并把ITILV3的流程整合到34个实践中，主要包括以下5个维度：
我们要把运维做好，决不能单单从产品的角度考虑问题，更应该注重服务的特点。想想海底捞为什么大家愿意为它买单，应该不只是其产品做得好，很重要的一点是它提供了优质的服务体验。
（服务与产品的特性对比）
从上表的对比中我们可以看出，服务是无形的，在服务里生产和消费是同步的，服务的过程管理更难度量和评价，而运维就是一个提供服务的过程。
说到持续，大家可能会想到持续集成、持续部署，我们不妨将视野放大一些，看看其它可持续发展目标，比如联合国制定了17个全球发展目标。
扯远了，说回到持续运维，其实很难和上图进行类比联想，毕竟我们认为的运维就是保证系统运行不出事就行了，而不是一个阶段一个阶段去提升，就像提升人类的物质精神文明。我们来看从DevOps知识体系如何定义持续运维。
如图所示，DevOps知识体系包括几个过程：敏捷管理、持续交付、IT服务管理，共同保证业务联系性。由此我们可以知道持续运维不是目标，而是一种手段。
说到这里似乎还不能得出持续运维的定义，我们换个角度，试着通过是与否的问题来找答案。运维不是什么？运维绝对不是杀鸡取卵、竭泽而渔，而是希望能够未雨绸缪、防患于未然，就是要更早地处理问题，让隐患没有机会发生。
我们查找了CI/CD/CT的定义：
至此，我们尝试给持续运维（CO）下一个定义：
我们认为应该以服务为中心，开发整个运维的活动。运维作为服务最终用户的第一责任人，承担起把价值源源不断地交付给客户的任务。
因此我们定义了如下三个持续运维的层次：
从上图我们可以看出软件研发的几个阶段分别是持续集成、持续交付和持续部署，持续部署是持续交付的下一步或者说更高阶段，指的是代码通过评审以后（或者是通过自动化测试以后）自动部署到生产环境。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。
我们在实践持续部署的时候，会遇到很多反模式的存在，介绍两个典型的持续部署反模式：手工部署软件、开发完成后才向类生产环境部署。
通常我们会有一份很详尽的文档，类似葵花宝典，然后通过人工验证、手工部署环境，然后烧香祈祷，而结果往往是不得不回滚，或遇到不可预见的问题。
研发阶段开发一往无前，上类生产前一时刻将特性交接给运维人员，开发人员以为就是个小特性，不会出问题，正常下班后回家，而运维人员拿到变更需求，一脸懵，安装程序和配置文件不匹配，数据库没有回退脚本，部署文档少写了依赖，一连串的问题，导致无法正常上线。从此友谊的小船翻了~
在很多优秀的企业中，从部署到生产环境都遇到很多问题。
这三个血淋淋的案例带给我们的警示，代码诚可贵，特性价更高，若引生产倒，两者都不要~
为什么总是临门一脚却射不中呢？如何才能做到持续部署？我认为有三个方向可以努力：
它包括四个方面的工作：版本控制、依赖控制、软件管理和环境配置。
也就是团队在写作开发代码的情况下，记录下代码每一次变更情况。这里以Git为例，要对所有的内容进行版本控制（源码、测试代码、构建脚本、部署脚本、数据库脚本），坚持频繁地提交代码到主干，并使用意义明显的提交注释。
就是记录应用依赖的二方、三方包，并进行管理，包括maven\npm\pip\gradle都是不同语言的依赖管理工具，在依赖管理中要做到在编译阶段创建二进制部署包，并上传到制品库；保证一致性，要按照GAV三元组（groupId/artifactId/version）唯一标识和引用一个对象；制品库可以按用途分为临时制品库和正式制品库。
指配置中心化，配置与应用隔离，统一管理，优雅地解决了配置的动态变更、权限管理、持久化等问题。
软件配置有三种实现方式，分别是打包时注入、部署时注入和运行时拉取。
这两位老哥1984年在IEEE上发表了一篇论文，论文的题目就是《分布式系统的动态配置》。当时他们对分布式系统的理解可能还没有达到今天这个层次，他们可能也想象不到分布式系统后来发展到今天这么庞大，这么复杂。但他们对动态配置这个领域的问题看得比较清楚，就是在一个大型的分布式系统中，你没有办法把整个分布式系统停下来，去做一个软件、硬件或者系统的升级。
接下来介绍几个阿里的实践案例。
我们知道，当你的系统同时涌进来超过一亿人并发访问的时候，这个系统一定是扛不住的，一定会挂掉，在这个过程中我们讲大促有3大法宝：弹性、限流、降级。系统的限流和降级本质上来讲就是从日常的运行态切换到大促态的一个行为的动态调整，这个本身天然就是配置起到作用的一个相应的场景。
最早淘宝配置中心产生的原因之一就是要解决大规模数据容灾的问题。
一般来说，为了高可用，业务可能部署在2个机房，现在一般同城双机房是标配。数据存储，比如像MySQL，在生产上为了高可用，可能会配备一主几备，主库是可写的，备库可能是只读的。在生产上可能有几台机器坏了或者甚至一个机房坏了，出问题、故障了，基础设置（infrastructure）这块可能有一些事件冒泡到软件平台PaaS这一层，这个事件冒泡一般会到DBA团队的一些数据库高可用基础设施，DBA会根据整个业务系统在机房的部署拓扑，找到这个坏掉的机房里的所有的主库，做一个主备库的切换，把备库切成可写。
在这个过程中，配置中心的作用就是跟DBA的高可用切换工具保持联动，DBA工具负责数据库切换，产生数据源配置变更，所有应用基于配置中心监听各自的数据源配置变更，当产生主备库切换，配置中心会将数据源配置变更推送到应用，整个过程对应用是透明无感知的。
现在一些大型的互联网系统，CDN后面会有一个统一接入层，包括PC和移动端的流量可能都是从这个统一接入层进入到生产的机房。在这个过程中，统一接入层负责根据前端用户的属性，去分配用户的流量到后端不同的单元。当一个单元挂了之后，这些流量需要无缝地切到其它的业务单元里去，这个单元糅合了机房及业务域的一些划分，在这个过程中，配置中心要起到一个关键的作用：在统一接入的机器上，让它们对于全局的流量规则达成一个分布式共识，这实际上是分布式一致性的要求。
我们运维的对象分两大类：一类是基础设施，包括机房、机架、服务器、网络设备、安全设备等；另一类是构建在基础设施之上的服务，包括应用程序、中间件、域名等等。
上图详细介绍了运维所面临的资源模型，包括基础属性、配置属性、运行状态、关联关系等。环境配置的实现方式有两种：Agent方式和ssh类。
Agent方式
Agent方式其本质上就是在各个服务器上执行subprocess.getoutput()命令，将每台机器上执行的结果通过request模块返回给主机API，主机API收到这些数据后放入到数据库中，然后通过web界面将数据展现给用户。
ssh类
介绍一个腾讯的实践案例。
它将整个环境配置分成了四层：
DevSecOps是DevOps的另一种实践，它将信息技术安全性作为软件开发所有阶段的一个基本点。安全性不仅涉及各种层次的隔离和合规性检查，还涉及从技术层面确保业务连续性。
DevSecOps由Gartner咨询公司研究员DavidCearley在2012年首次提出，它是一种糅合了开发、安全及运营理念的全新安全管理模式。
DevSecOps九大实践要素，其中“黄带”代表如何应对常见威胁来维护客户与品牌，“绿带”代表软件、网络、系统管理员、数据库管理员。其中的安全意识、团队工作协议、同业人员评审和安全评估均在强调企业组织对于DevSecOps的接受程度，以及整个企业文化中的安全意识，是影响DevSecOps实践的重要因素。技术能让安全融入DevOps过程，但人、流程以及文化才能推动DevSecOps常态化。
DevSecOps实施难点：
看一个小米的实践案例。
小米通过组织层面成立安全BP工作组，来强化安全团队和业务团队的沟通。基于安全BP，让安全更加深入到业务中，更了解业务的流程和制定对应的安全方案，让业务真正感受到安全在帮助业务。
在安全意识宣传和安全培训方面，他们也做了很多工作，不仅有面向全体员工的基础培训，而且还有针对不同业务或不同角色的专项培训。
在技术上，他们为业务提供了多种自动化的系统或工具、安全SDK，还会和业务的流程结合起来，让安全融入到业务流程中，同时避免人工过度参与阻碍业务流程。
变更不仅仅是狭义的上线新版本代码，也应该包含配置变更、数据变更、操作系统变更、网络变更、基础设施变更等方面。变更是运维人员的主要工作内容，同时也是导致服务故障的主要原因。
为什么要做变更管理？因为要控制影响，包括范围、进度、成本、质量、风险、资源等，一般项目管理系统中都包括项目管理信息系统、配置管理系统，以及最重要的变更管理系统。
看一个唯品会的实践案例。
唯品会提出了风险矩阵，他们做了一个SDK，这个矩阵用一句话形容就是“把原有的变更风险从对象和技术风险两个维度进行了拆分。”
对象是指一个业务系统，可能是核心系统，也可能是重要系统，也可能是不重要的系统，可以对它进行画像和打分。这两者结合在一起，可以对所有变更有一个精准的打分。
标准变更模版库是指专家针对每个组件进行变更模板设计，组件基于专家设计的模板进行变更，不可天马行空地想变更方案。
但这也是一把双刃剑，可能导致DevOps变更失控，变更流程得不到严格遵守，风险评估不准确，效率降低流程冲突、变更的质量控制也变得比较困难等问题。
真正要实现的变更打通设计思路：
上图是唯品会的整体架构，中间是一个标准模版库，技术专家组设计了一套标准变更，SDK跟左边的关联是从负载均衡管理平台、定时任务管理平台、云平台、运维平台以及打通这些平台给开发人员赋能。
现在开发人员如果想做简单的线上业务配置，只需要在tools平台上提交一个申请，中央管控认为风险非常低就可以直接做完了。这一架构带来的收益也很明显：固话标准变更，简化流程，有效控制变更风险，同时赋能开发，提高效率。
在实现持续交付到持续部署的最后一公里时，
业务服务上线后就交给了运维，运维需要保障系统和服务健康成长，为社会创造价值，这就是持续运行。
为确保服务持续运行，即提高服务的可靠性，我们借鉴了谷歌提出的SRE工程体系。接下来展开介绍Mikey金字塔的可靠性层次结构。
Mikey七层金字塔围绕着沟通设计，每一层都建立在前一层的基础之上。它被沟通所包围，因为每一层都需要沟通才能成功。
监控的目的一般分为两类：体检、急诊。
要实现对应用的可观测性和监控能力，需要采集和分析三个部分的数据：指标、应用跟踪、日志。
再来看监控体系。
整个监控体系从上往下，上层是业务监控，下层是基础监控，根据经验统计，90%的基础监控发现约30%的问题，10%的业务监控发现约70%的问题。阿里的监控指标：1分钟发现问题，5分钟定位问题，10分钟恢复服务。
上图展示了如何利用开源工具和产品实现应用可观测性。
比较理想的指标是请求成功率。比如一个API被调用1万次，成功了9999次，可以认为它的SLO值是4个9，这样粒度更细也更精准。还可以根据SLO制定错误预算，即一个周期内（如4周）如果超过错误预算将不允许增加新功能，说明系统不稳定，应该优先解决生产问题，避免雪上加霜。
监控的目的是将问题通过告警的方式暴露出来。我们通过采集日志、指标等信息，并对每个信息设置阈值或关键字生成告警，告警的信息量很大，CPU、内存、关键字等每个点都是一个监控的风险点，并不是每个风险点暴露出来都是故障或问题，需要对告警信息进行分析和压缩，最后通知到工作人员对告警的问题进行处理和修复。
收到告警即代表这时可能已经出现问题，我们需要对整个事故进行响应。
在SRE里，将整个运行周期分为两大部分，MTBF、MTTR。
我们的目标是提升MTBF，降低MTTR。
MTTR可以进行流的拆分：
理想状态是发生即发现，发现即定位，定位即恢复。
典型的故障排查过程：
上图展示的是排查思路，首先有告警，然后看大盘上显示哪个地方可能有红色报警点或曲线异常，针对异常曲线和报警点查询具体报错日志，再根据追踪深入代码，最后修复问题。当然这是一个比较理想的状态。
上图所示为整个事故的响应流程。通过舆情感知、监控告警、AIOps对海量数据进行异常检测发现故障；利用日志分析、链路跟踪、根因定位进行故障定位；采用容灾切换、服务降级、限流、熔断、重启扩容等手段，快速进行故障恢复；通过故障复盘、改进验收、故障模拟、混沌工程、容量压测等实现故障改进。
我们需要借助事后回顾来发现、解决、规避风险。经典的复盘黄金三问：
通过复盘总结的经验，可以作为后续的应急预案，也可以和告警进行关联，匹配对应场景，通过自动化平台实现故障自愈。
要保障系统的持续运行，还需要做到预防。但故障是系统运行的常态，没有异常才是特殊状态。真正要做到预防也不是件容易的事，需要开发人员在设计架构时注意做到：
混沌工程：将故障注入系统以测试系统对其的响应。通过故障演练验证系统是否高可用。其好处是使公司能够为宕机做准备，并在宕机发生之前将其影响降至最低。
故障演练：目标是沉淀通用的故障模式，以可控成本在线上重放，以持续性的演练和回归方式来暴露问题，不断推动系统、工具、流程、人员能力的不断前进，提高持续运行的能力。
故障注入与业务系统的架构是贴合的，现在故障注入的能力越来越强，可以从网络层面，模拟网络抖动和丢包等；从存储的层面，模拟磁盘打满；从虚拟化的层面，直接把服务器宕机；还可以从操作系统层面、中间件层面、应用的runtime层面，注入相应故障，检测系统在这些情况下是否可用。
在广义概念上来讲，反馈是系统与环境相互作用的一种形式。在系统与环境相互作用过程中，系统的输出成为输入的部分，反过来作用于系统本身，从而影响系统的输出。
这句话听起来有点拗口，我们来举个生动的例子。看过《天龙八部》的同学一定知道“北乔峰、南慕容”，“以彼之道还施彼身”是慕容复的武学心得。也就是把你的武功绝学（输入）通过吸收学习后为我所用（输出）。
我们在生活中也随时感受着反馈。比如在京东或天猫等电商平台上买东西的时候，平台一般会给你优惠券或返减折扣，这也是反馈。
同时，根据反馈对输出产生影响的性质，可分为正反馈和负反馈。前者增强系统的输出；后者减弱系统的输出。
了解了什么是反馈后，我们来看反馈有哪些分类。
我们对于反馈分类的理解是基于不同视角和角色的。以互联网企业和软件产品的日常反馈举例：日常生活接触到的反馈场景，包括部门内部反馈、企业内部反馈，企业外部反馈及用户反馈等等。
通常，一个运维部门内部的日常反馈形式是：通过系统监控的报警、警告、Log日志等进行问题分析；通过系统日志和警告信息，分析排查问题发生的原因，从而对问题进行定位和修复。企业的内部反馈较为行之有效的是借助监控平台和DevOps方法的落地实践，可以将用户故事通过合理的产品及功能点拆分，内置到系统配置、部署和构建运行的流水线中，以达到系统可以时时自动化发布，支持企业业务连续性的目的。
当然，企业除了内部的正常运转，还肩负社会价值和对外的价值输出，如股价、特殊日期的销售量，大家最熟悉的应该就是双十一和618的电商销量了。
用户反馈涉及到数据分析中的反馈收集。在数据分析中，行为分析是大家热衷的焦点之一。从长远来看，用户行为分析的主要目的是希望通过找到一些规律来预测用户未来的行为，比如我们找到了用户某种特性和用户流失之间的关系，就可以通过监控这一特性的变化及时挽留用户。
还可以通过用户行为分析来沉淀用户视角下的测试Case。我们收集的大量用户行为Case，其使用场景不仅仅是对新功能进行自动化测试，还可以针对用户进行标签化匹配。
不及时反馈和数据的关系：数据错误的出现数量和频率与数据传递的路径长度和传递时长成正比。
说到底，不反馈、无效反馈或者拒绝反馈，是负反馈放大的开始，它最终将导致企业和个人的价值流失和贬值。
对于软件公司来说，研发侧和运营侧的目标是统一的，就是为企业更加快速而高效地创造价值，同时提升客户的满意度和认可度。
如何有效达到反馈的目的呢？这里的“效”涵盖了两方面的含义：效果、效率。
我们认为的持续反馈是在质量、效率、安全、成本、创新价值的价值流动管理，核心是人与人的有效沟通，让反馈可以进行持续的流动。
持续改善（Kaizen）方法最初是一个日本管理概念，指逐渐、连续地增加改善。持续改善涉及每一个人每个环节连续不断地改进，从最高的管理部门到管理人员到工人。
PDCA戴明环也是主流的反馈改进指导方法论，如图服务7步法，更好地展现了螺旋上升的反馈过程。
反馈是一个持续优化的链路，包括从数据埋点到数字化运维到DevOps再到AIOps的全链路。
接下来介绍传统的运维反馈工具，包括《IT运维服务报告》、可视化的监控大屏以及主动反馈和混动工程的回报。
我们常见的运维反馈工具，如《IT运费服务报告》，是PDCA里面的C-Check，主要作用是从质量、效率、安全、成本四个维度进行的运维情况检查、审视与成果汇报。
如上图，运维的价值、反馈价值、用户端的价值是持续流动改进优化的。
DevOps有三个原则，分别是流动原则，即从业务侧向运维侧的交付流动；反馈原则，即从运维侧向业务侧反馈问题或异常；持续学习与实验原则，即持续试错、持续创新和持续学习，改善和提升组织效率。
运维对外价值主要体现为客户业务价值反馈。
比如基于特定项目和销售日的反馈：天猫双11和京东618。2020年是“双11”的第12个年头，受疫情影响消费习惯发生大幅改变以及直播电商的快速发展，双十一人们消费热情空前高涨。数据显示，2020年“双十一”全网销售额已经达到2673.65亿元。2020年的618大促落下帷幕时，天猫和京东累计下单金额分别达到6982亿元和2692亿元，双双创下新纪录。
运维另一种更加直观有效的工具就是监控大屏，直观可见各个运维参数指标，通过运维的数据进行指标度量和监控指标分析；可呈现社会价值和运营价值，如某县GDP和经济总产值、人口产业分部、累计生产总值、电子商务发展指数等；在疫情等特殊时期，民众可以在百度上查询获取疫情实时大数据报告。让每个人都可以随时了解身边的疫情情况，追溯和了解确诊人数、高风险地区和人群分布情况等。
持续反馈实践，主要是监控和告警能力的建设。持续反馈的非技术要素包括：组织、人员等软文化因素。
持续反馈三步工作法：首先从选择价值流入手；流动原则，打造持续部署流水线的基础；反馈原则，建立监控发现和解决问题；持续学习和实验原则，注入学习到日常工作中；最后要解决的就是集成安全、变更管理和合规性的技术实践。
前文提到的玛格丽特·汉密尔顿，是最早提出软件工程这一概念的人，也可以说是第一代的SRE工程师。汉密尔顿在阿波罗登月计划中负责软件系统的开发。有一次她女儿在模拟仓玩耍时不小心错按了按键。这让她开始思考，既然故障总是会发生，那么我们就有必要提前进行故障演练的场景测试。
在阿波罗8号之后，汉密尔顿开启了最早的故障场景模拟测试，我们可以理解为是混沌工程最早的雏形。
阿波罗13号的登月失败就是因为细节和故障的发生不可控、且非线性，几乎将三名宇航员困在太空，这一事件引发了历史上最雄心勃勃的救援任务。这里我想要强调的是我们生活的世界存在着非线性的风险和突发事件，我们必须具备面对和处理它的方法与技巧。混动工程就是一个很好的方案。
我们再看一下被动式IT运维服务和主动式IT运维服务的区别。从监控手段、异常出现的应对、异常信息的历史记录参考、运维有规范化的制度、运维人员从救火队员向急救员的转变；专业的运维报告、具有连续性和指导意义，工作可量化避免对运维专家的强依赖，这都是从被动运维向主动IT运维服务带来的好处。
混沌工程的回报
关于混沌成熟度模型，Netflix总结了两个维度：复杂度和接受度。前者表示的是混沌工程能有多复杂，而后者则表示的是混沌工程被团队的接受程度。
我们来看Netflix2018年使用混沌工程的投入产出比。
通过计算，得出其投资回报率52.17%，这是一个相当令人兴奋的结果，它的关键是风险提前发现和解决。
AIOps这一概念是在2017年由Gartner从基于大数据及算法扩充为基于人工智能的，2018年举行的GOPS大会上，AIOps还处于刚起步的阶段。
那么从传统运维到AIOps有哪些变化呢？
上图展示了运维的发展，从早期的传统运维，逐渐提高系统执行及决策的能力，到AIOps时代，大概要达到百分百系统执行，95%系统决策，仅有5%需要人工决策。AIOps主要实现的功能包括：性能监控预警和自使用调整，故障诊断和自动恢复，性能趋势分析和自扩展，问题诊断和关键因子分析，异常告警等趋势和辅助决策分析等等。所以我理解的AIOps实际是在自动化运维的基础上，收集各种监控数据，基于数据规则研发算法，达到自适应、自动恢复、自扩展的目的。
AIOps落地面临一系列挑战，包括：数据获取、干扰数据过滤、算法准确性及性能、隐藏风险、研发投入与收益等。
DevOps实现端到端的研发过程系统化，基于DevOps、Iaas平台等做全链路监控，对监控预警做进一步的升级提炼，实现故障自动处理、容量自动优化、弹性扩缩容等；所有的运维监数据，做数据分析、梳理事件自动处理策略，然后通过机器学习赋能运维。
总结这样一个金字塔，是为了清晰地展示AIOps需要有一定的基础才能做，就像盖房子要有地基一样。
最理想的自动化状态是机器完全自动化分析和运行，如华伦·贝尼斯所说：未来的工程里只有一个人，一条狗。人是要喂狗，狗是要看住人，不让他碰机器。
PDCA持续运维是一个价值流动的闭环：持续部署包括配置管理、安全管理、变更管理；持续运行包括SRE、监控、混沌工程，保证系统稳定性、高可用和反脆弱；持续反馈案例和工具包括AIOps、监控看板、度量等；持续改进环节包括主动反馈、复盘和OnCall等。
ITILV4是在需求输入和价值输出之间有一个闭环的改进过程。DevOps的三步工作法，第一步是从左到右快速的流动；第二步开始有从右到左的快速反馈；第三步是把整个持续的过程不断迭代。