混沌工程的入门
主要在生产环境中故意破坏东西是混乱工程中的一个咒语。但是当你把你的计划告诉你的工程经理或产品负责人时，你往往会得到一些阻力。他们的担心是有道理的。如果破坏东西是不可逆的呢？终端用户会发生什么？我们的支持票系统会不会变得很忙？这篇文章将帮助你消除这些顾虑，并在你的组织中开始使用混沌工程。
什么是混沌工程？
关于混沌工程，业界领袖有多种定义。
开始
混沌实验的目的是了解我们的系统在生产中出现灾难性故障时将如何表现，以及我们的系统的弹性如何。这给了我们一个优化和修复问题的机会。
下面是你如何开始你的混沌工程实践。
从你的经理那里获得购买力
第一步是得到你的经理的批准，在测试环境中进行实验。通常情况下，混沌实验应该在生产环境中进行–但我建议你采取小步骤。你可以在任何有效的环境中进行混沌实验。如果生产环境不可用，我建议在非生产（或阶段）环境中运行实验。
解释一下你通过执行混沌实验带来的价值，比如说:
识别故障和瓶颈
弹性验证
规模化验证
理解架构
系统一直在失败。在运行混沌实验之前，彻底了解你的系统架构。与你的开发人员、架构师和SREs进行一次工作会议，对应用架构进行头脑风暴。确保每个人都了解上游/下游组件、依赖关系、时间线、游戏日时间表等。这将有助于你更好地了解你的系统可能出现故障的地方。
撰写假设
开始写一个假设列表，例如，给定一个Kubernetes部署，删除一个pod不应该增加典型负载下的服务响应时间。另一个例子：负载均衡器必须只将请求路由到健康和运行的节点上。编写假设时没有对错之分。这是一个迭代的过程。我们的目标不是让我们的假说 “通过 “或 “失败”。测试每个假设将使我们有机会了解我们的系统。
尽量减少爆炸半径
总是从小处着手。在运行混沌实验时，通过最小化爆炸半径来减少对终端用户的影响，例如，不要删除Kubernetes集群中的部署，而是删除pods并验证弹性。即使你要删除一个部署，也要确保GitOps是有效的，这样GitOps流程会自动创建一个部署。另一个例子：与其关闭集群中的所有节点，不如去关闭50%的运行节点，或者与其关闭整个区域的电源，不如关闭一个区域。 一旦混乱过程成熟，你的团队处于一个舒适的区域，你可以慢慢增加爆炸半径。
为游戏日做计划
未雨绸缪，始终为你的 “游戏日 “准备一个B计划。至少在一周前通知你的所有利益相关者，并在Slack（或你公司的协作平台）中启动一个统一的沟通渠道，定期发布更新。我建议在你进行第一次实验时，让你的开发人员或你的DevOps或SRE团队待命。
运行你的第一个实验
没有人是完美的。如果你在运行你的第一个实验时遇到困难，那也没关系。及时发布更新并通知所有的利益相关者。运行第一个混乱的实验就像乘坐高难度的过山车。如果情况不妙，确保你能够停止实验，并在DevOps或SRE团队的帮助下恢复基础设施。 在实验过程中，监控你的可观察性仪表盘，观察响应时间、磁盘利用率、通过/失败的事务、健康检查等重要因素。
分析
一旦实验完成，在电子表格中记录你所有的观察结果，分析它们，并定义你的假设判决。同样，没有通过或失败；这都是学习。
集思广益
与你的开发人员、架构师和DevOps/SRE团队安排一次会议，讨论你的结论。这将有助于团队理解判决并解决你发现的问题。一旦问题得到解决，你就可以重新进行实验了。如果你发现系统是有弹性的，你可以尝试增加爆炸半径并重新进行实验。
接下来的步骤
在运行各种游戏日之后，你可以了解到团队动态、系统性能等。下一步是将混沌实验嵌入到你的开发者工作流程中，这样混沌实验就会自动化，这将给你的团队带来更多的信心。
今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管理，团队建设 有参考作用 , 您可能感兴趣的文章:
如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：
Original: https://www.cnblogs.com/wintersun/p/16704296.html
Author: PetterLiu
Title: 混沌工程的入门
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/565668/
转载文章受原作者版权保护。转载请注明原作者出处！