2020-DevOps导论-Exam-2021年考试复习

Exam1-2021年考试复习

1. 考试题：2019年

1. 摩尔定律和反摩尔定律分别是什么？对软件的发展有什么意义？
2. JIT及时生产，价值拉动和价值流的关系
3. 软件架构的演化过程？微服务对devops的意义？单体架构 -> 分层架构 -> 微服务架构
4. 构建一个基本的devops pipeline需要哪些工具和软件？

2. 考试题：2020年

1. 名词解释
   1. 云原生：基于微服务的软件架构思想以及基于DevOps的软件开发实践的一组方法论
   2. CI/CD
      1. CI 持续集成，一种实践，开发人员每天多次将代码提交到共享代码库，每次签入都会自动构建以验证，帮助团队尽早发现问题
      2. CD 持续交付，开发和实践，可以从根本上消除软件生产过程中的浪费，能够更快地交付高质量的功能，并在您的企业和用户之间建立快速有效的反馈循环
      3. CD 持续部署，您实际上会立即部署并向用户公开更改。
   3. IaaS：基础设施即服务，云托管的虚拟机通常按"现收现付"收费。用户可以完全控制机器，但需要自己安装和配置任何所需的中间件和应用程序。
2. 敏捷开发宣言，我们如何正确理解这个宣言
   1. 个体和互动 高于 流程和工具
   2. 可以运行的软件 高于 详尽的文档
   3. 客户合作 高于 合同谈判
   4. 响应变化 高于 遵循计划
3. 简述看板核心实践
   1. 可视化工作流程，Kanban方法(渐进增量式的过程改进方法学)，使用物理白板：提高信息辐射的作用，容易发现团队工作的状态和问题、降低沟通交流成本
      1. 工作项(即时贴)：描述、电子系统的标识、期限、处理者、类型
      2. 列：映射团队工作流，包括工作的所有阶段。
   2. 限制在制品：限制在制品的数量
      1. 原理是硬币游戏，折衷个人效率和工作效率
      2. 意义：减少在制品使其快速流过整个工作流，使前置时间缩短(前置时间：处理一个工作项从开始到结束所经过的时间)
4. 下列工具在DevOps Pipeline的作用
   1. Docker：容器将一个软件封装在一个完整的文件系统中，该文件系统包含它运行所需的一切：代码、运行时、系统工具、系统库——任何你可以安装在服务器上的东西。这保证了它总是以相同的方式运行，而不管它在什么环境中运行
   2. Git：分布式版本控制系统，强调速度、数据完整性和对分布式非线性工作流的支持
   3. Jenkins：持续集成工具，配置流水线等
   4. SonarQube：静态代码检查工具，用来静态的检查软件
5. 架构演化历史，并说明演化的驱动力
   1. 单体架构
   2. 分层架构
   3. SOA架构
   4. 微服务架构
   5. Service Mesh
6. Docker和传统虚拟机异同
   1. 隔离：借助于linux的namespace机制
   2. 资源限制：可以基于linux的cgroup计算对容器所能使用的资源做限制，主要指cpu、内存资源
   3. 进程：linux进程
   4. 依赖环境：进程运行所依赖的库、以及其他的资源
7. 介绍DevSecOps中的CAMS原则
   1. 文化（Culture）
   2. 自动化（Automation）
   3. 度量（Measurement or Metrics）
   4. 分享（Sharing）
   5. 随后Jez Humble先生将“L”精益 (Lean) 原则也加入其中，最终变成了CALMS。

3. Devops导论

3.1. 独角兽公司

1. 独角兽公司：一般指成立不超过10年；估值要超过10亿美元，少部分估值超过100亿美元的企业。

3.1.1. 三步工作法

1. 概念
   1. 充分理解工作流是关于从开发到IT运维再到客户的整个自左向右的工作流。
   2. 流量最大化(小批量、缩小任务间隔、缺陷控制)，不让缺陷流向下游工作重心。
   3. 不断为了整体目标(相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标)的实现而优化工作流
2. 部分关键实践和方法
   1. 持续构建、集成和部署
   2. 按需创建环境
   3. 限制半成品(WIP)
   4. 构建支持顺利变更的安全系统
   5. 看板(任务可视化)

3.1.2. 第二工作法

1. 概念
   1. 价值流(开发-运维-客户)的快速持续反馈流，放大其效益
   2. 避免问题再次发生(或者快速发现和修复)
   3. 从源头上保证质量
2. 部分关键实践和方法
   1. 适时停止生产线：部署流程中的构建和测试失败
   2. 持续改进
   3. 构建自动化测试套件，确保代码随时可部署
   4. Dev和Ops共享目标和pain
   5. 远程监测手段(自动化)

3.1.3. 第三工作法

1. 概念：创建培育良好的文化(不断尝试、重复和练习)
   1. 不断尝试，这需要承担分享并从成功和失败中吸取经验教训
   2. 理解重复和联系是熟练掌握的前提
2. 部分关键实践和方法
   1. 营造用于创新、敢于冒险以及高度信任的企业文化
   2. 确保至少20%资源投入在非功能需求上
   3. 不断鼓励和强化改进。

3.2. 四种典型IT工作类型

1. 业务项目：大部分支持企业业务计划的开发项目，由公司项目管理办公室跟踪和管理
2. IT内部项目：由上述业务项目衍生出来的基础架构或IT运维项目和内部的一些改进项目，不是集中跟踪和管理
3. 变更：由上述两种项目引起，往往通过问题跟踪系统来跟踪和管理
4. 计划外工作：操作事故和问题，一旦发生上述问题的解决会受到影响

3.3. 精益生产与Devops

1. 精益理论：降低批量规模、减少半成品，缩短并增强反馈回路，DevOps是IT价值流中应用精益理论的结果。

3.4. 什么是DevOps

1. Devops：开发运维一体化，是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。
   1. 方法论基础是敏捷软件开发，精益思想以及Kanban方法
   2. 以领域驱动设计为指导的微服务架构方式
   3. 大量虚拟化技术的使用(开发、测试环境)
   4. 一切皆服务XaaS的理念指导
   5. 构建了强大的工具链，支持水平自动化
2. Devops与敏捷的关系
   1. DevOps思想部分起源于一些运维工程师借鉴软件敏捷开发思想
   2. DevOps的早期活跃分子来自敏捷社区
   3. 公认的适用于DevOps的软件过程方法是敏捷软件开发，尤其是Kanban
3. Devops特点
   1. 让开发和运维共同为业务的成功负责
   2. 开发和运维技能一部分融合
4. Devops化的三个阶段
   1. System Thinking 充分理解工作流，完成整体产品
   2. Amplify Feedback Loop 快速持续反馈
   3. Culture Of Continual Experiment and Learning 培育不断尝试、重复和练习的文化
   4. DevOps与敏捷开发

	DevOps	敏捷
价值观	工作软件 -> 服务或交付的软件	敏捷宣言
原则	扩大敏捷原则以包括系统和操作，例如IaaS	战略方法(拥抱变更等)
方法	与敏捷相同，除了几种不同方法，例如Viaible Ops	具体流程实现(XP、Scrum)
实践	CD、工具链、虚拟化和云计算、指标和监控方案	高度具体的战术技术(站会、扑克等)
工具	工具爆炸(Jenkins等)	特定的技术实现(JIRA)

