独力的服务验证系统

最近在和同事开发新的小系统。

我们的目标是对服务做验证、检查。 各种已经被部署并被使用的服务、系统。

比如：数据库是否可读、cache服务器是否可链接、初始化配置是否正确等等。

这些验证需求在平时会夹杂在：自动安装、配置过程中，Nagios报警的定制插件，Puppet同步时的校验检查，排查突发故障的过程。

由于这些业务过程都会有验证工作，因此非常零散。

有这样一些例子，比如：

1.当你遇到故障或新部署服务器后想完整校验一次服务器或服务时，很困难，或者是能够用的程序都分散在Nagios插件，安装脚步，Puppet校验配置中没法一目了然或者就是程序与当前领域结合太紧密，没法单独使用，比如：安装服务器时有很多检查，但难免检查失败后会尝试重新配置，代码一来二去耦合的紧密了。

2.当你在云计算平台，深夜负载过大时，工程师还在睡觉，系统自动安装了一批服务器并投入使用了，安装中出问题在所难免，比如中途网络问题，一些配置文件没有覆盖，校验失败后，再次同步还是失败，服务已经online了，但不能用，也没有任何报警信息，因为Nagios监控的很粗糙，它不关心http服务器的puppet是不是安装了，它只关心http服务有没有。

我们将所有验证的需求整合到独立的系统中，有如下的优势：

1.验证变成独立的服务，通过API与其它系统通信，使整个大的系统更加灵活，大的系统由独立的子系统组成，子系统通过API互相服务，都是独立的Services.任何系统都可以找到对应的方法去检查，任何系统在执行过程中也都可以调用验证来保证服务正确，并根据结果来做出更合理的操作

2.CMDB存储了服务器安装、配置的方法，也可以保存验证的不同方法，对任意一台服务器或一批服务器都可以根据现有的资源重复检查

3.验证可以做的更细致，同时更少的冗余。

我们认为一个自动化的系统中，理想的状态依然是降低人的投入和操作风险，人应该更多的关注特例和突发问题，对于可遇见的，可归类的问题要努力的自动化。工程师大部分的时间是完善系统的不足，提供更多细致的程序，系统应该是自己在运行着。