软件稳定性运营总结和典型案例分析

2022和2023年一级以上事故，2024一整年事故总共154案例 进行分析：

类别	标签	事故数量	三级以上事故
项目管理	需求沟通	27	0
程序开发	业务逻辑错误	23	0
项目管理	配置问题	21	0
程序开发	数据库设计和sql	18	3
运维	监控	15	1
运维	基础设施维护	15	1
程序开发	线程管理	14	3
程序开发	系统健壮性	13	1
运维	部署架构	9	1
项目管理	版本控制：	9	0
程序开发	内存管理	5	0
运维	负载均衡	4	0
运维	权限控制	4	0
程序开发	缓存一致性	2	0

 

（  备注：一个生产事故发生原因复杂 ，一个事故有可能多个标签会有重复计算的情况。比如某事故是由：”需求沟通“，”配置“导致。所以“数量”类所有数量加起来大于 154。）

      要减少生产运营更加稳定从最简单工作开始：需求沟通清楚明确，业务逻辑核对和测试、配置管理规范等。要想系统在高并发下或者极端情况下不出大的问题就必须做好线程管理、数据库设计和sql编写并做好监控。在基础设施维护时做好预案。

如果在代码开发多考虑系统健壮性的设计和版本控制，在部署考虑高峰期业务量，这样就可以防止80%以上的生产事故的发生，支持公司的业务发展。

 

1、缓存一致性：

总样本：2  全部是二级事故

1) 缓存一致性问题主要原因

ü 版本升级需要清除旧缓存没有清除：

解释：比如上线一个新的功能，但是旧的缓存没有删除或者过期导致新的功能还是读取旧的缓存信息。

ü 缓存策略使用不当：

解释：并发情况下使用了不恰当的缓存策略。删除缓存策略有先删除缓存再更新数据库、延时双删等。

2) 典型案例分析

l 案例1：【二级事故】20231206 【决策】因规则下线功能缺陷导致阿里云数据源调用异常产生额外费用

ü 原因：在新版本未生效时，下线的规则使用的变量有缓存，依然存在调用

ü 现场解决措施：

    1、删除旧缓存

    2、屏蔽规则批量下线功能，就算旧缓存能获取到也不会有任何的损失

ü 后续优化措施：

1.修复规则批量下线功能 

2.对下线的变量做调用监控，如果调用量没变化，则提示告警

3.数据源调用量和决策使用量的对比监控 

ü 事故标签：二级事故

ü 事故划分依据：

3) 总结：

缓存相关的事故主要集中在两个方面：缓存一致性问题和缓存使用不当：

ü ‌缓存一致性问题‌是导致系统行为异常的主要原因之一‌：在分布式系统中，数据库和缓存之间的数据同步是一个复杂且容易出现问题的环节。一旦缓存中的数据与数据库中的数据不一致，就可能引发一系列的问题，如误拒、误判等。解决这类问题需要加强缓存与数据库之间的同步机制，并增加相应的监控和告警措施。

ü ‌缓存使用不当‌则主要体现在缓存的配置和使用方式上‌：不合理的缓存配置可能导致系统性能下降或资源浪费，而错误的使用方式则可能引发更严重的系统异常。解决这类问题需要对缓存的配置和使用进行严格的规范和审核，并确保相关人员具备足够的缓存使用知识。

综上所述，对于缓存相关的事故，我们需要从加强缓存预数据库之间的同步机制、优化缓存配置和使用方式、增加监控和告警措施等方面入手，以降低故事发生的概率和影响。

2、业务逻辑错误：

  总样本：23  事件：17  一级事故：3  二级事故：3

1) 业务逻辑错误原因

ü 该return 没有return：

ü 业务变化导致原来逻辑出现问题：

解释：比如订单就是一个订单，业务需求变成一个主订单一个副订单。

比如原来查询条件少，现在查询条件多才能查出一样的效果

比如一个新需求影响原来的功能

ü 程序处理逻辑错误：

