前天晚上做了一件“大事”——核心业务系统数据库服务器迁移,用新采购的两台高配服务器代替原有的两台低配。
如果上面只是部署了数据库应用倒也好说。
两台主从复制,主库还好,从库呢,netstat一下监听的东西真不少!其他的业务包括(均要拆分走):
- web端合同数据实时备份
- 监控服务端
- 日志与行为收集服务端
- 此处是被忽略了的邮件发送客户端配置
也就是说除了要在新的服务器上部署新的系统(操作系统之前不统一,这次统一了),配置新版本的sql应用(升级为更新的稳定版),目录与用户管理重新做之外,还要考虑任务计划、监控、日志收集……
(由此可见历史包袱之沉重……)
方案内部讨论过之后确定,实施时间最终定为晚上9点到12点。实施团队由基础架构组的我,DBA,两个架构师来进行。9点了,开工!两个架构师在一边玩手机,DBA在聊天。我在电脑前疯狂敲键盘。
凌晨0点2分发出公告邮件,业务系统恢复可用。大伙各自回家睡觉。
那为什么过两天才写出来呢?
当然是继续填坑了。大体如下:
- 某近期新加的子系统数据库未迁移过去,导致系统无法使用(业务受影响,好在有备用方案)
- 主从复制报错,从库数据查询结果非最新(业务未受影响,部分同事查询受影响)
- 上线脚本执行失败,权限原因还有邮件发送功能未启用
- 监控未能全部及时恢复。(计划之内)
- 远控卡IP变更过程中有一个出现异常无法访问。(计划外,过阵子处理)
除了填坑,还有新的需求要做,新的主从复制,账号管理,上线与系统版本升级等,总之忙碌不堪。
以上是大概情节,没什么营养,分析一下,给大家做个参考:
- 历史原因很多做的不到位,这是架构初期设计的缺陷,初期没运维,没人设计,能用就好。
- 说说这次方案中遇到的点滴问题。
方案的设计
事务级别与相应的不对称:
由于这次是数据库迁移,设计所有核心业务的使用,因此注意事项的级别,并据此做出方案设计。
Bad:
一个人写出方案,发给组内同事,总监确认后发送全体通知。
Good:
定性,重大:
首先内部讨论,这个事情要做,要尽快做,需由运维主导、DBA全程辅助,各系统组中产品经理与业务部沟通确定时间安排,技术开发协助后期测试,确保可用无误。
对于方案细节要头脑风暴,多人参与(相关人)要有文档,可逐一排查。
通知的逻辑:
由于没提前和业务部门沟通,因此邮件发出后,他们便以为我们高冷。
应该和各业务部门提前沟通,确认好之后再发邮件。或者即使没沟通,也应在邮件中注明时间冲突的话找谁协调,而不是直接将他们导向boss,这样造成了误会很不好,这里就要强调部门之间的沟通,常常不差于外交层面的艺术和技巧。
时间和工作的安排:
这是近期的第三个(或第四个)重大变动,每次都有后续工作需要处理,均属于重要不紧急的,本应该紧跟步伐去做,但往往新的需求下达,难以抽取时间处理。
一堆小事儿不做好将变成一个大事儿,要解决一个大事,则要弄好每一件小事儿。