文档更改4.高速IT技术

由 superadmin 于 2024/04/03, 17:15 最后修改

从版本< 13.1 >

由superadmin编辑
在2021/12/11, 22:56上

到版本

由superadmin编辑
在2021/12/11, 23:00上

< >

修改评论该版本没有评论

Raw
已渲染

Summary

Page properties (1 modified, 0 added, 0 removed)
Attachments (0 modified, 2 added, 0 removed)
- 1639234626691-221.png
- 1639234708265-714.png

Details

Page properties

Content

@@ -37,7
          +37,6 @@
  * 产品或服务所有权
  * A / B测试
--
  **ITIL故事：有价值的投资技术**
  //Marco：我们的业务策略是通过对技术的明智投资来实现的。因为我们使用敏捷的工作技术，所以我们可以保证我们的功效：我们的代码将始终有效。我们会监控投资情况，以确保我们明智地花钱，并确保应用程序的功能符合客户的需求。//
@@ -96,7
          +96,6 @@
  |服务财务管理|(% style="width:536px" %)计算时间值概要文件数据，以提供用于确定服务产品优先级的信息。|(% style="width:95px" %)M
  |服务请求管理|(% style="width:536px" %)计算和比较执行或延迟执行请求的财务影响，以便优先安排具有最高收益的工作。|(% style="width:95px" %)L
--
  **ITIL故事：优先排序技术**
  //Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
@@ -174,7
          +174,6 @@
  |服务连续性管理|(% style="width:575px" %)设计和建立连续性计划以支持最低限度的可行产品或服务。|(% style="width:87px" %)M
  |供应商管理|(% style="width:575px" %)合作伙伴和供应商提供产品和服务时，使用最小可用方法阐明所需的输出。|(% style="width:87px" %)M
--
  **ITIL的故事：最小可用产品和服务**
  //Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
@@ -228,7
          +228,6 @@
  |风险管理|(% style="width:566px" %)产品和服务所有者参与阐明和减轻企业风险。|(% style="width:63px" %)M
  |供应商管理|(% style="width:566px" %)产品和服务所有者及管理人员参与阐明需求，组织互动以及与合作伙伴和供应商进行谈判。|(% style="width:63px" %)M
--
  **ITIL故事：产品或服务所有权**
  //Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
@@ -278,7
          +278,6 @@
  |问题管理|在进行进一步投资之前，使用A / B测试方法确定规避措施和错误控制方法的有效性。|M
  |服务验证与测试|使用A / B测试方法定义和执行服务、验证和产品测试活动。|M
--
  **ITIL的故事：A / B测试**
  //Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
@@ -326,7
          +326,6 @@
  * 连续测试
  * 看板
--
  **ITIL故事：快速研发的技术**
  //Solmaz：我们不断开发新的应用功能，并定期且频繁地发布改进和变更。这有助于我们更早地实现价值并尽快收到反馈。它还使我们能够优先考虑开发的新功能和支持工作。因为变更很小，所以它们需要较少的支持，并且服务中断的风险也较少。//
@@ -405,7
          +405,6 @@
  * 它效率更高，导致重新设计和开发产品或服务所需的工作更少。
  * 它使从专注于组件的团队结构切换为基于产品或功能的团队结构。图4.8显示了松散耦合信息系统架构对服务价值链的贡献。表4.6概述了与松散耦合信息系统架构相关的实践。
--
  **ITIL故事：松耦合信息系统架构**
  //Su：我们在应用程序中使用了松耦合信息系统架构。通过将系统视为相对较小且独立的组件，每个组件上的团队可以独立工作，因为他们了解组件会接收的输入以及工作流中后续组件所需的输出。这减少了不同组件之间的重复、复杂性和相互依赖性//该应用程序。
@@ -436,7
          +436,6 @@
  |(% style="width:108px" %)供应商管理|(% style="width:520px" %)当某些组件松散时，建立合同并管理绩效。耦合体系结构由供应商或外部服务提供商提供。|(% style="width:87px" %)M
  |(% style="width:108px" %)战略管理|(% style="width:520px" %)由于投资的原因，将紧密耦合的体系结构去耦是一项战略级决策必要条件以及利用它的潜在运营模式含义（例如引入自治团队）。 这种架构的一个例子是面向服务的可以将第三方服务作为端到端服务的一部分的体系结构。|(% style="width:87px" %)L
--
  === 4.2.3 复查 ===
  通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
@@ -446,4
          +446,250 @@
  在敏捷中，回顾是在迭代（或称为“ 冲刺”）或项目结束时召开的团队会议，以讨论哪些进展顺利，哪些可以改进的方面以及将来如何从中受益。这种快速而频繁的反馈有助于快速研发。回顾可以应用于大多数场景以及需要不断改进的任何区域。为有效起见，应定期安排他们的时间，并由主持人安排参与者的贡献。应确定为持续改进而输入的行动，并委派责任。图4.9显示了回顾对服务价值链的贡献。
++
++(% style="text-align:center" %)
++[[image:1639234467928-357.png]]
++
++图4.9 回顾对服务价值链贡献的热图
++
++
++表4.7 与回顾相关的实践
++
++(% style="width:965px" %)
++|**ITIL管理实践**|(% style="width:722px" %)**与回顾相关的活动/资源**|(% style="width:77px" %)**影响**
++|持续改进|(% style="width:722px" %)定期或在完成时审查持续改进计划的活动和技术，以了解是否正在实现预期的成果。|(% style="width:77px" %)H
++|项目管理|(% style="width:722px" %)审查项目工作并汲取经验教训的活动和技术，可以使未来的类似项目受益。|(% style="width:77px" %)H
++|服务级别管理|(% style="width:722px" %)定期检查和修改服务水平（以了解如何改进）的活动和技术。|(% style="width:77px" %)H
++|软件开发管理|(% style="width:722px" %)定期审查工作以了解如何改进的活动和技术。|(% style="width:77px" %)H
++|变更控制|(% style="width:722px" %)定期审查进行变更的有效性和效率以了解如何改进的活动和技术（包括有关创建或暂停标准变更模型的决定）。|(% style="width:77px" %)M
++|事件管理|(% style="width:722px" %)定期或在重大事件后回顾事件管理工作的活动和技术，以了解如何改进。|(% style="width:77px" %)M
++|问题管理|(% style="width:722px" %)定期检查问题和错误控制以了解如何改进的活动和技术。|(% style="width:77px" %)M
++|关系管理|(% style="width:722px" %)定期审查与各种利益干系人之间现有关系的状态和方向的活动和技术。|(% style="width:77px" %)M
++|风险管理|(% style="width:722px" %)定期或在触发缓解措施后审查缓解风险的活动和技术，以了解如何提高风险。|(% style="width:77px" %)M
++|服务连续性管理|(% style="width:722px" %)从灾难恢复后，审查连续性计划的效率和有效性的活动和技术。|(% style="width:77px" %)M
++|服务台|(% style="width:722px" %)定期检查服务台交互的活动和技术，以了解如何改进。|(% style="width:77px" %)M
++|供应商管理|(% style="width:722px" %)定期审查与各种合作伙伴和供应商之间现有关系的状态和方向的活动和技巧。|(% style="width:77px" %)M
++
++表4.7概述了与回顾相关的实践。
++
++
++==== 4.2.3.2 免责的事后反思 ====
++
++数字化技术具有越来越重要的社会和经济后果，尤其是在HVIT环境中。因此，预防事故变得越来越重要。但是，复杂的系统具有固有的危险性：尽管付出了所有努力，但它们仍将失败。因此，从失效中学习也变得越来越重要。
++
++事后检验是事件的正式记录，包括对事件的影响，解决/缓解工作，原因和防止再次发生的措施。当参与者能够分享自己的知识和选择而不必担心声誉和位置时，事后反思的质量会更好。这就是为什么重点关注事件的原因而不是谁引起了事件。这种免责的文化起源于医疗保健和航空业，那里生命受到威胁。免责事后反思与安全性文化和心理安全性密切相关（见第3.2.2.2节）。
++
++
++**定义：事后反思**
++
++对事件之前的情况和事件的非判断性描述和分析。
++
++事后反思不仅对事件涉及的人员有用，还应与可能从结果中受益的其他人共享和阅读。与透明度和脆弱性建立信任并帮助价值共创，与包括消费者在内的广大社区分享研究结果也很重要。
++
++与事后反思相关的良好行为包括：
++
++* 作为'日常业务'的一部分进行事后反思的操作，并非例外
++* 关注于引起事件的原因，而不是谁
++* 广泛透明地共享结果，以学习和建立信任。
++
++图4.10显示了免责事后反思对服务价值链的贡献。表4.8概述了与免责的事后反思相关的实践。
++
++
++(% style="text-align:center" %)
++[[image:1639234516010-953.png]]
++
++图4.10 免责的事后反思对服务价值链的贡献的热图
++
++
++**ITIL的故事：评论**
++
++//Marco：使用该应用程序可能会很艰苦，但是回顾会给我们带来好处。我们会定期分析完成的工作，以便了解可以在下一个冲刺中汲取的经验教训。这些是不责怪的事后反思：我们公开且诚实地讨论我们的工作，而不必担心事件的起因会分配给任何团队成员。//
++
++
++表4.8 免责的时候反思的实践
++
++(% style="width:920px" %)
++|**ITIL管理实践**|(% style="width:701px" %)**与无指责相关的活动/资源**|(% style="width:80px" %)**影响**
++|变更控制|(% style="width:701px" %)调查成功和失败的变更，以发现机会，以提高未来变更的成功率。|(% style="width:80px" %)H
++|部署管理|(% style="width:701px" %)调查服务组件的成功和失败部署，以发现机会，以提高未来部署的成功率。|(% style="width:80px" %)H
++|事件管理|(% style="width:701px" %)调查事件管理（和重大事件管理）活动，以发现改进的机会。|(% style="width:80px" %)H
++|问题管理|(% style="width:701px" %)调整领导方式以检查系统而不是人员。事后回顾可以帮助组织获得有关事件情况的更多信息。这为问题识别和调查提供了更好的信息。|(% style="width:80px" %)H
++|项目管理|(% style="width:701px" %)调查项目活动，以吸取经验教训和改进未来项目的机会。|(% style="width:80px" %)H
++|发布管理|(% style="width:701px" %)调查服务的成功和失败版本，以发现提高未来版本成功率的机会。|(% style="width:80px" %)H
++|持续改进|(% style="width:701px" %)(((
++调查持续改进活动，以识别经验教训，了解系统中的变更以及确定增加或保持未来改进成
++
++功的机会。
++)))|(% style="width:80px" %)M
++|信息安全管理|(% style="width:701px" %)获取有关与安全漏洞和安全事件有关的情况的更多信息。|(% style="width:80px" %)M
++|风险管理|(% style="width:701px" %)触发风险缓解措施后，评估其风险，以了解如何改进缓解措施以及对当前和未来风险的应对措施。修改风险记录并探索可能的风险的新领域。|(% style="width:80px" %)M
++|服务台|(% style="width:701px" %)调查与外部利益干系人的互动，以发现改进互动和持续沟通的机会。|(% style="width:80px" %)M
++|服务验证与测试|(% style="width:701px" %)调查成功和失败的验证和测试活动，以发现提高未来成功率的机会。|(% style="width:80px" %)M
++|软件开发管理|(% style="width:701px" %)(((
++从回顾中获取经验教训和改进思路。
++
++让合作伙伴和供应商收集反馈以进行学习注册。
++)))|(% style="width:80px" %)M
++
++=== 4.2.4 持续业务分析 ===
++
++瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。
++
++做出投资决定后，至关重要的是要验证对产品或服务规范、特性和功能所做的任何初始假设。一些供应商忽略了与真实用户尽快进行交互的需要，而是在向客户和用户展示其解决方案之前在开发上花费了几个月甚至几年的时间。通常，采用这种方法时，产品或服务的某些功能是不必要的，某些功能需要进行重大调整，而其他有价值的功能却会丢失。但是，组织的资源和时间已经用完，营销机会正在减少。
++
++一种更好的开发方法是尽早实现反馈循环。正确的反馈循环可以提供有关产品或服务开发方向的有价值的信息。为了使反馈循环有用，迭代开发非常重要。为此可以使用最小可用方法（请参阅第4.1.2节）。图4.11说明了这一概念。
++
++
++(% style="text-align:center" %)
++[[image:1639234557151-851.png]]
++
++图4.11通过迭代方法更快地实现价值
++
++
++过去，需求总是在项目开始时在利益干系人和被分配了临时的、基于项目的任务的业务分析人员之间的正式讨论中定义的。这些要求将成为发展活动的规范。
++
++但是，越来越多地基于反馈来开发和改进产品。反馈可以由用户报告或间接观察。需求分析和说明是持续进行的。业务分析通常不再由专门的业务分析人员执行；它是可以与其他角色组合使用的角色。使用这种方法时，由于已经建立了产品架构，因此进一步的开发可能具有挑战性。因此，开发之前的分析应考虑这些未来的问题，并创建一个灵活的架构。开发之后的分析与开发之前的分析不同之处在于，开发后的分析较少关注于创建架构，而更关注于在系统的体系结构约束下有效地工作。
++
++图4.12显示了持续业务分析对服务价值链的贡献。表4.9概述了与持续业务分析相关的实践。
++
++
++**ITIL故事：持续业务分析**
++
++//Radhika：ITIL 指导原则对业务中的每个团队都有用。例如，聚焦价值原则可恰好适合业务分析。环境不断变化，开发中的功能优先级可能会变得更高或更低，这取决于价值如何受到影响。例如，影响应用程序使用或数据存储的新法规将自动成为高度优先事项。//
++
++
++(% style="text-align:center" %)
++[[image:1639234577551-314.png]]
++
++图4.12 持续业务分析对服务价值链贡献的热图
++
++
++表4.9 与持续业务分析相关的实践
++
++(% style="width:900px" %)
++|**ITIL管理实践**|(% style="width:682px" %)**与持续业务分析相关的活动/资源**|(% style="width:96px" %)**影响**
++|业务分析|(% style="width:682px" %)持续了解分析客户、市场状况和更广泛的生态系统，以了解他们对组织产品和服务的影响。|(% style="width:96px" %)M
++|基础架构管理|(% style="width:682px" %)持续了解分析客户、状况和更广泛的生态系统，以了解他们对组织的基础架构和平台产品的影响。|(% style="width:96px" %)M
++|组合管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织投资各种产品和服务的方式的影响。监控正在进行的组合投资，以识别价值或验证价值共创。|(% style="width:96px" %)M
++|项目管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统了解它们对组织项目和相关业务案例的影响。|(% style="width:96px" %)M
++|关系管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织与外部利益干系人关系的影响。|(% style="width:96px" %)M
++|风险管理|(% style="width:682px" %)持续分析内部和外部公司风险，以评估和了解其对组织产品和服务的影响，并设计适当的缓解措施和对策。|(% style="width:96px" %)M
++|服务设计|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解其对客户和用户体验组织产品和服务的影响。|(% style="width:96px" %)M
++|软件开发管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织软件产品的影响以及正在进行的软件开发工作的优先级。|(% style="width:96px" %)M
++|战略管理|(% style="width:682px" %)持续监视和评估客户，市场状况以及更广泛的生态系统，以了解其对组织产品和服务的影响，并相应地调整策略。|(% style="width:96px" %)M
++|架构管理|(% style="width:682px" %)持续分析组织内部和外部利益干系人对技术的使用，以了解其对组织的技术，服务和信息体系结构的影响。|(% style="width:96px" %)M
++|知识管理|(% style="width:682px" %)不断了解分析客户，市场状况和更广泛的生态系统，以在相关利益干系人之间建立共识。|(% style="width:96px" %)M
++|服务连续性管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，它们对组织的连续性和灾难恢复措施的影响。|(% style="width:96px" %)M
++|供应商管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以它们对组织与合作伙伴和供应商关系的影响。|(% style="width:96px" %)M
++
++=== 4.2.5 持续集成、持续交付和持续部署 ===
++
++持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。
++
++
++**定义**
++
++* **持续集成 **一种在软件开发环境中集成、构建和测试代码的方法。
++* **持续交付 **一种软件开发的方法，其中可以随时将软件发布到生产环境中。可以进行频繁部署，但是部署的决定要视具体情况而定，通常是因为组织更喜欢较慢的部署速度。
++* **持续部署 **一种软件开发的方法，其中的变更会通过流水线进行，并自动放入生产环境中，从而每天可以进行多个生产部署。持续部署依赖持续交付。
++
++CI / CD有助于快速研发，并且由于部署更可靠，因此有助于弹性运营。
++
++持续集成是每次提交代码时在构建和代码测试过程中实现的自动化，从而导致对版本控制进行变更。持续集成通过将变更合并到集中共享的代码存储库中，在软件开发社区中促进了代码共享的实践。代码提交触发自动构建功能，以从共享的版本控制存储库和构建，测试中提取最新的代码提交，并验证完整的主分支（即主干）。
++
++由于软件开发具有隔离性，因此持续集成已成为一种惯性时间内，因此开发人员需要在变更与开发团队其余代码之间保持恒定的集成点。漫长的等待周期会导致合并冲突，解决路径困难的错误，不同的代码策略以及重复的工作。持续集成的主要目的之一是使主分支免受异常和错误的影响。软件开发团队可以建立分支机构策略，以确保主分支符合某些预先约定和预先授权的质量标准。
++
++持续交付的重点在是构建和测试新版本并将其发布到生产环境的过程。这需要阶段发布环境，阶段发布环境已成为发布流水线的一部分，以自动化基础设施配置和新版本的部署。
++
++持续交付是一种精益实践。其目标是保持无事故的生产环境正常运行。这是通过发现从版本控制存储库中的新代码的可用性到包装管理（用于部署）的最短路径来实现的。
++
++持续交付依赖于部署模型的渐进部署环的概念。第一个部署环通常是组织的内部IT团队或其他相关的内部用户组访问的生产环境中的“ 金丝雀发布”。连续的部署循环欢迎更多的用户。这些后续的部署循环可能需要关键决策者的批准。如果组织使用这些循环进行部署，则通常采用相同的方法进行发布管理。
++
++另一个部署模型使用“ 蓝绿部署”的概念，即现有版本在一个生产环境（称为“蓝色”）中运行，而新的版本部署到相同的“绿色” 环境。通常，负载平衡用于将有限数量的用户重定向到“绿色” 版本。如果出现事件，则可以将流量重新路由到“蓝色” 版本。否则，“绿色” 环境成为默认的，而“蓝色” 环境用于下一个部署。
++
++图4.13显示了CI / CD对服务价值链的贡献。表4.10概述了CI / CD最相关的实践。
++
++
++(% style="text-align:center" %)
++[[image:1639234626691-221.png]]
++
++图4.13 CI/CD对服务价值链贡献的热图
++
++
++表4.10 与CI/CD最相关的实践
++
++(% style="width:852px" %)
++|**ITIL管理实践**|(% style="width:651px" %)**与CI/CD最相关相关的活动/资源**|(% style="width:84px" %)**影响**
++|变更控制|(% style="width:651px" %)可以根据业务需求和期望，使用CI / CD管道来调整组织产品和服务的变化率。|(% style="width:84px" %)H
++|部署管理|(% style="width:651px" %)系统地/自动地将特定版本的软件或软件包安装到预定的环境（集成，用户验收测试，生产）。|(% style="width:84px" %)H
++|基础机构管理|(% style="width:651px" %)将CI / CD技术用于数字基础架构。|(% style="width:84px" %)H
++|发布管理|(% style="width:651px" %)认识到软件的部署和功能的发布通常是有助于计划和管理发布的不同活动。|(% style="width:84px" %)H
++|服务配置管理|(% style="width:651px" %)管理代码存储库和构成CI / CD工具链一部分的相关工具，并不断更新CMDB以反映进行了重大（CI级别）变更的时间。|(% style="width:84px" %)H
++|服务验证与测试|(% style="width:651px" %)开发自动化测试用例以支持持续的集成活动。|(% style="width:84px" %)H
++|软件开发管理|(% style="width:651px" %)使用用于应用程序软件的CI / CD技术。|(% style="width:84px" %)H
++|架构管理|(% style="width:651px" %)设计和改进服务，技术和信息体系结构以利用CI / CD功能。容器化是支持CI / CD的体系结构选择。|(% style="width:84px" %)M
++|信息安全管理|(% style="width:651px" %)通过减少手工工作来确保遵守信息安全合规。通过利用CI / CD工具来增加自动化的规模和范围，可以通过减少手工工作并改进变更的可追溯性来帮助确保遵守信息安全合规。|(% style="width:84px" %)M
++|知识管理|(% style="width:651px" %)不断更新知识库，以确保组织保持对通过CI / CD管道构建和部署的软件的最新了解。|(% style="width:84px" %)M
++|服务连续性管理|(% style="width:651px" %)应该建立CI / CD管道以将软件组件推向连续性和灾难恢复系统。|(% style="width:84px" %)M
++|风险管理|(% style="width:651px" %)通过使用CI / CD自动化减少某些类型的企业风险的影响。|(% style="width:84px" %)L
++
++
++**ITIL故事：持续集成、持续交付和持续部署**
++
++//Marco：我们已经为该应用程序创建了相同的构建、测试和实时环境，这使我们能够不断集成和交付与现有代码库兼容的新代码。因此，我们可以使用已经有效的代码来高度开发该应用程序。我们还减少了由可能导致难以解决的路径的错误引起的事件。//
++
++
++=== 4.2.6 持续测试 ===
++
++软件测试不仅涉及测试已开发的和可运行的软件。测试是应该在整个软件开发生命周期中进行的工作。表4.11概述了不同类型的测试。
++
++
++表4.11 软件测试的类型
++
++(% style="width:813px" %)
++|(% style="width:165px" %)测试思路|(% style="width:646px" %)所有软件都源于一个想法，通常是试图解决问题的尝试。 测试该想法有助于从客户角度（基于需求和需求）和业务角度（基于指标，包括增长，收入，转化和用户基础）确定其质量。
++|(% style="width:165px" %)测试原型|(% style="width:646px" %)原型，例如史诗，用户故事，验收标准，数据流程图和过程流程图，应进行测试。 检查原型内的信息可以帮助识别与风险和变量有关的歧义，假设和信息。 该信息可用作反馈，以帮助审查和改进伪像。
++|(% style="width:165px" %)测试用户体验和用户界面设计|(% style="width:646px" %)原型用于设计活动，编程活动和测试活动。 设计活动产生的设计原型超出了可以测试的范围。 使用相关的原型对界面和体验进行了测试，并且测试结果可能会影响其他原型。
++|(% style="width:165px" %)测试架构和代码设计|(% style="width:646px" %)在设计软件体系结构并讨论如何构建它和新功能时，探索性测试可以增强设计和思想。
++|(% style="width:165px" %)代码测试|(% style="width:646px" %)代码审查是构建高质量产品的重要组成部分。任何人都应该能够阅读该代码并从不同的角度对其进行测试。单元测试可验证软件的每个单元是否都能正常运行。单元测试通常是自动化的。重要的是要注意，这是软件开发生命周期中的第一点，应该有针对性地加以衡量。
++|(% style="width:165px" %)测试操作软件|(% style="width:646px" %)测试操作软件是与测试相关的最常见的活动。开发后，许多敏捷团队都将“测试”作为其工作流中的一种状态。但是，测试不应该成为工作流程中的一种状态。它应该是在软件开发生命周期中进行的一系列结构化活动。
++|(% style="width:165px" %)在不同环境测试|(% style="width:646px" %)当涉及测试环境时，基于风险的方法可能是合适的。有很多风险可以测试。其中一些无法在开发环境中进行测试。对于其他人，则需要严格集成的环境来进行测试。某些风险只能在实际生产环境中进行测试。
++|(% style="width:165px" %)测试发布管道|(% style="width:646px" %)可以测试管道流程，团队通常会隐式地进行测试，以使其管道尽可能高效和快速地进行增强。这需要对管道测试背后的结构有充分的了解。
++|(% style="width:165px" %)生产环境下测试|(% style="width:646px" %)(((
++必须在生产环境中对某些风险进行测试，例如性能风险（尤其是用户负载和用户压力风险），用户接受度测试（用户将其与实际软件一样使用系统）和可观察性风险（以测试有效性、可观察性解决方案和实现）。
++
++在生产中进行测试时，目标应该是最大程度地降低影响客户的测试风险。实现这一目标的策略包括：
++
++● **金丝雀发布 **这项新功能最初是针对少数目标用户发布的，后来逐渐增加到所有用户。
++
++●** 功能开关** 可以将功能隐藏在功能标志的后面，通过打开或关闭该标志可以轻松启用或禁用
++
++该功能。
++
++● **蓝/绿部署 **两个相同的生产环境同时运行（一个“蓝色”和一个“绿色”），只有一个环
++
++境处于活动状态，为所有生产流量提供服务，而另一个用于部署新版本。
++
++● **自动化的回滚策略 **发生事件时，自动化工具可以快速将发行版恢复为先前版本。
++)))
++|(% style="width:165px" %)测试生产环境中的服务|(% style="width:646px" %)为已发布的生产软件实现了许多服务，活动和技术，所有这些都可以进行测试。从服务交付的角度来看，测试流程很重要。 例如，在测试用户是否可以访问支持时，重要的是要问用户获得支持有多容易，用户在软件中在什么情况下做到这一点。
++
++为了实现持续测试，应制定一些原则，包括：
++
++* 测试应该以最低级别进行。
++* 外部依存关系最少的测试应该受到青睐。
++* 编写一次即可在任何地方运行，包括在生产系统中。
++* 产品的设计应具有可测试性。
++* 测试代码是产品代码;只有可靠的测试才能生存。
++* 测试基础架构是共享的服务。
++* 测试的所有权跟随产品所有权。
++* 在生产中应进行故障注入和混沌工程测试服务弹性
++* 不可靠的测试应消除。
++
++图4.14显示了持续测试对服务价值链的贡献。表4.12概述了与持续测试最相关的实践。
++
++
++(% style="text-align:center" %)
++[[image:1639234708265-714.png]]
++

1639234626691-221.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+79.7 KB

Content

1639234708265-714.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+80.0 KB

Content

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司