3.5. DevOps关键术语和概念

名词	解释
持续集成(Continuous Integration, CI)	开发实践，需要开发人员每天多次将代码集成到共享存储库中。然后每次签入都通过自动构建进行验证，从而使团队能够及早发现问题
持续交付(Continuous Delivery, CD)	流程和实践，可以从根本上消除软件生产过程中的浪费，能够更快地交付高质量的功能，并在您的企业和用户之间建立快速有效的反馈循环
持续部署(Continuous Deployment, CD)	您实际上会立即部署并向用户公开更改。
软件即服务(SaaS)	一种软件许可和交付模型，其中软件在订阅的基础上获得许可并集中托管。
基础设施即服务(IaaS)	云托管的虚拟机通常按"现收现付"收费。用户可以完全控制机器，但需要自己安装和配置任何所需的中间件和应用程序。
平台即服务 (PaaS)	PaaS供应商为应用程序开发人员提供开发环境。提供商通常会开发工具包和标准，以及用于分销和支付的渠道
指标	部署频率、变更进入生成时间、平均恢复时间(MTTR)、改变失败率
流水线	为了让应用从概念到生产，工程师们都按照顺序和最终例行的步骤工作
流水线编排	使构成持续交付管道的各种自动化任务能够在正确的时间被调用的工具或产品。它们通常还会记录每个任务的状态和输出，并可视化通过管道的特征流
容器	容器为虚拟机提供了一种轻量级的替代方案，它们使开发人员能够使用相同的DEV环境和堆栈。他们还通过鼓励使用无状态设计来促进DevOps
Docker	Docker容器将一个软件封装在一个完整的文件系统中，该文件系统包含它运行所需的一切：代码、运行时、系统工具、系统库——任何你可以安装在服务器上的东西。这保证了它总是以相同的方式运行，而不管它在什么环境中运行
Git	Git是一个分布式版本控制系统，强调速度、数据完整性和对分布式非线性工作流的支持
GitHub	GitHub是一种基于Web的Git存储库托管服务，它提供Git的所有分布式修订控制和源代码管理(SCM)功能以及添加自己的功能。与严格意义上的命令行工具Git不同，GitHub提供基于Web的图形界面和桌面以及移动集成
A/B测试	一种技术，其中新功能或功能的不同变体可用于不同的用户集，并通过比较指标和用户行为进行评估

3.6. DevOps工具链

1. 项目管理：Jira
2. 源代码管理: Github, Gitlab, Bitbucket
3. 代码扫描: Sonarqube, Findbug, Cppcheck
4. 编译构建: Maven, Gradle, MSBuild
5. 持续集成: Jenkins, TeamCity
6. 单元测试: JUnit, NUnit
7. 制品管理: Nexus, Artifactory
8. 自动化测试: Selenium, Jmeter
9. 自动化发布: Ansible, Puppet, Chef
10. 监控预警: Prometheus, Zabbix
11. 日志分析: ELK, Splunk
12. 容器管理：Docker, K8S

4. 云计算与云时代运维

4.1. 什么是云计算

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

4.2. 云计算概述(“XaaS”)

1. 表示一切皆服务，它是一个统称(anything as s Service或everything as a Service)
2. XaaS强调的是下游对上游按照契约提供服务，隐藏实现细节，并且通常是通过网络的形式来提供服务。

4.2.1. 典型的三大XaaS

1. Software as a Service (SaaS) 软件即服务，软件分发方式，中心化，服务供用户订阅。
2. Infrastructure as a Service (IaaS) 基础设施及服务，虚拟化，用户需要配置和部署中间件和应用服务。
3. Platform as a service (PaaS) 平台即服务，服务供应商提供开发的整体环境。

4.2.2. 自建、IaaS、PaaS以及SaaS区别

在线编辑文档是SaaS

4.2.3. 云计算、边缘计算与雾计算

1. 云计算：一种利用互联网实现随时随地、按需、便捷地使用共享计算设施、存储设备、应用程序等资源的计算模式
2. 边缘计算：是指利用靠近数据源的边缘地带来完成的运算程序。
3. 雾计算(Fog Computing)，在该模式中数据、(数据)处理和应用程序集中在网络边缘的设备中，而不是几乎全部保存在云中，是云计算(Cloud Computing)的延伸概念。
4. https://www.zhihu.com/question/277126392

4.3. 软件服务的参考模型(ITIL、ITSS、ISO等)

4.3.1. CMMI-SVC

4.3.2. ITIL(Information Technology Infrastructure Library, 信息技术基础架构库)

1. 最佳实践：服务战略、服务设计、服务转换、服务运营、服务改进。

4.3.3. ISO20000、PDCA

1. ISO20000是国际标准化组织发布的第一部针对信息技术服务管理(IT Service Management)领域的国际标准
2. ISO20000定义了"策划-实施-捡查-处置II(PDCA)方法论应用于服务管理体系(SMS)和服务的所有部分：
   1. P-策划：建立书面和协定的服务管理体系；
   2. D-实施：实施和运行服务管理体系，以设计、转换、交付和改进服务；
   3. C-检查：根据方针、目标、计划和服务需求，对服务管理体系进行监视、测量和回顾，并报告结果；
   4. A-处置：采取措施，以持续改进服务管理体系和服务的绩效。

4.3.4. ITSS(Information Technology Service Standards，信息技术服务标准)

1. ITSS是一套成体系和综合配套的信息技术服务标准库

4.4. 运维

4.4.1. 什么是运维

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

4.4.2. 传统运维的转型之路

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

5. Scrum

没有人拥有Scrum，没有Scrum标准

5.1. 什么是Scrum

1. Scrum不是构建产品的一种过程或一项技术，是一个框架，在这个框架里可以应用各种流程和技术。Scrum能使产品管理和开发实践的相对功效显现出来，以便随时改进。
2. Scrum以整体的形式存在，才能作为其他技术、方法论和实践的容器良好运作。

5.2. Scrum 3355

1. 三个角色(Scrum仅承认如下三种角色)
   1. Scrum Master
   2. Product Owner(产品负责人)
   3. Team(团队)
2. 三个工件
   1. Product Backlog(产品待办事项)
   2. Sprint Backlog(Sprint 待办事项)
   3. 可交付产品增量(也有说是燃尽图)
3. 五大仪式(事件)
   1. Sprint(冲刺)
   2. Sprint Planning(Sprint规划)
   3. Sprint Daily Standup(每日站会)
   4. Sprint Review(Sprint 评审)
   5. Sprint Retrospective(回顾)
4. 五大价值观
   1. Coverage(勇气)
   2. Openness(开放)
   3. Focus(专注)
   4. Commitment(承诺)
   5. Respect(尊重)

5.3. 三个角色

1. Product Owner(产品负责人)负责最大化产品以及开发团队工作的价值
   1. 唯一有权要求团队做事以及改变列表条目优先级的人，产品待办事项列表的管理包括
      1. 清晰表达产品代办事项列表条目
      2. 对产品代办事项列表中的条目进行排序，最好地实现目标和使命
      3. 确保开发团队所执行工作的价值
      4. 确保产品事项列表对所有人可见、透明、清晰，并显示Scrum团队的下一步工作
      5. 确保开发团队对产品代办事项列表中的条目达到一定程度的理解
   2. 持有产品远景、代表业务和客户、拥有产品列表，划定故事优先级，设定故事接受标准、回答团队成员的问题
   3. 不要合并产品负责人和Scrum Master
2. Scrum Master负责确保Scrum被理解并实施，担当教练角色，引领团队达到更高级的凝聚力、自组织和表现
   1. 以各种方式服务开发团队，包括：
      1. 指导开发团队自组织和跨功能
      2. 教导并领导开发团队创造高价值的产品
      3. 移除开发团队进展过程中的障碍
      4. 按需推动Scrum事件
      5. 在Scrum还未完全被采纳和理解的组织环境下指导开发团队
      6. Coach and Teacher
   2. 可能担当直接贡献的责任，这种情况下称之为工作型(Working) Scrum Master或贡献型(Contributor) Scrum Master
3. Team(团队)，通常是七个人，一般是五到九个人
   1. 全功能团队拥有完成工作所需要的全部技能，不需要依赖团队外部的人(特性团队)
   2. 特性团队对于某个特性从开始到结束全程负责，存在一个团队等待另一个团队的风险
   3. 自组织团队选择如何最好地完成他们的工作，而不是由团队外的其他人来指使他们。降低管理成本！，更好的协同工作等等
4. 把有兴趣关心，并无利益或价值牵扯的人，排除在项目决策团队以外！

5.4. 用户故事

1. Kent发现最大的问题是使用文档来精确描述需求。
   1. 同样的一份文档，阅读的人不同，各自得到的信息也不一样
   2. 这种缺乏共识的情况，称为 “低质量的需求”
   3. 停止写出完美文档的"执念"
2. 用户故事之所以得名，并不是要人们如何写出更好的用户故事，而是如何在协作中更好地使用它。
3. 故事与任务 Story and Task
   1. Story是可以交付的东西
   2. Task是不可以交付的东西
   3. Product Owner对Task不关心

5.4.1. 需求 —— 用户故事模板

1. 用户故事是产品列表的基础构件。
2. 用户故事模板
   1. 用户角色(who)
   2. 功能(what)
   3. 为什么(why)

作为 <某类用户> (告诉我们想要功能的是谁)
我想 <做某事> (告诉我们预期的功能是什么)
从而 <创造出某些价值> (告诉我们为什么用户想要这个功能)
Eg.
作为管理员，
我想要这个网站使用情况报告，
从而做出有根据的预测并优先完成相关功能。

5.4.2. Ron Jeffries的3C原则

1. 卡片(Card)(placeholder，占位符)：在一堆卡片上写下你期望的软件特性
2. 交谈(Conversation)：聚在一起对要开发的软件进行深入讨论
3. 确认(Confirmation)：对完工条件进行确认

5.4.3. 用户故事的作用

1. 用户故事不是完整的需求或说明书，它们是占位符。
2. 它们的信息量足以提醒团队有东西要完成，但我们刻意地不过多探讨细节直到必需之时。
3. 需要阐述用户故事细节时，我们喜欢使用召集相关团队成员参与交谈的形式。交谈的目标在于，对故事内容以及所需完成的工作达成共识。相对于依赖书面文档，使用实时对话的方式能更高效地达成此目标。它有更多的信息流动。

5.4.4. 用户故事接收标准

1. 交谈中，如果某一刻大家觉得对用户故事已有共识，那就该写验收标准了。找出一列测试，直到所有参与交谈的人都认同测试通过意味着故事按预期实现即可，再用简单易懂的话记录下来。
2. 接收标准回答如下的问题:“我们如何得知它何时已完工?”
3. 理想情况下，团队应该可以根据接收标准写出自动化测试，甚至是在功能实现之前(TDD)。位于产品列表下方的故事可能不会很快被实现，接收标准可以降低精度。

5.4.5. 复杂故事卡

1. 简短的标题
2. 描述信息：用一两句话来描述我们在想什么。使用who、what、why的格式描述是个不错的主意，满足谁的需要(who)，用户会用产品做什么事情、what)，用户期待从中获取什么收益(why)。
3. 故事序号(方便查找或与电子系统连接)
4. 估算、规模或预算
5. 优先级：数字标识；或者高中低
6. 度量
7. 依赖
8. 状态
9. 日期
10. 验收条件

5.4.6. 产品 Backlog

1. 是Scrum的核心，是按重要性排序的需求或故事(Story)的列表(客户语言描述的客户需求)

5.4.7. 用户故事地图

1. 用户故事地图是一门在需求拆分过程中保持全景图的技术，在敏捷开发中使用用户全景地图来发现、管理需求。
2. 解决问题：传统列表式的用户故事难以清洗解释系统到底做什么。

1. 在地图的顶部是"大故事"。活动对人们来说是一件大事，有很多步骤，而且并不总是有精确的工作流程，无法进入迭代和冲刺
2. 大故事往往可以分解成其他故事，这些东西可以被称为用户任务，用一些网格形式将小东西安排在大东西下面。

5.5. Sprint计划会议

5.5.1. 会议准备

1. 所有重要的Backlog条目已经根据重要性被评分，不同的重要程度对应不同的分数(仅用来对Backlog条目排序)
2. 所有人都可以编写添加条目，但只有Product Owner才可以决定优先级

5.5.2. 会议目标

以终为始

1. 确定Sprint目标：尽可能简单的语言，团队成员认可
2. 确定团队成员名单：投入程度(百分比)
3. 确定Sprint Backlog(Sprint中包括的故事列表)
4. 确定好Sprint演示日期
5. 确定好时间地点，供举行每日Scrum会议

5.5.3. 会议注意事项

1. Product Owner必须参加计划会议
2. 每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖
   1. 范围(Scope)：产品负责人
   2. 重要性(Importance)：产品负责人
   3. 估算(Estimate)：由团队设置
   4. 在Sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。

5.5.4. 会议的大概流程

1. 产品负责人对Sprint目标进行总体介绍、概括产品Backlog、定下演示的时间地点
2. 团队估算时间：在必要的情况下拆分Backlog条目、产品负责人必要的情况下修改重要性评分、明晰Backlog的含义。
3. 团队选择放入Sprint中的故事：计算生产率，用作核查工作安排的基础。
4. 为每日Scrum会议安排固定的时间地点，将故事进一步拆分成任务。

5.5.5. 会议的合适长度

1. 确定Sprint长度：
   1. 时间短："敏捷"短反馈周期 = 频繁交付 = 频繁客户反馈 = 错误方向持续时间短 = 学习改进速度快 …
   2. 时间长：更多时间作充分准备、解决问题、达成目标，不会被接二连三的会议压的不堪重负
2. 当前，Scrum 周期通常为一个星期

5.5.6. 会议的产物-Sprint信息页

5.6. 估算

1. 估算是困难的，往往是错误的，误差巨大的。
2. 估算过程是有用的，是管理前方的不确定性的契机，可以作为风险管理的工具，让你发现误解、不一致和可以进一步调查的地方。
3. 团队共同完成估算可以让大家建立对工作一致的理解。根据收益递减原理，不用在估算上花费太多时间，可以做出一个快速但不那么准确的估计。

5.6.1. 估算单位：Story Point

