一件大事儿与一些小事儿

前天晚上做了一件“大事”――核心业务系统数据库服务器迁移，用新采购的两台高配服务器代替原有的两台低配。

如果上面只是部署了数据库应用倒也好说。

两台主从复制，主库还好，从库呢，netstat一下监听的东西真不少！其他的业务包括（均要拆分走）：

1. web端合同数据实时备份
   

2. 监控服务端
   

3. 日志与行为收集服务端

4. 此处是被忽略了的邮件发送客户端配置
   

也就是说除了要在新的服务器上部署新的系统（操作系统之前不统一，这次统一了），配置新版本的sql应用（升级为更新的稳定版），目录与用户管理重新做之外，还要考虑任务计划、监控、日志收集……

（由此可见历史包袱之沉重……）

方案内部讨论过之后确定，实施时间最终定为晚上9点到12点。实施团队由基础架构组的我，DBA,两个架构师来进行。9点了，开工！两个架构师在一边玩手机，DBA在聊天。我在电脑前疯狂敲键盘。

凌晨0点2分发出公告邮件，业务系统恢复可用。大伙各自回家睡觉。

那为什么过两天才写出来呢？

当然是继续填坑了。大体如下：

1. 某近期新加的子系统数据库未迁移过去，导致系统无法使用（业务受影响，好在有备用方案）
   

2. 主从复制报错，从库数据查询结果非最新（业务未受影响，部分同事查询受影响）

3. 上线脚本执行失败，权限原因还有邮件发送功能未启用
   

4. 监控未能全部及时恢复。（计划之内）

5. 远控卡IP变更过程中有一个出现异常无法访问。（计划外，过阵子处理）

除了填坑，还有新的需求要做，新的主从复制，账号管理，上线与系统版本升级等，总之忙碌不堪。

以上是大概情节，没什么营养，分析一下，给大家做个参考：

• 历史原因很多做的不到位，这是架构初期设计的缺陷，初期没运维，没人设计，能用就好。

• 说说这次方案中遇到的点滴问题。
  

方案的设计

事务级别与相应的不对称：

由于这次是数据库迁移，设计所有核心业务的使用，因此注意事项的级别，并据此做出方案设计。

Bad:

一个人写出方案，发给组内同事，总监确认后发送全体通知。

Good:

定性，重大：

首先内部讨论，这个事情要做，要尽快做，需由运维主导、DBA全程辅助，各系统组中产品经理与业务部沟通确定时间安排，技术开发协助后期测试，确保可用无误。

对于方案细节要头脑风暴，多人参与（相关人）要有文档，可逐一排查。

通知的逻辑：

由于没提前和业务部门沟通，因此邮件发出后，他们便以为我们高冷。

应该和各业务部门提前沟通，确认好之后再发邮件。或者即使没沟通，也应在邮件中注明时间冲突的话找谁协调，而不是直接将他们导向boss，这样造成了误会很不好，这里就要强调部门之间的沟通，常常不差于外交层面的艺术和技巧。

时间和工作的安排：

这是近期的第三个（或第四个）重大变动，每次都有后续工作需要处理，均属于重要不紧急的，本应该紧跟步伐去做，但往往新的需求下达，难以抽取时间处理。

一堆小事儿不做好将变成一个大事儿，要解决一个大事，则要弄好每一件小事儿。

本文出自 “运维故事” 博客，谢绝转载！