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