首先你们的代码，要检测好所有的网络故障造成的问题，显示出来一个错误信息之类的东西，这在用户用的时候也有用，帮助用户定位问题，当然也帮助你们在内部撕逼的时候，有明确的证据。

其次，遇到这种可能会伤别的组老大面子的指控，确实要小心，在公司里面做事情，做人还是蛮重要的。如果你什么都好，就是跟人不能合作，老板不见得会站在你这边，老板要看，留你呢，还是留一堆人呢。

其实，也不是不能去谈问题，也许私下先跟运维组的人沟通下，或者跟老大沟通下，问题就解决了。运维组会不会也有自己的难处呢？比如需要的设备，上面不批。或者本来准备把测试网络和办公网络分离等等，但是老板不让之类的。非要搞到对立，也不见得对你有好处。

1楼 @tinyfool 后台有记录请求的 head body 以及 return, 是最后 timeout 了报错, 后台没请求过来, 这个网络问题也并不是一两回这样, 而是天天这样. 每次有问题, iOSer 就会一脸愤怒的过来找我. 我也都会找那边问一下

我说的就只有一句; 这破网络能不能靠点谱. 拿我以前的经历(前公司倒闭前, 网络运维后台代码基本都兼着)来说, 碰到这种事, 直接大方承认并告知可能的原因(人员太多导致网络卡顿, 电信网关限制之类的), 然后路由上看一下占用带宽最严重的是谁私下让他上班时间少用一点(怎么也不至于因为怕老板说我而指责提出问题的人, 哪怕提出的这个问题老板能看到). 基本都是和平解决了. 后来运维组老大过来也说自己本来脾气也不好

倒不至于搞对立, 如果真要站队, 我宁愿 out 了

2楼 @tonyliu 不是后台，而是iOS前台，遇到问题，要报个错，这样用户也知道网络没连接啊

3楼 @tinyfool iOS 有提示网络超时, 说我是服务提供方, 让我解决. 次数一多就带着情绪了

我觉得先礼后兵吧

我估计：app端对网络检测做的估计也不够好，然后后台处理的时候，也有那么些小问题，最后网络上面确实也有些问题，然后为了甩锅，最后就给运维了。

网络的问题，要检查，需要功力，又不是随便找个运维就可以解决的。

6楼 @damon app 记录了每一次请求前和请求之后的时间. 后台记录了接收到请求的时间以及马上要返回数据回去的时间. 这些都是有理有据的可确定因素, 以及各自能做的处理. 内部测试时因为走的是内网, 从没出过这些情况