当我们在谈论 DevOps，我们在谈论什么？（当我们在谈论时在谈论什么出自哪里）

当我们在谈论 DevOps，我们在谈论什么？（当我们在谈论时在谈论什么出自哪里）

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

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

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

如今的 DevOps 工具大致可以分为两类:

更快的 Build Test Deploy更好的 Monitoring

但是大家似乎忽略了一个方向，就是上文提到的：「协作」和「沟通」。如何打破信息不对称？如何打破隔阂？当「协作」和「沟通」的效率达到最高，团队将战无不胜。

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

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

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

Bearychat

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

BearyChat 的出现是因为团队工具庞杂，每天产生大量信息，这些信息散落在各种服务里，其中重要信息很可能会被忽略。所以一个汇集信息、提升工作效率的工具成为一种刚需。

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

协作工具的未来

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

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

好在 BearyChat 可以通过第三方工具来自定义机器人。那如何更深入地与其他产品合作呢？

如果我们对工作中的人群进行划向：设计师、研发人员、项目管理人员等等，而这些人所需要的工具是不一样的。

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

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

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

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

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

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

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

结语

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

参考文章