他山之石——运维平台哪家强？

DevOps 全链路

下图是咱们熟知的软件研发环节，在迭代频率高的研发组织里，一天可能要经历屡次以下循环。对于用户群体庞大或者正在经历大幅业务扩张的企业研发组织，除了重点关注应用的快速上线以外，如何保障应用的高可靠、高可用也成为焦点，即服务上线要快，运行要好。

如何让开发更简单，运行更高效，接下来咱们从两个角度来探讨这个问题：

• 组织方式
• 研发工具

关于运维人员的组织方式

• 一种方式是组建专门的运维团队，一个运维团队每每会承接多个开发团队的协做。除了 DBA 这类针对某个中间件的运维以外，这种模式的弊端在于很多运维工程师深陷于环境配置、日志收集、业务恢复、现象记录等琐碎事情当中，没有时间阅读项目源码以及提高能力，对较为深刻的业务问题分析困难，开发团队又每每无暇分身，运维容易陷入被动的境地。
• 另外一种方式，开发人同时负责各自模块的开发与运维。好处天然是因为开发人员熟悉本模块源码，定位问题的效率要高出很多。同时开发者能够直接获得下游用户使用反馈，将其融入到研发当中去。坏处在于，让开发人员陷入到频繁的用户问题定位以后，难以保证代码开发的时间。

近年来，国内也兴起了 SRE 这种高级运维职业，特别是在云计算行业，SRE 的职业要求很是高，须要精通诸如网络、编程、算法、数据结构、操做系统、安全等知识与技能。当云平台出现网络故障、系统故障等问题，这对云租户/用户有时甚至是致命的，因此很多 SRE 是由高级别开发人员转型而来。

在 Google SRE 的服务可靠性层级当中，SRE 经过产品、开发、容量规划、测试、根因分析、事件响应、监控七个层次的实践来确保应用服务的健康状态。从这个层级当中咱们能够看出 Google 提倡运维要积极控制服务发展的方向，而不只仅在事故发生后反应性地灭火。目前来看，SRE 这种精英式的运维在国内还有待探索与实践。

粗暴地将开发运维拆开，或者将开发运维简单合并，都不是特别合适的一种方式。从笔者的研发经验看，一种方式可供你们思考与讨论——根据业务实际状况作分工：好比由团队内的开发者轮流负责整个项目运维。因为各个开发者对项目公共代码都须要熟悉，在理解其它模块代码也相对快速，这种方式基本能消灭大部分的问题，剩下的一小部分能够和指定模块的负责人结对定位。除此以外，为“每一个服务团队分派运维联络人”，“邀请运维工程师参加开发团队的会议”都是可以增强运维与开发之间协做的措施。

关于工具的使用

除了恰当的人员组织方式以外，合适的工具也能给研发团队注入能力。

在配置研发环境时，研发组织能够选择经过开源工具自建代码管理和持续构建环境。这种方式的缺点在于须要有专门的 CI 团队来维护持续构建环境，一旦环境被破坏，开发的脚步就会停滞。而且因为各个开源工具数据未打通，开发人员要在多个工具之间切换使用。另一种方式就能够经过现有的软件研发管理系统，例如 CODING 研发管理系统，来实现一站式的研发流程管理，无需自建、维护众多的研发工具与研发环境，支持在浏览器中完成全套软件开发流程，真正作到了 Coding Anytime Anywhere。

当开发人员经过 CODING 研发管理系统快速开发并部署好应用后，下一步就要让应用在运维工具的辅助监控下可靠运行（并非全部应用都须要运维工具，需对症下药）。研发组织能够选择本身开发运维工具，也能够选择现有的运维工具。

目前的运维工具逐渐地朝以应用为中心发展，由于应用是直接向用户提供业务能力的，不管是开发仍是运维，都是被业务价值驱动的。主流的运维工具主要涵盖基础设施层监控、应用层面监控、业务层面的分析与监控。

接下来咱们看看现有的运维工具通常会提供哪些具体能力：

• 基础设施环境的监控：对服务器总体的 CPU、内存、磁盘、文件系统、网络等资源占用状况进行上报。
• 应用性能监控：针对应用使用的中间件，例如持久化数据库、缓存数据库、消息中间件等访问效率进行监控；以及对应用自己请求响应速度进行监控，包括延迟、吞吐量等等。
• 应用调用链路追踪：在分布式系统下，一个请求每每须要通过多个进程处理完毕。当出现用户请求调用失败或者出错时，运维平台支持整个调用链路的分析与故障环节定位。
• 日志数据采集与分析：日志的采集主要是为了辅助应用调用链路分析以及性能监控，运维人员无需进入后台去大量翻找日志。
• 故障自动恢复
• 灵活的告警
• 可视化面板展现监控与告警信息

国外热度较高的运维工具包括 ZIPKIN（分布式追踪），pinpoint（分布式追踪），logstash（数据收集）等等。目前国内各大云厂商也基本都提供了应用运维平台，包括腾讯蓝鲸、阿里 ARMS、华为 APM 等。如下是这几个运维平台能力的简要对比：

目前大部分的运维平台主要经过 Agent 和探针的方式去采集应用的指标信息，汇总处理后反应在可视化界面上。除上述的工具和平台以外，AIOps 也逐渐成为将来的一个趋势，AIOps 经过 AI 技术的运用来进行智能业务故障诊断，同时自动恢复应用故障，企图让研发组织完全告别人肉运维时代，笔者也万分期待这天的到来。运维人员不用担忧因 AIOps 失业，工具和平台只是提高运维效率，不会取代运维。

在运维阶段发现缺陷后，开发人员可在 CODING 中处理对应的缺陷，记录下每一个缺陷的类型、优先级、模块、描述、处理人等信息。软件缺陷是不可避免的，但只有经过对缺陷进行管理和复盘才能知道缺陷产生的缘由（人为因素 / 环境因素 / 工具问题等），从而改进，避免相似缺陷的重复。对缺陷的管理也有助于管理人员对软件质量的正确评估。缺陷处理人经过 CODING 实现缺陷的快速修复和部署，可大大缩短故障恢复时间，减小因缺陷产生的业务损失。

在 DevOps 理念的指导下，笔者建议开发人员在开发业务代码时，除了功能以外，也应当思考如何开发可运维的代码，经过适当的日志、错误码、异常等措施来提高运维效率；运维人员也需逐步提高能力，从传统的繁杂运维当中转型，走上敏捷自动化的运维之路。

写在最后

咱们能够看到随着 DevOps 工具链自动化显著提高，DevOps 的门槛变得更加地低。拥抱自动化的结果是研发过程会变得愈来愈安静，顶尖的开源项目里的 committers 在平常仅仅是经过邮件和 issue 将事情说清楚，没有热火朝天、冗长拖沓的会议；也没有花花绿绿，色彩斑斓的工做表格。但这些都是创建在 DevOps 良好实践的基础之上。咱们相信在践行 DevOps 的道路上，将来软件的开发会更简单，运行也会更加高效。

参考：
https://www.collab.net
https://landing.google.com/sr...
吉恩·金（Gene Kim）；耶斯·亨布尔（Jez Humble）；帕特里克·德布瓦（Patrick Debois）；约翰·威尔斯（John Willis）.《DevOps 实践指南》