特别说明

本文是已读书籍的学习笔记和内容摘要，原文内容有少部分改动，并添加一些相关信息，但总体不影响原文表达。
《DevOps入门与实践》 ：本书结合实例详细介绍了在开发现场引入DevOps的具体流程。
- ISBN: 978-7-115-51256-7
- https://www.ituring.com.cn/book/2407

个人简评

适合已有实践经验的实施人员，对已有知识和技能做结构性梳理。
适合对DevOps欠缺了解的人员，能够建立起基本的概念。
缺憾是，因为外文书籍翻译引入存在时间差的原因，书中涉及的一些工具和方法的实例，落后于当前主流应用场景。
此外，书中最终实现的DevOps结构，仅满足于流程原理性演示，相对于当前主流业务需求，过于简单，不具备大的实用价值。

如何以DevOps为中心对架构进行变革，成功实施DevOps？

DevOps的核心要素

• 土壤---》组织---》人员的构建与培养
• 思想---》文化---》意识的形成
• 方法---》流程---》规则的建立
• 工具---》操作与配置---》自动化、智能化的演进

1 - 应用程序

1.1 借鉴已有的实践模式

在DevOps土壤上，将当前业务与DevOps思想、方法和工具结合时，最好参照已有的最佳实践模式来指导实践活动。
这将会实现规避掉一部分可能的问题，主要的时间和精力不应该花费在一个又一个问题上。

The Twelve-Factor App

• https://12factor.net/zh_cn/
• 软件通常会作为一种服务来交付，12-Factor 为构建如下的 SaaS 应用提供了方法论，适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。

    - 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
    - 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
    - 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
    - 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
    - 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

1.2 微服务

微服务架构是一种将单个应用作为一套小型服务来开发的方法。
微服务的9个特征：服务组件化、以业务功能为中心组织团队、做产品的态度、服务端点、分布式治理、分布式数据管理、基础设施自动化和容错和演进式设计。
每个小服务都以业务功能为单位来构建，采用自动化部署机制进行独立部署，并以独立的进程运行，不同进程之间使用轻量HTTP资源API等方式进行通信。
各个进程相互独立，因此在保持最低限度的集中式管理前提下，每个服务都可以采取不同的编程语言和存储来实现。
简而言之，微服务架构以业务功能为单位把一个大的服务拆分为多个小的进程，由这些小进程的集合构成一个完整的服务，可以轻松地对各个小进程进行功能的添加、修改和重复使用等操作。
对应的在组织架构上，每个单独的进程是由包含不同技能人员的一个团队来实现。

2 - 基础设施架构

2.1 不可变基础设施（immutable infrastructure）

顾名思义，其主要含义就是在基础设施构建完成后就不再进行任何变更。
如果想对环境进行操作时，需要先销毁现有的基础设施，然后再创建新的基础设施。
也就是说，能够舍弃原有的基础设施并可以从零开始重新构建出和原来一样的基础设施。

其主要优点

• 防止意外发生：保持干净状态的环境，从根源上避免错误的配置和操作
• 便于管理：不需要对已运行环境的配置和状态进行管理
• 强制实现基础设施即代码：代码的最新状态实时反馈到基础设施上
• 统一故障处理和配置变更的工作步骤：都归结为自动化的“重新构建”

需要特别关注的地方

• 一般情况下，不可变基础设施只适用于无状态服务器（不包含不断变化的数据或配置） ，不适用于类似DB这种有状态服务器。
• 特殊需求下需要保留基础设施，例如进行分析调查故障原因等
• 重新构建基础设施时，与服务器相关的监控等配置也需要进行对应的操作
• 选择工具和制定解决方案依据具体的实际的应用场景

2.2 蓝绿部署（Blue-Green Deployment）

蓝绿部署是为了解决传统发布方式的问题而出现的。

• 发布时需要暂停服务，影响可用性
• 发布失败后需要花费很长时间来修复

原理上，蓝绿部署是通过冗余来解决问题。

• 生产环境由蓝色环境和绿色环境组成，同一时间只能使用一个
• 在没有使用的环境中实施发布操作和业务测试，测试通过后通过DNS、负载均衡器、反向代理、路由等方式快速完成环境切换。
• 如果发生故障，也可以通过负载均衡器、反向代理、路由等方式快速回退到先前版本

蓝绿部署的切换速度快，即使发生故障，也能容易回退版本，几乎不影响用户的使用。
但也有一些限制，就是需要保持双重的基础设施，而且不适用于有状态服务器。

2.3 本地部署和云

DevOps的实现并不要求特定类型的环境，而是建议根据具体条件因地制宜。

本地部署

• 购入或租赁硬件资源，放置在数据中心，并自行负责维护，几乎所有的工作都在公司内部完成
• 自主性强，对设备和业务有完全的把控
• 需要投入足够的人力、物力、财力来构建和维护

公有云

• 由云服务提供商管理的云计算IaaS（Infrastructure as a Service，基础设施即服务）
• 可以快速获取资源、应对高负载
• 方便管理，当前主流平台都提供了API 、命令行工具、管理控制台等工具
• 必须按照提供商的规定和计划来构建和使用服务
• 故障处理只限于公有云平台的虚拟机层面

私有云

