关于数据库:我的工作是制造混沌我与-Chaos-Mesh®-的故事

2次阅读

共计 5029 个字符,预计需要花费 13 分钟才能阅读完成。

作者:殷成文,Maintainer of Chaos Mesh

这段时间北京真是冷得可怕,朋友圈晒出各种零下 20 度的照片,在这样一个凛冽的时候,总是想给本人找点和煦的事件去做。这几天闲时就回顾起本人从实习到当初这段时间的经验,前不久是 Chaos Mesh 开源一周年(2020.12.31),于是就将本人与 Chaos Mesh 一起成长的点滴整理出来和大家分享。一方面为了庆贺,另一方面也心愿可能在这个凛冽的冬天给大家带来点和煦。

与 PingCAP 结缘

开始 Chaos Mesh 故事之前,先说点本人和 PingCAP 的故事。

第一次真正接触 PingCAP 是在 2016 年的时候,我加入了一场 PingCAP CTO 黄东旭大佬的技术分享,正好过后在参加一个 Go 语言我的项目,对 Go 语言生态更加关注,对 Go 圈里的明星我的项目 TiDB 更是拜服。本认为这会是一个很有深度的分享,会波及数据库、CAP 定理等等。没想到最初东旭和咱们聊了一个小时的 Unix 哲学,说好的数据库?说好的 CAP 定理呢?置信过后好多小伙伴和我的情绪是一样的——懵逼。但 PingCAP 这个公司却更加吸引我了。

再次接触 PingCAP 是陪同学一起去北京面试的时候,偶尔在 Go 社区看到 PingCAP 的一条实习生招聘信息,一下就被吸引了,在同学的撺掇下就尝试投个简历试一下。当天早晨八点左右,我就接到秋哥 (PingCAP 创始人崔秋) 的电话,说他们正在 TB,在一家烧烤店撸串看足球,问我要不过来聊聊。过后把我惊到了,哪有大早晨约人去烧烤店面试的!到了烧烤店,他们还真是在看足球,我记得过后还是中国队的较量,这场神奇的面试就和这场球赛同步进行着。最初球赛完结,中国队输了,但我收到了个 offer,感激中国队!给了我这次机会!

Chaos Mesh 前世

下面聊了一下我与 PingCAP 结缘的故事,上面就是我与 Chaos Mesh 的故事。

正式来 PingCAP 实习前,我在某个周六的上午去加入了一期 PingCAP 组织的 Meetup。小小的会议室外面挤满了人,大多数人都是站着的。我记得其中一个主题是由 PingCAP 另一位创始人兼 CEO 刘奇带来的《深度摸索分布式系统测试》,奇叔的分享给我留下了粗浅的印象。我第一次晓得测试还能够这样搞,各种故障注入伎俩层出不穷,目标就是为了去虐咱们的零碎。当初想想,当初奇叔分享的不正是混沌工程的思维,同样没有想到的是这个主题会成为我前面一段时间内继续耕耘的事件。

正式开始实习后,我的第一个工作是对 TiDB 进行性能压测。如果只是想简略地跑出一组数字,这就是一个很简略的工作。然而如果须要去找目前集群的性能瓶颈,并找到集群拓扑的优化计划,这个工作就变得不那么简略了。也正是因为这个工作,让我开始学习 TiDB 的架构设计,以及传说中的玄学调参。这里大家可能感觉和我说的和混沌工程无关,其实不然,在混沌工程中,状态查看以及压力模仿是两个必不可少的步骤。同样从这个工作开始,后续我的很多事件都跟测试或者捣蛋无关。

CTO 捣蛋事件

大多数状况下,咱们都心愿零碎环境越稳固越好,然而往往状况并不是如此。为了更好地验证零碎稳定性以及疾速恢复能力,咱们的 CTO 东旭大佬,在咱们的 IDC 业务测试集群搞起了突然袭击。过后是一个十分重要的用户上线前夕,咱们外部有一整套业务测试集群,为了测试零碎的可靠性和故障自恢复能力,东旭大佬深夜连上 TiDB 服务器,间接暴力删除物理文件,重启机器各种骚操作,记得过后还真是把许多研发大佬惊出一身冷汗,还好,最初咱们的零碎抗住了 CTO 的捣蛋。

程序员都是懈怠的,这个事件之后咱们就开始筹划着如何去偷懒,其一是手动试验很难继续,其二是为了更加全面地测试 TiDB,做一个数据库其实不难,然而如何证实一个分布式系统的正确性和健壮性确是一件很有挑战的事件,而且同时要将这个事件做得高效,自动化就是一个更大的挑战,为了保障每次收回去的版本都是通过各种残害的版本。咱们开始了自动化混沌工程之路,Schrödinger 我的项目开始登上舞台。

