# DevOps [转载] > 本文为 转载文章， 非原创 # DevOps > DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 > DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。 ## DevOps 核心价值 > 文化观念的改变 + 自动化工具 = 不断适应快速变化的市场 * 更快速地交付, 响应市场的变化。 * 更多地关注业务的改进与提升。 ## 为什么需要DevOps > VUCA 概念 * V=Volatillity（易变性）是变化的本质和动力，也是由变化驱使和催化产生的 * U=Uncertainty（不确定性）缺少预见性,缺乏对意外的预期和对事情的理解和意识 * C=Complexity（复杂性）企业为各种力量，各种因素，各种事情所困扰。 * A=Ambiguity（模糊性）对现实的模糊，是误解的根源，各种条件和因果关系的混杂。 ![图片 1][1] ### 产品迭代 > 我们不管是做互联网还是做游戏，其实最终都是在做产品，做一款用户喜欢的产品。乔布斯有句非常著名的名言：“消费者并不知道自己需要什么，直到我们拿出自己的产品，他们才发现，这是我想要的东西”。所以乔帮主能够在一开始的时候就设计好了产品最终的效果，然后按照零部件一步步迭代生产 ![图片 2][2] ![图片 3][3] > 现实中的用户其实一开始并不知道自己想要什么，但是直到看到了我们的产品，他才知道自己不想要什么。 即让现实的产品迭代是如此曲折和反复 * 用户：我平时上下班都是走路，每天都要走五公里，好辛苦，有没有办法帮我设计个工具，解决下我的痛点。 我们思考了下，觉得这个不是很难嘛，可以试下，于是我们讨论 -> 设计 -> 开发 -> 测试 -> 交付给用户了一个滑板。 * 用户：这个滑板不好操控，可以给我加个扶手吗？ 然后我们按照用户新的需求，生产了个滑板车。 * 用户：滑板车得滑着走，能不能让我可以骑着走的。 我们继续改进产品，生产了个自行车。 * 用户：自行车还得登着走，路程远了也很累。 我们又继续优化，把它变成了电瓶车。 * 用户：电瓶车倒是解决了的需求，不过就是不太安全，能再优化下产品吗？ 经过各种努力我们最后生产出了一辆漂亮的小轿车交付给了用户，终于让用户满意了。 ### 技术革新 > 在以前的系统中业务单一、逻辑简单、用户量少，项目团队的规模一般在 10~30人。而现在的系统要面对不同用户的定制化推荐等，互联网连接着人与人、人与物、以及物与物，业务也变得越来越复杂，功能越来越多，如果整个系统耦合在一起，则必定会牵一发而动全身，导致系统维护起来相当困难。 > 因此IT技术架构也随着系统的复杂化而不断地变化革新，从早期所有服务的All In One发展到现在的微服务架构、从纯手动操作到全自动化流程、从单台物理机到云平台，下图展示了IT技术革新的变化： ![图片 4][4] ## DevOps的指导思想 > 其实DevOps核心思想就是：“快速交付价值，灵活响应变化”。 ![图 5][5] * 高效的协作和沟通； * 自动化流程和工具； * 快速敏捷的开发； * 持续交付和部署； * 不断学习和创新。 ### 整体流程图 ![图6][6] * 敏捷管理：一支训练有素的敏捷开发团队是成功实施DevOps的关键。 根据康威定律：软件团队开发的产品是对公司组织架构的反映。 所以根据公司情况调整组织结构是首要条件，它将直接影响到需求、设计和开发阶段的效率、以及沟通的成本。 关于团队的沟通成本的计算公式：沟通成本 = n(n-1)/2，其中n为人数，所以沟通成本将随着组织人员的增加而呈指数级增长。 * 持续交付部署：实现应用程序的自动化构建、部署、测试和发布。 通过技术工具，把传统的手工操作转变为自动化流程，这不仅有利于提高产品开发、运维部署的效率，还将减少人为因素引起的失误和事故，提早发现问题并及时地解决问题，这样也保证了产品的质量。 ![图 7][7] * IT服务管理：可持续的、高可用的IT服务是保障业务正常的关键要素，它与业务是一个整体。 IT服务管理（ITSM）直接影响产品运营的整个生命周期，传统的IT服务管理（像ITIL）在生产中做的非常好了，但是它对于DevOps来说又显得过于繁琐，所以有必要为DevOps创建一个只关注业务持续性的ITMS，它只需要很少的必要资源来为相应的业务提供服务，ITMS更多地从业务角度考虑了。 注：白话解释下什么是IT服务管理（ITSM），它是传统的“IT管理”转向为“IT服务”为主的一种模式，前者可能更关注具体服务器管理、网络管理和系统软件安装部署等工作；而后者更关注流程的规范化、标准化，明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程之间的关系等，比如建立线上事故解决流程、服务配置管理流程等； 而光有流程还不够，因为流程主要是IT服务提供方内部使用的，客户对他们并不感兴趣，所以还需将这些流程按需打包成特定的IT服务，然后提供给客户使用，比如在云平台上购买一台虚拟云主机一样。 * 精益管理：建立一个流水线式的IT服务链，打通开发与运维的鸿沟，实现开发运维一体化的敏捷模式。 精益生产主要来源于丰田生产方式 (TPS)的生产哲学，它以降低浪费、提升整体客户价值而闻名，它主要利用优化自动化流程来提高生产率、降低浪费。所以精益生产的精髓是即时制（JIT）和自动化（Jidoka）。 JIT（Just In time）：JIT用一句话描述就是消耗最少的必要资源，以正确的数量，生产和运送正确的零件。在这种模式下工作，可以最大程度上降低库存，防止过早或者过度生产。大多数公司更倾向用库存来避免潜在的停线风险，而丰田却反其道而行之。通过减少库存“逼迫”对生产中产生的问题做及时且有效的反应。当然JIT这一模式对解决问题的能力是相当大的考验，在能力不足的情况下，会有相当大的断线风险。 Jidoka（Build in quality）：自动化，在丰田TPS系统里，特意给“動”字加上了“人”字旁变成了“働”，换句话说，TPS/精益生产渴望生产的过程控制能像“人”一样智能，在第一时间就异常情况下自动关闭。这种自动停机功能可以防止坏件流入下游，防止机器在错误的生产状态下造成损坏，也可以让人更好的在当前错误状态下进行故障分析。当设备能够做到自动分析故障时，就可以将监管机器的“人”真正解放出来，做到对人力成本的节省。 ![图 8][8] > 精益软件开发是精益生产和实践在软件开发领域的应用。精益管理贯穿于整个DevOps阶段，它鼓励主动发现问题，不断的优化流程，从而达到持续交付、快速反馈、降低风险和保障质量的目的。 * 消除浪费 * 增强学习 * 尽量延迟决定 * 尽快发布 * 下放权力 * 嵌入质量 * 全局优化 ## 实施DevOps的具体方法 > 目前大多数IT互联网公司普遍的分层结构，它们一般分为七大部门：产品策划、设计美术、前端工程师、后端工程师、测试工程师、运维&DBA和市场运营等。各部门之间天然的形成了沟通障碍墙，相互之间主要以邮件和会议的形式沟通，效率低下、需求变更困难、很难快速响应市场变化和持续交付高品质的产品。 * 建立快速敏捷团队 ![图9][9] > Scrum Master 架构 ![图10][10] * 实现自动化的流程 > 完整DevOps的Pipeline ![图 11][11] * 提交：工程师将代码在本地测试后，提交到版本控制系统，如 Git代码仓库中。 * 构建：持续整合系统（如Jenkins CI），在检测到版本控制系统更新时，便自动从Git代码仓库里拉取最新的代码，进行编译、构建。 * 单元测试：Jenkins完成编译构建后，会自动执行指定的单元测试代码。 * 部署到测试环境：在完成单元测试后，Jenkins可以将应用程序部署到与生产环境相近的测试环境中进行测试 * 预生产环境测试：在预生产测试环境里，可以进行一些最后的自动化测试，例如使用Appium自动化测试工具进行测试，以及与实际情况类似的一些测试可由开发人员或客户人员手动进行测试。 * 部署到生产环境：通过所有测试后，便可以使用灰度更新将最新的版本部署到实际生产环境里。 ## DevOps 技术栈 ### 敏捷管理工具 * Trello * Teambition * Worktile * Tower ### 产品&质量管理 * confluence * 禅道 * Jira * Bugzila ### 代码仓库管理 * svn * Git ### 开发流程规范 * Git Flow ![图 12][12] * Github Flow ![图 13][13] * Gitlab Flow ![图 14][14] ### 自动化构建工具 * Gradle * Maven * SBT * ANT ### 虚拟机与容器化 * VMware * VirtualBox * Vagrant * Docker ### 持续集成（CI）&持续部署（CD） * Jenkins * Hudson * Travis CI * CircleCI ### 自动化测试 * Appium Appium是一个移动端的自动化框架，可用于测试原生应用，移动网页应用和混合型应用，且是跨平台的。可用于IOS和Android以及firefox的操作系统。 * Selenium Selenium 测试直接在浏览器中运行，就像真实用户所做的一样。Selenium 测试可以在 Windows、Linux 和 Macintosh上的 Internet Explorer、Mozilla 和 Firefox 中运行。 * Mock测试 Mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。这个虚拟的对象就是Mock对象，Mock对象就是真实对象在调试期间的代替品。Java中的Mock框架常用的有EasyMock和Mockito等。 ### 自动化运维工具 * Ansible * Puppet * Chef * 脚本 ### 监控管理工具 * Zabbix Zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级开源解决方案。 * ELK Stack日志分析系统 ELK Stack是开源日志处理平台解决方案，背后的商业公司是Elastic。它由日志采集解析工具 Logstash、基于 Lucene 的全文搜索引擎 Elasticsearch、分析可视化平台 Kibana三部分组成。 * 云监控（如Amazon CloudWatch） Amazon CloudWatch 是一项针对 AWS 云资源和在 AWS 上运行的应用程序进行监控的服务。您可以使用 Amazon CloudWatch 收集和跟踪各项指标、收集和监控日志文件、设置警报以及自动应对 AWS 资源的更改 [1]: https://jicki.cn/img/posts/devops/1.png [2]: https://jicki.cn/img/posts/devops/2.png [3]: https://jicki.cn/img/posts/devops/3.png [4]: https://jicki.cn/img/posts/devops/4.png [5]: https://jicki.cn/img/posts/devops/5.png [6]: https://jicki.cn/img/posts/devops/6.png [7]: https://jicki.cn/img/posts/devops/7.png [8]: https://jicki.cn/img/posts/devops/8.png [9]: https://jicki.cn/img/posts/devops/9.png [10]: https://jicki.cn/img/posts/devops/10.png [11]: https://jicki.cn/img/posts/devops/11.png [12]: https://jicki.cn/img/posts/devops/12.png [13]: https://jicki.cn/img/posts/devops/13.png [14]: https://jicki.cn/img/posts/devops/14.png