解释：日期截取错误导致日期读取错误

ü 重点节点判断出错：

解释：订单初始支付通道支付失败，切换通道重新支付时，推送SAP的配置信息没有正确更新。

ü 没有幂等判断或者幂等判断出错：

ü 校验判断过滤不够严谨，缺少容易忽略的关键条件：

解释：送的全量逾期订单时包含了还款订单，不应该包含

ü 业务场景考虑不全导致错误输出：

    解释：返回码错误 或者 权限输出错误

 

2) 典型案例分析

l 案例1：会员重复退费

ü 原因：

1. 会员退费业务，定义了四个业务状态，1退费申请中（中间态），2退费成功，3退费失败，4退费待确认（中间态）。

2. 退费申请时，会判断如果会员订单对应的退费订单，状态为1or2时，不允许再次发起

3. 续费会员需求上线后（2022-10-11），对于3个月以上的会员会走VPC的代付模式。此时对于退费中的状态，会改成为4

4. 对于为4的状态，营销中心未进行卡控，测试时未测试重复退费场景，故出现了重复退费，

ü 后续优化措施：

1.会员退费申请前置校验加上状态为4的卡控 

2.基于营销中心在退费申请时传的支付订单号，进行不可重复退费的卡控

3.补充测试案例，每个场景都需要增加重复退费案例

ü 事故标签：事件

ü 事故划分依据：

 

l 案例2：因代码缺陷导致B决策结果异常产生误放款

ü 原因：征信规则拒绝，但因代码缺陷（该return没有return）导致决策通过。

ü 后续优化措施：

1.涉及决策流程调整需求将征信规则通拒场景纳入回归场景中

2.涉及决策流程调整需求将征信规则通拒场景纳入UAT测试中

3决策工作台增加对征信拒绝而决策结果通过的异常数据的监控

ü 事故标签：一级事故

ü 事故划分依据：

l 案例3：部分催收坐席利用代码缺陷推测客户手机号

ü 原因：因需给高级账号展示身份证号码，此处控制存在代码缺陷，导致系统页面源码内存在身份证号码信息

ü 后续优化措施：

1.后台增加敏感数据输出门禁控制

2.统计和监控接口数

3 敏感信息增加回归必测用例

4 敏感信息相关改造增加设计和codereview

ü 事故标签：二级事故

ü 事故划分依据：

3) 总结：

业务逻辑错误导致的生产事故在多个层面都有体现，包括代码设计缺陷、需求理解错误、配置不一致以及流程设计不合理等。这些事故往往对业务造成直接影响，如服务中断、数据错误、客户体验下降等。为了减少和预防此类事故，需要采取以下措施：

ü ‌深化需求理解‌‌：在需求实现前，与开发、测试团队充分沟通，确保对需求有准确的理解

ü ‌优化业务流程‌：对业务流程进行定期审查和优化，确保流程设计合理，关键节点有必要的校验和监控，上生产进行产线验证。

ü 增强代码的健壮‌‌：就算逻辑出了点问题也会最大 范围减少损失

ü 重要判断节点进行评审‌：跟测试一起评审，更容易发现问题

ü 新需求修改尽量跟原来的代码解耦：减少新需求影响旧功能的情况

3、线程管理：

  总样本：14 事件：9  四级事故：1  三级级事故：2  一级事故：2  

1) 业务逻辑错误原因

ü 并发下线程锁问题：

    防止锁的相互等待

ü 线程资源监控问题：

未对线程池的使用情况进行监控，导致线程池资源耗尽时未能及时发现。

    未对线程任务的执行情况进行监控，导致任务失败或超时未能及时处理。

ü 线程安全问题：

    任务并发需要对主内存的管理

    工具类是否线程安全

  全局变量是否线程安全

    不同的任务是否线程安全

ü 线程资源管理：

    递归

    线程池参数设置

    不同任务线程池资源隔离问题、

ü 线程优化：

    从单线程到多线程

  加线程数

ü 线程同步问题：

