近期的工作失误

Tags etcd


2016-06-23 07:04:36


背景

做配置同步,机器数量非常非常多。错误波及范围在几百台,一方面我是数据流设计的太过负载没有做好功能上的取舍,造成了服务发现端与agent端双写的状态。以及由于错误的操作计划导致,不正确的异常处理造成的综合错误。

服务异常处理设计错误

  1. 在服务配置解析的异常处理中直接使用了暴力的进程Fatal进行处理,导致进程在初始化结束之后还在做类似的处理。每隔一段事件应该检查一下类似的问题。不然会造成明显的系统崩溃
  2. 历史原因: 在之前的开发中由于配置的初始化处于初始化的位置,后来因为设计修改。变成了配置重新载入时候的代码引入了此bug。
  3. 在抛出错误之后,并没有对系统状态,或者当前的业务逻辑进行错误处理,只处理了错误数据。比如说该逻辑应该break 或者 continue 或者 return 这部分容易落下。

当前最高时间性价比错误避免的方法:

  1. 基于上面的错误发生应该反复核对设计图纸,对于服务器比较多的场景,更应该对设计图纸的重视程度反复核对有没有设计上的逻辑错误。
  2. 使用测试的方法来防止细节上的错误。
  3. 在开发中逻辑最清晰的时候在工作日志中标记出测试Case

之前模块设计的错误

由于模块设计的读写职责不够情绪,想要的功能太多,想在ETCD里面备份要同步,要故障恢复等等的功能。 导致多个进程之间可读可写,逻辑越来越复杂,BUG非常多。维护起来很麻烦。

事故小记:

  1. 部署计划中写的很清楚如果自动化服务发现进程在线上表现不佳,那么就可以手动删除所有配置,让线上服务器自动回复上一次配置。 1.1 因为我知道ETCD如果全挂了都没有事情。因为Agent还可以用上一次正确的配置 1.2 我测试过了任何ETCD情况下Agent是否能启动。所以不会影响线上监控。

事故过程,HBS删除数据后触发所有Agent重新读取配置,结果为空。到时json.Unmarshal Panic进程崩溃后Supervisor 或者 Systemd重启进程。 并且使用上一次正确的配置,停止当前所有监控周期,导致所有Agent监控周期同步,由于大家的周期普遍在10-30秒的范围内。进一步的 同时执行了数据库写操作,然后InfluxDB集群整个全部挂掉,才500台服务器就搞成这个样子。

之后Agent全部停掉,分批重启解决问题。

技术全局性不足,无法解决模块解耦问题,工作流读写职责问题。

  1. 我是知道我现在要做什么功能,应该做什么功能了。
  2. 我知道重要级,先做重要且紧急的事情。
  3. 但是模块逻辑安排在模块比较多的时候我多应该考虑考虑。这些功能加在这些模块里面是否合适。
  4. 应该再多思考一遍。该谁做,用何种方式做,工程成本,维护成本应该给出大概工期评估。
  5. 而且我没分清人和自动化之间的关系。

关于自动化

  1. 日常重复操作过多。
  2. 数据库种类过多。
  3. 机房有点多,每个机房的CMDB数据触发的BUG基本不同。
  4. 自动化来解决重复劳动的问题。以及排除由于调试时候的操作失误问题。
  5. 自动化解决资源调度问题,数据多,数据库多。
  6. 可怕!光资源调度就要搞好久。

git小习惯:

  1. 我的确有一个不良的习惯按照时间提交git感觉差不多了commit一次。
  2. 我应该做到的是,我做完一个小的事情我就要提交一次做一次备份,但是不一定push上去。

总结几个不争的事实。

  1. 只要我一上手动服务器,一定会出错,每次升级线上的东西都会发生这种事。而且一错就是一个机房。
  2. 基础太薄弱。可怕!我得好好研究研究大神怎么做到的,才能知道我现在应该做什么。就跟想完好LOL比较省力玩好的方法就是看大神的视频。
  3. 我们的确需要一个服务器注册与发现了。跟CMDB无关。

本人博客文章采用CC Attribution-NonCommercial协议: CC Attribution-NonCommercial 必须保留原作者署名,并且不允许用于商业用途,其他行为都是允许的。