DevOps 从理论到实践
什么是 DevOps
DevOps 是一个流行词git
现在 DevOps 已经成为一个流行词，不少公司都在说本身在作 DevOps，可是每一个人、每家公司理解的 DevOps 又不尽相同，从 DevOps 诞生的第一天起，如何定义 DevOps 就是一个争论不休的话题。github
这里有一篇文章，笔者认为基本诠释了 DevOps 的定义：DevOps 是什么不是什么编程
若是你没有耐心把这篇文章看完，维基百科还给出了一个太长不读版：安全
概括成三点：服务器
DevOps 是一种强调沟通与协做的软件交付过程。它包括产品管理，软件开发及运营等各个方面。架构
DevOps 自动化软件集成，测试，部署以及基础设施的变动。框架
它的目标是创建一种文化和环境，使得软件的构建、测试、交付更快，更频繁，更可靠。运维
DevOps 的由来微服务
这里我想多提一句的是持续交付和 DevOps 的关系和差异，参照维基百科 对 DevOps 和持续交付的区别进行解释，DevOps 涵盖的范围比持续交付更宽，它包含了文化，强调团队协做和自动化；而持续交付侧重于频繁、快速 地执行交付流程，二者相辅相成，却又有所区别。工具
DevOps 理论框架
由于 DevOps 源自草根，缺少自上而下的理论支撑，因此如何定义 DevOps 成了 DevOps 社区里面的一个大难题。
一些 DevOps 从业者，纷纷设定本身的 DevOps 框架。其中比较有名的框架有Damon Edwards 所定义并被 Jez Humble（持续交付做者之一） 所修订的CALMS，和 Gene Kim 所定义的 The Three Ways。
The Three Ways
- The First Way： System Thinking （系统思考：强调全局优化，避免局部优化）
- The Second Way： Amplify Feedback Loops （通过放大的反馈回路：建立从开发过程下游至上游的反馈环）
- The Third Way： Culture of Continual Experimentation And Learning（持续作试验和学习的文化：持续作试验，承担风险、从失败中学习；经过反复实践来达到精通）
CLAMS
- Culture –文化：公司各个角色一块儿担当业务变化，实现有效协做和沟通；创建包括运维在内的跨职能协做文化,具备共同目标的一体化团队。这是DevOps运动的根本
- Automation – 自动化：在价值链中尽可能除去手工步骤；自动化一切能够自动化的步骤，下降部署和发布的难度
- Lean – 精益：运用精益原则更频繁地交付价值；以精益的方式小步快跑，对过程与技术进行持续改善
- Metrics – 度量：度量并使用数据来优化交付周期；经过创建有效的监控与度量手段来得到反馈,推进产品和团队的持续改进, 支持业务决策
- Sharing – 分享：分享成功和失败的经验来相互学习。
为何要实践 DevOps
- 更短的交付周期，生产环境部署频率愈来愈快，简化生产部署流程，且自动化不停机部署
- 更高的价值，造成特性提出到运营数据、用户反馈验证的实验性交付闭环，基于实际用户反馈调整计划和需求
- 更好的质量保障，在代码检查，功能和非功能验证，以及部署各方面创建较完善的质量保障体系，尤为是自动化测试集
- 更高绩效的团队，包含业务，开发测试，和运维职能在内的一体化团队，以产品交付为共同目标紧密协做，共同承担责任
DevOps 在技术领域的实践
DevOps运做包括文化（全功能，自运维）和技术（自动化，度量反馈）两方面，而技术能力的改进主要关注如下六个领域：
内建质量体系
经过持续代码评审，静态分析，自动化测试，自动部署验证等手段构成一套有效的质量保障体系。
主要实践包括：
- TDD：测试驱动开发的思想，保证代码质量和不偏离业务需求的技术实现
- 结对编程和代码审查，依靠团队的自治性让团队成员互相监督和审查代码质量
- 自动化测试，高自动化，且高频率运行的测试，保证测试用例质量的同时保证了交付软件的质量
持续部署
经过自动化的构建，部署过程快速频繁地将软件交付给用户，提升吞吐量；同时保障过程的安全，平滑，可视。
主要实践包括：
- 在已经作到持续集成的状况下，引入持续部署，每次提交均会出发构建并执行部署
- 蓝绿部署，用于实现零宕机发布新版本
- 金丝雀发布，用于使应用发布流程具有快速试错的能力
持续监控
持续对运行环境在系统，应用层面进行监控，及时发现风险或问题，保障系统运行的稳定性。
主要实践包括：
- 监控预警，在项目开始初期就引入监控，让整个团队实时可以收到关于产品各个维度数据的反馈
- 日志聚合，便于错误追踪和展现
- 分析，利用搜集到的数据实时分析，利用分析结果指导开发进度
度量与反馈
经过对用户行为或业务指标的度量或反馈收集，为产品的决策提供依据。
主要实践包括：
- 持续集成反馈，对代码构建质量，代码质量审查的反馈
- 测试反馈，对软件质量，功能性的测试，给到业务的反馈
- 运营数据反馈，新功能上线后对业务影响的反馈，用于指导业务人员提新的需求
环境管理
经过对服务器环境的定义，自动化创建和配置、更新等提升基础设施管理的效率，一致性，并更有效利用资源，可伸缩的架构，保证服务的健壮性。
主要实践包括：
- 弹性架构，保证服务的吞吐量和具有灵活变动的能力
- 自动化部署脚本，想胶水同样，用于解决一些工程实践不够完善的流程之间的衔接
- 基础设施即代码，用代码定义基础设施，便于环境管理，追踪变动，以及保证环境一致性
松耦合架构
对传统应用架构进行领域组件化，服务化，提高可测试性和可部署性。
主要实践包括：
- 采用弹性基础设施，好比公有云服务或是 PaaS（Platform as a Service） 平台
- 构建为服务应用
- 引入契约测试
将来 & 趋势
- DevOps 话语权愈来愈多被平台厂商掌握
在 DevOps 实践的第一阶段，每每会是 Jenkins, Nexus, Ansible, Shell 等一系列工具的拼凑组合，上手难度大，维护成本高，开发体验很差。随着 DevOps 日渐成熟，以 AWS、Pivotal、RedHat 为表明的一些公司分别退出本身的 “DevOps产品”，或是一套完整的工具链，或者直接整合到一个 PaaS 平台，甚至一些产品直接将“敏捷”，“精益”的概念也整合到产品中，直接能够把一家公司的所有业务放到平台上，这和最近大热的“数字化平台战略”也是相吻合的。
无论怎样，这些平台厂商一边卖本身的产品一边从新定义着 DevOps，随着平台的完善，DevOps 已经变得愈来愈不重要，我一直以为最好的 DevOps 团队应该是“润物细无声”的，就是一个团队不用提 DevOps，整个团队很天然地就能关注到业务价值的交付，且能有序地按照高质量，高效率的要求去作，平台或许能帮助咱们作到这一点。
- 容器化 & 微服务仍然是 DevOps 应用和发展的主要领域
容器化、微服务自然适合小而全的功能团队，且一个个自治的服务也很复合 DevOps 端到端交付团队的设计，近年随着容器化技术（Docker）的发展，容器管理（Kubernetes）的日渐成熟（据悉，github 已经将它们的一部分产品环境灰度发布到了 kubernetes 上，京东也将他们的服务百分之六十采用了 kubernetes 管理），DevOps 和微服务成为了相辅相成的两个趋势。
- 安全成为推进 DevOps 全面发展的重要力量
安全是 DevOps 永远绕不开的话题，也每每是新技术在传统行业（例如金融和电信）应用中的最大阻碍。一方面，组织结构的转型迫使企业要打破原先的部门墙，这意味着不少原先的控制流程再也不适用。另外一方面，因为大量的 DevOps 技术来源于开源社区，缺少强大技术实力的企业在应用相关技术时难免会有所担心。
DevOps 全局优化的特色与安全社区提出的 “Build Security In”也特别吻合，加之愈来愈多安全易用的工具涌现，DevOpsSec 会愈来愈被人们熟知。
