名词解释 + 简答

1 DevOps渊源

1.1 什么是DevOps？现代软件工程实践为什么需要DevOps？

DevOps：开发运维一体化，是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。

• 方法论基础是敏捷软件开发、精益思想以及看板方法
• 构建了强大的工具链，支持水平自动化
• 一切皆服务XaaS的理念指导
• 大量虚拟化技术的使用（开发、测试环境）
• 以领域驱动设计为指导的微服务架构方式

1. 持续性：在软件系统互联网化和服务化高速发展的环境下，软件系统需要持续不断地迭代和开发，以适应快速变化的业务需求。DevOps能够实现持续的交付，使得系统功能的添加或更新不会影响系统的使用。
2. 复杂性：随着软件系统的复杂性日益提升，质量和安全性的要求也越来越高。DevOps强调通过跨团队的沟通和协作，以及自动化和架构变更等一系列手段，来提高系统的质量和安全性。
3. 效率和成本：DevOps能够通过自动化和流程优化，有效提高研发效率，节省成本。同时，由于将开发、测试和运维融为一体，能更快地实现产品的交付。
4. 打破团队壁垒：传统的开发、测试和运维团队之间存在沟通和协作的难题，DevOps能够有效地打破这些壁垒，实现团队之间的高效合作。

1.2 DevOps 演化路径（Three Ways）

概念

• 充分理解工作流（从开发到IT运维再到客户的整个自左向右的工作流）
• 流量最大化（小批量、缩小任务间隔、缺陷控制[即不让缺陷流向下游工作重心]）
• 不断为了整体目标[相对于开发功能完成率等局部目标]的实现而优化工作流

部分关键实践和方法

• 持续构建、集成以及交付
• 按需创建环境
• 限制半成品（WIP）
• 构建支持顺利变更的安全系统
• 看板（任务可视化）

概念

• 价值流（开发-运维-客户）的快速持续反馈
• 避免问题再次发生（或者快速发现和修复）
• 从源头上保证质量

部分关键实践和方法

• 适时停止生产线
• 持续改进
• 构建自动化测试套件，确保代码随时可部署
• Dev和Ops共享目标和pain
• 远程监测手段（自动化）

概念

• 创建培育良好的文化（不断尝试、重复和练习）

部分关键实践和方法

• 营造勇于创新、敢于冒险以及高度信任的企业文化
• 确保至少20%资源投入在非功能需求上
• 不断鼓励和强化改进

1.3 关键术语

1. 持续集成（Continuous Integration，CI）：这是一种开发实践，要求开发人员每天多次将代码集成到共享代码库中。每次检入都会通过自动化构建进行验证，这样团队就可以提早发现问题。
2. 持续交付（Continuous Delivery，CD）：这是一套流程和实践，可以显著减少软件生产过程中的浪费，加速高质量功能的交付，并在您的业务和用户之间建立快速有效的反馈循环。
3. 持续部署（Continuous Deployment，CD）：意味着可以立即部署应用并向用户展示更改。
4. 基础设施即服务（Infrastructure as a Service, IaaS）：这种模式提供了云主机的虚拟机，通常在“按你所用”基础上计费。用户可以完全控制这些机器，但需要自己安装和配置所需的中间件和应用程序。
5. 平台即服务（Platform as a service, PaaS）：PaaS提供商为应用开发人员提供开发环境。服务提供商通常为开发提供工具套件和标准，并提供分发和支付渠道。
6. 软件即服务（Software as a Service, SaaS）：这是一种软件许可和交付模型，其中软件按订阅方式许可，并集中托管。
7. Docker：Docker容器将一个软件封装在一个完整的文件系统中，该文件系统包含它运行所需的一切：代码、运行时、系统工具、系统库——任何可以安装在服务器上的东西。这保证了不管是在什么样的情况下，软件总是能够以相同的方式运行。
8. A/B testing：一种技术，其中新功能或功能的不同变体可用于不同的用户集，并通过比较指标和用户行为进行评估。

2 云计算相关

2.1 什么是云计算？为什么需要云计算？

云计算是一种按量付费的模式，这种模式可以提供可用的、边界的、按序的网络访问，进入可配置的计算资源共享池（资源包括服务器、网络、存储、应用软件、服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。

1. 灵活性：用户可以拓展服务以满足自身需求，定制应用，以及通过互联网连接从任何地方访问云服务。

