文档更改4.高速IT技术

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Attachments (0 modified, 2 added, 0 removed)
  • 1639234221475-444.png
  • 1639234467928-357.png

Details

Page properties

Content

...	...	@@ -316,4 +316,134 @@
316	316	(% style="text-align:center" %)
317	317	[[image:1639234096344-870.png]]
318	318
	319	+图4.6 影响大小的变更可用于实现快速研发的技术包括：
	320	+
	321	+* 基础架构即代码
	322	+* 松耦合信息系统架构
	323	+* 评论
	324	+* 持续业务分析
	325	+* 持续集成/持续交付
	326	+* 连续测试
	327	+* 看板
	328	+
	329	+
	330	+**ITIL故事：快速研发的技术**
	331	+
	332	+//Solmaz：我们不断开发新的应用功能，并定期且频繁地发布改进和变更。这有助于我们更早地实现价值并尽快收到反馈。它还使我们能够优先考虑开发的新功能和支持工作。因为变更很小，所以它们需要较少的支持，并且服务中断的风险也较少。//
	333	+
	334	+
	335	+=== 4.2.1 基础架构即代码 ===
	336	+
	337	+基础架构即代码（IaC）支持更快的环境配置，从而有助于更快的开发和更有弹性的运营。虚拟化和虚拟机管理程序技术（通常通过云提供）允许通过编程接口远程创建、修改和删除基础架构项目。如今，使用脚本和配置文件来构建和配置服务器是一种常见的做法。
	338	+
	339	+IaC是一种通过使用机器可读的定义文件而不是物理配置硬件组件来管理和配置IT基础架构和平台的方法。然后可以将这些文件存储在版本控制系统中（请参阅第4.3.4节中的版本控制）。
	340	+
	341	+幂等性的概念是IaC的关键。这意味着部署命令始终将目标环境配置为指定的状态，而不管它以前是什么状态。这可以通过重新配置目标环境或用新的环境来实现。为此，需要对环境描述进行变更，并创建新版本的配置模型。该代码经过验证和测试，以防止常见的部署问题。发布流水线执行配置模型，从而产生新的（重新）配置的目标环境。如果需要变更，则编辑源，而不编辑目标。Vagrant、Ansible、Puppet和Docker等工具支持整个流程。基础架构即服务（IaaS）和平台即服务（PaaS）等基于云的解决方案使用IaC定义来动态配置和删除环境。然后，团队可以根据需求可靠地配置多个测试环境。这使他们能够在开发周期的早期阶段在类似生产环境中测试应用程序。
	342	+
	343	+选择使用IaC而不是传统的物理配置是一项架构设计决策，影响深远。架构的本质是选择要使用的构件或资源，以及如何使用它们。基础架构和平台的数字化可以更快，更可靠地配置所有必要的环境，例如开发、测试和生产，从而有助于快速研发和部署。这对于实现弹性运营也同样重要，因为它可以从某些事件中更快地恢复，并通过减少人为的错误来防止其他事件，例如手动错误配置和配置漂移。IaC效率更高，因为它具有较少的可重复手动操作，从而通过降低基础架构成本来促进宝贵的投资。
	344	+
	345	+图4.7显示了IaC对服务价值链的贡献。
	346	+
	347	+
	348	+(% style="text-align:center" %)
	349	+[[image:1639234145163-398.png]]
	350	+
	351	+图4.7 基础设施作为代码对服务价值链的贡献的热图
	352	+
	353	+‘
	354	+
	355	+表4.5 与基础设施作为代码相关的实践
	356	+
	357	+(% style="width:825px" %)
	358	+|**ITIL管理实践**|(% style="width:560px" %)**与基础设施作为代码相关的活动/资源**|(% style="width:90px" %)**影响**
	359	+|架构管理|(% style="width:560px" %)验证架构决策并比较基础架构解决方案。|(% style="width:90px" %)H
	360	+|变更控制|(% style="width:560px" %)启用虚拟基础架构组件的快速配置或停用，以平衡交付速度与治理，风险和合规性需求。|(% style="width:90px" %)H
	361	+|部署管理|(% style="width:560px" %)自动化基础架构的部署，确保基础架构和应用程序的部署更快，更重复，更可靠。|(% style="width:90px" %)H
	362	+|信息安全管理|(% style="width:560px" %)在虚拟基础架构组件中设计和实施安全策略。|(% style="width:90px" %)H
	363	+|IT资产管理|(% style="width:560px" %)跟踪分配给通常快速配置或停用的虚拟基础结构组件的商业软件许可证的使用。|(% style="width:90px" %)H
	364	+|知识管理|(% style="width:560px" %)存储虚拟服务器配置文件，并使它们可用于IaC自动化。|(% style="width:90px" %)H
	365	+|服务配置管理|(% style="width:560px" %)以适当的粒度级别设计和维护配置管理数据库和关系，以跟踪经常快速调配或退役的虚拟基础架构组件。|(% style="width:90px" %)H
	366	+|服务财务管理|(% style="width:560px" %)由于对基础设施的投资减少，资金从资本支出转向运营支出。|(% style="width:90px" %)H
	367	+|服务请求管理|(% 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" %)利用IaC功能自动化（在适当情况下）事件恢复任务。|(% style="width:90px" %)M
	371	+|基础架构管理|(% style="width:560px" %)快速交付/配置虚拟硬件基础架构。|(% style="width:90px" %)M
	372	+|问题管理|(% style="width:560px" %)利用IaC功能进行问题检测和错误控制。|(% style="width:90px" %)M
	373	+|服务连续性管理|(% style="width:560px" %)设计适当的连续性计划以反映组织对IaC功能的使用。|(% style="width:90px" %)M
	374	+|供应商管理|(% style="width:560px" %)选择可以提供IaC功能或利用组织对IaC的投资的供应商。|(% style="width:90px" %)M
	375	+|风险管理|(% style="width:560px" %)认识到通过使用IaC引入或减轻的风险。|(% style="width:90px" %)L
	376	+
	377	+表4.5 列出了与基础设施作为代码相关的实践。
	378	+
	379	+
	380	+**ITIL故事：基础架构即代码**
	381	+
	382	+//Marco：在测试环境下，我们在虚拟机上使用虚拟机监控程序技术创建了多个测试环境。我们想在多个平台上模拟该应用程序的使用。因为我们在开发周期的每个阶段都对代码进行了验证，所以我们知道该应用程序将随着它的增长而继续在不同的设备上运行。//
	383	+
	384	+
	385	+=== 4.2.2 松耦合信息系统架构 ===
	386	+
	387	+松耦合信息系统架构基于相对较小的独立组件。该架构使工作能够在相对较小的，相对独立的，基于产品或服务的团队和基于平台的团队中完成。通过将系统分解为可以相对独立地开发和管理的部分，团队可以专注于自己的部分并限制与其他团队的互动。基于产品或服务的团队由开发人员和工程师以及代表消费者观点的产品/服务所有者组成。更紧密的协作对快速研发和价值共创都是有益的。它还有助于进行有价值的投资、快速研发和弹性运营（其中IT运维也在团队中出现）。
	388	+
	389	+紧密耦合的体系结构（例如在单片信息系统中）的最大问题之一是变更的速度极低，因为许多变更都需要重新设计和重新开发系统的多个部分。实际上，在同一系统上增加更多的团队和员工可能会降低速度，因为这可能导致体系结构级别的组件之间的深度互连过多。
	390	+
	391	+一个密切相关的技术是应用程序绞杀。这可用于逐渐围绕旧应用创建新应用，然后用新代码慢慢替换旧代码。当无法重构应用程序（在不变更其功能的情况下重构代码）并且必须替换它时，这很有用。此技术可能会损害性能和可靠性，因此，如果使用此技术，则需要仔细的监督实施。
	392	+
	393	+微服务和容器化等技术通常与松耦合的体系结构相关。
	394	+
	395	+
	396	+**定义**
	397	+
	398	+* **微服务 **面向服务的体系架构的一种变体，其中应用程序被设计和开发为一组小型的、松散耦合的服务，每个服务都在自己的流程中运行并使用轻量级机制进行通信。
	399	+* **容器化 **将软件打包为标准化的轻型，独立，可执行单元以进行开发，运输和部署的技术。
	400	+
	401	+松散耦合的信息系统体系架构的优点包括：
	402	+
	403	+* 它有助于更快的开发和更频繁的变更。
	404	+* 它支持演进架构。
	405	+* 它效率更高，导致重新设计和开发产品或服务所需的工作更少。
	406	+* 它使从专注于组件的团队结构切换为基于产品或功能的团队结构。图4.8显示了松散耦合信息系统架构对服务价值链的贡献。表4.6概述了与松散耦合信息系统架构相关的实践。
	407	+
	408	+
	409	+**ITIL故事：松耦合信息系统架构**
	410	+
	411	+//Su：我们在应用程序中使用了松耦合信息系统架构。通过将系统视为相对较小且独立的组件，每个组件上的团队可以独立工作，因为他们了解组件会接收的输入以及工作流中后续组件所需的输出。这减少了不同组件之间的重复、复杂性和相互依赖性//该应用程序。
	412	+
	413	+
	414	+(% style="text-align:center" %)
	415	+[[image:1639234221475-444.png]]
	416	+
	417	+图4.8 松散耦合信息系统架构对服务价值链贡献的热图
	418	+
	419	+
	420	+表4.6 与松散耦合信息系统架构相关的实践
	421	+
	422	+(% style="width:718px" %)
	423	+|(% style="width:108px" %)**ITIL管理实践**|(% style="width:520px" %)**与松散耦合信息系统架构相关的活动/资源**|(% style="width:87px" %)**影响**
	424	+|(% style="width:108px" %)架构管理|(% style="width:520px" %)设计松耦合的服务，技术和信息体系结构。|(% style="width:87px" %)H
	425	+|(% style="width:108px" %)业务分析|(% style="width:520px" %)了解消费者需求并将其转化为每个需求的详细需求松耦合服务体系结构的组件。|(% style="width:87px" %)H
	426	+|(% style="width:108px" %)部署管理|(% style="width:520px" %)部署的范围和部署模式因以下因素的解耦而减小：系统架构；这使部署更易于管理和复制，并且功能强大自动化的候选人。|(% style="width:87px" %)H
	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" %)M
	434	+|(% style="width:108px" %)事件管理|(% style="width:520px" %)事件后可以计划调查和解决方案， 以更少的压力和更有效的方式进行演练。服务中断的影响松散耦合的体系结构通常限于无法使用的配置项（CI），而不是其他CI。这是由于系统组件的设计原理应该具有弹性，并且不依赖于其他配置项提供的服务。结果是，事件对客户的影响较小。|(% style="width:87px" %)M
	435	+|(% style="width:108px" %)服务财务管理|(% style="width:520px" %)松散耦合的系统体系结构使第三方服务的耦合和解耦更加容易，从而使服务提供商能够利用降价和提供新产品的优势。 这种灵活性还要求服务提供商采用敏捷成本核算模型来有效地切换提供商。|(% style="width:87px" %)M
	436	+|(% style="width:108px" %)供应商管理|(% style="width:520px" %)当某些组件松散时，建立合同并管理绩效。耦合体系结构由供应商或外部服务提供商提供。|(% style="width:87px" %)M
	437	+|(% style="width:108px" %)战略管理|(% style="width:520px" %)由于投资的原因，将紧密耦合的体系结构去耦是一项战略级决策必要条件以及利用它的潜在运营模式含义（例如引入自治团队）。 这种架构的一个例子是面向服务的可以将第三方服务作为端到端服务的一部分的体系结构。|(% style="width:87px" %)L
	438	+
	439	+
	440	+=== 4.2.3 复查 ===
	441	+
	442	+通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
	443	+
	444	+
	445	+==== 4.2.3.1 回顾 ====
	446	+
	447	+在敏捷中，回顾是在迭代（或称为“ 冲刺”）或项目结束时召开的团队会议，以讨论哪些进展顺利，哪些可以改进的方面以及将来如何从中受益。这种快速而频繁的反馈有助于快速研发。回顾可以应用于大多数场景以及需要不断改进的任何区域。为有效起见，应定期安排他们的时间，并由主持人安排参与者的贡献。应确定为持续改进而输入的行动，并委派责任。图4.9显示了回顾对服务价值链的贡献。
	448	+
319	319

1639234221475-444.png

Author

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

Size

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

Content

1639234467928-357.png

Author

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

Size

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

Content