最近一段时间的工作中，遇到了不少问题，逐渐的体会到经常听到别人说的一句话，快 就是 慢， 慢 就是 快。 之前大概也是了解这句话大致的意思，大致说的就是前期做好准备工作，后期少遇到问题，整体的项目或工作就不会遇到太多的麻烦，能比较顺利的完成。
这一段的工作中，其实对这句话有了一些更深刻的体会，快并不是指速度快，当然速度太快自然会来不及做一些准备的工作，这里的快，个人认为是不假思索，以经验主义替换看似已知，但其实未知的事情。
举例我们要做一个MYSQL 多源复制的项目，按照我以前的经验，这绝对不是什么大问题，基本上很快就会完成。但实际上操作中，发现各种问题，例如
1 多源复制中的数据库的版本是不统一的
2 多源复制中的数据库中的配置文件都有问题
3 多源复制中有些数据库根本就没有开启BINLOG
4 某些数据库服务器的修改配置文件需要重启动，生产的机器不是随便就能重启动的，需要各种流程，延误整体的时间
5 由于之前沟通有问题，使用了错误的汇聚的服务器
其实想想上面的哪一项，都是由于快，造成最后的慢，好在还在计划预定的时间点中完成。
1 如果提前将所有需要多源复制的，源短的主机的版本都统计一遍，并且可以预先查一查，可能存在的问题，会将避免踩一些坑。
2 如果提前将这些数据库的配置文件捋一捋，将一些基本一眼就能标识的错误标记，并提前更改，沟通，也能避免踩一些坑。
3 在计划之初，对一些“硬骨头”可以采取区分对待，并且对可能需要的时间有一些“宽容度”。
4 应该将这个工作提前，而不是在操作中发现问题，避免多次重启。
5 应该提前沟通或确认，避免错误或重复劳动
不过还好，后续的工作中会注意这些问题。该放“慢”的，还是的慢着来。
