【IT168 技术】本文根据周亮在2018年5月12日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。
讲师简介：
周亮，美创科技运维服务中心总监，中国南方Oracle用户组联合发起人，ITPUB论坛管理版版主，Oracle ACE/OCM，《Oracle DBA实战攻略》作者。
文章摘要：
Oracle 18c推出自治数据库概念之后，将数据库智能化运维推向了一个新的热度。本次演讲结合多年运维实践经验，接地气地谈谈数据库智能化运维常见的误区是什么?包含哪些基本要素?如何落地?
正文演讲：
首先，我们先来看一下智能化运维的发展趋势。第一个阶段是无序化运维，虽然很多大的甲方公司基本不存在这个问题，但是乙方公司或者是小型甲方公司都有这个问题，运维全靠人，没有规章制度，也没有很好的梯队建设。第二个阶段是标准化运维，这个阶段除了人员的增加，更重要的是要有工具和文档的积累。第三个阶段是自动化运维，即让机器干机械的事。什么是机械的事?就是重复劳动，例如安装、部署，甚至是某些监控报警和弹性扩容。这里的弹性扩容指的是当空间和资源不够了，我们去补充添加，而这些操作都是一些可控的机械化动作。第四个阶段是智能化运维，虽然现在关于智能化运维的讨论很火，但是客观来说，目前绝大多数公司还处于理论阶段。
以我们公司为例，目前维护的Oracle数据库大概是5000套左右，而我们的Oracle DBA团队在五年前是五六十人左右。5年期间，公司业绩以每年翻70%左右的速度成长，而公司业绩的成长、客户量的增加势必会带来一个问题，那就是需要扩大团队规模。但是，我们在业绩翻番的时候，团队成员数量也没有增加。为什么呢?因为我们的运维工作一路从标准化过渡到自动化再到智能化，人均产值一直在提升。
无序化运维高度依赖工程师价值，所以无论是甲方还是乙方都会碰到一个问题，那就是该岗位的人离职了怎么办呢?我经常会碰到这种情况，十几年前的一个系统没人敢去动它，因为之前维护的人离职了，该系统就一直跑在那里，Oracle数据库甚至还可能是跑在8i阶段。
师傅领进门，修行在个人。几乎没有任何一个师傅会是他在那儿敲命令，让你在旁边看着，再加上没有文档、流程等制度化的东西可以给到新人，让新人只靠个人去成长，速度是很慢的。
人不够了?招!当公司业绩在走上坡路的时候，几乎每个部门都会面临缺人的情况，如果每个部门都去找老板申请，那么老板可能会很厌烦。剩余价值怎么剥削呢?：)
标准化运维和自动化运维靠的是流程、制度、文档和工具去落实。例如实时监控、日志分析、快速部署、弹性扩容、故障处理等都有很多的重复劳动，只靠人来运维的话，可能分身乏术，但如果依靠机器去部署、处理、巡检，那么就能解放很多劳动力。
智能化运维，简单来说就是让机器干人的事。以我们公司为背景介绍，很多甲方客户的数据库都是可以上云的，这意味着其网络是可以打通的，所以，为了最大的复用DBA价值，我们推出了远程DBA。
在网络打通之后，客户的一些高级信息都会实时推送到我们二线DBA的邮件、微信以及手机客户端。我们成立了一支二线DBA团队，专门处理这些事情。因为这些运维日志来自于五花八门的客户，包括银行、公安、医疗、社保等等，所以收集上来之后我们会做一些机器学习，再结合每套系统的业务节奏，我们就可以提前预知哪些数据库或者哪个业务模块可能发生问题或者说即将发生问题。
大屏监控是我和我团队最近一年来一直在琢磨的东西。现在80%的监控都是以结果为导向，比如当空间不足了，监控报警。当CPU资源率达到90%了，再给一个报警。但其实监控不仅仅是给运维人员用的，更是给小白用户用的，因为他们不精通数据库，所以才需要去看监控。
但是这里就又出现了一个问题，既然用户不太懂数据库，那么只告诉他一个结果是没有用的。所以我们想设计一张简单易懂的大屏，就算做不到大家都能看懂，至少也要有80%的人能看懂。因此，我们的大屏不是以结果为导向，而是以输入输出流程及时间模型的角度联动展示各项指标。
监控大屏以过程为导向，例如CPU资源使用率达到100%时，那么大屏显示出问题的环节，如在SQL执行的生命周期中，明确指出SQL哪个环节出现了问题，甚至可以联动的显示出受影响的各个环节。当然并不是所有的问题都会在大屏里显示出来，大概会涵盖80%以上的常见数据库故障。
五大健康指数是最醒目的一个环节。第一个是可用性，这张大屏主要是针对Oracle，不过SQL Sever、MySQL除了一些技术实现细节，概念方面是通用的，如服务、监听、实例、表空间等。
第二个是性能，性能指标没有一千也有八百，如何选择一个指标去反映数据的性能好坏呢?我们思考了很久!一般情况下，我们读取数据都有个过程，如从磁盘上读上来，再读到内存里面，从内存里面读数据块的过程就叫逻辑读。数据库本质上就是一个存数据和读数据的过程，存数据之前要先把数据块读上来，这对Oracle来讲就是一个逻辑读。衡量逻辑读也有两个细化指标，一是逻辑读的时间，正常情况下单个逻辑读的时间是几纳秒，如果出现了几十倍的上升，那么一定是出现问题了。二是逻辑读次数，如果逻辑读次数急剧上升，那么也肯定是出现问题了，应用发生了变化或者是SQL的执行计划发生了剧烈变化。
第三个是错误，相信在所有的告警里，大家最关心的就是错误，我们会推送数据库运行过程中的错误到大屏。
第四个是变化，数据库发生问题了肯定是来自于变化。所以我们在监控里将变化作为一个重要因素放入其中。数据库中的对象有没有变多，权限有没有变更，空间使用有没有变高等等，一旦这个库发生变化，我们就会把它投到大屏里。
最后是可靠性，也就是备份，因为一般的生产库肯定是有备份或者灾备的，所以我们也会选择最重要的几个指标放到大屏上。
SQL生命周期监控，SQL生命周期可分为登陆、解析、执行、提交四个阶段，所以我们把整个库的性能也剖析成四个环节，每个环节分别进行机器学习。因为每套系统的业务结构都不一样，而个人经验又很有限，盲目判断很容易出问题，所以需要机器学习去动态学习每个业务系统的节奏。
以执行环节为例，需要用执行次数和每次执行的时间去衡量这个环节是不是有问题。如果通过多个业务周期的学习，执行次数和时间是相对固定的，那我就认为这是个正常值。如果突然在某个业务中某个指标超出这个正常值的范围，那我就认为这是出问题了或者是即将出问题。
通过变化和比较，能够直观凸显性能瓶颈。
资源关联分析，主要是查看我的数据库资源是不是快要不足了?做数据库DBA的都知道数据库资源包括processes、session、DB files和jobs，而我们经常碰到的数据库性能三大资源锁是Mutex、Latch和Lock，主机四大资源是CPU、内存、存储和网络。
这是大屏的细化图，除了上文提到的机器学习部分，整个模型过程中都需要去强化训练。例如在执行阶段的执行数和执行时间，也有很多其它环节需要去学习。
机器学习有什么用处?风险异常预测是老生常谈了，这里就不再展开讲了，我们谈谈另一个用户为决策提供依据。在不改变业务的情况下，DBA可以知道下个时刻，库空间有多大?按照这个趋势发展什么时候资源会不足?什么时候需要准备扩容?
因为我们的客户量比较大，所以涉及到库的类型也比较多。不过，数据库版本虽多，但是万变不离其宗，它们肯定是运行在小机上或者X86上，采用的硬件都差不多。在我们的数据积累过程中，发现很多厂商的硬盘故障率并没有他们标榜的那么好。从上图中，我们可以看到，机器刚刚运过来时，可能因为路上有颠簸或者其他原因，故障率是最高的，而一个月之后故障率就会下降，当到了一定生命寿命周期之后，就又上升了。
得到了这种趋势，我们就可以指导用户存储上线的时间。如在第一个月最好是进行跑批等测试，当测试没问题了之后，再上线。这样的话上线之后会稳定很多，这就是一个经验+数据指导用户决策的很好例子。
日常智能巡检，很多用户都会去做，但我们不同的地方是加入了机器学习的成分。大家都知道脚本是死的，一套脚本跑遍所有库，给出来的建议肯定是有问题的。而且数据库数量很多的情况下，人工写巡检报告也是很大的工作量。
所以，我们的巡检结合了某些指标进行动态的采样、动态的分析、动态的调整，甚至还可以自动书写巡检报告出来。巡检报告并不是巡检结果的一个简单展示，还需要做一些智能化的建议。自动巡检报告完成之后，DBA再进行人工审核，并给出自己的建议，形成最终完整的巡检报告。
上图是我们巡检平台的截图。
智能性能解析也是提供给小白DBA使用的，这个功能的灵感来源于医院体检。医学专业术语很多，也很复杂，但是体检报告大家都看得懂。为什么呢?因为体检报告会在各项数值之后都会标明正常、过高或过低。
同样，我们也可以把它应用在我们的AWR报告中。一般来说，AWR报告都会有几十页，如果SQL很多的话可能会达到上百页。如果是一个新手DBA去看这个报告，可能无从下手。但如果我们开发这样一个功能，它把AWR报告上传之后，我们把每个环节都帮他解析掉，并反馈给他一份新的报告。这份新报告中包含了所有的问题，甚至是哪些SQL是什么问题。而且如果平台能连到你的数据库，我还可以给出建议这条SQL如何改。
这对小白用户来说简直是大喜讯，不仅把长篇大论的几十页AWR报告浓缩成几页的新报告，而且还可以简单明了的看到问题出在哪里，甚至可以根据建议修正错误。
故障处理，我们已经能自动解决空间之内的容量故障。但是 Oracle报一个600错误或是其它稀奇古怪的错误，想要依靠机器或者软件把它解决掉或者分析出原因，难度实在很大。而且Oracle是一个商业化软件，版本更迭是难以避免的，而这对我们来说就意味着要始终追着Oracle的屁股跑，很明显，我们没有那么大的精力投入其中。
在摸索阶段我碰到了几个问题，第一个是虽然我可以通过一定的趋势去预测故障，但是可能有些故障并没有纳入到故障列表中，那机器还是解决不了;第二个是不同因素之间的干扰，不止是Oracle，其它数据库也一样都是并发性很强的数据库，一个因素可能会影响到其它因素，导致一个故障像滚雪球一样引发大面积的瘫痪。不同因素的干扰是一件非常痛苦的事情，不同因素有不同的因子，反映在机器学习里就有不同的变量，而且这些变量的权重还不一样。
当前我们能做到的是什么呢?首先是解决容量不足类故障。当空间、主机等资源不足了，可以自动去扩容。其次是保留故障现场。还有就是快速止损，很多客户都有考核标准，例如在30分钟内处理掉故障，那么就不需要上报领导或者上级机构。所以，即使是一个在DBA看来很严重的问题，只要你能及时恢复，那么对客户来说就是小问题。
如何快速止损呢?通常的手段是重启数据库或者杀会话。但是这又带来一个问题，数据库重启了，会话杀掉了，事后怎么分析?现场破坏了之后，人为就很难进一步分析了。所以在引入快速止损时要先保留故障现场，也就是说在重启数据库之前，要把那个时刻的主机资源、空间资源、内存、进程等等资料都保存下来。而且保留故障现场必须要工具化，否则靠人工敲命令，时间很快就流逝了。
总之，快速止损和保留故障现场是必须用起来的一套组合拳。
快速止损是当前数据库智能化运维领域中最易实现的，那么现在有哪些快速止损的手段呢?不同的故障对应不同的止损手段。假设是监听出问题了，那么就要重启监听，但这个问题的关键是如何判断监听出问题了以及如何在监听之前把这些状态保留下来?这个话题有点广，下次再说：)
其余的常见快速止损手段还包括实例重启、Kill进程、Kill锁、空间扩容、主机资源扩容、固化执行计划、阀值告警以及现场保存。其中，经过长期的实践发现，数据库自动化程度越高，执行计划突变的概率越大，而执行计划一旦发生变异的话，机器学习就要立即响应，通过调用调用响应时间正常值的执行计划，把它固化掉，让系统性能恢复正常。
