A 业务用了 B 模块在不常见的 C 环境下崩了 D 网关没有自动切走导致线上挂了。ABCD 怎么分锅？

D 的锅最大

小孩子才做选择题，成年人全都开除

何必要分，都有甩锅的理由，分不清楚，好好优化升级呗

@PiersSoCool 好家伙，这不就是朱元璋的作风嘛。

因为 C 环境并不常见，所以 B 模块没有预见 C 环境的特殊问题导致崩溃是正常的，测试用例不可能做到 100%覆盖的嘛。

A 业务为啥要选择使用 B 模块？有没有考虑 C 环境的特殊问题？反正，得负主要责任。至于网关 D，我不知道楼主说的切走是怎么个切法？路由策略还是服务降级？如果是需要配置但没有配置的话，也有责任。

B 比较无辜.
AD 背锅.

A 40%; D 60%

B 强制 A 使用的？

如果 B 是若依赖，A 无法对 B 进行容错或摘除，A：100%
如果 B 是强依赖，看起来完全依靠自动切流，A 并没有及时监控到错误进行人工干预，A：90% D：10%

发现问题解决问题，为什么要分锅？

先排除主观故意的行为。
过失的前提是应当预见并避免。也就是说，（某人）应当预见到可能导致某种结果，因为疏忽大意而没有预见，或者已经预见而轻信能够避免，以致发生这种结果。（这段抄自刑法，虽然刑法本身不适用，但不妨碍这段话是如此地合适）

实际上，通过添加不同的缺失信息，可反驳 [A,B,C,D] * [有,无] 过错这全部八个命题。

为什么要用 python 2.7 + tornado ？不考虑 Windows 平台下没有 epoll 或 kqueue 吗？
fastjson 强制你使用的？

同意 9 楼，发现有问题解决问题就好了，没有人能做到完美。
分锅，对谁都不好。

A 业务用了 B 模块在不常见的 C 环境下崩了 D 网关没有自动切走导致线上挂了

这描述 。。。

如果是程序员 ，估计代码组织能力一般般。
如果是运维，经验不够，没有测试好。

@wiewiewie 我觉得挺好理解的，读着还挺顺口

现在喷子是真的多 动不动就开始人身攻击了

@wiewiewie 读起不毫无违和感

@elfive
@no1xsyzy 线上事故要出报告要定责呀~ 底下人也不想

我觉得锅是 C 的

（ ABD 分锅也就算了，还把环境都安排了吗）

@chairuosen 如果有想要踢的人可以借机踢（
不然就应付一下和稀泥吧，实在不行找个人背黑锅，其他人其他方式补偿一下

@chairuosen 而且你这个题干其实根本不清晰
通过假设补全的信息，我可以创造四种情况，分别是 A B C 的锅
A: 强依赖于 B=journald 导致 C=upstart 的系统无法使用 不应该用 B=journald，该用 B=Sentry 之类的单机日志系统。
B: B=asyncio 之前不支持 IOCP…… 虽然 C=Windows 下能正常启动 B=asyncio，但没有效果。
C: 用着 B=tornado 呢，为什么要装台 C=Windows + Python 2.7 ？

D 的问题其实独立考虑。网关是否进行了恰当的 health check ？因为某一环境导致线上挂了是单机部署？单机部署谈什么网关切换？

D 吧，BUG 是不可能避免的，但是网关没有切换肯定是有问题

@no1xsyzy B 是自研日志系统的 SDK，C 是母鸡双网卡环境的 docker 容器，在这个环境下 node 一个读网卡的同步方法高并发时有可能卡住不返回导致请求 hang 住，docker 实例貌似大部分都分配到这批双网卡的母鸡。
整个服务是托管出去的类似 gae，网关层 health check 不清楚，但有可能只是一个接口挂了有其它正常请求导致没切走。

@chairuosen 首先记得一点，向上面的报告怎么写和你去踹谁屁股是两回事儿
比较混乱，我主要是想问分别为什么会运用这些内容。
不过看得出是一个 B+C 的问题。
1. A+B 组合之前是否存在过？
2. A+C 组合之前是否存在过？
3. A+B+C 没有 roll out / rollback 机制吗？