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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

标签：运维