在当今日益复杂和快速变化的环境中提供更可靠软件的分步指南。
这篇文章基于最近一次与Cloud Native Computing Foundation合作，与OverOps工程团队的Brandon Groves和Ben Morrise合作创建的网络研讨会。
如果您认为向微服务和容器的转变是演变而不是革命，那么您来对地方了！在本文中，我们将对基于Kubernetes的应用程序领域采取务实的方法，并详细介绍一系列步骤，以确保整个管道的可靠性。
因为即使今天确保应用程序质量是过去的两倍，但我们还有很多改进方法。具体来说，在对基于Kuberenetes的应用程序进行故障排除的上下文中，我们将涉及持续可靠性的3个支柱：在CI管道中实现代码质量门，在CD管道中实现可观察性，以及创建上下文反馈循环回开发。
当今软件质量状况
首先，让我们尝试了解发生了什么变化以及为什么需要重新审视代码质量的基础。
就在最近，我们总结了年度 软件质量状况 调查，来自世界各地的开发人员提供了600多个答复。我们今年的目标是找出当今的工程团队如何解决速度与质量的难题。
好消息是，大多数调查参与者（70％）表示 质量至高无上 ，他们会优先考虑速度。不幸的是，受访者每周花费一天或更长时间来排查与代码相关的问题，其中超过50％的受访者每月至少一次遇到影响客户的问题。
尽管本次调查更广泛地关注于交付可靠软件的现实和挑战，但仍有 45％的受访者表示，他们正在以一种或另一种方式采用容器。毫无疑问，容器化的微服务和k8s非常适合大规模交付软件，但它们也带来了新的挑战，需要采取更加结构化的质量方法来应对。挑战如下：
- 管理从单一应用程序到微服务的过渡。
- 协调跨多个服务的部署。
- 编写并运行有效的测试。
- 跨微服务处理多语言编程。
- 跨微服务记录。
- 并通过系统跟踪交易。
因此，到现在为止，当您听到kubernetes或微服务时，您有多害怕或自信？…我们希望不要太多！是时候深入了解我们的清单了。
阶段1：构建和测试
首先，我们认为从基础开始是有意义的。迈克·科恩（Mike Cohn）的测试金字塔快速回顾 ：
在底部附近，我们有单元测试，它非常快速且“便宜”，可以在资源上运行，但它们也非常精细，涵盖了应用程序的较小组件。随着我们不断发展，我们正在进入集成测试和端到端测试，这些测试需要更多的资源，但需要覆盖应用程序的更大区域，并可能涉及具有更复杂事务的多个微服务。在进入构建和测试的第一阶段时，这确实是我们需要考虑的权衡–如何确保我们充分利用时间来发挥最大的影响力？
静态分析
如果您尚未执行此操作，则要查看的第一件事就是将静态分析解决方案作为管道的一部分。顾名思义，静态分析意味着将针对常见错误和安全问题的数据库对代码进行扫描和分析。尽管静态分析依赖于IDE编译器中的相同输入，但静态分析要复杂一些，并考虑了编译器的问题。
此外，静态分析还可以用作整理工具，该工具将检查您的代码是否符合行业标准，并识别“代码气味”和样式问题。
单元测试
正如您在测试金字塔上看到的那样，这些类型的测试运行起来非常快，因为它们专注于较小的代码段，例如单个类或类中的一些方法。
很多人建议在所有代码上至少达到80％或90％的测试覆盖率，但这并不总是正确的做法。仅仅因为您测试了许多getter和setter来增加代码覆盖率，并不意味着您进行了良好的单元测试，因此请确保您在正确的位置测试了正确的事物。
集成和端到端测试
这些测试位于测试金字塔的顶部，涵盖了应用程序的更大部分，但在提出和运行测试方面都占用了更多资源。
开源解决方案可以研究：
- Apache JMeter （测试功能行为和性能），
- SonarQube （静态分析）
- kubectl apply validate -dry-run = client -f example.yaml （验证您的YAML文件）
阶段2：阶段/用户验收测试（UAT）
UAT环境的目标是尽可能地复制生产，以便在执行性能和规模测试时，您可以确信它的行为就像新版本正在生产中运行一样。各种模拟器。
性能/规模测试
专注于后端应用程序，您可以运行许多不同类型的性能测试，其中包括：
- 负载测试。 处理预期的用户负载，确定可能存在性能瓶颈的地方。
- 压力测试。 在处理极端工作负载时，要从规模上确定应用程序的“突破点”。
- 耐力测试。 长时间处理负载。它可能在一开始就表现良好，但是在运行一段时间后，性能可能会下降。
- 峰值测试。 立即处理大量的用户负载高峰。
- 容量测试。确定您的应用程序是否运行良好取决于数据库的填充程度。
- 可伸缩性测试。确定您的应用程序有效扩展以支持增加的用户负载的能力。帮助您有效规划系统容量的增加。
- 混沌工程。帮助增强人们对系统抵御动荡和意外状况的能力的信心。
根据您的特定应用程序和它通常会遇到的问题的类型，从此列表中投资至少几种类型的测试可能很有意义。
分阶段执行决定
在所有这些之后，并根据结果–您必须做出不可行的决定。在这里，您需要再次考虑风险承受能力，并定义您认为关键的问题。
为了帮助您做出这一决定，事实证明，在进行构建和进行测试时，使用仪表板有助于收集和查看指标。这样，您就可以掌握所有可能遇到的问题以及需要改进的地方。不仅通过/失败测试结果，而且还有更复杂的指标。
但是要小心-收集过多的指标并查看过多的仪表板会很快变成一个问题。在信息超载与有效优先级之间存在微妙的平衡，工程团队在进行此练习时需要学习和重新学习。
此外，您需要为回滚策略建立基础。当您确定需要回滚的问题时会发生什么？哪些类型的问题需要回滚，哪些问题可以等待下一个版本？回答这些问题将为该策略奠定基础，在生产之前最好回答这些问题。需要研究的一些开源仪表板包括 Grafana， Kibana 和 Prometheus。
阶段3：生产
Kubernetes的优点之一是您可以让多个团队在应用程序中的不同模块上工作。这些模块可以按自己的时间表分别开发和部署，也可以一起开发和部署，并且有多种方法可以解决此过程中的潜在问题，以防止影响客户的问题。
带我们去…
生成部署
Kubernetes的默认方法是进行滚动更新，这意味着使用新代码对Pod进行增量更新，直到完成发布为止。另一种方法是使用金丝雀部署作为渐进式交付机制。向一小部分用户发布更新，然后再介绍给所有人。一些常见的策略是将这些功能发布给随机子集，人口子集或仅内部用户。虽然金丝雀部署可以完全在Kubernetes里面完成，它更容易与像服务网状网络解决方案来实现他们 Istio ，可以调节路由。像Spinnaker这样的CI/CD解决方案也 提供类似的canary功能
推出的一个关键因素是时间安排–如果我知道一天当中有很多流量，那我可能不应该在那个时候发布。如果将要发生停机，最好找到一个不会影响用户的时间。我们一直试图避免的可能性。作为推出策略的一部分，您还想确保更新按照正确的顺序进行，以确保API不会突然破坏兼容性。
生产反馈循环
最重要的是–我们要确保开发人员可以轻松访问有关应用程序行为的所有数据。无论是在测试，分阶段还是生产中，都可以使用提供可见性并与问题跟踪和事件管理软件集成的多种工具来实现此反馈循环。解决性能监控，跟踪和日志记录的工具。
持续可靠性的好处
在理想的情况下，遵循此清单的工程团队将不必再担心生产错误。不幸的是，事实并非如此，投资于上述所有领域的公司仍然遇到问题。
这正是连续可靠性愿景的代名词，解决了测试，登台和生产中的空白。通过一种新技术来实现连续可靠性，该新技术可在运行时分析代码，从而为工程团队提供应用程序错误分析，使他们能够识别，预防和解决关键的运行时错误。简而言之，它使您能够选择在代码被测试执行或在生产中运行时发生的新错误和严重错误，并获得修复它们所需的完整上下文：