软件的开发是为了解决问题。然而，开发软件的过程往往会带来一系列新的问题，有时甚至会在过程中产生新的问题。一个组织需要在开发定制软件或购买预构建软件之间做出选择。对于像办公生产力套件这样的通用软件，购买预构建的软件通常是最经济的选择。然而，企业在业务功能领域中开发先进解决方案时，往往需要定制开发。定制解决方案的创建旨在实现获得竞争优势或提高效率的最终目标。
20世纪90年代末到2000年代初，软件开发的过程发生了重大变化。这一重大转变从对需求收集的高度关注，转向了对迭代和速度的关注。软件开发的迭代方式包括可重复的流程和自动化，从而能够快速交付新功能，并在整个开发生命周期中融入反馈循环。结合鼓励开源和透明心态的组织文化变革，形成了更加关注质量而非领域的跨职能团队，以及开发、运维和安全团队的融合，即DevSecOps。
本章探讨了推动DevSecOps运动的驱动因素。软件开发过程是最初的关注点。软件开发方法的演变为全面理解并成功实施DevSecOps提供了必要的背景。本章还重点强调了组织在迈向DevSecOps过程中文化变革的重要性。
开发软件
为了实现目标，组织会分配部分资源来创建软件。需要考虑的是，这些资源也可以投资在其他可能获得更高回报的地方。例如，将10万美元投资于营销可能会比将这些资金用于简化网站上的客户注册流程带来更多的客户。
即使资金不是问题，速度也是一个关键因素。快速创建并部署软件的能力是获取竞争优势或提高效率的任何努力中的限制因素。在某个阶段之后，向项目中增加更多开发人员并不会使项目更快完成。恰恰相反，随着更多开发人员的加入，连贯的沟通变得不可能。
软件从一个想法开始。将这个想法转化为可用的软件需要深思熟虑和规划。软件开发项目可以采用几种流程来管理，这在一定程度上取决于所开发的软件类型。软件开发涉及定义需求、设计解决方案、开发和编写代码，最后在发布前对软件进行测试。图1-1对此过程进行了说明。
这四个阶段，有时称为软件开发生命周期（SDLC），可以被概念化为一个瀑布模型，每个阶段都会产生一个或多个工件，然后这些工件被传递或“流”到下一个阶段，类似于图1-2所示。
在使用像瀑布模型这样的方法来开发软件时，每个阶段在进入下一个阶段之前都要完成。这在图1-1中得以说明，需求在进入设计阶段（在图1-1中标记为“设计解决方案”）之前被收集和记录。如果在设计阶段发现了新的需求或额外的问题引出了新的需求，这些元素通常会被添加到后续的项目中。
在需求收集阶段结束时，项目正式定义了范围，其中包括软件的所有功能。这些功能不仅包括软件的主要功能，还包括一些非技术上必须的、但用户期望的软件功能。这些非功能性需求包括响应速度、安全性以及应用程序的其他行为。如果没有捕捉并添加这些非功能性需求，最终的软件产品将让用户感到沮丧和失望。
考虑一个业务需求：使客户能够找到产品并下订单。在计算机出现之前，这一业务需求可以通过多种方式实现，包括客户走进商店，找到并购买产品，或使用目录找到产品，打电话给公司，并通过电话下订单。随着计算机和互联网的出现，这一业务需求现在通常通过网站来实现。
通过网站实现使客户找到产品并下订单的业务需求，留下了很大的空间来找到解决方案。在网站上上传目录的PDF文件，并提供一个表单让客户通过电子邮件发送订单，满足了网站的最低功能要求。然而，尽管需求得到了满足，大多数用户会期望不同的体验，可能不会使用如此笨拙的流程来下订单，这一过程缺乏许多客户在网上订购产品时理所当然的功能。
因此，还需要捕捉非功能性需求。向利益相关者或项目发起人提出一些探索性问题将揭示关于解决方案意图的丰富细节。例如：
- 产品如何在网站上展示（照片、描述、技术规格等）？
- 谁来拍摄产品照片并为网站制作，谁来撰写描述性产品介绍？
- 如何更新库存，以避免客户订购缺货产品？
- 订单将如何下达？
- 员工如何在有新订单时收到通知？
- 谁将负责在线目录的更新，包括新产品？
- 接受哪些支付方式？
- 客户是否需要创建账户、跟踪订单历史、跟踪发货情况？
这些问题只是需要在初步探索或可行性会议上回答的众多问题中的一小部分。其中一些问题在可行性阶段或需求收集阶段已经或将迅速成为功能需求。然而，如果会议中没有人部署过这样的项目，肯定会遗漏一些需求。
因此，项目范围定义了包含的元素，并划定了不打算包含在项目中的其他元素。任何未明确包括的内容都被认为是排除在外的，因此不在项目的范围内。如果遗漏了一个基本需求，项目发起人将面临重新定义范围或在没有该需求的情况下推进项目的选择，然后在后续项目中添加遗漏的功能。
从构思到实施可能会经历数月甚至数年的时间。构思与软件产品发布之间的延迟，使得等待遗漏功能的过程对于项目发起人来说更加痛苦。在这种延迟期间，可能实现的任何竞争优势可能会迅速消失，特别是在没有遗漏该需求的竞争对手发布了他们自己的版本时。
以下部分将探讨围绕现代软件开发的一些问题及其相关解决方案。
开发敏捷性
为了应对项目定义与完成之间的滞后，组织开始采用迭代流程，如敏捷（Agile）和Scrum，作为快速向利益相关者交付价值的一种手段。在迭代的软件开发过程中，前面提到的四个阶段（需求、设计、开发和测试）都会进行。与其试图捕捉项目所有可能方面的全部需求，迭代开发更关注对利益相关者价值最高的功能。然后，围绕这些最高价值的功能展开一轮需求收集，接着进行设计、开发、测试和发布，整个周期通常在两到四周内完成。图1-3展示了如何通过像敏捷这样的迭代过程来处理SDLC的每个阶段。
如图1-3所示，每个阶段都会完成，但不会试图收集全部需求，因为迭代开发过程中伴随着学习过程。如果遗漏了某个需求，利益相关者可以选择不发布该功能，或者在下一个迭代中添加该遗漏的需求。采用迭代开发流程，下一次发布仅在几周内即可完成，而不是几个月或几年之久。相比之下，在瀑布模型中，如果遗漏了某个需求，下一次发布可能需要几个月或几年，这样对比便能清楚地看到这一过程的优势。
迭代开发还能够快速应对不断变化的市场条件。例如，你可能有一个绝佳的创意用于开发下一款“杀手级应用”，并开始开发该应用，但你的竞争对手却发布了几乎相同的应用。在瀑布模型中，你可能需要完全放弃这个项目。而在迭代过程中，可以将重点转向竞争对手应用中可能缺失的功能。
敏捷软件开发包含多个仪式，如迭代计划、每日站会、迭代评审、迭代回顾和待办事项整理。首先会创建一个整体的待办事项列表，列出在某一时刻已知的所有可能功能，并根据优先级排序。然后从这个已排序的功能列表中生成一个迭代待办事项列表。迭代待办事项列表是开发团队在当前迭代中承诺实现的功能。该列表的创建基于团队成员的可用性以及他们对每个待办事项估计的工作量，也称为工作量评估（LOE）。
在迭代结束时，会进行迭代评审，团队展示在此迭代中完成的工作。在完成迭代评审后，团队会在回顾中检查在迭代过程中哪些地方可以做得不同。团队可能会在回顾中回答三个问题：
- 我们应该开始做什么？
- 我们应该停止做什么？
- 我们应该继续做什么？
这三个问题帮助团队反思哪些做法有效，哪些做法无效，以及在下一次迭代中可能会改变什么。在回顾完成后，团队可以进入待办事项整理阶段，在此阶段对产品待办事项进行细化和重新排序。利益相关者或产品负责人通常会参与待办事项的细化过程，以为团队设置优先级。
开发有缺陷的软件
不完善的需求会导致有缺陷的软件，或者说软件无法满足最初的需求。不完善的软件可能会在最初需求成功从项目发起人那里收集到的情况下仍然出现，最终结果是用户不满、功能损坏和安全问题。
在审查需求时，开发人员经常会遇到问题。这些问题的范围从琐碎的，比如在某些语言中条件语句的大括号应该放在哪里，到关键问题，比如获取数据库连接的凭证。在后者情况下，开发可能需要暂停，直到获得这些凭证。在其他情况下，开发人员可能会尽自己最大的能力回答这些问题，并继续推进开发。
在孤立的环境中开发软件，缺乏与开发人员以外的其他人的互动，往往会导致软件出现问题。在这种孤立的开发风格中，采用瀑布模型或类似的方法，开发人员会尽其所能去审查和解释需求。考虑以下问题：“网站应在哪些网页浏览器中正常运行？”以及一个常见的回答：“浏览器？我一直在使用Chrome开发，没想到还要考虑网站在其他浏览器中的运行情况。”图1-4展示了孤立开发的情景，在这种情况下，开发人员、运维人员和安全工程师之间缺乏良好的沟通。
最后期限决定了功能的数量和质量。 交付的最后期限可能紧迫到甚至没有时间去识别可能在使用不同浏览器或不同视口（如手机）进行测试时出现的问题，更不用说修复这些问题了。如果项目中没有包含跨浏览器测试作为一个步骤，并且需求中没有明确规定网站必须在哪些浏览器中正常运行，那么到底网站能在哪些浏览器中正常运行就变得难以预测。
项目的最后期限或时间表是软件开发项目中可以控制的三个杠杆之一。其他两个杠杆是成本和功能。老话说，一个项目只能在三者中选择两个，这意味着如果项目需要快速完成且具有许多功能，那么成本将增加。同样，如果项目需要许多功能但成本较低，那么完成项目将需要更长的时间。最后，如果必须尽可能压低成本，同时还要在最后期限内完成，那么功能通常是首先被牺牲的。
图1-5展示了软件开发三角形的概念。
接下来我将讨论开发与质量保证（QA）之间的交接问题。
在暗室中操作
在开发和测试之间，存在着一个常常令人尴尬的交接过程，这个交接发生在那些开发软件的人与现在负责在生产环境中部署、操作和支持软件的团队之间：即运维团队。运维团队可能有许多不同的称谓，包括网络管理员、系统管理员，或工程师（如站点可靠性工程师[SRE]、生产工程师等）。
运维团队需要接手可能从未在类似生产环境的计算环境中测试过的软件，并根据组织所需的服务级别协议（SLA）运行该软件。该软件可能只在开发人员的工作站上进行过测试，随后仅在一个小规模的质量保证（QA）环境中测试过。QA环境的配置可能完全不同——例如，可能缺少负载均衡器，可能部署在不同的区域，并且可能远没有生产环境那么繁忙。尽管如此，软件还是被部署到生产环境中，运维团队需要对其提供支持。
考虑以下情景：直到软件部署的那一刻，一切运作良好。几乎没有任何请求的延迟，即使所有开发人员都在同时使用该网站，响应时间也没有明显问题。然而，没有人注意到的是，开发人员使用的服务器与他们在同一局域网（LAN）上，并且应用程序使用的数据来自一个很少接收请求的非生产副本。
当运维团队将软件部署到生产环境时，网站的性能立即下降到几乎无法使用的程度。登录的用户无法继续，因为会话被分布在多个服务器上，而不是像开发人员在整个开发生命周期中使用的那台服务器。接着还有安全问题。
将安全性置于次要地位
在一些组织中，存在一种“无论如何都要出货”的心态，以及“最低可行产品”（MVP）的态度。虽然从理论上讲，这样的开发范式可能可行，但前提是假设将会有时间回头修复使软件成为“最低可行”的问题。然而，这种时间几乎不存在。
当最后期限迫近时，安全性往往是第一个被牺牲的需求，假设安全性曾经被考虑过。就像数学一样，安全性是困难的。安全分析师每次都必须是正确的，而攻击者只需一次成功即可。
在一个组织中，数据安全部门往往被视为那个总是说“不”的部门。无论是请求一个新应用程序、修改防火墙规则，还是放宽数据库访问的规定，负责维护安全性的人在接收到变更请求时，通常会倾向于说“不”。
运维和数据安全的固有问题在于，它们的作用往往是隐形的，直到出了问题才会被注意到。对于数据安全来说，许多时间花在响应合规审计上，这些审计在许多组织看来，似乎对日常安全性并没有太大价值。不要误会，法律和法规合规性是必不可少的，但法规往往滞后于现实，这意味着这些法规只能确保对过去漏洞的合规，而攻击者已经在利用最新的零日漏洞。
在DevSecOps的背景下，安全集成是必要的，这样防火墙更改或非合规的数据访问和存储方法甚至不会被考虑。如果没有安全集成，开发人员可能会使用未加密的密码或将凭证存储在源代码管理系统中，从而可能将它们暴露给未经授权查看数据的人员。
本节讨论了与软件开发相关的许多问题，其中一些问题可以通过DevOps和DevSecOps解决。接下来，我将深入探讨你所在组织的文化如何决定你在DevSecOps中的成功。
文化优先
组织文化是决定DevSecOps是否成功的主要因素。一个以控制为导向、自上而下的组织在实施真正的DevSecOps所需的变革上会遇到困难。这样的组织可能会使用一些看起来像DevSecOps的技术，但跨团队协作的文化转变将阻碍其取得真正的成功。
如果没有在一个严格控制导向的组织中尝试实施类似敏捷的实践，就不可能真正理解文化契合的重要性。在这样的组织中，最优的解决方案往往不如服从和保持分离来维持上层控制更为重要。如果没有这种经验，可能会认为文化在DevSecOps的成功中并不起作用。
当然，DevSecOps的目标并不是无政府状态和混乱。相反，DevSecOps促进了一种解决问题的方法，即使解决方案来自不同部门的人。一些人可能认为DevSecOps在与初创公司心态（历史上更为灵活的文化）结合时更为成功，但这一运动远比这要复杂得多。
初创公司心态意味着竞争力和创新，打破常规，不考虑等级制度。初创公司的创始人经常与员工并肩工作，作为他们的同事，甚至导师，共同推动产品的发展。在初创公司中，职位头衔并不如确保工作完成那么重要。
在DevSecOps中，人们跨越工作职能共同协作，在需要的地方运用他们的技能。像在初创公司中一样，团队对他们的工作保持透明，专注于完成有用工作的最终目标。在这样的环境中，潜在的问题可以在早期被识别和解决，远在问题变得明显之前。
没有安全的DevOps
在DevSecOps之前，存在的是DevOps（开发与运维）。然而，人们很快意识到，没有有效的安全实践整合，开发和运维无法取得成功。通过在项目开始时就整合安全讨论，安全可以变得无处不在但不会侵入性地干扰工作。
即使组织还没有准备好完全整合安全性，DevOps也可以存在并发挥作用。然而，那些导致DevOps运动的同样问题——在部署的问题发现得太晚——也可能因为生产或实际环境中存在的（必要的）安全控制而发生。当这种情况发生时，推动DevSecOps作为文化变革的势头就会增强。
下一节将探讨DevOps的核心，即强调过程而不是实现这些过程的工具。
过程优于工具
DevOps 和 DevSecOps 更注重流程，而非实现这些流程的工具。如果没有文化上的契合和流程的变革，DevSecOps 中使用的工具往往会妨碍进展，有时甚至会减慢开发速度。即使一个组织尚未准备好进行真正 DevSecOps 所需的文化变革，使用一些 DevSecOps 的最佳实践也可以带来一定的好处。让我们先从如何识别能够接受 DevSecOps 的人才开始，探讨其中的一些实践。
提升合适的技能
管理层的支持和对 DevSecOps 流程的明确承诺是决定 DevSecOps 成败的最终仲裁者。让团队互相沟通只是第一步，虽然这更具有象征意义而非实际效果。管理者不能指望把有时利益相冲突的人聚在一起就能产生奇迹。
在 DevSecOps 中发现价值的流程需要跨越职能领域的多样化技能组合。例如，一个既能够部署自己的集群，又能清楚说明 DNS 和 DHCP 区别的开发人员，是组织中 DevSecOps 试点项目的合适人选。因此，识别具有跨职能经验的员工才是真正的第一步。这些人可以成为 DevSecOps 推动工作的倡导者。
识别多样化的技能，并让具备这些技能的员工跨越职能边界，是流程的第一步，且说明了管理层和高层领导对 DevSecOps 的支持至关重要。开发人员需要访问，或至少能够看到，可能以前只属于运维职责范围的服务器和网络领域。运维和安全人员需要在项目生命周期的早期就给予实质性的反馈，以便他们能改进后续的流程。例如，开发中的项目变更会极大地增加磁盘利用率。然而，通过对项目进行一些微调，可以将利用率转移到另一个系统上。只有在开发过程的早期才能有机会实现这一变更，这就是为什么让运维人员实质性参与每个项目是非常重要的。
DevSecOps 作为流程
DevSecOps 的流程将来自不同职能领域的人聚集在一起。集结之后，目标是生产出更好的软件——满足需求的软件，并且能够快速、准确地交付。交付这些软件的过程中，通常会涉及到工具的使用。让我们在下一节中探讨一些这些流程。
锤子和螺丝刀
工具对于高效完成某些工作至关重要。一个屋顶工使用连接到压缩空气罐的钉枪将瓦片固定在我的屋顶上。这个工作也可以使用锤子来完成，但如果用螺丝刀则会变得非常困难。当然，承包商可以用螺丝刀的把手将钉子敲进去，但这样做会既缓慢又低效，还会导致钉子弯曲，瓦片受损。如果让我在屋顶上尝试使用钉枪，结果很可能是至少要去一趟急诊室。
DevSecOps 也是类似的道理。正如正确修屋顶需要技术娴熟的工人和工具一样，DevSecOps 也需要工具和正确使用这些工具的能力。就像合格人员使用的强力钉枪是正确的工具一样，DevSecOps 的工具在合适的人手中可以显著提高效率。
工具应当帮助完成任务，但工具本身并不定义任务。
可重复性
DevSecOps 专注于构建可重复的流程，这反过来也促进了自动化。或者说，也许是自动化促进了可重复的流程。是的，两者都成立。自动化环境创建和代码部署能够使这些流程被反复执行，并且每次都能得到相同的结果。自动化测试减轻了需要手动测试和重测相同代码区域的负担，即使在实施了更改或修复了错误之后也是如此。
在实施帮助实现可重复性的流程和工具时，“即代码”的范式在实践 DevSecOps 的组织中变得突出。“基础设施即代码”、“配置即代码”、“一切皆代码”这些术语都指的是同一个概念：尽可能使用源代码管理工具和流程来管理。
大多数服务器使用文本文件或类似文本的文件来存储配置元素。这些文本文件可以存储在诸如 Git 的源代码管理工具中。这样做可以实现配置更改的版本控制。例如，其他管理员可以回顾提交历史，看到我曾在 DNS 主机名中使用过下划线，结果导致数千个域名下线。至少那个仓库不是公开的，所以没有人会发现我的错误。严肃地说，版本控制配置更改使得在配置更改引起问题时可以快速恢复。服务器配置的源代码管理实践也有助于实现版本控制，这意味着开发人员可以部署一组特定的配置，来在相同环境中重现正在报告的错误。
相同的软件版本和相同的配置集使得软件部署具有可重复性。可重复的部署直接与持续集成/持续部署（CI/CD）场景相关，在这些场景中，代码在被推广到生产环境之前会自动经过一系列环境的测试和提升。管理员更改某个服务的配置元素，提交配置文件，并将更改推送到远程仓库，在那里更改被注意到，部署会自动开始到相应的服务器上。
注意
我有意忽略了用于存储配置的众多格式，如 Yet Another Markup Language (YAML)、INI 文件结构、可扩展标记语言 (XML)、JavaScript 对象表示法、brew 脚本、m4 命令，以及任何可以用 Vim 等文本编辑器编辑的结构。就本书的目的而言，除非这样做会导致不必要的混淆，否则你会看到所有这些格式都被简单地称为文本文件。以下是一个 YAML 示例：
- name: add docker apt key
apt_key:
url: https://download.docker.com/linux/debian/gpg
state: present
- name: add docker repo
apt_repository:
repo: deb [arch=amd64] \
https://download.docker.com/linux/debian stretch stable
state: present
可见性
DevSecOps 还通过整个开发过程提供可见性。不仅通过像每日站会这样的敏捷仪式提供频繁的可见性，还通过可以按需自动部署代码到环境的工具提供可见性。DevSecOps 团队的成员可以确切地看到哪个代码和配置存在于哪些环境中，并可以根据需要部署新的环境。
可靠性、速度和规模
可重复性和可见性带来了可靠性。代码和环境可以一遍又一遍地以相同的方式一致地部署。如果在部署过程中出现错误，由于部署工具和流程中固有的可见性，该错误会立即被发现。有了可靠性，随之而来的是速度，或者说是快速应对变化需求的能力。这个变化可能是基于需求进行扩展或缩减的需要，这在有可重复且可靠的部署流程的情况下不再困难。
微服务和架构特性
虽然不是 DevSecOps 的直接要求，但微服务的使用可以作为速度和规模的推动因素。通过微服务，代码的小功能区域被识别并分离出来，使这些功能区域可以独立存在，向架构中的其他服务提供一致的应用程序编程接口（API）。API 通常通过 HTTP Web 服务来表达。作为独立的组件，微服务可以独立于其他服务或功能区域开发和部署，从而进一步提高整体速度和开发势头。
本节探讨了 DevOps 和 DevSecOps 中涉及的一些流程。下一节将扩展本章前面提到的 SDLC（软件开发生命周期），并结合这些流程背后的思想创建一个扩展的 DevSecOps SDLC。
DevSecOps 软件开发生命周期 (SDLC)
到目前为止，希望你已经对软件开发中固有的一些问题有所了解；即使是像敏捷这样相对较新的开发方法，也会助长一种孤立的心态。为了应对这些问题，创建了一个八阶段模型，而不是图1-2中显示的四阶段模型。这个模型结合了规划、开发、测试以及其他任务，如图1-6所示。
DevOps SDLC 的主要优势在于它更接近实际的软件开发过程。 比起计划编写和测试软件，实际上花更多的时间在编写代码和测试软件上。但中间的“构建”步骤反映了现代应用程序的各个部分相互连接的组装阶段。同样，“发布”步骤反映了多个组件的需求，以及软件在开始部署之前必须通过的潜在批准关卡。本章中涉及的 SDLC 中未捕捉到的是软件上线后需要进行的操作和监控。如果没有“操作”和“监控”阶段，运维团队将再次变得不可见。
你可能已经注意到，在上一段和图1-6中，“Sec”暂时被省略了。这是因为 DevOps 在加入安全性之前本身就是一场运动。显然，安全性是必要的，但它应该放在什么位置？从概念上和实际操作上来看，将安全性作为一个独立的阶段实施是困难的。如果“添加安全性”是一个新的阶段，并且在计划之后进行，那么如果在编写代码时引入了安全问题怎么办？在测试或发布阶段之后或期间添加安全阶段也很困难。如果出现了严重的安全问题怎么办？整个项目是否会停下来以解决问题？将安全性进一步推迟到操作和监控阶段，实际上意味着问题会出现在生产环境中，这带来了生产环境中安全问题的固有危险。
相反，安全性通常被显示为每个阶段的基础。你可能会看到如图1-7所示的安全性示意图。
安全性通常以这种方式展示，目的是强调在软件开发的每个阶段都需要纳入安全性和安全导向的流程。 这样就不需要再确定安全阶段应该出现在何处，或者在发现安全问题时该如何处理。
将 SDLC 从四阶段模型扩展到由安全性包围的八阶段新模型，使 DevSecOps 的实践者能够反映现代软件开发所包含的流程。重要的是，这些阶段中的任务无论如何都已经在幕后进行了。DevSecOps SDLC 只是突出了这些任务。本书的其余部分将详细探讨这些阶段。
总结
DevSecOps 是软件开发自然演进的结果。从敏捷流程和透明的开源心态出发，DevSecOps 力图打破那些减慢开发速度并降低开发可靠性的孤立现象。文化变革是从组织的高层开始的，是从 DevSecOps 中获得最大收益的关键要素。除非管理层做出承诺，否则 DevSecOps 可能会退化为只部分使用的更多工具。然而，通过文化变革和团队之间障碍的消除，可以添加工具来促进现代组织所需的可重复性、可见性、可靠性、速度和扩展性。
接下来，本书将以图 1-7 的内容为指南，探讨常见的 DevSecOps 实践。每一章涵盖 DevSecOps SDLC 中的一个或多个阶段，特别关注流程和实践，并介绍在这些阶段中使用的选定工具。在开始 DevSecOps 的无尽之路之前，第2章包含了一些基础知识，这些知识将对本书后面的章节有所帮助。许多读者可能已经掌握了大部分甚至更多的这些知识。同样，根据背景的不同，许多读者可能对第2章涵盖的一些领域有所了解。当然，第2章中涉及的技术也可能是全新的。但随着本书深入探讨 DevSecOps，拥有对那些常常被过度使用的技术术语的共同定义和理解将对所有人有所帮助。
