在快速发展的软件开发领域，一种全新的软件交付方法，称为“shift down”，已经崭露头角，对传统方式提出了挑战。
将视线从开发人员转向平台的概念为传统方式带来了一个范式转变，重新构想了我们如何优化软件交付流程。“The Modernization Imperative: Shifting left is for suckers. Shift down instead”是一篇很好的文章，它强调了shift down 哲学的相关性和紧迫性。
在 DevOps 团队 shifting down 到平台的新时代，平台工程成为了一个至关重要的课题。它专注于设计和创建简洁的工作流程和工具，让软件团队能够更轻松地构建和部署他们的应用程序。
通过拥抱这一变化，企业可以为其开发团队提供平台作为工具，以确保更高质量、更快速的交付软件。
本文探讨了软件构建和测试的shift left 和 shift right 方法，分析了它们的局限性，并介绍了shifting down如何弥补这些缺陷并为现代软件开发提供更全面的策略。
什么是左移（shift left）？
Larry Smith 在 2001年提出的 "shift left ”概念彻底改变了我们的软件开发方式。这个概念指的是将测试阶段移至软件开发历程的起始阶段，这是一种积极主动的战略方法。其重点是尽早进行软件测试，并在整个开发过程中不断重复这一步骤。这种方法有助于在开发早期发现并解决问题，从而避免了在后期阶段花费更多的时间和资源进行修复。
这种方法的意义在于，它能够在漏洞渗透到整个应用程序之前就发现并解决它们。
确实，shift left方法虽然强调了早期测试，但并不能完全反映实际使用场景和生产环境下的情况。在这种情况下，shift-right testing的重要性就凸显出来了。
了解shift left V Model
它是一种shift left方法，其基础是将测试阶段与每个相应的开发阶段联系起来。V Model是软件工程经典瀑布模型的延伸，只有在前一阶段完成后，下一阶段才会开始。
使用V Model有诸多优点。它是一种自律性很强，将测试阶段与每个相应的开发阶段紧密联系的方法。由于其高度的自律性，使得每个阶段都能在前一个阶段结束时开始，不仅易于使用，而且易于理解。然而，由于其与瀑布模型的相似性，V Model也存在着一些局限性：
- 对于大型项目，V-Model的结构化和相互关联的阶段可能会给测试团队的管理带来负担，导致协调方面的挑战和复杂性增加。
- 客户参与通常更多地集中在V-Model开发过程的后期阶段，这减少了早期反馈的机会，并可能导致与客户期望不一致。
- 该模型本身并不支持快速变更或迭代。
需要更先进的方法，如增量法和基于模型的方法
随着现代应用变得越来越复杂，需要更先进的shift left方法，如增量测试和基于模型的测试方法。
增量测试方法
shift left是一种软件开发流程，它提倡在开发过程中尽早、频繁地对单个组件或单元进行测试。这种方法最适用于复杂系统，并且有助于降低问题在后期阶段逐渐演变成更复杂问题的风险。
基于模型的测试方法
基于模型的左移测试方法有助于减轻需求定义、架构和设计阶段的缺陷。这种方法测试可执行需求、体系结构和设计模型，以消除在这些早期阶段引入的45-65% 的错误。
基于模型的测试方法是左移测试的最新方法，它的主要优势是可以在项目开发周期的早期阶段使用。
什么是右移(shift right)？
“shift right 到生产中测试”的概念为我们处理软件测试和质量保证的方式引入了一种动态转变。与shift left 等只关注生产前测试的传统方法不同，shift right主张将测试阶段扩展到实际生产环境中。这种方法通过在真实条件下进行严格评估来捕捉真实的用户体验。
shift right是指将我们的应用程序部署到实际生产环境中，观察应用程序对用户、数据和环境的响应。通过将我们的应用程序置于真实的用户负载和实际使用场景中，shift right可以让我们获得宝贵的洞察力，了解我们的应用程序是如何运行的、它的响应速度有多快以及它是如何满足用户需求的。
下面是shift right testing的一些显著好处:
- 确定客户流量的实际工作量，并确保软件能够在实时生产环境中处理精确的用户需求和要求。
- 通过 A/B 测试或蓝绿部署确定用户偏好。
- 在生产环境中，及时发现并解决可能升级并影响到更多用户的潜在问题。
平衡shift left和shift right: 应用程序安全的整体方法
尽管shift left方法多年来发挥了重要作用，但过分强调它也可能导致一些问题。由于它无法完全涵盖真实场景和生产环境的复杂性，这种测试误差可能会给开发团队带来压力，使其注意力从开发任务转移到解决后期阶段的问题上。因此，为了确保软件质量，应该更加重视全面的测试方法，包括在开发周期的早期阶段进行测试，以及在更接近生产环境的条件下进行测试。
本节将探讨过度关注shift left可能带来的潜在安全风险，以及结合shift left和shift right对于最大程度地降低安全风险和保障应用程序安全的重要性。
高度关注shift left带来的安全隐患
shift left安全测试只是测试安全性的一部分，并不能提供完整的基础设施安全性保障。
shift left对于开发测试非常有效。然而，当它被应用到已经在环境中使用的应用程序和技术时，它的价值会迅速降低，因此shift right方法显得很重要。shift left效率低下的另一个例子是 API。shift left方法可能需要彻底评估 API 身份验证和授权机制中的潜在漏洞，使 API 容易受到未经授权的访问、数据破坏和恶意攻击。
全面的运行测试策略，正确运用shift right测试，对于降低这些安全风险至关重要。
平衡shift left 和shift right对有效解决安全问题的重要性
过度依赖shift left测试可能导致我们忽略一些在实际生产环境中才会显现出来的安全漏洞；而shift right测试则可以将测试扩展到生产环境中。
shift left测试强调将开发测试纳入软件开发周期，从而将开发和测试紧密结合。另一方面，shift right测试涵盖运行测试。通过融合这些测试策略，安全团队可以构建一个强大的安全体系。
shift left和shift right在微服务体系中的应用
微服务的模块性和互操作性使得大型复杂应用的交付变得频繁，这对左移测试方法提出了挑战。
- 首先，微服务间通常通过应用程序接口（API）进行通信，因此其交互错综复杂。shift left测试难以准确模拟这些服务的动态和互联性质。
- 其次，隔离单个微服务进行测试可能具有挑战性。shift left实践需要有效解决多个服务交互时出现的问题，这些问题可能会导致整个系统出现未被发现的问题。
- 此外，微服务架构涉及许多服务，因此全面测试需要大量资源。
- 最后，shift left可能会遗漏微服务特有的安全漏洞，如服务间数据验证不足、令牌传递问题或访问控制不当。
采用shift right测试确保全面监控和反馈的重要性
在微服务中，shift right和shift left的测试方法是进行全面监测和反馈的重要工具。shift right允许我们在实际生产环境中评估不同微服务的生态系统，提供有价值的洞察，了解这些服务如何相互交互、扩展和响应用户负载。
shift right方法确实通过迭代反馈回路实现了连续改进。这种迭代方法使我们能根据用户反馈和实际生产环境中的数据使用模式，不断改善客户对应用程序的体验。
什么是下移（shift down）？
“shift down“方法是综合了shift left 与shift right 利用现有平台建设全面的软件交付体系，使技术经验较少的人员能够在流程早期解决更多问题。通过此方法，我们充分利用了现有技术，减轻了软件开发人员的认知负担，并将更多的工作量转移至现在使用的平台上。
开发中的“shift down”方法旨在提高效率、降低成本，解放高级开发人员生产力，让他们专注于更复杂、更具创新性的任务。我们可以在不同场景中观察到“向下转移”方法的实例，包括：
- 授权给一级支持工程师解决故障和问题，而不上升到更高级的工程师。
- 自助服务工具和文档允许用户在不联系支持人员的情况下解决问题。
- 压缩技术堆栈和减少开发人员认知负担的优势
- 压缩技术堆栈涉及在开发中战略性地选择和使用一组较小的技术、框架和工具。这种方法旨在降低管理多个依赖项和交互的复杂性，从而简化软件开发人员的开发。
压缩技术堆栈和减少开发人员的认知负担可以带来多种优势，其中包括：
- 减少技术和框架的复杂性：通过使用较少的技术和工具集，开发人员可以更快地掌握并开始项目工作，降低了学习和理解的难度。
- 提升团队协同合作：使用较少的工具和技术，可以减少团队成员之间的学习差距，促进更好的沟通和协作。
- 提高开发效率：减少认知负荷意味着开发人员有更多的时间和资源来专注于开发新项目和实现业务目标，而不是花费大量时间来理解和掌握新的复杂工具。
在软件交付周期中shift down
随着shift down方法将责任转移到底层团队和平台，有助于促进更顺畅的协作、更快地解决问题和更高软件交付效率。
平台工程是指设计和构建工具链和工作流，以便在云原生时代为软件工程提供自助服务功能。除了支持自助服务功能外，在软件交付周期的不同阶段采用平台工程还有其他好处:
- 平台工程通过简化流程和提供用户友好的环境来增强开发者体验；
- 平台工程通过自动化任务和提供标准化工具和流程，帮助提高效率和加速软件交付流水线的开发；
- 标准化过程，也称为黄金路径，确保各个阶段的一致性，从而减少误差，提高质量；
- 平台工程可以降低软件交付成本，提高资源利用效率。
协作和沟通在实现平台工程实践中的重要性
为了有效地实现平台工程，我们需要跨职能的团队协作和沟通，这种协作确保每个团队成员都理解并朝着共同的目标努力。
沟通弥合了团队之间的差距，鼓励不断的反馈、分享见解和最佳实践，提高持续改进、学习和解决问题的能力。
Shifting Down的挑战与缓解策略
本文详细讨论了为什么将工作重心转移到平台或经验较少的团队成员上是对企业来说是正确的举措，但这种转移会面临很多挑战。
- 首先，需要企业内部转变思想，团队必须放弃更多的控制权，协同工作。
- 其次，需要在工具、基础设施和培训方面进行大量投入，以便为经验不足的团队成员提供支持。
应对shifting down的技巧
为了应对shifting down过程中的挑战，企业可以采取一些实用的策略，其中包括：
- 从一个小的项目和团队开始，然后逐步推广这种方法。一下子把整个项目shifting down是很累人的。
- 投入适当的工具和基础设施，支持shiftdown方法。采用自动化和易于使用的自助服务工具，这些工具可以使开发人员在平台工程中适应并茁壮成长。
- 建立一个强大的平台工程师团队，他们对shiftdown到平台有深入的了解。
shifting down到平台而不是shifting left的好处
shifting down到平台可以带来显著的长期收益，这些收益包括：
- 提高软件交付过程的效率:shifting down到平台有助于释放资源和经验丰富的工程师，将重点放在更复杂的任务上，以简化开发、测试和运维流程。并且shifting down到平台可以更快地解决问题，更快地将产品投向市场。
- 提高敏捷性:shifting down到平台更容易部署和调试新组件的功能，从而提高整体代码的质量。
- 降低成本:shifting down到平台可以通过集中基础设施和资源来提高资源使用率，从而降低IT成本。
结论
Shifting down到平台提供了一种变革性的方法，可以优化资源利用率，从而快速跟踪并增强组织的软件交付流水线过程。传统上，企业在软件开发中采用熟悉的左移策略，但是它的局限性促进了shifting down到平台的方法出现。
在平台工程的世界中，组织可以利用现有的平台和工具来设计、构建和部署强大的工具链，这些工具链提供标准化、自动化的流程以及超越复杂技术难题的简化部署方式。
采纳shifting down的策略，与平台工程携手并进，不仅可以确保资源和专业知识的有效利用，而且可以建立一个生态系统，促进持续学习、协作和创新的发展。
热门跟贴