1. Story point：故事点
   1. 选取可识别的最小用例为2个Story Point.其它估算都是相对值，在所有Sprint中保持该相对值一致。
   2. 估算时缩小人与人能力的误差，衡量确定的工作量。
2. 估算速度时，估计我们能在一个迭代周期内能够完成的Story point，之后按照优先级顺序在现有的Product Backlog中选择对应量的Story Point在本迭代周期内完成。
3. 减少故事的规模：很多团队要求每个故事的大小在2-8个故事点，大于8要求拆分故事。

5.6.2. 估算单位：T恤尺码

1. 经常使用的序列是S、M、L。
2. 如果工作项比L大，他们会把它拆分成大小为S、M和L的更小条目。一个XL的条目会占用团队太多的产能，也不便于管理。
3. 必要时可以使用XS和XL。

5.6.3. 估算过程：工程"计划扑克"

1. 示例
   1. 斐波那契数列
   2. 微信小程序：规划卡片
   3. 应用程序：ScrumPlanningPoker
2. 估计过程
   1. 每个团队成员拿到一组卡片。
   2. 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问。
   3. 团队讨论这个条目。
   4. 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上。
   5. 阅读者向大家确认是否都已经确定估算结果，确认后，数"1，2，3"，大家同时展示估算结果。
   6. 团队评估不同的估算结果.我们是否想法一致？我们是否存在分歧？有没有什么是我没有考虑到的？团队共同讨论估算的差异，最终达成一致。如果差异不可接受，返回3.
   7. 返回2，开始估算下一个条目。
3. 算法价值：
   1. 估算过程中的考虑更加全面，估算更加准确：跨职能团队成员从不同视角来四思考和分析问题
   2. 估算过程中的讨论和评判更充分，避免武断或拍脑袋操作
   3. 估算过程是一个知识分享和学习的过程，可以通过讨论等过程来认识学习条目

5.6.4. 另一种扑克牌估算法

1. 在Agile Adoption Patterns: A Roadmap to Organizational Success》一书中Amr Elssamadisy以另一个方式描述了计划扑克的过程。那就是对每一个需求:
   1. 由一个领域专家向团队解释需求并回答问题，以确保大家都理解。
   2. 进入以下轮次，只有在没能达成一致时才进入下一轮次。
      1. 第一轮:大家用卡片独立投票，不要讨论。比如像上面一样数1，2，3一起投票。
      2. 第二轮:让人们先思考一到两分钟，再进入下一轮独立投票，还是不要讨论。
      3. 第三轮:大家先解释一下自己为什么给出这样的投票，然后再次投票。
      4. 如果还没有达成一致，就暂时搁置，先进行下一个需求的估算。
2. 这个方法让你快速得到足够好的估计。如果能够达成一致，就不会对需求做详细的讨论了。

5.6.5. 扑克队列估算法

1. 把每个条目的描述写在单独的卡片上，这个应该在估算前就准备好。
2. 把所有的卡片摞成一摞放在桌上。
3. 拿出第一张卡片，放在旁边。
4. 再拿出一张，问:“这个比第一个大还是小?” 为了回答这个问题，你可能需要和其他人讨论一下这个工作项是干什么的。这需要时间，但别太长，记住这是一个快速估算。
5. 当你决定了它更大或更小后，把它放在原先卡片的上方或下方，形成一列。
6. 重复第4和第5步，直到用完所有的卡片 。
7. 现在你可以把所有的卡片分组了。这也是该技术的第二阶段。从桌上底部(最小)的卡片开始，声明第一组的估算是"小的"。
8. 继续向上，决定到何时为止卡片已经变大到需要用一个新的估算值(如 “中等”)了，让团队决定。
9. 很快，你就可以把整列卡片再过一遍，并加总(5 个的估计是S, 4 个 M ,等等) 以得到整个列的总和，这也就是需求的总工作量估计。从队列最下面的部分开始，第一部分可以被当做S。

5.6.6. "金发女孩"估算技术

1. 这一技术从儿童故事《金发女孩和三只小熊》中受到启发。
2. 作为对工作项大小估计的替代，你可以把工作项调整到合适的大小。
3. 你不再是指定每个工作项的大小，而是去分割或组合工作项，让它们的规模大致相当，并便于后续操作。

5.6.7. 估算差异的原因

1. 需求理解不同。例如：复杂登陆和简单登陆。
2. 技术不熟悉。例如：没有嵌入式经验的工程师估算嵌入式系统开发内容。

5.7. Sprint管理-白板

5.8. 跟踪进度-燃尽图

1. 包含信息：
   1. 该Sprint共需要完成70个故事点
   2. 目前团队还剩下15个故事点要完成
   3. 估计：按照目前速度该Sprint目标可以达到

2. 燃尽图表示生产速度，提醒团队适当修改生成速度

5.9. 每日站会 Daily Scrum

1. 不超过15分钟
2. 回答三个问题：
   1. “昨天我做了什么”
   2. “今天准备干什么”
   3. “你遇到了什么障碍，需要其他人如何帮你”
3. 移动任务板上的即时贴到对应的地方
4. 每日例会一结束就要计算剩余工作故事点并更新燃尽图
5. 团队每日报到、简短、及时开始与结束、聚焦重点、有规律性
6. 另一种站会
   1. 关注事(接力棒) —而不是人(运动员)
      1. 不关注每个人做了或没做什么，而是关注整个工作流或者单个工作项的流动是否有什么问题。
   2. 遍历看板墙
   3. 关注味道
   4. 每日站会之后，鼓励自发改善会议

5.10. Sprint演示会议

1. 为什么定义Sprint结束于演示：
   1. 其他人可以了解你的团队在做什么
   2. 团队得到认可，团队成员感觉很好
   3. 不同的团队得到交流，讨论各自工作
   4. 演示可以吸引相干人士的关注，并得到重要的反馈
   5. 演示会迫使团队真正完成一些工作而不是貌似完成，这样不会污染下一个Sprint。
2. 检查列表
   1. 确保明确阐述Sprint目标
   2. 集中精力演示可以实际工作的代码
   3. 演示保持快节奏
   4. 演示我们做了什么而不是我们怎么做的
   5. 不演示细碎bug的修复和微不足道的特性

5.11. Sprint回顾会议

1. Sprint回顾是仅次于Sprint计划的第二重要的事件！
2. 这是做出改进的最佳时期。
3. 主题：我们怎样才能在下个Sprint中做的更好，不是追究责任！

5.11.1. 活动列表

1. 根据要讨论的内容范围，设定时间为1-3个小时。
   1. 参与者：产品负责人，整个团队还有我自己。
   2. 我们换到一个封闭的房间中，或者舒适的沙发角，或者屋顶平台等等类似的场所。只要能够在不受干扰的情况下讨论就好。
   3. 我们一般不会在团队房间中进行回顾，因为这往往会分散大家的注意力。
   4. 指定某人当秘书。
   5. Scrum master向大家展示Sprint Backlog，在团队的帮助下对Sprint做总结。包括重要事件和决策等。
   6. 我们会轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法，他认为什么是好的，哪些可以做的更好，哪些需要在下个Sprint中改变。
   7. 我们对预估生产率和实际生产率进行比较。如果差异比较大的话，我们会分析原因。
   8. 快结束的时候，Scrum master对具体建议进行总结，得出下个Sprint需要改进的地方。

