互联网生产环境问题规避与排查

互联网生产环境问题规避与排查
【每个人对生产问题的理解不同,本文只代表个人看法,时间有限,抛砖引玉】
【如有雷同,纯属巧合】

1,概述
1.1 什么是生产问题
生产问题是在生产过程中需要面对并解决的一切问题
面对:已经发生的,且无法逃避的问题
例如:
(1) 一笔交易发生了异常,交易挂账走不下去了(校验合同时未获取到签订结果)或结果不满足
预期(对客放款放了两次) 【流程受阻】
(2) CPU,内存,线程数,句柄数持续增加,系统每隔一段时间就发生假死 【内存泄露】
(3) 该catch的异常没catch住,出现了空指针(无法定位产生问题的代码位置)或者不同阶段却
使用同一事务导致异常时全部回滚(比如已经对客放款成功,此时代码回滚会带来严重后果) 【抗险力
低】
(4) 接口之间交互没有使用幂等机制,因系统问题导致多次提交交易或执行放款等 【交互风
险】
(5) redis没有设置失效时间,导致存储持续增加 【使用规范】
(6) 发错版本导致测试时的版本和生产版本不一致 【做事粗糙】
(7) 系统未存储有效数据导致其他问题无法溯源或报表数据无法产出 【数据缺失】
(8) 没有维护数据模型(表结构sql),数据字典等,导致一系列数据或枚举无法识别 【模型缺
失】
(9) 交接文档缺失导致项目负责人更替时无法承接 【文档缺失】
等等等...
解决:已经解决,可总结成经验的问题
例如:
(1) 考虑到可能出现性能问题,提前预留出扩展接口【埋点】
(2) 重要代码异常catch住或流程代码日志规范输出 【规避】
(3) 逻辑添加预警机制,系统出现问题第一时间可以发现 【发现】
(4) 接口交互时做到调用方可控或做了防sql注入或DDOS攻击【安全】
(5) 发生生产问题后形成处理方案,下次同样的问题可以按方案执行 【预案】
(6) 编写部分脚手架对某一类问题提供解决支持 【工具】
(7) 对某一种问题再研发或测试阶段就能考虑到【预防】
(8) 问题发生后总结教训,整理经验,形成预案 【复盘】
等等等...
1.2 生产问题的种类
1.2.1 优先级划分 :【紧急生产问题】【一般生产问题】
1.2.2 影响范围分: 【生产事故】【生产缺陷】
1.2.3 生产状态分: 【流程阻碍问题】【非流程阻碍问题】
1.2.4 文档情况分: 【文档缺失问题】【文档不准问题】
1.2.5 规范情况分: 【代码不规范问题】【流程不规范问题】【技术不规范问题】
1.2.6 软硬类型分: 【硬件问题】【软件问题】
1.2.7 生产组件分: 【应用问题】【服务器问题】【网络问题】【数据库问题】
等等等...