防止无限等待：设置等待时间

2) 典型案例分析

l 案例1：客服系统】因新功能性能问题，导致订单查询、创建工单等操作超时，影响时长19分钟

ü 原因：

客户标签查询和订单信息查询在同线程池中执行，当并发查询请求增多时，线程池的容量不足，无法有效处理这些请求，从而引发了线程池的阻塞。

ü 后续优化措施：

1.将客户标签查询和订单标签查询共用的线程池拆分成各自单独的线程池，并增加线程数量，核心线程从30增至50，最大线程从50增至70。

2.安排性能测试团队对客户标签查询接口进行压力测试。

3.已与客服业务负责人沟通，客户标签暂时不使用订单信息（页面配置），避免用户有大量订单时接口耗时长。

ü 事故标签：事件

ü 事故划分依据：

 

l 案例2： IVR调用TTS并发超限

ü 原因：

并发的集中外呼，导致tts请求过载的情况。

ü 后续优化措施：

1.业务需求，提交TAPD,经过维信，慧捷多方评估 -

2.增加监控，慧捷平台调用外部服务的连接数，反应时效等

3. 平台不同业务解耦，避免互相干扰

4. 灾备云平台演练

事故标签：一级事故

ü 事故划分依据：

 

l 案例3：VCS早晨9点无法登录

ü 原因：后台管理员在下载委外数据时，这段代码会对下载数据，每5w条创建一个线程，一般来说有大概有250w条数据，大约50个线程，由于没有对调用并发进行控制。在用户多次点击后，比如5次，会创建250个线程，每个线程都有一段查询语句，该语句执行需要3-5分钟，造成了数据连接池耗尽

ü 后续优化措施：

1.控制线程并发数

ü 事故标签：三级事故

ü 事故划分依据：

l 案例4：路由决策费率问题

ü 原因： 路由与费率决策交互频繁，风控系统优化处理效率，路由针对调用费率决策由串行改为并行。并行处理中，忽略了一个局部变量在多线程中的安全性问题，导致多资方的费率区间映射错乱，最终导致费率决策回吐年化错误。

ü 后续优化措施：

 1. 梳理费率处理路径，节点测试案例增加费率值验证，增加不同的排除费率资方进行验证

 2. 强化技术优化类 项目的技术影响范围评估和系统分析，强化技术评审 ，严格按照测试流程实施。

 3. 技术优化类项目，测试需做详细的测试影响分析和场景分析，从用户场景进行测试而不是仅从开发改动点进行测试。  

ü 事故标签：四级事故

ü 事故划分依据：

 

3) 总结：

 线程管理的一些建议：

ü 线程生命周期管理

1.1 线程创建与销毁

‌明确创建时机‌：确保线程在合适的时机创建，避免不必要的线程开销。

‌及时销毁线程‌：任务完成后应立即销毁线程，释放系统资源。

1.2 线程状态监控

‌实时监控线程状态‌：通过监控工具或日志记录线程状态，及时发现并解决线程挂起、死锁等问题。

‌设置超时机制‌：对于可能长时间运行的任务，设置合理的超时机制，避免线程无限期等待。

ü 线程池管理

2.1 合理配置线程池

‌根据系统负载配置‌：根据系统的实际负载情况，合理配置线程池的大小，避免资源浪费或线程饥饿。

‌动态调整线程池‌：对于负载变化较大的系统，考虑实现线程池的动态调整机制。

2.2 任务队列管理

‌有限队列策略‌：设置任务队列的大小限制，避免队列无限增长导致内存溢出。

‌优先级队列‌：根据任务的重要性设置优先级队列，确保关键任务得到优先处理。

ü 线程同步与通信

3.1 使用合适的同步机制

‌避免过度同步‌：尽量减少线程间的同步操作，以提高系统的并发性能。

‌选择合适的同步工具‌：根据实际需求选择合适的同步工具，如互斥锁、信号量、条件变量等。

3.2 优化线程通信

