Devops review

DevOps渊源

什么是DevOps，为什么需要？

DevOps（开发运维一体化）是Patrick Debois在2009年提出的一种方法论——能否像敏捷开发一样来做运维？DevOps（Development Operations）加强了开发，测试和运维之间的沟通协作，打破了传统团队之间的壁垒，通过实现自动化和架构变更，从而提高研发效率，节省成本，最终更快捷地实现交付产品，并且提高产品质量。DevOps是IT价值流中应用精益理论的结果。

为什么需要？

软件系统互联网化和服务化的高度发展和走向成熟为DevOps的出现和普及提供了基础。这个阶段的软件具有持续的特征，要求软件系统应该始终处于一种可用的状态，即系统功能的添加或者更新不影响系统使用；同时，软件系统的复杂性日益提升、质量和安全要求以及更新频率越来越高。持续性正在成为当代软件企业关键性的能力和竞争优势......

演化路径

三步工作法

第一工作法

概念：

• 充分理解工作流（开发-运维-客户）
• 流量最大化（小批量、缩小任务间隔、缺陷控制）
• 不断为了整体目标的实现而优化工作流

部分关键实践和方法

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

第二工作法

概念：

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

部分关键实践和方法：

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

第三工作法

概念：

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

部分关键实践和方法

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

关键术语

CI/CD

持续集成（Continious Integration，CI）

持续集成是一种开发实践，要求开发人员每天多次将代码集成到共享代码库中。每次提交后，会通过自动化构建进行验证，从而使团队能够及早发现问题。

持续交付（Continuous Delivery）

持续交付是一组流程和实践，彻底消除了软件开发过程中的浪费，实现了更快速地交付高质量功能，并在业务和用户之间建立了快速有效的反馈循环。

持续部署（Continuous Deployment，CD）

持续部署（Continuous Deployment, CD）意味着您实际上立即部署和发布更改，使用户能够立即使用新的功能。

devops使用的CD是持续部署。

XaaS——一切皆服务

1. SaaS：Software as a service。软件即服务是一种软件许可和交付模型，其中软件以订阅方式许可，并在中心进行托管。
2. IaaS：Infrastructure as a service。基础设施即服务（IaaS）是一种云计算模型，其中虚拟化机器以“按需付费”的方式提供，并由云托管。用户对机器拥有完全的控制权，但需要自行安装和配置所需的中间件和应用程序。
3. PaaS：Platform as a service。平台即服务（PaaS）供应商为应用程序开发人员提供开发环境。供应商通常开发工具包和开发标准，并提供分发和支付渠道。

Docker

Docker是一个开源项目，它可以自动化部署Linux应用程序到软件容器中。Docker容器将一个软件打包到一个完整的文件系统中，其中包含运行该软件所需的所有内容：代码、运行时、系统工具、系统库 - 任何可以在服务器上安装的东西。这保证了它无论在何种环境下运行，都会始终保持一致。

A/B Testing

通过将新功能或不同变体的功能提供给不同的用户群体，并通过比较指标和用户行为来进行评估的技术。

云计算

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

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

• 服务模式：SaaS、PaaS、IaaS等
• 部署模式：私有云、社区（行业）云、公有云、混合云等

why？

1. 弹性和灵活性：云计算提供了按需、即时的资源供应，可以根据需求快速进行扩展或缩减计算资源。无需提前采购硬件设备或规划容量，从而实现更高的弹性和灵活性。
2. 降低成本：传统计算模式下，构建和维护自己的计算基础设施需要大量的资金投入。通过使用云计算服务，可以将这些成本转换为按使用量或订阅方式的付费模式，避免了高昂的初始投资和持续维护成本。
3. 高可用性和可靠性：云计算提供了分布式架构和冗余机制，在服务器故障或网络中断时能够实现高可用性和可靠性。用户可以享受到持续的服务和数据的备份，提高业务的连续性和可靠性。
4. 方便的远程访问：云计算使用户能够通过互联网从任何地点、任何设备访问其应用程序和数据。无论是在家办公、旅途中还是在不同的办公地点工作，用户都可以便捷地获取和管理数据。
5. 简化管理和维护：云计算提供了自动化的管理工具和服务，简化了资源的管理和维护过程。用户可以将更多的精力集中在核心业务上，而不是花费时间和精力来管理底层的基础设施。