开始 Schrödinger 之旅

从我的项目名字就能看进去咱们的设计思维:把待测试集群看作盒子中的猫,而后一直给这个盒子减少各种异样,最初测验这只猫的状态。

用技术的语言来说,Schrödinger 的核心思想很简略,应用 K8s 作为底座,将不同的 TiDB 测试集群以及测试用例跑在一个个受控的容器集群中(盒子),而后对底层的容器平台进行谬误注入。

开始 Schrödinger 我的项目还是 2017 年九月份的时候,遇到的第一个挑战就是如何去治理多 TiDB 集群,那时候咱们有两个计划:一是应用曾经比拟成熟的 tidb-ansible 为底座本人去搞个多集群的治理;二是抉择刚刚开始搞没多久的 tidb-operator。在和老大简略沟通后,Schrödinger 就成为了 tidb-operator 的第一个用户,作出这个抉择的次要起因是咱们坚韧不拔的云原生方向。

后 Schrödinger 期间

通过一年多的工夫,Schrödinger 我的项目逐步稳固。同时随着 TiDB 生态的一直成熟,各类周边工具 TiCDC、TiDB Data Migration、TiDB Lightning 等的呈现,测试需要也越来越多。逐步地,咱们发现把这些工具接入 Schrödinger 的艰难越来越大。应该是在 19 年初,在和部门老大一起吃饭的时候,聊起这个事件,过后他提了个想法,倡议咱们能够把故障注入能力独自形象进去,故障定义成 CRD 对象,并应用 controller 的形式去监控治理故障对象。听到这个想法后,我登时感觉一扇新的窗户被关上了。

Chaos Mesh 这一年

2019 年九月份提交了 Chaos Mesh 早退半年的第一个 Commit。可能和很多我的项目一样,Chaos Mesh 第一个 Commit 只有一行,初始化 README 文件。

经验了一个月的开发,Chaos Mesh 终于具备了最根本的性能,这个时候也迎来了 Chaos Mesh 的第二位开发者可奥同学,过后可奥同学还是实习生,可是战斗力十足。在后续的一个月里,可奥同学推动应用 Kubebuilder 替换之前原生的 controller, 进一步优化了 Chaos Mesh 中多 controller 的逻辑,进一步拥抱生态。看到本人写的代码逐步被优化掉,刚开始还真是有点不舍。

开源之路

通过三个多月的密集开发,期间将很多混沌测试胜利迁徙到 Chaos Mesh 后,咱们决定在年底把这个工具开源进来。心愿这个工具可能帮忙到有需要的小伙伴,也心愿可能借助社区的力量更好地推动 Chaos Mesh 倒退。

开源前的几天,是咱们几个人 (我,强哥,可奥) 最忙的时候:测试、文档、视频、文章齐头并进。有些小伙伴可能感觉开源不就是把源码公开就能够了吗?然而从咱们以往的教训来看,一个好的开源工具,只开放源码远远不够,想要用户释怀疾速地应用,必要的测试,入门教程,原理介绍这些都必不可少,欠缺的文档更是尤为重要。

实现一个性能往往很简略,然而想要用户释怀疾速地应用,则须要破费更多的精力。有时候,咱们常常看到某某用户在应用某些开源工具时,会经验踩坑到弃坑,剖析其中起因,往往归纳于文档的缺失,如果这样的用户多了,那这个工具将最终被社区所摈弃。为了可能分享给大家一个开源即可用的工具,咱们在开源前这几天始终致力查漏补缺,一直测试,欠缺文档。致力总是会有播种,终于,咱们在 2019 的最初一天顺利开源了 Chaos Mesh。

Chaos Mesh 开源音讯公布的当天,间接登上了 Hacker News 首页,前面间断几天还登顶 Github Go 语言 Treding 我的项目榜首。Chaos Mesh 的火爆出乎了我的预料,然而开心的同时也多了些压力。

退出 CNCF

云原生从 Chaos Mesh 创建之初就写在我的项目的基因里,成为云原生混沌事实标准始终是咱们坚韧不拔的指标。为了更好地实现咱们的指标,让更多的人,乃至全世界的人都能够享受到 Chaos Mesh 的红利,依据之前 TiKV 我的项目托管到 CNCF 后疾速倒退的教训,Chaos Mesh 开源后,咱们就开始摸索把 Chaos Mesh 托管到 CNCF。

