昨天有道云笔记的服务当机，官网以及服务都不能使用，我幸灾乐祸的发了一个朋友圈，强调了一下容灾的必要性，还调侃性的说不要省那点备份和容灾的钱，其实公司容灾和备份方案都是我定的，老板哪知道该做些什么才能让产品稳定。
最近我们一直在切换服务器，在切换负载均衡，在切换域名以及存储，最后也就是在今天，我把发布脚本也切换了。发布内容出错导致了公司服务短时无法使用(10分钟内，我的感觉是断了这么久)，断当时还是有点慌的，还要决策是恢复还是继续发布，后来相信自己的脚本，还是继续找报错，修了下去，还好结果还可以，影响不是很大。
起因
之前服务比较少，采用的是单机发布，也就是先登录到服务器，再执行部署脚本进行发布，有多少服务就要登录多少机器，一是慢，一是怕执行错顺序，好处就是心里不慌，挂掉就挂掉，有负载均衡撑着呢
这次服迁移，我们把原来的单服务进行了切分，要维护的服务器更多，服务也更多，所以也就打起了发布全自动化的主意。
过程
其实之前写的脚本主流程还是可以用的，只是缺少很多检测，比如tomcat杀不掉怎么办，启动后有没有启动起来，添加了相关的检测后，我找了个我负责的另一个产品上做测试，经过一下午的时间总算是可以完美运行了。
今天就开始搞主服务，照着昨天的脚本改，为服务器做定制，写好后，认认真真检查了半个多小时。觉得没问题后发布，一点，刷刷的日志滚滚而来，看到了报错，可惜无法中止，等都执行结束，产品就不能访问了。
这时心里还是有些慌的，回滚？还是继续发？经过一番思想斗争，决定还是继续发下去，回滚也不是那么容易的，也要很多步骤的。这时客服就开始叫了，然后是公司其他部门的，产品经理就开始找我，群里各种消息接踵而至。没办法，我也急呀，拉到个产品经理，让他替我回复。我就静下心找到错误，修正，多机执行，经过一番折腾总算是恢复了。
总结
1. 经过这次事故，我觉得最好的方案是将发布由一次变为两次甚至更多次，将服务器划分为一些子网，每次都是先在一个子网中进行发布，无问题后再再其他子网中发布，如果出现问题，就将子网切断隔离，进行修复。
2. 脚本也应该具有遇错自动回滚功能，不过实际情况下报错种类很多，也有一些是无害的，这种只能解决一小部分问题。
3. 能备份还是多备份吧
4. 脚本还是要多进行实际测试，别太自信，现在年纪大了，眼睛跟不上了，只能在思路上提意见。本以为是复制好的脚本，只改一些参数不会有问题，改好后，还认真看了半个小时都没看出错误
5. 这种事情最好不要让负责人去做，如果我当时交给运维同学去做，我去检查，可能也不会出现脚本错误。负责人会有时会逾越一些必要流程以及些许的盲目自信。