‌减少通信开销‌：尽量通过共享内存等高效方式进行线程间通信，避免频繁的上下文切换。

‌明确通信协议‌：制定清晰的线程间通信协议，确保数据的正确传递和处理。

ü 异常处理与恢复

4.1 异常捕获与处理

‌捕获线程异常‌：为线程设置异常捕获机制，及时记录并处理异常信息。

‌优雅退出机制‌：在异常情况下，确保线程能够优雅地退出，释放占用的资源。

4.2 恢复策略

‌自动恢复机制‌：对于可恢复的异常，考虑实现自动恢复机制，减少人工干预。

‌定期巡检与修复‌：定期对系统进行巡检，及时发现并修复潜在的问题，防止异常情况的累积和恶化。

ü 线程安全与性能测试

5.1 线程安全设计

‌避免共享可变状态‌：尽量通过不可变对象或线程局部变量来避免共享可变状态。

‌加锁策略‌：对于必须共享的状态，采用合适的加锁策略来保证线程安全。

5.2 性能测试与优化

‌定期进行性能测试‌：通过模拟实际负载对系统进行性能测试，发现潜在的性能瓶颈。

‌优化线程代码‌：根据性能测试结果，对线程代码进行优化，提高系统的并发处理能力和响应速度。

ü 做好线程资源监控：

  是否发生线程锁，线程池资源利用情况

 用好线程是系统稳定性非常关键的一环，相对于其他问题线程管理一旦出现问题对系统影响大的概率是非常大的，要特别重视对系统中多线程的代码审查和测试。

 

4、内存管理：

总样本：5  事件：3  一级事故：1  二级级事故：1

1) 内存管理出错原因

ü 资源没有及时释放，造成内存溢出：

ü 批处理没有控制，造成内存溢出：

ü 指针未初始化或已被释放后继续使用

 

2) 典型案例分析

l 案例1：【资方系统-资方平台】因批扣服务OOM

ü 原因：

1分钟内发起近3000笔扣款交易，短时间内频繁操作数据库，产⽣⼤量对象，造成服务oom

ü 现场解决措施：

1. 及时处理未决数据，联系贷后发起补扣，并与10:30已完成补扣，已扣订单完成填帐；

2与领导沟通后，联系运维同事，临时将内存增加至6g；

ü 后续优化措施：

1. 调整扣款批次数据量，单批次不能超过300条（待压测后补充“300条“的评估依据）；

2. 优化jdsj-adapter程序：扣款初始化数据采⽤批量⽅式落库

3. 完善应用程序基础指标（OOM等异常情况）实时预警

ü 事故标签：事件

ü 事故划分依据：

3) 总结：

 线程管理的一些建议：

ü 增加内存报警

内存达到一定的阈值报警

ü 控制好数据处理的颗粒度

  太多容易引起内存溢出，太少影响性能

ü 借助工具做好代码审查和性能测试：

   防止由于代码的原因，该释放的内存无法是否

 

5、数据库相关：

总样本：18  事件：8  一级事故：2  二级级事故：5 三级事故：2  四级事故：1

1) 数据库相关出错原因

ü 慢sql：

索引使用不当：全表扫描，增加回表的次数

sql太复杂连表嵌套太多：复杂的业务逻辑可以放在代码实现

表数量过多：分库，分表，定时归档

查询量多：拼接sql有时候在特殊环境下查询出大量数据导致性能下降，内存溢出等

高并发：合理配置数据库连接池线程数：默认只有10，需要根据实际情况调整

锁使用不当：长事务，操作同一条数据库起不同的会话造成相互等待

表字段过多：查找数据库需要翻更多的索引页

数据库部署不合理：从库读，主库可读写，做好读写分离

ü 主键设置不合理：

    主键自增长超出范围，主键string类型或者没有主键

ü 字段类型和长度设置不合理

     影响性能和实际业务存储，有时候影响精确度。

 

2) 典型案例分析

l 案例1：【VBS】payid字段超限导致无法填帐影响贷后和客服一线作业，字段扩位操作导致从库异常影响提现、授信和主动还款

