一个撕逼的案例
这是双十一期间微博热搜上非常有名的图，说实话我第一次见到这张图的时候，真是小刀拉屁股—开了眼了。
后来这个P1故障当时就引起了两个部门的撕逼，因为这个故障影响面太大，又发生在双十一尾声，当时每秒钟可能几万的GMV，涉及到了理论资损。所以为了各自部门不吃全年325，这两活人就开始甩锅。后来又折腾了前后一周，各方看日志截数据找证据，才最后裁决出主责次责。
复盘是一个很折磨人的事情，既要写很多的材料，又要跟高P们一遍一遍的解释，还要填写时间线，灵魂深处交代当时的心路历程等等等。最重要的是整个过程都要背上巨大的心理包袱。也正是因为避免这样的折磨再次降临到头上，所以在双十一之后的双十二，两个部门都开始在压测模型开始保守，要知道双十二的体量跟双十一相比差了两个级别，但是在这个故障场景—商品详情页的QPS量级上都很保守。所以硬件资源的使用量级相比较双十一不降反升。
这里我有几点思考：
- 压测的时候，上下游已经对流量达成了共识，那么一方在面对意料之外的流量到来的时候，就有义务通知下游，下游先扩容上游再扩容，而不是自己只管自己，事后来一句“我就多加了X%，你就抗不住了？”“你为什么不留余量”。这是违反契约精神的，因为说好了就按照这个数字来，有特殊情况也要在已知压测场景的基础上评估，而不是凭感觉在压测的标准上又预留所谓的“余量”，因为这个“余量”是部门间事前不对焦的，不通知下游就贸然使用“余量”，这是不负责任的行为。
- 大促实际流量大于压测流量的时候，正确的操作应该是报备大促项目组，然后大家一起统一的操作，比如一起扩容，一起调整限流。因为现在系统的交互错综复杂，不能“只管自己，不管别人”，因为有可能你管了你自己，反而把下游打挂了，然后如果你还依赖下游的返回，下游崩溃再把你带崩溃了。所以这种应急不是一个好的SRE操作，而是在坑人。好比开车的时候，前面有路障，你没有踩刹车，反而猛打方向盘，把别人撞沟里去了，然后大家又是一体的，掉沟里的车把你的车也带进了沟里。
- 往往撕逼的原因就是当时一方的自救操作引起了另一方的故障，有些是因为后者本身能力不行没有保护性限流等面向失败的设计，有些就是前者的突破约定SLA操作。
- 好的SRE就是好的副驾驶员，他可以不了解车的“内燃机”，“发动机”等等部件具体的工作原理，但是他是应用系统owner的主辅助，可以横向观察，而且知道什么时候也有权力进行“踩刹车”等应急操作。好的SRE，面对“飞行换发动机”这样的紧急情况的处理就是丝般润滑，而不好的SRE，可能就直接造成停机了。
- 全链路压测模型制作起来非常麻烦，因为很多部门的口径并不一致，有些是前台交易部门，有些是后端物流部门，他们一个用词是“类目”，一个用词是“行业”。两边的内容又不完全严丝合缝，导致沟通起来很费劲，调整压测模型也费劲，带来大量的沟通成本。这也是全链路压测模型越来越偏，跟实际大促情况越来越大差距的原因。
- 无意义的卷现在太多了。压测的目标是看在整个链路下自己的系统在极限压力下的表现，但是压测数据报的水分太大或者过于保守，就是导致压测场景与实际场景失真太多，压测即使通过了，也失去了本来的意义，同时也带来了资源成本的大量消耗。
- “一朝被蛇咬，十年怕井绳”是人之常情，但是不要因噎废食，不要极左极右跳来跳去，也不能为了保障稳定性无底线的透支硬件能力，到后来挣得钱都不够赔的，做事情的意义何在呢？
- 大促日常化我现在觉得是一个伪命题。无论在《新闻联播》和国家统计局怎么说，中国大陆广大老百姓现在就是消费降级，靠频繁的大促是不能挽救业绩和股票的，卖血不能救贫穷！把页面做的干净一点，减少狗皮膏药的数字，少点套路，价格实惠一点，其实根本不需要那么多大促，大促也就是大家一起抢抢券，一切恢复简单更加事半功倍。把大促日常化的时间和精力做其他的事儿更有价值。
