01 - 10

01 - Do the right thing!

在实践中，很难时刻关注目标并审视自己。
如果将DevOps看做是一个工具箱，那么就需要思考并从中找出合适的工具，来正确应对当前工作。
要确保在做正确的事情，而不是在不理解问题的前提下实现想法。
虽然有Sprint回顾会议机制，用来捕获潜在的改进空间，但往往没有真正地执行。

• 是否在做正确的事？
• 是否在正确的路上？
• 应该以怎样的积极行动来敏捷地面对？

02 - PCDA循环与DevOps

PDCA循环是一种管理方法，主要用于在企业和商业活动中进行持续生产改善，并采取相应的控制措施。
这一方法将业务分为Plan(计划)、Do(执行)、Check(检查)和Act(处理)四个阶段来进行，在执行改善措施之后，又回到Plan(计划)阶段，如此循环往复。

• P (Plan) 计划：包括方针和目标的确定，以及活动规划的制定。
• D (Do) 执行：根据已知的信息，设计具体的方法、方案和计划布局；再根据设计和布局，进行具体运作，实现计划中的内容。
• C (Check) 检查：总结执行计划的结果，分清哪些对了，哪些错了，明确效果，找出问题。
• A (Act）处理：对总结检查的结果进行处理，对成功的经验加以肯定，并予以标准化；对于失败的教训也要总结，引起重视。对于没有解决的问题，应提交给下一个PDCA循环中去解决。
  以上四个过程不是运行一次就结束，而是周而复始的进行，一个循环完了，解决一些问题，未解决的问题进入下一个循环，阶梯式上升。
  全面质量管理活动的全部过程，就是质量计划的制订和组织实现的过程，这个过程就是按照PDCA循环，不停顿地周而复始地运转的。

关于PDCA的现代观点

• P（Planning）——包括三小部分：目标（goal）、实施计划（plan）、收支预算（budget）。
• D（design)——设计方案和布局。
• C（4C)——4C管理：Check（检查）、Communicate（沟通）、Clean （清理）、Control（控制）。
• A（2A)——Act（执行，对总结检查的结果进行处理）、Aim（按照目标要求行事，如改善、提高）。

与DevOps的关系

实施DevOps需要以PDCA的方式循环进行，在DevOps中，敏捷开发方法是实现PDCA循环的方法之一。
也就是说，DevOps是融合在业务中的持续性的改善和实践，而不是为了一次性完成所有的改善。

03 - 组织形式与DevOps

康威定律：设计系统的组织，其产生的设计等同于组织的沟通结构。
通过引入DevOps的工具和文化，能够使系统架构和组织结构同时发生变化。

04 - 在DevOps中应用Docker

构建功能单一的轻量级容器镜像

• 容器以功能为单位进行分割，内容精简，缩小镜像
• 容器之间尽量松耦合，消除容器内部对环境的依赖因素，提高通用性
• 容器镜像本身不应保存与具体环境相关的信息

05 - From Traditional to Future

06 - DevOps技能图谱

仅作为参考，实际情况差异巨大。

• https://github.com/TeamStuQ/skill-map/blob/master/data/map-DevOps.md
• https://www.infoq.cn/article/the-must-know-checklist-for-devops-and-sre
• https://www.infoq.cn/article/NpBtkovq8idXk-Z0yoby

不同成长阶段对技能的需求是不同的，无法准确用一张图来表示合适的内容。
大而全的技能图谱，不是为具体实施场景所准备的，而且里面甚至包括了过时的信息，不适合作为了解的途径。
这种技能图谱中的很多知识点、工具和技能其实不是现在就必须掌握的，重点是要掌握实际实施所必须的最少必要知识，先开展工作，然后在后期工作中按照需求、循序渐进地接触和使用。。
什么都想接触都想了解，效果必然很差，浪费时间和精力。

07 - 分支策略

制定分支的创建规则和使用规则，避免随意创建新分支导致的分支混乱、难以区分和回溯等问题。

• 在什么时候需要使用分支？
• 在什么时候合并到哪个分支？
• 在不同的环境中分别使用哪个分支？
• 在修改bug或者添加新功能时使用哪个分支？
• ......

08 - DevOps几个关键点

• 系统思考（将开发、测试、运维等环节之间的流程视为一条管道，从整体分析、定位和解决问题）
• 增强反馈回路
• 培养不断试验和学习的文化
• 积极传播信息促进团队和个人成长

09 - 信息共享与管理

只有积极地传播和共享信息，才能推进DevOps的实施，提高团队的战斗力

• 传统的方式：以文件形式存储在一台共享服务器上，存在难于搜索内容、无法获知更改信息和文件实时状态等问题
• Web方式：Wiki、Confluence、看板等，易于创建和修改，能够快速准确找出所需信息
• 代码库方式：信息文件存储在代码库，能够准确获知信息内容的状态和变化，以及历史信息

