本文来自twt企业IT社区，作者/wanglaye。
一、背景
在现今云计算、大数据等新型技术推动下，业界主流的应用架构，正由松耦合、集中式的SOA架构向解耦合、分布式的微服务架构发展，运维人员的工作方式也正在由烟囱式运维、人工运维向自动化、流程化、平台化、智能化运维转变。在“去IOE”、“自主可控”的技术和政策双重背景下，传统金融行业的业务系统所采用的数据库，正在从老牌厂商的传统数据库逐渐过渡至开源数据库或国产新兴的分布式数据库。技术路线的变化同时也带来了工作方式的转变，传统数据库运维人员在这一轮发展浪潮中会遇到哪些挑战，以及应该如何应对这些挑战，这些问题成为各位管理员们首先要思考的问题。笔者结合自身工作经历整理了一些感悟与各位分享。
二、新形势下的挑战
1.技术架构发生改变
和传统集中式数据库相比，分布式数据库具备明显优势，例如带来了数据去中心化、负载分摊；能够按照需求变化进行动态伸缩，支持横向与纵向扩展；分布式架构下，服务可用性保障质量更高，不会因为单点失效而中断，整体容灾能力更强；x86服务器组成集群，性价比更高。当然，分布式架构也存在一定的局限性，例如分布式架构带来的复杂性，比集中式数据库运维难度大；X86服务器硬件本身的可靠性有所降低；应用设计的复杂度有所增加，面临应用的改造。
2.运维辅助工具亟需丰富
作为一家传统金融行业，业务系统都有各自独立的数据库，每个数据库会被分派给指定的数据库管理员运维，这就导致每个人之间存在信息壁垒，无法对全部数据库的运行状况形成全局视图，缺乏统一的“运维大脑”，无法进行统一的数据库分析和辅助决策，出现问题时往往各自为政，大家各自查看自己负责的那些数据库，然后靠现场沟通互通有无，运维时效性难以保障。
在集中式运维时代，我们数据库管理员有时间、有精力直接敲命令进行运维，例如安装、巡检、备份、升级、调参等基本工作，此时是“纯人工时代”；随着数据库数量的增加，再通过手工敲命令方式逐一操作各个数据库已经不再现实，因此，我们开始写脚本，放到服务器上自动执行，由操作系统完成脚本执行，管理员只需读取针对各个数据库的脚本执行结果即可，此时是“脚本时代”；然而，数据库数量日益增长，即使逐一读取脚本执行结果也要消耗相当大的精力，此时管理员们开始借助Ansible这类自动化运维工具批量管理数据库，只需读取一次批量执行结果即可，此时是“初级自动化运维时代”。然而，即使到了“初级自动化运维时代”，信息的终点还是“人”，需要由我们管理员做最终判断，当出现问题时登陆数据库读取各项指标进行人工分析，在当今这个分布式技术蓬勃发展、数据海量井喷的时代里，只靠我们这些“人”来判断处理如此之多的信息流，已经出现力不从心的情况。这种形势下，必须引入其他运维手段，帮助把我们管理员从繁琐高压的工作环境中解放出来。
3.运维压力和成本增加
传统数据库运维人员面对的数据库往往是各自独立的。业务系统仍然是纵向隔离的状态，在烟囱式系统架构中，每个业务系统都有自己独立的数据库，我们在管理这些数据库的过程中，往往需要串行化操作。然而，我们的数据库运维团队规模还比较小，却已经承担了上百套数据库的运维，随着业务系统数量越来越多、数据规模越来越大、交易复杂度不断提升，如果仍按照传统的数据库单点运维方式，势必导致运维时间成本和人力成本大幅攀升。
4.技术经验和人才缺乏
我们在近年也不断进行分布式数据库的转型实践。然而，在团队建设方面，仍然与新技术存在一定的脱节，有的数据库管理员已经成为传统数据库领域的专家，可能已经运维了十年甚至二十年之久。面对新型数据库技术，传统技术经验并不能完全适用，甚至可能是颠覆性的。
三、新形势下的运维新要求
1.制定规范和标准，区分常规运维和应急场景
作为传统金融机构，我们有一套完整的运维规章制度，如运维操作流程、应急处置规范和预案、完善的变更与回退流程等等，保障各项运维工作有条不紊开展，而这些规章制度的有效执行往往需要依靠各岗位的细化落实，数据库运维岗位也不例外。数据库运维团队正在按照这些规范指引，结合岗位各方面的具体工作，制定出属于数据库管理的规范和标准。例如把升级、上线、备份、迁数等工作整理成标准模板文档，形成运维资产随时调用；把数据建模和数据库设计、容量规划、SQL开发、高可用架构设计等工作整理成规范文档，面向所有数据库开发人员提供咨询指导；把常见故障问题及解决方案整理成册，制定面向不同场景的应急处置预案等。通过标准、规范化的管理，使得数据库运维工作有据可依，从而降低运维风险。
2.运维工具向自动化、平台化、智能化转变
大数据背景下运维工作已经不能单纯依靠人力来解决，而要借助工具、平台来完成。目前开源的和商用的运维工具和平台丰富多样，很多传统的手工运维工作都可以交给这些工具或者建设相应平台来做。常规序列化操作如安装、巡检、升级、备份等，我们已经开始借助自动化运维平台；以往通过手工更新的数据库配置信息表交给ITSM或CMDB来管理；数据库的监控告警可以利用近几年大热的Prometheus+grafana技术进行配置，或者引入商用产品建设数据库监控平台或数据库性能分析系统；等等。作为一名数据库管理员一定要经常思考哪些工作可以交给“机器”去做，多多借助运维工具和平台。
同时，随着越来越多的运维工具投入使用，运维管理员似乎又“忙”了起来，因为需要在不同的工具和平台之间进行切换，并在大脑中将各种指标关联起来综合进行判断，以实现故障分析、关系维护等操作难题，这对于运维人员来说也形成了不小的压力。深入思考后发现，所有这些运维工具、平台、系统，归根结底，都在采集“数据”并向外输出“信息”。数据在当代已经成为企业生存的根本，如果能够整合这些“信息”并产生更大的“价值”，那么对于运维人员来说必然又多了一项利器。如何实现运维资产数据有效、精确、精细化管理，利用大数据技术形成决策中心，运维数据消费效率，成为目前不得不思考的问题，而数据中台、运维数据中台、智能运维平台等技术正是为了解决此类问题应运而生。数据库运维员作为智能运维的直接受益者，我们也正在朝这个方向探索。
3.知其然与所以然，实践出真知
分布式数据库经过了多年的发展，在用户体验方面和可视化操作层面其实已经做的很好了，有时候管理页面点击几下就可以把数据库操作完成，但是，作为数据库管理员，仍然需要谨记：系统做得越优化、越简单，里面隐藏的技术、原理反而越多。因为所有个性化的功能都是做了包装的，如果一直停留在表面去使用，那可能在出问题的时候无法解决。所以我们在使用分布式数据库这种架构复杂、经过封装的软件产品时，还是要花更多的时间去了解其原理。
分布式数据库技能的提升一定要放到真实环境中去，这个真实环境选择不影响业务的。自主搭建一套测试环境进行学习实践是转型的开端。如果已经有DB2或者Oracle的实践基础，可以通过对比的方式来进行新数据库技术的学习。MySQL是当今使用最广泛的开源数据库，搭建简单，网络上学习教程非常多，如果能够先把MySQL原理理清楚，再去对比学习其他分布式数据库便会简单许多。目前市面上分布式数据库技术有两种实现方式，一类靠MySQL+中间件实现，一类靠研发新型分布式数据库实现。MySQL+中间件有开源版本，也有诸多数据库厂商基于中间件做了商业版的分布式增强，而数据库仍沿用开源Mysql；自研分布式数据库也有很多。如果企业已经有了向分布式数据库转型的思路，那么数据库运维人员不妨借此机会开始参与到项目前期调研中，一定会收获良多。
4.技术和管理两手抓
大型金融机构内部的分工往往比较细，很多情况下技术人员、项目管理人员是不同的团队，然而对于个人发展来说，还是应该把重点从技术领域扩展到复合型领域。正如前文所说，如果企业已经有了向分布式数据库转型的思路，那么数据库运维人员一定要从项目前期调研就开始参与，因为项目前期所进行的调研、需求、poc测试是了解新技术的第一步，可以最快速地了解市场主流技术和应用现状。到了项目建设期，就更需要技术和管理的复合型人才了，数据库运维人员自身已经有了技术实力，更能方便地把业务需求与实践相结合，利于项目成功落地。项目建成后进行新技术推广时，技术人员的优势又能进一步凸显，因为无论是何种新技术的推广实施，一定要先制定完善的技术升级规范，提前做好测试，获取迁移改造量和改造难度，制定出切实可行的切换计划，在这一点上技术人员可谓具有得天独厚的优势。
5.适当引入技术支持
技术支持分内部和外部。先说外部，大型金融机构的技术团队规模可能比不上互联网技术公司，但更多时候金融机构以甲方的身份出现，有更多的机会与技术公司开展合作。数据库运维人员可以借助这些合作机会，向专业技术公司学习，例如以培训、证书、定制课程的方式。对于内部，如果企业有人才招聘计划，不妨适当引入新型数据库的技术人才，一方面使得团队整体对外服务能力得到提升，另一方面也为团队引入了内部讲师有利于全体成员的进步。
四、总结
以上是笔者结合自身工作经历整理的些许感悟。在传统数据库转型的过程中，运维人员一定要运用新时代运维理念及时调整自身发展方向，提升技术与管理技能，顺应新技术潮流，以精细化、自动化、智能化的管理思维持续成长。
