从一次救火想到问题

写在前面的话:

火烧大了,总会嫌水不够用。今天机房网络出现了问题,导致许多go服务从zk上断开了,因为网络断开,这些程序在尝试重新连接一定次数后主动退出了。开发人员需要到部署系统重启这些服务。这个时候部署系统也无法工作了,导致服务全部无法重启,大家只能干瞪眼。部署系统的前端能页面,后端api调用不通,原因机房的网络的问题。领导指示把后端服务迁移到网络正常的机器,因为当初api是直接ip连接的,没有使用域名,这个时候迁移后端服务,需要手动重新编译前端,手动部署前端(部署系统前端也是部署系统部署,部署系统无法工作,只能手动部署),手动部署后端服务,手动修改新机器的ngix。。。。。。
大吉大利,赶在早高峰前网络恢复了,能够正常部署了,虽然我什么也没有干。。。,但是这次事故让我看到了一些问题。

内部服务是否应该使用ip访问

内部服务不应该用ip访问,目前公司内部服务知之间都是通过ip或者机器名字(本地host)项目调用,这回存在一些问题,新加了机器host忘记同步,机器改了名字,host忘记同步,或者有的同步了Host,有的没有,服务迁移会导致很多其他的服务不可用,需要一个一个手动更新调用地址,这过程麻烦,并且容易改错或者遗漏。

程序是否应该有手动hack的后门

一定需要。当服务运行起来了,我想查看服务的内部信息,修改服务的状态,绕过某些条件限制执行操作,这个时候怎么办。最常见的就是线上环境发现很难调试的bug,无法复现,这个时候就需要开启日志的debug,让开发人员能看到更多的调戏信息。Linux下给进程发送信号,控制进程完成相应的操作。linux切换到root权限,修改特权文件,之前特权操作。

自动化工具不能使用时候怎么办

明确自动化的过程,将自动过程(日志)记录下来,使开发人员能够按照这个流程来执行。比如自动化执行一条非常复杂的命令,那么就应该将这条命令及命令执行过程,执行结果都保存下来,无关人员应该能够通知日志知道程序作了什么,在哪里出错,以便在救火的时候能够手动hack。即使无法自动化,也要将手动档的难度降到最低。