软件企业需要什么？从案例谈ChatOps协作体系

序言

在上一篇文章中，我们回顾了信息传递与处理在历史长河中的变迁，也介绍了信息处理的架构和关键要素，最后提出“软件研发运维的信息传递和处理如何优化？” 我们能否让每一位技术人员，从需求、到开发、再到测试、运维等……都生出三头六臂？让我们先看看软件组织里面研发运维在信息传递和处理上的典型现状和挑战。

背景

A是一家互联网公司的CIO，管理着众多业务导向的交付团队和IT系统。交付团队分布在墨尔本、悉尼、西安、意大利等多个地点，IT系统分别部署在公司机房、数据中心、AWS、国外的数据中心等多个地点。由于公司业务发展势头非常好，该公司的交付团队（包括合作伙伴的团队）快速扩张，IT系统的数量也越来越多，CIO发现自己陷入了疲于救火的状态：

1. 分布式研发团队对于测试环境、发布窗口、构建能力等共享依赖资源的请求层出不穷，如何高效协调？
2. 分布式研发团队在集成、测试、发布等关键活动上的状态变化频繁，如何迅速传播到相关团队与个人？
3. 分布式研发团队对于关键活动状态的变化（构建失败、集成延期等），如何确保及时响应和处理？

B是一家金融机构的运维总监，底下有多个运维团队，分布在上海、深圳、北京等多地。运维部门负责维护该金融机构数百个IT系统，对应的考核指标是99.99%的高可用性。每个不同地点的运维人员都身兼数职，需要对不同系统的不同异常事件进行响应和处理。为了保障4个9的高可用性，运维总监发现日常运维中存在如下的难题：

1. 出现故障时，如何更有效地通知一线运维个人，或者故障升级（Escalate）到二线处理小组？
2. 异常来自于不同的系统和监控工具，除了告警之外，如何更有效地查询异常的上下文信息，进行故障排查？
3. 分析异常之后，如何确保异常故障被高效地响应和处理？

分析

事实上，IT企业中的研发运维基本都遵循着如下的流程框架，这个框架有着如下的特点：

软件企业典型流程

• 存在大量的基础设施，以及围绕着基础设施的各类IT流程（需求、构建、部署、测试、上线……）
• 基础设施与IT流程产生了大量的数据，以及针对这些数据的分析和整理（流程改进、业务支撑、应用支撑……）
• 前两个阶段产生了数据和信息，以及组织内各角色的沟通、协作与下一步改进（组织治理、知识库、改进……）

纵观整个流程，机器、应用持续不断产生新的增加、修改、状态信息，这些信息需要被周密地分析和思考，不同的人要参与到这两个过程，并且产生更多的知识、信息。简而言之，这就是一个关于“人－机器（应用）－信息”的管理问题，包含着如下的场景：

• 需求阶段：如何确保需求的价值是值得投入的？产品经理可能需要做用户研究、用户访谈，绘制NPS指标来向管理层和团队沟通需求的价值
• 开发阶段：如何确保系统的质量（Quality）和完备度（Readiness）？项目经理可能需要通过迭代、showcase，绘制燃尽图、CFD以及构建频率、构建通过率之类的指标，来揭示软件系统的质量和交付完备度
• 测试阶段：如何确保系统的质量和bugfix的效果？测试经理可能需要收集bug发现的记录，计算FFR或者缺陷率，来评估回归测试以及bugfix的效果和质量
• 运维阶段：如何确保系统的高可用以及业务连续性？运维经理需要收集系统运行的数据和故障的数据，计算MTTR、MTTF等其它指标，来衡量系统运行的可靠性

挑战

上一篇博客中提到了消息处理四要素：消息、输入者、处理者、消息网络。对应到软件组织的研发运维流程，我们可以发现：

• 输入源：物理基础设施、虚拟化平台、云管理平台、虚拟机操作系统、中间件、数据库、应用程序、网络等
• 处理任务：创建一台虚拟机、弹性扩容、配置中间件、数据库、配置应用程序、部署新版本应用程序、删除机器、告警、推送消息
• 协作网络：运维一、二、三线处理人员、开发人员（分布式）、需求人员、测试人员、管理人员等

信息处理四要素

一个典型的IT流程包括：从故障源采集环境信息，关联不同的环境信息，分析故障根因，采取行动（展示、推送、处理、通知）、固化知识。但是，当处理故障的规模放大，面对着多系统、多团队的软件组织，如何能够高效地完成信息的采集、传递和处理？让上文中的CIO和运维总监不再发愁？信息未来肯定是爆炸的，但是靠人来管理和协调肯定是无法满足研发运维过程的协作和沟通的。如何解决这个问题呢？

ChatOps方案

以机器人为中心的ChatOps

