从一次救火想到问题
写在前面的话:
火烧大了，总会嫌水不够用。今天机房网络出现了问题，导致许多go服务从zk上断开了，因为网络断开，这些程序在尝试重新连接一定次数后主动退出了。开发人员需要到部署系统重启这些服务。这个时候部署系统也无法工作了，导致服务全部无法重启，大家只能干瞪眼。部署系统的前端能页面，后端api调用不通，原因机房的网络的问题。领导指示把后端服务迁移到网络正常的机器，因为当初api是直接ip连接的，没有使用域名，这个时候迁移后端服务，需要手动重新编译前端，手动部署前端(部署系统前端也是部署系统部署，部署系统无法工作，只能手动部署)，手动部署后端服务，手动修改新机器的ngix。。。。。。 大吉大利，赶在早高峰前网络恢复了，能够正常部署了，虽然我什么也没有干。。。，但是这次事故让我看到了一些问题。
内部服务是否应该使用ip访问
内部服务不应该用ip访问，目前公司内部服务知之间都是通过ip或者机器名字(本地host)项目调用，这回存在一些问题，新加了机器host忘记同步，机器改了名字，host忘记同步，或者有的同步了Host，有的没有，服务迁移会导致很多其他的服务不可用，需要一个一个手动更新调用地址,这过程麻烦，并且容易改错或者遗漏。
程序是否应该有手动hack的后门
一定需要。当服务运行起来了，我想查看服务的内部信息，修改服务的状态，绕过某些条件限制执行操作，这个时候怎么办。最常见的就是线上环境发现很难调试的bug，无法复现，这个时候就需要开启日志的debug，让开发人员能看到更多的调戏信息。Linux下给进程发送信号，控制进程完成相应的操作。linux切换到root权限，修改特权文件,之前特权操作。
自动化工具不能使用时候怎么办
明确自动化的过程，将自动过程(日志)记录下来，使开发人员能够按照这个流程来执行。比如自动化执行一条非常复杂的命令，那么就应该将这条命令及命令执行过程，执行结果都保存下来，无关人员应该能够通知日志知道程序作了什么，在哪里出错，以便在救火的时候能够手动hack。即使无法自动化，也要将手动档的难度降到最低。