亚马逊Oncall, 工程师接力, Stadia下架

这两个星期, 是我进公司以来最酸爽的两周. 它重现了我在亚马逊时候的那种强度. 我知道很多人不喜欢过于紧张, 压力过大的工作, 我也不.

但在特定情况下, 如果有坚强的技术后盾, 人力后盾, 良好的心理状态, 高压工作一段时间, 其实很带劲. 今天写几个oncall的小故事.

① Amazon Q4 Scaling

亚马逊的Device Org有个特别活动叫Q4 Scaling. 这应该算是个内部行话, 网上能搜到的不多.

每逢过节, 大家要准备好对付这个大事件: 节日拆包. 比如: 感恩节, 圣诞节, 新年, 双十一, Amazon Prime Day. 在北美, 最要命的是圣诞节.

平安夜前后24小时, 很多人会拆开自己的礼物, 而很多礼物就是亚马逊的电子产品, 比如Alexa, Kindle, Fire Tablet. 亚马逊向来打的是平民价, 又喜欢打折, 于是买的人特别多.

压力在哪呢? 整个美国, 甚至全世界, 在同一个时间段拆礼物: 第一次打开电子产品, 谁都有个十分钟的新鲜感, 当然要各种乱点刷刷刷. 尤其是圣诞节早上, 短时间内会产生巨大的流量.

Device Org下面的组, 基本上都要面对这个压力, 尤其是后端.

Q4 Scaling, 其实就是要预测: 到底需要多少台机器才能支持圣诞节的流量; 其次还要确保这过去一年写的代码, 在高压情况下不能崩.

最好的办法, 就是模拟最坏情况. 他们会做一个Load Generator, 说白了就是写个脚本, 模拟巨大的流量, 把系统的各个角落都冲击一遍.

虽然泥石流, 但是有用. 有问题的系统, 提前崩溃, 提前修复. 做预算的时候, 会根据去年实际的流量, 再根据今年卖出去的电子产品量, 综合做一个几倍的估算. 一般在应对冲击前的这个季度就会做好准备, 圣诞节实在第四季度, 于是就叫Q4 Scaling.

倒也不是说亚马逊支持不了那么大流量, 而是: 全公司那么多系统需要服务器支持, 所以必须提前很久做统筹安排, 把硬件投放好. 等峰值过去了之后, 还要再把服务器都归还回去, 什么时候用, 什么时候拿, 不闲置浪费.

来来来, 笔记拿出来, 亚马逊的Leadership Principle之一, Frugality, 节俭.

Frugality: Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense.

② 圣诞节48小时接力

什么事儿跟$$💰挂钩的时候, 容错率就很低. 当年我们还有个传统: 圣诞节熬夜值班.

Q4 Scaling是做足了准备, 但谁知道圣诞节晚上会有什么幺蛾子? 即便是我们的系统没问题, 但要是上游出问题呢? 再或者是我们系统的下游出岔子, 需要我们及时调整?

总而言之, 不管系统多么自动化, 也放不下这个心.

谍战片谁都看过. 圣诞节凌晨, 我们就像监控室里的安保. 操作不难: 盯屏幕.

当时我们后端几个大组, 上上下下有几十个人. 圣诞节peak hour 48个小时内, 每个人值班8小时, 六七个人轮换负责.

要分Primary Oncall, Secondary Oncall; 第一道防线和第二道防线. 作战计划很明确: 遇到问题, 如果30分钟之内没有自动缓解, 立刻联系Secondary Oncall. 同时还有manager oncall, 也轮班, 有事情一直在线.

作战计划的一个主要环节是汇报战况. 在这8个小时里面, 尤其是最中间的那16个小时, 每一个小时都要做一份汇报: traffic是不是到预计的程度? 报错量多少? 系统(memory, cpu)是否平稳? Latency P99/P95是不是靠谱?

亚马逊的工程结构是非常垂直的, 每个org有自己的生态圈, 要靠自己维护. 除了AWS那一套工具基本上可以不操心, 自己的系统里面的逻辑对错, QPS, 系统内存, 事无巨细, 尽是变数, 全部要拿捏.

别以为这是个苦差事, 没人干. 每年做Christmas Oncall都有点英雄主义, 一定会有自告奋勇的: 要么是没他不行, 要么是有英雄情结, 再要么是热血单身狗. 总之这种有组织有纪律, 工程师抢着熬夜的硬仗, 出了亚马逊应该都罕见. 要说亚马逊的工程师硬核, 有团魂, 我是能体会到的.

好几年没这么硬拼过: 这两周我跟着我司一个业界明星工程师, 救了两周的场, 像迷弟一样观察偶像四两拨千斤, 还学到一些技术干货. 虽然每天8点睁开眼工作, 晚上1点睡觉, 但因为参与了一场重要的战役, 心里居然幸福感爆棚.

③ 云端游戏

这周Stadia宣布, 明年, 01/18/2023 就要被关闭了(新闻链接). 它2019年刚刚预售的时候, 我还买了特别版. 它太适合我这样的用户了: 对游戏没粘性但偶尔想试试; 想玩又没有PC.

2020新冠元年, 我在Stadia上面跑遍了希腊(Assassin's Creed Odyssey, 刺客信条奥德赛). 年底我尝试了Cyperpunk 2077. 我还在科罗拉多的Airbnb里面, 跟朋友们各种介绍Stadia的好处, 是游戏的未来等等.

跟很多科技公司一样, 今年的谷歌也拉紧了裤腰带, 缩减入不敷出的项目, 于是Stadia被砍掉了.

我们的选择还有GeForce Now.

GeForce Now是我尝试的第一个云游戏平台, 2019年我就试过它的beta版本, 做过一期’真香’视频, 当时还对尚未面世的Stadia特别期待.

它跟Stadia最大的区别是, 并没有强调无缝链接. 我们可以明显感觉到, GeForce Now有一个虚拟机在远程跑. 当年它甚至直接给我打开一个Windows界面, 让我选游戏, 就像网吧主机一样. 现在GeForce Now还是有免费的选项, 以及两种付费月包套餐.

我感觉Stadia的一个瓶颈, 是它要求游戏产品跟谷歌自己的系统融合, 因此一定增加了很大的工程成本, 而能登录谷歌Stadia平台的游戏自然就少一些.

GeForce Now是远程主机, 理论上, 凡是在Windows上跑的游戏, 应该都能运行. 它还跟Steam合作: 大部分Steam上买过的游戏, 只要游戏厂家允许, 就能跑. 这样就比Stadia灵活很多.

从本质上讲, GeForce Now做的是远程Windows系统租赁, 而Stadia更像是云端游戏的生态圈. 只可惜现在少了竞争, 相信大部分像我一样的苹果用户, 会自然挪动到GeForce Now.