DevOps学习总结

                                                                              DevOps学习总结  2017-4-28

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

应用模型的变迁：

开发模型也经历了变革：

              

历史及现状    

很多组织将开发和系统管理划分成不同的部门。开发部门的驱动力通常是“频繁交付新特性”，而运营部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配，就在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。

 

开发人员经常不考虑自己写的代码会对运营造成什么影响。他们在交付代码之前，并不邀请运营人员参与架构决策或代码评审。

 

开发人员对配置或环境进行修改之后，经常没有及时与运营人员沟通，导致新的代码不能运行。

开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。想找到必要的配置参数，通常需要尝试很多不同的参数；在得到一个可工作的状态后，往往很难识别出通过哪些最小步骤就能到达该状态。

 

开发人员倾向于使用有利于快速开发的工具：对代码修改更快的反馈，更低的内存消耗，等等。这样的工具集与运营人员面对的目标运行时环境非常不同：后者对稳定性和性能的要求远胜于灵活性。

 

由于开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统。生产环境的运行时系统通常都运行服务器操作系统上。

 

在开发过程中，系统在开发者的本地机器上运行。在运营过程中，系统经常分布在多台服务器上，例如web服务器、应用服务器、数据库服务器等等。

 

开发是由功能性需求（通常与业务需求直接相关）驱动的。

 

运营是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。

 

运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险，
如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大。

 

变更规模越大，风险也越大，因为其中涉及的区域越多。

 

由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。

 

运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。

 

开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。

 

诉求

更小、更频繁的变更──意味着更少的风险

让开发人员更多地控制生产环境

更多地以应用程序为中心来理解基础设施

定义简洁明了的流程

尽可能地自动化

促成开发与运营的协作

 

DevOps模型

 

组织文化是基础，DevOps需要产品经理，开发，运维人员一起参与进来，树立共同的目标，统一考核标准，沟通协作，共同努力。

早参与，多参与。对于开发人员，要让运维人员常驻到开发部门，全程参与开发流程。邀请运维人员参与你的Scrum或者开发会议，与他们分享项目计 划、分享新技术的点子和心得。搜集功能性需求（指开发人员用到的需求）的同时也要搜集运维方面的需求。把对于“发布、备份、监控、安全、配置管理和系统功能”的测试作为一项独立的项目流程。软件产品在开发时解决的问题越多，那么在使用时暴露给用户的问题就越少。给运维人员做培训，让他们弄清楚项目的体系结构和核心代码。如果运维人员在反馈bug时提供的信息越多，那么你花在排查问题（trouble-shooting) 的时间就越少，这个bug也就会更快的被解决掉。

对于运维人员，在遇到问题时需要把开发人员加进来，大家一起解决问题。邀请开发人员参与你们的会议，分享项目进度（roadmaps），并且共同修订工作计划。运维人员一定要了解开发部门下一步的工作方向，从而确保产品运行的底层平台能够良好的支持最新技术。开发人员也会带来相关的技术、知识和工 作，帮助你们改善产品的运行环境，使其更加易于维护、简洁有效。

有一些开发领域的概念，例如：“要根据API而非封闭的interface来构建工具”，分布式版本控制，驱动测试开发，以及诸如敏捷开发、看板管理（Kanban）和Scrum等方法论。如果把这些概念应用在运维领域，同样会产生革命性的变革。

不要惧怕新点子和新技术。我们可以随时随地的向他人学习，哪怕是一句“我们再也不要那样做了！”也会让我们从中获益。尽管处于不同的部门，但是我们要共同学习、共同成长，这样才能协同工作的更好！

按照从高到低的顺序，有效的沟通方式应该是：面对面交流 、视频会议、电话、即时通讯软件、Email。

看板示例：

 
任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
看板的内容不局限，可以是个人，项目组，公司的近期任务或目标，以高效信息沟通为目的。

 

可视化是运维的本质与关键所在。

一套成熟的运维系统，能够将应用、网络、计算、存储、虚拟化等资源的性能以及告警信息进行综合分析，通过简洁易懂的界面，直观呈现业务健康水平。当出现故障时，能够第一时间收到信息，从监控相关信息确定问题位置，缩小故障定位范围，确定问题是在计算、应用还是网络，进而明确问题职责，让相应的开发运维迅速处理问题，没有推脱责任之嫌。
数据的可视化能力非常重要，需要在面向整体和面向某个业务流上都有实现。它首先体现出你对运维的理解是什么样的，从可视化Dashboard上可以看到最直接的运维经验；其次基于可视化之上的数据共享，让大家对数据的理解达成一致；最后利用一致化的可视化数据发挥运维的驱动能力，驱动DevOps，数据的核心价值就在于此。 
因此可视化的能力就代表了运维的能力，可视化的程度越高，运维的能力越高。

 

自动化是DevOps的核心。DevOps提倡“自动化一切” （Auto everything)。自动化是持续交付和提供高质量运维服务的实现方式和途径。
持续交付软件从代码产生的那一刻就开始进行管理，到编译、到测试、到灰度环境验收再到正式环境部署，最终目标是这一过程完全自动化。

 
实现自动化必须借助工具。
一、 开发工具：
源码管理（SourceTree, Git, Gerrit, Repo）
案例：使用Git, Gerrit开发工具实现自动定位编译错误责任人。
代码扫描 （sonarqube， coverity）

二、自动化构建和测试:
ANT， Gradle， Maven， JMeter

三、持续集成
Jenkins

四、部署工具
容器平台
Docker
配置管理
Chef， Bash

五、日志
Logstash

六、监控
Nagios,zabbix

 

DevOps企业实践

 

一般而言，当企业希望将原本笨重的开发与运营之间的工作移交过程变得流畅无碍，他们通常会遇到以下三类问题：

发布管理问题：很多企业有发布管理问题。他们需要更好的发布计划方法，而不止是一份共享的电子数据表。他们需要清晰了解发布的风险、依赖、各阶段的入口条件，并确保各个角色遵守既定流程行事。

发布/部署协调问题：有发布/部署协调问题的团队需要关注发布/部署过程中的执行。他们需要更好地跟踪发布状态、更快地将问题上升、严格执行流程控制和细粒度的报表。

发布/部署自动化问题：这些企业通常有一些自动化工具，但他们还需要以更灵活的方式来管理和驱动自动化工作──不必要将所有手工操作都在命令行中加以自动化。理想情况下，自动化工具应该能够在非生产环境下由非运营人员使用。

要开始优化发布流程，可以从问题识别开始，看看上面提到的哪种问题在你的团队中具有最高的优先级。基于公司实际情况，制定阶段性目标，一步一步实现。

坚持持续改进，推行精益管理，不断优化开发，业务流程，打造创新，高效，负责，协作的企业文化。推行DevOps是所有竞争性公司的必由之路，是一个长期的过程，靡不有初，鲜克有终，只有不忘初心，方得始终。