共计 3782 个字符，预计需要花费 10 分钟才能阅读完成。
8102 年的那个冬天，北京的天气有两种：一寸雾霾携着一抹温暖，阵阵寒流带着万缕阳光。每逢这样的天气里，我时常会想起赤道上那个永远在 27°-31°之间的城市：新加坡。想起那里潮湿温热的空气，那里几乎永远浅蓝色飘着白云的天空，和那个每周五有个妹子唱华语歌的小酒吧。在最低温度 -13°的那个晚上，下班的我走在寒风中，甚至开始思念印尼的沙滩：炽烈的阳光透过椰子树洒满沙滩，也照在身上；海浪随一阵阵风浮浮沉沉，椰子树哗啦哗啦作响；远处海面上一只小船上，当地船员放着载满游客的风筝。我努力回忆躺在沙滩旁长椅上的那份炎热，而唯一能感受到的是一阵扎脸的寒风。
我隐隐感觉到，新加坡，大概是我永远渴望却呆不住的新加坡。
两年前，我加入 Grab 北京。作为一个从没有出过国的软件工程师，为了应付出差，我也办理了护照，从此开启了浪浪浪模式。由于市场在东南亚，Grab 普通员工入职三个月基本上都要去新加坡出差，目的是保证能和 PM 用半吊子英语正常沟通、体验公司服务，之后每 4-6 个月出差一次核对需求、推进项目。Grab 不仅仅给了我看东南亚的机会，还留给我充足的时间去体验当地的风土人情。平时的日子里，也遵循朝十晚七的节奏，除非 oncall 其他时间都是生活。在技术层面，Grab 主要用 Go 语言，走敏捷开发规范，大家对问题也寻根究底，氛围还算不错。在经历了前一个公司的单双周模式之后，在 Grab 真正感受到了接近完美的 life-work balance。
当一种 balance 逐渐成为日常，它注定要被打破，因为随着时间推移，会累计一些负面问题；如同战争之后的和平，持续太久，新势力会变成旧势力，而旧势力会阻碍发展。Grab 一个很大的问题是组织架构趋于稳定，越来越像传统欧美外企，越来越不像创业公司，这种稳定极大地降低了执行力，只能保证现有业务不被侵蚀，却不能促进快速开发和推进新的业务线。对我个人而言，最大的感受是：太闲了，我是不是要废了？！
经历了三四个月的业务交接，来 Grab 的第二年，我开始转向新业务；与此同时，偶然碰到一个新加坡的 team 就帮他们做一个项目。这次偶然的机会，我了解到 SRE，真正开始尝试从架构的角度了解一个服务：有没有 single-point-failure, 有没有 downtime-fallback，怎么做服务降级，等等。这么来一波以后，终于明白了为什么 MapReduce、gossip protocol、分布式 hash、p2p system、consensus、append-only file system 之类的概念为什么会被广泛用于各种分布式计算框架、消息队列、数据库和文件系统。
然后问题来了，我做过的项目中，除了 MySQL、Redis、ES、SQS、Kafka 为什么其他产品都没有用过？为什么 Kubernetes、docker 那么火，Service Mesh 都成熟了，公司还在用 AWS 原生虚拟机？坐拥东南亚六亿人口，没有 Spark、Cassandra、Mesos 等产品的应用场景？有时候会想，分布式系统的套路千篇一律，为什么不根据自己的需求写一个呢？这大概是一种无知的狂妄吧。
为了搞明白这些问题，也为了挣更多钱，我尝试 transfer 到 Grab 新加坡总部。然而，中途发生意外，被 300k QPS“骗”到了头条。这段故事后面细说。
为什么离开 Grab？
虽然离开了 Grab，但 自认为 Grab 还是一个不错的公司。作为东南亚版 Uber，是东南亚最大的独角兽，最近刚刚完成了 45 亿美金的 H 轮融资，估值达到 140 亿美金。它正处于一个比较快的上升期，是一个还不错的平台。我可以列出一堆它的优点：
外企文化，不加班，不加班，不加班。Life-work balance 应有尽有；
能锻炼英语，能出国，对英语不太有信心，但想出国（移民、下一代教育），简直是完美的候选（将来去 FANG 也会容易很多）；
离职后，到手的期权保留十年（比某团良心太多）；
完善的工作流：强制 code review，架构审核、上线审核非常严格；
公费旅游（类似于 2，对于只想出国玩耍的小伙伴）
每年工资普调（依据人民币的贬值速度）
我曾设想过平平淡淡的生活，上班做着喜欢的技术，下班学习下吴恩达的课，累了打打 Dota。如果 transfer 到新加坡，还可以远离北京的雾霾，去印尼的海滩晒晒太阳。然后坐等 Grab 上市，拿一波钱，改善下生活。在新加坡这个高度发达、阶级固化的国家，往后余生大概率没有更多的可能性了。这倒不是大问题。更多时候，人是被琐碎的细节所打倒，比如婚姻、爱情。对我而言，是耐心逐渐消磨殆尽。
Grab 在权限管理上做了很多工作，服务器专门由 DevOps 团队维护，数据库专门由 DBOps 团队维护，架构 Review 专门由 SRE 团队负责，CI/CD 平台由专人开发和维护，普通工程师只负责写代码和单元测试，上线流程有专人把控。你可能会问：每个团队负责一块资源，工具会不会做得特别完美？
事实上，答案是不，几乎没有工具，唯一的工具就是 Jira（提工单 )。
想申请服务器？提 ticket 想申请 MySQL？提 ticket 想申请 Redis？提 ticket 想申请访问另一个服务, 要修改 security group? 提 ticket 想部署升级? 提 ticket 新服务部署一直起不来，想 ssh 上去看看? 提 ticket 申请 VPNbugfix 要紧急上线？先过了单元测试的所有 case 一天想升级两次? 没门想用 Cassandra？别用，这儿没人会 …
重点的重点是提一个 ticket，少则两天，多则一周，别人才会执行，你才会拿到 permission 或者资源；有时候对面和你 argue 了一番，然后拒绝了你。
基础设施相关的团队只是管理基础设施吗？是的，只是管理，自动化工具几乎没有。
要建一个新服务，服务器、MySQL、Redis、Kafka、SQS 等资源申请花费了一个月，代码写了一周，测试、上线、到全量发布又是一个月。
等服务器资源的时间，研究了下 Spark 做推荐系统，本地做完实验要开搞了，Data Science 团队说，这是我们的活，你们停下，直接调用我们的 API。怎么办呢？测试延期两周吧。
等这边上线，放到国内典型互联网公司，都迭代 N 个版本了。
耐心一点一点流失，我一直在想，怎么样才能跳过这些耗时而无用的步骤呢？当然是去 SRE，一个可以操作所有基础设施的部门，一个可以查看任何监控和日志的部门，去以后可以自主立项做一堆自动化工具，团队文化很 open，组成非常国际化，组员也很 nice，还在新加坡！！！
由于之前一直在帮 SRE 做项目，北京这边 leader 也很给力，一个愿放、一个愿收，剩下的问题就是多少钱值得过去。
根据搜刮到的消息和我的心理预期，最后得出一个公司很可能开不到的价格。
我当时还陷入在 BBC 黑帮剧 “Peaky Blinders” 当中，里面最为震撼的一个观点是：当你需要一个物品时，拿另一个别人看来等价的物品来交换。
所以，我需要国内一线大厂的 offer 来做“交换”。我看到了头条和某团这两个新兴巨头。当时坊间传闻头条叫“宇宙条”，某团还不叫“裁团”。
为什么加入字节跳动？
庆幸的是，投递 Go 的职位，“裁团”三面全是 Java，后来换了个岗位也是 Java，没面过（没错，锅是 Java 的）；同样庆幸的是，头条的面试比想像中简单，面过了。
顺便了解了下头条系 app，被它强大的产品研发速度刺激到了；和面试官聊了下业务相关的服务，QPS 30 万，这辈子我还没见过这种服务的代码实现。最终头条发了一个还不错的 offer，虽然待遇不如去新加坡，但是那时的我眼里只有 30 万 QPS。
进入头条以后，我并没有参与到那个 30 万 QPS 的服务当中，但是明白了构建这类服务的通用法则。数个过亿日活的 app 需要强大的基础设施团队和数据团队作支撑。下面是我比较喜欢的几点：
基于容器的私有云平台，申请资源几乎完全自动化。熟练的话，半天就能把一个新服务部署上线
完善的数据仓库、流式计算平台。多种数据源互相导很方便，spark、flink 任务任性跑
OnCall 的回复通常都很及时
周围的人都很聪明。有时候一句话说不完，对面已经懂了
在过去短短三四个月里，能够深度参与三个项目，其中一个已经结束；上线次数至少超过过去一年的总次数，查询 sql 至少超过过去两年的总次数，还把一直想学的函数式编程语言 Scala 用到实际项目中。如果放在之前，这是不敢想象的。
前面我提到过 Grab 的 SRE：直观感受是实现业务的团队负责写代码，几乎没有 SPOF 和稳定性的概念，SRE 负责服务稳定可用。反观头条，周围人在设计一个服务的时候，就在行使一个 owner 的全部责任，降级方案是必然考虑的一个方面。同样的，谁写的这个接口，谁就是 owner，他会自觉担起 稳定性保证、疑难解答和 oncall 的责任。
关于时间，加班也好，单双周也罢，一个全局的时间规划非常重要，因为要做的事情有太多太多，而你需要挤出一定的时间休息和感受生活。
累吗？有时候累，非常累；值得吗？当你和一群聪明人一起解决一个个难题时，当你写的服务被数十万、百万、甚至数亿人使用时，当月末收到银行的转账短信时，当然，值得！
我亲爱的小伙伴，既然看到这儿了，你还在犹豫什么？简历砸过来吧
点击链接查看职位信息：https://job.toutiao.com/2018/…
扫码关注微信公众号“深入 Go 语言”
