有关运维监控的反思
推荐 原创
©著作权归作者所有:来自51CTO博客作者chcearth的原创作品,请联系作者获取转载授权,否则将追究法律责任
SteveY之前意外的公布了一篇博客(原文链接:http://coolshell.cn/articles/5701.html),其中有一段有关亚马逊系统监控的描述。
监控与QA是被统一了。如果你不进行一个大规模的SOA,你就不会这么去想。但是,等到你的Service说,“是的,我还好!”,但实际情况可能是,服务器里唯一能正常运作的功能就是一个快乐的机器声音在呼叫你:“我很好,收到,收到”。为了要确认整个服务能正常运作,你需要对Service的每一个部分都去Call一下。这个问题会以递归的形式地出现,直到你的监控系统能够全面性地系统地检查所有的Services和数据,此时,监控系统就跟自动化测试QA没什么两样了,所以两者完美的统一了。
这是在他眼里亚马逊解决的问题中最具代表性的几个之一。
在呆过的公司里,几乎没有人考虑到过程序的监控或测试接口。即使有人想到过,也只是也做得不全。如果出了问题,客服第一个发现,然后我们就把开发前端测试dba全叫过来,大家一起查问题,一起花半天或一天扯淡,然后花半小时查出问题所在。最后把现象监控起来。
所以基本的情况就是:出了问题才有人过来说,那个程序不稳定,你写一个监控它是否存在的脚本。或者是:这个服务器有问题,你多注意一下load或cpu,不能太低也不能太高。(我靠!你自己写的破程序关服务器鸟事)
我们要提供的是服务而不是运算量好不好!如果服务上线时都能提供服务监控或测试接口,这就不用靠客服才能发现问题了;如果每个服务都有自己的api,那么大部分单靠自动化QA就可以发现原因所在或基本方向。
之前上线了一些服务,我常常收不到开发和测试文档(深恶痛绝之!)。所以我就去问开发人员,怎么才能确认你的服务是不是正常的?他回答,用户在页面上勾选A和B之后点再查询可选的C的类型时出现那样那样界面就是正常的。
tmd!如果用户勾选不了A和B会不会是你的问题;如果某用户确实在数据库中没有相应数据,你的服务会出正常的格式吗?遇到的程序员里面只有少数几个能在着手开发之前写好开发文档,考虑到可能会出现的问题。这样交付以后出了问题我们自己对文档就能定位,省去好多扯淡的时间。
还是那句话,我们要提供的是服务。现在市面上提供系统监控的工具大把大把的,几乎随便一个运维人员都可以在一周之内把100台以上的linux服务器的系统监控起来。但是服务呢?只有少数几个公司的某几个小组能保证吧。我也做过那样的努力,但是总是遭到冷漠或敌视的对待,最终逃不过失败或流于形式的结局。大家意识不到稳定性的重要性而得不到支持,才是最重要的原因吧。
发点牢骚。见笑见笑。
![](https://ucenter.51cto.com/images/noavatar_middle.gif)
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
检讨
检讨
检讨