通过调研,CNCF 生态中刚好短少一个推动混沌工程规范的我的项目,这更加动摇了咱们把 Chaos Mesh 托管到 CNCF 的信心。这里不得不说的是 PingCAP 的理想主义和动摇的全球化策略,让咱们在做任何我的项目的时候,都是毫无保留,思考的不再是简略的某几个人,而是整个生态,整个世界。这进一步动摇了咱们把 Chaos Mesh 去和全世界分享的信心,CNCF 正是一个最佳的抉择与平台。在短暂筹备后,咱们就开始了这段漫长的托管申请之路。

在申请期间,也产生了很多故事,惊险一直。期间,CNCF 批改了抉择 Sandbox 我的项目的规定,间接导致咱们的申请被延期,甚至还呈现了一家和 Chaos Mesh 同名的公司,这些意外都一度让咱们缓和。同时,为了更好地适应社区倒退,咱们构建了更加欠缺的自动测试流程,建设了 Chaos Mesh 的官方网站,减少了开发者领导等等,为 Chaos Mesh 社区之后的倒退打下来松软的根底。最终在 2020 年七月的 CNCF TOC 会议上,Chaos Mesh 成为 Sandbox 我的项目的提案通过了。

退出 CNCF 是 Chaos Mesh 在过来一年里的重要里程碑,这对我集体也产生了深远的影响:第一次进行英文分享,第一次和大家一起组织社区会议,同时我对 Chaos Mesh 我的项目的指标也有了全新的意识和想法。

角色转变

随着 Chaos Mesh 我的项目的成长,小小的团队也慢慢扩充起来,一直有新的力量退出咱们:有了业余的前端工程师,有了更多有教训的小伙伴,同时咱们的社区开始茁壮成长。还记得最后咱们开发新性能的时候,就是感觉这个需要有情理,那就开始搞。当初发现,当初的模式尽管效率高,然而不足思考,往往会实现一些没有理论用处的性能。社区的倒退推动咱们必须转换本人的角色,因为 Chaos Mesh 我的项目不再是几个人的我的项目,而是一个社区化的我的项目,咱们也只是社区中的一般一员。同时,Chaos Mesh 也逐步建设起了用户群体,咱们每一个 PR 都要对社区和用户负责。为此咱们创立了 RFCs 仓库,用来收集和探讨 Chaos Mesh 的需要和设计。如此一来,既保证了咱们的设计都通过社区的探讨和认可,也在肯定水平上可能吸引更多小伙伴一起帮忙 Chaos Mesh 我的项目成长。

咱们始终置信一个优良的开源我的项目,一个人或者几个人的力量是远远不够的,为了吸引更多的小伙伴退出到 Chaos Mesh 我的项目中,让更多人可能参加进来,Chaos Mesh 为之做了更多工作和致力。

除了 RFCs 仓库以外,咱们对 Issue 进行了更多的分类,把遇到的问题和发版打算都通过 Issues 公开,对于刚接触 Choas Mesh 的小伙伴,带有“good first issue”标签的 Issues 是一个好的开始,如果有想要在咱们后续的版本中退出某些性能,能够在咱们的 Release Issues 留下评论,一起探讨。除此之外,咱们提供了欠缺的开发者文档,帮忙开发者疾速开始 Chaos Mesh 的开发之旅。当然如果想好和咱们进行进一步交换沟通,能够退出到 CNCF Slack 并搜寻 #project-chaos-mesh channel,参加到咱们的探讨中来。另外,咱们在每个月的最初一个星期四早晨定期举办社区会议,一起探讨 Chaos Mesh 的问题以及后续打算,并且会定期邀请社区的小伙伴一起分享本人的 Chaos Mesh 经验。期待更多小伙伴退出咱们,一起打造更加凋谢、敌对的 Chaos Mesh 社区!

这里我就不多分享 Chaos Mesh 我的项目自身的成长了,如果有趣味,能够期待前面咱们对 Chaos Mesh 的一周年总结。

最初

从 2016 年底到当初,意外地退出 PingCAP,意外地与混沌工程结缘。在这四年里本人见证了混沌工程在 PingCAP 的摸索和利用,也随同着 Chaos Mesh 从 idea 阶段到落地实现。其实下面的经验算不上轰轰烈烈,只是在这个一周年的非凡时刻,本人的一点小矫情罢了。
工夫在持续,我和 Chaos Mesh 的故事也才刚刚开始。在接下来的日子里,挑战不止,精彩有限存在!我将与社区一起致力,将 Chaos Mesh 打造成为真正的混沌工程规范!Chaos Mesh,将来可期!

最初附上 Chaos Mesh 社区考察链接,填写有惊喜哦:https://bit.ly/2LzES5o

正文完
 0