确保在线游戏安全:将混沌工程与DevOps实践相结合

作者:吴昭军(腾讯互动娱乐集团高级DevOps工程师)

Transcreator:Yajing王；编辑器:汤姆政府高级官员

互动娱乐集团(IEG)是腾讯控股的一个部门，专注于在线视频游戏和直播等其他数字内容的开发。它以发行了一些最受欢迎的电子游戏而闻名。

在本文中，我将解释为什么以及如何将混沌工程引入我们的DevOps过程。

我们每天处理超过10,000,000次访问，在高峰时段，我们每秒处理超过1,000,000次查询(QPS)。为了保证玩家有一个有趣和吸引人的体验，我们推出各种日常或季节性的游戏活动。有时，这意味着我们必须每天更新事件代码500次以上。随着用户基数的增长，数据总量迅速增加。目前，这个数字是200tb。我们必须管理大量的用户查询和快速的发布迭代，我们做得很好。

云原生DevOps解决方案将我们的事件操作员从不断增长的在线事件中解放出来。我们开发了一个管道来照顾他们所需的一切，从编写代码到在生产环境中启动事件:一旦检测到新的事件代码，运营平台就会自动从它们构建图像，并将图像部署到腾讯Kubernetes Engine (TKE)。您可能想知道整个自动化过程需要多长时间:只有5分钟。

目前，几乎所有的IEG运营服务都在TKE运行。由于采用了云原生技术，弹性扩展有望更快地扩展和减少云服务。

此外，我们期望迭代更容易。最佳实践是将难以维护的大型服务分解为许多可以独立维护的“较小”服务。“小”服务的代码更少，逻辑更简单，移交和培训成本更低。作为开发人员，我们继续将这种微服务架构作为DevOps计划的一部分进行实践。然而类似的问题依然存在。随着服务数量的增加，在它们之间进行调用的复杂性也在增加。更糟糕的是，如果一个“小”服务失败，可能会引发连锁反应，导致所有服务都瘫痪——这是微服务依赖关系的地狱。

问题是，容错能力因服务而异。一些人支持降级，而另一些人则不支持。更不用说一些服务无法提供及时的警报或缺乏有效的调试工具。因此，调试服务已经成为我们日常工作中一个棘手且日益紧迫的问题。

但我们不能放任不管。如果不稳定的表现不断地将玩家赶走该怎么办?如果出现灾难性的故障怎么办?

让我们有缺点

Netflix引入了混沌工程的概念。该方法通过在非生产环境中注入故障来测试系统对各种尖锐情况的恢复能力，以达到理想的系统可靠性。根据高德纳的一篇文章到2023年，40%的组织将使用混沌工程来实现其顶级DevOps目标，将计划外停机时间减少20%。

这正是我们避免最坏情况的方法。在我看来，故障注入现在是每个技术团队必须做的事情。在我们早期的测试用例中，开发人员会在启动服务之前关闭一个节点，以查看主节点是否自动切换到辅助节点，以及灾难恢复是否有效。

但是混沌工程不仅仅是故障注入。这是一个不断推动新技术、专业测试工具和坚实理论的领域。这就是我们继续探索它的原因。

一年前，IEG正式启动了其混沌工程项目。我们一开始就想把事情做好。关键是选择一个支持在Kubernetes环境中运行实验的混沌工程工具。经过仔细的比较，我们相信混乱的网是我们最好的选择因为:

• 它是一个具有友好和高效社区的云原生计算基金会(CNCF)沙盒项目(编辑:已于2022年2月接受CNCF孵化项目)。
• 它不会侵入现有的应用程序。
• 它提供了web UI和各种故障注入类型，如下图所示。

注意:这个比较已经过时了，只是为了将混沌网格支持的故障注入特性与其他知名的混沌工程平台进行比较。它不打算偏袒或将一个项目置于另一个之上。欢迎任何更正。

建立一个混沌测试平台

我们的混沌工程团队将混沌网格嵌入到我们的持续集成和持续交付管道中。如下图所示，Chaos Mesh现在在我们的运营平台中扮演着重要的角色。我们使用Chaos Mesh的仪表盘API来创建、运行和删除混沌实验，并在我们自己的平台上监控它们。我们可以模拟Pods、容器、网络和IO中的基本系统级故障。

在IEG,混沌工程通常被总结为一个具有几个关键阶段的闭环：

1. 提高整个系统的弹性。
   建立一个混沌测试平台，我们可以根据需要进行修改。
2. 设计测试计划。
   测试计划必须指定目标、范围、要注入的故障、监视指标等。确保测试控制良好。
3. 执行混沌实验并回顾结果。
   比较了混沌实验前后系统的性能。
4. 解决可能出现的任何问题。
   修复发现的问题，并为后续实验升级系统。
5. 重复混沌实验并验证性能。
   重复混沌实验，看看系统的性能是否达到预期。如果是，设计另一个测试计划。

我们经常测试高CPU使用率下的服务性能例如。我们从编排和安排实验开始。在此之后，我们运行实验并监控相关服务的性能。多种监控指标，如QPS、延迟、响应成功，都可以通过操作平台立即看到。然后，平台生成报告供我们检查，这样我们就可以检查这些实验是否符合我们的预期。

用例

下面是我们如何在DevOps工作流中使用混沌工程的几个例子。

更细粒度的故障注入

没有必要关闭整个系统来查看我们的游戏是否仍然对玩家可用。有时候我们只是想在一个游戏帐户中注入错误，比如网络延迟，然后观察它的反应。我们现在能够通过劫持流量并在网关上运行实验来实现这种更细的粒度。

红色的合作

可以理解的是，我们的团队成员厌倦了常规的混沌实验。毕竟，这就像让你的左手和右手打架一样。在IEG，我们将一种称为红队的测试实践集成到混沌工程中，以确保我们的系统弹性以有机的方式提高。红队类似于渗透测试，但更有针对性。它需要一组测试人员从局外人的角度模拟真实世界的攻击。如果我负责IT操作，我将模拟特定服务的故障，并检查我的开发人员团队是否做得很好。如果我发现了任何潜在的缺点，好吧，准备好接受一些“严厉的谈话”。另一方面，开发人员会积极地进行混沌实验，确保不留下任何风险，以避免受到指责。

依赖关系分析

管理微服务的依赖关系非常重要。在我们的例子中，非核心服务不能成为核心服务的瓶颈。幸运的是，使用混沌工程，我们可以通过向被调用的服务注入错误并观察主服务受影响的严重程度来运行依赖项分析。根据这些结果，我们可以优化特定场景下的业务调用链。

自动故障检测和诊断

我们也在探索人工智能机器人来帮助我们检测和诊断故障。随着服务变得越来越复杂，出现故障的可能性也在增加。我们的目标是通过生产环境或其他受控环境中的大规模混沌实验来训练故障检测模型。

混沌工程赋予DevOps实践以权力

目前，平均每周有50多人进行混沌实验，运行150多个测试，总共检测到100多个问题。

执行错误注入需要手写脚本的日子已经一去不复返了，对于不熟悉它的人来说，这可能是一件困难的事情。将混沌工程与DevOps实践相结合的好处是显而易见的:在几分钟内，您可以通过简单的拖放来编排各种故障类型，只需单击即可执行，并实时监控结果——所有这些都在一个平台中实现。

多亏了功能全面的混沌工程工具和精简的DevOps流程，我们估计在过去的六个月里，IEG的故障注入和基于混沌的优化的效率至少提高了10倍。如果您不确定在您的业务中实施混沌工程，我希望我们的经验可以提供一些帮助。