• 可伸缩性：可按需缩放云基础架构，以支持不断变化的工作负载。
• 存储选项：用户可以选择公有、私有或混合存储产品，具体取决于安全要求和其他方面的考虑。
• 控制选择：组织可以通过“即服务”选项，决定自己的控制水平。这些选项包括软件即服务 (SaaS) 、平台即服务 (PaaS) 和基础架构即服务 (IaaS) 。

2. 高效率：企业用户可以快速将应用推向市场，而无需担心底层基础架构的成本或维护工作。

• 可访问性：可从几乎任何与互联网连接的设备访问基于云的应用和数据。
• 节约设备成本：云计算使用远程资源，从而帮助组织节省了服务器和其他设备的成本。
• 加快产品面市速度：在云环境中进行开发使用户能够更快地将应用投入市场。

3. 战略价值：云服务可以提供最具创新性的技术，帮助企业塑造竞争优势。

• 协作：全球访问意味着团队可以在分布广泛的地点开展协作。
• 定期更新：服务提供商会定期更新服务，为用户提供最新的技术。
• 竞争优势：与竞争对手相比，企业无需耗费 IT 资源来管理基础架构，而是可以灵活发展，领先一步。

2.2 什么是云原生？

云原生是指在云计算环境中构建、部署和管理现代应用程序的软件方法。云原生是一个组合词，即cloud + native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性和分布式优势。云原生可概括为4个要点：DevOps + 持续交付 + 微服务 + 容器化。

2.3 云计算、雾计算和边缘计算范式

1. 云计算：一种利用互联网实现随时随地、按需、便捷地使用共享计算设施、存储设备、应用程序等资源的计算模式。

• 优点：灵活性、高效率、战略价值
• 缺点：
  延时：由于数据必须在用户和远程数据中心之间传输，可能会有延时
  数据安全和隐私问题：虽然云服务提供商都提供了强大的安全体系，但数据的控制权仍在服务提供商手中
• 适用场景：大数据处理、WEB应用部署，客户关系管理(CRM)等

2. 雾计算：在该模式中，数据处理和应用程序集中在网络边缘的设备中，而不是几乎全部保存在云中，是云计算的延伸概念。

• 优点：填补云和物之间的差距：安全、认知、敏捷、低延迟、高效率
• 缺点：设备管理复杂：需要配置和管理大量的设备
• 适用场景：IOT等需要实时响应和处理海量数据的场景

3. 边缘计算：是指利用靠近数据源的边缘地带来完成的运算程序。

• 优点：
  减少延迟：数据处理在网络边缘，减少了数据在用户和数据中心之间的传输，进而降低延迟
  数据安全：数据在本地处理，减少了数据泄露的风险
• 缺点：边缘设备性能有限，不适合大规模数据处理
• 适用场景：视频监控、智能家居、智慧城市、智能交通等

2.4 运维标准

2.4.1 CMMI-SVC

2.4.2 ITIL

ITIL，全称Information Technology Infrastructure Library（信息技术基础架构库）
ITIL最佳实践主要围绕5个部分：

• 服务战略
• 服务设计
• 服务转换
• 服务运营
• 服务改进

2.4.3 ITSS

2.4.4 ISO20000

ISO20000定义了“策划-实施-检查-处置“（PDCA）方法论应用于服务管理体系和服务的所有部分：

• P-策划：建立书面和协定的服务管理体系；
• D-实施：实施和运行服务管理体系，以设计、转换、交付和改进服务；
• C-检查：根据方针、目标、计划和服务需求，对服务管理体系进行监视、测量和回顾，并报告结果；
• A-处置：采取措施，以持续改进服务管理体系和服务的绩效。

2.5 传统运维的转型之路

• 互联网式运维：快速迭代、快速发布、灰度发布、安全
• 云计算下的运维：云计算系统本身的运维和基于云计算的应用系统运维；快速部署、快速更新、实时监控、自动化、动态扩容或者缩小系统部署、适应平台差异
• 大规模下的运维：标准化、自动化、智能化
• “提前”运维：介入系统可监控性、可运维性方面的设计；将系统的监控和运维接口设计提前到软件开发设计阶段

3 软件架构演进

3.1 软件架构

软件架构所需要解决的根本问题是在软件实际生产环境的诸多限制条件下，对于各种软件质量属性进行取舍和权衡，并为了满足软件架构需求（即质量属性）寻找合适的“战术”。

3.2 软件架构的4+1视图

