有关运维监控的反思

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服务器的系统监控起来。但是服务呢？只有少数几个公司的某几个小组能保证吧。我也做过那样的努力，但是总是遭到冷漠或敌视的对待，最终逃不过失败或流于形式的结局。大家意识不到稳定性的重要性而得不到支持，才是最重要的原因吧。

 

发点牢骚。见笑见笑。