5.11.2. 使用白板

1. Good：哪些做法可以保持
2. Could have been better：那些做法需要改变
3. Improvements：具体改进想法

5.12. 其他细节点

5.12.1. 敏捷软件开发工作环境

1. 让团队坐在一起
2. 让Product Owner无路可走
3. 让经理和教练无路可走

5.12.2. 静默时间

1. "flow"心流时间，全神贯注在某件事情，以至于忘记了时间的流逝。
2. 公司层面可以为程序员设计专门的静默时间。

5.12.3. Scrum局限

1. 没有技术实践！
2. 可以使用极限编程技术实践：测试的驱动开发、简单设计、重构、持续及成果等等。

6. 敏捷与精益

1. 精益与敏捷是两组具有高度兼容性的价值观和原则，都阐述了如何成功地进行产品开发。
2. Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。

6.1. 敏捷宣言

1. 我们正在通过亲身实践以及帮助他人实践，探寻更好的软件开发方法。通过这项工作，我们建立了如下价值观
   1. 个体和互动 胜过 流程和工具
   2. 可以工作的软件 胜过 详尽的文档
   3. 客户合作 胜过 合同谈判
   4. 响应变化 胜过 遵循计划
2. 也就是说，虽然右项也具有其价值，但我们认为左项具有更大的价值。

6.2. 敏捷原则

1. 通过持续不断地及早交付有价值的软件使客户满意(最重要目标)
2. 欣然面对需求变化：为客户竞争优势，通过敏捷过程控制变化
3. 经常地交付可工作的软件：短周期交付
4. 业务人员和开发人员必须相互合作
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标
6. 不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈
7. 可工作的软件是进度的首要度量标准
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强
10. 以简洁为本，它是极力减少不必要工作量的艺术
11. 最好的架构、需求和设计出自自组织团队
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现

6.3. 敏捷方法

1. 凡遵循上述价值观和原则的方法或方式都视为敏捷方法。

6.4. 敏捷软件开发

1. 敏捷软件开发是当前公认的，应对模糊需求、快速变化需求的最佳软件开发方式。
2. 核心实践：
   1. 可视化工作流程，Kanban方法(渐进增量式的过程改进方法学)，使用物理白板：提高信息辐射的作用，容易发现团队工作的状态和问题、降低沟通交流成本
      1. 工作项(即时贴)：描述、电子系统的标识、期限、处理者、类型
      2. 列：映射团队工作流，包括工作的所有阶段。
   2. 限制在制品：限制在制品的数量
      1. 原理是硬币游戏，折衷个人效率和工作效率
      2. 意义：减少在制品使其快速流过整个工作流，使前置时间缩短(前置时间：处理一个工作项从开始到结束所经过的时间)

6.5. 精益

精益来自于日本丰田公司的TPS(丰田生产方式)。敏捷与精益可以看作是一对拥有共同价值观但起源不同的兄弟。精益起源于制造业，敏捷起源于软件开发。

6.6. 精益原则

1. 全局优化：局部的优化长期来说会对系统整体优化不利
   1. 专注于整体价值流：从概念到现金。从客户需求到软件部署。
   2. 交付完整产品：客户不要软件产品，他们要解决问题。完整的解决方案是由完整的团队构建的。
   3. 着眼长期：警惕导致短期思维和优化局部业绩的治理和激励体系。
2. 消灭浪费：浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下：
   1. 构建错误的功能：“没有什么比高效完成根本不应做的工作更无用”
   2. 拒绝学习：我们有很多策略都干扰了我们学习，例如，只按计划行事、频繁移交、决策与工作分离等，而学习则是开发的精髓。
   3. 辗转现象：那些干扰价值顺利流动的做法，例如，任务切换、请求清单冗长、大堆未完成的工作等等，都只能达到事倍功半的效果。
3. 品质为先：如果在验证过程中总是能发现缺陷，那流程就有问题。
   1. 最终验证不应发现缺陷：所有软件开发流程的根本目的都是尽早在开发阶段发现并修复缺陷
   2. 采用测试先行的开发模式让流程具有防误机制：测试(包括单元测试、端对端测试和集成测试)必不可少，以此建立信心，保证系统在任何层次、在开发阶段任何时间点都始终正确无误
   3. 打破依赖：系统架构应当支持随时添加功能
4. 不断学习：规划工作非常有用。学习则必不可少。
   1. 可预测的性能来自于反馈：可预测的组织不会猜测未来并称之为计划；反之，他们会培养能力对未来做出响应。
   2. 保持选择方案：视代码为实验——使其具有容变性。
   3. 最后可靠时刻：在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策，也不要事后才做出决定！
5. 尽快交付：从一开始就深入了解所有干系人看重的价值。然后基于这样深入了解的价值观，创建稳定、连贯的工作流。
   1. 快速交付、高质量和低成本是完全相互兼容的：以速度竞争见长的公司拥有很高的成本优势，他们可以交付优质的产品，而且对客户需求更为敏感。
   2. 排队理论同样适用于开发，而不仅仅是服务行业：专注于使用性会造成交通堵塞，反而降低了使用性。以较小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。
   3. 管理工作流比管理进度表要容易得多：建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。
6. 人人参与：聪明、有创造力的人员的时间与精力，是当代经济的稀有资源和竞争优势的基础。获得公正薪资的人员在自主性、成长性和使命感等方面受到激励。
   1. 自主性：最有效的工作小组是半自治团队，有一个内部主管从头到尾负责完整、有意义的任务。
   2. 成长性：对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。
   3. 使命感：将工作与价值挂钩。只有相信自己工作的意义，团队成员才会全心投入工作，实现这种使命。
7. 不断提高：结果不是重点——重点是培养人、发展体制，使之能够交付结果。
   1. 失败是个学习机会：即使是非常小的失败都会被深入调查并纠正的，做到一丝不苟的时候，才可能获得最可靠的性能。
   2. 标准存在的目的就是要被质疑和提高的：将现行的、最知名的做法纳入人人都遵循的标准，与此同时鼓励所有人质疑并改变标准。
   3. 使用科学方法：教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。

7. 看板

7.1. 什么是看板方法

1. 看板方法，由David Anderson创立，它脱胎于大野耐一所创立的丰田生产方式(TPS)，以及埃利亚胡·高德拉特(EliGol-dratt)的约束理论(TOC)，并结合统计质量控制(SQC)、排队论(QT)、工业工程(IE)、软件成熟度模型(CMMI)等多个领域的知识，在软件开发社区中获得了极高的关注度，并迅速传播开来。
   1. 看板并不是一种软件开发生命周期的方法学，也不是一种项目管理的方法。
   2. 实施看板时，需要当前已经有一些在运行的过程，这样便可应用看板来逐步改变当前运行的过程。
   3. 平均生产周期。每次有任务到达"Done"这一列(不管它叫什么吧，反正是最右边那一列)的时候就更新数据。
   4. 瓶颈。典型症状就是X列里面堆满了卡片，但是X+1列里空空如也。找找板上哪里有"气泡"吧。
