当咱们在谈论 DevOps，咱们在谈论什么？

Cloud Insight 携手 BearyChat：打造适合运维人员的团队协做工具

走过 C 轮的 OneAPM，旗下的产品已经日渐丰满，从应用性能监控的 Application Insight 到系统监控工具 Cloud Insight，再到安全产品 OneRASP，以及日志分析工具 .LogInsight。而今，咱们一直困顿于一个问题：监控帮助人们更快地发现了问题，而解决问题的落点在哪？

机器尚未智能到能够帮助咱们修复代码中的问题，没有办法解决一个页面的 SQL 时长长达 5000 ms 的问题，也没有办法权衡计算资源的流向。

当咱们深刻 DevOps 这个方法论，以及思考 Slack 的流行，咱们发现「协做」和「沟通」，也许是帮助咱们更高效地解决问题的解决之道。

DevOps 和 ChatOps

DevOps 这个一再被人们说起的概念，在实际操做中，这个方法论其背后的实际操做方法，和项目管理的手段是什么样的，甚少有人能够给出一个完美的答案。

DevOps 在最初，是让开发、运维、QA 之间增强沟通，经过不一样的工具来消除隔阂。而隔阂的造成有两个缘由，一是信息不对称，研发没法获取到运维的数据，运维也没法解读代码的错误信息；二是所秉持的价值观、方法论的不一样，不一样部门之间的目标也所以有差别。说得实际一点，就是由于 KPI 这座大山形成了不一样部门之间的对责任的逃避，而 DevOps 是倡导你们一块儿来面对问题、解决问题。

开发环境和部署环境的快速迁移，帮助产品快速上线；愈来愈多的监控工具，明确负载问题是计算资源不足的问题，仍是代码质量的问题。

咱们来看 stackshare 排名前 10 名的 DevOps 工具：

现在的 DevOps 工具大体能够分为两类:

• 更快的 Build Test Deploy
• 更好的 Monitoring

可是你们彷佛忽略了一个方向，就是上文提到的：「协做」和「沟通」。如何打破信息不对称？如何打破隔阂？当「协做」和「沟通」的效率达到最高，团队将望风披靡。

Slack 的流行让这个方向又重获生机：ChatOps。

ChatOps 是诞生于 GitHub 的一种基于会话驱动的协做开发方法，过去团队之间的通信和开发操做是两层皮，致使各类不透明和低效率。ChatOps 将开发工具带入开发者聊天室，经过定制的插件和脚本，一个聊天机器人可以执行聊天中输入的各类命令，实如今聊天平台上的团队协做开发自动化，把团队沟通和执行统一整合到一个可视化更高的聊天环境中，“聊着天就把事情办了”。

咱们来看下 WIRED 杂志对 GitHub 系统主管 Sam Lambert 的采访：

当你走进 GitHub 的大厅，在前台的 iPad 上登陆后，全部计划与你会面的人都会收到一份通知。GitHub 的系统主管 Sam Lambert 对 Wired 网站说，Hubot 是公司工做最努力的员工。这是公司内部的一个玩笑。其实，Hubot 是嵌入到 Github 聊天系统里的软件，或者说，它是个聊天机器人。

经过向 Hubot 发送信息，工程师们能够升级服务器上的系统，删除数据库中的数据，甚至让所有的服务器下线。在公司外部，Hubot 被称做是 ChatOps 工具。就是说，它可以处理运营任务，好比设置新服务器和数据库，或者升级 GitHub 网站背后的代码。ChatOps 是 Github 自造的单词，不过，这种想法来源于软件界的 DevOps 运动。经过一些新型的软件，工程师们可让公司内部的大量硬件和软件实现自动化设置和升级。ChatOps 添加了对话元素。“GitHub 网站天天的升级都是经过聊天机器人完成的。” Lambert 说。

ChatOps 这项 GitHub 自创的运动，的的确确为 DevOps 中「增强沟通」带来了实质性的进展。

而硅谷的 Slack 这块团队协做的明星产品的流行，说明 ChatOps 正在往产品化的方向上行进。

BearyChat

