以前我在《我维护过最坑的核心交易数据库，没有之一》一文中，提到过让我印象深刻的一套核心交易数据库。我相信很多DBA都会和我有一样的感慨，大多数莫名其妙的故障，都是来自于应用系统，尤其一些老旧的系统，缝缝补补弹孔遍地。在每次核心交易系统升级之前，我都会再三叮嘱相关同事，一定要把数据库相关的升级内容也抄送我一份，以便于让我有个心理预期，不合理的地方也能够提前发现。即便如此，还是会有一些兼顾不到的地方，甚至是升级过程中临时改动的。要命的往往都就在这个区域里。
那会负责应用系统的同事是个北京土著，我跟他一样都喜欢看《我爱我家》。有一次我就跟他说，千万别有什么遗漏，你也不想很多年后我们的后代来一场“你爷爷一失误，我爷爷就要饭”的故事吧。
两年后换了工作，到了另一家公司，权限比之前大了，不仅仅是系统层面上的，还有制度上的。于是我和同事开始去从制度上梳理，怎么样避免出现“你爷爷一失误，我爷爷就要饭”的事情发生。
第一步，说服领导
公司制度层面上的支持，往往总是离不开领导的支持，这一点在中国的企业更加重要。但是和部门一把手去沟通，总是要拿出一些真凭实据，以自己的后续方案，而不是由领导给你拿主意。
这期间我做了三件事：
- 和每个业务系统级别为重要的负责人都做了一对一沟通，结合过往组里的事故报告，了解了他们过去几年数据方面发生过的问题，以及当时的处理办法
- 对问题发生的原因进行归类，哪些是可以在不提高成本的情况下通过技术手段尽量避免，哪些需要从制度上进行完善，所有重要系统跟数据库相关的变更，必须有DBA在流程中确认才有效
- 将自己的相关想法落于文字，并明确说明需要从流程上和技术上给予哪些支持
三件事情做完，终于约到了部门一把手的时间，于是带着之前自己做的作业，去跟他沟通。整个过程不是很顺利，主要的阻力在于会让应用系统的上线以及变更不灵活，这事在应用系统负责人那边会比较大的阻力。而且作为刚加入公司的我，还不具备足够的说服力。退而求次，我选择了一个折中方案，在重要系统的上线或变更时，DBA必须知晓数据库有关的内容，如果发现有重大隐患或者与历史事故有关联的内容，会邮件通知负责人并抄送部门一把手，由部门一把手来决策。
这件事情做完，算是得到了领导的支持，接下来就是具体实行的过程中不断完善。
第二步，力行实践
这一步其实有点难，因为应用系统负责人即便得到了部门一把手的通知，也不见得会主动把东西全部发给你。不在一个组，信息是被隔离的，如果没有什么问题出现，可能DBA都不知道系统做过什么升级。
这件事情让让我推进整个事情陷入了困境。直到两三个月以后，其中一个重要系统的负责人离职，接替他的是个新人。这个新同事刚来，我在他面前反而成了老员工。这让我找到了突破点。我主动把这个系统之前在数据库上有过的问题跟他做了沟通，并且把我的一些想法介绍给他。不知道是这些东西真的打动了他，还是他作为新员工想和大家搞好关系，很痛快同意了我的一些想法。从此每次系统升级，和数据库有关的部分，他都会主动发给我，并抄送给了部门一把手。这期间整个系统运行的比较平稳，偶尔出现小问题也都在影响范围最小的情况下得以解决。
我和他熟络之后，于是开始建议他在他们组内的会议中去分享跟他合作的一些收益，他的直属领导对他新入职几个月的工作也比较满意，慢慢也开始有了其他系统的负责人愿意尝试给我发送相关的变更升级细节。从一开始大家互相遮掩，到慢慢打开屋子互相串门，还是获得了很好的成效。
终于在第二年，半数以上的重要系统负责人都慢慢接受了主动把数据库相关的升级内容发给我。有的还会主动请我参加他们的会议旁听，我从而获得了对这个系统更多的了解。对于以后的运维还是有很大的帮助。
这也让我意识到，其实自己一开始急于求成，忽略了很多东西，其实很多事情，都是水到渠成的，强扭的瓜不甜。
第三步，建立制度
在入职后的第二年，跟大家慢慢熟悉了，对系统和公司业务制度等多方面也有了更多维度的了解之后，我再度跟部门一把手讲述了我的想法。
因为在过去一年的时间里，大家对我的整体评价还不错，年底绩效评价部门一把手给我了优，这使我底气更足了。这次敲开部门和一把手的门，没有再做更多铺垫，而是把过去一年践行的结果，以及大家的反馈做了回顾。同时对我自己第一年的方案也有了调整。
他听完了我的汇报之后，也问了我一些比较尖锐的问题，有些角度是我不曾想到的，有些是我已经准备好的。这次谈话总体比第一次要平顺很多，并且初步获得了我要的结果：
- 所有新系统的上线，从调研开始就必须有基础设施部门的人参与，数据库相关的部分需要由DBA知晓
- 对数据库的各项配置和指标做规范，建立统一的服务标准，无特殊情况不允许变动
- 从测试开始，对于数据库的各种规划就要提前做好，从算力到存储到高可用
- 重要系统上线之前，需要由DBA对数据库相关内容进行审核，审核通过后方可上线
- 重要系统在较大的版本升级或变更时，需要DBA提前审阅，对于存在较大风险的操作，必须提前预警甚至中止
- 重要系统出现生产环境的事故时，事故如果与数据库有关，DBA必须提供复盘以及整改方案
在制度上确立了之后，接下来做的就是不断实践不断调整。
第四步，不断完善
任何流程或者制度，都不是一步到位的。一个良好的管理模式，一定是动态中不断调整。
在制度建立没多久，公司开启了数字化转型，带来了组织结构以及运营模式的变化。面对几乎每天都有的新变化、新同事、新系统、新业务，之前的制度和规范就慢慢开始脱节。这对于我来说又成了一个新的挑战。
就在我希望通过这次大的变动，来继续调整完善之前设立的各项制度和规范的时候，部门却发生了很多大变化。之前支持我的领导离职，也有很多配合默契并且彼此认可的同事慢慢离开。直到有天，我从工位上站起身发现，周围熟悉的面孔竟然已经这么少了。
这次我成了下一个告别的那个。而有关这套规范流程制度的完善，终究成了一个不可及的梦想。
就在上个星期，那个“你爷爷一失误，我爷爷就要饭”的同事微信问我，怎么样避免某些某些问题，突然又把我的思绪带回了这段经历中。
最后修改时间：2022-05-19 14:20:24
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
