不知不觉中，自己已经成了一个老员工。这么多年，基本可以说或大或小，监控都是工作的一部分。负责监控的工作可以说从根本上提升了我的技术能力，但是并不是负责监控就能提升技术能力，最重要的还是自己对自身能力的认同。

无论是早期的OVO、之前的Nagios或是现在的Zabbix，作为扩展能力较强的监控系统（其实不光光是监控系统）来说，自带的功能能够满足我们需求的70%~80%，那些无法满足的怎么办呢，扔那里么？负责监控，就需要将力所能及的部分都实现了。

“你的能力有多大，你的责任就有多大”——这句话想必看过《蜘蛛侠》的朋友们都很耳熟。自身的能力如同一个瓶子，大小由你的看法设定，装多少、装什么由你的行动决定。监控的工作就是这样，有些事不是你做就是SA做，做了对能力有提升，做不了的没办法，能做而不想做的只能撇撇嘴了。

一日，需求分析时，获知要在Windows系统中检测某些cmd脚本的运行情况，处理步骤如下：

1、查找监控系统是否支持此功能——主要的功能都在脑海中，比较偏门的就不太清楚了，好像有吧——查得支持Linux的，Windows真可怜。

2、不支持此功能，我们能否通过脚本实现？Windows下脚本环境有BAT、VBS、Powershell、WMI等等，其中一个能够实现就可以了。所谓外事不决问Google，Google不稳定么，HTTPS的总可以了吧，金盾二期依然搞不定HTTPS。网上只要有一个案例就够了。

3、等等，第2步该我们管么？我们不是只负责监控么——监控工作包含服务器端和客户端，其实SA（系统管理员）应当只提需求的。但是现实是人手依然紧张，部分需求可能SA能够自身完成的我们就拜托给SA了。其他的我们应当尽可能实现，多学一些总是好的。

因此负责监控的领域知识和专业度要求比较高，比如对Windows的了解，为了要明白监控什么，如何监控，你必须对Windows整体有一个大概的了解，知道那些计数器能够反映什么，知道那些内容是可以通过脚本获取的，哪些不能等等。这些方向，其实前期内部Windows培训都有介绍过，不过很浅而已。

当然，部分特殊的对象我们可能没有办法监控，比如说某系统页面是用内部的一个网页表示系统状态，使用了红黄绿3个灯，要求监控红灯亮起时的状态——看了下源码，尼玛不管亮不亮，灯所使用的图片名字都不变的……爱莫能助了。

4、实现之后就要部署，调试等工作在测试环境中做就行了，别拿到正式环境中，否则很难说没有影响，调试出问题那就麻烦大了，切记。

5、这还没完，部署之后要确保正常监控——也就是说，当SA部署完成后，各项指标应当是正常的，我们不能在部署后监控状态一直处于故障状态（话说首次告警可以检测通知规则配置正常没:)），所以必须要全部正常后才能说监控配置工作完成了。

6、最后就是总结下，哪些工作做了，哪些工作没做（什么原因），反馈给SA和相关人员确认，至此，工作完成。

负责监控的我们现在多做一些工作，监控的质量就能提升一些，SA就轻松一些（虽然对于SA能力提升没什么帮助）。

另外，希望咱们的SA未来都会脚本，Windows下Powershell、BAT、VBS（太多了吧，请联系MS，他们没事就知道乱搞），Linux下主要就是Shell、Python了。脚本能够解决工作中的不少问题。