Wiki source code of 4.高速IT技术

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