2. RUP和Scrum
   1. RUP的规范性相当强：它有30多种角色，20多种活动，70多种工件
   2. Scrum和RUP的主要区别在于，RUP给你的东西太多了，你得自己把不需要的东西去掉；而Scrum给你的东西太少了，你得自己把需要的东西加进来。
3. XP、Scrum
   1. XP(极限编程)比Scrum又规范一些。它囊括了Scrum的大部分内容，还多了很多相当具体的工程实践，例如测试驱动开发和结对编程。而Scrum没有规定任何具体的工程实践。
4. 看板几乎对任何做法都是开放的。它仅有的约束就是将流程可视化和限制在制品。它离做什么都行只有几步之遥，但仍有令人惊异的力量。

7.2. 看板和Scrum

1. 看板适合支撑维护团队，Scrum适合支撑全新开发团队，但不绝对
2. 看板和Scrum都是过程工具，都较高的适应性：相对Scrum更规范一些，它规定了迭代和跨功能团队之类的东西。
3. 看板和Scrum都是经验主义的产物，需要使用前先实验再调整。 它最核心的一点就是反馈环。改变=>检查结果=>从中学习=>继续改变。一般而言，反馈环越短越好，这样可以快速调整过程。

4. 相似性
   1. 都是既精益又敏捷、都是拉动式计划、都限制了WIP。Scrum的WIP按单位时间限制；看板的WIP按流程状态限制。
   2. 都以透明的方式驱动过程改进
   3. 都关注于尽早交付、频繁交付可发布的软件
   4. 根基都是自组织型团队
   5. 都需要把工作拆分
   6. 发布计划都是根据经验数据(生产率/生产周期)不断优化的。
5. 差异

7.3. 白板

1. 把项目原来在Jira中的工作内容贴在白板上。
2. 每个工作项一个记事贴。
3. 我们一般称电子工具为信息冰箱。
4. 可视化工作
   1. 你无法对自己没有看到的进行改进。
   2. 让隐藏的工作无所遁形
   3. 为每个工作项建立一个即时贴即可轻易做到
   4. 帮你理凊
   5. 谁在干什么
   6. 你正在处理的工作
   7. 进行中的工作数量
   8. 工作可视化之后，信息将散播给看到的每个人
5. 完成工作流映射

7.3.1. 工作项

1. 卡片上有什么内容?
2. 从卡片上你可以
   1. 看到工作项的进展状态
   2. 能够决定下一步如何处理
3. 常见的属性为
   1. 工作项描述
   2. 电子系统中的唯一标识
   3. 完成期限
   4. 谁在处理这个工作项
   5. 工作类型(比如bug或者常规工作)

7.3.2. 在制品(Work in Progress，WIP)

1. 在制品(WIP)是同时进行中的工作数量，减少在制品使其快速流过整个工作流，即前置时间缩短。
2. 我们不再关注是否每个工人的工作都是最有效率的
3. 在最后一轮中，前置时间是最短的，但每个工人的工作时间都延长了，从个人来看工作效率下降了，但整个团队的效率最高。
4. 寻找WIP的例子
   1. WIP上限提醒我们要采取行动，改善瓶颈；而不是把没完成的工作堆啊堆啊堆啊堆个没完。
   2. 但要是WIP当初设成4的话，我们早就能有所反应了，这样平均生产周期还能表现得好点。所以这是要平衡的。我们度量平均生产周期，不断优化WIP上限，以此优化总生产周期。

7.3.3. 紧急工作

1. 快速通道
2. 处理特殊情况的常用方式，如紧急工作
3. 通常在白板上刻划为单独通道
4. 快速通道的相关规则如下:
   1. 任何时候最多只能有一个工作项在快速通道内
   2. 每周最多有一个紧急工作
   3. 快速通道内的工作项无需计入在制品限制

7.4. 限制在制品

1. 致力于减少同时处理的工作项
2. 批量规模越小，前置时间越短
3. 流动效率提升的同时资源效率会有所降低
4. 立即实施:停止立项并开始完成
5. 限制在制品将使改进机会浮出水面：着手改进后会获得更快的流动
6. 不要企图找到一个唯一正确的数字作为团队的在制品限制规模.
7. 在制品限制不是仅为了设立规则，而是为了触发讨论

7.5. 度量

1. 有利于团队改进
2. 团队自己选择度量指标，但不要将度量指标用于绩效考核
3. 两个常用的度量指标为:
   1. 前置时间是整个工作流的时间
   2. 吞吐量是一定时间段内完成的工作项数量

7.6. 看板实例

7.7. 别把自己绑在一种工具上

1. 把工具搭配着用，用在合适的地方。
2. 无法想象几乎不用XP的Scrum团队还能成功。很多看板团队也在做每日立会(Scrum实践)。有些Scrum团队也把backlog条目写成用例(RUP实践)，还会限制队列大小(看板实践)。只要有用就行。
3. 不过我们还是要关注每样工具有哪些约束的。假如你在用Scrum，又决定不用固定时长的迭代(或是其他任一款Scrum的要素，3355)，就不要说你在用Scrum了。Scrum本身已经足够浓缩了，如果你去掉一些东西，然后还叫它Scrum，那这个词就失去了意义，只会带来困扰。

8. 微服务化软件架构

1. 软件架构
   1. 架构是一系列重要决策的集合，包括：软件的组织，构成系统的结构要素和接口选择，元素在协作中的行为
   2. 架构是计算组件和组件之间的交互：连接件和约束

8.1. 软件架构发展

1. C/S架构 -> B/S架构 -> 服务端MVC架构 -> 客户端MVC架构 -> 服务端-N层架构(展示层、业务层、持久层、数据库) -> SOA -> 微服务架构
2. 架构设计策略：缓存与读写分离 -> 动静分离 -> 集群化高可用架构 -> 业务拆分与分布式 -> 微服务架构
3. 单体架构
   1. 优点：为人熟知、IDE友好、便于共享、易于测试、容易部署。
   2. 缺点：不够灵活、妨碍持续交付、受技术栈限制、技术债务积累、性能、可用性、伸缩性、扩展性、安全性。
4. 分层架构：“关注点分离”
   1. 表示层、业务层、持久层、数据层
   2. 优点：结构简单、易于组织开发、易于测试和维护
   3. 缺点：不容易实现持续发布和部署、层层调用影响性能、层层接口可扩展性差
5. 面向服务架构(SOA)
   1. 是一个分布式组件的集合，组件通过提供服务与消费来进行通信，企业服务总线(ESB)提供环境支持
   2. 绑定时间延后到运行时
   3. 优点：服务自身高内聚、服务间低耦合、互操作性良好、可重用性高
   4. 缺点：复杂性提高、难以测试验证，演化不可控、总线(ESB)可能会成为运行瓶颈
   5. 与面向服务架构相关的Web服务标准包括：SOAP、WSDL、UML
