“DBA100人”专访计划是OceanBase围绕资深DBA进行的人物专访活动，旨在通过人物故事、职业发展经历以及日常工作中遇到的技术难题和实践案例，未来对技术趋势的想法，希望他们的成长之道能够给到各行业DBA一些建议和思考。
DBA如何快速定位故障？如何做好性能优化？如何做好技术选型与技术体系建设？
今天《DBA 100人》第1期带你了解一位拥有十多年职场经验的资深数据库专家&运维人——云南某银行信息科技部运维中心经理，他曾负责主机、中间件、数据库的维护；参与银行核心系统、支付系统的开发；领导运维体系、应急容灾体系、监控体系的建设，希望他的经验能给你带来参考价值。
2001年，这个问题对于正在报考大学志愿的李建明而言，一无所知。和许多因为“喜欢玩电脑”和觉得“编程有趣”的人不同，李建明高中时都不曾接触计算机，只因那时计算机还未在全国校园普及，他只曾听人说起，学计算机能在毕业后找到一份不错的工作。
就这样，李建明成为中国第一批学习信息安全技术的本科生，在校期间还兼职开发了办公软件、论坛、博客等，第一次感受到了编程的乐趣：“我很享受这种从无到有，一步一步把产品做出来的过程”。由于信息安全技术的知识比较宽泛，对于想在计算机领域稳扎稳打的李建明而言必须深入工程，打好编码的底层基础。因此，他在报考研究生时选择了系统分析与集成专业。对于专业的选择，李建明认为一个重要的判断因素是“未来这条路是宽还是窄，通俗地说就是未来择业时，你所选方向的市场需求量是大还是小？还可以结合自己的兴趣考虑，在自己感兴趣的领域或许会更加顺利。”
这次选择，为李建明进入数据库领域，成为一名DBA埋下了伏笔。
成长中的DBA：
快速定位故障，清楚系统运行机制
2008年，研究生毕业的李建明入职正值电子化改革高速发展期的某信用社，参与核心系统和支付系统的维护与开发工作。早在2004年，国务院要求深化农村信用社改革，某信用社响应国家号召，在2005年成立了科技结算中心，建设了信息系统，此举也为客户带来了更方便、快捷的金融服务。但不断上涨的交易量给系统带来了挑战，系统稳定性的保障难度不断加码。
“快”是一大挑战
信用社信息系统的搭建正是由李建明所在的科技结算中心负责，因此，从入职起他就一边负责系统的维护，一边优化系统，工作之余还自学DBA相关的知识。作为系统维护人员，李建明需要在系统出错时，及时定位故障并快速修复。而要做到“快”，对于初入职的“技术小白”而言却很有挑战。
李建明的办法是搞清楚系统运行机制、执行流程。当系统报错时就可以很快地查询到哪些账务是错误的，以及这种错误会在什么情况下出现。
一般来说，运维人员会觉得应用系统永远都是缺文档的。开发人员可能不会将文档写得全面。因此，运维人员在维护系统时就需要多钻研。比如，了解系统架构与业务架构及其技术实现路径，了解系统表结构就能基本掌握业务结构，了解操作系统的命令就能掌握系统的结构。此外，还要进一步学习系统组件，如钻研数据库的表结构。
通过不断地深入了解系统各个层面以及不断向上层探索，逐渐清楚系统的运行机制与执行流程，并在一次又一次的假设问题与验证答案中掌握真理。当“实验”做得足够多时，自然就能掌握快速定位故障并修复故障的能力。除此以外，李建明花了七八个月的时间通读系统主要的源代码。这段时间的钻研与自学，不仅使李建明可以在系统出错时快速找到问题，也让他的技术能力与代码质量都得到了迅速提升。
2010年，李建明也因为两年的优秀表现，正式成为了一名系统管理员兼数据库管理员（DBA），负责系统的稳定与高效运行，并管理和维护数据库、操作系统、应用软件、中间件等。“当时有两个系统管理员，只要出现技术故障，我们都需要介入处理”。而他在这两年对系统的钻研与探索，使他对系统基本了如指掌，对新的工作任务得心应手。
摸索、踩坑、学习
这些问题对于一个成熟的DBA而言都不算难。但对于成长中的DBA而言，需要不断在实践中摸索、踩坑、学习。
例如，数据库连接池出现故障时，经验较少的DBA可能会认为是连接数量不够，于是不断创建更多的连接，当连接池占满时也没能解决问题。因为连接池满只是一种现象，解决根本问题还需从现象看本质。在一些情况下，确实存在业务量过大的原因，但在大多数情况下，业务量不会突然增大，连接池满的原因可能是新业务不高效，导致连接池堵塞或者连接池没有及时释放。这时，一味地加连接只是延缓系统堵塞，并不能从本质解决问题。
再例如，发生长事务问题导致业务中断时，对原理不熟悉的DBA只会傻傻地等待事务回滚。但积累一定经验后，就会知道，其实可以通过不断增加事务日志文件，来保证业务正常运行的过程中将事务回滚完成。
“系统管理员的工作，让我对软件系统有了更深入的了解。从理论到实践，积累了丰富的故障处理及性能优化经验，提升了技术自信心”，李建明如是说。同时，他总结了保障系统稳定性及定位故障、优化性能的经验。
作为DBA，保障系统稳定性是重中之重，李建明认为需要做好三项工作。
第一，预防，即关注网络、存储、计算资源，以及操作系统等基础架构的规划。确保基础框架保持相对的统一。
第二，在系统正常运行时，注重从业务视角观察系统运行是否有异常，是否处于亚健康状态，做好预警、应急等方面的可观测性建设，完善容灾体系和标准化操作管理。
第三，应急，即通过系统架构定位故障，再结合监控系统辅助分析问题。对于故障定位与性能优化，可从三方面开展：
1）确认系统架构和业务架构，站在全局的角度排查问题；2）关注各种指标，如常见的CPU内存、I/O、负载、业务量，业务的成功率、响应时间等；3）在压力场景下，从前到后排除每个模块的性能表现，或者是一些活动的概要信息和详细信息，包括当前系统正在做的一些操作。比如调用了什么函数，执行了什么SQL，以及每一个线程正在执行什么函数，甚至关注网络传输包的响应效率和网络延迟等问题。
此外，为了避免各模块负责人之间推卸责任，需要有一个技术融合的团队，在应急时每个人都能统管全局，快速上手处理问题。
经验丰富的DBA：
数据库选型不求最贵，只求最好
在某信用社的十年，李建明从懵懵懂懂的应届生成为了经验老到的系统管理员与高级工程师，该信用社的电子系统也从支撑上百万账务交易量发展为支撑上千万账务交易量。如果说信用社是李建明职业生涯的基石，是培养他职业技能的摇篮，那么银行就是他十年职业技能与经验的高级试炼场。
自2018年李建明加入云南某银行，负责运维团队的管理与运维体系、应急容灾体系、监控体系的建设。另外，在2021年参与了一项看似离DBA很遥远的工作：数据库选型。
不以业务为基础的选型就是耍流氓，想做好技术选型，首先要对市场中哪些数据库可以作为备选有一定的了解。李建明认为，一款优秀的数据库产品应该像Informix一样稳定、简洁，同时又能像Oracle一样拥有丰富的内置系统表，且具备高性能特性。还应该达到ACID（Atomicity、Consistency、Isolation、Durability，即或称不可分割性）、原子性、一致性、隔离性、持久性）的要求，另外，保证应用的透明性是不可或缺的能力。数据库还应该给予DBA足够的掌控感，让DBA看到他和数据库交互的过程中使用了什么工具、消耗了多少CPU、用了多长时间，以及做过哪些操作。
其次，针对业务特性，选择“最优解”。以李建明当前所在的银行行业更换数据库时的技术选型为例。
大部分银行都会使用较为成熟的Oracle数据库，使用Oracle的好处在于其文档、书籍等资料较全，工具丰富且生态成熟，遇到问题时能复用他人的解决方案或比较快速地找到懂Oracle的开发者。但随着银行数据量的日益庞大，Oracle的数据处理能力显得捉襟见肘，在做异地多活的时候也显现出了短板，Oracle的全局缓存机制会使A客户的数据跑在A中心，B客户的数据跑在B中心，如果交叉跑会导致性能极大地衰减。另外，硬件投入成本、软件使用成本都在不断增加。可替换数据库谈何容易，李建明所在的银行在数据库选型上陷入两难境地。
其实银行真正需要的是一个性能更好且成本更低的数据库，能够灵活地扩容、缩容，在业务量较低时减少节点，在应对交易峰值时增加节点。将对于传统的集中式数据库Oracle，分布式数据库似乎是新的选择方向。
从系统角度而言，对比目前市面上优秀的分布式数据库，李建明认为，数据库的架构应该由其本身决定，而不是由上层应用和DBA总关注它的数据分布机制，就这一点，便能够排除一些数据库选项，OceanBase数据库由于其一体化的架构占据了优势。从扩、缩容角度而言，有数据库级、表级、行级的弹性，数据库级别的扩、缩容不够细致，而行级的扩、缩容对于当前业务交易量而言还用不到，因此，表级扩、缩容的OceanBase便是不错的选择，且OceanBase的三地五中心能够做到不丢失数据。从性能角度和成熟案例这两方面来看，经历过大型活动考验的数据库产品，OceanBase较为出众，已经稳定支撑了十年的“双11”活动，并经过支付宝、网商银行等的验证。而且在性能测试时，达到了8000 TPS（每秒事务处理量）。
由于云南某银行是在传统的核心系统基础上使用分布式数据库。因此在综合考虑后，认为OceanBase是更适合的选择。参与了此次数据库选型的李建明总结了四点经验：
第一，国产数据库当前的产品和技术实力也在逐步提升，可以作为选型考虑的一部分。
第二，面对日益庞大的数据量，分布式数据库是较好的选择。
第三，选择分布式数据库时，考虑数据库的ACID。
第四，考虑对应用的改造程度及兼容度。考虑数据库的性能、体量以及对硬件的兼容度。
给 DBA 的七个成长建议
在采访的最后，谈及一名优秀的DBA应该具备哪些素质或能力时，李建明根据自己十多年的职场经验，分享了他的看法并给出了七个建议：
- 具备扎实的数据库理论功底。比如数据库系统的概论、数据库的核心概念、分布式数据库原理等，理论能为工作中的实践提供宏观指导。
- 熟悉软件开发基础知识和技术架构。DBA或许不需要写好代码。但如果他不熟悉代码，比如不知道代码怎么写出来的、怎么做负载均衡，怎么连接数据库，以及不清楚常见的框架，那么他可能在排查问题时只会说“我觉得数据库没有问题”，更不能站在全局角度保障系统的稳定性。
- 熟悉操作系统的操作及性能调优。数据库最终还是要跑在操作系统上。对于操作系统的操作熟练度可以通过日常工作积累，而对于性能调优，可以通过阅读官方文档中的说明来掌握，比如了解参数的意义和修改参数会带来的影响，并在日常工作中多动手。
- 熟练的数据库运维操作。尤其要经过高并发、大数据量的洗礼。操作的熟练度更多是靠量的积累。至于能不能碰到高并发场景，由所在企业的业务决定。比如支撑小的业务量的Oracle数据库，很多时候按照默认参数就可以运行得很好。DBA不会遇到较大挑战，顶多是扩展存储空间。因此难以积累这方面的经验。
- 越是难懂的理论，越应该努力掌握。对于众多的技术知识，先做到学会其中一个知识点并达到一定深度后再横向发展，如果你熟悉多项技能，且每项技能只停留在表层，那么你在技术领域很难到达高层次。
- 保持对知识的好奇心，坚持终身学习。对于技术人而言，想学习IT理论可以阅读技术书籍；有针对性地学习系统的实操经验可以用极客时间；学习专业领域的技术知识，可以阅读厂商的官方文档；遇到“疑难杂症”时可以浏览CSDN；对于学科类与常识性的内容，就用得到App；研究强理论、学术型的知识可以翻看论文。
- 培养自己的逆向思维和结构化思考能力。打破思维惯性想象多种可能性，尤其是向两个极端方向去思考。不断问问题，推翻自己的假设并验证新的假设。
如果能给年轻时的自己一些建议，李建明表示“吾生有涯而知无涯，要舍得放弃，找到自己最感兴趣或者最擅长的方向，下笨功夫、练就必杀技。还要多学一些跨学科的基本原理，拓宽自我的知识面，提升多维思考能力，并且要勤于思考、有计划的多动手。”与众多数据库从业者共勉。
————————————————————————————————————————————
社区版官网论坛
社区版项目网站提 Issue
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群，或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