2,生产问题排查
问题的发现是一种偶然,问题的解决是一种能力,但问题的排查却是一门科学。
2.1 归纳法
归纳是一种由个别到一般的推理。由一定程度的关于个别事物的观点过渡到范围较大的观点,由特殊具体 的事例推导出一般原理、原则的解释方法。 个体 -> 一般 例如:为什么接口要加幂等,因为在接口交互过程中大多数业务都是正常的。只有少数会出现问题,甚至 接口交互时的问题。因为这种特殊事件的出现,才让码农们发现了接口没有幂等的害处,归纳出所有接口一定 要添加幂等来防止重复调用的问题。 该方法适合对已发生生产问题归纳整理,提取共同点进行问题预案制定。 开发规范,标准化,预警机制,数据字典,数据清理/转历史,服务器配置等。
2.2 演绎法
演绎是由一般到特殊的推理方法。与“归纳法”相对。推论前提与结论之间的联系是必然的,是一种确实 性推理。一般 -> 特殊 例如:联合放款异常了,表中只有自有借据信息没有资方借据信息。违背了一般情况的正常逻辑。 此时有可通过演绎法,分为业务流演绎法和数据流演绎法 (1)可在测试环境进行相同数据的演练,打断点跟踪,跟踪每段代码观察业务上是否出现某种情况没有将 资方借据信息插入到数据库。 (2)可在测试环境进行相同数据的演练,打断点跟踪,跟踪数据的流转,是否出现数据的丢失或处理错误 的情况。该方法适合小范围内处理(例如知道问题肯定出自自己的系统,模块内方便演绎的进行) 一般使用演绎法时代表自己也不知道哪里出问题了。演绎法代价比较大,一般不建议使用。
2.3 辩证法
辩证法是对逻辑过程的抽象,即对语词,推理,描述,概念,解释过程的研究。由两个或两个以上的人因 为持有不同观点,希望通过合理的讨论来获得真正的知识。分为唯物主义辩证法和唯心主义辩证法 特异 -> 一般 例如:多人进行讨论一个生产问题,每个人说自己观察到的问题和想法进行辩论,并针对可行性的几个方 案进行论证。 该方法适合范围较大的问题分析,即没有人能看到问题的全貌或问题发现流程的全貌。针对每个人了解到 的部分进行讨论分析实践检验,形成合理的问题点和解决方案。 讨论不是解决问题的手段,实践才是,讨论只是为实践寻找方向。切忌唯心主义。 最常用的分析方法,也是最普遍适用的方法。
2.4 排除法
排除法是依据类比对比及可行性进行的判断进行对事物存在的假命题的排除方式。 集合 -> 剩余 例如:出现了内存溢出的问题。排除了服务器上硬件软件因素后只会是应用程序出现了问题。 排除掉所有不可能的因素,剩下的即便再不可思议,也是真实答案 该方法适合粒度粗糙的,从几个可能出现问题的地方排除一定不会出现问题的,剩余可能出现问题的地方 再进行细粒度的分析。 更多的是为解决一个问题指引方向。
2.5 溯源法
溯源法是一种追究根源的逆向思维方式,也是一种以倒推的方式追寻原因而达到解决问题的工作方式。 节点 -> 根 例如:数据库一个参数(通过接口接收到的)存的不符合常理,最好的方式就是先分析源头,先看接口接 收到的参数是否就是异常的,如果不是再从数据加工方向考虑。 该方法适用于数据或功能从其他地方获取的情况,从当前节点直接找到源头查看。若源头有问题则是源头 上游问题,若源头没问题,则是内部加工问题。
2.6 推理法
推理法是由一个或几个已知的判断(前提)推出新判断(结论)的过程,进行一种总体的判断。有直接推 理、间接推理等。 碎片 -> 整体 例如:当程序出现内存溢出时,首先可以排除JVM运行出现的问题,其次若发现是周期性的(例如每隔一 小时),此时可以考虑是否是存在批量等情况,若增长和业务交易处理相关,考虑是否存在连接未关闭或缓存 数据未删除等。 该方法适合在一定框架内进行,有一定的前提推理出结论。 收集现象,结合前提,分析本质,推导结论。
2.7信任法(个人)
信任法是源自于对某个人,某个操作,某段逻辑,或者某种健壮性的信任。以这些不会是引起问题的原因 为基础,进行外围的分析。 结论 -> 原因 例如:交易出现问题挂账了。但是出于对上游系统传数的信任,对与下游系统交互方式的信任。推测问题 是XXX信任有时候也是一种解决问题的思路,相当于推理的前提和排除法的排除部分。空指针可以源于对某个开 发人员的信任定位到其他位置,交互可以源于对系统的信任定位到其他位置。 该方法适合在对某个人的了解或者某个系统千锤百炼的问题处理上。
2.8推锅法(个人) 推锅法是针对问题处理条线先排除自身原因影响,进行外围的分析。通过问题排查,问题分析,先将自身 的问题剔除,将问题处理节点推给别人的过程。 收集 -> 推诿 例如:某个问题定位不到原因,只知道是哪几个系统可能出现问题。 就像风险数据经理规则引擎 - 大数据前置- 外联平台-三方系统-大数据轻量化 此时应该通过查找,分析先将自己剔除问题之外,给问题的解决提供新的方向和思路 推诿不是贬义词,不作为的推诿是怠工,深思熟虑的推诿是排除 该方法适合在范围比较大的问题的上,不同节点的人查找自己的问题,并将没有问题的节点剔除或找到有 问题的节点