10 - 管理工作技术化

• 需求失真，不透明，太抽象，需求管理混乱：明确唯一入口、团队共商共建、可视化、数据化等
• 代码质量差：代码扫描自动化、在CI环节限制、评审策略化等
• 测试反复，人力资源缺失：测试自动化、采用高效工具RobotFramework，Postman等
• 版本零散、分支混乱、发布环境不一致：明晰的管理策略（代码、分支、环境）
• 流程臃肿、数据繁杂，难以查看：可视化流程和数据
• ......

11 - 20

11 - DevOps和Agile

如果说Agile是内功和心法的话，那么DevOps则是力量与招式。
Agile描述了一套价值观，却没有显式的把方法论体系化，而DevOps定义了一套方法论，把价值观蕴含在其实践中。

12 - DevOps标准与认证

《研发运营一体化（DevOps）能力成熟度模型》

• 由工信部直属单位中国信息通信研究院牵头
• 云计算开源产业联盟、高效运维社区和 DevOps 时代社区联合发起
• 携手国内互联网、电信、金融等行业领先企业百余位专家共同编制
• 全球首个 DevOps 标准，已在联合国直属标准化组织 ITU-T、中国工信部、中国通信标准化协会(CCSA)正式立项。

13 - 九问DevOps

“问题”一定是着某种具体的“目的与需求”来提问的，关于答案，没有正不正确，只有“合不合适”。

1. 你对DevOps的理解是什么？
2. 你认为DevOps的发展趋势是怎样的？
3. 如果让你来组织或者引导一个DevOps项目的实施，你如何开展工作？
4. 你将如何去说服或引领关键人（例如决策者、管理者、最终使用者、反对者等）赞同并支持建立DevOps机制？
5. DevOps项目的实施后，落地了工具和方法，如何去评价DevOps的成效？
6. 你获取和更新DevOps信息的途径和方式有哪些？最常用的是什么？
7. 一套DevOps系统建立后，你认为如何保证这套系统的健康稳定的运转？
8. 你在实施或运维DevOps过程中，遇到最大的困难是哪方面的？如何解决的？具体的方法是怎么？
9. 你在推动和建立DevOps的过程中，投入最多精力和时间的是哪方面？为什么？

14 - CI Pipeline

15 - 限制信息流动的因素

• 权责过于分明：不愿轻易踏足其他领域
• 流程繁琐：漫长的处理和反馈
• 严格的安全限制：担心违规，限制分享
• 精细的权限管理：一些基础操作 花费额外精力

16 - 问题产生的因素

所谓“难度”：

• 稀缺性 ---》 资源限制 -----》 开源共享
• 规模性 ---》 数量庞大，量变引发质变 -----》 标准化
• 重复性 ---》 产出低效 -----》 自动化
• 特殊性 ---》 全新未知 -----》基于标准的定制化

17 - ITIL(information technology infrastructure library， 信息技术基础架构库)

• 贯穿软件生命周期的大型框架，用以管理复杂变更
• 很多大型成熟企业采用的一种实践
• 某些ITIL描述的实践可以直接转换成相对应的DevOps实践

18 - 周期性的迭代

• 看板： 短周期，一般24小时，也就是一天，每日站会
• Scrum：一个sprint周期大概2到4周
• SAFe（Scaled Agile Framework，大规模敏捷框架）：多个Scrum Sprint

19 - 滚动升级

• 避免让最终用户停机
• 极低的停机时间
• 国际企业可能并没有合适的时间窗口来处理升级，滚动升级可能是唯一的选择。

20 - 大规模部署

- 服务日志：统一搜集日志，快速针对某个业务问题定位到具体日志
- 服务监控与健康检查：自动化获取数量众多的实例运行状态
- 服务网络：避免网络复杂化和管理琐碎化，有效管理IP、端口等资源在满足服务隔离要求下实现服务互通

- 服务发现：自动化探测服务并加入集群，及时剔除不可用的服务
- 服务调度与编排：根据优先级和使用策略调度资源，编排和定义服务，实现定制化服务部署和可控频率的滚动更新
- 服务自动伸缩：自动的资源伸缩能力，应对性能问题

- 负载均衡：切换平稳，不影响业务运行，终端客户无感知
- 微服务支持：简化传统集群的部署结构，降低部署成本

- 数据存储：采用网络存储来应对容器实例非持久化

21 - 30

21 - DevOps的6C周期

- Continuous Business Planning    持续经营计划
- Collaborative Development    协作开发
- Continuous Testing    持续测试
- Continuous Release and Deployment    持续发布与部署
- Continuous Monitoring    持续监控
- Collaborative Customer Feedback & Optimization    协同客户反馈和优化

22 - ChatOps