什么是云原生？

基于微服务的软件架构思想以及基于DevOps的软件开发实践的一组方法论，其实现了以分布式和容器技术为核心在异构云平台环境下利用云计算交付模型优势来快速构建、部署和进行企业应用。

XaaS——"X" as a Service

在线编辑文档是SaaS。

边缘计算

边缘计算面临的挑战：

1. 可编程性：异构平台和系统
2. 命名规则：数量众多的边缘设备
3. 数据抽象：数据多样性（频率、格式等）
4. 服务管理：D（差异性）E（可扩展性）I（隔离性）R（可靠性）模型
5. 数据隐私保护及安全：隐私、数据权属等
6. 理论基础：多学科协同
7. 商业模式：协调利益相关者

雾计算

这张图是重点。

IT服务标准(可能考名词解释吧)

CMMI-SVC

CMMI-SVC即CMMI for Services服务模型，是CMMI三大套装产品中的一个，从服务的角度描述过程描述流程，为服务型的企业或组织提供建立、管理和交付服务的知道，可用来作为评估服务相关流程成熟度的标准。分为初始、可重复的、已定义级、量化管理级、优化管理级五个等级，24个流程领域。

ITIL（国际标准）

ITIL，全称Information Technology Infrastructure Library（信息技术基础架构库）

ITIL最佳实践主要围绕5个部分：

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

ITSS（中国标准）

信息技术服务标准(Information Technology Service Standards，简称ITSS)是一套成体系和综合配套的信息技术服务标准库

•基础标准旨在阐述信息技术服务的业务分类和服务原理、服务质量评价方法、服务人员能力要求等。

•服务管控标准是指通过对信息技术服务的治理、管理和监理活动，以确保信息技术服务的经济有效。

•业务标准按业务类型分为面向IT 的服务标准（咨询设计标准、集成实施标准和运行维护标准）和IT 驱动的服务标准（服务运营标准）。

•服务外包标准是对信息技术服务采用外包方式时的通用要求及规范。

•安全标准重点规定事前预防、事中控制、事后审计服务安全以及整个过程的持续改进，并提出组织的服务安全治理规范，以确保服务安全可控。

•行业应用标准是对各行业进行定制化应用落地的实施指南。

传统运维转型之路

运维主要指软件系统测试交付后的发布和管理工作，其核心目标是将交付的业务软件和硬件基础设施高效合理的整合，转换为可持续提供高质量服务的产品，同时最大限度降低服务运行的成本，保障服务运行的安全。

互联网式运维：互联网业务系统具有快速迭代的特点，这就要求互联网系统的运维具有快速发布的能力，甚至能针对特定用户进行灰度发布的能力。此外，还应具备更全面的安全知识来应对未知的安全威胁。

云计算下的运维：可分为云计算系统本身的运维和基于云计算的应用系统运维。需要应对如何在云平台上实现应用的快速部署、快速更新、实时监控，要求运维人员能够自动化部署应用、动态扩容或者缩小系统部署、适应不同平台的差异。

大规模下的运维：运维工作必须向标准化、自动化、智能化转变。

“提前”运维：

软件架构的演进

软件架构

4 + 1架构模型（重要，尤其是干嘛的）

逻辑视图——面向对象的分解

• 体现功能需求/服务
• 一般用类图或ER图来描述

进程视图

开发视图——子系统分解

物理（部署）视图——建立软件和硬件之间的映射关系

场景视图——综合所有的视图

1.Joe的电话控制器 (controller)检测到Joe拿起电话听筒，随即它发了条消息来唤醒相对应的终端(terminal)

2.终端分配了一些资源，同时告诉控制器发出拨号音

3.控制器开始接收到Joe拨的数字，同时把他们传给终端

4.终端调用编号方案服务来分析数字序列

5.当一串有效的数字被输入以后，终端打开一个会话

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

这边重点关注微服务和SOA，不过感觉rgp这边写的很乱，可以看后面lss的ppt，比较详细。

单体架构和分层模型

软件架构一直是跟随着需求而做出的高层设计决策，由于传统软件一般用户量不大、数据量不大、业务相对固定、变化不大、系统部署相对简单，容易维护等，所以，并不需要一个非常复杂的系统。最常见的方法是采用单体架构，一般所有的层都运行在一个进程里 。

简单的资源分离