ü 原因：

1扣款程序使用到的dbo.Received表中的字段PayID超过了定义int最大值

ü 现场解决措施：

1、先直接在表上扩展字段 ，预估1个小时 ：

2、先删除索引， 扩字段期间会影响数据的读写

3、排查原因为同步扩位事务和生产事务同步执行导致从库压力过大导致 ，影响从库读业务 要求回滚，领导坚持 不回滚继续扩充字段

4、扩字段失败

5、换修改程序，id改成负数存储。 过程 18个小时

6、接下来用表替换法4天完成整体的字段扩充。

ü 后续优化措施：

1. 整理信贷所有数据库隐患并整改：大表隐患，·主键数值类型和外键数值类型隐患

2. 完善内部质量管理：

·设计阶段重点关注点宣导及完善设计方案评审规范，计划6.14完成

·数据库原理培训，计划6.28完成

·主流程依赖项梳理并排查风险点，计划6.14完成

3. 制定故障处理中确定指挥人流程和故障上报内容模板(上报内容规范化，标准化) 

4. 自增主键监控

5. 完善数据库变更规范，与研发讨论并确认，完成后做好全员宣贯

ü 事故标签：四级事故

ü 事故划分依据：

 

l 案例2：贷后服务超时导致App端借款卡死，内部系统查询慢

ü 原因：

1. 应用服务vsi-api数据库连接池使用默认配置可能并不适配应用实际使用要求   

2. 贷后的扣款指令数据增长到1.7亿未归档，原未决查询脚本性能严重下降

ü 后续优化措施：

  1、对数据量大的表像以前一样进行常规归档

  2、对所有查询脚本进行优化，每周抓取一些历史慢脚本进行优化，或者逻辑调整

  3、新上线的脚本，尽量不使用复杂查询，如果涉及多表复杂的查询发DBA评估

  4、对接口进行读写分离，能使用读库的尽量使用读库

  5、贷后对应用的数据库连接池配置进行梳理

ü 事故标签：四级事故

ü 事故划分依据：

l 案例3：订单中心服务异常

ü 原因：

发现部分请求的入参中没有userToken，registerId,vcid中的任意一个，订单中心未做相应的强校验，经DBA拉取数据库日志，发现一个全表扫描语句

ü 后续优化措施：

1、必要参数校验

:特别是sql查询条件中非常重要的字段，缺少就有可能导致全表扫描

ü 事故标签：二级事故

ü 事故划分依据：

l 案例4：【VCS-催收子系统】因代码缺陷造成事务死锁，导致委外订单回收分案延迟13小时

ü 原因：

不同事务之间出现相互等待的现象，造成死锁：

多批次用in查询，分批在同一个事务中查询更新，如果有相同的订单号分在不同批次，此时第一个批次订单没有释放锁，同一个订单开启新的session就会等待第一批是否锁，而第一批又在等待第二批释放锁造成死锁

ü 后续优化措施：

1、测试优化措施：

    a、增加分片处理场景下极端情况测试

    b、增加大批量数据模拟真实回收测试场景

2、研发优化措施：

a.ORM框架升级， 原生JDBC部分代码升级为mybaits

3、数据库优化措施：

a、优化dg broker切换步骤

在主动维护实例前，先禁用dg broker的Fast-Start Failover功能，维护后重新启用Fast-Start Failover功能，可以防止主从切换。

b、vcs主、备库双活改造

在vcs主、备库上创建双活专用service和启用触发器，只在primary角色的实例启动该service，应用端url同步改造为双活连接串。

ü 事故标签：二级事故

ü 事故划分依据：

 

 

3) 总结：

数据库设计和sql建议

ü 字段类型和取值范围

‌选择合适的数据类型‌：根据存储数据的特点选择合适的字段类型，避免使用不必要的大字段类型，如将整数存储为字符串。

