如何理解DevOps

引言

• DevOps是一种重要的软件开发模式；
• 我所在的团队正在进行DevOps转型；
• DevOps极大地提升了开发效率；
• 本文介绍了我对DevOps的理解；

什么是DevOps

• DevOps是一种软件开发人员（Research and Dev，RD）和IT运维运营技术人员（Ops）和质量检测（QA）之间沟通合作的模式；
• DevOps的根本目的是快速频繁的、小步的、自动化便捷的监控和审计的、云端和虚拟化的、可视化的部署，满足“每天部署10次”或者“快速解决bug并上线”的要求；
• DevOps是敏捷开发、持续交付的基础；
• DevOps模式和传统的瀑布模型相对应；

我们需要维护什么？

• 以我所在的团队为例，我们需要维护的内容如下：
  • 需要维护的环境分为：开发环境，测试环境，准生产环境，生产环境；
  • 每个环境包含若干个scope，每个scope都是整个系统的一部分，由不同的团队进行开发；
  • 使用microsoft微服务架构，每个scope中都有若干service，每个service之间可能还存在相互依赖关系；
  • 每个service都需要若干resource，这些resource包括但不限于：

• RabbitMQ；
• Service Fabric；
• IoTHub；
• EventHub；
• ELK；
• Consule；
• KeyVault；
• MongoDB；
• Postgresql；
• Cassandra；
• Storm；
• Redis；

如果没有DevOps，我们怎样工作？

• 没有流水线Pipeline：
  • 开发过程变得非常痛苦，会经常忘记对代码进行单元测试和集成测试；
  • 开发完成的服务，打包后不知道放在何处，别人需要引用时很不方便；
  • 代码质量得不到保证，很多代码没有经过“单元测试覆盖率检测”和“代码重复率检测”，代码可维护性变差；
  • 随着开发的深入进行，开发人员的主要精力不在是编写新的代码，而是处理bug和维护旧的代码，使开发效率逐渐降低；
• 没有自动化环境部署：
  • 在开发者完成一个微服务的开发后，不知道将自己开发的服务部署到什么环境上去测试；
  • 开发者在测试自己的代码时，会时常发现所依赖的资源没有准备好，比如测试环境缺少MongoDB等资源；
  • 运维人员不能显式的看到自己维护了多少资源，每种资源都在被哪些环境、哪些service引用；
  • 运维人员不能显式的看到资源的使用情况及使用量；
  • 经理不能有效的进行成本控制；
• 没有自动化监控系统：
  • 运维人员不能在机器、硬件、软件出现故障时得到及时的警告，导致机器挂掉了都还不知道；
  • 不能灵活调配各种资源的使用，导致某些资源极度紧缺、某些资源却有富余；
• 手动，而不是自动：
  • 从下面的图片可以看出，只需手工运行5条命令的情况下，成功部署的概率就已跌至86%，如需手工运行55条命令，成功部署的概率将跌至22%，如需手工运行100条命令，成功部署的概率将趋近于0（仅2%）！

为什么要有DevOps

• 不知道目前发布、部署的进展情况；
• 没有一套明确的发布、部署流程，急上线时容易出问题，出了问题也没有预案来解决；
• 自动化程度不够；

DevOps工具链

• 编码：代码开发和审阅，版本控制工具、代码合并工具；
• 构建：持续集成工具、构建状态统计工具；
• 测试：通过测试和结果确定绩效的工具；
• 打包：成品仓库、应用程序部署前暂存；
• 发布：变更管理、发布审批、发布自动化；
• 配置：基础架构配置和部署，基础架构即代码工具；
• 监视：应用程序性能监视、最终用户体验；

DevOps的多维度目标

• 团队维度：拟合开发和运维的鸿沟，支持位于全球多个地点的、包含外包人员的、混合开发/测试/基础设施的团队；
• 技术维度：拟合多类型的分布式的硬件平台和上面部署的多种应用、多种需求的鸿沟；
• 需求维度：平衡软件开发过程中对软件用户需求变化、追求稳定性、追求开发效率、降低check-in风险这几个目标；
• 市场维度：解决软件迭代慢和较高的用户需求的矛盾；
• 终极目标：从时间和空间两个维度，合理统筹并高效使用现有资源，实现组织目标，最大限度满足用户需求；

DevOps需要遵循的基本原则

• 以人为本，一切工具都是为人服务；
• 需求细分，及时开发，及时验证；
• 减少开发的分支，尽量在主干上开发，避免合并分支造成的开销和时间浪费；另外，分支太多的时候不可能做到持续集成；
• 减少代码积压，代码积压越多、越多的需求和开发成果得不到验证、效率就越低、下次部署的风险就越大；
• 代码和配置相分离，尽量降低他们在逻辑或者物理上的耦合；
• 尽早生成二进制包，而不是使用源代码，并确保二进制包不被篡改；
• 二进制包应当和环境无关；
• 确保部署流程是幂等的；
• 对生产和测试环境的修改只能由程序，而不是人完成；

环境管理

• 环境必须遵循：快速部署和响应（使用docker或者其他虚拟化技术能够更容易做到这一点），可恢复，可支持，可审计；
• 环境配置项目：
  • 操作系统和配置；
  • 中间件和软件栈及配置：数据库，消息系统，队列；
  • 基础设施软件：代码管理，目录服务，监控；
  • 外部集成：外部系统和服务；
  • 网络：路由，防火墙，交换机，DNS；
  • 团队：开发团队和infra团队之间的协调分工；
• 自动化的环境部署；
• 测试环境应当和生产环境尽量一致；
• 环境的配置文件也应当进行版本控制；

监控

• 监控的内容：
  • 硬件，物理设备，路由器，代理；
  • 操作系统；
  • 中间件；
  • 应用程序；
  • 日志；
• 如何监控：
  • 清晰的信息展示；
  • 及时地告警；
  • 可视化的状态呈现；

常用DevOps利器

• Jenkins：开源的持续集成工具；

https://www.jenkins.io/

• SonarQube：开源的代码质量管理系统；

https://www.sonarqube.org/

• Puppet：开源的软件自动化配置和部署工具；

https://puppet.com/

• Docker：让应用程序布署在软件容器下的工作可以自动化进行；

https://www.docker.com/

总结：DevOps到底是什么？

• 高效的流水线开发/测试/上线；
• 自动化的环境部署和管理；
• 良好和及时的监控/告警/可视化/反馈/日志；
• 开发团队、运维团队、用户之间良好的沟通协作，快速解决问题的能力；
• 完整的文档；
• 任一模块的幂等和可恢复；
• 良好的审计和评估，良好的成本管理；
• 整个系统稳定且灵活，高度自动化；
• 总而言之，DevOps的核心只有三个词：高效、自动、监控；

参考

DevOps的真谛到底是什么？https://mp.weixin.qq.com/s?__biz=MzIzNjUxMzk2NQ==&mid=2247485035&idx=1&sn=d8dbc8e682dc9f634263b9ba1178daa9
持续集成是什么？http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html
持续交付概述 http://exceedhl.thoughtworkers.org/cd/cd.html
看板管理 https://zh.wikipedia.org/wiki/%E7%9C%8B%E6%9D%BF%E7%AE%A1%E7%90%86

source: //changsiyuan.github.io/2017/06/15/2017-6-15-DevOps