您的位置:首页 > 运维架构

为什么很多公司都自主开发监控系统?

2015-12-08 13:49 405 查看
在互联网业务蒸蒸日上的今时今日,系统架构日渐复杂,开源的监控产品层出不穷。然而仍然有很多公司选择自主研发监控系统,那么,现有的较为知名的开源监控系统 cacti、Nagios、zabbix 等其他商业系统,有什么方面不满足公司的需求吗?网上有人说,监控粒度和深度是不满足个性化需求的点,但这种说法很难理解。

知乎上有一条回答挺有意思,下面来看看 OneAPM 产品经理程默是怎么回答这个问题的吧。

一个产品经理的回答

其实这个问题可以延伸到,为什么很多公司都自主开发订餐系统,很多公司都自主开发客户管理系统,为什么很多公司都打算自主开发运营监控系统?

除开生产力过胜,和可恶的 KPI 之外,我觉得还有一些其他重要原因吧。

很多答案里提到了当业务变得慢慢复杂起来,开源的、第三方的监控解决方案,不能满足需求,我觉得说不通。拿一张图来说话吧:



上图来自一家分享和发现各 IT 公司使用什么工具的网站:StackShare——Discover and discuss the best dev tools and cloud infrastructure services

可以看到 Facebook 用了 Datadog 来做运维监控,Netflix 用了 Boundary 来做运维监控。

那么,那么多业务量巨大的公司,在监控这块依旧使用 Datadog Boundary 这样的第三方监控解决方案。

说明业务量大、逻辑复杂,根本不是要转向自己来研发这些系统的原因。

那为什么还要反复地造轮子、造轮子、造轮子呢?以我这几年的工作经历说说吧。

领导是傻 X

我现在所从事的刚好是给企业提供第三方监控解决方案的工作。在跟很多企业提供解决方案的时候,项目实施到一半,可能在监控本身需要加入:

你们能不能顺便把 IT 资产管理也给做了?

你们能不能帮我们做下整个园区的 3D 建模?

你们能不能按照我们的行政划分,把每项监控事宜都落到个人头上?

这就是楼上很多人提到的所谓业务复杂,本身业务不复杂,只是领导们的要求很复杂。管理本身存在很多问题,不能够将一件大事情细分到每一项具体的事情上。而领导们觉得自己只需要考虑全局,中层干部们也没有理顺领导的要求并拆分领导的要求。

工具能够帮助我们将每项具体的事情变得更高效,但是解决不了实际情况中某个大的命题。

我一直坚信:工具是让聪明人变得更高效,而不是让傻 X 变得牛 X。

当上层领导只能按照行政、业绩来划分具体实施人员的工作时,运维的监控这件事情就可以扩大到一个漫无边际的地步,并且和自己的行政划分、规章制度高度耦合。

有情怀的程序员太少

就拿系统监控工具这件事情来说吧,国外有 Host Graphite、Boundary、Datadog 等等。国内除了小米的 Open-Falcon互联网企业级监控系统 和 OneAPM 的 Cloud Insight, 鲜少有一些真正易用的、开源的、产品化的工具,来帮助我们解决某项具体事情。

但是大公司内部,却有很多人在帮助所在的公司做这些事情。但是没有想过自己做一款产品是什么样的,也没有思考过从头开始经营一款自己的产品是啥样的。

活在大公司里,盼望着过 KPI、期待着公司上市后期权可以兑现。

中国的开源和 SaaS 服务落后于国外,很大一部分原因是因为企业文化的差异和制度本身的问题吧。

总的来说,就是程序员们都在造轮子,而且轮子越造越大,可能只适合所在的企业。没有想过自己的轮子,可以形成通用化的产品。

没耐心

将一个产品吃透,按照这个产品的设计思路来指导自己的工作。我觉得比自己本身去研发一个产品效率要高很多啊。

打个不恰当的比方,设计师觉得 Photoshop 不好用,因为用钢笔要练习,而且 Photoshop 本身也不能给自己拓宽视野和给风格带来影响。所以决定要自己研发一个取代 Photoshop 并且更适合自己的产品。

也许还不适合自己公司在交接工作中的流程,行政部门打不开 PSD 文件,具体实施的人没有要求换成 CMYK 就印刷了。

幸好大部分设计师不具备研发的能力,只好耐着性子去学习了。

其实很多工具在经过反复的迭代和设计时,都透漏着设计者本身的一些方法论和思想在里面。有些成熟工具不好用,或者很麻烦,其实可能是使用者本身的工作方式有问题。

题外话

最后做个广告吧。之前提到我也是做系统监控工具服务的,我们有一款系统监控工具 Cloud Insight:安装简单、UI 美丽、未来会有再开发能力。爱用不用,不用拉到。啊哈哈,上几张图。







说一下 Cloud Insight 的产品规划吧。我们正在做事件处理,有参考国外的 Bigpanda,主要方向是报警风暴的处理、事件的聚合,以及动态门限类与算法有关的报警策略。

然后我们也用到了 OpenTSDB,架在了 HBase 上,负载还不错。虽然在公测,但是每天处理的数据量还是挺大的。

至于行政和规章制度需要架在产品里,我指的不是报警需要分发到不同的人、并且选择不同的渠道来分发。这些一般的第三方工具,和开源工具集成一些渠道,都可以做到。

我指的是,之前面对的企业客户。可能老板根本不需要看指标,老板需要看机房里每天机器是不是 DOWN 掉了,还需要很酷炫的 3D 建模。

而真正的实际操作人员,又需要到很具体很具体的指标,甚至每个单位都需要落实到产品里。

一个工具不可能自上而下地解决管理上的问题,我们的目标是通过一个像 JIRA 的工具来达到通用的、科学的管理,而不是把这个工具做到跟公司一些很腐化的制度绑定在一起。

就像有些公司项目管理做得很烂,JIRA 用不起来,所以去找国内一些软件公司来做一个和自己制度高度耦合的项目管理软件,并天真地以为可以解决问题。

总结一下

按照程默同学的观点,业务量大,逻辑复杂并不是根本原因,毕竟 Facebook、Netflix 这样的大公司都选择了第三方监控产品。而领导们复杂的要求,程序员们遵循任务重复造轮子,和使用第三方监控产品所需要的学习成本,才是很多公司自主开发监控系统的原因。

然而究竟自主研发和使用第三方监控工具哪一种更好,还是要综合公司的资源等实际情况来考虑,对于没有足够精力和实力自主研发和维护监控产品的中小心公司来说,开源的、免费的监控产品无疑是福音,对于需求清晰,不愿重复造轮子的大公司来说,一款好的第三方监控产品想必也是进步征途中的利器。(备注:本文中引用部分经过程默同学同意。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: