Wiki源代码4.高速IT技术

Version 6.2 by superadmin on 2021/12/11, 22:48
Show last authors
1 = 4. 高速IT技术 =
2
3 本章介绍了表征HVIT环境特征的一些技术选择。有些通常只在这些环境中发现，而另一些是对HVIT工作至关重要的更通用的技术。选择并不详尽；这些技术是帮助高度数字化的组织实现其苛刻目标的工作方式的示例。
4
5 本章中的技术根据与五个HVIT目标之一的关系进行分组和描述：
6
7 * 有价值的投资
8 * 快速研发
9 * 弹性运营
10 * 共同创造价值
11 * 保证合规
12
13 尽管此处列出的技术是根据这些目标分组的，但一种技术通常会支持多个目标。每种技术都可以在多种ITIL管理实践的背景下使用，并且在以下各节的结尾是一张表格，列出了所讨论的技术与哪些实践有关，并概述了该技术如何促进每种实践。每种技术都有一个热点图，可以大致表明每种ITIL服务价值链活动受该技术影响的程度。
14
15
16 **ITIL故事：高速IT技术**
17
18 //Su：我们的预订应用程序的更新已成功部署，该更新将改进其在智能手机和设备上的性能。我们计划进一步开发该应用程序，并增加其他功能，例如会员计划、会员链接、优先预订和车辆升级。我们利用并将继续利用许多技术来帮助我们优化工作和聚焦价值。//
19
20
21 == 4.1 有价值的投资技巧 ==
22
23 有价值的投资目标包括识别和证明对业务战略有重大贡献的数字投资。此练习应使您对数字投资的潜在价值、预期成本、投资回报以及其功用的定义标准有很好的了解。尽管不会增加功能的潜在价值，但也应确定功效或非功能性要求。功效确保投资的潜在价值不受中断，使用不当或其他因素的不利影响。
24
25 有价值的投资是根据市场研究和新产品开发建立的。应当设想新的数字化产品和服务，并根据盈利能力进行评估。产品和服务的实质质量及其发布时间都是获得和保持竞争优势的关键因素。越早设想和评估潜在的投资，就越早实现诸如竞争优势之类的收益。在制定投资决策时，应使用道德原则制定考虑广泛利益干系人的利益。
26
27 在证明投资的合理性和批准性之后继续评估投资也很重要，因为可能存在更有价值的投资选择。有关替代投资的信息越早可用，就越可以重新评估当前的投资。
28
29 在商业组织中进行有价值的投资通常意味着通过增加销售和提高价格，减少资本和运营支出或降低风险来获得更多收入。在非营利组织中，有价值的投资并不专注于收入，而是与其特定于组织的主要目标有关。有价值的投资可以通过销售收入和成本来衡量，也可以通过在投资实现过程中开发的能力来衡量。投资的价值只有在实现回报后才能确定。当供应商、消费者和其他利益干系人共同创造价值时，就会发生这种情况。
30
31 在数字化组织中，IT驱动并推动了业务发展。因此，至关重要的是不断评估IT不断发展的潜力以及获得战略优势。这方面主要关注点应该是投资计划的内在质量以及可以对其进行识别、评估、设计、开发和部署投资计划的速度。在确定潜在投资之前，总会有一段时间不了解，这可能与机会或需求有关。越早确定技术发展并评估其业务潜力，就可以越早做出投资决定。
32
33 可用于实现有价值的投资的技术包括：
34
35 * 优先级技术
36 * 最小可用的产品和服务
37 * 产品或服务所有权
38 * A / B测试
39
40
41 **ITIL故事：有价值的投资技术**
42
43 //Marco：我们的业务策略是通过对技术的明智投资来实现的。因为我们使用敏捷的工作技术，所以我们可以保证我们的功效：我们的代码将始终有效。我们会监控投资情况，以确保我们明智地花钱，并确保应用程序的功能符合客户的需求。//
44
45
46 === 4.1.1 优先级排序技术 ===
47
48 只要工作的需求超出了在预期时间内完成工作的能力，就会发生队列。在理想情况下，组织将没有需求的变化，并且将拥有满足需求所需的适当质量和数量的资源。但是，组织经常需要应对具有固定容量但对服务需求不断变化的问题。这种不平衡会导致需要对工作项进行优先级排序的队列或积压。
49
50 优先级排序是一项通常与支持和软件开发的工作相关活动（例如，对事件调查优先级或对紧急待办项进行优先级排序），但是它是通用的。
51
52
53 ==== 4.1.1.1 延迟成本 ====
54
55 进行优先级排序的一种可用技术是估算新服务或改进服务的延迟成本。这指的是如果服务活动或任务被延迟会损失的财务和非财务利益。对延迟成本的理解使从业人员能够根据价值数据而不是凭直觉确定工作的优先级。这适用于在不断变化的环境中对正在进行的工作进行初始优先级划分、持续评估和重新排序。几乎总是，数字化产品和服务的业务重要性证明了估算延迟成本所付出的努力是合理的。
56
57 延迟成本可以应用于各种级别的决策，例如，产品或服务组合中产品或服务级别的大型投资，产品或服务中功能级别的较小投资或运营任务中。
58
59 该技术在HVIT环境中特别有用，因为投资通常更为重要，并且市场条件会迅速变化，这意味着持续评估替代投资的选择很重要。
60
61
62 ==== 4.1.1.2 买/持有/卖 ====
63
64 可以使用购买/持有/出售技术来管理产品组合（或其他资产）。这涉及评估每种产品并确定三种投资策略中最适合的一种：
65
66 * **买 **投资以改进或扩展生产。
67 * **持有 **只要费用可以承受，就尽可能少地花钱来维护产品。
68 * **卖 **投资以淘汰，减少或更换产品。
69
70 该技术阐明了开发、维护或淘汰产品的成本与收益之间的差异，以及相关的风险和权衡。它可以帮助决策者明确他们的选择并接受决策的后果。
71
72
73 ==== 4.1.1.3 其他技巧 ====
74
75 产品/服务所有者还可以考虑其他许多产品优先级排序技术，包括堆叠排名，Kano，净现值（NPV），投资回报率（ROI）以及适合性/可行性/吸引力。
76
77 图4.1显示了优先级对服务价值链的贡献。表4.1概述了与优先级相关的实践。
78
79 (% style="text-align:center" %)
80 [[image:1639233798811-450.png]]
81
82 图4.1 优先化对服务价值链贡献的热图
83
84
85 表4.1 与优先级相关的实践
86
87 (% style="width:781px" %)
88 |**ITIL管理实践**|(% style="width:536px" %)**与优先次序相关的活动/资源**|(% style="width:95px" %)**影响**
89 |组合管理|(% style="width:536px" %)持续根据价值优先考虑服务产品，并考虑延迟成本。|(% style="width:95px" %)H
90 |问题管理|(% style="width:536px" %)计算未解决问题和错误的财务成本，以便确定优先级并指导问题管理工作。将规避措施的成本与长期解决方案的成本进行比较。|(% style="width:95px" %)H
91 |项目管理|(% style="width:536px" %)计算执行或延迟项目工作的财务影响。|(% style="width:95px" %)H
92 |软件开发与管理|(% style="width:536px" %)计算延迟工作对新软件功能或较大的基于软件的服务组件的财务影响。决定是获取还是构建软件组件。|(% style="width:95px" %)H
93 |变更控制|(% style="width:536px" %)计算对服务或服务组件的变更进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
94 |事件管理|(% style="width:536px" %)计算事故和重大事故的成本，以便优先安排对经济影响最大的工作。|(% style="width:95px" %)M
95 |发布管理|(% style="width:536px" %)计算对新服务或变更的服务进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
96 |服务财务管理|(% style="width:536px" %)计算时间值概要文件数据，以提供用于确定服务产品优先级的信息。|(% style="width:95px" %)M
97 |服务请求管理|(% style="width:536px" %)计算和比较执行或延迟执行请求的财务影响，以便优先安排具有最高收益的工作。|(% style="width:95px" %)L
98
99
100 **ITIL故事：优先排序技术**
101
102 //Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
103
104 //Radhika：正当我们进行市场推广时，我们意识到我们应用程序中的已知错误正在引起不良的宣传。因此，延迟修复的成本大于添加新功能的价值。//
105
106 //Su：我们使用购买/持有/出售技术来计划产品套件中的投资：//
107
108 * //购买我们投资了该应用程序，以改进体验并扩展其功能。//
109 * //保留必须保留在我们网站上预订的选项，因为客户仍在使用它。但是，我们选择最小化对它的投资。//
110 * //出售少数客户仍希望通过传真进行预订。我们停用了此功能，与客户一起将其转换为更现代的通信模式。//
111
112 //我们努力保证令人满意的投资回报。//
113
114
115 === 4.1.2 最小可用的产品服务 ===
116
117 最小可用产品或服务具有足够的功能，以便能够对其进行早期的评估并收集反馈意见，以供将来开发。“ 最小可用”方法是开发产品和服务的有效方法，尤其是当市场动荡并且难以预测的情况下。这与复杂性思维一致，后者认识到某些事情是不可知的，因此不可能设计出具有完整、预先确定需求的产品或服务。当需求未知、不明确或模棱两可时，实验可以确定哪些有效，哪些无效。因此，最小可用方法可以实现有价值的投资，并通过迭代的工作方式促进快速发展。
118
119 在动荡市场上，很难判断哪种产品或服务产品将是成功的。这种不确定性可以通过最小可用方法解决。产品或服务提供者不应投入大量资源和时间来开发全面的产品或服务，而应该限制他们的工作。他们应该针对刚开发出足以刺激反馈和其他数据的产品或服务，然后可以指出是否以及如何继续进行开发。一旦收集了足够的数据，就可以做出决定，这增加了成功的机会。此外，如果决定停止开发，则产品或服务提供者可以将其资源分配给另一项投资，从而最大程度地减少了最初想法的浪费。
120
121 最小可用产品或服务通常具有三个关键特征：
122
123 * 它具有足够的价值，人们愿意使用或购买它。
124 * 它证明了留住那些早期采用者的潜在好处。
125 * 它提供了一个反馈循环以指导未来的发展。
126 * 图4.2显示了最小可用方法对服务价值链的贡献的热图。表4.2概述了与最小可用方法相关的实践。
127
128 (% style="text-align:center" %)
129 [[image:1639233870259-674.png]]
130
131
132 图4.2 热图贡献最小可用的服务价值方法
133
134
135 表4.2 与最小可用方法相关的实践
136
137 (% style="width:863px" %)
138 |**ITIL管理实践**|(% style="width:575px" %)**与最小可用方法相关的活动/资源**|(% style="width:87px" %)**影响**
139 |架构管理|(% style="width:575px" %)(((
140 使用最小可用的方法来描述服务、技术、信息或环境体系结构，这将为其他类型
141
142 的服务或产品工作创建必要的约束、边界或促成因素。
143 )))|(% style="width:87px" %)H
144 |业务分析|(% style="width:575px" %)使用最低可行的方法作为从产品或服务中提取核心业务价值的工具。|(% style="width:87px" %)H
145 |容量与性能管理|(% style="width:575px" %)(((
146 使用容量和性能管理作为计算最低可行产品或服务所需的最小资源（服务器数量，服务
147
148 台代理数量等）的基础。
149 )))|(% style="width:87px" %)H
150 |监控与事态管理|(% style="width:575px" %)(((
151 使用监控和事态管理作为设计和配置监视和遥测工具的基础，这些工具用于操作和从最低
152
153 限度可行的产品或服务中学习。
154 )))|(% style="width:87px" %)H
155 |组合管理|(% style="width:575px" %)(((
156 使用最小可用产品的概念作为动态决策工具，以支持对产品或服务中的功能组合进行良好
157
158 的投资。
159 )))|(% style="width:87px" %)H
160 |项目管理|(% style="width:575px" %)阐明满足业务案例所需的最小输出。|(% style="width:87px" %)H
161 |服务设计|(% style="width:575px" %)使用最小可用的方法来设计产品或服务的必要客户体验和用户体验元素。|(% style="width:87px" %)H
162 |服务验证与测试|(% style="width:575px" %)开发测试用例以检查所有服务组件是否支持最低限度的可行产品或服务。|(% style="width:87px" %)H
163 |软件开发管理|(% style="width:575px" %)使用最小可用方法作为决策工具来优先处理软件功能。|(% style="width:87px" %)H
164 |架构管理|(% style="width:575px" %)(((
165 使用最小可用方法作为决策工具来设计，实施基础架构组件上正在进行的工作并确定其优
166
167 先级。
168 )))|(% style="width:87px" %)M
169 |服务目录管理|(% style="width:575px" %)(((
170 使用最小可用方法作为描述所有产品、服务和服务产品的基础，并确保相关受众能够获取
171
172 信息。
173 )))|(% style="width:87px" %)M
174 |服务连续性管理|(% style="width:575px" %)设计和建立连续性计划以支持最低限度的可行产品或服务。|(% style="width:87px" %)M
175 |供应商管理|(% style="width:575px" %)合作伙伴和供应商提供产品和服务时，使用最小可用方法阐明所需的输出。|(% style="width:87px" %)M
176
177
178 **ITIL的故事：最小可用产品和服务**
179
180 //Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
181
182 //Solmaz：我们知道我们不了解未来的客户会想要什么。通过迭代，我们可以在每个阶段对产品进行测试，如果出错，可以在不牺牲大量投资的情况下返回以前的成功版本。//
183
184
185 === 4.1.3 产品或服务所有权 ===
186
187 Scrum建议三个角色：产品负责人，开发团队和Scrum主管。产品负责人负责使开发团队生产的产品价值最大化。产品所有权需要建立需求并确定其优先级，并将其传达给开发团队。在这些软件开发团队的背景下，是产品负责人与包括消费者在内的各种利益干系人进行联络和协商。HVIT环境通常是面向产品的，因此产品负责人的概念与HVIT高度相关。产品负责人的概念也适用于服务和服务所有者。
188
189 产品负责人角色依赖于：
190
191 * **技能和经验 **产品负责人需要具备利益干系人管理、需求分析、市场研究、客户细分等方面的技能。具有业务分析或产品管理背景的产品负责人通常具有这些技能，并且他们可能只需要短期学习就能熟悉敏捷的工作方式。但是，成为产品负责人的技术人员可能需要更多培训。
192 * **权限 **产品负责人至少必须能够识别和传达短期优先事项，而无需长时间或不必要的辩论。组织应信任产品负责人使用其权限。
193 * **合法性 **产品负责人还具有需求的合法性。直接的客户联系人和第一手体验将增强这种合法性，并为他们提供有效地确定优先级所需的知识。
194 * **时间 **产品负责人需要时间来履行职责，包括思考故事、筛选和编辑待办项、拜访利益干系人、分析反馈、与团队合作、评估交付后收益的实现以及反思进度和当前状态他们的项目。
195
196 产品或服务的所有权是所有价值链活动的关键部分，并助于有价值的投资。图4.3显示了产品或服务所有权对服务价值链的贡献。
197
198 表4.3概述了与产品或服务所有权相关的实践。
199
200 (% style="text-align:center" %)
201 [[image:1639233949377-875.png]]
202
203 图4.3 产品或服务所有权对服务价值链贡献的热图
204
205
206 表4.3 与产品或服务所有权相关的实践
207
208 (% style="width:788px" %)
209 |**ITIL管理实践**|(% style="width:566px" %)**与产品或服务所有权相关的活动/资源**|(% style="width:63px" %)**影响**
210 |架构管理|(% style="width:566px" %)(((
211 产品和服务所有者参与阐明，完善基础架构和平台开发积压工作并确定其优先级，并
212
213 决定是否购买市售的基础架构组件和服务。
214 )))|(% style="width:63px" %)H
215 |组合管理|(% style="width:566px" %)（软件）产品所有者和产品或服务经理参与评估和确定产品或服务投资建议的优先级。|(% style="width:63px" %)H
216 |关系管理|(% style="width:566px" %)(((
217 与利益干系人的互动。
218
219 参与确定客户对新产品或已变更产品和服务的优先级。
220
221 协调客户的需求和反馈。
222
223 参与解决投诉和调解相互矛盾的要求。
224 )))|(% style="width:63px" %)H
225 |服务目录管理|(% style="width:566px" %)产品或服务所有者和经理参与发布有关所有产品、服务和服务产品的信息。|(% style="width:63px" %)H
226 |软件开发管理|(% style="width:566px" %)产品和服务所有者参与阐明，完善和确定软件开发积压的优先次序，并决定是否购买或升级商用软件。|(% style="width:63px" %)H
227 |项目管理|(% style="width:566px" %)产品和服务所有者及经理参与交付项目工作和管理风险。|(% style="width:63px" %)M
228 |风险管理|(% style="width:566px" %)产品和服务所有者参与阐明和减轻企业风险。|(% style="width:63px" %)M
229 |供应商管理|(% style="width:566px" %)产品和服务所有者及管理人员参与阐明需求，组织互动以及与合作伙伴和供应商进行谈判。|(% style="width:63px" %)M
230
231
232 **ITIL故事：产品或服务所有权**
233
234 //Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
235
236 //我具有在敏捷开发和业务分析培训方面的经验的技术背景，包括与客户合作所花费的时间。我了解我可以授权的变更级别以及何时需要升级问题。Axle确保我有时间履行自己的职责，并了解我的要求以及产品如何专注于价值。//
237
238
239 === 4.1.4 A / B测试 ===
240
241 很难预测某个功能是否对用户有价值。这个问题通过测量用户行为来收集可靠的数据来解决。但是，当影响因素太多时，几乎不可能将新功能的效果分离出来。因此，需要一个对照组。
242
243 A / B测试是一项限时实验，其中一组用户（即对照组）提供了旧版本的产品或服务。同时，为另一组用户（实验组）提供了包括新功能的产品或服务的新版本。假设影响两组的所有其他因素均相等，则可以比较两组的测量值，从而收集数据以基于价值的决策。此方法如图4.4所示。
244
245 A / B测试有助于项目组合管理实践。投资组合管理的本质是在资金和资源的限制下进行正确的投资。项目组合管理适用于各种级别，包括产品或服务中功能的“组合”。A / B测试有助于确定功能的哪个版本最有价值。因此，它有助于有价值的投资。
246
247 (% style="text-align:center" %)
248 [[image:1639234024512-147.png]]
249
250 图4.4 有时间限制的A/B测试实验
251
252
253 例
254
255 组织的市场营销部门希望通过添加生产的简短视频来变更组织网站上的产品描述。该部门确信，这款新功能将大大提高转换率，目前转换率为2.5％（也就是说，有2.5％的访客将产品添加到他们的购物车中）。如果该功能是在未进行A / B测试的情况下实现的，并且转换率有所提高，则无法说出这种增加是否是由于这一特定的变更引起的。此指标可能同时受到多种因素的影响，例如针对该产品的新广告系列。市场营销部门决定进行A / B 测试。将为一个实验组用户显示一个带有视频的产品页面，向一个对照组用户显示一个不带视频的产品页面的先前版本。通过比较治疗组和对照组的转化率，更容易判断变化的效果。
256
257 由于HVIT环境通常面向产品，并且在无法预测的市场中承受时间压力，因此A / B测试与HVIT特别相关。
258
259 图4.5显示了A/B测试对服务价值链的贡献。表4.4概述了与A / B测试相关的实践。
260
261
262 (% style="text-align:center" %)
263 [[image:1639234052832-469.png]]
264
265 图4.5 A/B测试对服务价值链贡献的热图
266
267
268 表4.4 与A/B测试相关的实践
269
270 |**ITIL管理实践**|**与A / B测试相关的活动/资源**|**影响**
271 |组合管理|确定并优先考虑使用A / B测试数据进行投资的服务、产品和功能。|H
272 |风险管理|在进行进一步投资之前，使用A / B测试方法确定风险缓解方案的有效性。|H
273 |服务设计|在进行进一步的投资和设计决策之前，使用A / B测试方法确定客户体验和用户体验原型的有效性。|H
274 |架构管理|使用A / B测试方法设计和完善技术，信息，产品和服务体系结构。|M
275 |持续改进|在进行进一步投资之前，使用A / B测试方法确定各种改进方案和计划的有效性。|M
276 |知识管理|在进行进一步的投资之前，使用A / B测试方法确定不同知识管理，表示以及通讯技术和工的有效性。|M
277 |组织变革管理|在进行进一步投资之前，使用A / B测试方法确定组织变革的有效性。|M
278 |问题管理|在进行进一步投资之前，使用A / B测试方法确定规避措施和错误控制方法的有效性。|M
279 |服务验证与测试|使用A / B测试方法定义和执行服务、验证和产品测试活动。|M
280
281
282 **ITIL的故事：A / B测试**
283
284 //Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
285
286 //Marco：为了评估此新功能对我们客户的价值，我们进行了A / B 测试：50％的客户可以升级，而50％的客户没有。结果是结论性的：有机会时，有70％的客户升级了车辆。在免费升级一次的汽车中，有20％选择在下次预订时租用更高规格的汽车。//
287
288 //Su：基于这些结果，我们可以放心发布此新功能。//
289
290
291 == 4.2 快速研发技术 ==
292
293 快速发展的目标涉及频繁、快速且可靠地实现新的和改进的数字化产品和服务。“ 开发”通常是指产品开发，尽管应用程序开发通常包含在其中。
294
295 通常，越早交付数字化产品，越早实现价值。但是，有时情况并非如此，应相应地修改时间表；例如，提早交付可能与市场需求不符。将单个产品分成一系列增量交付可加快整体交付速度，并使用户比等待整个产品更早地实现价值。
296
297 除了快速和频繁之外，交付还必须可靠。但是，有时最好在有容量时快速交付产品或服务，或快速恢复服务，而不是等待提供更可靠的产品或服务。在这些情况下，平均服务恢复时间（MTRS）通常比平均失效间隔时间（MTBF）更好。
298
299 快速研发没有内在价值；它的价值与正在开发的价值有关。在商业组织中，它可以通过缩短产品上市时间和客户时间来实现更快的投资回报。通常，这是用更多的销售收入来表示的，因为收入流开始得较早。它也可以用网站访问量或注册邮件的潜在客户数量来表示。
300
301 快速研发可以根据每单位时间应用程序（变更）的大小来衡量。应用程序的大小可以用技术单位（例如代码行）或功能型单位（例如故事点或功能点）表示。比较生产效率时应谨慎，因为它取决于许多因素：例如，非功能型的需求未反映在故事点中。当为应用程序和团队的特定组合指定条件时，比较生产效率更有意义。
302
303 组织通常将重点放在应用程序的快速研发上，因为这就是功能和价值所在。但是，同样重要的是相关组件也要快速研发或交付。这些请求包括服务请求，例如提供设备、提供访问权限、设置新邮箱或商业智能（BI）报告。
304
305 跟踪预期开发时间的可预测性也很有用；例如，通过记录何时报告偏离计划的情况。管理人员应鼓励人们尽快报告潜在的延迟。这是期望的行为。
306
307 为了迅速实现业务价值，在业务压力下敏捷开发团队尽可能频繁地交付可能可部署的软件增量。不幸的是，对于实际的部署，这些发行版通常必须等待数天，数周甚至是数月，这通常是价值流中最长的延迟。这通常是由于对批准和部署采取了广泛谨慎的方法。通常，批准流程是变更顾问委员进行的评估，仅在计划的日期开会。实际的部署也经常按照时间表进行。因此，快速研发和弹性运营之间可能存在冲突。
308
309 这种方法背后的想法是变更具有潜在的破坏性，因此应谨慎控制。由于快速变化和谨慎变化是截然相反的目标，因此开发团队和IT运维通常无法有效地协作，因此IT和服务管理的从业人员必须缩小差距。
310
311 这种张力基于熟悉的心理模型，其中变更破坏了稳定性，而稳定性控制变更发生的变化：变化越少，稳定性的风险就越低。最近，出现了另一种思维方式。变更大小的减少会减少中断的风险。较小的变更还意味着变更可以更频繁地发生。通过更频繁地进行变更，可以提高组织的变更能力。变更能力的提高反过来又降低了中断的风险。图4.6演示了变更大小的影响。
312
313 DevOps社区已经接受了这种思维方式，并且已经开发了适当的实践和支持技术。研究发现，在部署频率、变更准备时间和变更失效率方面的高性能与版本控制、持续交付和自动化测试相关。研究还表明，在团队中基于同行评审的变更批准的风险不比使用变更顾问委员会的风险低。
314
315
316 (% style="text-align:center" %)
317 [[image:1639234096344-870.png]]
318
319
深圳市艾拓先锋企业管理咨询有限公司