随着微服务及容器化技术的普及至大众视线后DevOps常被提及，关于DevOps似乎并没有一个标准的定义，如果说从基于目标导向去给它做一个定义，DevOps是一套实践方法，即在保证高质量的前提下，缩短系统由变更、提交、部署更新到生产环境的时间，DevOps的核心由此可见体现在“保证高质量”, “缩短时间”，“部署”。

如上图，传统开发和运维之间存在一堵墙，开发人员想改变而运维人员想要稳定。另外，传统开发工具与运维工具也存在一堵墙，并没有打通成为一条工具链。

从字面上来理解DevOps ，Dev（开发人员）+Ops（运维人员），DevOps 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

软件开发演变：

缓慢而繁琐的瀑布模型演变成敏捷，开发团队在短时间内完成软件开发，持续时间甚至不超过两周。如此短的发布周期帮助开发团队处理客户反馈，并将其与bug修复一起合并到下一个版本中。

虽然这种敏捷的SCRUM（迭代式增量软件开发）方法为开发带来了敏捷性，但它在运维方面却失去了敏捷实践的速度。开发人员和运维工程师之间缺乏协作仍然会减慢开发过程和发布。DevOps就是基于对更好的协作和更快的交付的需求而产生的。

从2009年提出DevOps的概念，时至今日已经有十余个年头，在此之前DevOps为什么没有迅速走红，总结主要原因为以下几点：

● 之前的云计算还属于小众产品，虚拟化、虚拟机还是重量级的IT基础设施。

● 容器相关技术（Docker为代表）没有横空出世，导致DevOps无法迅速走红。

● Micro Service即微服务尚未广泛的推广使用。

DevOps开始深入人心，和云计算、容器/Docker、微服务、敏捷等相关概念和实施的发展离不开，互联网迅猛的发展，需要更快的业务试错与业务创新，让软件的生产、交付、获取、升级变得自动，DevOps在传统企业也开始备受关注开始走红。

对DevOps的狭义理解：

简单说DevOps是提倡开发和IT运维之间的高度协同，在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。

DevOps不仅需要打通开发和运维之间的隔阂墙，更需要从应用的全生命周期考虑，实现全生命周期的工具全链路打通与自动化、跨团队的线上协作能力。

纵向集成，打通应用全生命周期（需求、设计、开发、编译、构建、测试、打包、发布、配置、监控等）的工具集成，最终实现自助化。

例如：项目组的开发人员可以通过DevOps的平台上，自主申请开通需要的各种服务，比如开通开发环境、代码库等。

横向集成，打通架构、开发、管理、运维等部门墙。横向集成中DevOps强调的重点是跨团队的线上协作。

例如：传统的系统上线部署方式，通过一个发布手顺文档，上百页都有可能，但在DevOps的平台下，应该是通过标准运行环境的选择、环境配置的设置、部署流程的编排，实现数字化的部署手册，这样的手册，人机都能够执行，并且过程可以被追踪和审计。

我们使用DevOps时，大致有这几种误区认知：

● 企业没有使用云相关产品（IaaS、PaaS），无法开展DevOps；

● 微服务架构开发的应用适合DevOps，传统SOA应用不适合；DevOps的实施和应用架构无关，无论是微服务架构，还是SOA类型应用，都可以开展DevOps工作；

● 自动化工具的运用等同于DevOps的成功；采用自动化工具本身不是DevOps，只有将这些工具与持续集成、持续交付、持续的反馈与优化进行端到端的整合时，这些工具才成为DevOps的一部分；

● DevOps不仅仅是自动化。自动化是DevOps非常重要的一部分，但不是的部分，实施DevOps需要从敏捷、持续、协作、系统性、自动化多个维度进行建设与改进。

逻辑架构整个DevOps平台分为三层：

设施层：包括IaaS，CaaS，一般是基于OpenStack和Kubernetes、Docker；

服务层：服务管理与调度的基础能力，如注册中心，编排，以及企业级或互联网式的云服务；

DevOps层：更多的是工作流程需求、设计、开发、测试、发布等，看板等；

实施DevOps的核心目标是加速企业IT精益运行，提升IT的生产效率，加速部门、企业的业务创新能力。实施DevOps需要从组织、技术、流程三个维度进行。

可以梳理出目前团队中欠缺但又容易改进的点，逐步将更多的实践活动纳入团队当中。团队实施DevOps的目的在于，将重复、价值低的事情交由DevOps平台实现。在传统企业中，技术方面的实践最容易在团队中实现、流程次之、组织的优化与变革艰难。

1、技术方面

