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