DevOps - 随想札记

---

1 - 趋势与本义

随着技术的发展, 基础设施和应用程序之间的界限会变得越来越模糊, "服务"管理也将变得更加全面和简单。
通过实施DevOps可以便捷地搭建包含交付流水线的研发协作平台，可以快速实现商业价值。
在这一过程中，反对将DevOps绝对理论化、模型化，而是坚持DevOps的实践性和灵活性。

明确“DevOps具体能做什么？或者应做什么？”是成功实施DevOps的一个必要前提。
DevOps就是应对产品研发、交付、运维过程中各团队（开发、质量、运维）交汇处的工作，让各团队能集中精力做自己的主业。

---

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/资源占用状态等指标, 在同一个时间轴上实现可视化, 就可以掌握系统的整体和详细状态.

---

7 - 如何开始 DevOps 征程？

开启DevOps征程并非易事。从哪里开始? 什么时候开始? 如何开始? 与哪些人同行?

• 一定先要组建在主观意愿上愿意尝试 DevOps 实践的团队，并将这个团队树立为一个榜样
• 从简单的业务或者服务的价值流开始入手
• 允许失败，让团队在失败中学习和探索
• 为团队指派 DevOps 教练来协作团队的建设
• 需要企业的管理层绝对的支持
• 让成功的团队用结果来影响其他的团队

---

8 - DevOps实践要素

• 理解组织与业务、技术与运维的情境
• 研究确定什么样的技术决策和路径能够实现DevOps目标？
• 任何实施都必须适合客观的组织文化氛围
• 知识转移和技能传递是采用任何新技术新工具的必要步骤
• 将所做的事情描述为一个清晰的端到端的“过程”，就能够知道此刻在做什么？
• 在“过程”中，理解、认知、行动和改善
• 任何新事物的创造，都是为了解决固有的问题，满足新的需求
• “应运而生”，迎接挑战，也就应当“顺势而为”
• PoC试点项目：验证可行性、费用成本、目标和步骤
• 先锋小组&探险小队：专职，关注转型和适配
• 实时反馈
• 模块化、标准化、自动化--》集中汇总 --》持续演进

---

9 - 九问DevOps

“问题”一定是着某种具体的“目的与需求”来提问的，应该关注实际结果和状态的“合不合适”，而不应在观点形式上争论“答案的正不正确”

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

---

10 - Check List for DevOps

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

---

11 - 业务案例

实施DevOps实践需要管理层认同，相应地，需要一个领军人物来说服管理层DevOps实践是有益于组织的。
通常通过创建业务案例的方式说服管理层，业务案例包括成本、收益、风险和风险减缓、推出规划和成功标准。
管理层希望看到对风险和风险缓解的枚举、初始推出计划和项目的成功标准。

业务案例必须在以下4个方面说服管理层:

1. 存在一个正在发生严重影响的真实问题
2. 解决问题的方法是合理的、合规的
3. 解决问题所带来的好处大于成本
4. 干系人不会过于失望

引入 DevOps 的业务案例的组成部分

问题
- 为什么对组织来说引入 DevOps 实践是有好处的

成本
- 引入DevOps实践的预期成本（费用与时间）是什么？
- 一次性成本：工具引入、人员培训、现有系统改造（兼容和替换）
- 持续性投入：系统维护与升级

干系人影响
- 对内部和外部干系人的影响是什么
- 内部：日常需求、事故处理与业务恢复、变更部署、基础设施
- 外部：正式发布（业务相关人、管理层相关人）

风险和缓解
- 与引入 DevOps实践相关联的组织和技术风险是什么？
- 如何减缓这些风险？

推出计划
- 推出 DevOps 实践的计划是什么
- 依赖组织的影响力和最终目标
- 大规模的一次性交付隐含的错误和抵触更多，采用分阶段针对性的增量交付更可行


成功标准
- 如何知道 DevOps实践的引入是成功的？
- 基于推出计划和采用的理由：客观数据、相关人的满意度
- 可度量的成功标准：获取足够的客观数据支持，避免“自卖自夸”
- 关注引入DevOps前后可以收集的指标，包括在引入DevOps前和引入DevOps后的各种指标
- 减少开发、测试、部署、问题恢复的时间和费用

---

12 - 技术管理者的素养

关注IT和业务之间的紧密关系。
从技术实现接入业务战略，将创新引入业务，将业务需求与技术进行一致性整合。

• 落实真正的管理创新，通过IT创新让商业模式与时俱进
• 提高IT的投资回报率，如何帮助企业提高收益？
• 进一步扩大横向的业务影响，IT服务战略管理如何落地？

1. 落实真正的管理创新

• 拥有敏锐的洞察力的梦想家，富有远见地促进落实各种技术性工作，帮助企业从技术方案落地中收益
• 能力全面的实干家，通过IT解决方案处理和解决各种实际的业务问题

2. 提高IT的投资回报率

• 价值创造者
• 持续关注IT成本的降低和工作效率的提升，通过不断发现新的方式使业务受益
• 通过提升IT工作效率来不断消减不必要的成本开销，以达到IT投资回报率的提升

3. 扩大横向的业务影响

• 业务和技术的双料专家
• 扮演协作型业务领导的角色，与企业其他管理者通力合作，推动实施新的业务方案和文化转变
• 扮演激励型IT经理的角色，在IT职能中发挥核心作用，激励IT组织的发展并实现卓越的IT绩效

---

13 - 安全可靠和合规运行

推动内部IT运维服务和设施标准化、可视化、容器化、资源池化
充分运用分布式、自动化、云计算、智能化等手段，构建DevOps体系
打通从需求分析、编码、构建、测试到发布、部署、运营、监控的全生命周期敏捷产品研发
快速变更、快速交付，降低故障修复耗时，提高资源利用率，助力金融企业数字化转型

• 对于研发，通过企业级开发框架、脚手架和代码生成工具、统一封装的各类组件库来统一开发标准，提升开发效率
• 对于测试，通过提供统一的自动化测试框架，提高代码单元测试覆盖率，提高自动化测试用例占比，提升质量团队的执行效率和质量保障水平
• 对于运维，通过构建自动化装机、自动化发布、自动化巡检、全链路监控、CMDB等系统建设DevOps体系，提升运行保障的效率和水平

---

14 - 实践中的组织风险

组织壁垒是客观存在的，两个组织单元各自拥有不同的使命、不同的文化和不同的激励。
想让不同的组织单元联合起来意味着至少理解对方单元的使命、文化和激励。
不同的报告链是一个壁垒，物理距离也是另一个壁垒。

新角色的创建会在组织内部造成压力，必须为这个新角色配备职员、宣告新角色和制订报告路径，
调整各组的关键业绩指标（Key Performance Indicator， KPI）可以有效减缓这些压力和风险。

---

15 -