运维进行时-修改数据库密码

时间:2021-03-20 05:52:19

     从今天起不断分享我在团队中遇到的问题和想法,激励自己和团队不断成长进步。

     完事开头难,有想法却不知从何开始……

     就从今晚修改数据库密码开始。

     最后一次全量修改数据库密码可以追溯到3年前,连续3年不敢动数据库密码。今年交费系统需要一卡集中,面临未来业务的扩张,数据库的安全性存在隐患了。

     对于历史原因不在追溯,为了把数据库密码修改的风险性降到最低,团队花了近一个月的时间对读库、写库、卡库、报表库进行梳理,本着影响最小原则,分四次进行修改,今天已经是第三批次修改。

     数据库密码修改规范中应是常态,第一次修改时跟预期又出现了较大的出入,本计划1小时内结束,结果却花费了近2小时,而且影响到了在线业务。不由进行深思,为什么会出现这些问题。

     罗列了下第一次数据库修改时出现的问题:

     1、数据库密码有着复杂度,在修改前先给出了需要修改的密码,从复杂度上不存在问题,但是密码却以数字打头,导致预先写好的配置文件在修改时全部重新了一遍。没有人意识到这个密码是不合法的。

     2、密码修改后仍有错误的密码在不断连接到数据库,导致数据库被锁死,只有不断解锁,原因是该停的应用没有考虑全面,导致还存在部分功能在调用,排查又用了好久。

     3、dblink使用不规范,在修改前已经梳理好dblink的范围,但在操作时又被人新增了3个dblink,这个不在配置修改范围,导致后期排查时才找到原因。任何人都可以建dblink,对数据的安全性,可控性都存在隐患。

     4、业务没有考虑全,只考虑到了3.0的业务,在2.0上仍有业务未考虑。

     5、修改密码预期本次是不需要停核心业务,不需要停监控,在监控侧可以明显看到业务量降到了底,怎么影响业务了?回调的业务中也是未考虑全面。

     6、修改后,很多人还是使用老的密码登录,产生了新的锁,这个还在可控范围。

     7、修改后,部分主机未重启,导致密码未生效。

     出了这么多问题,第一天感觉就失控了,幸好在第二次修改时及时纠偏,半小时就把报表库修改掉了。今晚要修改写库了,好处就是业务全部停,可以放心修改了。