我所了解的DevOps

2017/09/01

什么是DevOps

DevOps是一种方法论,是一系列可以帮助开发者和运维人员在实现各自目标的前提下,向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

进一步了解查看一下文章:

DevOps是一种文化,不是角色!

什么是(不是)DevOps,我们如何实现DevOps?

DevOps面面观

DevOps的真谛到底是什么?

龙门阵之 DevOps 门外汉须知

DevOps原则和方法

Everything Sysadmin 提出了帮助组织采用 DevOps 文化的5个里程碑。

该网站将这5个点置于三方法 (The Three Ways)的语境中,而三方法是由 凤凰项目(The Phoenix Project) 推广开来的一套原则。DevOps 社区的重要成员 Jez Humble 以及 CFEngine 创始人 Mark Burgess 均在 Twitter上指向了这些里程牌。

  • 第一方法(The First Way): 意味着思考系统的端到端流程,例如,考虑一次软件变更需要经历的所有步骤,从客户的初始需求一直到生产环境部署。正如Gene Kim等人在“凤凰项目”中所说的那样,这有助于避免局部最优和消除工作孤岛。
  • 第二方法(The Second Way): 增加了反馈回路,问题因此可以得到快速识别和纠正。一个典型的例子是使应用程序的生产日志可以随时提供给开发团队。
  • 第三方法(The Third Way): 意在培养一种不断实验以及通过反复实践达到精通的文化。Netflix的Chaos Monkey服务可以看作第三方法在实践中的一个极端示例。

查看文章:

对三种方式的重新解读

DevOps 工程师的工作内容

⽬前招聘DevOps工程师职位实际的工作内容主要有几类情况:

  1. 普通开发/测试/运维职位,只是希望应聘者具备DevOps技能

  2. DevOps相关工具和平台的研发⼈员

  3. 研发、运维、运营流程自动化和反馈机制的实施人人员

  4. 推进组织级效率提升和流程改进的专项⼈员(专家/Specialist)

DevOps 相关的场景

  • 管理项目的核心资产(代码)

  • 项目交付流程的管理和可视化

  • 质量指标的反馈和可视化

  • 部署过程自动化(虚拟机方式)

  • 部署过程自动化(容器方式)

  • 线上状况反馈和可视化(指标)

  • 线上状况反馈和可视化(数据)

代码管理与版本控制

什么是版本控制

你可以把一个版本控制系统(缩写VCS)理解为一个“数据库”,在需要的时候,它可以帮你完整地保存一个项目的快照。当你需要查看一个之前的快照(称之为“版本”)时,版本控制系统可以显示出当前版本与上一个版本之间的所有改动的细节。

使用版本控制的好处

1.协同合作:

如果没有版本控制系统,当你需要处理那些共享文件夹中的文件时,你必须告知办公室里的所有人,你正在对哪些文件进行编辑;与此同时,其他人必须要避免与操作相同的文件。

如果使用了版本控制系统,每一个团队成员都可以在任何时间对任何文件进行修改,版本控制系统可以把之后所有的改动合并成一个共同的版本,不论是一个文件还是整个项目。

2.历史记录:

每一次的改动都会提交一个版本进行记录,可以把一些文件恢复到任意的提交过的版本

3.记录变更信息:

每当你提交,都需要添加一个对这次改动的简短描述。除此之外,你还可以看到一个改动前和改动后的内容的详细对照。

4.备份:

备份是一个分布式版本控制系统(例如 Git)提供的非常好的附带功能。每一个团队成员都会在他的本地有一个完整的项目副本,包括整个项目的历史记录。如果你所依赖的服务器宕机了,或者是你的存储硬盘坏,所有你需要的恢复文件都可以在另外的团队成员的 Git 本地仓库中得到。

常用的版本控制工具

持续交付流水线

持续集成

持续集成指的是,频繁地(一天多次)将代码集成到主干。持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

持续集成的好处主要有两个:

  1. 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
  2. 防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

持续交付

持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

持续部署

持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

持续部署的前提是能自动化完成测试、构建、部署等步骤。

流程

根据持续集成的设计,代码从提交到生产,整个过程有以下几步。

  1. 提交

流程的第一步,是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交(commit)。

  1. 测试(第一轮)

代码仓库对commit操作配置了钩子(hook),只要提交代码或者合并进主干,就会跑自动化测试。

测试有好几种:

  • 单元测试:针对函数或模块的测试
  • 集成测试:针对整体产品的某个功能的测试,又称功能测试
  • 端对端测试:从用户界面直达数据库的全链路测试

第一轮至少要跑单元测试。

  1. 构建

通过第一轮测试,代码就可以合并进主干,就算可以交付了。

