本页网址二维码：
本页网址二维码：
首先要明确一个观点：无论是管理什么规模的数据库，作为DBA，自制工具是必要的能力，区别只在于工具的复杂性。
运维人员必须具备写自动化脚本的技能。这是个人能力高低的分水岭。我之前的运维文章内容重点之一就是通过脚本实现日常重复的运维工作。
进一步地，对于DBA，编写脚本或者自制管理工具，不仅是个人能力分水岭，而且是刚需。这是岗位特性所决定的。
那么DBA自制工具该如何定位和如何发展？
理解本文需要对DBA岗位有一定经验，或者虽然不是DBA岗位但实际从事了该项工作。
| 一、自制工具的目的 |
自制工具的关键目的在于以下三点：
（1）避免人为出错
（2）解决批量重复劳动需要
（3）定时自动化执行，释放人力
手写SQL导致批量删数据甚至删表删库已经是业界老梗了。但凡事看本质，这梗其实就是在说作为DBA的动手意愿和动手能力，以及开发、测试和生产三分离的环境分离控制是否到位。
环境分离控制非常重要，但不是这篇文章的内容，以后会再讨论。对于DBA来说，要严格要求自己任何操作先对测试环境实施，成功后再对生产环境实施，也就是至少要两次操作。
自制工具首先就能避免分别对测试环境和生产环境重复操作时的人工疏忽，固化在工具内的数据库操作不会因为执行次数而变化。然后，重复操作的执行工作量也因自制工具的存在而减少。再然后，通常对生产环境的操作需要在系统闲时进行，通过自制工具固化后，就可以在系统闲时利用各种定时自动执行方法实现自动实施，释放DBA。
如果是24*7生产不停，需要滚动变更的环境，更需要通过自制工具，实现自动化滚动执行能力，使变更过程全程自动化和可追溯。所以我说这是刚需。
| 二、自制工具的方法 |
自制工具一般包括以下三种实现方式：
（1）操作系统脚本
（2）存储过程
（3）专门开发
操作系统脚本是最常见的“自制工具”方式，结合操作系统的定时自动执行功能，是DBA解决绝大部分工作需要的基本手段。脚本可以是固定不变的SQL，也可以通过引入参数而实现有一定的动态变化能力，尤其是如果测试环境和生产环境存在不同，典型如数据库名、表名不同等情况。顺带说这是环境三分离的其中一种实践，具体实践效果上，我认为是好坏参半。
存储过程是相对少人用的方法，因为存储过程不好写，难DEBUG。但存储过程用于DBA运维却是非常关键的技能。首先是因为存储过程能保密执行的内容，可以仅允许调用执行而不允许查看，充分实现操作系统管理员和数据库管理员的权限分立。只不过如果是一人兼两职，这个权限分立就当我没说过了。
其次是存储过程的可靠性和逻辑性。操作系统脚本和存储过程都能实现逻辑，但两者面向的是不同的范畴。如果对数据库的管理操作需要按数据库内元数据甚至数据本身按特定逻辑进行处理，用操作系统脚本语言就会增加了脚本复杂度，某些逻辑还可能很难实现，不仅降低了操作逻辑的严谨性，还降低了管理操作整体的可靠性。
所以我的建议是操作主要过程用存储过程封装，操作系统脚本只做调用。
如果是本身自带定时任务功能的数据库系统，那就全部用存储过程。如果不细分职责，也可以直接纳入数据库系统的维护任务脚本之内，实际等同于存储过程。
专门开发的工具应基于成熟的、与系统环境相匹配的开发环境开发实施。如果不是瞄准着产品化方向或者需要实现严格的职责分离、审计控制等要求，这种实现方式会显得费时费力。
| 三、自制工具的发展 |
发展过程大致都是以下的三步：
（1）单一专用
（2）工作环境内的通用化
（3）产品化
基本上没有DBA会从工作的一开始就自制工具。都是从信息系统的不断发展，数据库架构和数据关系的不断调整，持续积累各种数据库运维工作实践，实践多了，开始发现重复性，进而逐渐形成可重复的脚本，这是第一步。然后随着能力提升，逐渐对重复劳动生厌了，开始思考脚本的通用化，前瞻适配数据关系的未来调整，形成相对通用的工具。最后在可行的条件下形成产品化的工具软件。
一般来说，大多数自制工具都走不到第三步，而走到第三步也就脱离了DBA本身的工作范围，如果不配以良好的用户友好设计（比如模版、预设之类），反而会变得不好用。但这些用户友好设计则是实打实的工作量，超越了DBA本身的职责，是否走到这一步是要有很多支持因素，这里不细表。最起码的是，由于现在IT行业工作岗位细分程度越来越高，熟悉软件开发且能独立开发出工具软件的DBA已经很少。
在于内部环境通用化方面，重点其实不是把工具通用化，而是在通用化的过程中同步收敛环境的复杂性，解决因为系统升级迭代而产生的历史欠账和遗留问题。在这一点上，需要DBA协同系统架构师、开发人员等方面共同实践。
一些典型的因为应急修改造成的遗留问题，比如表结构偏离内部规范，表关系不够正规化等等，都可以在这个过程中逐步修正。
只是，如果DBA、SA以及DevSecOps都是自己一个......那还是自己琢磨一下论IT人员的自我约束算了。
| 结论 |
技术文章的内容主要分为讲“术”还是讲“道”。具体如何自制运维工具或编写可重复使用的脚本，都是属于“术”的范围。如何理解、定位和发展自制工具，则属于“道”。本文从“道”出发介绍了自己对DBA自制工具的一些思考，具体实例打算另起一文。
