DevOps-DevOps的框架和工具 | “朝闻道”知识分享大赛

[小年华°Moon]

这是我参加朝闻道知识分享大赛的第29篇文章。

前言：本文是我学习“腾讯云开发者认证”-“CODING DevOps 开发者”的过程性笔记。CODING DevOps相较于别的课程而言，他更注重的不是代码，而是方法。通过对课程和相关拓展资料的了解，可以更进一步的了解和掌握和应用开发相关的知识。帮助我们在团队开发中做一个更好的领导者。另外，CODING DevOps的基本功能是免费的，大家可以多多尝试用CODING DevOps来协助我们平时简单项目的开发。

目录

1. 基础原则

1.1 三步工作法

1.2 流动原则

1.3 反馈原则

1.4 持续学习和实验原则

2. 模式

2.1 开发和运维协作

2.2 完全共享的运营职责

2.3 SRE团队（谷歌模型）

3. 反模式

3.1 开发和运营孤岛

3.2 DevOps团队孤岛

3.3 开发者不需要操作

---

1. 基础原则

1.1 三步工作法

• 三步工作法是支撑DevOps 发挥重要作用的理论基础，它包括流动原则、反馈原则、持续学习与实验原则。

• 这三大原则分别从不同方面指导优化着软件开发过程，其中流动原则聚焦于增强价值流的流动性、反馈原则关注于持续快速的反馈机制、持续学习与实验原则致力于创建学习型、高度信任感的企业文化。

1.2 流动原则

让价值流快速的从左（Dev，Business）到右（Ops，Customer）进行流动

1. 让工作可视化

2. 限制在制品

3. 减少批量规模

4. 减少交接数量

5. 持续识别和扩宽约束

6. 在价值流中消除浪费

1.3 反馈原则

经过放大的反馈回路，创建从开发过程下游至上游的反馈环，即从右到左的反馈。

1. 在复杂系统中安全地工作

2. 在出现问题时及时发现

3. 密集解决问题，构建新知

4. 保持将质量向源头推进

5. 为下游工作进行优化

1.4 持续学习和实验原则

持续做试验，承担风险、从失败中学习；通过反复实践来达到精通。

1. 开启组织学习和安全文化

2. 让日常工作的改进做到制度化

3. 将局部发现转化为全局改进

4. 在日常工作中注入恢复模式

5. 领导层强化学习文化

2. 模式

2.1 开发和运维协作

模式介绍： Dev 团队和Ops团队之间的顺畅协作，每个团队都专注于需要的地方，但也分享需要的地方。 可能有许多独立的开发团队，每个团队都在独立或半独立的产品堆栈上工作。

适用性：具有强大技术领导力的组织

有效性：高

2.2 完全共享的运营职责

模式介绍： 产品开发人员集成了运营人员。Dev和Ops之间几乎没有分离，所有人都高度关注一个共同的目标。 netflix和Facebook 这样拥有单一基于Web的产品组织已经实现了这种模式

适用性：具有单一的主要基于Web的产品或服务的组织

有效性：高

2.3 SRE团队（谷歌模型）

模式介绍： 明确地从开发“移交”到运行软件的团队，即站点可靠性工程［SRE］团队。在这个模型中， 开发团队需要向 SRE 团队提供测试证据［日志、指标等〕，证明他们的软件具有足够好的标准，可以得到SRE团队的支持

适用性：仅适用于具有高度工程和组织成熟度高的组织

有效性：从低到高 （组织工程能力越强，有效性就越高）

3. 反模式

3.1 开发和运营孤岛

模式介绍： 这是Dev和Ops之间经典的“把它扔到墙上”分裂。这意味着可以提早声明故事点 ［DONE意味着“功能完整”，但不能在生产环境中工作〕，并且软件可操作性会受到影响， 因为开发人员没有足够的上下文来处理操作功能，并且运维人员没有时间或不愿意参与开发阶段的工作

3.2 DevOps团队孤岛

模式介绍： DevOps团队孤岛通常是由于经理或高管决定他们“需要一些DevOps的东西”并开始一个“DevOps团队”［可能充满了被称为“DevOps”的人］。 DevOps 团队的成员很快形成了另一个孤岛，让Dev 和Ops比以往任何时候都更加分离，因为他们保护自己的角落、技能和工具集免受“Devs”和“Ops”人员的侵害 。

3.3 开发者不需要操作

模式介绍： 这种拓扑结构源于开发人员和开发经理的天真和傲慢，尤其是在开始新项目或系统时。 假设Ops现在已成为过去［云计算已经不需要运维人员了？〕，开发人员大大低估了运维技能和活动的复杂性和重要性， 并相信他们可以不使用它们，只需要在开发团队中由DevOps负责一切运维就好了