Wiki source code of 4.高速IT技术

Version 37.1 by superadmin on 2022/01/09, 11:56
Show last authors
1
2
3
4 [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%AB%98%E9%80%9FIT%E3%80%8BHVIT/3.%E9%AB%98%E9%80%9FIT%E6%96%87%E5%8C%96/]]
5
6 {{box cssClass="floatinginfobox" title="**X Contents**"}}
7 {{toc/}}
8 {{/box}}
9
10 = 4. 高速IT技术 =
11
12 本章介绍了表征HVIT环境特征的一些技术选择。有些通常只在这些环境中发现，而另一些是对HVIT工作至关重要的更通用的技术。选择并不详尽；这些技术是帮助高度数字化的组织实现其苛刻目标的工作方式的示例。
13
14 本章中的技术根据与五个HVIT目标之一的关系进行分组和描述：
15
16 * 有价值的投资
17 * 快速研发
18 * 弹性运营
19 * 共同创造价值
20 * 保证合规
21
22 尽管此处列出的技术是根据这些目标分组的，但一种技术通常会支持多个目标。每种技术都可以在多种ITIL管理实践的背景下使用，并且在以下各节的结尾是一张表格，列出了所讨论的技术与哪些实践有关，并概述了该技术如何促进每种实践。每种技术都有一个热点图，可以大致表明每种ITIL服务价值链活动受该技术影响的程度。
23
24
25 **ITIL故事：高速IT技术**
26
27 //Su：我们的预订应用程序的更新已成功部署，该更新将改进其在智能手机和设备上的性能。我们计划进一步开发该应用程序，并增加其他功能，例如会员计划、会员链接、优先预订和车辆升级。我们利用并将继续利用许多技术来帮助我们优化工作和聚焦价值。//
28
29
30 == 4.1 有价值的投资技巧 ==
31
32 有价值的投资目标包括识别和证明对业务战略有重大贡献的数字投资。此练习应使您对数字投资的潜在价值、预期成本、投资回报以及其功用的定义标准有很好的了解。尽管不会增加功能的潜在价值，但也应确定功效或非功能性要求。功效确保投资的潜在价值不受中断，使用不当或其他因素的不利影响。
33
34 有价值的投资是根据市场研究和新产品开发建立的。应当设想新的数字化产品和服务，并根据盈利能力进行评估。产品和服务的实质质量及其发布时间都是获得和保持竞争优势的关键因素。越早设想和评估潜在的投资，就越早实现诸如竞争优势之类的收益。在制定投资决策时，应使用道德原则制定考虑广泛利益干系人的利益。
35
36 在证明投资的合理性和批准性之后继续评估投资也很重要，因为可能存在更有价值的投资选择。有关替代投资的信息越早可用，就越可以重新评估当前的投资。
37
38 在商业组织中进行有价值的投资通常意味着通过增加销售和提高价格，减少资本和运营支出或降低风险来获得更多收入。在非营利组织中，有价值的投资并不专注于收入，而是与其特定于组织的主要目标有关。有价值的投资可以通过销售收入和成本来衡量，也可以通过在投资实现过程中开发的能力来衡量。投资的价值只有在实现回报后才能确定。当供应商、消费者和其他利益干系人共同创造价值时，就会发生这种情况。
39
40 在数字化组织中，IT驱动并推动了业务发展。因此，至关重要的是不断评估IT不断发展的潜力以及获得战略优势。这方面主要关注点应该是投资计划的内在质量以及可以对其进行识别、评估、设计、开发和部署投资计划的速度。在确定潜在投资之前，总会有一段时间不了解，这可能与机会或需求有关。越早确定技术发展并评估其业务潜力，就可以越早做出投资决定。
41
42 可用于实现有价值的投资的技术包括：
43
44 * 优先级技术
45 * 最小可用的产品和服务
46 * 产品或服务所有权
47 * A / B测试
48
49 **ITIL故事：有价值的投资技术**
50
51 //Marco：我们的业务策略是通过对技术的明智投资来实现的。因为我们使用敏捷的工作技术，所以我们可以保证我们的功效：我们的代码将始终有效。我们会监控投资情况，以确保我们明智地花钱，并确保应用程序的功能符合客户的需求。//
52
53
54 === 4.1.1 优先级排序技术 ===
55
56 只要工作的需求超出了在预期时间内完成工作的能力，就会发生队列。在理想情况下，组织将没有需求的变化，并且将拥有满足需求所需的适当质量和数量的资源。但是，组织经常需要应对具有固定容量但对服务需求不断变化的问题。这种不平衡会导致需要对工作项进行优先级排序的队列或积压。
57
58 优先级排序是一项通常与支持和软件开发的工作相关活动（例如，对事件调查优先级或对紧急待办项进行优先级排序），但是它是通用的。
59
60
61 ==== 4.1.1.1 延迟成本 ====
62
63 进行优先级排序的一种可用技术是估算新服务或改进服务的延迟成本。这指的是如果服务活动或任务被延迟会损失的财务和非财务利益。对延迟成本的理解使从业人员能够根据价值数据而不是凭直觉确定工作的优先级。这适用于在不断变化的环境中对正在进行的工作进行初始优先级划分、持续评估和重新排序。几乎总是，数字化产品和服务的业务重要性证明了估算延迟成本所付出的努力是合理的。
64
65 延迟成本可以应用于各种级别的决策，例如，产品或服务组合中产品或服务级别的大型投资，产品或服务中功能级别的较小投资或运营任务中。
66
67 该技术在HVIT环境中特别有用，因为投资通常更为重要，并且市场条件会迅速变化，这意味着持续评估替代投资的选择很重要。
68
69
70 ==== 4.1.1.2 买/持有/卖 ====
71
72 可以使用购买/持有/出售技术来管理产品组合（或其他资产）。这涉及评估每种产品并确定三种投资策略中最适合的一种：
73
74 * **买 **投资以改进或扩展生产。
75 * **持有 **只要费用可以承受，就尽可能少地花钱来维护产品。
76 * **卖 **投资以淘汰，减少或更换产品。
77
78 该技术阐明了开发、维护或淘汰产品的成本与收益之间的差异，以及相关的风险和权衡。它可以帮助决策者明确他们的选择并接受决策的后果。
79
80
81 ==== 4.1.1.3 其他技巧 ====
82
83 产品/服务所有者还可以考虑其他许多产品优先级排序技术，包括堆叠排名，Kano，净现值（NPV），投资回报率（ROI）以及适合性/可行性/吸引力。
84
85 图4.1显示了优先级对服务价值链的贡献。表4.1概述了与优先级相关的实践。
86
87 (% style="text-align:center" %)
88 [[image:1639233798811-450.png]]
89
90 图4.1 优先化对服务价值链贡献的热图
91
92
93 表4.1 与优先级相关的实践
94
95 (% style="width:781px" %)
96 |**ITIL管理实践**|(% style="width:536px" %)**与优先次序相关的活动/资源**|(% style="width:95px" %)**影响**
97 |组合管理|(% style="width:536px" %)持续根据价值优先考虑服务产品，并考虑延迟成本。|(% style="width:95px" %)H
98 |问题管理|(% style="width:536px" %)计算未解决问题和错误的财务成本，以便确定优先级并指导问题管理工作。将规避措施的成本与长期解决方案的成本进行比较。|(% style="width:95px" %)H
99 |项目管理|(% style="width:536px" %)计算执行或延迟项目工作的财务影响。|(% style="width:95px" %)H
100 |软件开发与管理|(% style="width:536px" %)计算延迟工作对新软件功能或较大的基于软件的服务组件的财务影响。决定是获取还是构建软件组件。|(% style="width:95px" %)H
101 |变更控制|(% style="width:536px" %)计算对服务或服务组件的变更进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
102 |事件管理|(% style="width:536px" %)计算事故和重大事故的成本，以便优先安排对经济影响最大的工作。|(% style="width:95px" %)M
103 |发布管理|(% style="width:536px" %)计算对新服务或变更的服务进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
104 |服务财务管理|(% style="width:536px" %)计算时间值概要文件数据，以提供用于确定服务产品优先级的信息。|(% style="width:95px" %)M
105 |服务请求管理|(% style="width:536px" %)计算和比较执行或延迟执行请求的财务影响，以便优先安排具有最高收益的工作。|(% style="width:95px" %)L
106
107 **ITIL故事：优先排序技术**
108
109 //Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
110
111 //Radhika：正当我们进行市场推广时，我们意识到我们应用程序中的已知错误正在引起不良的宣传。因此，延迟修复的成本大于添加新功能的价值。//
112
113 //Su：我们使用购买/持有/出售技术来计划产品套件中的投资：//
114
115 * //购买我们投资了该应用程序，以改进体验并扩展其功能。//
116 * //保留必须保留在我们网站上预订的选项，因为客户仍在使用它。但是，我们选择最小化对它的投资。//
117 * //出售少数客户仍希望通过传真进行预订。我们停用了此功能，与客户一起将其转换为更现代的通信模式。//
118
119 //我们努力保证令人满意的投资回报。//
120
121
122 === 4.1.2 最小可用的产品服务 ===
123
124 最小可用产品或服务具有足够的功能，以便能够对其进行早期的评估并收集反馈意见，以供将来开发。“ 最小可用”方法是开发产品和服务的有效方法，尤其是当市场动荡并且难以预测的情况下。这与复杂性思维一致，后者认识到某些事情是不可知的，因此不可能设计出具有完整、预先确定需求的产品或服务。当需求未知、不明确或模棱两可时，实验可以确定哪些有效，哪些无效。因此，最小可用方法可以实现有价值的投资，并通过迭代的工作方式促进快速发展。
125
126 在动荡市场上，很难判断哪种产品或服务产品将是成功的。这种不确定性可以通过最小可用方法解决。产品或服务提供者不应投入大量资源和时间来开发全面的产品或服务，而应该限制他们的工作。他们应该针对刚开发出足以刺激反馈和其他数据的产品或服务，然后可以指出是否以及如何继续进行开发。一旦收集了足够的数据，就可以做出决定，这增加了成功的机会。此外，如果决定停止开发，则产品或服务提供者可以将其资源分配给另一项投资，从而最大程度地减少了最初想法的浪费。
127
128 最小可用产品或服务通常具有三个关键特征：
129
130 * 它具有足够的价值，人们愿意使用或购买它。
131 * 它证明了留住那些早期采用者的潜在好处。
132 * 它提供了一个反馈循环以指导未来的发展。
133 * 图4.2显示了最小可用方法对服务价值链的贡献的热图。表4.2概述了与最小可用方法相关的实践。
134
135 (% style="text-align:center" %)
136 [[image:1639233870259-674.png]]
137
138
139 图4.2 热图贡献最小可用的服务价值方法
140
141
142 表4.2 与最小可用方法相关的实践
143
144 (% style="width:863px" %)
145 |**ITIL管理实践**|(% style="width:575px" %)**与最小可用方法相关的活动/资源**|(% style="width:87px" %)**影响**
146 |架构管理|(% style="width:575px" %)(((
147 使用最小可用的方法来描述服务、技术、信息或环境体系结构，这将为其他类型
148
149 的服务或产品工作创建必要的约束、边界或促成因素。
150 )))|(% style="width:87px" %)H
151 |业务分析|(% style="width:575px" %)使用最低可行的方法作为从产品或服务中提取核心业务价值的工具。|(% style="width:87px" %)H
152 |容量与性能管理|(% style="width:575px" %)(((
153 使用容量和性能管理作为计算最低可行产品或服务所需的最小资源（服务器数量，服务
154
155 台代理数量等）的基础。
156 )))|(% style="width:87px" %)H
157 |监控与事态管理|(% style="width:575px" %)(((
158 使用监控和事态管理作为设计和配置监视和遥测工具的基础，这些工具用于操作和从最低
159
160 限度可行的产品或服务中学习。
161 )))|(% style="width:87px" %)H
162 |组合管理|(% style="width:575px" %)(((
163 使用最小可用产品的概念作为动态决策工具，以支持对产品或服务中的功能组合进行良好
164
165 的投资。
166 )))|(% style="width:87px" %)H
167 |项目管理|(% style="width:575px" %)阐明满足业务案例所需的最小输出。|(% style="width:87px" %)H
168 |服务设计|(% style="width:575px" %)使用最小可用的方法来设计产品或服务的必要客户体验和用户体验元素。|(% style="width:87px" %)H
169 |服务验证与测试|(% style="width:575px" %)开发测试用例以检查所有服务组件是否支持最低限度的可行产品或服务。|(% style="width:87px" %)H
170 |软件开发管理|(% style="width:575px" %)使用最小可用方法作为决策工具来优先处理软件功能。|(% style="width:87px" %)H
171 |架构管理|(% style="width:575px" %)(((
172 使用最小可用方法作为决策工具来设计，实施基础架构组件上正在进行的工作并确定其优
173
174 先级。
175 )))|(% style="width:87px" %)M
176 |服务目录管理|(% style="width:575px" %)(((
177 使用最小可用方法作为描述所有产品、服务和服务产品的基础，并确保相关受众能够获取
178
179 信息。
180 )))|(% style="width:87px" %)M
181 |服务连续性管理|(% style="width:575px" %)设计和建立连续性计划以支持最低限度的可行产品或服务。|(% style="width:87px" %)M
182 |供应商管理|(% style="width:575px" %)合作伙伴和供应商提供产品和服务时，使用最小可用方法阐明所需的输出。|(% style="width:87px" %)M
183
184 **ITIL的故事：最小可用产品和服务**
185
186 //Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
187
188 //Solmaz：我们知道我们不了解未来的客户会想要什么。通过迭代，我们可以在每个阶段对产品进行测试，如果出错，可以在不牺牲大量投资的情况下返回以前的成功版本。//
189
190
191 === 4.1.3 产品或服务所有权 ===
192
193 Scrum建议三个角色：产品负责人，开发团队和Scrum主管。产品负责人负责使开发团队生产的产品价值最大化。产品所有权需要建立需求并确定其优先级，并将其传达给开发团队。在这些软件开发团队的背景下，是产品负责人与包括消费者在内的各种利益干系人进行联络和协商。HVIT环境通常是面向产品的，因此产品负责人的概念与HVIT高度相关。产品负责人的概念也适用于服务和服务所有者。
194
195 产品负责人角色依赖于：
196
197 * **技能和经验 **产品负责人需要具备利益干系人管理、需求分析、市场研究、客户细分等方面的技能。具有业务分析或产品管理背景的产品负责人通常具有这些技能，并且他们可能只需要短期学习就能熟悉敏捷的工作方式。但是，成为产品负责人的技术人员可能需要更多培训。
198 * **权限 **产品负责人至少必须能够识别和传达短期优先事项，而无需长时间或不必要的辩论。组织应信任产品负责人使用其权限。
199 * **合法性 **产品负责人还具有需求的合法性。直接的客户联系人和第一手体验将增强这种合法性，并为他们提供有效地确定优先级所需的知识。
200 * **时间 **产品负责人需要时间来履行职责，包括思考故事、筛选和编辑待办项、拜访利益干系人、分析反馈、与团队合作、评估交付后收益的实现以及反思进度和当前状态他们的项目。
201
202 产品或服务的所有权是所有价值链活动的关键部分，并助于有价值的投资。图4.3显示了产品或服务所有权对服务价值链的贡献。
203
204 表4.3概述了与产品或服务所有权相关的实践。
205
206 (% style="text-align:center" %)
207 [[image:1639233949377-875.png]]
208
209 图4.3 产品或服务所有权对服务价值链贡献的热图
210
211
212 表4.3 与产品或服务所有权相关的实践
213
214 (% style="width:788px" %)
215 |**ITIL管理实践**|(% style="width:566px" %)**与产品或服务所有权相关的活动/资源**|(% style="width:63px" %)**影响**
216 |架构管理|(% style="width:566px" %)(((
217 产品和服务所有者参与阐明，完善基础架构和平台开发积压工作并确定其优先级，并
218
219 决定是否购买市售的基础架构组件和服务。
220 )))|(% style="width:63px" %)H
221 |组合管理|(% style="width:566px" %)（软件）产品所有者和产品或服务经理参与评估和确定产品或服务投资建议的优先级。|(% style="width:63px" %)H
222 |关系管理|(% style="width:566px" %)(((
223 与利益干系人的互动。
224
225 参与确定客户对新产品或已变更产品和服务的优先级。
226
227 协调客户的需求和反馈。
228
229 参与解决投诉和调解相互矛盾的要求。
230 )))|(% style="width:63px" %)H
231 |服务目录管理|(% style="width:566px" %)产品或服务所有者和经理参与发布有关所有产品、服务和服务产品的信息。|(% style="width:63px" %)H
232 |软件开发管理|(% style="width:566px" %)产品和服务所有者参与阐明，完善和确定软件开发积压的优先次序，并决定是否购买或升级商用软件。|(% style="width:63px" %)H
233 |项目管理|(% style="width:566px" %)产品和服务所有者及经理参与交付项目工作和管理风险。|(% style="width:63px" %)M
234 |风险管理|(% style="width:566px" %)产品和服务所有者参与阐明和减轻企业风险。|(% style="width:63px" %)M
235 |供应商管理|(% style="width:566px" %)产品和服务所有者及管理人员参与阐明需求，组织互动以及与合作伙伴和供应商进行谈判。|(% style="width:63px" %)M
236
237 **ITIL故事：产品或服务所有权**
238
239 //Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
240
241 //我具有在敏捷开发和业务分析培训方面的经验的技术背景，包括与客户合作所花费的时间。我了解我可以授权的变更级别以及何时需要升级问题。Axle确保我有时间履行自己的职责，并了解我的要求以及产品如何专注于价值。//
242
243
244 === 4.1.4 A / B测试 ===
245
246 很难预测某个功能是否对用户有价值。这个问题通过测量用户行为来收集可靠的数据来解决。但是，当影响因素太多时，几乎不可能将新功能的效果分离出来。因此，需要一个对照组。
247
248 A / B测试是一项限时实验，其中一组用户（即对照组）提供了旧版本的产品或服务。同时，为另一组用户（实验组）提供了包括新功能的产品或服务的新版本。假设影响两组的所有其他因素均相等，则可以比较两组的测量值，从而收集数据以基于价值的决策。此方法如图4.4所示。
249
250 A / B测试有助于项目组合管理实践。投资组合管理的本质是在资金和资源的限制下进行正确的投资。项目组合管理适用于各种级别，包括产品或服务中功能的“组合”。A / B测试有助于确定功能的哪个版本最有价值。因此，它有助于有价值的投资。
251
252 (% style="text-align:center" %)
253 [[image:1639234024512-147.png]]
254
255 图4.4 有时间限制的A/B测试实验
256
257
258 例
259
260 组织的市场营销部门希望通过添加生产的简短视频来变更组织网站上的产品描述。该部门确信，这款新功能将大大提高转换率，目前转换率为2.5％（也就是说，有2.5％的访客将产品添加到他们的购物车中）。如果该功能是在未进行A / B测试的情况下实现的，并且转换率有所提高，则无法说出这种增加是否是由于这一特定的变更引起的。此指标可能同时受到多种因素的影响，例如针对该产品的新广告系列。市场营销部门决定进行A / B 测试。将为一个实验组用户显示一个带有视频的产品页面，向一个对照组用户显示一个不带视频的产品页面的先前版本。通过比较治疗组和对照组的转化率，更容易判断变化的效果。
261
262 由于HVIT环境通常面向产品，并且在无法预测的市场中承受时间压力，因此A / B测试与HVIT特别相关。
263
264 图4.5显示了A/B测试对服务价值链的贡献。表4.4概述了与A / B测试相关的实践。
265
266
267 (% style="text-align:center" %)
268 [[image:1639234052832-469.png]]
269
270 图4.5 A/B测试对服务价值链贡献的热图
271
272
273 表4.4 与A/B测试相关的实践
274
275 (% style="width:1031px" %)
276 |**ITIL管理实践**|(% style="width:747px" %)**与A / B测试相关的活动/资源**|(% style="width:103px" %)**影响**
277 |组合管理|(% style="width:747px" %)确定并优先考虑使用A / B测试数据进行投资的服务、产品和功能。|(% style="width:103px" %)H
278 |风险管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定风险缓解方案的有效性。|(% style="width:103px" %)H
279 |服务设计|(% style="width:747px" %)在进行进一步的投资和设计决策之前，使用A / B测试方法确定客户体验和用户体验原型的有效性。|(% style="width:103px" %)H
280 |架构管理|(% style="width:747px" %)使用A / B测试方法设计和完善技术，信息，产品和服务体系结构。|(% style="width:103px" %)M
281 |持续改进|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定各种改进方案和计划的有效性。|(% style="width:103px" %)M
282 |知识管理|(% style="width:747px" %)在进行进一步的投资之前，使用A / B测试方法确定不同知识管理，表示以及通讯技术和工的有效性。|(% style="width:103px" %)M
283 |组织变革管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定组织变革的有效性。|(% style="width:103px" %)M
284 |问题管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定规避措施和错误控制方法的有效性。|(% style="width:103px" %)M
285 |服务验证与测试|(% style="width:747px" %)使用A / B测试方法定义和执行服务、验证和产品测试活动。|(% style="width:103px" %)M
286
287 **ITIL的故事：A / B测试**
288
289 //Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
290
291 //Marco：为了评估此新功能对我们客户的价值，我们进行了A / B 测试：50％的客户可以升级，而50％的客户没有。结果是结论性的：有机会时，有70％的客户升级了车辆。在免费升级一次的汽车中，有20％选择在下次预订时租用更高规格的汽车。//
292
293 //Su：基于这些结果，我们可以放心发布此新功能。//
294
295
296 == 4.2 快速研发技术 ==
297
298 快速发展的目标涉及频繁、快速且可靠地实现新的和改进的数字化产品和服务。“ 开发”通常是指产品开发，尽管应用程序开发通常包含在其中。
299
300 通常，越早交付数字化产品，越早实现价值。但是，有时情况并非如此，应相应地修改时间表；例如，提早交付可能与市场需求不符。将单个产品分成一系列增量交付可加快整体交付速度，并使用户比等待整个产品更早地实现价值。
301
302 除了快速和频繁之外，交付还必须可靠。但是，有时最好在有容量时快速交付产品或服务，或快速恢复服务，而不是等待提供更可靠的产品或服务。在这些情况下，平均服务恢复时间（MTRS）通常比平均失效间隔时间（MTBF）更好。
303
304 快速研发没有内在价值；它的价值与正在开发的价值有关。在商业组织中，它可以通过缩短产品上市时间和客户时间来实现更快的投资回报。通常，这是用更多的销售收入来表示的，因为收入流开始得较早。它也可以用网站访问量或注册邮件的潜在客户数量来表示。
305
306 快速研发可以根据每单位时间应用程序（变更）的大小来衡量。应用程序的大小可以用技术单位（例如代码行）或功能型单位（例如故事点或功能点）表示。比较生产效率时应谨慎，因为它取决于许多因素：例如，非功能型的需求未反映在故事点中。当为应用程序和团队的特定组合指定条件时，比较生产效率更有意义。
307
308 组织通常将重点放在应用程序的快速研发上，因为这就是功能和价值所在。但是，同样重要的是相关组件也要快速研发或交付。这些请求包括服务请求，例如提供设备、提供访问权限、设置新邮箱或商业智能（BI）报告。
309
310 跟踪预期开发时间的可预测性也很有用；例如，通过记录何时报告偏离计划的情况。管理人员应鼓励人们尽快报告潜在的延迟。这是期望的行为。
311
312 为了迅速实现业务价值，在业务压力下敏捷开发团队尽可能频繁地交付可能可部署的软件增量。不幸的是，对于实际的部署，这些发行版通常必须等待数天，数周甚至是数月，这通常是价值流中最长的延迟。这通常是由于对批准和部署采取了广泛谨慎的方法。通常，批准流程是变更顾问委员进行的评估，仅在计划的日期开会。实际的部署也经常按照时间表进行。因此，快速研发和弹性运营之间可能存在冲突。
313
314 这种方法背后的想法是变更具有潜在的破坏性，因此应谨慎控制。由于快速变化和谨慎变化是截然相反的目标，因此开发团队和IT运维通常无法有效地协作，因此IT和服务管理的从业人员必须缩小差距。
315
316 这种张力基于熟悉的心理模型，其中变更破坏了稳定性，而稳定性控制变更发生的变化：变化越少，稳定性的风险就越低。最近，出现了另一种思维方式。变更大小的减少会减少中断的风险。较小的变更还意味着变更可以更频繁地发生。通过更频繁地进行变更，可以提高组织的变更能力。变更能力的提高反过来又降低了中断的风险。图4.6演示了变更大小的影响。
317
318 DevOps社区已经接受了这种思维方式，并且已经开发了适当的实践和支持技术。研究发现，在部署频率、变更准备时间和变更失效率方面的高性能与版本控制、持续交付和自动化测试相关。研究还表明，在团队中基于同行评审的变更批准的风险不比使用变更顾问委员会的风险低。
319
320
321 (% style="text-align:center" %)
322 [[image:1639234096344-870.png]]
323
324 图4.6 影响大小的变更可用于实现快速研发的技术包括：
325
326 * 基础架构即代码
327 * 松耦合信息系统架构
328 * 评论
329 * 持续业务分析
330 * 持续集成/持续交付
331 * 连续测试
332 * 看板
333
334 **ITIL故事：快速研发的技术**
335
336 //Solmaz：我们不断开发新的应用功能，并定期且频繁地发布改进和变更。这有助于我们更早地实现价值并尽快收到反馈。它还使我们能够优先考虑开发的新功能和支持工作。因为变更很小，所以它们需要较少的支持，并且服务中断的风险也较少。//
337
338
339 === 4.2.1 基础架构即代码 ===
340
341 基础架构即代码（IaC）支持更快的环境配置，从而有助于更快的开发和更有弹性的运营。虚拟化和虚拟机管理程序技术（通常通过云提供）允许通过编程接口远程创建、修改和删除基础架构项目。如今，使用脚本和配置文件来构建和配置服务器是一种常见的做法。
342
343 IaC是一种通过使用机器可读的定义文件而不是物理配置硬件组件来管理和配置IT基础架构和平台的方法。然后可以将这些文件存储在版本控制系统中（请参阅第4.3.4节中的版本控制）。
344
345 幂等性的概念是IaC的关键。这意味着部署命令始终将目标环境配置为指定的状态，而不管它以前是什么状态。这可以通过重新配置目标环境或用新的环境来实现。为此，需要对环境描述进行变更，并创建新版本的配置模型。该代码经过验证和测试，以防止常见的部署问题。发布流水线执行配置模型，从而产生新的（重新）配置的目标环境。如果需要变更，则编辑源，而不编辑目标。Vagrant、Ansible、Puppet和Docker等工具支持整个流程。基础架构即服务（IaaS）和平台即服务（PaaS）等基于云的解决方案使用IaC定义来动态配置和删除环境。然后，团队可以根据需求可靠地配置多个测试环境。这使他们能够在开发周期的早期阶段在类似生产环境中测试应用程序。
346
347 选择使用IaC而不是传统的物理配置是一项架构设计决策，影响深远。架构的本质是选择要使用的构件或资源，以及如何使用它们。基础架构和平台的数字化可以更快，更可靠地配置所有必要的环境，例如开发、测试和生产，从而有助于快速研发和部署。这对于实现弹性运营也同样重要，因为它可以从某些事件中更快地恢复，并通过减少人为的错误来防止其他事件，例如手动错误配置和配置漂移。IaC效率更高，因为它具有较少的可重复手动操作，从而通过降低基础架构成本来促进宝贵的投资。
348
349 图4.7显示了IaC对服务价值链的贡献。
350
351
352 (% style="text-align:center" %)
353 [[image:1639234145163-398.png]]
354
355 图4.7 基础设施作为代码对服务价值链的贡献的热图
356
357 ‘
358
359 表4.5 与基础设施作为代码相关的实践
360
361 (% style="width:825px" %)
362 |**ITIL管理实践**|(% style="width:560px" %)**与基础设施作为代码相关的活动/资源**|(% style="width:90px" %)**影响**
363 |架构管理|(% style="width:560px" %)验证架构决策并比较基础架构解决方案。|(% style="width:90px" %)H
364 |变更控制|(% style="width:560px" %)启用虚拟基础架构组件的快速配置或停用，以平衡交付速度与治理，风险和合规性需求。|(% style="width:90px" %)H
365 |部署管理|(% style="width:560px" %)自动化基础架构的部署，确保基础架构和应用程序的部署更快，更重复，更可靠。|(% style="width:90px" %)H
366 |信息安全管理|(% style="width:560px" %)在虚拟基础架构组件中设计和实施安全策略。|(% style="width:90px" %)H
367 |IT资产管理|(% style="width:560px" %)跟踪分配给通常快速配置或停用的虚拟基础结构组件的商业软件许可证的使用。|(% style="width:90px" %)H
368 |知识管理|(% style="width:560px" %)存储虚拟服务器配置文件，并使它们可用于IaC自动化。|(% style="width:90px" %)H
369 |服务配置管理|(% style="width:560px" %)以适当的粒度级别设计和维护配置管理数据库和关系，以跟踪经常快速调配或退役的虚拟基础架构组件。|(% style="width:90px" %)H
370 |服务财务管理|(% style="width:560px" %)由于对基础设施的投资减少，资金从资本支出转向运营支出。|(% style="width:90px" %)H
371 |服务请求管理|(% style="width:560px" %)自动配置或停用虚拟基础架构组件。|(% style="width:90px" %)H
372 |服务验证与测试|(% style="width:560px" %)设计和维护测试用例，以确保虚拟IaC满足组织要求和策略。|(% style="width:90px" %)H
373 |软件开发管理|(% style="width:560px" %)开发软件体系结构和代码，以利用虚拟硬件基础结构的快速交付/配置。|(% style="width:90px" %)H
374 |事件管理|(% style="width:560px" %)利用IaC功能自动化（在适当情况下）事件恢复任务。|(% style="width:90px" %)M
375 |基础架构管理|(% style="width:560px" %)快速交付/配置虚拟硬件基础架构。|(% style="width:90px" %)M
376 |问题管理|(% style="width:560px" %)利用IaC功能进行问题检测和错误控制。|(% style="width:90px" %)M
377 |服务连续性管理|(% style="width:560px" %)设计适当的连续性计划以反映组织对IaC功能的使用。|(% style="width:90px" %)M
378 |供应商管理|(% style="width:560px" %)选择可以提供IaC功能或利用组织对IaC的投资的供应商。|(% style="width:90px" %)M
379 |风险管理|(% style="width:560px" %)认识到通过使用IaC引入或减轻的风险。|(% style="width:90px" %)L
380
381 表4.5 列出了与基础设施作为代码相关的实践。
382
383
384 **ITIL故事：基础架构即代码**
385
386 //Marco：在测试环境下，我们在虚拟机上使用虚拟机监控程序技术创建了多个测试环境。我们想在多个平台上模拟该应用程序的使用。因为我们在开发周期的每个阶段都对代码进行了验证，所以我们知道该应用程序将随着它的增长而继续在不同的设备上运行。//
387
388
389 === 4.2.2 松耦合信息系统架构 ===
390
391 松耦合信息系统架构基于相对较小的独立组件。该架构使工作能够在相对较小的，相对独立的，基于产品或服务的团队和基于平台的团队中完成。通过将系统分解为可以相对独立地开发和管理的部分，团队可以专注于自己的部分并限制与其他团队的互动。基于产品或服务的团队由开发人员和工程师以及代表消费者观点的产品/服务所有者组成。更紧密的协作对快速研发和价值共创都是有益的。它还有助于进行有价值的投资、快速研发和弹性运营（其中IT运维也在团队中出现）。
392
393 紧密耦合的体系结构（例如在单片信息系统中）的最大问题之一是变更的速度极低，因为许多变更都需要重新设计和重新开发系统的多个部分。实际上，在同一系统上增加更多的团队和员工可能会降低速度，因为这可能导致体系结构级别的组件之间的深度互连过多。
394
395 一个密切相关的技术是应用程序绞杀。这可用于逐渐围绕旧应用创建新应用，然后用新代码慢慢替换旧代码。当无法重构应用程序（在不变更其功能的情况下重构代码）并且必须替换它时，这很有用。此技术可能会损害性能和可靠性，因此，如果使用此技术，则需要仔细的监督实施。
396
397 微服务和容器化等技术通常与松耦合的体系结构相关。
398
399
400 **定义**
401
402 * **微服务 **面向服务的体系架构的一种变体，其中应用程序被设计和开发为一组小型的、松散耦合的服务，每个服务都在自己的流程中运行并使用轻量级机制进行通信。
403 * **容器化 **将软件打包为标准化的轻型，独立，可执行单元以进行开发，运输和部署的技术。
404
405 松散耦合的信息系统体系架构的优点包括：
406
407 * 它有助于更快的开发和更频繁的变更。
408 * 它支持演进架构。
409 * 它效率更高，导致重新设计和开发产品或服务所需的工作更少。
410 * 它使从专注于组件的团队结构切换为基于产品或功能的团队结构。图4.8显示了松散耦合信息系统架构对服务价值链的贡献。表4.6概述了与松散耦合信息系统架构相关的实践。
411
412 **ITIL故事：松耦合信息系统架构**
413
414 //Su：我们在应用程序中使用了松耦合信息系统架构。通过将系统视为相对较小且独立的组件，每个组件上的团队可以独立工作，因为他们了解组件会接收的输入以及工作流中后续组件所需的输出。这减少了不同组件之间的重复、复杂性和相互依赖性//该应用程序。
415
416
417 (% style="text-align:center" %)
418 [[image:1639234221475-444.png]]
419
420 图4.8 松散耦合信息系统架构对服务价值链贡献的热图
421
422
423 表4.6 与松散耦合信息系统架构相关的实践
424
425 (% style="width:718px" %)
426 |(% style="width:108px" %)**ITIL管理实践**|(% style="width:520px" %)**与松散耦合信息系统架构相关的活动/资源**|(% style="width:87px" %)**影响**
427 |(% style="width:108px" %)架构管理|(% style="width:520px" %)设计松耦合的服务，技术和信息体系结构。|(% style="width:87px" %)H
428 |(% style="width:108px" %)业务分析|(% style="width:520px" %)了解消费者需求并将其转化为每个需求的详细需求松耦合服务体系结构的组件。|(% style="width:87px" %)H
429 |(% style="width:108px" %)部署管理|(% style="width:520px" %)部署的范围和部署模式因以下因素的解耦而减小：系统架构；这使部署更易于管理和复制，并且功能强大自动化的候选人。|(% style="width:87px" %)H
430 |(% style="width:108px" %)信息安全管理|(% style="width:520px" %)为松散耦合的服务设计和管理信息安全策略、服务组件。|(% style="width:87px" %)H
431 |(% style="width:108px" %)基础设施及平台管理|(% style="width:520px" %)松耦合基础架构的详细设计，构建，运行和管理和平台组件。|(% style="width:87px" %)H
432 |(% style="width:108px" %)问题管理|(% style="width:520px" %)研究问题并设计跨越多个松耦合系统的错误控制。|(% style="width:87px" %)H
433 |(% style="width:108px" %)服务配置管理|(% style="width:520px" %)设计和维护有关各种服务和服务组件的信息，以及他们的相互关系。|(% style="width:87px" %)H
434 |(% style="width:108px" %)服务级别管理|(% style="width:520px" %)通过与消费者的松耦合架构设计和调整服务级别服务消费方面的期望。|(% style="width:87px" %)H
435 |(% style="width:108px" %)软件开发管理|(% style="width:520px" %)松耦合软件的详细设计、构建、运行和管理组件。|(% style="width:87px" %)H
436 |(% style="width:108px" %)变更控制|(% style="width:520px" %)松散耦合的体系结构降低了与应用程序、基础架构变更相关的风险，如果这些变更失败。 较低的风险状况会导致变化在团队级别（而不是部门或组织级别）批准，从而减少了官僚。|(% style="width:87px" %)M
437 |(% style="width:108px" %)事件管理|(% style="width:520px" %)事件后可以计划调查和解决方案， 以更少的压力和更有效的方式进行演练。服务中断的影响松散耦合的体系结构通常限于无法使用的配置项（CI），而不是其他CI。这是由于系统组件的设计原理应该具有弹性，并且不依赖于其他配置项提供的服务。结果是，事件对客户的影响较小。|(% style="width:87px" %)M
438 |(% style="width:108px" %)服务财务管理|(% style="width:520px" %)松散耦合的系统体系结构使第三方服务的耦合和解耦更加容易，从而使服务提供商能够利用降价和提供新产品的优势。 这种灵活性还要求服务提供商采用敏捷成本核算模型来有效地切换提供商。|(% style="width:87px" %)M
439 |(% style="width:108px" %)供应商管理|(% style="width:520px" %)当某些组件松散时，建立合同并管理绩效。耦合体系结构由供应商或外部服务提供商提供。|(% style="width:87px" %)M
440 |(% style="width:108px" %)战略管理|(% style="width:520px" %)由于投资的原因，将紧密耦合的体系结构去耦是一项战略级决策必要条件以及利用它的潜在运营模式含义（例如引入自治团队）。 这种架构的一个例子是面向服务的可以将第三方服务作为端到端服务的一部分的体系结构。|(% style="width:87px" %)L
441
442 === 4.2.3 复查 ===
443
444 通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
445
446
447 ==== 4.2.3.1 回顾 ====
448
449 在敏捷中，回顾是在迭代（或称为“ 冲刺”）或项目结束时召开的团队会议，以讨论哪些进展顺利，哪些可以改进的方面以及将来如何从中受益。这种快速而频繁的反馈有助于快速研发。回顾可以应用于大多数场景以及需要不断改进的任何区域。为有效起见，应定期安排他们的时间，并由主持人安排参与者的贡献。应确定为持续改进而输入的行动，并委派责任。图4.9显示了回顾对服务价值链的贡献。
450
451
452 (% style="text-align:center" %)
453 [[image:1639234467928-357.png]]
454
455 图4.9 回顾对服务价值链贡献的热图
456
457
458 表4.7 与回顾相关的实践
459
460 (% style="width:965px" %)
461 |**ITIL管理实践**|(% style="width:722px" %)**与回顾相关的活动/资源**|(% style="width:77px" %)**影响**
462 |持续改进|(% style="width:722px" %)定期或在完成时审查持续改进计划的活动和技术，以了解是否正在实现预期的成果。|(% style="width:77px" %)H
463 |项目管理|(% style="width:722px" %)审查项目工作并汲取经验教训的活动和技术，可以使未来的类似项目受益。|(% style="width:77px" %)H
464 |服务级别管理|(% style="width:722px" %)定期检查和修改服务水平（以了解如何改进）的活动和技术。|(% style="width:77px" %)H
465 |软件开发管理|(% style="width:722px" %)定期审查工作以了解如何改进的活动和技术。|(% style="width:77px" %)H
466 |变更控制|(% style="width:722px" %)定期审查进行变更的有效性和效率以了解如何改进的活动和技术（包括有关创建或暂停标准变更模型的决定）。|(% style="width:77px" %)M
467 |事件管理|(% style="width:722px" %)定期或在重大事件后回顾事件管理工作的活动和技术，以了解如何改进。|(% style="width:77px" %)M
468 |问题管理|(% style="width:722px" %)定期检查问题和错误控制以了解如何改进的活动和技术。|(% style="width:77px" %)M
469 |关系管理|(% style="width:722px" %)定期审查与各种利益干系人之间现有关系的状态和方向的活动和技术。|(% style="width:77px" %)M
470 |风险管理|(% style="width:722px" %)定期或在触发缓解措施后审查缓解风险的活动和技术，以了解如何提高风险。|(% style="width:77px" %)M
471 |服务连续性管理|(% style="width:722px" %)从灾难恢复后，审查连续性计划的效率和有效性的活动和技术。|(% style="width:77px" %)M
472 |服务台|(% style="width:722px" %)定期检查服务台交互的活动和技术，以了解如何改进。|(% style="width:77px" %)M
473 |供应商管理|(% style="width:722px" %)定期审查与各种合作伙伴和供应商之间现有关系的状态和方向的活动和技巧。|(% style="width:77px" %)M
474
475 表4.7概述了与回顾相关的实践。
476
477
478 ==== 4.2.3.2 免责的事后反思 ====
479
480 数字化技术具有越来越重要的社会和经济后果，尤其是在HVIT环境中。因此，预防事故变得越来越重要。但是，复杂的系统具有固有的危险性：尽管付出了所有努力，但它们仍将失败。因此，从失效中学习也变得越来越重要。
481
482 事后检验是事件的正式记录，包括对事件的影响，解决/缓解工作，原因和防止再次发生的措施。当参与者能够分享自己的知识和选择而不必担心声誉和位置时，事后反思的质量会更好。这就是为什么重点关注事件的原因而不是谁引起了事件。这种免责的文化起源于医疗保健和航空业，那里生命受到威胁。免责事后反思与安全性文化和心理安全性密切相关（见第3.2.2.2节）。
483
484
485 **定义：事后反思**
486
487 对事件之前的情况和事件的非判断性描述和分析。
488
489 事后反思不仅对事件涉及的人员有用，还应与可能从结果中受益的其他人共享和阅读。与透明度和脆弱性建立信任并帮助价值共创，与包括消费者在内的广大社区分享研究结果也很重要。
490
491 与事后反思相关的良好行为包括：
492
493 * 作为'日常业务'的一部分进行事后反思的操作，并非例外
494 * 关注于引起事件的原因，而不是谁
495 * 广泛透明地共享结果，以学习和建立信任。
496
497 图4.10显示了免责事后反思对服务价值链的贡献。表4.8概述了与免责的事后反思相关的实践。
498
499
500 (% style="text-align:center" %)
501 [[image:1639234516010-953.png]]
502
503 图4.10 免责的事后反思对服务价值链的贡献的热图
504
505
506 **ITIL的故事：评论**
507
508 //Marco：使用该应用程序可能会很艰苦，但是回顾会给我们带来好处。我们会定期分析完成的工作，以便了解可以在下一个冲刺中汲取的经验教训。这些是不责怪的事后反思：我们公开且诚实地讨论我们的工作，而不必担心事件的起因会分配给任何团队成员。//
509
510
511 表4.8 免责的时候反思的实践
512
513 (% style="width:920px" %)
514 |**ITIL管理实践**|(% style="width:701px" %)**与无指责相关的活动/资源**|(% style="width:80px" %)**影响**
515 |变更控制|(% style="width:701px" %)调查成功和失败的变更，以发现机会，以提高未来变更的成功率。|(% style="width:80px" %)H
516 |部署管理|(% style="width:701px" %)调查服务组件的成功和失败部署，以发现机会，以提高未来部署的成功率。|(% style="width:80px" %)H
517 |事件管理|(% style="width:701px" %)调查事件管理（和重大事件管理）活动，以发现改进的机会。|(% style="width:80px" %)H
518 |问题管理|(% style="width:701px" %)调整领导方式以检查系统而不是人员。事后回顾可以帮助组织获得有关事件情况的更多信息。这为问题识别和调查提供了更好的信息。|(% style="width:80px" %)H
519 |项目管理|(% style="width:701px" %)调查项目活动，以吸取经验教训和改进未来项目的机会。|(% style="width:80px" %)H
520 |发布管理|(% style="width:701px" %)调查服务的成功和失败版本，以发现提高未来版本成功率的机会。|(% style="width:80px" %)H
521 |持续改进|(% style="width:701px" %)(((
522 调查持续改进活动，以识别经验教训，了解系统中的变更以及确定增加或保持未来改进成
523
524 功的机会。
525 )))|(% style="width:80px" %)M
526 |信息安全管理|(% style="width:701px" %)获取有关与安全漏洞和安全事件有关的情况的更多信息。|(% style="width:80px" %)M
527 |风险管理|(% style="width:701px" %)触发风险缓解措施后，评估其风险，以了解如何改进缓解措施以及对当前和未来风险的应对措施。修改风险记录并探索可能的风险的新领域。|(% style="width:80px" %)M
528 |服务台|(% style="width:701px" %)调查与外部利益干系人的互动，以发现改进互动和持续沟通的机会。|(% style="width:80px" %)M
529 |服务验证与测试|(% style="width:701px" %)调查成功和失败的验证和测试活动，以发现提高未来成功率的机会。|(% style="width:80px" %)M
530 |软件开发管理|(% style="width:701px" %)(((
531 从回顾中获取经验教训和改进思路。
532
533 让合作伙伴和供应商收集反馈以进行学习注册。
534 )))|(% style="width:80px" %)M
535
536 === 4.2.4 持续业务分析 ===
537
538 瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。
539
540 做出投资决定后，至关重要的是要验证对产品或服务规范、特性和功能所做的任何初始假设。一些供应商忽略了与真实用户尽快进行交互的需要，而是在向客户和用户展示其解决方案之前在开发上花费了几个月甚至几年的时间。通常，采用这种方法时，产品或服务的某些功能是不必要的，某些功能需要进行重大调整，而其他有价值的功能却会丢失。但是，组织的资源和时间已经用完，营销机会正在减少。
541
542 一种更好的开发方法是尽早实现反馈循环。正确的反馈循环可以提供有关产品或服务开发方向的有价值的信息。为了使反馈循环有用，迭代开发非常重要。为此可以使用最小可用方法（请参阅第4.1.2节）。图4.11说明了这一概念。
543
544
545 (% style="text-align:center" %)
546 [[image:1639234557151-851.png]]
547
548 图4.11通过迭代方法更快地实现价值
549
550
551 过去，需求总是在项目开始时在利益干系人和被分配了临时的、基于项目的任务的业务分析人员之间的正式讨论中定义的。这些要求将成为发展活动的规范。
552
553 但是，越来越多地基于反馈来开发和改进产品。反馈可以由用户报告或间接观察。需求分析和说明是持续进行的。业务分析通常不再由专门的业务分析人员执行；它是可以与其他角色组合使用的角色。使用这种方法时，由于已经建立了产品架构，因此进一步的开发可能具有挑战性。因此，开发之前的分析应考虑这些未来的问题，并创建一个灵活的架构。开发之后的分析与开发之前的分析不同之处在于，开发后的分析较少关注于创建架构，而更关注于在系统的体系结构约束下有效地工作。
554
555 图4.12显示了持续业务分析对服务价值链的贡献。表4.9概述了与持续业务分析相关的实践。
556
557
558 **ITIL故事：持续业务分析**
559
560 //Radhika：ITIL 指导原则对业务中的每个团队都有用。例如，聚焦价值原则可恰好适合业务分析。环境不断变化，开发中的功能优先级可能会变得更高或更低，这取决于价值如何受到影响。例如，影响应用程序使用或数据存储的新法规将自动成为高度优先事项。//
561
562
563 (% style="text-align:center" %)
564 [[image:1639234577551-314.png]]
565
566 图4.12 持续业务分析对服务价值链贡献的热图
567
568
569 表4.9 与持续业务分析相关的实践
570
571 (% style="width:900px" %)
572 |**ITIL管理实践**|(% style="width:682px" %)**与持续业务分析相关的活动/资源**|(% style="width:96px" %)**影响**
573 |业务分析|(% style="width:682px" %)持续了解分析客户、市场状况和更广泛的生态系统，以了解他们对组织产品和服务的影响。|(% style="width:96px" %)M
574 |基础架构管理|(% style="width:682px" %)持续了解分析客户、状况和更广泛的生态系统，以了解他们对组织的基础架构和平台产品的影响。|(% style="width:96px" %)M
575 |组合管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织投资各种产品和服务的方式的影响。监控正在进行的组合投资，以识别价值或验证价值共创。|(% style="width:96px" %)M
576 |项目管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统了解它们对组织项目和相关业务案例的影响。|(% style="width:96px" %)M
577 |关系管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织与外部利益干系人关系的影响。|(% style="width:96px" %)M
578 |风险管理|(% style="width:682px" %)持续分析内部和外部公司风险，以评估和了解其对组织产品和服务的影响，并设计适当的缓解措施和对策。|(% style="width:96px" %)M
579 |服务设计|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解其对客户和用户体验组织产品和服务的影响。|(% style="width:96px" %)M
580 |软件开发管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织软件产品的影响以及正在进行的软件开发工作的优先级。|(% style="width:96px" %)M
581 |战略管理|(% style="width:682px" %)持续监视和评估客户，市场状况以及更广泛的生态系统，以了解其对组织产品和服务的影响，并相应地调整策略。|(% style="width:96px" %)M
582 |架构管理|(% style="width:682px" %)持续分析组织内部和外部利益干系人对技术的使用，以了解其对组织的技术，服务和信息体系结构的影响。|(% style="width:96px" %)M
583 |知识管理|(% style="width:682px" %)不断了解分析客户，市场状况和更广泛的生态系统，以在相关利益干系人之间建立共识。|(% style="width:96px" %)M
584 |服务连续性管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，它们对组织的连续性和灾难恢复措施的影响。|(% style="width:96px" %)M
585 |供应商管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以它们对组织与合作伙伴和供应商关系的影响。|(% style="width:96px" %)M
586
587 === 4.2.5 持续集成、持续交付和持续部署 ===
588
589 持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。
590
591
592 **定义**
593
594 * **持续集成 **一种在软件开发环境中集成、构建和测试代码的方法。
595 * **持续交付 **一种软件开发的方法，其中可以随时将软件发布到生产环境中。可以进行频繁部署，但是部署的决定要视具体情况而定，通常是因为组织更喜欢较慢的部署速度。
596 * **持续部署 **一种软件开发的方法，其中的变更会通过流水线进行，并自动放入生产环境中，从而每天可以进行多个生产部署。持续部署依赖持续交付。
597
598 CI / CD有助于快速研发，并且由于部署更可靠，因此有助于弹性运营。
599
600 持续集成是每次提交代码时在构建和代码测试过程中实现的自动化，从而导致对版本控制进行变更。持续集成通过将变更合并到集中共享的代码存储库中，在软件开发社区中促进了代码共享的实践。代码提交触发自动构建功能，以从共享的版本控制存储库和构建，测试中提取最新的代码提交，并验证完整的主分支（即主干）。
601
602 由于软件开发具有隔离性，因此持续集成已成为一种惯性时间内，因此开发人员需要在变更与开发团队其余代码之间保持恒定的集成点。漫长的等待周期会导致合并冲突，解决路径困难的错误，不同的代码策略以及重复的工作。持续集成的主要目的之一是使主分支免受异常和错误的影响。软件开发团队可以建立分支机构策略，以确保主分支符合某些预先约定和预先授权的质量标准。
603
604 持续交付的重点在是构建和测试新版本并将其发布到生产环境的过程。这需要阶段发布环境，阶段发布环境已成为发布流水线的一部分，以自动化基础设施配置和新版本的部署。
605
606 持续交付是一种精益实践。其目标是保持无事故的生产环境正常运行。这是通过发现从版本控制存储库中的新代码的可用性到包装管理（用于部署）的最短路径来实现的。
607
608 持续交付依赖于部署模型的渐进部署环的概念。第一个部署环通常是组织的内部IT团队或其他相关的内部用户组访问的生产环境中的“ 金丝雀发布”。连续的部署循环欢迎更多的用户。这些后续的部署循环可能需要关键决策者的批准。如果组织使用这些循环进行部署，则通常采用相同的方法进行发布管理。
609
610 另一个部署模型使用“ 蓝绿部署”的概念，即现有版本在一个生产环境（称为“蓝色”）中运行，而新的版本部署到相同的“绿色” 环境。通常，负载平衡用于将有限数量的用户重定向到“绿色” 版本。如果出现事件，则可以将流量重新路由到“蓝色” 版本。否则，“绿色” 环境成为默认的，而“蓝色” 环境用于下一个部署。
611
612 图4.13显示了CI / CD对服务价值链的贡献。表4.10概述了CI / CD最相关的实践。
613
614
615 (% style="text-align:center" %)
616 [[image:1639234626691-221.png]]
617
618 图4.13 CI/CD对服务价值链贡献的热图
619
620
621 表4.10 与CI/CD最相关的实践
622
623 (% style="width:852px" %)
624 |**ITIL管理实践**|(% style="width:651px" %)**与CI/CD最相关相关的活动/资源**|(% style="width:84px" %)**影响**
625 |变更控制|(% style="width:651px" %)可以根据业务需求和期望，使用CI / CD管道来调整组织产品和服务的变化率。|(% style="width:84px" %)H
626 |部署管理|(% style="width:651px" %)系统地/自动地将特定版本的软件或软件包安装到预定的环境（集成，用户验收测试，生产）。|(% style="width:84px" %)H
627 |基础机构管理|(% style="width:651px" %)将CI / CD技术用于数字基础架构。|(% style="width:84px" %)H
628 |发布管理|(% style="width:651px" %)认识到软件的部署和功能的发布通常是有助于计划和管理发布的不同活动。|(% style="width:84px" %)H
629 |服务配置管理|(% style="width:651px" %)管理代码存储库和构成CI / CD工具链一部分的相关工具，并不断更新CMDB以反映进行了重大（CI级别）变更的时间。|(% style="width:84px" %)H
630 |服务验证与测试|(% style="width:651px" %)开发自动化测试用例以支持持续的集成活动。|(% style="width:84px" %)H
631 |软件开发管理|(% style="width:651px" %)使用用于应用程序软件的CI / CD技术。|(% style="width:84px" %)H
632 |架构管理|(% style="width:651px" %)设计和改进服务，技术和信息体系结构以利用CI / CD功能。容器化是支持CI / CD的体系结构选择。|(% style="width:84px" %)M
633 |信息安全管理|(% style="width:651px" %)通过减少手工工作来确保遵守信息安全合规。通过利用CI / CD工具来增加自动化的规模和范围，可以通过减少手工工作并改进变更的可追溯性来帮助确保遵守信息安全合规。|(% style="width:84px" %)M
634 |知识管理|(% style="width:651px" %)不断更新知识库，以确保组织保持对通过CI / CD管道构建和部署的软件的最新了解。|(% style="width:84px" %)M
635 |服务连续性管理|(% style="width:651px" %)应该建立CI / CD管道以将软件组件推向连续性和灾难恢复系统。|(% style="width:84px" %)M
636 |风险管理|(% style="width:651px" %)通过使用CI / CD自动化减少某些类型的企业风险的影响。|(% style="width:84px" %)L
637
638 **ITIL故事：持续集成、持续交付和持续部署**
639
640 //Marco：我们已经为该应用程序创建了相同的构建、测试和实时环境，这使我们能够不断集成和交付与现有代码库兼容的新代码。因此，我们可以使用已经有效的代码来高度开发该应用程序。我们还减少了由可能导致难以解决的路径的错误引起的事件。//
641
642
643 === 4.2.6 持续测试 ===
644
645 软件测试不仅涉及测试已开发的和可运行的软件。测试是应该在整个软件开发生命周期中进行的工作。表4.11概述了不同类型的测试。
646
647
648 表4.11 软件测试的类型
649
650 (% style="width:813px" %)
651 |(% style="width:165px" %)测试思路|(% style="width:646px" %)所有软件都源于一个想法，通常是试图解决问题的尝试。 测试该想法有助于从客户角度（基于需求和需求）和业务角度（基于指标，包括增长，收入，转化和用户基础）确定其质量。
652 |(% style="width:165px" %)测试原型|(% style="width:646px" %)原型，例如史诗，用户故事，验收标准，数据流程图和过程流程图，应进行测试。 检查原型内的信息可以帮助识别与风险和变量有关的歧义，假设和信息。 该信息可用作反馈，以帮助审查和改进伪像。
653 |(% style="width:165px" %)测试用户体验和用户界面设计|(% style="width:646px" %)原型用于设计活动，编程活动和测试活动。 设计活动产生的设计原型超出了可以测试的范围。 使用相关的原型对界面和体验进行了测试，并且测试结果可能会影响其他原型。
654 |(% style="width:165px" %)测试架构和代码设计|(% style="width:646px" %)在设计软件体系结构并讨论如何构建它和新功能时，探索性测试可以增强设计和思想。
655 |(% style="width:165px" %)代码测试|(% style="width:646px" %)代码审查是构建高质量产品的重要组成部分。任何人都应该能够阅读该代码并从不同的角度对其进行测试。单元测试可验证软件的每个单元是否都能正常运行。单元测试通常是自动化的。重要的是要注意，这是软件开发生命周期中的第一点，应该有针对性地加以衡量。
656 |(% style="width:165px" %)测试操作软件|(% style="width:646px" %)测试操作软件是与测试相关的最常见的活动。开发后，许多敏捷团队都将“测试”作为其工作流中的一种状态。但是，测试不应该成为工作流程中的一种状态。它应该是在软件开发生命周期中进行的一系列结构化活动。
657 |(% style="width:165px" %)在不同环境测试|(% style="width:646px" %)当涉及测试环境时，基于风险的方法可能是合适的。有很多风险可以测试。其中一些无法在开发环境中进行测试。对于其他人，则需要严格集成的环境来进行测试。某些风险只能在实际生产环境中进行测试。
658 |(% style="width:165px" %)测试发布管道|(% style="width:646px" %)可以测试管道流程，团队通常会隐式地进行测试，以使其管道尽可能高效和快速地进行增强。这需要对管道测试背后的结构有充分的了解。
659 |(% style="width:165px" %)生产环境下测试|(% style="width:646px" %)(((
660 必须在生产环境中对某些风险进行测试，例如性能风险（尤其是用户负载和用户压力风险），用户接受度测试（用户将其与实际软件一样使用系统）和可观察性风险（以测试有效性、可观察性解决方案和实现）。
661
662 在生产中进行测试时，目标应该是最大程度地降低影响客户的测试风险。实现这一目标的策略包括：
663
664 ● **金丝雀发布 **这项新功能最初是针对少数目标用户发布的，后来逐渐增加到所有用户。
665
666 ●** 功能开关** 可以将功能隐藏在功能标志的后面，通过打开或关闭该标志可以轻松启用或禁用
667
668 该功能。
669
670 ● **蓝/绿部署 **两个相同的生产环境同时运行（一个“蓝色”和一个“绿色”），只有一个环
671
672 境处于活动状态，为所有生产流量提供服务，而另一个用于部署新版本。
673
674 ● **自动化的回滚策略 **发生事件时，自动化工具可以快速将发行版恢复为先前版本。
675 )))
676 |(% style="width:165px" %)测试生产环境中的服务|(% style="width:646px" %)为已发布的生产软件实现了许多服务，活动和技术，所有这些都可以进行测试。从服务交付的角度来看，测试流程很重要。 例如，在测试用户是否可以访问支持时，重要的是要问用户获得支持有多容易，用户在软件中在什么情况下做到这一点。
677
678 为了实现持续测试，应制定一些原则，包括：
679
680 * 测试应该以最低级别进行。
681 * 外部依存关系最少的测试应该受到青睐。
682 * 编写一次即可在任何地方运行，包括在生产系统中。
683 * 产品的设计应具有可测试性。
684 * 测试代码是产品代码;只有可靠的测试才能生存。
685 * 测试基础架构是共享的服务。
686 * 测试的所有权跟随产品所有权。
687 * 在生产中应进行故障注入和混沌工程测试服务弹性
688 * 不可靠的测试应消除。
689
690 图4.14显示了持续测试对服务价值链的贡献。表4.12概述了与持续测试最相关的实践。
691
692
693 (% style="text-align:center" %)
694 [[image:1639234708265-714.png]]
695
696
697 图4.14 持续测试对服务价值链贡献的热图
698
699
700 表4.12 与持续测试最相关的实践
701
702 (% style="width:834px" %)
703 |**ITIL管理实践**|(% style="width:641px" %)**与持续测试相关的活动/资源**|(% style="width:79px" %)**影响**
704 |架构管理|(% style="width:641px" %)设计和改进服务，技术和信息架构，以利用CI / CD功能|(% style="width:79px" %)H
705 |服务验证与测试|(% style="width:641px" %)在整个开发生命周期中，将持续进行单元，集成和回归测试。这包括应用程序单元测试，基础结构服务测试，功能/非功能测试，canary版本，蓝/绿测试以及基础结构安全性测试。|(% style="width:79px" %)H
706 |部署管理|(% style="width:641px" %)导致连续测试失败的变更或部署会触发团队的告警线。然后，团队成员蜂拥而至以解决问题。|(% style="width:79px" %)M
707 |信息安全管理|(% style="width:641px" %)通过减少手工工作来确保遵守信息安全合规。利用自动化测试工具，可以减少手工工作并提高变更的可追溯性，从而有助于确保遵守信息安全合规。|(% style="width:79px" %)M
708 |问题管理|(% style="width:641px" %)自动化测试有助于验证问题的解决方案，已知错误的存在或规避措施的有效性。|(% style="width:79px" %)M
709 |服务连续性管理|(% style="width:641px" %)自动化测试可以加速提供从灾难中恢复所需的技术资源。|(% style="width:79px" %)M
710 |风险管理|(% style="width:641px" %)使用测试自动化减少某些类型的企业风险的影响。|(% style="width:79px" %)L
711
712 **ITIL的故事：持续测试**
713
714 //Su：我们投放市场的每个产品都经过全面测试，以确保它是符合目 的并适合使用。应用程序的改进没有什么不同。我们测试了//：
715
716 ●     新功能的初步构想，以确保它们有潜力实现我们的目标
717
718 ●     史诗、用户故事和接受标准
719
720 ●     设计界面的改进，以确保它直观且易用
721
722 ●     代码设计和软件架构，以确保其健壮性
723
724 ●     修复开发期间引入的错误和故障的代码
725
726 ●     生产中的系统和软件
727
728 //在每个阶段，如果测试表明我们引入了明显的低效或缺陷，我们就会重新考虑以前的决定。//
729
730
731 === 4.2.7 看板 ===
732
733 看板是一套原则、实践和常规活动，旨在开发和管理可预测的，有节奏的，持续的工作流程。如果正确应用，它可以极大地加速高质量产品和服务的开发。拉动式触发机制使客户能够通过价值流进行工作。拉动式的工作具有不会被强加于人的优点，从而不必要地增加了工作负担。这在精益团队中很有价值，因为过载是浪费的一种形式。
734
735
736 **定义：看板**
737
738 一种基于高度可视化基于拉动的工作流程的精益方法，该工作流程通过平衡需求与可用的容量并改进对系统级别瓶颈的处理，来管理和改进整个人系统的工作。
739
740 看板的主要做法是：
741
742 * 可视化工作
743 * 限制进行中的工作
744 * 管理流程
745 * 明确制定流程政策
746 * 实施反馈循环
747 * 改进协作
748 * 实验性地发展。
749
750 有时组织仅使用看板来可视化进行中的工作。尽管使用看板很重要，但这是看板的有限应用。看板的功能取决于整体实施和对工作流程的持续关注。看板示例如图4.15所示。
751
752 (% style="text-align:center" %)
753 [[image:1639568393888-457.png]]
754
755 图4.15 看板的一个例子
756
757
758 看板建议定期召开会议，以确保有效的沟通。该系统通常被称为“ 看板节奏”。节奏的频率特定于组织，应根据情况进行定义和调整。会议是：
759
760 * 战略评审
761 * 运营评审
762 * 风险评审
763 * 服务交付评审
764 * 补充会议
765 * 交付规划会议。
766
767 图4.16显示了看板对服务价值链的贡献。表4.13概述了与看板相关的实践。
768
769
770 **ITIL故事：看板**
771
772 //Radhika：我们使用看板来可视化我们应用程序的工作流程，以便我们可以跟踪瓶颈。通常可以通过额外的资源或重新设计工作流来消除这些问题。看板的视觉特性使核心开发团队之外的同事和利益干系人能够了解工作的进展情况，从而使他们能够更好地计划并创建更多价值。//
773
774
775 (% style="text-align:center" %)
776 [[image:1639568494739-564.png]]
777
778 图4.16 看板对服务价值链贡献的热图
779
780
781 表4.13 与看板相关的实践
782
783 (% style="width:804px" %)
784 |**ITIL管理实践**|(% style="width:524px" %)**与看板相关的活动/资源**|(% style="width:70px" %)**影响**
785 |变更控制|(% style="width:524px" %)通过限制进行中的工作，可视化并改进对服务和服务组件的变更流程。|(% style="width:70px" %)H
786 |持续改进|(% style="width:524px" %)可视化并改进SVS中的改进流程。|(% style="width:70px" %)H
787 |项目管理|(% style="width:524px" %)可视化并改进跨项目和团队的工作流程。|(% style="width:70px" %)H
788 |发布管理|(% style="width:524px" %)可视化并提高发布给消费者的质量。|(% style="width:70px" %)H
789 |软件开发管理|(% style="width:524px" %)可视化和改进新的或变更的软件组件进入实时环境的流程。|(% style="width:70px" %)H
790 |事件管理|(% style="width:524px" %)通过限制进行中的工作来可视化并提高事件解决的速度和质量。|(% style="width:70px" %)M
791 |组合管理|(% style="width:524px" %)可视化并改进整个投资组合管道中的投资流程。|(% style="width:70px" %)M
792 |问题管理|(% style="width:524px" %)通过限制进行中的工作来可视化并改进问题和错误控制。|(% style="width:70px" %)M
793 |供应商管理|(% style="width:524px" %)可视化供应商的入职/离职进度。|(% style="width:70px" %)M
794
795 == 4.3 弹性运营的技术 ==
796
797 弹性运营目标涉及确保在需要时可以使用数字化产品。
798
799 数字投资的潜在价值仅当投入使用的数字化产品和服务可用时才能实现。满足非功能性要求提供了功效，并降低了问题将严重影响产品和服务的功用的风险。
800
801 信息系统越来越依赖于如此众多的组件，以至于行为通常无法被预测或保证。故障安全系统是一种幻想。组织必须为不可避免的和意外的失效做准备。重点不再是在失效之间保持较长的间隔；当不可避免的问题确实发生时，它可以快速恢复服务。这样可以减少对业务运营的干扰。
802
803 弹性适用于系统堆栈的所有部分，也适用于管理这些组件部分的组织。只有每个组件都具有弹性时，面向消费者的部件才具有弹性。弹性运营不会增加潜在的价值投资；相反，他们确保可以实现其潜在的价值。由于信息系统很复杂，因此本质上容易出错，因此弹性涉及损害限制。根据系统的性质，损害可以用收入损失、价格降低，产生的成本和声誉损害来表示。例如，当电子商务网站的可用性或性能较差时：
804
805 * 如果客户转向其他提供商，收入将会损失
806 * 客户满意度降低而产生价格降低的压力
807 * 恢复服务，实施规避措施以及与消费者进行沟通会产生成本
808 * 当提供者不能很好地处理事件时，会造成声誉损害；例如，不采取适当的行动，不关心，隐瞒信息或不从事件中汲取教训。
809
810 IT的消费化导致人们期望随时随地可以使用公司的IT系统。云服务能力可以极大地改进弹性，而云功能的成本仅为本地系统的一小部分。弹性系统和服务不再是一种选择，由于云和IT的消费化，它们已成为现实的期望。
811
812 根据可用性、性能和安全性来衡量弹性操作。可用性是两次失效之间的平均时间和恢复服务的平均时间以百分比规范。众所周知，可用性不可靠，不能说明可用性对服务使用者的影响。这也很难衡量；例如，当系统部分可用时。
813
814 绩效的测量方法多种多样。例如，网页加载时间、数据查询执行时间或批处理流程完成时间。可以根据安全漏洞来衡量安全，但这仅衡量已检测到的漏洞。更好的指标是控制监控的成熟度，以及分析日志信息以识别风险和漏洞的能力。
815
816 可用于实现弹性运营的技术包括：
817
818 * 技术债
819 * 混沌工程
820 * 完成的定义
821 * 版本控制
822 * 人工智能运营
823 * 聊天运营
824 * 站点可靠性工程。
825
826 **ITIL故事：弹性运营的技术**
827
828 //亨利：我们的应用程序必须可靠且一致，否则我们的客户将其视为有缺陷的。如果他们的工作方式需要变更，我们还需要确保我们的团队有应变能力并且可以适应不同的条件。//
829
830
831 === 4.3.1 技术债 ===
832
833 **定义：技术债**
834
835 通过选择规避措施而不是需要更长时间的系统解决方案来累积待办项的返工。
836
837 在软件开发和管理中，技术债是修复不合格（变更）软件所需的返工待办项。通常，当使用软件时，将进行增强和修复。应用这些变更后，除非努力限制损坏，否则软件的质量将会下降。这被称为“软件熵”，它与HVIT密切相关，因为在软件上的大量投资，变更的频率以及需要变更迅速跟上市场需求的需求。
838
839 技术债是待办的工作，用于解决在增强或修复软件时引起的损坏。这种损坏通常是由于时间、金钱、知识和技能有限所造成的。例如，在软件出现故障时承受恢复正常服务压力的组织可以应用简单的规避措施来快速解决问题。通常有意在以后对其进行正确修复，但是在许多情况下，这不会发生。预期的“正确修复”可能未正式记录，随后将被遗忘。
840
841 技术债也可以在应用程序的初始开发期间发生，在此之前，期限或预算限制导致出现捷径。几乎每个项目都有其遗产，这有时使其捐助者感到惊讶。
842
843 技术利益是指由于质量下降而使变更难以进行的软件应用变更所涉及的成本之和，以及由这些缺陷引起的事件成本。只要利息不高，技术债就是可以接受的。但是，它倾向于积累，并且债务越高，涉及的风险就越大。此风险必须加以管理。
844
845 减少技术债可以减少事件的发生，因此有助于弹性运营。它还有助于有价值的投资和快速研发。这些收益之间应保持平衡。因此，应谨慎考虑技术债的存在，尽可能对其进行鉴定和量化，评估相关的短期和长期风险，并作为（软件）产品管理的一部分做出适当的决定，包括将预算分配给“偿还技术债“（另请参阅第4.3.7节中的错误预算的概念）。
846
847 图4.17显示了技术债对服务价值链的贡献。
848
849 表4.14概述了与技术债相关的实践。
850
851
852 **ITIL故事：技术债**
853
854 //Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
855
856 //Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
857
858
859 (% style="text-align:center" %)
860 [[image:1639568670048-316.png]]
861
862 图4.17 技术债对服务价值链贡献的热图
863
864
865 表4.14 与技术债相关的实践
866
867 (% style="width:702px" %)
868 |**ITIL管理实践**|(% style="width:545px" %)**与技术债相关的活动/资源**|(% style="width:70px" %)**影响**
869 |事件管理|(% style="width:545px" %)解决事件和管理事件需要了解现有的技术债及其解决方案。|(% style="width:70px" %)H
870 |基础架构管理|(% style="width:545px" %)通过创建或修改基础架构和平台服务组件来识别和减少技术债。|(% style="width:70px" %)H
871 |知识管理|(% style="width:545px" %)确保所有相关的利益干系人都可以访问最新信息。|(% style="width:70px" %)H
872 |组合管理|(% style="width:545px" %)决定是否投资资源来解决实时产品和服务中存在的技术债，并了解对投资对未来产品和服务的影响。评估技术债，以便可以将新的投资组合项目引入现有资产池。评估当前投资组合项目的技术债，以防止价值流失。|(% style="width:70px" %)H
873 |问题管理|(% style="width:545px" %)应用问题控制和错误控制方法来管理技术债。|(% style="width:70px" %)H
874 |软件开发管理|(% style="width:545px" %)通过创建或修改基础架构和平台服务组件来识别和减少技术债。|(% style="width:70px" %)H
875 |业务分析|(% style="width:545px" %)了解技术债对需求和解决方案表达的影响。|(% style="width:70px" %)M
876 |持续改进|(% style="width:545px" %)确定优先顺序和管理减少技术债的工作。|(% style="width:70px" %)M
877 |信息安全管理|(% style="width:545px" %)信息安全控制的设计，实施和改进受现有技术债的影响。信息安全控制还可能导致技术债的产生，这需要得到承认并传达给所有相关的利益干系人。|(% style="width:70px" %)M
878 |项目管理|(% style="width:545px" %)计划和执行项目受现有技术债的影响。 项目还可能导致技术债的产生，需要承认这一债务并将其传达给所有相关的利益干系人。|(% style="width:70px" %)M
879 |风险管理|(% style="width:545px" %)认识到技术债对新的或现有的企业风险的影响；减轻风险可能会产生技术债，需要予以确认并传达给所有相关的利益干系人。|(% style="width:70px" %)M
880 |服务台|(% style="width:545px" %)与需要事件和请求协助的外部用户进行交流，需要了解现有的技术债以及为解决该问题而计划的工作。|(% style="width:70px" %)M
881
882 === 4.3.2 混沌工程 ===
883
884 **定义：混沌工程**
885
886 为了建立对系统承受生产中动荡环境能力的信心而在系统上进行实验的学科。
887
888 为了解决分布式系统的不确定性，混沌工程依靠四个基本步骤：
889
890 * 定义稳态；这将是普通行为的输出。
891 * 假设这种稳定状态将持续下去。
892 * 引入反映真实事态的变量。
893 * 尝试反驳这个假设。
894
895 混沌工程理想应用的原则是：
896
897 * **围绕稳态行为进行构建和假设 **关注于可测量的系统输出，而不是系统的属性。
898 * **变化的真实世界事态 **混沌变量反映真实世界的事态。必须通过考虑事态的影响或估计频率来定义优先级。
899 * **在生产中进行实验 **混沌倾向于直接对生产流量进行实验。
900 * **使实验自动化以连续运行 **将自动化构建到系统中以推动业务流程和分析。
901 * **最小化爆炸半径 **应该最小化并控制实验的后果。
902
903 混沌工程的一些优点是：
904
905 * 为团队为随机实例失效做好准备
906 * 鼓励冗余
907 * 使系统更强大，从而增强了在复杂系统中快速移动的信心
908 * 将现实条件引入受控运行中，在弱点引起问题之前就将其发现
909 * 在影响生产中的客户之前，主动解决最重要的弱点。
910
911 混沌猴子是所谓的猿猴军团中最著名的混沌工程工具集之一。猿猴军团是由Netflix®创建的开源云测试工具的集合。混沌猴子通过禁用某些组件来测试对系统失效的响应，以查看其余系统将如何响应。尽管混沌猴子可能会中断运营，但也有助于它们的长期恢复能力。
912
913
914 **定义：混沌猴子**
915
916 通过有意地禁用生产中的组件来测试其余系统如何响应中断的方式来测试IT系统的弹性的工具。
917
918 混沌猴子的部署导致在已识别的系统组中随机选择的系统终止。这会产生接近自然事件的情况，并测试系统承受失效的能力。猿猴军团的另一个成员，合规性猴子，检查每项服务，以实现架构定义的最佳实践。
919
920 猿猴军团的其他成员包括：
921
922 * **延迟猴子 **导致人为延迟，以模拟服务降级并检查相关服务是否充分响应。
923 * **猴子医生 **进行健康检查以确定不健康的实例，如果所有者不修复根因，则主动将其关闭。
924 * **安全猴子 **查找并终止安全违规或漏洞的实例。
925 * **看门猴子 **确保云环境没有混乱和浪费。图4.18显示了混沌工程对服务价值链的贡献。表4.15概述了与混沌工程相关的实践。
926
927 (% style="text-align:center" %)
928 [[image:1639568794032-283.png]]
929
930 图4.18 混沌工程对服务价值链贡献的热图
931
932
933 表4.15 与混沌工程相关的实践
934
935 (% style="width:912px" %)
936 |**ITIL管理实践**|(% style="width:677px" %)**与混沌工程相关的活动/资源**|(% style="width:97px" %)**影响**
937 |持续改进|(% style="width:677px" %)使用混沌工程作为提高服务质量的最有效工具之一。|(% style="width:97px" %)H
938 |基础架构管理|(% style="width:677px" %)设计基础架构和平台，以提供足够的弹性和冗余来处理混乱的工程工具导致的意外中断。为混乱的工程提供有关服务组件和备份活动的信息。|(% style="width:97px" %)H
939 |服务连续性管理|(% style="width:677px" %)设计具有足够弹性和冗余性的服务连续性措施，以应对混乱的工程工具导致的意外中断。 持续监控弹性的连续性计划，措施和机制。|(% style="width:97px" %)H
940 |服务级别管理|(% style="width:677px" %)在设计和运行测试时，必须考虑业务连续性策略，服务水平协议以及为服务降级建立的明确标准，以防人为破坏超过可接受的水平。|(% style="width:97px" %)H
941 |软件开发管理|(% style="width:677px" %)混沌工程工具本身就是需要开发（或配置）和管理的软件应用程序。软件的设计和架构应具有足够的弹性和冗余性。|(% style="width:97px" %)H
942 |架构管理|(% style="width:677px" %)(((
943 通过混乱的工程促进弹性基础设施的建设。
944
945 考虑服务和组件之间的交互以支持需求。
946 )))|(% style="width:97px" %)M
947 |容量与性能管理|(% style="width:677px" %)运行此类测试时，应捕获性能信息。因此，应确定改进措施，以确保为最佳性能，可伸缩性和容量设计服务。|(% style="width:97px" %)M
948 |事件管理|(% style="width:677px" %)团队可以使用混乱的工程工具练习响应故障并从中断中恢复。他们必须准备好在不影响用户的情况下管理事件。冗余和自动化应内置于流程中。|(% style="width:97px" %)M
949 |度量与报告|(% style="width:677px" %)混沌工程测试涉及实验和假设，将有助于收集和分析数据以进行计划和预测。结果支持连续性业务战略。|(% style="width:97px" %)M
950 |监控与事态管理|(% style="width:677px" %)可以设置监视和事态管理工具来标记由混乱的工程工具策划的中断，或者监视服务质量而不是技术组件。|(% style="width:97px" %)M
951 |组织变革管理|(% style="width:677px" %)混沌工程将有助于确保在现场环境中的契动与合作。|(% style="width:97px" %)M
952 |问题管理|(% style="width:677px" %)通过引入随机失效并寻找服务/组件中的潜在缺陷来主动检测问题。从混乱的工程工具中收集的数据可以帮助识别需要调查和修复的潜在问题。|(% style="width:97px" %)M
953 |服务配置管理|(% style="width:677px" %)CMDB和代码存储库应具有高可用性和准确的信息（与服务连续性管理定义的恢复点目保持一致），以帮助组织从中断中快速恢复。|(% style="width:97px" %)M
954 |服务设计|(% style="width:677px" %)混沌工程测试原理可以帮助架构师设计更具弹性的系统并改进用户体验。|(% style="width:97px" %)M
955 |服务台|(% style="width:677px" %)必须将有关测试的情况通知服务台团队，并准备好在不影响用户的情况下管理事件。|(% style="width:97px" %)M
956 |服务验证与测试|(% style="width:677px" %)混沌工程测试原理可以帮助评估服务的可靠性。架构师应专注于服务中断。|(% style="width:97px" %)M
957 |风险管理|(% style="width:677px" %)通过使用混乱的工程工具和方法来提高组织的弹性和健壮性，可以减轻某些类型的组织风险。|(% style="width:97px" %)L
958
959 ITIL故事：混沌工程
960
961 //Radhika：我们需要测试该应用程序的弹性。例如，如果成员资格功能停止工作会怎样？客户仍然可以预定汽车？预订是否仍可以追溯分配到他们的账户？//
962
963 //Solmaz：我们使用了混沌猴子工具来了解该应用在胁迫下的工作方式。它使我们能够看到系统可能在哪里崩溃，这意味着我们可以修改代码和软件体系结构以减少或消除薄弱环节。//
964
965
966 === 4.3.3 完成的定义 ===
967
968 **完成的定义**
969
970 拟议产品或服务的商定标准清单。
971
972 应用程序开发人员通常使用敏捷方法“ 完成的定义”。敏捷社区将“完成”定义为“已经产生了可能发布的软件增量”。在DevOps圈子中，此功能已扩展为“已发布到生产环境”。从端到端的角度来看，这种急需的扩展仍然不足。如果用户使用不当，错误地解释数据，做出次优决策或无法做出好的决定，则释放所需的功能将无用。专注于IT部门的职能可能不是阻止它的责任，而是组织的责任。
973
974 因此，对完成的更完整的定义包括操作和使用标准。该技术广泛适用，并且在HVIT环境中经常遇到。
975
976 完成的定义描述了有助于产品或服务实用程序的功用标准，以及有助于其修复的非功效标准。应定义这些非功能性标准并与负责操作的人达成一致。因此，包含非功能性标准的完成定义有助于弹性运营，并通过提高可用性共创价值共创，也有助于加快研发速度，因为需要的返工较少。
977
978 非功能性标准指定了将要操作，维护和增强系统的人员以及将确保安全和法规合规性的人员所需的质量。这些标准解决了执行和演进所需的质量。功能性标准描述“是什么”，而非功能性标准描述“如何”。完成的定义中指定了质量属性，以便开发和支持团队可以在早期阶段考虑它们。对于开发来说，它们是软件设计约束。
979
980 在敏捷软件开发中，“完成”通常意味着具有潜在可部署的软件增量。DevOps将此定义扩展为三类：已部署、已发布和可使用。从共同构服务的角度来看，将工作定义为“完成”的更好方法是用户从其投资中获得期望的成果。不管选择哪种方法，完成的定义都应该是整体的，并着重于价值。
981
982 创建完成的定义时应考虑以下方面：
983
984 * **应准备好使用环境 **应当验证连续集成框架并使其正常工作。
985 * **支持的交付内容应完整 **且接受所有标准、用户故事和测试。
986 * **应该有可用的度量标准 **每个发布以验证其满足用户故事和标准（在敏捷世界中被称为“故事点”）非常重要。
987 * **代码必须易于理解，可维护并且可以支持将来的变更。**
988
989 考虑就绪定义也很有用，它描述了何时可以处理待办项。首字母缩略词“ INVEST”代表有用的标准。项目应为：
990
991 * **独立 **自包含，不依赖于其他待办项。
992 * **可协商 **进行讨论和微调。
993 * **有价值 **关于利益干系人将如何受益的问题应该有明确的说明。
994 * **可估计 **范围足以接受可接受的近似值。
995 * **足够小 **足以估计并计划到一个时间表中。
996 * **可测试 **具有明确的验收标准。
997
998 弹性测试可验证系统在不同领域是否满足约定的非功能性标准，例如可用性、容量、效率、可维护性、性能、隐私、可靠性、可恢复性和安全性。
999
1000 图4.19显示了完成定义对服务价值链的贡献。表4.16概述了完成定义相关的实践。
1001
1002
1003 (% style="text-align:center" %)
1004 [[image:1639568893041-234.png]]
1005
1006 图4.19 完成定义对服务价值链贡献的热图
1007
1008
1009 表4.16 与“完成”定义相关的实践
1010
1011 (% style="width:777px" %)
1012 |**ITIL管理实践**|(% style="width:601px" %)**与“完成”定义相关的活动/资源**|(% style="width:70px" %)**影响**
1013 |可用性管理|(% style="width:601px" %)新服务或变更服务的详细功效要求应与利益干系人协商并达成协议。|(% style="width:70px" %)H
1014 |容量与性能管理|(% style="width:601px" %)完成清单的定义必须考虑容量需求，需求预测以及管理业务和客户期望的性能。|(% style="width:70px" %)H
1015 |变更控制|(% style="width:601px" %)变更支持活动可以围绕完成的定义来组织；例如，使用发布管理或部署管理创建边界。|(% style="width:70px" %)H
1016 |持续改进|(% style="width:601px" %)完成的定义可用于范围和结构持续改进活动，并检查是否已实现结果。|(% style="width:70px" %)H
1017 |部署管理|(% style="width:601px" %)部署管理活动可以围绕完成的定义来组织；例如，使用发布管理创建边界。将发行版移至实际环境时，团队应验证支持的交付成果是否完整：应接受所有要求，用户案例和测试。|(% style="width:70px" %)H
1018 |事件管理|(% style="width:601px" %)事件管理活动可以围绕完成的定义来组织；例如，建立问题管理的界限。|(% style="width:70px" %)H
1019 |信息安全管理|(% style="width:601px" %)应该考虑安全测试，例如漏洞，渗透或策略合规性在针对弹性产品和服务的完成定义中。|(% style="width:70px" %)H
1020 |项目管理|(% style="width:601px" %)项目任务或输出可以使用以下定义定义成功或完成标准：完成的方法。|(% style="width:70px" %)H
1021 |发布管理|(% style="width:601px" %)发布管理活动可以围绕完成的定义进行组织；例如，创建具有变更支持或部署管理的边界。发行必须设计为符合业务，客户和用户的期望。这很重要，评估每个版本以验证它满足用户需求和要求。|(% style="width:70px" %)H
1022 |服务级别管理|(% style="width:601px" %)完成的定义可以阐明提供者和消费者的服务行为，并且可以用作根据预期性能监视实际性能的基础。|(% style="width:70px" %)H
1023 |服务请求管理|(% style="width:601px" %)服务请求管理活动，例如记录或满足请求，可以是使用完成方法的定义进行结构化。|(% style="width:70px" %)H
1024 |服务验证与测试|(% style="width:601px" %)可以围绕完成的定义来组织测试活动，以确保多种类型测试进行。|(% style="width:70px" %)H
1025 |软件开发管理|(% style="width:601px" %)可以开发（或配置）软件以满足部署之前完成的定义进入实时环境，确保代码易于理解，可维护并且随时可以支持未来的变化。|(% style="width:70px" %)H
1026 |业务分析|(% style="width:601px" %)保修和实用程序的功效和功用要求必须记录在为了满足客户的需求和期望。|(% style="width:70px" %)M
1027 |服务设计|(% style="width:601px" %)完成的定义应以客户为中心，以简化设计方法采用并确保服务将可维护且具有成本效益。|(% style="width:70px" %)M
1028 |服务目录管理|(% style="width:601px" %)发行新功能，产品或服务时，服务目录必须被更新。|(% style="width:70px" %)L
1029 |服务台|(% style="width:601px" %)在完成的定义中指定质量属性，以便开发和支持团队可以在早期阶段考虑他们。|(% style="width:70px" %)L
1030
1031 **ITIL故事：完成定义**
1032
1033 //Su：该应用程序的交付团队包括来自Alxe汽车租赁部门许多部门人员，当开发人员移交工作代码时，对完成传统定义并不是最有效或最准确的。我们要保证该应用程序的弹性、功效、可维护性、功用和可用性。对我们来说，“完成“是指：//
1034
1035 //●     生产和测试环境已准备就绪//
1036
1037 //●     准备了持续集成框架//
1038
1039 //●     用户故事和测试已得到认可//
1040
1041 //●     度量和指标已被接受并且可以进行测试//
1042
1043 //●     该软件具有可读性、可用性和适应性//
1044
1045
1046 === 4.3.4 版本控制 ===
1047
1048 **定义：版本控制**
1049
1050 信息系统、产品和服务的来源和人工制品的管理。
1051
1052 版本控制与HVIT特别相关，因为已经在好的版本控制和高IT性能之间建立了强大的关联：它提供了更早的变更前置时间、更频繁的部署以及更快地平均恢复服务时间。
1053
1054 版本控制跟踪在哪些环境中存在哪些版本的源和人工制品。在版本控制系统中存储软件源代码的通用实践扩展为包括IT系统、产品或服务的几乎所有其他重要组件，例如：
1055
1056 * 为每个环境创建和配置基础的脚本，包括开发、测试和生产环境
1057 * 验收标准、测试用例和测试本身
1058 * 外部和内部库、模块和组件
1059 * 有关相互依赖性的信息
1060 * 部署管道的脚本和配置文件
1061 * 运行任务的脚本，例如重复操作
1062 * 文档，包括架构决策
1063 * 构建和运行系统所需的制品
1064 * 合同，协议等。
1065
1066 因此，版本控制不仅适用于服务组件（在获取或构建价值链活动中开发/设计和管理），而且还适用于服务级别。适当的版本控制可以收集有关产品或服务所需的每个组件的当前和以前状态的有价值的信息。该信息包括变更的初始状态、变更、变更时间和日期、操作变更的人员以及任何其他澄清和支持信息。版本控制的优点包括：
1067
1068 * 版本控制支持基础架构即代码技术（请参阅第4.2.1节）。
1069 * 版本控制应用于源代码和产品，可以缩短变更的前置时间、更频繁的部署以及更快的平均恢复服务时间。
1070 * 版本控制支持的自动化测试与更快的变更前置时间相关。
1071 * 版本控制是持续交付的前提条件，而持续交付与更频繁的部署相关。
1072
1073 因此，版本控制有助于弹性运营和快速研发。也可以将其视为用于架构的促进因素：一种实践，其中的架构决策不受限制，而是使产品和服务能够持续发展和实现改进点，而无需重新设计和重新开发先前的解决方案。
1074
1075 图4.20显示了版本控制对服务价值链的贡献。表4.17概述了与版本控制相关的实践。
1076
1077 (% style="text-align:center" %)
1078 [[image:1639568991350-151.png]]
1079
1080 图4.20 版本控制对服务价值链贡献的热图
1081
1082
1083 表4.17 与版本控制相关的实践
1084
1085 (% style="width:890px" %)
1086 |**ITIL管理实践**|(% style="width:689px" %)**与版本控制相关的活动/资源**|(% style="width:91px" %)**影响**
1087 |部署管理|(% style="width:689px" %)使用版本控制的存储库来部署新的或变更的服务组件，或者返回以前的版本。|(% style="width:91px" %)H
1088 |信息安全管理|(% style="width:689px" %)通过标记易受攻击的版本来解决或消除信息安全风险服务组件。|(% style="width:91px" %)H
1089 |基础设施管理|(% style="width:689px" %)基础架构组件，配置设置以及虚拟和物理基础架构可以使用版本控制的存储库正式存储和管理组件。|(% style="width:91px" %)H
1090 |服务配置管理|(% style="width:689px" %)CMDB可以联合在一起，利用版本控制的代码存储库，基础架构即代码配置文件，甚至是物理设备和其他硬件的存储。办理登机手续应该每天发生多次，并且应该管理环境规范和版本化。|(% style="width:91px" %)H
1091 |软件开发管理|(% style="width:689px" %)代码，甚至其他软件组件的配置设置都可以正式使用版本控制的存储库来管理软件输出开发和管理工作。|(% style="width:91px" %)H
1092 |持续改进|(% style="width:689px" %)创建当前环境的基线，并在改进完成后更新基线。|(% style="width:91px" %)M
1093 |事件管理|(% style="width:689px" %)使用版本控制的软件或硬件组件存储库来解决一个事件。|(% style="width:91px" %)M
1094 |知识管理|(% style="width:689px" %)服务版本时更新知识库并传达信息组件发生变化。|(% style="width:91px" %)M
1095 |服务连续性管理|(% style="width:689px" %)了解服务组件新版本的影响；并且如果可行，将它们传播到服务连续性和灾难恢复计划中。|(% style="width:91px" %)M
1096 |服务请求管理|(% style="width:689px" %)使用版本控制的软件或硬件组件存储库来快速满足要求。|(% style="width:91px" %)M
1097
1098 **ITIL故事：版本控制**
1099
1100 //Marco：我们实行持续集成和持续交付，我们利用版本控制系统地记录我们发布的应用程序的每次迭代，如果发布不稳定，我们可以通过将服务返回到先前的稳定版本来快速还原该服务。//
1101
1102
1103 === 4.3.5 人工智能运营 ===
1104
1105 **定义：AIOps**
1106
1107 将机器学习和大数据应用于IT运营以获取持续的见解，并通过自动化提供持续的修复和改进。也称为“IT运营的人工智能“或”算法IT运营“。
1108
1109 AIOps旨在将人工智能引入IT运营，以应对基础架构持续发展中的现代趋势所带来的挑战，例如软件定义系统的增长。这些新技术的影响（例如，基础设施的重新配置和重塑速率的增加）需要更自动化和动态的管理技术，这些技术可能在组织的数字化服务上具有重要的影响。
1110
1111 AIOps平台用于增强和部分替代许多主要的IT运营功能，例如可用性和性能监控、失效识别、预测分析以及事态相关性和分析。
1112
1113 AIOps利用数据平台和机器学习，收集观察数据（例如事态、日志文件、运营指标）和参与数据（例如客户请求和服务台票证），并通过对该数据应用认知或算法处理得出见解。
1114
1115 这些见解可用于驱动一些或全部范围的通用输出，例如：
1116
1117 * **问题检测和预测 **帮助服务组织更快地对事件做出响应。
1118 * **主动的系统维护和调整 **减少了人工和潜在错误。
1119 * **阈值分析 **可以更准确地了解系统的正常运行范围。
1120
1121 AIOps的应用在很大程度上取决于要分析的数据的可用性，以及数据是否适合进行分析，如果其性质极其复杂，原因和影响之间的相关性较弱，则可能不会。
1122
1123 一些组织还开始在IT运营以外使用AIOps，以使业务管理人员实时了解IT对业务的影响。这样可以使他们随时了解情况，并使他们能够基于实时的相关数据做出决策。
1124
1125 图4.21显示了AIOps对服务价值链的贡献。表4.18概述了与AIOps相关的实践。
1126
1127 (% style="text-align:center" %)
1128 [[image:1639569057821-522.png]]
1129
1130 图4.21 AIOps对服务价值链贡献的热图
1131
1132
1133 表4.18 与AIOps相关的实践
1134
1135 (% style="width:904px" %)
1136 |(% style="width:99px" %)**ITIL管理实践**|(% style="width:724px" %)**与AIOps相关的活动/资源**|(% style="width:77px" %)**影响**
1137 |(% style="width:99px" %)容量与性能管理|(% style="width:724px" %)AIOps提供了识别模式和异常，确定资产的容量和利用率以及规划未来产品或服务的容量能。|(% style="width:77px" %)H
1138 |(% style="width:99px" %)事件管理|(% style="width:724px" %)事件管理数据可受益于AIOps工具提供的高度自动化的功能，这些功能可增强手动工作。使用从不同系统合并的上下文预先分析的数据解决关联事件。|(% style="width:77px" %)H
1139 |(% style="width:99px" %)基础架构管理|(% style="width:724px" %)AIOps工具可以自动执行基础结构和平台资源的大部分日常管理。|(% style="width:77px" %)H
1140 |(% style="width:99px" %)监控与事态管理|(% style="width:724px" %)AIOps工具可以帮助关联来自多个监视工具的大量数据集。他们可以更好地理解IT环境。 AIOps通过一组集成的业务和运营指标来实现价值共创，从而降低了运营事态或事件的发生频率，因为它们是可以预测和预防的。AIOps通过替换以筒仓为中心的IT监视工具，并监视价值流中所有层的应用程序的运行状况和性能，来帮助优化IT并降低IT成本。|(% style="width:77px" %)H
1141 |(% style="width:99px" %)变更控制|(% style="width:724px" %)AIOP支持在每个设备级别可视化依赖项详细信息。|(% style="width:77px" %)M
1142 |(% style="width:99px" %)IT资产管理|(% style="width:724px" %)AIOps可以收集具有逻辑和物理属性的动态库存信息。|(% style="width:77px" %)M
1143 |(% style="width:99px" %)度量与报告|(% style="width:724px" %)AIOps为度量提供数据，以评估性能和法规遵从性。它还有助于自动执行报告任务。|(% style="width:77px" %)M
1144 |(% style="width:99px" %)问题管理|(% style="width:724px" %)来自AIOps工具的信息可以帮助识别和调查问题和错误，以及自动化和监视规避措施的应用。们还可以基于预处理和合并的数据来帮助主动检测问题。|(% style="width:77px" %)M
1145 |(% style="width:99px" %)服务配置管理|(% style="width:724px" %)AIOps数据可用于检测配置项的变更，从而帮助识别未经授权的变更。|(% style="width:77px" %)M
1146 |(% style="width:99px" %)服务台|(% style="width:724px" %)来自AIOps工具的信息可以支持与外部利益干系人的互动。AIOps可帮助组织在问题发生主动进行计划，发现问题及其业务影响。AIOps还可以根据合并的数据和已识别的趋势对用户查询进行明智的分类。|(% style="width:77px" %)M
1147 |(% style="width:99px" %)劳动力和人才管理|(% style="width:724px" %)在整个IT团队中实施AIOps故障孤岛的组织可以使经验不足的员工提高生产力，发展技能和效率。|(% style="width:77px" %)M
1148 |(% style="width:99px" %)知识管理|(% style="width:724px" %)IT流程，运营，性能结果和数据处理算法的知识的组合支持关键的业务功能。|(% style="width:77px" %)L
1149
1150 **ITIL故事：AIOps**
1151
1152 Radhika：：成千上万的客户使用该应用程序并租用我们的车辆。这些转换会产生大量数据，这是有关客户需求的丰富信息来源。
1153
1154 Su：我们创建了脚本来分析数据，查找使用模式并优化服务的基础架构。例如，如果数据表明电动汽车的用户正在达到电池充电的终点，则脚本会自动突出显示提示，说明如何为电池充电，以及最近的充电设施的地图。
1155
1156
1157 === 4.3.6 聊天运营 ===
1158
1159 ChatOps是一个模型，其中人员、工具、流程和自动化都连接在透明的流程中。该模型有助于控制管道和协作。它是即时通信与运营执行的紧密结合：这是一个新兴的运动，促进了多个团队、工具和DevOps平台的集成。通过将工具和平台进行对话来驱动开发。当机器人是团队成员时，可以向他们发送请求并获得即时响应。
1160
1161 ChatOps支持人与工具之间的协作通信，通过消除对重复信息的请求并自动执行一些常规的IT运维操作来减少事件响应时间。
1162
1163 ChatOps的元素包括：
1164
1165 * **聊天平台 **连接利益干系人，团队及其工作系统的服务。
1166 * **Bots ** ChatOps模型的核心。Bot存在并且可以在协作工具和DevOps工具之间工作。他们接收团队成员的请求，然后通过执行脚本从集成系统中检索信息。
1167 * **集成和自动化服务 **ChatOps中的第三方元素。例如，用于问题跟踪：版本控制系统、基础架构即代码、持续集成服务器或监控工具。
1168
1169 这款模型变得越来越受欢迎。组织将其聊天平台连接到其构建系统，以便在其持续集成服务器上接收通知并执行和查询过程。相同的模型可以应用于质量保证团队。ChatOps工作流程考虑：
1170
1171 * 工作需要
1172 * 工作进行中
1173 * 工作完成。
1174
1175 模型可以促进反馈，改进沟通和交叉培训并增强团队协作。在“聊天”中，人们进行协作和创新，从而推动进步。通过收集知识并确定按计划或预期提供服务的要求，ChatOps使工作人性化。
1176
1177 这类工具强调了在工具、运营团队和消息传递工具之间需要即时协作。ChatOps是传统聊天的发展，因为它使系统能够加入对话。例如，DevOps或IT和服务管理工具可以将事件或事态通知支持小组。
1178
1179 图4.22显示了ChatOps对服务价值链的贡献。表4.19概述了与ChatOps相关的实践。
1180
1181 (% style="text-align:center" %)
1182 [[image:1639569157526-866.png]]
1183
1184 图4.22 ChatOps对服务价值链贡献的热图
1185
1186
1187 表4.19 与ChatOps相关的实践
1188
1189 (% style="width:923px" %)
1190 |**ITIL管理实践**|(% style="width:743px" %)**与ChatOps相关的活动/资源**|(% style="width:95px" %)**影响**
1191 |服务台|(% style="width:743px" %)与用户进行沟通和协调，以更好地管理事件和请求。|(% style="width:95px" %)H
1192 |变更控制|(% style="width:743px" %)在管理服务变更的所有团队之间进行沟通和协调和服务组件。一些ChatOps工具可以与其他IT和服务集成管理工具。ChatOps提供了与用户和团队进行沟通的渠道成员了解新服务或变更的服务，从而人性化工作方式。|(% style="width:95px" %)M
1193 |持续改进|(% style="width:743px" %)实现持续改进计划的目标，以改进沟通与协调团队之间。|(% style="width:95px" %)M
1194 |部署管理|(% style="width:743px" %)在参与部署新的或变更的所有团队之间进行沟通和协调服务组件。一些ChatOps工具可以与部署工具集成。|(% style="width:95px" %)M
1195 |事件管理|(% style="width:743px" %)在外部利益干系人与参与其中的各个团队之间进行沟通和协调事件管理活动。一些ChatOps工具可以与其他IT和服务集成管理工具。ChatOps帮助IT团队进行支持活动，例如注册和诊断，从而减少响应时间并消除重复的任务。|(% style="width:95px" %)M
1196 |知识管理|(% style="width:743px" %)在聊天日志中搜索非结构化知识。获取知识并确定按计划或预期提供服务的要求。收集反馈以支持持续改进。|(% style="width:95px" %)M
1197 |问题管理|(% style="width:743px" %)运行根本原因分析和回顾。|(% style="width:95px" %)M
1198 |发布管理|(% style="width:743px" %)在管理服务变更的所有团队之间进行沟通和协调。|(% style="width:95px" %)M
1199 |风险管理|(% style="width:743px" %)以可搜索的格式存储数据和信息。|(% style="width:95px" %)L
1200
1201 === 4.3.7 站点可靠性工程 ===
1202
1203 **定义：站点可靠性工程**
1204
1205 该学科结合了软件工程的各个方面，并将其应用于基础结构和操作问题，旨在创建超可扩展且高度可靠的软件系统。
1206
1207 由于高度数字化的组织要求高度弹性的运营，因此站点可靠性工程（SRE）与HVIT特别相关。
1208
1209 SRE将软件开发思维方式应用于IT运营，并有助于使开发和运营保持一致。SRE团队将时间分散在执行IT运营、指导IT运营团队以及开发可提高IT系统弹性和性能的软件之间。他们倾向于花费少于一半的时间在琐事工作上（否则，这表明系统存在问题）。
1210
1211 琐事被定义为工作，即：
1212
1213 * **手动 **需要人工的时间。
1214 * **重复性 **一遍又一遍。
1215 * **可自动化的 **因为不需要特殊的人工判断，所以可以通过机器来实现。
1216 * **战术型 **由中断驱动和被动式驱动，而不是由策略驱动和主动驱动。
1217 * **缺乏持久性价值 **并非永久性地改进和服务。
1218 * **线性缩放 **与服务的大小、流量或用户的数量成比例地缩放。
1219
1220 SRE基于经验表明，系统很复杂，因此会发生故障。因此，在预防故障和减少无法预防的失效的影响之间可以进行权衡，例如通过将系统设计为逐渐降级而不是突然失效。认识到人是复杂系统的适应性要素，并且他们的专业知识与系统的其他部分一样在发生变化，因此失效被认为是学习的机会。
1221
1222 从失效中学习并不是专注于根本原因的识别，因为在复杂系统中这是无效的，甚至是不可能的（请参阅第3.2.3.1节）。相反，失效是用来提高团队的集体知识的。它们帮助人们不断地校准其心理模型，以便他们可以更轻松地识别危害，并采取行动将系统保持在可接受的性能范围内。从业人员评估何时应用标准修复程序以及何时需要即兴创作。他们永远无法确定其行动的后果，他们会从反馈中学习有关系统性能如何根据其行动而变化的信息。因为团队应该承担风险，所以不要将责任归咎于责备文化至关重要。虽然算法在机器学习中占有一席之地，例如，启发式算法在处理复杂系统方面更为有效，因此人工判断至关重要。这需要智力，经验和采取行动的动力；和鼓励期望行为的工作场所。
1223
1224 在可用性管理中，平衡停机预防和事件解决很重要。相应的关键可用性指标是MTBF和MTRS。系统越复杂，不可避免的失效就越多，这意味着重点应该从预防失效转移到快速恢复服务。正确的平衡因服务而异，具体取决于服务的功效要求和基础系统的特性。在HVIT环境中，系统通常会更复杂，因此，专注于减少MTRS比增加MTBF更有效。
1225
1226 平衡对新功能和服务可靠性的投资可能是一项挑战。错误预算是一个功能强大的SRE工具，可在此方面提供帮助。变更往往会导致系统事件。功能的开发工作和稳定性的开发工作需要平衡。错误预算是一种控制机制，可为开发工作分配适当的能力以保持稳定，并确保适当的平衡。当服务接近其错误预算时，产品团队应专注于改进而不是新功能。
1227
1228 错误预算表示为100％减去服务的服务水平目标（SLO）。99.9％的SLO服务的错误预算为0.1％。这笔预算应用于改进稳定性。错误预算允许团队根据策略进行自我调整，如果超出错误预算，后果将不堪设想。重要的是，应以影响服务消费者体验的术语表示SLO，而不是内部系统的KPI。
1229
1230 SRE对可用性，延迟和性能的改进都有助于恢复操作。图4.23显示了SRE对服务价值链的贡献。
1231
1232 表4.20概述了与SRE相关的实践。
1233
1234
1235 (% style="text-align:center" %)
1236 [[image:1639569226390-186.png]]
1237
1238 图4.23 SRE对服务价值链贡献的热图
1239
1240
1241 表4.20 与SRE相关的实践
1242
1243 (% style="width:840px" %)
1244 |**ITIL管理实践**|(% style="width:707px" %)**与SRE相关的活动/资源**|(% style="width:51px" %)**影响**
1245 |可用性管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。跟踪“技术性” MTBF和（更重要的是）MTRS指标，例如用户中断时间，丢失的转换数量，丢失的业务价值和用户满意度。使用错误预算来平衡服务的可靠性和创新。|(% style="width:51px" %)H
1246 |容量与性能管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。监控系统和已定义的SLO必须加以考虑和衡量。改进监视功能，以便在出现问题时更好地了解系统。|(% style="width:51px" %)H
1247 |变更控制|(% style="width:707px" %)使用SRE技术和工具来启用对服务组件的变更以及失败变更的回滚。|(% style="width:51px" %)H
1248 |事件管理|(% style="width:707px" %)使用SRE技术和工具来管理基础架构或平台层中的事件。|(% style="width:51px" %)H
1249 |基础架构管理|(% style="width:707px" %)使用SRE技术和工具来帮助架构师和设计基础架构和平台功能以满足组织的需求。|(% style="width:51px" %)H
1250 |监控和事态管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。|(% style="width:51px" %)H
1251 |问题管理|(% style="width:707px" %)(((
1252 来自SRE工具的数据可帮助识别问题，确保通过使用自动化快速应用规避措施。
1253
1254 自动化IT流程可提高弹性并减少工作量。
1255
1256 回顾。
1257 )))|(% style="width:51px" %)H
1258 |服务设计|(% style="width:707px" %)在设计阶段进行SRE协作可以防止在生产后期出现各种问题或事件。尽管可以在开发生命周期的后期撤消或纠正设计决策，但这种变更付出了高昂的努力成本和复杂性。|(% style="width:51px" %)H
1259 |软件开发管理|(% style="width:707px" %)向SRE团队提供要求并根据反馈采取行动。|(% style="width:51px" %)H
1260 |部署管理|(% style="width:707px" %)部署过程应与服务设计中描述的风险过程保持一致。|(% style="width:51px" %)M
1261 |组织变革管理|(% style="width:707px" %)SRE团队的核心职责是为团队快速创新做好准备。|(% style="width:51px" %)M
1262 |发布管理|(% style="width:707px" %)借助SRE，用于发布软件的技术已应用于数字化基础架构。|(% style="width:51px" %)M
1263 |服务配置管理|(% style="width:707px" %)借助SRE，可以将自动发现和版本控制应用于基础架构组件。|(% style="width:51px" %)M
1264 |服务验证与测试|(% style="width:707px" %)对于SRE中的发布工程，建议连续的构建测试目标与确定项目发布的相同测试目标相对应。|(% style="width:51px" %)M
1265
1266 **ITIL故事：站点可靠性工程**
1267
1268 // Su：我们添加到应用程序的功能越多，它变得越复杂，其中的代码失败的可能性就越大。失败是任何软件平台都不可避免的功能。应用失败的方式可以教会我们如何对其进行重新校准以使其更具弹性。//
1269
1270 //Radhika：站点可靠性工程在减少服务故障的需求与减少服务故障之间进行平衡的需求之间取得了平衡。我们越能自动化工作并减少重复的手动操作，代码就越强大。价值共创的技术//
1271
1272
1273 == 4.4 价值共创的技术 ==
1274
1275 价值共创目标涉及通过服务提供商和服务消费者的紧密合作，从数字化产品价值共创。
1276
1277 价值共创是服务消费者有效地使用服务提供商的产品和服务，并从其功用和功效中受益。只有通过从自动化信息系统获得的信息来改进决策（无论是由人，自动化还是AI来完成），才能实现数字投资的回报。因此，用户必须了解数字化产品和信息及其在上下文中的用途。他们应该充分理解该功能以适当地使用它，并能够正确地解释信息以改进决策。最后，人或事必须根据这些决定采取行动；只有这样，价值才能实现。
1278
1279 例
1280
1281 有人使用叫车应用程序前往机场。他们错误地将指示的到达时间解释为保证而非估计。他们做出错误的决定等待。然后他们会紧张地飞往机场，因为他们可能会错过航班。正确地解释后，这些信息将使他们决定搭乘一辆普通的出租车，因此将具有价值。
1282
1283 许多用户没有有效地使用信息系统的功能。他们还会误解系统提供的数据的含义，随后做出次优的决策，因此无法获得所需的IT投资回报。不仅无法实现潜在价值，而且在出现问题时生产率通常会下降。造成的某些损失是由于与弹性操作相关的问题所致，而某些损失是由于服务使用者的滥用所致。这意味着应该优先考虑主动的功能用户支持。在业务环境中，这种形式的支持更适合于位于同一地点的角色，例如充当“价值实现教练”的主动超级用户，而不是远程服务台。
1284
1285 “价值共创”是指服务消费者、服务提供商和其他利益干系人的价值。对于服务使用者而言，价值是服务输出促进的成果。对于服务提供商而言，取决于投资的性质，价值可以用不同的术语表示，例如数字化产品和服务的收入、网站流量以及降低的成本和风险。
1286
1287 在HVIT环境中，服务使用者经常使用数字化产品和服务，因此期望值更高。消费者需要更直观，响应更快的用户体验和客户体验。服务提供商更好地了解服务消费者如何使用IT服务或数字化产品，他们为他们提供更好的支持。同样，服务消费者对服务提供商如何提供IT服务或数字化产品的了解越多，他们与他们进行有效交互的能力就越强。这些概念说明了服务的共生、共创性的本质。
1288
1289 尽管按照定义，数字体验将是基于算法的，但是经验丰富的数字服务消费者希望它也应该是复杂的，并且要尽可能地适应他们的情况。如果这对于数字服务来说太困难了，那么服务消费者将期望与服务提供商的员工有丰富的身体/模拟/人类体验。在数字体验依赖于高级算法的情况下，人类体验则依赖于应对不可预测的情况所需的高级启发式方法。这样的服务交互是社会交互，并且服务可能会因人类交互中的小细节而被破坏。经验丰富的服务提供商和消费者认识到环境和对方的人性。这产生了一种相互经验，在彼此尊重彼此立场的情况下，已经实现了可能的成就。
1290
1291 共创不仅与服务交互有关，而且在其中实现价值。这也与消费者参与服务设计和进一步开发有关。敏捷产品所有者与开发团队之间的协作是IT从业人员、业务人员以及某些情况下客户与消费者之间紧密协作的一个很好的例子。这样自成体系的面向产品或服务的团队非常有效。在许多情况下，只有在设计信息系统时考虑到这种工作方式，才能实现这种构造，从而使各个小型团队可以在较大系统的相对隔离的部分上工作而无需太多交互。这需要一个松散耦合的信息系统体系结构（请参阅第4.2.2节）。
1292
1293 支持价值共创的一项重要技术是服务体验。
1294
1295
1296 **ITIL故事：价值共创的技术**
1297
1298 //Henri：我们的目标是为所有利益干系人价值共创，因此，无论表面上发生什么变化，我们都需要确保为预订汽车提供的界面是一致且直观的。该应用程序应无缝响应客户要求，以确保用户获得提供最佳价值的优化服务。//
1299
1300
1301 === 4.4.1 服务体验 ===
1302
1303 “服务体验”是指服务消费者对服务的评价是基于服务的“技术”输出以及从人的角度看待它的方式这一事实。这意味着服务提供商应该越来越意识到消费者的需求以及他们可用来价值共创的资源。不会被动地获得服务：价值共创需要消费者的努力。服务提供者和使用者必须动态地响应彼此的行为，并尽可能地容纳异常。
1304
1305 当在一些具有数字功能的组织中，业务和IT融合为一个组织实体时，就不再需要业务和IT实体。因此，也不再需要管理业务与IT的关系。“业务人员”和“ IT人员”向同一管理人员报告，具有相同的目标，并且通常在物理上位于同一地点。当采用敏捷或Scrum的工作方式时，有一个相对独立的团队致力于一个产品，则业务人员和IT人员在同一团队中，产品所有者代表业务利益。产品负责人经常管理与外部客户和其他利益干系人的关系。这些其他利益干系人包括寻求协同作用的其他产品所有者；例如知识和资源共享。
1306
1307 数据分析和机器学习可以极大地促进关系管理。信息安全和道德也同样重要。客户体验管理和客户旅程是值得考虑的其他主题。
1308
1309 有关服务关系和服务体验的更多详细信息，请参见ITIL4：推动利益干系人价值。图4.24显示了服务经验对服务价值链的贡献。
1310
1311 表4.21概述了与服务经验相关的实践。
1312
1313
1314 (% style="text-align:center" %)
1315 [[image:1639569323167-699.png]]
1316
1317
1318 图4.24 服务体验对服务价值链贡献的热图
1319
1320
1321 表4.21 与服务体验相关的实践
1322
1323 (% style="width:977px" %)
1324 |**ITIL管理实践**|(% style="width:719px" %)**与服务体验相关的活动/资源**|(% style="width:83px" %)**影响**
1325 |业务分析|(% style="width:719px" %)除了关于功用和功效的传统要求之外，了解用户需求并将其转化为客户体验或用户体验要求。|(% style="width:83px" %)H
1326 |服务目录管理|(% style="width:719px" %)从技术和体验方面描述服务和产品。|(% style="width:83px" %)H
1327 |服务设计|(% style="width:719px" %)表达客户体验和用户体验的需求超出了基本体验。|(% style="width:83px" %)H
1328 |服务台|(% style="width:719px" %)(((
1329 善解人意并拥有情绪智力，以了解用户的体验需求。
1330
1331 让用户选择沟通渠道。
1332
1333 服务经验需要技术和信息支持者，例如自助服务工具，在线门户，移动应用程序，呼叫中心工具和聊天。
1334
1335 使用用户满意度作为KPI。
1336
1337 评估用户体验，同时选择与用户进行双向通信的工具。
1338
1339 收集服务体验数据（用户对服务满意/不满意的粗略估计）。
1340 )))|(% style="width:83px" %)H
1341 |服务水平管理|(% style="width:719px" %)促进对服务消费者的心理和服务交互对消费者的（情感）影响的良好理解。|(% style="width:83px" %)H
1342 |软件开发管理|(% style="width:719px" %)所需的服务体验会通知用户界面的设计。|(% style="width:83px" %)H
1343 |监控与事态管理|(% style="width:719px" %)除技术监视和事态管理之外，还开发和配置工具和技术以监视服务体验和相关事态。|(% style="width:83px" %)M
1344 |关系管理|(% style="width:719px" %)善解人意，在情感上能够理解消费者的体验需求。|(% style="width:83px" %)M
1345 |服务验证与测试|(% style="width:719px" %)开发和维护服务体验测试。|(% style="width:83px" %)M
1346 |供应商管理|(% style="width:719px" %)基于主观和客观协议来参与和管理供应商。|(% style="width:83px" %)M
1347
1348 **ITIL故事：服务体验**
1349
1350 //Su：在Axle汽车租赁公司，业务与IT之间没有鸿沟。开发团队协作以提供可响应客户需求的服务体验。我们使用应用程序和车辆中的数据来指导服务的优化和自动化。该应用程序是可定制的，因此用户可以根据自己的需求优化服务。//
1351
1352
1353 == 4.5 保证合规的技术 ==
1354
1355 保证合规目标涉及确保服务提供和服务使用在治理，风险和合规性方面符合公司和法规指令。除了确保合规性之外，确保责任人员实现合规性也很重要。
1356
1357 尽管外部需求可能保持不变，但是对于启用数字化技术的组织来说，可能会有其他更合适的方式来实现它们。
1358
1359 高速往往与冒险息息相关，从商业角度看，这些风险可能是必要的。矛盾的是，组织可能承担的最大风险之一就是没有承担足够的风险。
1360
1361 但是，必须证明风险是合理的，并且组织必须遵守内部规则和外部法规。必须确保理事机构遵守其指示。保证合规性可以确保对治理，风险和合规性问题负责并受其影响的人们放心，因为他们知道组织在这些约束条件下会更加自信。
1362
1363 关于治理，从业者不治理而是被治理。他们在治理框架内运营，并且必须了解适用的限制以及如何在该框架内采取行动。从业者的见识和判断会影响他们的行为。他们越有洞察力，他们的判断能力越强，从业人员就越有能力判断何时有必要在合理的相关收益和风险下偏离规则。这就要求从业者理解约束背后的思想。
1364
1365 保证合规可以通过（不存在）安全漏洞、监管机构罚款、宣传不佳、内部和外部审计师要求采取的措施以及确保与治理，风险和合规性问题相符的措施成本来衡量保证的符合性。
1366
1367 可以用来保证合规的技术包括：
1368
1369 * DevOps审核防御工具包
1370 * 开发安全
1371 * 同行评审
1372
1373 **ITIL故事：保证合规的技术**
1374
1375 //Henri：与所有道德企业一样，Axle完全遵守法律法规。我们利用保证合规的技术，因为有时IT进步如此之快，以致可以忽略或延迟遵从性要求。我们敬业的治理团队只是我们关注合规性要求变化的方式之一。//
1376
1377
1378 === 4.5.1 DevOps审核防御工具包 ===
1379
1380 DevOps审核防御工具包17是指南，解决了DevOps社区中新的、更流畅的工作模式所引起的IT与审核之间的紧张关系。它有助于向审计师证明IT部门了解业务风险并正在适当地减轻风险。该工具包建议了一些技术，这些技术可以降低风险，并在IT部门和审计师之间建立共同的观点和共识。因此，它有助于保证合规。通过减少不必要的官僚主义，它也为快速发展做出了贡献。
1381
1382 DevOps审核防御工具包与HVIT有关，因为HVIT的某些原理和技术似乎与常规合规性要求相抵触。但是，通常情况下，这是寻找获得所需结果的其他方法的情况。内部法规源自外部要求，通常可以找到替代的内部法规。但是，使审核员参与此过程非常重要。
1383
1384 图4.25显示了DevOps Audit Defense Toolkit对服务价值链的贡献。表4.22概述了与DevOpsAudit Defense Toolkit相关的实践。
1385
1386 (% style="text-align:center" %)
1387 [[image:1639569448205-317.png]]
1388
1389 图4.25 DevOps审计防御工具包对服务价值链贡献的热图
1390
1391
1392 表4.22 DevOps审计防御工具包与之相关的实践
1393
1394 (% style="width:968px" %)
1395 |**ITIL管理实践**|(% style="width:650px" %)**与DevOps审计防御工具包相关的活动/资源**|(% style="width:97px" %)**影响**
1396 |持续改进|(% style="width:650px" %)审核提供了正式注册，确定优先级和进行管理的新信息或改进机会。|(% style="width:97px" %)H
1397 |信息安全管理|(% style="width:650px" %)在产品生命周期中设计和实施控制措施，以提供广泛的可追溯性和联合责任制。|(% style="width:97px" %)H
1398 |监控与事态管理|(% style="width:650px" %)合并性能和事态数据的运营数据仓库提供了丰富的信息库，以审核控制的实施和性能。|(% style="width:97px" %)H
1399 |服务配置管理|(% style="width:650px" %)标准化配置可支持安全性和审核要求。|(% style="width:97px" %)H
1400 |知识管理|(% style="width:650px" %)使员工和其他主要利益干系人可以访问相关政策文档和以前的审核报告。|(% style="width:97px" %)M
1401 |风险管理|(% style="width:650px" %)在企业风险管理，技术风险管理和新的工作方式之间创建一种平衡，实用的方法。|(% style="width:97px" %)M
1402 |劳动力和人才管理|(% style="width:650px" %)培训员工的义务和义务，以确保他们遵守所有相关政策和法规。|(% style="width:97px" %)M
1403 |业务分析|(% style="width:650px" %)将审核结果和建议的补救措施纳入产品积压。|(% style="width:97px" %)L
1404 |战略管理|(% style="width:650px" %)将定期的外部或内部审核合并到服务的路线图中，以提供对服务的独立管理。|(% style="width:97px" %)L
1405
1406 === 4.5.2 开发安全 ===
1407
1408 大多数组织都有专门的信息安全团队，该团队执行风险评估并定义策略，规程和控制。在高速环境中，信息安全已尽可能集成到开发和运营的日常工作中，并将对过程控制的依赖转移到验证前提条件（例如员工的专业知识和完整性）上。安全员的角色从“维持治安”转变为使其他人能够采取必要措施。
1409
1410 “ DevSecOps”是指将与安全相关的活动集成到应用程序开发和IT运营的日常工作中。在整个DevOps流程中，跨文化，自动化，指标和共享（CAMS或CALMS加上精益）的四个支柱都内置了安全性。
1411
1412
1413 定义：职责整合
1414
1415 由于已应用其他控件，因此一个人容易执行欺诈或错误的任务。这是职责分离（或隔离）的替代方法。
1416
1417 传统上，职责是分开的，以减少欺诈和错误的风险；例如，未经测试和未经授权的代码将被部署到生产中的风险。但是，这可能会导致延迟和人们所认为的官僚主义感到挫败。职责分离本身并不是目标，而是实现目标的一种方法。还可以使用其他方法来实现相同的目标，因此可以在保持相同保证水平的同时整合职责。
1418
1419 信息安全严重取决于整个组织中人员的行为。受过良好培训且遵循信息安全策略和其他控制措施的员工可以帮助检测、预防和纠正安全事件。训练有素训练或工作动力不足的员工可能是一个主要漏洞。
1420
1421 支持信息安全管理需要许多过程和过程。这些包括：
1422
1423 * 安全事件管理流程
1424 * 风险管理过程
1425 * 控制评审和审核过程
1426 * 身份和访问管理过程
1427 * 事态管理
1428 * 渗透测试，漏洞扫描等过程
1429 * 用于管理与安全相关的变更（例如防火墙配置变更）的过程。这种处理安全性的集成方法有助于保证合规。
1430
1431 **案例分析**
1432
1433 大型音乐流媒体服务提供商依赖于能够快速交付。它不断提高以保持其领先状态。它的工作方式和操作模型基于速度和持续改进。即将发生的法律地位变更引入了新的合规性要求，从而触发了其运营模式的变更。
1434
1435 特别是，其财务系统受到有关职责分离和审计追踪的必要控制的影响。流程和相关工具需要变更。最初，这受到自治团队的抵制，他们为自己的工作方式感到自豪。
1436
1437 为了克服这种阻力，团队将面临挑战并拥有解决方案的所有权。提出新法规是生活中的事实：企业成长的自然结果。由于团队习惯于具有很大的自治权，因此可以信任他们发现如何遵守法规，而又不影响流程和敏捷性。内部审计团队和过程工具团队会为他们提供专家帮助。
1438
1439 每个团队都开发自己的流程和流程工具配置，并与主要利益干系人进行交互。尽管对于所有团队而言，方法的多样性可能不如一劳永逸的解决方案有效，但好处显而易见。有更好的流程，因为每个团队都遵循自己的特定流程。而且，重要的是，每个团队对遵守控制措施负有全部责任。这创造了可持续的利益。
1440
1441 从此案例中获得的主要经验是：
1442
1443 * 发挥团队优势在这种情况下，责任受到欢迎。对于较少自治的团队，可能需要另一种方法。
1444 * 着眼于外部法规，而不是如何将其转化为内部政策和约束条件。通常，可以采用其他方法来实现相同的合规性。这需要内部审计团队的灵活性。
1445
1446 图4.26显示了DevSecOps对服务价值链的贡献。
1447
1448 表4.23列出了与DevSecOps相关的实践。
1449
1450
1451 (% style="text-align:center" %)
1452 [[image:1639569550207-851.png]]
1453
1454 图4.26 DevSecOps对服务价值链贡献的热图
1455
1456
1457 表4.23 与DevSecOps相关的实践
1458
1459 (% style="width:909px" %)
1460 |**ITIL管理实践**|(% style="width:690px" %)**与DevSecOps相关的活动/资源**|(% style="width:75px" %)**影响**
1461 |持续改进|(% style="width:690px" %)安全控制和策略的改进可以成为开发和运营团队纳入的学习和反馈的一部分。|(% style="width:75px" %)H
1462 |信息安全管理|(% style="width:690px" %)在开发生命周期中设计和实施控件，以提供广泛的可追溯性和联合责任制。将信息安全职责整合到从业者的日常工作中。|(% style="width:75px" %)H
1463 |监控与事态管理|(% style="width:690px" %)配置监视工具以连续扫描威胁和漏洞，以便可以将其升级为适当的团队。|(% style="width:75px" %)H
1464 |变更控制|(% style="width:690px" %)实施预防性控制会自动要求安全管理人员进行预授权，然后开发人员才能根据某些定义的标准进行某些类型的生产数据编辑，包括他们有权使用的功能。|(% style="width:75px" %)M
1465 |部署管理|(% style="width:690px" %)(((
1466 安全管理提供有关关键证书管理，CD管道安全检查，容器安全，自动渗透测试以及数据和性能监视的指南。
1467
1468 信息安全管理和风险管理应该是从业者日常工作的组成部分。
1469 )))|(% style="width:75px" %)M
1470 |知识管理|(% style="width:690px" %)使员工和其他主要利益干系人可以访问相关的政策文档。|(% style="width:75px" %)M
1471 |风险管理|(% style="width:690px" %)(((
1472 在企业风险管理，技术风险管理和新的工作方式之间创建一种平衡，实用的方法。
1473
1474 在变更IT服务时，确定并消除对外部团队/团队的依赖，这可能涉及将批准权限委派给团队的产品/交付经理。
1475
1476 投资具有定义和集成控制的过程自动化（例如CI / CD），以执行职责分离的要求。除此之外，采用独立的第三方合规软件可以中止部署的生产，直到获得批准为止。
1477
1478 详细说明供应商合同中的要求和风险控制措施，以支持职责整合，并守组织的安全策略。
1479
1480 进行价值流映射，以识别和最小化流程移交和批准。
1481 )))|(% style="width:75px" %)M
1482 |服务验证与测试|(% style="width:690px" %)测试数据管理是帮助确保持续稳定性，可靠性，可用性和安全性的关键元素。|(% style="width:75px" %)M
1483 |战略管理|(% style="width:690px" %)整合职责以平衡法规要求和执行速度。|(% style="width:75px" %)M
1484 |劳动力和人才管理|(% style="width:690px" %)在如何将安全性纳入开发和运营工作方面，对员工和其他相关利益干系人进行培训和辅导。|(% style="width:75px" %)M
1485 |业务分析|(% style="width:690px" %)(((
1486 了解内部和外部环境中的安全策略，标准，风险，潜在威胁和漏洞，并将其转化为开发和运营团队的要求。
1487
1488 将安全要求纳入产品积压中。
1489 )))|(% style="width:75px" %)L
1490 |基础架构管理|(% style="width:690px" %)(((
1491 安全管理可以通过有关安全标准和培训，隐私审查，威胁建模，凭证管理和数据安全的指南来增强基础架构和平台管理（尤其是在将基础架构用作代码时）。
1492
1493 信息安全管理和风险管理应该是从业者日常工作的组成部分。
1494 )))|(% style="width:75px" %)L
1495 |软件开发管理|(% style="width:690px" %)(((
1496 通过有关安全编码标准和培训，隐私审查，威胁建模，代码分析，源代码和凭证管理以及数据安全性的指南来增强软件开发。
1497
1498 信息安全管理和风险管理应该是从业者日常工作的组成部分。
1499 )))|(% style="width:75px" %)L
1500
1501 //ITIL故事：DevSecOps//
1502
1503 //Henri：数据的完整性和安全性是Axle汽车租赁团队工作方式的基础。快速工作以高节奏提供新的应用程序功能时，存在引入安全漏洞的风险，这些漏洞可能会被利用。//
1504
1505 //Marco：我们所有的员工都接受过培训，以了解他们的行为如何危害我们的安全。他们遵循安全流程，可以检测，预防和纠正安全事件。//
1506
1507
1508 === 4.5.3 同行评审 ===
1509
1510 **定义：同行评审**
1511
1512 同一领域的其他人对一件科学或其他专业作品的判断。当应用于软件开发时，工作产品的开发人员和一个或多个同事将对其进行检查，以评估其技术含量和质量。这有助于保证合规。
1513
1514
1515 (% style="text-align:center" %)
1516 [[image:1639569657674-856.png]]
1517
1518 图4.27 同行评审形式谱
1519
1520
1521 基于在工程行业中的同行评审的价值，许多行业专家已将其视为非常理想的开发实践。经验表明，如果开发过程包含同行评审，则可以较早地消除问题（缺陷）。这些审核与测试一样有效，甚至比测试更有效。
1522
1523 同行评审提供了一种纪律严明的工程实践，用于检测和纠正设计产品中的缺陷。在软件工程和其他工程学科（包括电气，土木，机械和消防工程）中，它也是提高设计过程质量和生产率的最有效方法之一。
1524
1525 在同行评审过程中收集的数据用于纠正缺陷，以及评估和改进开发过程本身。
1526
1527 同行评审方法可以包括以下一项或多项：
1528
1529 * 检查
1530 * 团队审查
1531 * 演练
1532 * 结对编程
1533 * 同行检查
1534 * 传送
1535 * 临时审查。
1536
1537 这些方法按形式顺序在图4.27中进行了说明。此外，表4.24概述了不同类型的同行评议中通常包括的活动（摘自Wiegers，2002年；经纽约皮尔森教育公司许可转载）。
1538
1539 表4.24 在不同的同行评审方法中的活动
1540
1541 |(% rowspan="2" %)**评审方法**| | |**活动**| |
1542 |**规划**|**准备**|**讨论**|**改进**|**验证**
1543 |检查|是|是|是|是|是
1544 |团队审查|是|是|是|是|无
1545 |演练|是|无|是|是|无
1546 |结对编程|是|无|连续|是|是
1547 |(((
1548 同行检查
1549
1550 传送
1551 )))|无|是|可能|是|无
1552 |临时审查|无|无|是|是|无
1553
1554 (% style="text-align:center" %)
1555 [[image:1639569697056-454.png]]
1556
1557 图4.28 同行评审对服务价值链贡献的热图
1558
1559
1560 表4.25 与同行评审相关的实践
1561
1562 (% style="width:919px" %)
1563 |**ITIL管理实践**|(% style="width:622px" %)**与同行评审相关的活动/资源**|(% style="width:104px" %)**影响**
1564 |风险管理|(% style="width:622px" %)(((
1565 减少未经授权的变更被开发并发布到生产中的风险。
1566
1567 在识别和评估风险之间进行交叉检查。
1568 )))|(% style="width:104px" %)H
1569 |软件开发管理|(% style="width:622px" %)检查同级之间的开发工作以提高代码质量，以确保其有效满足需求和性能期望。|(% style="width:104px" %)H
1570 |变更控制|(% style="width:622px" %)(((
1571 同事通过对标准或低风险变更进行同行评审来充当变更权限。
1572
1573 通过同行评审或对变更请求的初步评估来授权进行某些变更。
1574 )))|(% style="width:104px" %)M
1575 |持续改进|(% style="width:622px" %)审查作为持续改进计划一部分而完成的工作，以帮助提高所取得成果的质量。|(% style="width:104px" %)M
1576 |基础架构管理|(% style="width:622px" %)检查基础架构和平台组件以提高其质量。|(% style="width:104px" %)M
1577 |知识管理|(% style="width:622px" %)查看知识文章和类似文档可帮助消除偏见并提高整个组织的沟通质量。|(% style="width:104px" %)M
1578 |问题管理|(% style="width:622px" %)审查规避措施并提出对错误的修正，以提高其质量。|(% style="width:104px" %)M
1579 |架构管理|(% style="width:622px" %)对技术架构的拟议变更进行演练，以确保变更与商定的蓝图和路线图保持一致。|(% style="width:104px" %)L
1580
1581 图4.28显示了同行评审对服务价值链的贡献。
1582
1583 表4.25概述了同行评审相关的实践。
1584
1585
1586 **ITIL故事：同行评审**
1587
1588 //Su：我们的应用程序开发团队协同工作，并定期进行定期的同行评审。我们从同事的专业知识和经验中受益匪浅，他们会互相回顾彼此的工作，并在问题到达实际环境之前发现并纠正问题。//
1589
1590 //索尔玛兹：我们倡导开放，无责的文化，这意味着个人在与同行分享工作时会感到自在。这有助于构建强大，有影响力的服务，为所有利益干系人创造价值。//
1591
1592
1593 == 4.6 小结 ==
1594
1595 在第2章中，描述了实现高速IT的五个重要组织目标。为了支持实现这些目标，组织可以采用多种技术和模型。其中一些是最近开发的，而其他一些则是根据以前采用的运营模型和管理方法改编的。第4章探讨了一些流行且重要的技术。
1596
1597 在本章中，这些技术围绕高速目标进行了分组。但是，它们中的大多数在一定程度上有助于实现多个目标。HVIT技术在许多实践中普遍适用。为了帮助在实践中采用它们，提供了它们对服务价值链的相对贡献的热图。
1598
1599 请从业者将此章视为一个多功能工具集，并根据上下文和所执行的工作任务来应用这些工具。实施此处描述的技术不应仅作为目标。应始终将它们视为实现组织目标的手段。这适用于本出版物的其他章节以及总体上的ITIL：应采用并改编这些工具以满足组织的需求。
1600
1601
1602
1603 **结论**
1604
1605 数字化技术已经打破了许多行业的业务，带来了新的机遇和新的挑战。商业产品、服务和运营都发生了重大变化，即所谓的数字化转型，而这种变化需要采用新的IT和业务管理方法。
1606
1607 为了满足这些要求，已经开发了许多方法，技术和工具。这些的数量和种类以及决定如何最好地使用它们会带来挑战，并且选择合适的方法并不总是容易的。除了对产品、服务和运营的变更之外，数字化转型还涉及文化和组织上的变革，这些变革自身都有困难。
1608
1609 业务和IT领域的领导者和从业者应该了解数字化转型的前景，并能够定义目标，采用有效的行为模式并采用适当的技术来取得成功。
1610
1611 该出版物概述了数字化转型以及高速业务和IT管理的关键概念。它提出了一组目标和行为模式，这些目标和行为模式将帮助企业转型，使其从数字化技术中获得最大收益。最后，它描述了可以支持每个目标的有用技术和方法的集合。ITIL SVS提供了一个整体结构，将有助于高速IT的实际应用。
1612
1613 为了充分利用ITIL 4：高速IT，应与ITIL管理实践指南一起进行研究，该指南可在线获得，并为所有34种实践提供详细的实用建议。它们包括可在所有ITIL 4出版物中应用的动手指南。
1614
1615 所有ITIL出版物都是整体出版物，并且注重价值。它们解决了服务管理的四个方面，并以一种能够为组织，其客户和其他利益干系人创造价值的方式帮助管理资源。
1616
1617 //ITIL4：指导、计划和改进：//为使产品和服务管理与当今的业务需求保持一致，推动成功的组织转型以及将持续改进融入组织的各个层次的文化提供了指导。
1618
1619 //ITIL4：驱动利益干系人的价值：//包含有关建立、维护和发展有效服务关系的指南。它带领组织以服务提供者和服务使用者的身份进行服务之旅，帮助他们在每个步骤进行有效的交互和沟通。
1620
1621 //ITIL4：创建、交付和支持：//提供有关产品和服务管理的文化和团队管理方面的指南，并概述了支持服务管理的各种工具和技术。它演示了如何将管理实践集成到端到端的价值流中。
1622
1623
1624
1625 [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%AB%98%E9%80%9FIT%E3%80%8BHVIT/3.%E9%AB%98%E9%80%9FIT%E6%96%87%E5%8C%96/]]
深圳市艾拓先锋企业管理咨询有限公司