所有操作和处理都会通知到即时通讯工具，可以通过聊天工具来追踪、确认和推动DevOps全链路的状态。
一些常见工具

• Slack：https://slack.com/
• 企业版微信：https://work.weixin.qq.com/
• 钉钉DingTalk：https://www.dingtalk.com/
• 微软Teams：https://docs.microsoft.com/zh-cn/microsoftteams/teams-overview
• Cisco Jabber：https://www.cisco.com/c/zh_cn/products/unified-communications/jabber/index.html
• 华为云WeLink：https://www.huaweicloud.com/product/welink.html

23 - 镜像仓库规划

如果在公司或组织内部进行基于容器的私有云建设，那么往往同时也需要建立一个私有的镜像仓库。
镜像仓库是容器化的关键组成部分，如果镜像仓库服务异常，那么就无法发布和部署新版本。
一些镜像仓库规划的建议

• 除了建立容灾备份、实现负载均衡外，还需要建立集群，防止镜像服务异常
• 利用Jenkins任务自动化清理旧版本镜像，节省存储空间，简化管理
• 基于简单可靠的原则，测试和生产环境可以共用一套镜像仓库
• 如果测试和生产环境分别建立了镜像仓库，就需要特别关注“复制规则的制定”

24 - CheatSheet - devops-tutorial

https://intellipaat.com/blog/tutorial/devops-tutorial/

• DevOps Tutorial – Learn DevOps from Experts
• Ansible Tutorial – Learn Ansible from Experts
• DevOps and Agile
• DevOps Tools
• Introduction to DevOps
• Jenkins Tutorial – What is Jenkins?
• Docker Tutorial for Beginners – What is Docker?
• Puppet Tutorial
• A Thorough Guide to Basic Git Commands and the Command-line Interface
• Git Tutorial - Learn Git
• Docker Cheat Sheet
• Chef Cheat Sheet
• GIT Cheat Sheet
• Ansible Basic Cheat Sheet
• Jenkins Cheat Sheet
• Kubernetes Cheat Sheet
• Puppet Cheat Sheet

25 - Check List for DevOps

• 核心需求是什么？
• 当前公司的现状如何？是否具备实施DevOps的基础？
• 基本架构图和演进路线图如何？
• 需要耗费多少资源：人、时间、硬件、软件等？
• 用什么工具？当前业界主流使用什么工具、方法？优势和劣势是什么？
• 后续维护需要多大的成本？
• 如何降低开发适应性问题？
• 如何实现容器化？选择什么容器管理的工具？指定怎样的管理策略？

26 - 构建个人本地开发环境

在个人计算机中搭建一个精简版的、与生产环境基本一致的本地开发环境，既不会占用团队公共环境的资源，也可以缩短等待时间，从整体上提高效率。
一般包括Git、开发语言、IDE、VirtualBox（Docker）等工具。
本地开发环境的适用场景：

• 从应用程序开发的初期到单元测试阶段
• 原型开发
• 对风险或影响较大的变更进行前期调查
• 确认需要完全独占环境的工作内容

27 - DevOps 杂谈

# 1 - 趋势
随着技术的发展, 基础设施和应用程序之间的界限会变得越来越模糊, "服务"管理也将变得更加全面和简单。
便捷地搭建包含交付流水线的研发协作平台，可以快速实现商业价值。



# 2 - 结构与组织

## 2.1 关注点分离： 分开考虑系统不同的方面
- 内聚原则： 内聚（各部分之间相互关联的程度），单模块内的高内聚是可取的
- 耦合：模块间相互依赖的程度，要实现模块间的低耦合。
- 高内聚低耦合的系统自带关注点分离，反之亦然。

## 2.2 微服务
- 可以简单地将每个微服务视为一个隐式的三层架构（表示层、业务层、数据层），
- 但通常是指业务层，包含有许多小的服务组成，彼此之间使用语言无关的协议来通信
- 适用于持续交付：部署小型独立的服务

## 2.3 康威定律
- 设计软件的组织结构等价于软件的组织结构
- DevOps的主要目标是与不同的角色共同协作，最好是一个跨职能团队。
- 微服务模式正好密切反映了跨职能团队

## 2.4 服务组合使用
- 不盲目推崇某个工具和服务的优点, 而是使用不同的工具和服务来提高自动化程度和效率是当前的主流趋势
- 因此一整套的CICD环境必然包括多种工具和服务, 涉及不同的组合和集成方法



# 3 - 流水线
流水线是DevOps的核心，实现持续交付的核心在于Pipeline。
通过自动化流水线，让需求小批量流转，实现软件短周期的频繁交付，
把Jenkins作为基础设施，而不是操作管理界面，这是研发协作平台集成流水线技术的重点。

