EE 团队： Automating Everything！ | PingCAP 招聘季

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 1848 天前的主题，其中的信息可能已经有所发展或是发生改变。

在 PingCAP 成立之初，我们就在思考 TiDB 的核心价值。在存储并处理较大规模的数据时，TiDB 本质上是帮助 DBA 和开发人员提升效率。《资本论》中说道：当个别劳动时间低于社会必要劳动时间时，人们才有钱赚。可见效率即是价值。在 PingCAP 内部，我们信奉效率至上。随着公司的发展和壮大，沟通协作的成本随之升高，在研发、测试、交付，乃至公司运营等各个环节的效率问题随之暴露出来。公司内部网络不稳定时，我们经常调侃：这个网络就是阻碍未来的分布式数据库前进的障碍！我们必须主动的发现日常工作中各种影响效率的问题，然后用最擅长的武器，即手中的代码来一一解决。在 PingCAP，有一支特殊的 Team 肩负着此项重任—— EE (Efficiency Engineering) 效率工程团队，也就是我们今天介绍的主角。

关于 EE 团队

EE 团队致力于提高公司内部的自动化程度，是 PingCAP 中最 Hack 的团队，信仰重复的事情人肉只做一遍，尽最大努力把一切可以 Scaling 的事情都交给工具和各种 bot 来解决。为了能让大家对 EE 团队有更直观的了解，EE 团队小伙伴下面将「现身说法」，分享他们是如何用工程化的手段来解决效率问题的。

工程效率研发工程师职位信息：https://pingcap.com/recruit-cn/engineering/engineering-efficiency-engineer/

@zhouqiang-cl

大家好，我来介绍下 PingCAP 内部的 DevOps 是如何提高研发的效率的。可能各个技术型公司都有自己的一套 DevOps，而且社区的各种轮子也不少。虽然建设一套 DevOps 并不难，但要和公司内部研发流程紧密契合，真正提高研发效率，也不是一件容易的事。不仅需要对开发、对测试、对产品了解的都比较深入，同时需要具备运维的思想和知识体系。接下来我结合实际例子，具体介绍一下。

DevOps 里面很重要的一个是 CI，而 TiDB 的 CI 并不好做。一方面数据库的 test case 比较多，一次代码提交可能会触发跑上千万 test case ；另一方面 TiDB 项目非常活跃，平均每天都有 10-20 多个 PR，而每个 PR 的每次 commit 都要触发 CI。可想而知，如果 CI 跑的比较慢，我们和社区的开发者就会浪费大量的时间在等 CI 跑完，如果跑挂了，fix 之后还要再跑一次。因此我们设定了一个目标，让千万级的分布式数据库 test case 在 3 分钟内跑完。

为了实现这个目标，我们从几个方面来考虑。

首先第一个思想是“拆”。把大的 test case 拆成小的，耗时的拆成多段来跑，然后尽可能的并行跑。一个 pipeline 不行就多个 pipeline，一个 Jenkins master 不够就多个 master。这里不得不提的是 K8s，Jenkins 自身的并发管控能力是有限的，然而 Jenkins 和 K8s 的结合极大的扩展了 Jenkins 的并发能力，利用 K8s 动态创建 Jenkins 的 worker node，使得千万级的测试 case 能够在 3 分钟内跑完。另外一个好处是，对资源使用非常弹性，过了高峰期后对集群资源使用会自动回缩。

第二个思路是对基础设施进行极致的优化。拉代码慢就优化网络、自建 DNS ；编译慢就尽可能将中间结果放到持久化缓存，甚至我们对底层操作系统做定制，选择最优的内核版本；集成测试慢就自建对象存储，减少重复编译的次数。不要小看每一秒钟的优化，因为很可能因为这一秒钟达不到 3 分钟的目标。是的，我们就是这样苛刻的提升效率。

第三个思路，是不是每个代码 commit 都要跑完整的 CI ？显然不是。有时候恰恰开发者不希望跑 CI 或者跑部分的 test。于是我们使用 PR-bot 实现基于 GitHub 的协作，开发者通过在 PR 上回复命令的方式，决定 CI 要怎么跑。bot 还可以帮我们干很多事，比如我们内部项目管理是用 JIRA，而 GitHub 上的 issue 能否自动同步到 JIRA，于是我们开发了一个 bot 专门干这个事情。

其实还有很多的事情，现在还没做或者做的不够好。比如：发版流程自动化，benchmark 自动化，PR-bot 也需要更多的功能，像自动 merge 代码，自动打 label，通过 commit message 控制行为等等。所以希望有想法的小伙伴加入，一起做更酷的事情。