● 集成工具链：

打通应用开发工具链：需求、项目、代码、构建、测试、打包、发布、配置、监控；

● 基础设施即编码：

将基础环境服务化、可编程化，基础设施让项目团队可以自助获取；让基础设施从物理机、虚拟机、走向容器；

● 一键编译、测试、部署：

开发人员可以从代码开始，一键获得可访问的环境，根据需要可以推送开发、测试、预发、生产环境；

● ChatOps：

项目团队成员将沟通、工具和过程整合在一起。将工具植入对话中，保障团队能够自动执行任务与协作。推荐最近比较流行的hubot。

2、 流程方面

● 看板：

在DevOps中看板不仅是任务协调沟通的机制；也可作为管制平台，量化组织生产能力的工具。

● MVP：

采用MVP（Minimum Viable Product最小可行产品）原则，最短时间内快速交付产品原型，然后通过测试并收集用户的反馈，快速迭代，不断修正产品，适应客户的需求。

● 发布：

建立持续发布机制，形成自动化、自助化，支持常见的灰度发布、金丝雀、蓝绿、回滚、A/B测试等；

● 软件度量：

通过软件度量（包括过程度量、质量度量、用户度量、成本度量），推算出组织的各种有效指标；可以掌控组织的生产力水平，也可通过度量数据，反向优化组织瓶颈点；

● 一切皆代码：

文档（用户场景、功能特性等）、配置（应用配置、环境配置、脚本等）、环境（基础设施、中间件环境等）、发布包需要统一看待成代码，纳入版本管理，提供全视角的链路追踪。

例如：每个发布的版本，可以追溯其对应的配置，代码、文档，发布的功能点。

组织、技术、流程三个维度中，技术、流程可以通过平台或者工具进行实践的固化。

平台建设步，梳理出DevOps的整体模型。从角色、规划设计、开发交付、运营反馈四个维度进行梳理。以产品为核心，将代码、配置、环境进行严格分离，同时覆盖产品全生命周期。

另外企业在落地DevOps也存在如下困境：

关于DevOps工具选择，按照阶段进行拆分，将其分解到各阶段分别是：规划、构建、持续集成、部署、运营以及持续反馈。

1) 规划

视觉与设计方面达成协作，推荐使用的工具：Confluence， HipChat，JIRA Software。

2) 构建

开发阶段环境构建，推荐使用的工具：Docker。

基础设施自动化，推荐使用的工具：Bamboo， Bitbucket， Chef，Docker, Puppet。

3) 持续集成

它是支撑新功能的代码与当下代码集成的环节。软件在持续性开发，升级后的代码必须持续性集成，并快速地与系统集成，实现用户的各种需求变更。变更后的代码，还应当保证执行时环境中沒有异常。推荐使用的工具：Bamboo， HipChat。

自动化测试，对于准备和支持开发构建工作，自动化测试的操作过程透明化以及性是非常重要的。推荐使用的工具：Bamboo， Bitbucket，Capture for JIRA。

4) 部署

发布仪表盘，在一个地方对于你想寻找的关于分支，构建，拉请求和部署警告等信息提供高可视化。推荐使用的工具：JIRA Software。

自动化部署，推荐使用的工具：AWS， Bamboo， HipChat，Puppet。

5) 运营

监控，实施自动化监控针对服务器监控和应用程序性能监控，推荐使用的工具：BigPanda，HipChat，HostedGraphite，Nagios，NewRelic，PagerDuty，Pingdom，Splunk。

沟通与集群，跨团队沟通是实现文化转变的步，工具可促进它的实时性。推荐使用的工具：BigPanda，DataDog， HipChat，NewRelic， PagerDuty，StatusPage。

事件、变更和问题跟踪，推荐使用的工具：JIRA Service Desk，JIRA Software

6) 持续反馈

通过用户反馈创造更好的产品，推荐使用的工具：GetFeedback，HipChat，JIRA Service Desk，Pendo，Surveymonkey，HootSuite。

在实践DevOps时，可以从运营效率、IT服务水平、组织效能、客户价值、经营业绩五个维度进行评判，持续优化与改进。

1、从原先线下协作、沟通，统一到DevOps平台上协作、沟通；可以随时了解项目进展全貌，利用平台可以做到各种过程数据的实时收集；

2、 资源管理由原来专职人员，过渡到开发人员实现自助化服务，可按需实现各类环境申请与开通，基础设施即服务提供来技术的支撑；

3、由邮件文化到DevOps平台统一沟通，同时DevOps打通多个工具链路端，任务分发、沟通、提醒可以实时推送。