一体式应用的高性能分布式系统架构

一般传统软件的架构到这步，已经能很好的支持业务需求。而且，一般传统软件部署环境相对简单，系统维护员会比较关注数据备份，准备好主备机切换等维护操作，即可顺利得进行系统维护。

单体架构在互联网时代面临的挑战

单体->分布式异步架构

大型互联网软件架构——事件驱动架构

是一个通用mediator模型。一个事件通过消息队列发给Event Mediator的时候，Event Mediator会根据预配置的步骤分成多个子事件，通过Event Channel分发给具体的Event Processor。这里Event Channel可以采用消息队列或者消息主题的方式。大多Mediator模式会采用的是消息主题的方式，从而Event Mediator产生的子事件可以同时被多个不同的Event Processor接收处理。

下图是搬家之后的保险处理步骤。

下图是一个通用的Broker模型，它没有中央控制的event mediator。每个消息处理器接收到一个事件，处理，然后生产一个新的事件给下游的消息处理器。

这是一个Mediator模式的示例，假设你在A地的保险公司有一份保险合约，你需要搬家到B地，那么保险合约需要重新调整保费的一系列步骤。

大型互联网软件架构——微服务架构（重要）

• 它把单体应用垂直拆分，分成一个小的垂直模块，每一个模块都是一个完整的，自包含的服务。
• 在这个垂直服务内，有可能还是采用单体的架构方式。
• 每个服务对外提供API，并且可以独立被调用，可以独立烟花。
• 在微服务架构中，每个服务只包含少量的模块，被独立部署在各自的容器中，提供REST接口，并有一层独立的API gateway (API网关)把细粒度的微服务进行组合，协议转换等，封装成新的粗粒度接口提供给客户端使用。

大型互联网软件架构小结

事件驱动架构和微服务架构都能很好得完成应用的垂直划分。两种架构方式并不是完全互斥的，在一个真实的应用场景中，往往会共存，尤其是一个大型应用里面有很多子系统共存的时候。这种情况下，一般用微服务架构为应用提供服务治理的方案，事件驱动架构来异步得整合多个子系统。

• A和B这两个子系统与其他子系统（日志系统，监控与报警系统）的交互通过消息队列进行，采用事件驱动的方式，驱动日志系统和监控报警系统

• A和B应用服务器只处理最简单的一些业务逻辑或界面相关部分，把真正的业务逻辑采用微服务的方式，独立划分成多个服务专门部署在分布式服务N服务器里

• 随着流量的剧增，应用数量的提高，数据库也会爆炸，我们对数据库也进行垂直划分和水平划分，把数据库变成一个分布式数据库集群

• 从运维的角度来看，系统必须有即时的监控和报警机制。

• 另外，现在互联网企业越来越重视日志系统，最直接的原因是分布式系统难以进行调试，所以通过日志系统来记录日志以便还原现场；其次，日志记录了海量的用户行为，之后可以用来分析用户行为，挖掘出有价值的信息。

• 当然大部分流量大的网站还会增加CDN (Content Delivery Network，即内容分发网络)，反向代理（一种代理服务器，用来接受连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给请求连接的客户端），采用NoSQL数据库（泛指非关系型的数据库）或者使用Spark（为大规模数据处理而设计的快速通用的计算引擎）等平台做实时推荐引擎

单体架构

分层架构

SOA架构（重要）

• 面向服务的体系结构是构造分布式计算的应用程序的方法。

• 它将应用程序功能作为服务发送给最终用户或者其他服务。

• 它采用开放标准、与软件资源进行交互并采用表示的标准方式。

• SOA架构中一般都会涉及到企业消息总线(Enterprise Service Bus, ESB)和服务编排(Service, Orchestration)。

• 总之SOA架构是在企业需要把很多系统集成到一起工作的工作中逐步演化而来的，每个系统本身是高内聚，对外以暴露接口的方式提供服务，而SOA架构则会提供ESB以及服务编排，将不同协议的接口编排起来，最后满足特定的业务需求。

软件过程和方法

软件过程

理论基石——软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。

软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合，这组实践之间往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。

PSP

个体软件过程：Personal Software Process

是一种个人级用于控制、管理和改进软件工程师个人工作方式的持续改进过程。

作用

•个人级管理实践和过程估算和计划

•承诺和拒绝承诺

•理解和改进

•工业水准的过程和规范

