推荐序

2020 年国庆节前，老孟跟我说：“帮我们的书写个序吧！” 我开玩笑说：“你们怎么不找一个更有名气的人来写呢？” 老孟说：“已经找了，但是还是想找你写一个序，因为你更了解我们的日常工作。”

我自己平时很喜欢做总结，也常写专栏文章，深知写一两篇文章容易，要坚持写很多篇，并且汇集成书是很需要毅力的。老孟他们平时的工作强度很大，回家还要照顾孩子，能写成这样的 “大部头” 实属不易。

老孟、小强、文利还有苏菲，在这本书中，把自己这么多年在生产环境摸爬滚打的经验都毫无保留地倾囊分享了。要驾驭eBay 这样规模的生产环境，必须了解技术背后的原理，而不能仅仅停留在操作层面，因此，这本书更多的是帮大家梳理系统设计背后的思考和细节。

想要学习云计算，就要学习很多基础知识，我们部门的新人刚加入的时候都觉得不适应密集型的信息轰炸，我觉得以后我们部门有新人加入时，我会建议他们先读一遍这本书。大家如果经历一两次生产环境的问题，再回来看这本书，估计体会更深。

我真切感到，书里面的知识无论从覆盖面还是深度都超越我们公司内部的文档，看来鼓励大家写书才是推进我们内部文档质量提高的出路啊！

我看这本书的时候仿佛在看回忆录。我记得我们在把 eBay 的 Feature 测试环境从OpenStack 换成Kubernetes 的时候，还顺便换掉了原先的负载均衡系统，上线后出了事故，被 “捅” 到了CTO 那里，老孟他们通过持续努力，好不容易从 “坑里” 爬出来。之后我给老孟团队发了一个奖状，我把奖状交给老孟的时候跟他说，这个奖状外人看上去是个奖状，但是我们自己都知道它是一个提醒，提醒我们从开源系统到生产环境高可用之间还有很长的路要走。老孟一直把这个奖状摆在他桌子的显眼位置。

看到书中介绍Contour 和Istio 的章节，我们部门内部在关于技术选型时选用Contour还是Istio 的激烈争吵历历在目，我们基础架构部全球副总裁为了这个事情，还让老孟写一个详细的分析报告，并且跟副总裁逐一分析技术细节。书中说CGroup 弄得不好，会造成对系统性能的影响，还有内存水位线的介绍、RSS/RPS/RFS 的介绍等，其实我们都是吃过苦头的，内部总结会是在公司3 楼的会议室 “Fencing 和Training Room” 开的，整个会议室坐满了人，一起学习了两个多小时，开完会天都黑了，还是周末，但是我觉得这时间花得值。

Resource Quota 的章节，专门解释了资源横向切分和纵向切分的思考。这次国庆节长假前最后一天，小强还在跟我讨论这个问题，eBay 因为历史原因数据中心资源被割裂成很多孤岛，我跟小强说，他的工作就像一条鲶鱼，迫使整个公司重新审视过去十多年的资源管理方式，eBay 并不做内部部门间的单独财务结算。在这种情况下，我觉得如果真的要在保证资源利用率的前提下，缩短我们交付云计算资源的时间任重而道远。

在看第2 章的时候，我就会想起，周末我去公司，看到文利还在那里思考怎么解决Cassini（eBay 内部的搜索引擎集群）在Kubernetes 上为什么会出现性能问题，一查就是两个月，最后还是被他 “死磕” 着搞定了。

看到介绍Containerd 的章节我就会想起苏菲，我们公司所有Kubernetes 集群替换成Containerd runtime 就是她做的，把NPD 从Daemonset 换成系统服务也是吃了亏后改的……还有很多很多不能在这里一一列举了，书中轻描淡写的一两句话，背后其实有我们很多的思考、教训和尝试。

我们这5 年多来也是起起伏伏，公司做Kubernetes 有一点是一直坚持的，就是要往深里做，把系统为什么这么设计搞清楚。一路的教训让我们非常重视系统上线前的压测和失效分析，而这些无不让我们对系统底层有了更深的认识。

待本书正式发售的时候，我得自己花钱买一本，也摆在我办公桌的显眼位置，因为这记录了我们的成长。我还很期待我们可以再写一本生产环境的 “踩坑实录”。

eBay 基础架构工程部研发总监　 许健

2020 年10 月7 日