交付后,就先进行构建(build),再进入第二轮测试。

所谓构建,指的是将源码转换为可以运行的实际代码,比如安装依赖,配置各种资源(样式表、JS脚本、图片)等等。

  1. 测试(第二轮)

构建完成,就要进行第二轮测试。

第二轮是全面测试,单元测试和集成测试都会跑,有条件的话,也要做端对端测试。所有测试以自动化为主,少数无法自动化的测试用例,就要人工跑。

需要强调的是,新版本的每一个更新点都必须测试到。如果测试的覆盖率不高,进入后面的部署阶段后,很可能会出现严重的问题。

  1. 部署

通过了第二轮测试,当前代码就是一个可以直接部署的版本(artifact)。

将这个版本的所有文件打包( tar filename.tar * )存档,发到生产服务器。

生产服务器将打包文件,解包成本地的一个目录,再将运行路径的符号链接(symlink)指向这个目录,然后重新启动应用。这方面的部署工具有Ansible,Chef,Puppet等。

  1. 回滚 一旦当前版本发生问题,就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接,指向上一个版本的目录。

原文链接:http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html

持续集成发展史

SIT

SIT(System Integration Testing)系统集成测试,也叫做集成测试,是软件测试的一个术语,在其中单独的软件模块被合并和作为一个组测试。它在单元测试以后和在系统测试之前。集成测试在已经被单元测试检验后进行作为它的输入模式,组织它们在更大的集合,和递送,作为它的输出,集成系统为系统测试做准备。集成测试的目的是校验功能、性能和可靠性要求,配置在主设计项目中。

UAT

UAT(User Acceptance Testing)用户验收测试,通常是由最终软件的用户(通常这些用户不了解软件的具体逻辑,而对业务逻辑却相当熟悉)进行的测试,因此是面向最终用户的测试,结束之后通常就可以发布生产环境了。

扩展阅读: 流水线即代码

项目质量追踪

尽管软件的质量是⼀个很难量化的东西,但现实中我们依然会想方设法衡量它的好坏,从而尽早发现项目中的潜在问题,降低产品和代码腐化的风险。

静态质量验证

主要验证两类问题,安全问题和编码问题:

安全问题: 如:潜在安全漏洞、潜在内存泄露风险 编码问题: 如:代码风格问题、常见Bug代码

静态扫描的特点:

  • 外置扫描,侵入性较低
  • 无需额外开发量
  • ⼯具与代码语言强相关
  • 有些安全扫描可能需要专业技能

运行时验证

  • 探索性测试
  • 端到端测试
  • 集成测试
  • 契约测试
  • 接口测试
  • 单元测试

代码质量指标

戴明质量管理 十四条原则

  1. 持之以恒地改进产品和服务

  2. 采用新的观念

  3. 停止依靠大规模检查去获得质量

  4. 结束只以价格为基础的采购习惯

  5. 持之以恒地改进生产和服务系统

  6. 实行岗位职能培训

  7. 建立领导力企业管理

  8. 排除恐惧,使每一个员工都可以为公司有效的工作。

  9. 打破部门之间的障碍

  10. 取消对员工的标语训词和告诫

  11. 取消定额管理和目标管理

  12. 消除打击员工工作情感的考评

  13. 鼓励学习和自我提高

  14. 采取行动实现转变

软件活动结果可视化

直观&及时的反映项⽬健康度, 开源项目 https://github.com/capitalone/Hygieia

扩展阅读: http://www.infoq.com/cn/news/2016/04/hygieia

基础设施即代码

基础设施即代码1.0

通过脚本去进行自动化操作,可复用的脚本,可版本化管理。

缺点: 无法用于复杂的系统。

  • 脚本之间的关系和依赖难以管理
  • 复杂脚本的可读性差
  • 主机和配置之间的关联关系难以记录

基础设施即代码2.0

基于配置管理工具的自动化操作,并行的自动化操作,缩短操作执行时间。 基于状态(而非命令)的服务管理,易阅读,减少低级错误发生。 标准化的目录结构,便于管理和复用。

配置单独代码仓库和流水线

  • 统⼀权限管控
  • 操作审计
  • 方便查看执行历史的结果和时间
  • 避免部署代码的低级错误(写错服务器地址、弄错执行顺序、 …)
  • 加快批量部署速度
  • 易于追溯的部署过程日志

容器化运行环境

容器,是⼀种以镜像为单元的软件配置、运行和管理方式。 镜像,对软件运行环境的封装,但不包含操作系统。

容器创造了一种更加高效且可靠的软件交付、部署和管理服务的方式,以及⼀种基于轻量级环境镜像的发布流程。