• 在本地部署环境中使用OpenStack等云计算平台实现不可变基础设施，
• 前提需要现在本地部署环境中构建一个IaaS的基础设施，实现有难度、也要花费时间和成本

2.4 软件即服务（Software as a Service，SaaS）

对于和服务不直接相关的非核心功能，可以选择基于互联网服务来实现，彻底削减非核心部分的成本。
例如，在持续集成范围，就有CircleCI和Travis CI等。
如果SaaS服务提供的功能越重要，就越需要在使用之前进行严密的验证并制定相应的应急计划（灾害、故障的应对计划）

SaaS的好处

• 服务器的运维基本由服务商负责
• 操作和配置直观简单
• 及时提供中间件等相关的支持

SaaS的缺点

• 无法对出现故障的SaaS服务进行控制
• 很难提供个性化定制
• 价格和服务由服务商设定

2.5 日志收集

在DevOps中，日志除了被收集和存储，还应该积极地用于分析。
在使用不可变基础设施的情况下，最为理想的方式是实时进行日志收集、处理和输出展现。
使用ELK技术栈（Elasticsearch、Logstash和Kibana）、可以快速完成日志的传输、分析和可视化（信息的数值化和图形化），有助于进行客观的判断。
通过持续地日志分析和可视化，认真地对现状加以思考和反省，通过迭代式的改进最终达到长期的目标。

• Elasticsearch：具有良好实时性和可扩展性的基于 JSON 的分布式搜索和分析引擎，作为 ELK 的核心，集中存储数据
• Logstash：动态数据收集管道，以多种方式收集和处理数据并以多种形式输出和传输，可以将数据导入到可视化工具中
• Kibana：ELK 的用户界面，汇总、分析和搜索 Logstash 和 ElasticSearch 提供的数据并将其可视化，并提供配置和管理 ELK 的界面

3 - 团队

3.1 敏捷开发（agile development）与DevOps

敏捷开发是一种通过改善开发方法和团队结构，持续对最终成果进行改善的方法。
开发成功与否并不在于是否按计划准时发布了服务，而在于服务的的开发是否能应对变化，是否产生了商业价值。
在以迅速应对变化为目标的敏捷开发中，计划、设计、开发、测试以及发布等相关工作均由一个小型团队完成。
通过在短期内不断重复这一系列的工作，接受外界对服务和产品的反馈，从而持续进行改善。
所有成员都要对服务和产品负责，需要理解彼此的业务，自然而然地就形成了DevOps所需要的模式。

3.2 Ticket驱动

在软件开发过程中使用JIRA、Redmine和Trac等缺陷跟踪系统或问题跟踪系统，以ticket为单位对问题、缺陷以及敏捷开发中的用户故事等进行管理的方法。
作为DevOps实践的一个良好补充，解决了文档式管理的信息分散问题，可以支持从瀑布开发到Scrum开发。
在DevOps中，通过ticket为单位进行信息共享以及任务管理，将会使内外部之间的协调变得简单，信息也更易于集中管理。

在具体实现上，就是所有任务包括代码改动都以ticket方式进行管理，与具体事项和相关人员进行关联，同步更新状态。
ticket中可以包含各类日期、负责人、详细内容和讨论记录等信息。
提供仪表盘功能(Dashboard)，可以从项目管理、工作量估算和进度管理等角度把握开发整体情况。

3.3 网站可靠性工程（Site Reliability Engineering，SRE）

基于Google长期的运维实践经验而提出，重点关注运维，可以说SRE是DevOps中运维的一个更加具体的描述。
虽然网站可靠性的下降并不会直接阻碍商业价值的实现，但受阻的风险概率大幅提高。
SRE团队要在资源有限的条件下保证SRE，技术难度很大，要求较高的改善技能。

提高SRE的主流方法与观点

• 系统优化：可用性、延迟与性能
• 监控：服务、容量
• 质量内建：自动化、变更管理
• 故障处理：恢复机制

3.4 ChatOps

针对各种任务，通过即时通讯工具来提高工作效率，确保团队成员都能够实时了解其他人的操作和系统当前的情况。
通讯工具可以所有类型信息做集成，例如CI&CD工具、Web服务等。
Slack（聊天工具，可集成第三方工具）和Hubot（聊天机器人）是实现ChatOps的代表性组合。

• 统一沟通方式，简化沟通渠道，降低编写和传递信息的难度
• 操作智能快捷，例如，只需要在通讯工具中输入一条指令就完成指定的工作或者获得特定的信息
• 过程和结果对所有人可见（实时可见、记录可见）
• 利于通知、查看和回顾，例如，关键信息即时发送、统一的时间线上显示所有相关信息、沟通记录保存等

使用ChatOps实现自动化与效率化

• 任务操作：应用程序构建与部署、测试、
• 系统资源查看
• 关键信息（重大变更、故障告警等）通知
• 定时提醒或操作

ChatOps的构成

• 用于沟通的聊天系统
• 从聊天系统中读取信息并执行相应操作的机器人系统

ChatOps的阶段

• 聊天工具接收通知，团队成员基于通知进行沟通（系统--》聊天工具--》人）
• 通过聊天工具下达操作命令，实施具体操作（人--》聊天工具--》系统）

DevOps - DevOps精要 - 变革

原文：https://www.cnblogs.com/anliven/p/11870155.html