自动化(2.27)

自动化对提升我们工作效率至关重要，特别是对于 程序员 更加应该具备自动化思维，即不要在完全重复的事情上面浪费时间，也就是在编程思维里面我曾经谈到的一个关键内容。

1. 将完全重复的事情自动化掉。

2. 将相似或有共性的事情先抽象和模板化，然后再进行自动化。

对于第一点相信很多人都能够做到，最难的还是在第2点，即如何去发现哪些是相似和具备共同特征的事情，并对这些事情进行抽象，在抽象后进行模板化和参数化，然后再自动化。而这个往往考验的就是一个人的抽象能力和建模能力，当然也是考验你认知和分析事物的能力。

最近工作，我们来看哪些工作是可以考虑自动化掉的内容。

IT基础设施环境，应用的日常巡检工作

为何有了统一的IT网管，或APM监控平台还需要做日常巡检？这个主意还是当前的IT网管或APM无法对所有我们关心的指标做到实时监控，特别是一些和应用相关的个性化指标。那么这些内容往往就需要我们自己去监控。实际做法应该是了解清楚我们当前人工是如何做该事情的，然后在将人工做的内容自动化和脚本化掉。

例如通过 Python 来写相关的自动化巡检脚本，采集相关的性能指标数据，制定相关的告警规则，在触发预警规则的时候自动发送相关的邮件。同时自己定义轮询周期和时间间隔。

服务运行监控的自动化

对于服务运行监控，我们不断的在做新功能，包括原有的服务监控告警，业务系统异常监控告警，心跳检测，业务系统的心跳检测等诸多功能。但是当前我们还是会人工进行服务运行监控，这个说明我们的监控规则还没能做到标准化和模板化，只有在大量监控分析后这些规则或参数才能够定下来。

这个服务运行监控实际上最难的是异常告警本身的升级机制应该如何？

比如监控ERP系统出现业务系统异常告警，我们系统实现是按照服务总异常数或总的出现错误服务数告警，而这种告警我们很难去判断究竟是一个小范围问题还是一个大面积故障。

因此监控自动化最核心的还是出现问题的严重程度判断，对于这块的判断准则我们需要从人工转到系统判断，一个小问题我们通知到接口人就可以了，但是如果一个大面积的问题我们就需要通知到多个业务系统，甲方客户，合作伙伴等多个点。

最近的监控预警我们发现，最难的不是监控指标，而是告警准则和严重程度的判定，这些参数没有设置好那么就出现大量的监控告警邮件通知和误判，对于这种大量邮件我们接收后往往也很难有精力一个个的查阅，然而是全部删除掉都不看。那么监控的意义本身也就失去了。

包括监控的时候，我们还得考虑系统发版等特殊情况。否则仍然是大量垃圾邮件通知。

服务运维周报和月报的自动生成和推送

这个我们当前需要人工进行周报和月报的整理，然后人工发送邮件。按道理这个也是可以做到完全自动化的。当然如果我们的周报是PPT格式，估计实现起来相对来说比较困难。如果是Excel格式的话，我们可以提前定义清楚Excel格式模板，包括提前定制好的图形展现，然后通过程序代码对数据进行自动填充即可。

周报月报上除了数据呈现外，还有相关的总结分析的话，而对于这部分内容也可以进行模板化和参数化。只要可能出现的业务场景和异常规则定义清楚，那么相关的文字内容就完全可以参数化和自动生成。

当前在管控我们已经实现了按业务系统维度的服务运行日报和月报显示，包括大量的图形化展示，对于这块我们一直在考虑对于前台界面已经生成出来的内容，能否直接存储为图片，然后将图片通过邮件发送？

如何从单纯的系统运维和问题发现，走向实际的服务运营，是后续SOA治理管控考虑的一个关键问题，也是SOA治理管控价值挖掘的一个重点。即从服务的运行统计分析，我们可以间接反应出来当前多个业务系统之间集成交互的效率，质量，跨业务协同的效率和质量等。

其它日常运维工作的自动化

除了上面的，在运维方面还有很多工作我们需要考虑自动化。类似网络策略开通后的自动化验证，类似数据库表的备份导出，压缩等。这些日常常态化的操作也可以考虑通过运维小 工具 全部自动化掉。

任何一次发现故障或问题，都需要反思是否在前面已经做了监控，如果做了监控就要考虑维护没有监控到。如果没有做监控就需要考虑如何去增加新的监控指标和监控规则。并最终将相关工作完全自动化掉。