容器镜像即代码

  • 透明的构建过程
  • 可重复的操作
  • 版本化控制
  • 代码级复用
  • 便于修改和定制

可视化性能和故障

基础设施监控

CPU、内存、磁盘IO、网络IO、存储空间等等

基础服务监控

数据库压力、缓存命中率、消息队列长度等

应用监控(APM)

用户行为、 API访问热点、性能瓶颈

合理展示数据

数值:

  • 告警个数
  • 超出安全范围指标数
  • 节点/容器/服务总数

曲线/直方图:

  • CPU负载曲线
  • 内存用量曲线
  • 磁盘IO曲线

数据表/热力图:

  • 节点连接数峰值/分布
  • 集群负载量峰值/分布
  • 节点容器个数峰值/分布

故障反馈和告警处理

  1. 提供有意义的告警命名和必要的错误信息

  2. 适量的告警(“狼来了”效应)

  3. 采用告警抑制(大范围告警抑制小范围告警,例如已经发生节点故障,在节点上的其他服务故障是必然的,无需重复告警)

  4. 采用告警聚合(合并同⼀时段内的重复告警)

  5. 多次采样,避免误诊(例如连续采样3次均发现,服务无法访问才判断服务真的不可访问)

  6. 区分告警线和恢复线,避免数值抖动,产生大量重复告警

分布式日志管理

  • 无管理:日志分布在各个服务器,需要分别登录查看(管理困难、 查找困难)

  • 集中管理:分开存储,通过Web方式集中查看或下载(查找依旧困难)

  • 集中存储:统一挂载NAS盘,集中存储到公共磁盘(单点故障、性能问题)

  • 分布式采集+集中存储:存储到数据库或搜索引擎中

云原生十二要素

  1. 基准代码 一份基准代码,多份部署

  2. 依赖 显式声明依赖关系

  3. 配置 在环境中存储配置

  4. 后端服务 把后端服务当作附加资源

  5. 构建,发布,运行 严格分离构建和运行

  6. 进程 以一个或多个无状态进程运行应用

  7. 端口绑定 通过端口绑定提供服务

  8. 并发 通过进程模型进行扩展

  9. 易处理 快速启动和优雅终止可最大化健壮性

  10. 开发环境与线上环境等价 尽可能的保持开发,预发布,线上环境相同

  11. 日志 把日志当作事件流

  12. 管理进程 后台管理任务当作一次性进程运行

原文链接: https://12factor.net/zh_cn/

提供合理的日志

  • 提供尽可能详细的错误原因
  • 包含日志时间和出现的位置
  • 包含其它与运行状况相关的信息
  • 以固定的标签形式展示日志信息

日志的采集和存储

日志的采集来源:

  • 日志文件:最常用的方式,通用性好,实时性较高
  • 日志数据流:需要输出日志的服务提供⽀持,实时性很高

日志的存储方式:

  • 全文搜索数据库:例如ElasticSearch,便于快速检索
  • 分布式文件系统:例如HDFS,便于大数据分析

日志的检索和分析

错误关键字检索:快速反馈潜在问题,每日生成线上错误报表等 错误信息统计:监控线上错误的发⽣频率 流量热点分析:关键调用处打印日志,快速统计流量和热点 出错内容告警:根据错误内容自动触发操作或告警 ⽤户⾏为分析:日志中包含操作用户ID 业务趋势观察:根据特殊日志打印频率反映业务变化趋势

问题持续追踪

项目看板

  • 管理工作计划
  • 可视化任务和人员情况
  • 识别工作流程瓶颈
  • 提供交付风险反馈

工作流的例子: 工作流有两种状态打开和关闭,一个问题该有如下属性

  • 描述: 关于问题的描述
  • 报告者: 表明是谁创建了这个问题
  • 指派: 这是应该在工作在这个项目上的人

细化适用于敏捷开发的状态,把打开和关闭细化为:

  • 打开: 问题被报告,暂未指派人在上面工作。
  • 进行中: 有人被指派到这个问题,正在尝试解决它。
  • 可以测试: 问题修复,现在需验证,又是未指派。
  • 测试中: 有人被指派上这个问题,正在测试。
  • 完成: 任务标记为已完成,再次未指派,完成状态用来标记问题,以持续跟踪他们。
  • 关闭: 这个问题不再被关注,留作记录,备日后参考。

还有一些其他的附加属性:

  • 到期日: 预期问题被解决的日期
  • 里程碑: 里程碑是一个将数个问题归并为一个较大工作包的解决方法。里程碑通常有一个到期日,如果你使用里程碑功能,一般不再使用单个问题到期日了。
  • 附件: 能够给问题添加截图和文档。
  • 问题量估计: 对解决问题很有帮助。

Post Directory