6. 微服务架构
   1. 将单一应用程序开发为一组小型服务的方法。每个服务运行在自己的进程中，将应用拆分成多个小业务单元来开发和部署，使用轻量级协议通信，通过协同工作实现应用逻辑的架构模式。
   2. 微服务的理念：分而治之，本质上也是分布式架构(面向服务(SOA)的一种扩展)
   3. 特点
      1. 应用程序分解为具有明确定义了职责范围的细粒度组件
      2. 完全独立部署，独立测试，并可复用
      3. 使用轻量级通信协议，HTTP和JSON，松耦合
      4. 服务实现可使用多种编程语言和技术
      5. 将大型团队划分成多个小型开发团队，每个团队只负责他们各自的服务
   4. 挑战
      1. 运维要求高
      2. 发布复杂度高
      3. 部署依赖强
      4. 通信成本高
   5. 微服务的核心模式
      1. 服务的注册和接收机制
      2. 外部服务和内部服务的通讯方式：API网关服务，作为全部服务端的单一接入口
      3. 服务间的通讯方式：API转发服务
      4. 熔断器：防止程序不断尝试无效操作，并且可以进行诊断
         1. 闭合状态：直接发出请求
         2. 半断开状态(Check)：对程序一定数量的请求调用服务。若成功，则认为已经修正，改回闭合
         3. 断开状态：发起请求就出错
   6. 微服务和SOA的关系
      1. 微服务是SOA的扩展
      2. 微服务架构强调业务系统需要彻底组件化和服务化
      3. 微服务强调去ESB，去中心化，分布式，按业务而不是按照技术划分模块
      4. SOA以ESB(服务总线)为核心，可仍然是单一系统
7. 应用架构对比

8.2. AFK可扩展性模型

1. AKF扩展原则
   1. 理论上按照三种扩展模式可以将单体系统进行无限扩展。
   2. X轴：水平复制，配合负载均衡
   3. Z轴：数据分区，不同地区有不同的数据分区
   4. Y周：微服务的拆分模式，基于不同的业务进行拆分

8.3. 微服务治理

8.3.1. 微服务架构转型遇到的挑战

8.3.2. 分布式追踪

1. Skywalking核心概念和组件
   1. 两个维度
      1. Tracing 追踪链路数据
      2. Metrixs 指标数据
   2. 三个层级
      1. Receiver 接收器：解析和适配不同协议
      2. Analysis Core 分析内核：OAL
      3. Query Core 内核：多维度数据查询

8.4. 微服务设计原则

1. 大平台
   1. 以业务分层方式将核心业务功能沉淀到平台中
   2. 采用微服务架构,支持互联网使用场景
   3. 采用持续交付平台,更好支撑先有研发流程,并提升效率
   4. 采用敏捷基础架构,更好支撑微服务架构应用
   5. 采用统一监控运维平台,提升运维自动化水平和效率
2. 微应用
   1. 只包含特定业务逻辑和展现
   2. 支持多种触点方式
   3. 支持快速创新与试错

8.5. 下一代微服务：Service Mesh

1. 一种基础设施层，服务间的通信通过Service Mesh进行。
2. 可靠地传输复杂网络拓扑中服务的请求，将服务变成现代的云原生服务。
3. 一种网络代理的实现，通常与业务服务部署在一起，业务服务不感知。
4. 一种TCP/IP之上的网络模型。

8.5.1. 部署模型：单个服务调用，表现为sidecar

8.5.2. 部署模型：多个服务调用，表现为通讯层

8.5.3. 部署模型：有大量服务，表现为网络

8.5.4. 为什么使用Service Mesh

1. 无需多种语言的微服务框架开发
2. 对业务代码0侵入
3. 不适合改造的单体应用
4. 开发出开的应用既是云原生的又具有独立性

9. 云原生简介

1. 云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
2. 云原生是一种基于微服务的软件架构思想以及基于Devops进行软件开发实践的一组方法论，其实现了以分布式和容器技术为核心在异构云平台环境下利用云计算交付模型优势来快速构建、部署和进行企业应用。
3. 云原生描述了一种高性能的组织模式，可快速、一致、可靠的规模化交付软件。
   1. 业界选择云原生的原因
      1. 更高的资源效率可以用更少的服务器运行相同数量的服务
      2. 云原生基础设施提高了开发速度
      3. 云原生支持多种云和混合云开发
      4. 云原生使得快速部署成为可能
   2. DevOps(如何云原生)
      1. 开发和运维：职责不同，技能不同
      2. 让开发和运维共同为业务的成功负责
      3. 技能一部分融合
   3. 微服务(做什么来云原生)按业务逻辑拆分出小而专注的服务，对外暴露接口，生产环境组装在一起
4. 黄金三角
   1. 微服务架构：应用脚骨
   2. 敏捷的基础设施 容器、SaaS
   3. Devops，持续交付：如何快速地交付软件

9.1. 容器

1. 容器是资源精细化编排的代表。
2. 容器通常指在一个隔离的环境中运行的进程以及进程所依赖的环境的总称。
   1. 隔离：借助于linux的namespace机制
   2. 资源限制：可以基于linux的cgroup计算对容器所能使用的资源做限制，主要指cpu、内存资源
   3. 进程：linux进程
   4. 依赖环境：进程运行所依赖的库、以及其他的资源
3. 容器的优点
   1. 更轻量
   2. 资源利用更高效
   3. 以应用为中心的管理

9.2. K8S

9.2.1. 什么是K8S

1. K8S是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。
2. 能力
   1. 支持不同的底层资源平台
   2. 自动弹性伸缩
   3. 高可靠性

9.2.2. 为什么需要K8S

1. 需要一个系统来管理集群上的大量容器。
2. 用于完成容器的编排，目前K8S已经是容器编排领域事实上的标准。

9.2.3. K8S架构

1. Master节点
   1. API Server
   2. Schuduler
   3. Controller
   4. etcd
2. Node节点
   1. pod
   2. docker
   3. kubelet
   4. kube-proxy
   5. fluentd

9.2.4. K8S组件

1. 控制平面：对集群做出全局决策，以及检查和响应集群时间(例如，当不满足部署的replicas字段时，启动新的pod)
   1. kube-apiserver
   2. kube-scheduler
   3. kube-controller-manager
   4. cloud-controller-manager
   5. etcd
2. 计算平面
   1. 计算平面由Node节点组成
   2. 运行组件
      1. Kubelet
      2. Kube-proxy
      3. 容器运行时(Container Runtime)
3. 插件(Addons)
   1. DNS
   2. Dashboard
   3. 容器资源监控
   4. 日志

9.2.5. K8S重要概念

9.2.5.1. POD

1. POD是K8S的最小资源管理单位，POD有点脆弱。
2. POD中包含资源
   1. 一个或多个应用程序容器
   2. 存储卷
   3. 网络地址，如IP地址、端口等

9.2.5.2. Workload 工作负载

1. 工作负载是在K8S上运行的应用程序，K8S主要支持
   1. Deployment
   2. Statefulset
   3. Damonset
   4. Job
   5. CronJob

9.2.5.3. Service

1. Service定义了POD提供给外部应用的方式
2. 为什么引入Service?
3. Service怎么和Pod关联起来？
4. Service有哪些类型
   1. ClusterIP
   2. NodePort
   3. LoadBalancer
   4. ExternalName

9.2.5.4. label

1. label是key/value键值对，用来识管理和识别资源。
2. Node、Pod、工作负载、密钥、configmap、service等等所有资源都可以增加标签
3. 签通常用来识别资源，一般和标签选择器配合使用。

10. 软件工程和方法