3,生产问题规避
3.1 为什么要规避风险问题
(1) 生产问题情况复杂,类型繁多,不同问题的性质特点各不相同,处理时很难方方面面都考虑到。很 容易出现不同问题之间互相干扰,或者不同维度的考虑形成错误引导。 (2) 为了更高效的解决生产问题,生产问题的规避显得尤为重要。即: 把能预料到的生产问题在设计或研发阶段解决(空指针异常,内存泄露等) 把能预料到却无法解决的问题添加监控等发现机制(脏数据,接口交互异常等) 把时间留给【预料不到】的生产问题 (3) 生产问题处理的效率高,才能将主要精力从【拧螺丝】向【造火箭】延伸。 可以做新的需求,研究新的技术,思考新的方案,制作新的工具。
3.2 如何规避风险问题
【设计】(1) 能考虑到的问题都考虑进去,包含正常,异常,预警机制,接口管控,数据存储,备份, 清理...包括性能问题,安全问题,数据存储的准确性和完整性(报表或后续分析可使用) 【文档】(2) 概要设计文档,数据字典,流程图,软硬件环境信息,系统架构拓扑图,数据模型,sql 语句...【复盘】(3) 对于自己遇到的问题或别人遇到的问题能够整理,复盘,保证形成方案和警醒... 【工具】(4) 制作提高效率的工具,把问题的解决处理交给系统,最大限度的减少人工操作... 【规范】(5) 代码开发规范,分包清晰,可读性强,代码健壮,基本异常问题系统可以自行解决... 【学习】(6) 学习新的技术,或深化使用的技术,拧螺丝和造火箭两不耽误... 等等等... 规避的越多,产生的越少,定位越准确。

4,解决问题的艺术
目的:
1,高效的解决问题(减少在这些问题上的时间消耗) 2,排查是自己系统的问题(明确责任不在自己,也标识自己问这个问题时候是进行过思考的) 3,规避生产出现问题(如果生产上出现了,即便不是你的问题,但是你要协调查找解决和后续回退处
理等)
4.1 提报方
问题的提出者,期望得到对问题的定位,分析和解决方案,能提供足量的信息供问题查找 需要提供: (1) 问题情况(发现时间,产生时间,情况描述,影响范畴,初步猜想等) (2) 查找标识(交易的唯一标识,跟踪号等) (3) 期望最晚的解决时间(比如如果紧急问题,需要明确问题非常紧急) 错误话术: 有个问题你看下@XXX 你们系统异常了,我把交易号发你 正确话术: 你好,现在有个问题是XXX情况下会出现,目前观察12日15点交易编号为XXX,另一笔14日16点交 易编号为XXX出现过两次,测试环境和生产环境均有出现,因为现在导致记账错误了需要调账所以问题很紧 急,麻烦你优先处理下 提报方提供充足的信息,而不是像采访一样一问一答,问啥回答啥。 多打几个字,自己方便也与人方便
4.2 查找方
问题的查找者,期望排除自身,定位问题,并快速解决,能提供足量的信息供问题影响范畴的分析 需要提供: (1) 问题产生的原因(即便问题不在自己也要证明) (2) 问题的解决方案
(3) 问题解决的时间 错误话术: 我不知道,找XXX 不是我们的问题 谁让你找我的 正确话术: 【非自身问题】我刚才查了下,目前发现这笔交易经过了XXX和XXX目前看到在我们这边都是正常 的,因为数据的来源是上游XXX同传给我们的,所以根据推测可能是XXX原因导致的,可以找XXX同时帮忙查一 下。 【自身问题】我刚才查了下,目前发现这笔交易经过了XXX和XXX目前看到这里是有问题的,目前我 们采取XXX的方法先将这个问题解决,后续我们会进行XXX的方案彻底解决这个问题,大概在XX日上线,您看 可以么。查找方提供充足的问题定位信息和解决方案信息,毕竟提报方不知道你们系统的处理逻辑,指望让提报方 分析逻辑和查找原因是不现实的,此时需要发挥自身优势,根据业务逻辑和经验进行分析,定位是外界问题还 是自身问题。如果是外界问题需拿出充足证据表明不是自己,并提供提报方可查找方向。若是自身问题则需要 进行分析和解决并提供解决的时间等。 多打几个字,自己方便也与人方便