发布计划的管理： 在持续交付模式下，发布操作仍然是一个严肃的事情，需要非常审慎的对待
- pipeline的运行结果
- codereview的结果
- 发布窗口
- 人工检查的结果等等

## 3.1 分支管理/开发流程/环境
- pull request机制: 代码审核之后再进行后续操作
- 制定分支的运用策略: 对应环境/合并规则等
- 开发流程与分支相对应

## 3.2 自动化测试
要实现Pipeline，重点之一在于自动化测试
- 一切皆可自动化！
- 高效的自动化测试能够使部署变更有更好的质量。
- 规范的测试流程和粒度: 包含必要的测试类型和合理的测试顺序
- 例如: 静态测试--->>构建--->>础设施配置--->>应用程序部署--->>环境验证--->>单元测试--->>集成测试--->>系统测试

## 3.3 蓝绿部署
- 使用标签名来区分蓝绿环境, 实现更灵活/安全的机制
- 积极使用云计算环境中类似AutoScaling的功能, 灵活安全地调整服务器数量等资源
- 只适用于状态服务器
- 新版本的应用程序在部署和使用前, 需要在内部/备用环境进行严密的测试
- 蓝绿部署的架构需要和CICD进行结合

## 3.4 错误处理
- 自动触发CICD任务开始执行, 如果执行失败, 得到的不应该仅仅是一个通知
- 例如, 在生产环境, 必须及时发现的错误, 因此采取自动回滚等错误处理措施是极其重要的

## 3.5 及时通讯工具
- 来自CICD的信息应该被合理的展现和存放, 便于追踪关联信息
- 例如, 在teams或者Slack中, 应发送到对应的频道



# 4 - 云化环境
内部云化的工具平台，包括内部的开发工具链平台，测试工具链平台，安全工具链平台，运维工具链平台等，将各种标准化技术平台的能力输送给各个业务线团队，提升团队整体质量和效能。
在使用云服务的情况下, 自动化服务器的构建和销毁, 将使得DevOps架构更为简洁，也就是实现了不可变基础设施的环境
可以简单地批量创建或销毁基础设施, 并实现不可变基础设施和蓝绿部署
- 快速简单地进行不可变基础设施的创建和销毁
- 在不影响正常服务的情况下进行发布操作
- 能够将整套基础设施回退到正常版本, 及时处理故障
- 操作简洁, 通过命令行或API方式方便与其他工具和服务集成



# 5 - 资源管理

## 5.1 建立公司或大部门级别的标准应用库
以标准化应用为中心，是整个研发协同活动的基石，
应用信息可以直接对应一个服务，一个代码库，一个环境，一条流水线，一个监控job,一个质效数据。

依靠应用这个维度，串联整个研发协作过程，代码、资源、流水线、监控、运维、故障、质效等等都是围绕着应用维度来开展，
开发、测试、运维、安全等等技术团队也就可以在各自平台上去定义它的应用，并实现无缝的衔接。

应用有了标准库，也就有了生命，有了生命周期的管理。
应用不再只是一个干瘪的代号或标识，而是一个活动集合一个工作系列。无论是新建和停用，都会影响到一系列的工作环节，当然这个过程我们需要各种自动化串联。

## 5.2 容器化的资源管理
使用容器，让各套环境配置、软件包、资源类型等保持一致。
软件包管理、目录管理、基线变更、运维脚本等等通过一个dockfile就可以规范解决，再通过分布式配置中心实现对不同环境的配置管理，基本实现了环境的标准化以及运维服务的下沉。




# 6 - 监控
“如果你不能度量它，你就无法改进它。”
围绕应用，建立一站式监控管理，包含多维度立体式的监控体系，并且通过统一的报警设置，建立共同的响应机制。
- 通过监控服务并在问题发生时采取适当的行动来缓解服务宕机的影响
- 针对不同的应用程序来提供监控接口，全面了解当前系统的健康状态
- 使用的监控软件类型不同，监控的结构也有所不同

## 6.1 度量管理：DevOps仪表盘
建立快速和持续的从右到做的反馈尤为重要，通过建设质量和效能的数据看板，让整个交付过程更加透明，暴露出瓶颈点并持续改进。
列举一些常见的度量点，这些应该在应用的维度下系统展示，而不是在一个个内部平台上去跳转，去人工采集。
- 项目进度和风险大盘
- 需求完成率
- 项目及时率
- 代码静态分析结果
- 流水线执行频率、时长和成功率
- 发布执行频率、时长和成功率
- 监控报警频率和趋势
- 线上故障情况统计等

## 6.2 可视化
- 利用KLK或者EFK技术栈可以方便, 实时地对数据进行可视化
- 通过Logstash或者Fluentd采集服务器的syslog/资源占用状态等指标, 在同一个时间轴上实现可视化, 就可以掌握系统的整体和详细状态.