@sykp241095

我在 EE 团队主要负责优化 IDC、网络等基础设施，提升内部资源利用率，以及提高办公自动化水平和团队协作的效率。

在 PingCAP 这样一家极客公司，一群优秀的工程师对基础设施的要求极为苛刻，每天又都会有大量的开发和测试的资源需求找到我们。可能某位同学刚刚优化好的代码，希望立刻找个地方跑一下，而低效繁琐的流程是难以容忍的。另外一方面，如果资源分配出去了，但资源利用率很低，对于一个“处女座”占大多数比例的公司也绝对是难以接受的。

这样想的话，我们是不是要在公司内建一套私有云呢？不，私有云管理太重了。[上篇文章](https://zhuanlan.zhihu.com/p/60095255 ) 介绍过，我们 All in K8s，**我们用 K8s 来管理 IDC 资源。每个 PingCAP 工程师用自己的公司 G Suite 帐号在内网 K8s 进行认证和鉴权，并在属于自己的独立 namespace 下搞事情。同时我们可以统一调配每个人的资源使用限制（ CPU/内存 /磁盘），让大家最大化的利用好这个大池子。**未来我们也会监控大家的使用量，对于用完没有及时释放的资源会通过 Slack 自动发出通知，不过这个目前还没有实现。

对于网络方面的效率优化就不具体展开说了。PingCAP 是个全球化的公司，为了保证和硅谷团队的同事能顺畅的交流和开发协作，我们在基础设施上面的确做了很多工作。如果想了解更多细节，欢迎加入我们（^ ^）

最后聊聊团队协作，实话说这部分做的还不够。虽然我们同时在用多个协作工具，比如 Google G Suite，GitHub，Slack，Trello，Atlassian JIRA & Confluence，但平台之间还没有完全打通，流程还没有串起来。近期计划要做的几件事，譬如：通过 SAML2 进行统一登录认证，点对点 Slack 通知，完善平台之间的数据自动同步等等。

@ethercflow

我是一名 Linux 内核工程师，我的目标是高效精准的定位与内核相关的各种性能和稳定性问题，并开发工具来度量操作系统内部的实时状态，提高排查线上问题的效率。

对于性能分析，已有的一些 Linux 性能分析工具只能给出比较笼统的性能指标（比如 top, pidstat ），或给被分析的服务带来较大的负面性能影响（比如 strace ）等，我们花了大量时间，运行了几组工具后，依然一头雾水的场景并不少见；另一方面，当面对多个内核进程进入了不可中断状态导致服务不可用，或运行一段时间后，内核突然 panic 掉重启了，我们如何从根本上去解决这些问题，并构造类似的可控场景去测试我们分布式系统的稳定性。

为了解决上述问题，我们需要深入研究 Linux 内核，能够动态 hack 内核子系统来提升定位问题的效率，以及给稳定性测试增加错误注入的能力进而提高测试效率。

举个性能分析的例子：如何诊断并修复不稳定的 Kmem Account 问题。

我们的 TiKV 在薛定谔平台上（ K8s 环境）做 OLTP 测试时偶尔会发生 IO 性能抖动，且从服务日志、负载等监控信息看不到任何异常，于是我们将目光转向了 Linux 内核，使用基于 ftrace 的工具，我们抓取到引起性能抖动的内核执行路径，结合出现性能抖动前后 dmesg 出现大量 SLUB: Unable to allocate memory on node -1 信息（而我们系统剩余内存是充足的），我们研究了对应的内核代码，初步验证了延迟的来源，于是我们需要进一步分析 SLUB 分配失败的原因。我们创建 docker 容器时，并没有设置 kmem limit，为什么还会有 kmem 不足的问题呢？为了确定 kmem limit 是否被设置，我们进入了 cgroup memory controller 对容器的 kmem 信息进行查看（执行 cat memory.kmem.slabinfo，未开启 kmem account 会得到 cat: memory.kmem.slabinfo: Input/output error ），发现 kmem 的统计信息被开启了, 但 limit 值设置的非常大。我们已知 kmem account 在 RHEL 3.10 版本内核上是不稳定的，因此怀疑 SLUB 分配失败是由内核 bug 引起的，搜索 kernel patch 信息我们发现确实是内核 bug，在社区高版本内核中已修复：

commit d6e0b7f (slub: make dead caches discard free slabs immediately)

同时还有一个 namespace 泄漏问题也和 kmem account 有关：

commit:73f576c (mm: memcontrol: fix cgroup creation failure after many small jobs)

那么是谁开启了 kmem account 功能呢？我们开发的内核工具捕获到了开启 kmem account 的进程：runc。找到罪魁祸首后，我们从 K8s 代码上发现，K8s 的 runc 项目在 1.9 版本默认开启了 kmem account。定位到问题后，解决方案也就有了，要么 patch 内核，要么从 K8s 入手，为实现最小化改动，我们通过条件编译 runc 修复了这个问题。

类似的问题还有很多，比如当剩余内存不足，产生大量 allocStall 时，如何量化对关键业务的延迟影响，当关键业务执行 fsync 有较大的 stall 时，如何定位 stall 的来源，当多个进程进入不可中断状态时，如何判定是否是读写信号量产生了死锁，如何分析锁未释放的原因等等。

如果你对 x86_64 体系结构和 Linux 内核感兴趣，深入了解过某个内核子系统，欢迎上船。

@cwen0

大家好，最后我来谈谈 EE 团队在提升测试效率方面做的事情。

通常情况下，我们进行一次测试需要做那些工作呢？ Write Case -> Prepare Machines -> Build TiDB Binary -> Deploy TiDB Cluster -> Inject Faults -> Run Test Cases -> Watch Result -> Output Report -> Analysis Result... 想象一下如果我们的每一位工程师每天都在做这些，估计我们自己都会疯掉的。

当看到这些重复而又复杂的手动劳动时候，我们第一反应就是如何“偷懒”，毕竟“偷懒”是我们每一位 EE Team 的小伙伴都应该具备的基本素质嘛。我们思考能不能构建一套自动化测试平台，来提高测试效率，同时提供底层的错误注入能力。因此，诞生了我们的“薛定谔”平台。

**“薛定谔”是基于 Kubernetes 建立的一套自动化测试框架，提供各种 Chaos 能力，**比如干扰 CPU、干扰内存、干扰网络、模拟网络分区、模拟磁盘损坏、模拟节点宕机等等一系列我们在生产环境中可能遇到的错误。同时也提供自动化的 Bench 测试来验证每次代码提交对数据库性能是提升还是下降的影响。此外测试平台还提供各类异常监控、告警以及自动输出测试报告等功能。

目前薛定谔平台正在使用我司 80% 的机器、数十套测试集群 7*24 小时不间断运行着，很大程度上保证了 TiDB 正确性以及稳定性。

薛定谔在 PingCAP 内部使用快将近一年了，TiDB 已修复的缺陷中已经有不少是通过薛定谔平台发现或者帮助复现的。我们还需要考虑如何在有限的资源下应对不断增长的测试需求？同时随着 TiDB 周边组件的不断成熟，测试的对象也会不断丰富，“薛定谔”平台需要承担的测试任务也越来越重。接下来除了要把薛定谔平台做的更稳定易用，我们还打算把底层的 Chaos 这部分的实现独立开源出去，并结合 K8s 提供通用的错误注入能力，希望成为测试分布式系统稳定性的一个通用解决方案。

总而言之，EE 团队致力于用工程的方式解决效率问题，最终的目标是 Automate Everything。

对你的期望

兴趣和野心

希望你热爱技术，对开源、基础架构有兴趣，看到这里面的巨大技术挑战以及广阔前景，希望能为业界带来激动人心的解决方案。同时希望你是一个能自我驱动的人，且能带动周边的人一起来推进，这一点很重要。

技术能力

看到这里，你会知道我们的技能树有好几十米。如果你技术精湛，喜欢紧跟新技术的步伐，涉猎广泛，那就过来一起折腾吧。

沟通能力

目前我们已经有一百多名同事，分散在全球 6 个 Office 或者是远程办公。所以如何高效的沟通，如何能跟上其他同事的思维节奏非常重要。

你会得到的收获

在 PingCAP，我们不设限，工程师可以足够自主的选择所使用的技术和拓展新的方向，公司在很大范围内提供相应的资源及指导。

我们崇尚自由的文化，你可以在这里使用和探索新的语言、工具、方法等等（如 Golang / Rust / K8s / Raft / Chaos / Wperf ）、自由的选择合适的技术和工具来解决问题；我们提供丰富的可供选择的方向（分布式测试平台 / Kernel Debug Toolkit / CI 工具链 / DevOps 各类管理工具等），对个人的职业发展也有足够的好处；另外团队间合作交流足够通畅，可以深入了解各其他团队所使用的技术思想，也常有各种 Meetup 供大家业余充电；就职业发展来说 PingCAP 处于高速发展时期，你可以经历国内稀有的开源公司的整个发展历程和周期。我们公司不仅做开源产品，也可能将各种小工具开源出去，让社区和个人都从中受益。