•客观决策的数据

典型PSP过程

PSP基本原理

•软件系统的整体质量由该系统中质量最差的某些组件所决定；

•软件组件的质量取决于开发这些组件的软件工程师，更加确切的说，是由这些工程师所使用的开发过程所决定；

•作为合格的软件工程师，应当自己度量、跟踪自己的工作，应当自己管理软件组件的质量；

•作为合格的软件工程师，应当从自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的开发实践中，也就是说，应当建立持续地自我改进机制。

上述基本原理除了继续肯定“过程质量决定最终产品质量”这一软件过程改进的基石之外，更加突出了个体软件工程师在管理和改进自身过程中的能动性。这也就形成了PSP的理论基础。

TSP

团队软件过程：Team Software Process

TSP注重团队的高效工作和产品交付能力，结合PSP的工程技能，使软件工程师将个体过程结合进小组软件过程，并通过指导管理层如何支持和授权项目小组，坚持团队的高质量的工作，并且依据数据进行项目管理，以达到生产高质量产品的目的。

挣值管理方法

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

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

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

• 简单实现：这种方式仅仅关注进度信息。在实现时，首先需要建立WBS，定义工作范围；其次为WBS中每一项工作定义一个价值（PV）；最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。常用规则分别为0-100规则和50-50规则，前者只有当某项任务完成时，该任务的PV值将转化成EV值；后者只需要开始某项任务，即可以赋原PV值的50%作为EV值，完成时，再加上另外的50%。而实际完成的工作所需成本AC不对EV值产生任何影响。

• 中级实现：在简单实现的基础上，加入日程偏差的计算。典型计算方式有：

  • 日程偏差SV = EV – PV;

  • 日程偏差指数SPI = EV/PV；

• 高级实现：在中级实现的基础上，还需要考察项目的实际成本。

"Hours to date" 是一个用来描述在某个日期之前总共工作的小时数的术语。这通常用于追踪和记录个人或团队在特定项目、任务或工作岗位上的工作时间。

EVM的局限性

• EVM一般不能应用软件项目的质量管理
• EVM需要定量化的管理机制，这就使其在一些探索型项目以及常用的敏捷开发方法中的应用受到限制。
• EVM完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算。

敏捷方法

XP

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

极限编程开发过程框架

SCRUM（在英语的意思是橄榄球里的争球）

• Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。
• 虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队。

摩尔定律和反摩尔定律

摩尔定律：集成电路上的晶体管数量大约每18个月翻倍一次。（ppt）每18个月后，同样的价格可以买到两倍的产品性能。

反摩尔定律：如果我们18个月后卖出和今天相同的产品，就只能得到和今天相比一半的价值

精益产品开发屋

这张图很重要。

DevSecOps

起源

DevSecOps原则

DevSecOps原则是对DevSecOps核心理念的总结，对DevSecOps实践有着重要的指导作用。

• 偏理念的CAMS（Culture，Automation，Measurement，Share）原则
• 偏实践的NCSC（National Cyber Security Center，英国国家网络安全中心）安全开发和部署八原则（不考）

CAMS原则（重点关注）

CAMS原则是由John和Damon Edwards两位先驱针对DevOps率 先提出，并随着DevOps的不断发展而日趋成熟。CAMS原则从四个方面高度概括了DevOps价值观，为正确实施DevOps实践提供 了概念上的指导。目前，在DevSecOps背景下，CAMS原则也相 应地需要在安全领域增添新的内容。

DevSecOps典型实践和典型工具（估计会考）

典型实践（至少要知道一些，说不全也说几个）：阶段实践和通用实践。

典型工具（静态扫描、动态扫描工具至少知道几个）：指的是阶段里的一些工具，我加粗了6个。

阶段实践

计划阶段

•安全知识管理：安全知识管理要求组织在管理显性知识的时候加入信息安全的知识体系。

•安全需求工程：DevOps对安全需求工程提出了更多响应速度上的要求。

•固有风险评估：风险评估的目的在于识别威胁(Threat)、判断威胁转变成现实可能带来的影响以及判断这种转变的可能性。

•威胁建模：威胁建模是一种用来识别、量化并正确应对系统所面临的威胁的结构化方法。

创建阶段

•开发环境扫描：为了始终保障开发环境本身的安全可靠，我们需要对开 发环境进行一定的安全扫描工作 。

