1、DevOps 实战分享2018.6Part 1：什么是 DevOps敏态业务和稳态业务 业务按照传统方式经营，战略目标明确，业务流程相对成熟； 对应的信息化特征为 SOR（ Systems of Record）； 信息化是业务的有效支撑手段，企业当前的 IT 重点聚焦于实现业务电子化。 稳态业务敏态业务 业务则采用“互联网 +” 思维模式，业务模式本身处在不断探索、优化、总结的过程，需要通过不断试错来逐步完善； 对应的信息化特征为 SOI（ Systems of Innovation）； IT与业务深度融合，是业务创新赖以实现的必备要素。双态 IT旨在实现支撑企业业务多样化发展的管理体系和信息
2、技术之间的相互匹配、协调一致。稳态管理以 ITTL 理念为核心，强调流程和规范、安全和稳定，维护好原有的 IT基础设施持续提供服务敏态运营以 DevOps 理念为核心，通过促进开发、测试和运维团队之间的沟通和协作，打造 IT服务完整的生命周期交付链双态 IT传统行业的 IT部门内部的团队墙运维团队 开发团队稳定第一 实现第一可靠性、可维护性、性能、安全性、验证、上线规范、流程、文档 敏捷、快速迭代、原型、 组件、框架、自动测试、开发进度 主导权竞争、鄙视链、相互指责、踢皮球 常见的问题 开发是由功能性需求（通常与业务需求直接相关）驱动的。运维是由非功能性需求（例如可获得性、可靠性、性能等）驱动
3、的。 开发人员经常不考虑自己写的代码会对运维造成什么影响。交付代码之前，并不邀请运维人员参与架构决策或代码评审。 开发人员对配置或环境进行修改之后，经常没有及时与运维人员沟通，导致新的代码不能运行。 开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。 开发人员平时使用桌面电脑以及为桌面用户优化的操作系统。生产环境的运行时系统通常都运行服务器操作系统上。 在开发过程中，系统在开发者的本地机器上运行。在运维过程中，系统经常分布在多台服务器上。 运维人员希望尽量避免修改功能，从而降低满足非功能性需求的风险。 如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大
4、变更规模越大，风险也越大。 由于运维人员尝试变更部署，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。 运维人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。 开发人员可能对运行时的环境缺乏了解，从而难以正确地对代码进行调整。 DevOps的概念 DevOps一词的来自于 Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。 DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序 /软件工程）、技术运营和质量保障（ QA）部门
5、之间的沟通、协作与整合；填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。过去 DevOps概念的演变2008年 还没有人提出这个 DevOps名词，只是强调需要 敏捷架构 。2009年 DevOps第一次被提出来，被定义为 开发运维一体化 。2010年 DevOps的概念被明确 ： “一组过程、方法与系统的统称。用于促进开发、技术运营和质量保障之间的 沟通、协作与整合 ”。2011年 DevOps被定义为“一种强调 Dev和 Ops之间 沟通合作的文化、运动或惯例 ”。通过自动化式的交付与变更流程。使得构建、测试、发布软件能够更加地快捷、频繁和可靠。近期的 DevOps定义2016年
6、 DevOps被定义为旨在统一开发和运维的一种 软件工程文化和实践 。目标是： 与业务目标保持一致 更短的开发周期 更高的部署频率 更可靠的软件发布2017年 兴起的 DevOps运动，强调了 DevOps的重心 “将软件建设的所有环节进行自动化 &全面监控 ”。DevOps的根本目的持续集成持续交付支撑敏态业务DevOps的本质是什么 DevOps希望做到的是软件产品交付过程中 IT工具链的打通 ，使得各个团队减少时间损耗，更加高效地协同工作。 专家们总结出了下面这个 DevOps能力图，良好的闭环可以大大增加整体的产出 。DevOps广义理解DevOps的实施，需要从组织、技术、流程、文化
7、四个维度进行持续的优化与改进。组织开发自助服务平台工程师技术文化全栈团队 岗位轮换 JointMeetings(联席会议）特性团队服务式领导网站运维工程师自洽团队集成工具箱监控一切基础设施即代码一切编译、测试、发布持续监控聊天运营最小可用产品构建自动化测试自动化发布自动化金丝雀发布失败回滚工具化一切 特性标记 /功能发布控制ChaosMonkey通用度量流程优化价值流持续集成持续测试持续交付版本化一切测试驱动开发技术债券测试一切最小可用流程测试驱动发布V批量迭代 V看板流程信任协作主人翁持续优化工程师文化学习型组织应用快速集成和发布的背后DevOps的目标高效 构建快 交付快 迭代快品质 代码
8、质量高 安全可靠 系统更稳定组织 改善公司组织文化 提高员工参与感 提高 IT团队稳定性为什么最近才流行 大家对 DevOps有了一定的了解 技术配套发展成熟 越来越多的技术支撑 微服务架构理念、容器技术使得 DevOps的实施变得更加容易 计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用 外部对适应快速变化的需求越来越高 互联网应用越来越多 敏捷开发的诉求越来越高 工程师也需要 对于开发者而言，最有力的工具就是自动化工具 工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；Part 2： DevOps的落地DevOps核心流程打造具备持续交付能力 团队
9、产品人员测试人员 运维人员开发经理 开发人员运营人员UI/UE 敏捷教练 同一个团队、同一个目标Tips：1，物理位置2，人员管理3，认领工作打造具备持续交付能力 精益消除浪费 增强学习 尽量延迟决策 尽快交付授权团队 嵌入完整性 着眼整体1.消除浪费制造业七大浪费 举例 软件业七大浪费 举例1 库存 不结合主生产计划需求流线生产所导致局部大批量库存 半成品、部分完成的 工作 同时研发中的多个功能需求2 额外过程制造过程中作业加工程序动作不优化，可省略、替代、重组或合并的未及时检查额外的过程 文档3 生产过剩 不结合主生产计划需求流线生产所导致局部大批量库存 多余的功能 想当然以为有用的功能4
10、 运输 车间布置采用批量生产，不是按照流水线生产 任务调换 同时分配多个任务5 等待 作业不平衡，安排作业不当、待料 等待 等待上级或者第三方响应6 移动 产生不必要的搬运、堆积、放置、防护处理、找寻等浪费 移动 需要其他人的协助时的移动7 缺陷 品质不良 缺陷 Bug2.增强学习 软件开发是一种学习的过程 敏捷开发鼓励通过尝试、测试、修正的短周期来开发程序 需求完善也是一个学习的过程 产品经理或者客户往往也无法把需求和业务流程考虑得非常周全 团队同步的学习： 新技术 开发架构 业务需求 开发工具 运维工具3.尽量延迟决策 敏捷开发为了处理需求的不断变更、鼓励把决策的下达延迟到最后可以容忍的时
11、间点再做决定 延迟决策的目的为了避免早期信息还不够清楚的状况下，就作出决定和评估，这是一种浪费，后面还有可能会修改或者重建 等到真正需求做改变的时候再做决策，提前的变更只会增加无形的成本4.尽快交付 客户喜欢尽快交付 让团队成员自己有效安排时间 敏捷团队强调组织优化的最佳途径是强调组织的吞吐量5.授权团队 精益理论的两个假设： 1，成熟的组织关注是整体的系统，不会专注于优化分散的部分 2，成熟的组织强调的是有效学习，会授权工作人员制定决策的全力 我的团队会自我管理么？ 你无法面面俱到，考虑得丝毫无错：帮他们制定简单的规则，然后把担心转化为信心 简单的规则法：管理者专注在一些明确且 需要注意的规
12、范上，并运用一些基本规则来处理 简单的规则让团队显得一致，而一致的目标会让团队更加的团队，混乱与充满抱怨的环境只会让团队失去内在成长的动机； 越优秀的团队越适用简单的管理规则6. 嵌入完整性 了解业务：让全体开发人员了解应用领域方面的知识，持续把客户的价值观变成对细节设计给开发团队 认同迭代：接受变更，将变更看成是一件正常的过程和容纳新设计及决策的能力 沟通协同：营造提高沟通能力的环境，以便对人员、工具和信息进行整合，同时建立沟通机制降低复杂性7.着眼整体 开发团队注重全局，避免局部优化、舍本逐末 避免过度注重细节产生局部优化，例如： UI 避免因为业绩考核造成局部优化，例如：大家只做对业绩有
13、帮助的事情 避免因合同或成本造成局部优化，例如：具备需求变更 客户需要的不是软件，而是解决他们的问题 敏捷式的合同 让需求有优先级一个简单的流水线功能开发 测试用例开发 源码管理SVN/GIT 程序构建JENKINS 单元测试 XUINT代码扫描SONARQUBE归档包管理NEXUS配置管理CMDB部署测试服发布平台集成测试Selenium人工测试 反馈问题 发布生产服 发布平台 运维监控监控平台DevOps体系的工具链DevOps平台，就是通过打通工具链来支撑 DevOps的组织和流程、文化，实现集成化、自动化DevOps 涉及的技术和组件 代码管理（ SCM）： GitHub、 GitLa
14、b、 SubVersion、 TFS 构建工具： Ant、 Gradle、 Maven 自动部署： Capistrano、 CodeDeploy 持续集成（ CI）： Bamboo、 Hudson、 Jenkins 配置管理： Ansible、 Chef、 Puppet、 SaltStack、 ScriptRock GuardRail 容器： Docker、 LXC、第三方厂商如 AWS 编排： Kubernetes、 Core、 Apache Mesos、 DC/OS 服务注册与发现： Zookeeper、 etcd、 Consul 脚本语言： Python、 Ruby、 Shell 日志管
15、理： ELK、 Logentries 系统监控： Datadog、 Graphite、 Icinga、 Nagios 性能监控： AppDynamics、 New Relic、 Splunk 压力测试： JMeter、 Blaze Meter、 loader.io 预警： PagerDuty、 pingdom、厂商自带如 AWS SNS HTTP加速器： Varnish 消息总线： ActiveMQ、 SQS 应用服务器： Tomcat、 JBoss Web服务器： Apache、 Nginx、 IIS 数据库： MySQL、 Oracle、 PostgreSQL等关系型数据库； cassandra、 mongoDB、 redis等 NoSQL数据库 项目管理（ PM）： Jira、 Redmine、禅道、 Asana、 Taiga、 Trello、 Basecamp、 Pivotal Tracker开源是大趋势协同工具 让 DevOps团队共同进行任务分配和工作协同的平台 主流工具： TAPD、禅道、 Jira、 Redmine 几个主要管理的对象： 工作 /任务 需求 文档 问题 /缺陷 测试用例 /测试结果 Wiki 协同平台不仅仅只是数据的记录，更应该打通开发、测试的过程，能提供精益分析的依据