经过会话来增强沟通，从而更高效地解决问题。在国内，就要说说 BearyChat 了。

BearyChat 的出现是由于团队工具庞杂，天天产生大量信息，这些信息散落在各类服务里，其中重要信息极可能会被忽略。因此一个聚集信息、提高工做效率的工具成为一种刚需。

固然，除了界面，产品自己的功能是最重要的，BearyChat 在团队讨论上除了基本的文字沟通，还接入了各类第三方服务，好比图片和视频直接显示，网页连接直接抓内容，以及展现 Github 代码片断、Trello 列表等功能，尽量将影响团队协做流程的操做简化（如点击、跳转等等）。

除了整合梳理信息的功能，BearyChat 还有一个相似于 Workflow 的机制，他们称之为机器人。在小编看来，Workflow 是提高效率的关键功能，Mac 内有自建的 Automator，网络上有著名的 IFTTT。从 If this then that 的逻辑上延伸，BearyChat 的机器人应该是内容的搬运工，好比项目代码一旦更新会自动发送到讨论组这样的功能。

协做工具的将来

康威定律说：设计系统的组织，最终产生的设计等同于组织以内、之间的沟通结构。

若是一款团队协做工具，作到了通用，却没有根据组织内部的沟通方式、工做方式来作配合，最终沟通和协做的效率会大打折扣。

好在 BearyChat 能够经过第三方工具来自定义机器人。那如何更深刻地与其余产品合做呢？

若是咱们对工做中的人群进行划向：设计师、研发人员、项目管理人员等等，而这些人所须要的工具是不同的。

设计师须要 Adobe 的 Creative Cloud 来随时随地访问他们的文件，须要 Behance 和 Dribble 的推送来扩展视野。研发人员以 Cloud Insight 研发组为例，须要 GitLab 的变动管理，须要 Docker 的管理工具，须要基于 Bara 的测试环境部署的变动管理等等。

而不一样工种的关注点，和沟通方式也是不同的，而且围绕的话题、和传输的文件的特征也是不同的。

单就运维这个工种来讲，他们须要关注的点包括：

• 每一项指标的历史曲线图
• 报警产生的事件
• 出现异常点时的解决方案
• 高级工程师和初级工程师之间的沟通
• 对基础设施的控制

也就是说，若是一个团队协做工具不可以针对某个特定工种，根据他们的关注点作适配，最终沦为一个通用级的工具，是没有将来的。这也是加速了像 Slack、BearyChat 这样的团队协做工具，和其余第三方工具合做的缘由。

而今，Cloud Insight 和 BearyChat 的合做，就是为了打造一个适合运维工程师进行实时沟通与协做的一体化工具。

Cloud Insight 是一款系统监控工具，可以监控操做系统、数据库、中间件的运行状况，并根据指标产生报警。也能够经过 SDK 上传任何指标，来作集中的展示和管理，包括：业务指标、应用性能监控指标等等。

所以，参与到 Cloud Insight 这个工具的人员，不止运维人员还包括研发人员、管理人员，甚至运营人员。而团队协做也是 Cloud Insight 不可或缺的功能。Cloud Insight 事件流就是聚集报警、探针启动和操做历史记录于一身的功能。

不一样工具之间的相互整合，在 SaaS 这个环境中意味着更多的可能性，更多的使用场景，给用户带来更多的选择。

结语

性能监控的意义在于让运维变得高效、智能。团队沟通、协做的根本目的也在于经过一切方式提升效率。DevOps 是倡导你们一块儿来面对问题、解决问题，经过 Cloud Insight 及时发现性能问题，这时候再由于BearyChat
的快捷和易用让解决问题的过程不那么痛苦。有着一样的情怀和期许，Cloud Insight 和 BearyChat 的合做势必成为一件 1+1 > 2 的事。

参考文章

1. The Most Important Startup's Hardest Worker Isn't a Person

2. DevOps 年中盘点：国外最受欢迎的 10 篇技术文章（下）

3. IT 人士耻于下问但又不可不知的“聊天运营” —— ChatOps

本文系国内 ITOM 管理平台 OneAPM 工程师编译整理。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客