作者介绍
孙志俊，新炬网络资深数据库工程师，超过5年Oracle数据库运维经验，服务于银行、保险、电信、医疗等行业，擅长数据库迁移升级、性能优化。
本文根据〖6月18日DBAplus金融行业运维实践沙龙〗孙志俊老师的现场演讲内容整理而成。点击文末【阅读原文】还能下载PPT哦~
大家好，我是来自新炬网络的孙志俊，今天给大家分享的主题是《金融业数据库规范运维》。近年来，不少金融客户和我们交流时都会问到数据库的运维体系应该怎么去创建，他们知道要建设规范体系，但不知道具体有什么方法。对此，我把这几年在金融驻场运维规范的建设做了一些总结，正好借着这次DBAplus线下沙龙的机会拿出来分享一下，希望能对大家有所帮助。
什么是双态运维？对于传统金融业来说，就是在保证一贯强调的安全生产、稳定运行的基础下，继承互联网高速迭代的更新速度，保证企业的信息建设思路既稳又敏。
去年曾听过一个演讲谈到了双态模式下的运维演进之路，分享者分享了如何去做，提出了运维的发展方向就是以ITIL理念为核心的稳态管理，同时使用DevOps的方式进行敏捷运维，实现敏态。
但是，以金融为代表的传统行业都知道，DevOps对于整个IT中心的改动太大，很难完全DevOps。那么，在这种很难打破传统壁垒的情况下，我们怎么去实现双态运维呢？
回过头来看看DevOps的思维：精益，价值，跨界，敏捷。下面我们就来聊聊如何通过抓住DevOps思维中的精益、价值、敏捷这三个思维要点，在尽量少的变动下，在保证稳态的同时实现这个敏态。
IT的发展很快，我们的数据库也跟着这张图在企业内部飞速膨胀着。20多年前，我们维护的数据库的数量仅几套到10几套，10多年前，维护的数量维持在几十套。10年前的时候，数量开始逐步破百了。2年前，我们的一些金融客户数据库的数量破千了，到现在这些破千的企业，所有种类数据库的数量基本维持在1500套上下。
互联网里有个说法，数量在几十套的时候，人肉运维对于企业来说，是最节省成本的方法，但当数以千计的运维对象存在时，我们需要更高效的方法去运维。这年头其实关于运维提出了很多方法论，高效运维、白盒运维、精益运维等，说到底，需要靠我们的运维人员去执行。对于传统金融来说，运维人员的心理就愈加重要了。这里以一个DBA团队中工作了两年左右的中坚力量小明进行举例。
在一次偶然的机会下，小明见到了自己曾经的大学同学小刚，对方目前正在一家互联网里做着DBA，同样的工作，让两个人对于近况展开了讨论，酒足饭饱，小明回忆着饭桌上的种种话题，不禁对未来感到了迷茫。
小明一直认为自己的薪水不高，每年涨幅也很低，小刚说自己从不担心薪酬，每年涨薪都不会被遗忘，而且数量不低，当然如果公司没倒闭的话。
小明觉得现在的通宵太多，常规情况下每周至少两个，感觉太累。小刚说，通宵不算啥，补贴丰富。
同样的活，干了两年的小明认可领导说的“稳定压倒一切”思想，觉得目前的环境下已经没有新技术的挑战了，感觉着把IT从一个技术活，变成了体力活。而小刚在吹嘘自己的技术博客中，又加了什麽新架构技术的使用。
晚上回家精疲力尽的小明，一直在想，自己之后的路在何方。睁眼仿佛看到了白天领导提的，两年满三年就可以升级了。闭眼却又想起了同学在旁边吹嘘，别看现在我是一线民工，等我这两年积累好了，我就是某创业公司首席技术官。
酬薪，强度，内容，前景，这四个我们大部分在社会上拼搏了四五年内的人最关注的，也是最决定人才去留的四个点，而这批人也往往是团队中的中坚力量，在传统和互联网的博弈下，这两年传统金融的员工流向各种互联网金融非常多。
在运维对象数量剧增的当下，我们的人员替换永远比人员养成的速度要快。做运维久了，有时候挺感叹，如果现在的团队里面，谁谁谁还在打造一只全明星团队多好。对于我们运维的对象数据库来说，我们配置了容灾，但是运维人员的容灾缺青黄不接，人员替换永远快于人才养成。那么，在库那么多、人员流失又那么重的当下，我们怎么去把握精益，价值，敏捷这三个点呢？
有一句俗话说得好，思路决定高度，去年运维圈里提出了个概念——从运维到运营。其实说的就是关注点前移，将运维对象从库提升为人，化被动为主动等。但是对于DBA来说，IT运营的终极目标：简单来说就是不仅活着，更要活得好。
那么做运维的，如何实现运营到运维的转变？反过来逆推一下，我们作为企业的员工，要想活得好，企业要做得好，在这个信息化时代，就务必要跟上时代的脚步，企业IT就必须要加速变化。而对于金融IT来说，无论怎么快，安全生产、稳定运行是第一要素。
这是前面说的双态运维的理念，但它靠什么来落地？清晰明确的流程，简洁明了的步骤，不怕断档的团队，三者融合，确保了在将价值导向的同时确保工作的精益，并且实现我们的敏捷运维，而这一切的基础，在于规范。这张图，从下往上，其实就是借着规范，通过一个个里程碑，而从运维走向运营的道路。
做规范，相信也是让很多朋友头疼的一件事。规范这玩意，由无数大大小小的文档组成，牵扯面之广，往往让我们一些刚起步的企业不知道从哪个方向入手。而且传统企业IT系统越建越多，多而杂，各种各样的技术规范都可能有，非常乱，这样造成IT运维支持比较困难。
差不多6、7年前，在运维规范不成体系时，我们需要去装一个库，因为找不到安装文档，所以去网上下了份。对于初创企业来说，有问题问百度，解决了就行。但对于大型金融业来说，这里面有着很大的隐患。
我这边结合这几年的运维经验，梳理了一下我们规范建设的思路。规范有两个重要的特性：工作手册的总纲，团队传承媒介。将这两个特性深挖展开就是我认为规范建设的思路：工作流和信息流。
首先说说工作流。建设的时候，我们从设置流程大类、流程子类、技术分类、SOP手册这四个纬度逐步细化进行建设。流程大类包含五个纬度：变更操作、告警处理、值班巡检、性能优化、应急预案。
其中前三项各个企业都是按照流程的不同，内容肯定也不一样。第四项性能优化就比较偏技术层了，属于一种可以拿出来交流的通用性流程。第五项应急预案，在最开始的时候是几乎没有的，但无数血泪的教训告诉我们设立应急预案的重要性，于是也加了上去。
各自的流程子类如图：
变更操作：安装部署、迁移升级、用户权限维护、数据归档、数据对象维护等
告警处理：性能告警（异常等待，高效耗语句，锁阻塞）、实例告警、同步告警、空间告警、配置告警（基于安装规范的，参数没有按照规范配置）等
值班巡检：值班流程、巡检流程、投产流程
性能优化：参数调整、语句改写、非改写优化、
应急预案：硬件损坏、软件损坏、关联系统损坏（nbu）
关联系统：类似数据库的备份，监控系统坏了该怎么办
接着就是根据各项子类，在根据相关的技术进行细分，比如说像迁移升级：Oracle XTTS升级、Oracle DG切换迁移或者其它数据库Informix hdr切换迁移、Informix RSS切换迁移等，根据使用的技术不同，以及数据库类型不同再进行的细分。最后再落地到sop标准流程执行手册。SOP里肯定包含了基本上所有的执行步骤、脚本，写SOP的这个过程，其实也是一步步将规范脚本化的过程。
这边列举了三个最主要的问题：
操作复杂：我们的某些变更操作，涉及步骤动辄十几二十多步，相当繁琐复杂，而且又需要多个数据库间进行交互，更加加剧了我们的复杂度；
不通用：花大精力写出来的变更方案，每次同类型的变更，要做很多修改，不通用；
校对困难：我们是直接在金融生产库上做操作的，重大变更的话，有些企业还会把每个具体的步骤一页一页打印出来，严谨性不用去说。所以做运维时，对于这类改动的方案校对审核得非常仔细，当然这也和我们公司的一条红线有关，所有上生产的方案，一定要审核通过才执行。所以这种情况下，经常有大量的方案堆积在评审人这边。
这个时间是非常痛苦的，穷则思变。我们就想了一个办法，一个字——拆，针对不同场景的复杂步骤，将它分割成一个个原子步骤。当然不是所有类别都可以这么做的，但是我们发现其实大概90%的操作都是能拆的。
举一个Oracle DG切换的案例。常规的DG切换，肯定不是这样切的，有switchover的步骤，但是这个操作我们是不做的，它里面存在着未知，我们不敢做。在常规DG切换中，switchover这个操作有无法把控的风险，主库切换为备库无法切换回去，怎么办？我们把切换的步骤变为，从主库这边直接将在线redo和控制文件通通拷贝到备库进行启动的方式。
这样一个操作，我们切分成了13个原子型操作。这其中，对于物理文件的备份，都是可以复用的；减少标准操作的复杂性，让每个原子标准都可以被复用，是我们做原子化标准的目的；将同一个变更中不相关的操作进行分离是我们的分割标准。
刚开始，我们是针对变更操作入手开始进行原子化标准建设，后面逐渐发现，分割出来的原子化标准很多。我们拥有了一个原子库，这个和我们的函数库其实类似。原子库中的规范呢，在根据不同的技术和平台进行分类。再然后我们发现这些原子化标准，慢慢的，可以辐射到其它流程大类里面的操作。
就像PDCA戴明环一样，不断地推动工作流的建设，整个标准原子化操作成为了整个工作流建设的突破点。差不多一年多的时间，我们60%的SOP可以在原子标准的基础上结合而成。
工作流基本上就讲到这里了，下面来谈谈信息流规范的建设。
什么是信息流？字面意思，我要把我知道的告诉你，这个过程就是信息流。信息流建设可以分为三块，信息的归档记录、信息的沟通，信息的升级。
企业的信息库一般由事件库、告警库、变更库组成，企业基本都有自己的内部管理平台，这些平台的覆盖面很广泛，基本上所有的重要事件都会通过平台中的事件、变更、告警保留下来，以供追溯。
但对于可用性事件，我们拿故障来说，它可能是由1个告警而被发现，几个事件被其他部门察觉，再借由几个变更进行解决的。
对于传统的ITSM来说，信息存放太碎。很明显，这些信息的传递沟通，并不是需要我们这些团队中的老员工，靠记忆来硬刚，也不是在各种碎片信息中去拼接，而是需要靠着曾经完整的记录来追溯的。
所以这边我给出了两条鱼，目前为止我们认为需要额外记录的信息库：包括可用性事件库和Bug库。两根鱼骨头，表示了需要记录的点。我们做DBA的，其实无所谓甲方还是乙方，都是做运维服务的，企业本身其实就是一个很好的案例来源，我们是需要从历史教训中学习前进的，总不能一个问题一年前发生过，换了一波人，又踩一次坑。
在你的企业内部，沟通方式有哪些？微信？钉钉？企业内部通信工具？邮件？手机？
这么多的联系方式，却还是带来一个问题，部门同事间的历史信息不对等。我们发现一个部门里某个同事他不知道某件事，很大的概率在于，他的确是不知道这件事，而不是他忘了这件事。于是我们针对任何团队里任一位同事都分配了为期四周的一个工作计划，每周一个任务。
第一周，熟悉环境，他需要知道哪些库是重要的，哪些平台是给他工作的，谁是他的领导，哪些是禁止项等。
第二周，安装部署，我们企业有很多的库，很多种类的技术，但是变更也好，告警也好，他们都离不开一点，我们一开始安装部署的标准项，第二周的任务是安装部署，去熟悉这些标准项。
第三周，基础技术，我们每个人进来可能是高技能的，也可能是低技能的，但是不重要，第三周就是让你掌握有哪些基础技术是你在80%的工作里面需要用到的。
我这边截取了，目前我们团队在MySQL方面做的一个新人入职前四周的一个学习计划，通过我们的学习概要，内容细分，学习文档，来让这个新人员入职流程切实可行，而不仅仅只是一个高高在上的规范。
第四周，流程实战，跟随我们的老员工，把重要的流程走一遍。通常我们大型企业对于新员工都是有一个考核制度才能上生产进行操作，那第四周终极目标考核。
大家可以看到，这套规范其实对于一个老DBA来说，仅仅是加速对工作的上手速度，但是对于一个新人来说，短短两个月，他就可以让一个初出茅庐的新人，成为一个知其然不知其所以然的伪中级DBA。
做运维时间久了，都说运维是个把脑袋别在他人裤腰带上的活。我们遇到的问题往往不取决于自己，那么在这种某一天肯定会发生的意外情况下，该怎么去做好信息的升级？
我们这边制定了三条红线，其中一条就是关于问题的升级，根据我们服务的客户不同的情况，这条红线的落地也是不同的。我们在做金融运维时，把运维团队分成了三个层次，值班岗、专家岗、远端专家。通过分工，设立一二三线岗位，先把人力资源有效利用，避免高级人才在做一些繁重的体力活。那在不同的场景下，我们各岗位人员的职责是不同的。
这里我把运维问题分为了四个方面：常规事件处理（像清理以下表空间，删下归档之类的）、异常问题处理（包含一些技术难度较高的工作，比如SQL性能低下，存储过程某类语句问题缓慢等）、应急预案实施（当某些不可抗拒的事情发生后，我们是没有回退方案的，这个时候就是应急预案的启动了）、重大故障救援（这个是指某些第一次发生的，没有应急预案的事件）。
常规事件处理：值班岗处理并记录，当天结束时统计汇报；
异常问题处理：值班岗依照自己能力，十分钟无法解决时，上报专家岗，由专家岗处理解决并记录汇总给值班岗，当无法解决时上报给负责人，并协调远端专家。当天值班结束时进行汇报；
应急预案实施：值班岗上报给专家岗和负责人，专家岗成员从技术上判断是否需要采用应急预案，当需要时，第一时间通报数据库组负责人，团队项目经理，并由负责人决定是否采用应急预案，该预案通常由一位以上的专家岗成员复核执行。同时远端专家在技术介入，进行后备保障；
重大故障救援： 同样由值班岗进行上报，但是我们的值班岗在这个时间中，还起到了协调人的作用，重要的是对外接口，让组内的专家和远端专家团能够安心的以处理问题为主。
而我们的本地专家和远端专家呢，则以救援方案的制定为中心开展工作这是我们整个信息的升级机制，使各个岗位在不同情况下各司其职，而不是一拥而上去解决。
前面说了很多，我们的规范怎么去做，从工作流和信息流方面。那么写过文档的同学肯定知道，我们一般文档都会从v1-v2-v3-v4慢慢迭代跟进。
运维规范同样需要迭代去更新，简单来说就是一点——利用好当前已有的东西，在体系大纲明确的基础上去查缺补漏，这里梳理了六个方面：
我们的工作流程是否发生了变化；
各流程分类是否需要去丰富；
部门同事间的信息沟通机制是否发生了变化；
可用性事件的原因是否因为规范的不合理；
是否有新技术需要引入，从而修改更新我们的规范；
当前规范是否已经覆盖了所有版本和平台；
但是有两个注意点，这两个注意点是曾经很长一段时间里，我们的痛：
做好版本控制
不要只增不减
不然的话，文档的逻辑乱了的同时，我们的规范也就渐渐臃肿到无法看了。
另外，永远要记住我们的SOP精髓：
工作手册
传承媒介
精简而复用
我们的服务团队在为金融业服务时，这些运维规范建设，也经历了不同的阶段周期：
第一阶段是地基阶段，叫规范标准化：坦白来说，确定每个SOP规范的标准流程、标准操作、标准沟通。
第二个阶段，规范脚本化：我们的目标是标准操作脚本化。但是在这个阶段，我们遇到了两个问题：简单操作，因为环境往往不一致，导致了脚本化后不能复用；复杂操作，又会导致我们的人力时间成本投入过高。所以对于这个阶段，我们只有一个建议：不建议整体脚本化。千万不要把一整件事，放在一个脚本里面去做。
也正是因为预计到了这些问题，我们经历了第三个阶段：规范原子化。通过拆拆拆的方式，将操作分解，操作脚本原子化，同时建立标准原子库，便于后期操作的调用。
到这步为止，其实我们都在做规范，虽然经历了很多阶段，用了很多方法，但是说白了，依然停留在文档阶段，稳是做到了，但是敏还差得很远。很自然的，开始追求这些工作的平台化落地。
这个是我们自己开发的自动化运维平台对于运维规范的一些功能，当我们把大部分规范脚本原子化后，我们发现自动化成了一件很简单的事，所需要去做的就是可以支持各类脚本的集中化管理、工作流程的编排、原子脚本的调用、以及去观察每个脚本的执行结果。
比起之前很痛苦的分人，针对每个长流程来写脚本，我们工作长流程的自动化实现就这么自然简单地实现了。当然我们的这个自动化运维平台里还有很多其它功能，包括自动化巡检、自动化安装部署等等，有兴趣的欢迎在本文微信评论区留言咨询。
随着规范的平台化落地后， DBA在整个规范建设阶段里面其实也有着不同的感知，这里的ABCD分别对应了规范的四个阶段：
阶段B：规范脚本制作（体现脚本不能复用）
运维人员a：这个脚本上次写过啦
运维人员b：这次场景变化不少，需要改动地方挺多
在确保工作质量的同时，提升了工作的效率，还加速了人员的养成。
前几年大家都在说自动化，那么自动化运维的极致是什么？这里截取了一段关于智能化运维的解释：一个因应突发事件而弹性自伸缩、自愈、自适应的软件系统，“自己运维自己”的“无人值守”运维。
这三个自是智能化运维的切入点，而我们目前也是从其中一点入手：从监控告警入手，先做自愈。左边是我们传统的告警处理、右边是我们目前正要做到的。通过告警触发我们的脚本调用，以达到自愈。
传统的告警处理，主要靠7*24小时人工值守进行告警处理，一旦运维人员错过了告警，本来有很简单有效的运维操作没有被执行，就可能导致系统故障。通过固化常见的故障处理方式，在收到告警时自动调用相关脚本处理告警，可以快速的消除系统隐患，降低业务风险。
当然这一点目前已经可以做到了，但是我们还没有去做最后一步，仅仅是在告警的同时，生成可以去解决的脚本，还是需要人为的点击去执行。原因在于追求稳妥，不过不管怎么说，这已经比当年一个个告警手动去做稳妥很多了。
从运维走向运营是需要一个过程的，我们仍在这条路上，目前的成绩：
将工作流，信息流实现了标准化；
将标准原子化推动了问题前进；
通过自动化实现了稳态和敏态；
通过智能化自愈将被动式运维转化为主动式运营。
希望通过今天的分享，能让一些boss级的企业呢，在回顾过去自动化创建的艰苦历程时，会心一笑，也希望咱一些初创型的金融企业呢，知道原来规范可以这么建设与落地。
相关专题：
