上周一使用发布系统为项目进行发版实验的时候提示失败，提示如下：
update failed, deploy failed, rollback-useless before any actual changes, task 235347 update, Command '/home/w/xxxx/rs_action_front/leads_server/control.sh stop' returned non-zero exit status -9
提示shell执行stop命令的时候项目返回的exitcode是 137 或者143 反正不是期待的exitcode0，然后脚本里面明明写了 exit 0 ；
后来和shuchang一起去找运维zhangke 和fuzengj 帮着一起排查问题，通过在执行shell脚本时候增加-x 参数发现是执行stop 脚本的时候 里面有一行按照进程名字进行kill的命令会把control.sh脚本自己也给kill掉，导致返回的code是 137 ；
改进的措施是：把grep出来的进程再过滤掉control.sh 脚本自身； 问题终于得到简单解决；
但是发布系统带来了另外一个问题； 目前项目的目录如下：
|-- 1config
| |-- xxx.xml
| `-- run_log.xml
|-- log
|-- bin
| |-- restart.sh
| |-- start.sh
| |-- stop.sh
| `-- test.sh
|-- control.sh
|-- leads_server
|-- leads.zip
|-- nohup.out
发布系统中有个配置是，选择不备份的目录；配置发布系统的时候让运维同学填写了log 目录不备份，本意是这个目录可能太大，二进制删除替换就行这个log目录不用备份就行，但是令人无语的是发布系统会把系统部署的整个目录rm 掉，幸好日志里面没有太多价值很大的东西，最重要的信息已经进入了数据库；
这就是涉及到团队协作和开发时候的沟通误区：我理解的信息和别人理解的信息没有达成共识，大家都在按照自己理解的层面去做事情；
虽然项目部署的时候进行了二进制和配置的备份，但是删除整个目录绝对不是一个好的解决方案； 因此应该给做发布系统的这些同学提提意见，后续不处理的话感觉会是埋个炸弹；
针对上述问题进行的整改方案是：1，对部署脚步增加grep -v 过滤，避免把执行stop 的脚本本kill掉（ 深层分析是：kill -9 是暴力的做法，如果早期接入发布系统的时候使用supervisor 守护进程或许就没有这个问题）
2，修改日志的路径，将要部署的二进制配置的目录和日志的目录分开，日志的目录变成了硬编码的目录和项目目录平级，项目名字 xxxx 日志目录 xxxlog 避免发布时候的删除； （脚本中增加创建日志目录的步骤）
随着团队规模的增加，需要不断去达成共识去解决问题，各个业务端应该提供充分的文档和反馈路径来协作解决问题，否则简单的事情也会变成复杂的事情，耗费的是更多的人力投入来解决沟通不畅导致的问题；