九 再见作战室, 你好DevOps 2.0 - 应用发布中提升质量和速度的6种方法
9.1 概要
很多失败了因为他们没有正确的组织, 公司文化 和合适的工具.
对于整个团队- 开发， 测试， 运维 - 来说最关键的是，保证软件交付给终端用户更快，同时不危害软件质量。工具扮演了一个非常重要的支持作用：它们交付pipeline的自动化任务帮助公司更高效。
DevOps 1.0是一个伟大的方式，从80年代的精益制造业学习，让我们思考进行必要的变革。现在是时候引入DevOps 2.0了，你组织里的每个人提升技能， 并且对终端产品负责。
作战室是个例外，而不是规则，我们应该在出现质量问题时全部“shift left（左移）”。质量必须被构建到所有环节中 - 需求，设计，测试，部署，并且要尽可能自动化。
在本文中，我们将专注于你需要做什么来继续这种变革：
- 出问题时，问正确的问题，得到正确的答案，来高效地行动
- 升级开发，测试，和运维技能来从一开始就构建质量
- 定义一系列常见的基于共同目标的metrics，来做到敏捷团队的良好协作
- 定义业务优先级，这样团队可以集中关注最重要的
- 将持续的质量metrics作为硬性指标集成到项目的交付pipeline中，减少技术债务和计划外工作
- 自动化架构, 可扩展性, 性能分析 取代在成堆的日志文件中艰难前行.
9.2 再见作战室
在生产环境修复bug是很抓狂的一件事.
我们都知道在生产环境修复bug是一件很让人抓狂的事情: 比在早期开发环境要多花费150 倍的时间.
想想你的典型作战室 - 很多确实重要和经验丰富的人坐在一个房间好几天分析日志文件. 不是为未来开发新功能, 他们在修复昨天的问题, 在还技术负债.
不幸的是这种场景太常见了: 很多典型的开发团队的主要精力花费在修复bug上而不是新功能, **烂软件每年花费600 亿美元**.
基于我们的经验, 80%的生产问题只是由20%的问题类型导致的.你可以彻底的尖山作战室场景, 通过使用DevOps原则, 并且使用正确地工具(能准确定位问题)来主动地监控交付pipeline上的每个环境.
9.3 问正确的问题并得到答案
有很多人被叫到作战室, 但是对于这个问题他们是否可以修复, 是否他们应该负有责任, 经常没有线索.
"证据"(基础架构监控数据, 日志文件, 用户投诉等等) 表明了症状, 但是与root cause无关. 只有很多的日志信息和高级别的告警并不会给你与这个问题真正相关的答案.
为了远离这种场景, 真正的"证据"应该是什么? 你应该问什么问题?
是一个用户抱怨还是所有用户都受影响?
"只是"CEO抱怨一个问题, 因为一份报告在他的老IE7上无法工作? 或者"只是"使用拨号上网的终端用户? 了解一个问题发生在非常小的用户群, 还是说全中国的用户都受到影响, 是重中之重.
交付链(如: CDN, 第三方, ISP, 云供应商, 托管服务, 手机网络)有问题么?
当代 web 应用依赖一长串交付链的服务. 知道每个的影响会告诉你是否应该检查自己的数据中心, 还是说应该打电话给服务商.
关键事务是否受影响?
是否关键业务比如搜索受到影响? 还是说报错的页面早已经不用了? 你需要监控杆关键业务性能.
是这个应用的问题么?
应用很复杂. 如果你知道问题是发生在这个应用里, 你然后需要隔离, 然后让对应的开发和架构师效率更高.
这个问题与糟糕的代码有关么?
如果应用响应时间很慢, 第一个问题应该是是否与糟糕的代码有关. 你需要分析代码级别的性能热点来找到是否原因是低效的算法还是缺乏代码和架构的最佳实践.
这个问题在虚拟机里么?
如果虚拟机(如:VMware, EC2...)或你的容器(Docker)没有正确的size, 或者和其他虚拟机存在资源争用也可能引起性能问题. 如果你知道虚拟机的性能影响到了应用, 你会知道引入VM专家, 而不是应用开发, 来解决这个问题.
是基础架构导致的问题么?
如果不是应用自身问题, 而是因为app运行在资源不足的基础架构上会怎样? 如果需要运行垃圾回收的CPU因为超用导致不可用会怎样? 那么是时候考虑拆分应用或扩展基础架构了.
是应用服务器的问题么?
因为不正确的配置或错误的部署, 应用服务器也可能是性能问题的原因. 正确的资源池(线程, 数据源等)大小, 安全配置或日志参数都会影响性能. 如果发现是应用服务器的问题, 你需要联系IBM, Oracle, 微软专家.
有了这些问题的答案, 你可以消除作战室, 迅速定位问题根源, 优化并找到解决方案. 所以不需要20人的作战室, 你只需要3个人 - 一个开发, 一个测试, 一个运维 - 评估详细的性能insight, 并引入需要的专家. 完美!
9.4 是时候升级技能了
不同的metrics 不同的工具 = 不同的世界观
当你的DevOps时间不一致, 开发, 测试和运维将有一套不同的世界观, 他们的性能将会通过不同的metrics测量.
- 开发: 交付新功能, 每个sprint完成尽可能多的story points.
- 测试: 找到缺点, 推给开发.
- 运维: 维稳, 而不是开发新功能.
如果他们的目标都不一样, 他们怎么一起工作, 来支持你组织的持续交付的目标? 他们会彼此独自行动, 除了问题, 会有很多推诿.
为了达到你的持续交付的目标, 你必须打破这些团队间的墙, 让每个人在同一个队伍: 这个队伍的首要目标是创造伟大的高质量软件.
取代每天发现10个问题, 测试需要教育开发常见的问题, 使他们一开始就避免这些问题. 测试然后集中于更重要的任务 - 验收测试和大规模性能测试.
是时候升级你的工程师团队的技能. 所有职务需要开始了解其他职位的挑战. DevOps最好的是让所有人一起工作, 商定一系列常见的工具和指标, 然后商定每个指标的定义和测量的方式.
应用性能监控工具 - 从纯系统监控工具发展到现在的跨越应用交付链的端到端质量监控 - 让所有人都说共同的语言. 它们提供了一个单一的, 自动化的性能视角, 者也是为团队的每个成员的角色和需求定制的. 当出现问题, 跨功能团队可以一起修复问题而不用发起作战室.
9.5 你的重点在哪里?
给我钱
我们知道你遇到过这种问题, 因为我们也遇到了: 你的工程师团队认为有一个问题要修复需要花费一大笔钱和时间. 但是...结果是, 业务担心的是完全不同的另外一个问题.
有时你看到的全是红的. 有250个问题, 但是你怎么来指出其中最重要的呢?
优先考虑这些问题
用户体验和应用性能监控工具可以帮助聚合跨应用交付链的大量数据. 它们通过深入分析root cause提供智能影响分析. 它们也防止你首先看到所有红色 - 通过识别在交付pipeline的第一梯队, 可能导致生产系统性能下降的问题类型.
优先考虑的改进
性能监控工具可以帮助你优先考虑用户体验相关的改进:
- 在你的应用中, 你的用户按照你期望的路线来操作么?
- 他们用了所有的功能了么?
优先级最高的:
- 销售
- 品牌价值
- 用户满意度
9.6 "Shift left(左移)" 到开发工作站
持续交付需要持续质量.
9.7 自动化, 自动化, 自动化(重要事情说三遍)
你有如此之多的数据进来, 你可能担心没有时间和技能来分析所有数据.
有了应用性能监控软件, 你需要做的只有: 和业务团队一起定优先级, 找到关键指标并设置KPI, 就可以自动性能监控了.
哪些事情可以自动化? - 压测后, 发送变更请求给开发 - 集成测试中, 发送问题给开发 - 当KPI和SLA被测试和违例, 发送告警
附录
我们喜欢的DevOps工具 (2016年)
- 变更控制 - JIRA
- 开发 - Eclipse
- 源代码控制 - GitHub
- 自动化构建 - Ant, Maven
- 配置管理 - Ansible, Chef, Puppet
- 测试自动化 - LoadRunner, Selenium
- 虚拟机 - Vagrant, Packer VeeWee