‌考虑极端情况‌：在设计字段时，要考虑字段取值范围是否满足业务需求，特别是自增长字段，如用户ID、订单号等，要确保其数据类型和长度能够支持未来业务的发展。

ü 索引设计

‌合理使用索引‌：索引可以加快查询速度，但也会增加写操作的负担。应根据查询频率和查询条件合理设计索引。

‌避免冗余索引‌：重复的索引不仅浪费存储空间，还会影响写性能。

‌考虑索引的选择性‌：选择性高的列（即列中唯一值多的列）适合建索引，选择性低的列（如性别字段）则不适合。

ü 表结构设计

‌规范化与反规范化‌：数据库设计应遵循一定的规范化原则，减少数据冗余。但在某些情况下，为了查询性能，可以适当进行反规范化。

‌表关联‌：合理设计表之间的关联关系，避免过多的级联查询。

ü 权限控制

‌严格权限管理‌：对数据库的操作权限进行严格控制，确保只有授权人员才能对数据库进行增删改查操作。

‌最小权限原则‌：为每个用户或角色分配最小必要权限，避免权限过大导致的安全风险。

ü 避免全表扫描

‌使用索引‌：在查询条件中尽量使用索引列，避免全表扫描。

‌限制查询结果集‌：使用LIMIT子句限制查询结果集的大小，减少不必要的数据传输和处理。

ü 优化查询条件

‌避免使用函数或计算‌：在查询条件中避免对列进行函数运算或计算，这样会导致索引失效。

‌使用合适的比较操作符‌：根据需求选择合适的比较操作符，如=、>、<等，避免使用LIKE开头的模糊查询。

ü 分批处理大数据量操作

‌分批插入或更新‌：对于大数据量的插入或更新操作，应分批进行，避免一次性操作导致数据库性能下降或锁表。

‌使用事务‌：对于需要保证数据一致性的操作，应使用事务进行处理。

ü SQL代码审查

‌定期审查SQL代码‌：定期对SQL代码进行审查，确保代码逻辑正确，没有性能瓶颈。

‌使用执行计划‌：在编写复杂SQL时，使用数据库的执行计划工具分析查询性能，优化查询语句。

ü 注意SQL注入风险

‌使用预处理语句‌：在编写动态SQL时，应使用预处理语句或参数化查询，避免SQL注入风险。

‌输入验证‌：对用户的输入进行严格验证和过滤，确保输入数据的合法性和安全性。

通过以上建议，可以提高数据库设计的合理性和SQL编写的效率，减少生产事故的发生，提升系统的稳定性和性能。

  

6、系统健壮性：

总样本：13 其中 事件 ：5，一级事故：6 ，二级事故：1 ，三级事故：1

1) 典型案例分析

ü 幂等：

ü 任务失败或异常中断处理：

     定时任务失败或者某些特殊原因比如断电服务重启，也能正常处理业务。

ü 异常值的判断：4

 空置，数组越界值，及其其他异常值的判断

ü 条件可预测改变的处理：1

   比如处理的json多一个字段会不会影响业务或者程序正常运行

ü 关键字段校验： 1

   确保进来的数据能保证程序正常运行，对业务不会有影响

2) 典型案例分析

l 案例1：【VCS】预提醒短信发送任务超时被搁置导致短信未发送

ü 原因：任务策略设置为单机串行，因为前面的任务尚未完成，故后续任务不进行调度。

ü 后续优化措施：

1.优化任务调度策略，单机串行调整为丢弃后继续 -

2.优化任务运行时间，降低超时时间

3.梳理贷后业务告警，按照业务等级增加各层级监控和告警通知

ü 事故标签：一级事故

ü 事故划分依据：

l 案例2：【渠道接入平台系统】因逻辑缺陷，触发换卡的主动还款被错误执行成提前清贷，影响客户496名，赔付1690元

ü 原因：

1.数据还款类型没有赋值，入库默认-1

2.捞取数据的任务判断非1即2，结果还款类型2（提前清贷），没有核对还款金额直接清贷。