•开源组件安全扫描：我们需要通过合适的安全扫描工具，如FOSSID、

BlackDuck等，来对项目中使用的开源组件进行安全扫描 。

•容器安全扫描：容器安全扫描保障的是镜像源和镜像文件本身的安全。

•集成安全插件：为及时发现自身开发的代码中的安全问题，我们鼓励开 发人员在集成开发环境中安装统一的安全插件。

•安全框架：使用全面的安全框架能够很好地处理常见的安全问题，能够极大地提高开发人员的开发效率和编码质量。

•代码审查：一般是通过人工审阅的方式来查看提交的代码是否合乎公司的代码规范，是否功能齐全，是否使用了危险函数，是否考虑到安全编码等相关问题。

•编码规范：趋于一致的代码风格反而会有助于公司进行代码审查，来降低隐藏

在高复杂度背后的漏洞风险，也能够提高代码的可读性和健壮性。

•可重复性构建：相同的源代码在经过两次编译后，应当能够始终输出比特位相同的二进制，这对于我们确保源代码到二进制的过程中没有被中途篡改，具有 重要意义。

验证阶段

•SAST：Static Application Security Testing，即静态应用程序安全检测，是进 一步加强代码安全的手段之一。

•DAST：Dynamic Application Security Testing，即动态应用程序安全检测。

•IAST：Interactive Application Security Testing，即交互式应用程序安全检 测，IAST分为主动IAST和被动IAST。

•TDS：Test Driven Security，即测试驱动安全，是由Mozilla提出的。TDS主 张将安全测试集成到交付管道中，是验证系统、网络和服务是否符合安全策略 的过程。

预生产阶段

•渗透测试：渗透测试是从攻击者的视角出发，通过模拟恶意黑客的进攻 手段对系统进行攻击，主动去发现系统中存在的安全隐患和弱点的一种 测试方法 。

•模糊测试：模糊测试是一种向系统提供非预期的随机输入，并监视可能 发生的异常结果的自动化技术。

•混沌工程：混沌工程是一门在生产中对软件系统进行试验的学科，其目 的是建立对系统抵抗动荡和意外情况能力的信心。该方法允许在生产中 随机关闭服务、模拟网络故障等多种手段来测试系统的弹性恢复能力， 以保证系统在部分节点故障的情况下，仍然能够提供高质量的服务。

发布阶段

•强化云部署：DevOps与云技术结合得愈加紧密，在多云环境中进行安全 部署仍然需要考虑很多方面的问题，比如，如何在确保安全的情况下保 障计算资源的高可用、如何实现相对均衡的负载、如何对存储资源进行 合理分配等等。

•添加数字签名：在发布软件包之前，都应该为其添加数字签名，以增加 该软件的可信度和公信力。

•容器加固：在确保容器镜像来源和镜像内容本身的安全可靠之后，容器安全还需要其他的加固保护措施，其目的主要是为了减小潜在的攻击面。

预防阶段

•数字签名检查：在使用相关应用或者文件前，我们应当检查它们是否含有数字签名。

•证书完整性验证：数字证书由受信任的第三方颁发，用于验证证书持有者的身份。

•敏感信息保护：大多数应用系统在正常工作时需要访问敏感信息，而这些敏感信息如果不加以管理和保护，可以在互联网上肆意传播，这无疑会大大增加系统的安全漏洞风险。

•安全漏洞修复计划：组织内应该具备这样一个流程，专门用于支持安全漏洞的确认以及采取相应补救措施，从而达到持续保护整个应用系统的安全性能的目的。

检测阶段

•欺诈检测：欺诈问题涉及多个行业，据不完全统计，每年因被欺诈而损失数亿美元。

•合规监控：合规监控是评估我们对公司政策和程序的遵守程度，这些政策和程序

控制着对业务构成合规风险的活动，并帮助业务在持续的基础上有效地管理风险。

•入侵检测：入侵检测系统是一种检测网络流量以发现可疑活动，并在发现此类活动时发出警报的检测系统。

•红蓝对抗：红蓝对抗是在了解企业实际安全状况的基础上，针对企业重要的核心业务模拟真实的网络攻防场景，从而揭示系统中实际存在的脆弱环节，主动提升企业自身的安全能力。

响应阶段