• 逻辑视图：面向对象的分解
  • 体现功能需求/服务，一般用类图或ER图来描述
• 进程视图：进程分解
  • 进程视图主要从性能，可用性等一些非功能性需求的角度去描述系统
• 开发视图：子系统分解
  • 开发视图主要关注在软件开发实现过程中的软件模块及其组织方式
• 物理（部署）视图：建立软件和硬件之间的映射关系
  • 这个视图中，进程视图的进程会被映射到一组基于网络的计算节点上
• 场景视图：综合所有的视图
  • 场景视图是把以上一些视图的设计元素结合在一起，利用对象场景图和对象交互图来描述系统中一些重要用例的场景，对最重要的一些需求进行抽象

3.3 不同架构的优缺点和适用场景

1. 单体架构：

• 优点：
  具有非常简单的架构风格，易于构建和测试。
  以封闭的形式统一部署，便于管理和控制。
• 缺点：
  作为一个紧耦合的”大泥球”，一旦需要增加或修改功能，可能涉及大量的改动工作。
  难以应对大规模需求的扩展。
• 适用场景：业务发展早期，对于规模不大且变化不频繁的业务是一个不错的选择。

2. 分层架构：

• 优点：
  抽象和分层使得架构更加清晰，便于理解和维护。
  通过采用结构化的思考方式，能够清晰地划分不同的业务逻辑。
• 缺点：
  分层架构的紧耦合性可能导致“重复造轮子”，降低开发效率。
  修改一层可能会影响其他层，维护成本较高。
• 适用场景：业务快速增长的阶段，需要划分清晰的业务逻辑层和数据访问层来提高系统的可维护性。

3. SOA架构：

• 优点：
  使用消息通信机制提供服务，使得系统的组件化和解耦更加严密。
  ESB企业服务总线能实现服务间的灵活对接。
• 缺点：
  SOA架构可能会引入重量级的ESB，使得系统复杂性增加。
  由于服务共享数据库，容易产生数据管理的矛盾和冲突。
• 适用场景：适合大型企业级应用，不断增长的业务规模需要解决复杂的服务依赖关系。

4. 分布式架构：

• 优点：
  服务解耦程度高，每个服务的调试、部署和扩展很灵活。
  非共享数据库使得数据管理更加可控。
• 缺点：
  系统设计和维护复杂度高，需要考虑服务间的通信和数据一致性等问题。
• 适用场景：适合大型互联网公司，需要对服务进行灵活调度，快速迭代的业务。

3.4 微服务架构 VS SOA

4 软件过程方法

4.1 PSP/TSP过程

• PSP（Personal Software Process，个体软件过程）
• TSP（Team Software Process，团队软件过程）

4.2 挣值管理方法

项目的挣值管理方法(Earned Value Management，简称EVM)是用来客观度量项目进度的一种项目管理方法。

• 每项任务实现附以一定价值（credit）
• 100%完成该项任务，就获得相应价值

EVM采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量。

4.3 敏捷方法XP、SCRUM

极限编程（eXtreme Programming）是敏捷过程中最负盛名的一个，其名称“极限”二字的含义是指把好的开发实践运用到极致。

• 小型发布：XP倾向于进行小型且频繁的发布，以便在整个开发过程中获得反馈。这些发布通常是直接面向客户的，尽管它们也可能仅在内部进行。
• 结对编程：所有编程活动都是由并排坐着的两名开发者共同完成的。在XP中，没有单独编程的工作。
• 测试驱动：极限编程强调“测试先行”。在编码之前，应该首先设计好测试方案，然后再编程，直至所有测试都获得通过之后才可以结束工作。

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。

• 三个角色：Scrum Master、产品负责人、团队
• 三个工件：产品待办事项、Sprint待办事项、可交付产品增量
• 五大仪式：冲刺、Sprint规划、Sprint评审、每日站会、回顾
• 五大价值观：勇气、开放、专注、承诺、尊重

4.4 精益产品开发屋

5 DevSecOps

5.1 DevSecOps的CAMS原则

1. Culture 文化：

• 在观念上，DevSecOps强调人人对安全负责，发现并解决安全问题不再是安全人员独有的任务。
• 开发人员需要对自己所生产的代码的安全性负责，参与交付的人员也需要对最终交付的软件产品的安全性负责。
• 所有参与软件生命周期的工作人员都需要提升自身的安全意识和技能，在完成各自阶段任务时就保障足够的安全性要求。
• DevSecOps需要Dev, Sec, Ops三个团队之间的理解与配合。安全团队也不再像以往一样位于整个工作流的末端，而是尽可能将安全左移。