1. 软件的困难和挑战：没有银弹：软件开发的宿命
   1. 复杂度：不同于建筑、汽车等产品，软件实体可能比任何由人类创造的其它实体都要复杂
   2. 一致性：不同于数学、物理等学科，软件工程所控制的很多复杂度是由大量因素组合影响的，来自于人为惯例和系统内外部影响，如合规、GDPR、CMMI等
   3. 可变性：由于软件是纯粹的思维产物，易于修改，用户经常会提出改进要求
   4. 不可见性：软件是无法可视化的，不仅限制了个人的设计过程，也阻碍了设计人员之间的交流
2. 软件工程的核心问题
   1. 管理视角：成功是否可以复制
   2. 技术视角：问题是否可以解决地更好

10.1. 软件过程

1. 软件过程：为了实现一个或多个实现定义的软件目标而建立起的一组实践集合
2. 广义软件过程
   1. 理论基础：软件产品和服务的质量，很大程度上取决于生产和维护该软件或服务的过程的质量
   2. 包括技术、人员以及狭义过程，比如有XP方法、Scrum方法、敏捷软件过程等等。
   3. 同义词：软件开发过程、软件开发方法

10.2. 生命周期模型

1. 生命周期模型：对软件过程的人为的划分
   1. 软件过程和生命周期模型的区别和联系
      1. 对软件过程的人为的划分
      2. 是软件开发过程的主框架，是对软件开发过程的粗粒度划分
      3. 往往不包括技术实践
   2. 典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法。

10.3. 软件项目管理与软件过程管理

1. 软件项目管理(产品生产管理，关注各个目标(成本、质量等)有没有实现，着眼于一个特定的项目)：包括估算、计划、跟踪、风险管理、范围管理、人员管理、沟通管理等。
   1. 三要素：目标、状态、纠偏
   2. 三目标：成本、质量、工期
   3. 是应用方法、工具、技术和人员能力来完成软件项目，实现软件目标的过程。
2. 软件过程管理(关注研发流程和生产效率)
   1. 管理对象：软件过程
   2. 关注研发的流程，关注流程的输出效率和质量，不关注某个特定的项目
   3. 目的是为了让软件过程在开发效率、质量等方面有更好的性能绩效。
   4. 包括CMM/CMMI和SPICE模型

10.4. 软件过程改进

1. 软件过程改进：与软件过程管理含义相近，包括PDCA(图)和IDEAL模型

2. 为什么CMMI模型不应该是敏捷方法的对立面：CMMI模型本身并不是开发模型，而是一个过程改进的模型，刻画了软件组织从不成熟到成熟的路线图。
   1. 5级成熟度：初始级、可重复级、定义级、管理级、优化级
   2. 是过程改进模型而非过程模型，CMMI Vs. Agile是伪命题

10.5. 软件工程三大阶段

1. 软硬件一体化 50-70年代 code and fix
2. 软件成为独立的产品 70-90年代 结构化程序和瀑布模型
3. 网络化和服务化 90年代-至今 迭代式、敏捷、XP、Scrum

10.6. 个体软件过程(PSP，略讲)

1. PSP的意义
   1. 开发在前，运维在后
   2. 高质量开发确保DevOps中的价值顺畅流动
   3. 个体软件工程师的技能、过程直接影响产品质量
   4. PSP关注提升个体软件工程师工程技能
2. 面向用户的质量观：定义质量为满足用户需求的程度
   1. 用户是谁？
   2. 用户需求优先级是什么？
   3. 用户需求优先级对软件产品的开发过程产生什么样的影响？
   4. 怎样度量这种质量下的质量水平？
3. 什么是PSP
   1. 包含了数据记录表格、过程操作指南和规程在内的结构化框架
   2. 基本的PSP流程包括：策划、设计、编码、编译、单元测试以及总结
   3. 每个阶段都有对应的过程操作指南。
   4. 每个过程都有时间日志和缺陷日志。
4. PSP质量策略：用缺陷管理替代质量管理
   1. 几乎没有缺陷是用户的首要期望
   2. 组成软件产品的各个组件基本无缺陷
   3. 各个组件的高质量是通过高质量评审来实现的
5. 缺陷消除方式：测试、评审
6. 开展有效的评审
   1. 评审检查表
   2. 质量控制指标
      1. Yield：某阶段在消除缺陷方面的效率
         1. Phase Yield = 100 * (发现缺陷个数) / (注入缺陷数 + 进入阶段前遗留缺陷数)
         2. Process Yield = 100 * (第一次编译前发现缺陷数) / (第一次编译前注入缺陷数)
      2. A/FR：PSP质检成本 / PSP失效成本，值越大质量越高，但不能过高，期望值为2.0
      3. PQI(以下5个数值成绩，>0.4被认为是高质量)
         1. 设计质量 min(设计时间/编码时间)，设计时间应该大于编码时间
         2. 设计评审质量
         3. 代码质量：代码缺陷密度应该小于10/千行
         4. 代码评审质量
         5. 程序质量：单元测试缺陷密度应小于5/千行
   3. 评审速度：代码 < 200行每小时，文档 < 4页每小时
7. PSP过程
   1. 过程度量：规模度量、时间度量、缺陷度量

10.7. 判断

1. 软件过程管理是软件项目管理应该要实现的目标 √
2. XP与CMM是对立的两种软件开发方法 √
3. CMM不适合当今互联网环境的项目管理需求 √
4. PDCA和IDEAL不适合在敏捷环境中使用 ×

11. DevSecOps

11.1. 什么是DevSecOps

1. DevSecOps 旨在将安全性嵌入研发过程的每个部分(比如，需求，架构设计，开发，测试和运维等)。这意味着将应用安全思维模式左移到开发团队

3. DevSecOps 通过在 DevOps 流程的每个阶段或检查点构建安全性来消除 DevOps 和信息安全之间的障碍，从而更快，更安全地生成高质量地代码
4. 为什么需要DevSecOps
   1. DevOps的快速交付与传统安全模式形成冲突，让安全性成为束缚快速交付的瓶颈
   2. DevSecOps的好处包含：
      1. 快速交付
      2. 控制风险
      3. 节省成本

11.2. 原则

11.3. 方法

11.4. 工具

1. 静态应用安全工具(SAST)
   1. 优势
      1. 白盒测试，代码具有高度可视性，安全漏洞精准定位，检测问题类型更丰富
      2. 不需要用户界面，漏洞发现更及时
      3. 容易被程序员接受
   2. 劣势
      1. 区分开发语言和平台，误报多，人工成本高
      2. 扫码时间随着代码量的提高显著变长
      3. 不能测试整个问题，集成系统的漏洞发现不了
2. 动态应用安全工具(DAST)
   1. 优势
      1. 攻击者视角，可发现大多数高风险问题
      2. 黑盒测试，无需源代码，测试对象范围较广
      3. 支持当前的各类主流编程语言开发的应用
   2. 劣势
      1. 对测试人员有一定的专业要求
      2. 大部分工具不能被自动化
      3. 无法定位漏洞的具体位置
      4. 较强入侵性，安全测试的脏数据会污染业务测试数据
3. 交互式应用安全工具(IAST)
   1. 优势
      1. 漏洞检出率和准确性高，误报漏极低，漏洞信息详细度高
      2. 测试过程无感知，漏洞发现快
   2. 劣势
      1. 每次更新agent需要重启webserver, 部署成本较高
      2. 无法测试业务逻辑漏洞