背景
做配置同步，机器数量非常非常多。错误波及范围在几百台，一方面我是数据流设计的太过负载没有做好功能上的取舍，造成了服务发现端与agent端双写的状态。以及由于错误的操作计划导致，不正确的异常处理造成的综合错误。
服务异常处理设计错误
- 在服务配置解析的异常处理中直接使用了暴力的进程Fatal进行处理，导致进程在初始化结束之后还在做类似的处理。每隔一段事件应该检查一下类似的问题。不然会造成明显的系统崩溃
- 历史原因： 在之前的开发中由于配置的初始化处于初始化的位置，后来因为设计修改。变成了配置重新载入时候的代码引入了此bug。
- 在抛出错误之后，并没有对系统状态，或者当前的业务逻辑进行错误处理，只处理了错误数据。比如说该逻辑应该
break 或者 continue 或者 return 这部分容易落下。
当前最高时间性价比错误避免的方法：
- 基于上面的错误发生应该反复核对设计图纸，对于服务器比较多的场景，更应该对设计图纸的重视程度反复核对有没有设计上的逻辑错误。
- 使用测试的方法来防止细节上的错误。
- 在开发中逻辑最清晰的时候在工作日志中标记出测试Case
之前模块设计的错误
由于模块设计的读写职责不够情绪，想要的功能太多，想在ETCD里面备份要同步，要故障恢复等等的功能。
导致多个进程之间可读可写，逻辑越来越复杂，BUG非常多。维护起来很麻烦。
事故小记：
- 部署计划中写的很清楚如果自动化服务发现进程在线上表现不佳，那么就可以手动删除所有配置，让线上服务器自动回复上一次配置。
1.1 因为我知道ETCD如果全挂了都没有事情。因为Agent还可以用上一次正确的配置
1.2 我测试过了任何ETCD情况下Agent是否能启动。所以不会影响线上监控。
事故过程，HBS删除数据后触发所有Agent重新读取配置，结果为空。到时json.Unmarshal Panic进程崩溃后Supervisor 或者 Systemd重启进程。
并且使用上一次正确的配置，停止当前所有监控周期，导致所有Agent监控周期同步，由于大家的周期普遍在10-30秒的范围内。进一步的
同时执行了数据库写操作，然后InfluxDB集群整个全部挂掉，才500台服务器就搞成这个样子。
之后Agent全部停掉，分批重启解决问题。
技术全局性不足，无法解决模块解耦问题，工作流读写职责问题。
- 我是知道我现在要做什么功能，应该做什么功能了。
- 我知道重要级，先做重要且紧急的事情。
- 但是模块逻辑安排在模块比较多的时候我多应该考虑考虑。这些功能加在这些模块里面是否合适。
- 应该再多思考一遍。该谁做，用何种方式做，工程成本，维护成本应该给出大概工期评估。
- 而且我没分清人和自动化之间的关系。
关于自动化
- 日常重复操作过多。
- 数据库种类过多。
- 机房有点多，每个机房的CMDB数据触发的BUG基本不同。
- 自动化来解决重复劳动的问题。以及排除由于调试时候的操作失误问题。
- 自动化解决资源调度问题，数据多，数据库多。
- 可怕！光资源调度就要搞好久。
git小习惯：
- 我的确有一个不良的习惯按照时间提交git感觉差不多了commit一次。
- 我应该做到的是，我做完一个小的事情我就要提交一次做一次备份，但是不一定push上去。
总结几个不争的事实。
- 只要我一上手动服务器，一定会出错，每次升级线上的东西都会发生这种事。而且一错就是一个机房。
- 基础太薄弱。可怕！我得好好研究研究大神怎么做到的，才能知道我现在应该做什么。就跟想完好LOL比较省力玩好的方法就是看大神的视频。
- 我们的确需要一个服务器注册与发现了。跟CMDB无关。