我们先来看看一个典型的ChatOps例子：

ChatOps完成自动化部署

在这个例子中，人可以随意地与机器人进行沟通，通过向机器人下指令，让机器人完成应用部署、部署状态检查等任务，再也不用喊嗓子叫桌子对面或者办公室另一个角落的运维人员来做这件事情了。优雅，安静。

什么是ChatOps？

ChatOps在很大程度上是由GitHub发起并推动的新趋势。简单地说，就是通过聊天机器人来完成自动化的指令，以及通过聊天机器人来自动推送输入需要的信息。为了实现ChatOps，一是需要把工具与机器人放在了沟通与协作的核心枢纽，二是需要完成现有研发、运维工作任务的梳理、标准化和自动化。

ChatOps概念图

ChatOps能够集成并自动完成的场景有：

• 代码管理系统：GitHub／GitLab - 采集代码变更的提交信息以及状态
• 持续集成系统：Jenkins／GoCD - 采集代码持续构建、集成的任务信息与状态
• 需求任务管理系统：Trello／Jira - 采集需求任务的信息与流转状态
• 运维监控系统：Zabbix／PagerDuty - 采集运维监控系统的监控状态和事件
• 运维工单系统：ITIL／ZenDesk - 采集运维事件和工单的任务和状态
• 其他办公系统：gdoc／dropbox - 采集其他办公系统的文档状态和事件
• ……

借助于ChatOps的自动化指令和规则，机器人能够代替人完成绝大部分的检索、响应和处理的工作；借助于ChatOps的机器人网络，信息处理的效率可以水平扩展，大大满足软件企业研发运维过程中信息爆炸的挑战。

ChatOps示例

下面以ScaleWorks ChatOps为例，分别展示进入聊天频道、聊天频道内以及自动化指令的系统截图，可以很清楚地看出来ChatOps的使用效果。

ChatOps效果图

真正的足不出户，家事、国事、天下事，事事关心

ChatOps落地路线

国外的ChatOps工具主要有Slack、Hubot、Lita等，国内的典型工具可以算阿里的钉钉和腾讯的微信。这些工具提供了完善的沟通协作API，通过广泛的ISV支持了不同场景的自动化和服务，譬如OA办公、系统监控以及其它服务等等。

对于自身能力比较强的技术公司，也可以通过引入开源的、免费工具链，打造一套符合自身的运维协作体系以及ChatOps平台，比较有名的产品包括Hubot、Lita等。

但是，无论是商业产品抑或开源产品，建议按照如下的节奏进行“三步走”的系统规划与建设：

ChatOps落地路线

展望

硅谷大佬Mark Andreessen提出了一个观点，“Software is eating the world”。传统行业不断地被软件侵蚀：Uber颠覆了taxis、WhatsApp颠覆了短信聊天、Fibit／Keep颠覆了健身业、Netflix颠覆了电影业……不胜枚举，ChatOps开始颠覆软件企业的信息处理也就顺理成章了。在现在的时代，依赖于文山会海、邮件往来进行信息传递和决策的企业，无法战胜通过即时聊天和自动化机器人来处理信息的竞争对手。

眼光再放长远，万物互联将是必然，人机接口（HCI）将不可避免地朝着最简单的方式演进，直至有一天，进化成为脑机接口（BCI）。到了那一天，Arthur Clark在其著作《2001太空漫游》中给出的HAL 9000机器人或许将成为人类最好的朋友。人类端坐在网络中央，等着不同边界不同节点处理好的信息进入最终的大脑；大脑的指令下发到不同边界不同节点，每个节点完成信息的处理。

正如风起于青萍之末，新的协作模式并不是“大炮一声响，换了人间”。ChatOps代表着团队集体式智慧决策以及处理信息的方式，将不断推动着手工工作的自动化和协作组织的方式。正如Kevin Kelly（KK）在《失控》一书中指出，"技术是生命体的第七种存在。人类目前已定义的生命形态包括植物、动物、原生生物、真菌、原细菌、真细菌，而技术应是之后的新一种生命形态"。

信然。

后记

文章刚收笔，又看到这篇新闻《“AlphaGo”不只会下围棋，还将为Google节约15%的数据中心用电》——

从今年开始，Google 让 DeepMind AI “接管”了部分数据中心里的一些控制单元，从简单一些的风扇、空调和窗户，到复杂的服务器本身，最后节约了“几个百分点”的电力。经过复杂的计算模型折算后，DeepMind AI 大约提高了 Google 15% 的能源使用效率……

过去，上面提到的很多开关和控制单元都需要维护人员手动操作——毕竟，人的力量还是有限的，而 DeepMind AI 却有着无限的扩展能力。

万物互联以及“机器人”对物理世界的进击速度，永远超出人类的想象。