•问题跟踪：问题跟踪系统是一种软件应用程序，它允许企业记录和跟踪计算机系 统用户识别的每个问题或“问题”的进展，直到问题得到解决 。

•应用屏蔽：应用屏蔽技术是一项修改应用程序的二进制代码的技术，用以加强应 用程序抵御入侵、篡改和逆向工程的能力。使用应用屏蔽技术可以很好地保护应 用软件的资产安全，防止出现盗版、数字信息盗窃等情况。

预测阶段

•舆情监控：在实际应用正式发布前，由于时间要求、测试资源限制等因素，我们 很难测试出全部的安全威胁。很多被忽视的安全漏洞，往往是在生产环境下由用 户发现的，因此企业应当密切关注各大网站、各大论坛讨论的安全问题和安全动 态，在可能的安全漏洞被利用之前，尽快完成相应的检查和修复工作。

•漏洞智能分析预测：对特定的软件系统使用漏洞智能分析技术，我们一般需要提 取出漏洞的基本特征，并使用机器学习方法进行建模、训练，再对系统中潜在漏 洞进行预测。

调整阶段

•控制技术债务：技术债务是指在进行软件开发时，开发团队从短期效应的角度选 择了易于实现的解决方案而导致的额外的返工成本。技术债务的不断积累，会严 重阻碍系统长期的可扩展性和安全性，并使得公司需要花费更多的时间来解决这 些债务。

•调整安全机制：系统的整体运行应当具备动态调整功能，管理人员可以根据实际 业务目标或者资源限制等，根据既定的优先级，对整个系统的安全机制做出动态 的调整。

通用实践

协作实践

•开发/运维人员安全培训：DevSecOps要求团队中的每一个成员都需要具备一定的安全意识。

•任命DevSecOps团队负责人：任命一些DevSecOps的负责人来推动项目的进行。

•安全责任共享：安全是整个IT团队每个人的责任。

•常用工具共享：在大多数情况下，开发、运维和安全人员很少使用相同的工具， 这使得他们相互之间难以高效地进行协作。

•建立知识共享体系：知识共享是消除不同部门之间的分歧的有效手段之一。

过程实践

•创建安全反馈循环：正如CI/CD可以通过持续测试和建立反馈循环更早更快地 发现并处理软件产品中的Bug以提高软件质量，安全反馈循环的建立也可以帮 助软件开发团队高效地处理安全问题。

•事件管理：DevOps中提出了智能运维的理念，使用脚本化、自动化的方式来 处理一些重复出现的常见运维问题，DevSecOps对这一理念在安全领域进行 了拓展，即对于安全事件采用标准化的方式进行响应。

•变更管理：变更管理包括了所有与应用程序和平台本身的版本控制相关的标准 和规范，对代码的任何更改在部署到生产环境之前都需要通过变更管理进行审 查和批准。

微服务架构设计

单体架构

单体架构应用的全部功能被集成在一起作为一个单一的单元。

• Java Web应用程序（WAR）文件
• GoLang语言，交付形态为单一可执行文件
• Ruby或Node.js，交付形态为目录和子目录下各种源码
• 初始化、配置、监控、管理等功能

好处：

• 易于开发：一个应用（不复杂）
• 易于修改：代码和数据库模式
• 易于测试：端到端测试、UI测试
• 易于部署：WAR文件复制
• 易于伸缩：多个实例负载均衡

问题：

• 过度复杂性：
  • 理解、数以千计JAR文件和百万行代码
  • 修复bug和实现新功能易出错、脏泥球
• 开发速度缓慢：
  • IDE编辑-构建-启动运行
• 部署周期长且易出错：
  • 微小变更同一代码库提交、构建
  • 变更测试（持续集成测试套件、手动）
• 难以扩展
  • 资源冲突
• 可靠性差
  • 无法全面测试
  • 缺少故障隔离
• 过期技术栈

微服务架构

概括性描述：微服务架构是把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注、内聚的功能职责组成。

微服务 vs SOA（重要）

微服务拆分设计（重要）

领域驱动设计（Domain-Driven Design，DDD）

记住战略设计包括问题域和架构方面两部分。

战术设计。

下面这张图比较重要。

实体与值对象

实体不是通过它们的属性而是连续性和标识定义的。（也就是id）

说白了也就是是不是持久化数据的问题。也就是entity和vo嘛。

聚合是领域模型的概念边界

例子