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的阶段

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