前记：
前段时间，项目要迁移服务器，迁到一个单独的机房去，熬了至少4-5个晚上，最后都迁到吐了；
非常之痛苦；
2，配置，这是最恶心的地方，我们svr之间交互非常多，很多地方用了ip配置（能用内网域名
做的都用域名做了）；另外系统维护脚本也有大量的svr配置等等，迁移后，需要一一
去改配置，改的蛋都痛了，而且非常容易出错（人是很容易犯这些错的）；
手动去改这些配置效率非常低；
3，服务器之间的关系，比如：
1) iptables 要给这个服务器打开访问的端口
2) mysql 权限开放
3) 服务器之间赤裸裸的信任关系（统计或者监控数据要拷贝到中央服务器进行处理）
经常出现迁移某子系统后过几天发现问题...查来查去...那叫一个累啊；
4，脚本迁移也挺啰嗦
我们很多脚本都是放入crontab中执行的；迁来迁去，最后就忘了加入crontab中了；
最后终于迁移完了，最后的感觉是：我再也不想迁移服务器了；tmd的痛苦，纯手工活；
分析：
这几天事情稍微少了点，有空闲下来，就分析了为啥前段时间痛苦的原因，几点感受：
1，我们的系统维护太弱了，这样手动去管理服务器都嫌累了，何况系统整体迁移，而且是
一个包含非常多模块，覆盖好几个机房的系统呢？
于是我在想，如果qq，baidu都用这么弱智的手段去管理成千上万台机器，那蛋就不止
痛了，非碎了不可；
刚好看到 instagram 这个牛逼轰轰的网站架构文章，7个人搞定了上百个节点；哦，原来
他们用了 fabric；
2，配置管理是门艺术，尽量使用内网域名dns吧；同时我在想，是不是其他配置也可以采用这种
中心化的控制手段呢？比如，某个子系统，包含多少个节点，每个节点在哪台服务器节点
上；这样至少不要去到处修改维护这些配置了；
阅读(920) | 评论(0) | 转发(0) |
