lesserror2021-11-14我也写了几年的PHP，想问一下雪峰老师关于饿了么用PHP遇到的一些坑，有写文章复盘总结吗？ 觉得这块还是挺有意思的。作者回复: 内部复盘n次，wiki上不少内容，但对外分享（如：Qcon或公众号文章）印象中没有。2015年那个不堪回首夏天后，我们也逐步将PHP相关系统迁移或下线了。其实不止PHP（当年我们自认对PHP驾驭尚可），哪怕我们一直自认驾驭能力最强的Python/Java，一旦面临超高并发，都有可能出现各种意想不到突发情况。一言以蔽之：防火胜于救火。
10
HarperMom2021-11-11想请问下关于RabbitMQ的巨坑是什么样的情况？作者回复: 这里展开不了，细节太多，建议先搜索「饿了么 RMQ 技术运营 徐盎 兰建刚」等关键字
共 3 条评论6
泰伦卢2021-12-04有问题为什么没追责测试呢，测试为什么没测出来？哪个工程师敢保证自己写的代码没问题呢？作者回复: 几方面原因： 1、访谈中有提到，root cause 来自一个开源组件 bug，非业务代码或自研框架 bug，QA/SDET 很难测到； 2、即使来自开源组件 bug，触发条件也比较苛刻，否则之前早就爆发了； 3、即使来自开源组件、即使触发条件比较苛刻，在这次爆发前也出现了端倪，负责这个开源组件同学（虽然是开源组件，按技术团队内部规定，也需要确定 owner）和另一位相关同学，在事后复盘时承认当时没引起足够重视：因为 bug 属温水煮青蛙类型，爆发需要一段累积时间，所以错过了最佳修复时间； 4、最终修复其实很简单：升级开源组件即可。而且事后复盘发现，即使不修复开源组件，也有其他 workaround 可以绕过去，就是麻烦一些。
2
UncleNo22021-11-15到底应不应该处罚一线工程师呢？作者回复: 见仁见智，怎么做都会引起波澜。就我经历而言，看团队不同阶段的一些核心变量是否有较大变化，如：味道、氛围、文化、业务规模、组织规模等。以饿了么为例，早期团队、主动（空降）引入团队、被动（被收购）引入团队等时期，核心变量都有不小变化。有较大变化，相应游戏规则（不止故障问责这么细的领域）就要随需应变。
共 2 条评论2
任国强2021-12-28管理细则方便公布吗，特别想看看怎么去定义这些规则作者回复: 细节主要PMO负责，宗旨就三点：1、可明确（one）owner；2、可量化（数字化或人肉皆可）评估；3、不可模棱两可，否则宁弃之。
1
hao-kuai2021-12-01简单来说这个事情需要一个背锅的，但是不能是张老师，如果是张老师，那就意味着你的老大也有责任，为了“大局”体面只能牺牲工程师作者回复: 并不是，最终我的自请降级也执行了，而且我始终认为我要担主要责任（管理疏忽），不是简单的江湖义气。
1
lisimmy2022-07-09任何时候主动承认错误没毛病，但是主动申请降级，有点拙了。会让上级觉得，你越权做决定、你没担当、没责任心、自暴自弃等的。 很简单，犯错了，承认错误，改正，尽力挽回损失。如果犯错了，申请降级，上级的心里可能会这么想：“怎么着，犯个错，就承受不了压力了？拔腿就跑不干了？你要降级，好，那么成全你” 个人见解，如有冒犯，见谅！
范2021-11-29究竟是责任担当，还是江湖义气，感觉很多时候是分不清了。不过每个成年人都要为自己的行为负责，这是没错的。- 侯建坡2021-11-16坐在哪个位置都有自己的无奈。