ü 后续优化措施：

1补充异常场景的用例，12月完成渠道对接主流程接口的异常场景用例

2还款JOB针对还款类型的判断加强，增强渠道还款功能代码健壮性

ü 事故标签：一级事故

ü 事故划分依据：

l 案例3：短信发送异常

ü 原因：产品字段值缺失，可交单决策认为当前用户存在非当前产品的在途订单，客户请款可交单误拒

ü 现场解决措施：

   可交单判断订单产品值为空抛出异常处理

ü 后续优化措施：

1.增加可交单拦截率监控，浮动范围、同比等

2.可交单获取订单数据必要值（产品、订单号、放款状态、产品编码等）缺失抛异常。

3.排查实时调用汇集库场景

4.调研汇集库使用场景，排查风险

5.评估风控订单调用VOS接口

6.增加必要字段校验逻辑的测试案例

ü 事故标签：一级事故

ü 事故划分依据：

 

3) 总结：

 

 

二、运维部署篇：

 

1、监控：

2、部署架构：

3、负载均衡：

4、权限控制：

 

 

三、项目管理篇：

1、需求沟通：

2、源代码管理：

3、软件升级： 组件接入

4、配置

总样本：21 其中 事件 ：10 ，一级事故：11

1) 配置问题主要包括

ü 配置格式错误：

样本数：1

解释：配置格式没有按要求写，比如：ip:port 错误写错 ip.port

ü 配置内容错误：

样本数：12

解释：配置的值是错误的，可能由于不理解或者信息获取错误。

ü 配置遗漏：

样本数：4

解释：配置的值是错误的，可能由于不理解或者信息获取错误。

ü 忘记回退临时配置：

样本数：1

解释：为了系统维护或者临时任务需要该配置，任务完成或者维护完成再改回来

ü 配置冲突：

样本数：1

解释：某个配置和其他配置是耦合的，不同配置相同的值

ü 配置误删除

样本数：1

解释：不小心或者误认为可以删除的配置。

 

2) 典型案例分析

l 案例1：【复盘】20240520【一级事故】【VBS】银行维护状态配置未及时恢复，造成约1000账单晚扣

ü 原因：忘记回退临时配置

ü 现场解决措施：

    1、调整交通银行，广发银行两家银行运维状态为正常

    2、将未发起账单日批扣的订单拉起补扣

ü 后续优化措施：

1.运维Owner需要建立待办，跟踪执行过程 

2.研发交接运营界面给运维 

3.研发开发更方便的维护工具 

ü 事故标签：一级事故

ü 事故划分依据：

l 案例2：【复盘】20240823【事件】【慧捷2.0】因配置错误造成核心服务健康检查不通过被下线，造成电销，客服和催收呼入呼出不可用27分钟

ü 原因：配置格式错误，比如IP:port 写成 IP.port

ü 现场解决措施：

    1、 更新中继edge地址配置，重启core服务

ü 后续优化措施：

1.实施复核机制

2.增加对core服务器和edge服务器连接状态进行微信告警。

3.改进校验机制，错误的配置信息不应该允许保存。

ü 事故标签：一级事故

ü 事故划分依据：

3) 总结：

配置相关的事故往往由于人为操作失误、管理流程不规范或技术实现缺陷等原因导致。为了避免类似事故的发生，需要采取以下措施：

ü ‌加强配置管理‌：建立完善的配置管理流程，包括配置变更的申请、审批、执行和验证等环节，确保配置变更的准确性和有效性。

ü ‌提高配置复核‌：对重要的配置变更进行双人复核或多级审批，减少人为错误的发生。

ü ‌加强监控和告警‌：对关键配置进行实时监控，并设置合理的告警阈值，一旦发现异常及时处理。

ü 做好配置注释：让维护人员明白配置的意思，

ü 从系统层面做好配置的校验机制

ü 简化配置：管理更方便

通过上述措施的实施，可以有效降低配置相关事故的发生概率和影响程度，保障系统的稳定运行。