目前所面临的问题
目前的报警系统只能简单的把用户分为为不同的组，然后每个报警分发至一个和多个组，有的机器或服务的报警并不是每个用户都关心，太多的报警反而会降低警惕心失去报警的意义。
1. 需求分析
本来打算实现分组报警和发送报警至项目负责人两个功能，以及用户按照用户意愿选择想要的接受报警的服务等功能，不过作为一个没正经写过项目小菜同学，还是以做出东西为第一目标。所以此系统第一版只实现以项目负责人为目标的报警分发功能。
思考：每个人都希望自己的产品百分百的完美，但是世上并没有完美的东西，大家都只是在向着完美的方向努力向前而已。
1.1. 需求分析引伸出来的问题
目前我们只能实现一个功能，不过以后慢慢加入其他的功能，为了以后其他功能加入的方便，我们应该尽可能的保证程序的可扩展性。
2. 概要设计
本程序会从接受一个报警信息开始的，每个报警信息经过此系统的分发会发送至不同的用户。所以每个报警信息本身必须带有标记，用于标记自己的属性，比如属于哪个负责人。要把每个报警信息和接收人对应起来，就必须有一个对于关系表，并且此对应关系存储在某个介质上。为了方便起见，此处以文件的形式来存储报警与接收人的对应关系，最后就是以指定的方式发送报警了。所以此系统主要流程有下面三个部分：
1. 报警输入标记
2. 获取报警
3. 获取报警与接收人对应关系
4. 根据标记和对应关系发送报警
3. 详细设计
①报警输入有标记
遇到没标记的情况怎么办：得有默认的发送方式及目标
用户如何自定义标记：以配置的方式把标记的定义放入配置文件中
②获取报警
报警信息的输入只能来自prometheus的alertmanager?
把报警信息的输入设计成一个接口，此接口有一些方法，然后来自alertmanager的报警实现此接口，然后此信息就能被后续的方法获取并处理。
③报警与接收人的对应关系获取
第一版的关系来自于文件，后面的版本有可能来自数据库或者其他存储。所以此处“对应关系”的处理也是一个接口。后面所有的操作依赖此接口
④发送报警
第一版只实现钉钉的发送报警，后面可能实现一些其他的发送方式，所以此处也是接口。
4. 接口设计
接口就等着后面边实现边决定把，现在也没啥思路。毕竟我连接口都没写过呢。
总结
以前写代码，都是......不对，不应该称作代码。。。嗯。。。叫做“脚本“可能更为合适。以前写脚本呀，都是想到那写到哪，也没啥规划，类什么的真心得是懒得写。至于继承。。。作为一个小菜，我还是crtl+c/v搞定吧。毕竟是写脚本嘛，以实现暂时的目标为第一方向。不过现在呢，【我要写代码】了，已经不是简单的脚本了，要有基本的结构，不说什么高内聚，低耦合了，至少也得考虑到简单的扩展吧。当然，依然还只是以实现简单的功能为目标。至于什么并发之类的东东，还是以后版本再考虑吧。不过，即使简单也要有基本的东西。比如日志，配置文件，异常处理~
第一次写的分析肯定一点都不像个分析，但是呢，就跟写代码一样，总是要迈出第一步的，以后肯定会尽量越来越来哒，代码也会越来越好~就酱！
随时随地看视频