2. Automation 自动化：

• DevOps自动化几乎遍布整个DevOps生命周期，组织通过使用自动化工具或自动化手段实现持续部署、持续集成、自动监控、自动修复等活动， 以实现快速发布、快速迭代等目的。
• DevSecOps在此基础上，也更加强调安全保障活动的高度自动化，这种自动化是为了能够在不牺牲软件安全性的条件下跟上DevOps的速度和规模，避免由于人为干预而可能导致的安全问题。
• 通过整合自动化的安全检测工具和监控框架等来形成完整的DevSecOps安全工具链和反馈环，达到全方位保障软件产品的安全性要求。

3. Measurement 度量：

• 在DevOps中，度量是提高流程可见性的一个重要手段，通过相关的度量指标（如关键性能指标，新版本对系统稳定性影响指标等），任何人都能够知道在什么时候发生了什么事情，进而了解到当前系统的状态，并及时思考如何进行改进等。
• 在DevSecOps环境下，我们仍然需要始终掌握项目进展、系统状态等信息，同时，DevSecOps也更加推崇使用度量标准来评估、控制和改善整个软件开发过程。如组织可以根据对漏洞的定位和修复时间信息来衡量DevSecOps所产生的效果并考验组织的应变能力。

4. Sharing 分享：

• 团队之间分享想法和问题是合作的前提，在DevOps中，开发人员和运维人员通过共享知识、工具和技术来管理软件的整个生命周期。
• 同样的，在DevSecOps中，开发团队、运维团队和安全团队仍需要通过共享工具和技能的方式来协同保障软件的安全开发和运维。
• 安全团队需要为开发团队和运维团队找到合适的、统一的安全工具来满足日常的安全开发活动，三个团队通过共享的安全工具来将安全检查左移到开发阶段，让安全问题在早期就能够得以发现并解决。

5.2 DevSecOps典型实践

5.2.1 阶段实践

5.2.2 通用实践

事件管理：对安全事件采取标准化的方式进行响应

5.3 DevSecOps典型工具

• 创建阶段 - 开源组件安全扫描：FOSSID、BlackDuck
• 验证阶段 - 静态应用程序安全检测：SonarQube、Checkmarx
• 验证阶段 - 动态应用程序安全检测：Nessus
• 验证阶段 - 交互式应用程序安全检测：Seeker

6 微服务架构

微服务架构是把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注、内聚的功能职责组成。
微服务架构是一种将单体应用拆分为细粒度的服务，并使其运行在独立进程中，服务之间采用轻量级通信机制（如HTTP RESTful API）进行交互的架构风格。这些服务围绕系统的业务能力构建，且可以通过全自动的部署机制进行独立部署。服务可以进行分布式管理，从而支持不同的编程语言进行开发和不同的数据存储技术进行存储。

6.1 微服务拆分原则、策略和方法

6.1.1 拆分原则

单一职责原则：

• 高内聚：每个微服务处理的业务逻辑单一，与不相关的业务逻辑隔离
• 低耦合：不同微服务之间取消不必要的依赖，降低服务间协作成本

服务依赖原则：

• 区分核心/非核心服务（依据业务重要性划分）
• 实际落地时，应尽量避免核心服务依赖于非核心服务，避免因非核心服务降级或中断而影响到核心服务

服务自治原则：

• 每个核心服务都拥有独立的全功能团队负责整个生命周期（需求、设计、 实现、验证、发布、运维）

6.1.2 拆分策略

6.2 领域驱动设计（DDD）

层次、战略设计、战术设计

• 战略设计：限界上下文、通用语言，子域
• 战术设计：聚合、实体、值对象、资源库、领域服务、领域事件、模块

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e9%a2%86%e5%9f%9f%e9%a9%b1%e5%8a%a8%e8%ae%be%e8%ae%a1%e5%ae%9e%e8%b7%b5%ef%bc%88%e5%ae%8c%ef%bc%89/101%20%e5%ae%9e%e8%b7%b5%20%20%e5%91%98%e5%b7%a5%e4%b8%8a%e4%b8%8b%e6%96%87%e7%9a%84%e9%a2%86%e5%9f%9f%e5%bb%ba%e6%a8%a1.md
康威定律：指出组织设计系统来反映他们自己的沟通结构（组织形式等同系统设计）