系统崩了怎么办,在线等

文章概要
- 生产问题分类
- 生产问题定位路径
- 生产问题发现来源
- 数据大盘设计

生产问题分类

随着业务的发展，由于内部或外部的原因，系统运行迭代过程中总是会出现大大小小生产问题。

在进行生产问题处理时会遇到各种各样的问题，有时在人员流动性较大团队进行老系统维护时，一个隐藏的比较深的问题往往要花费极大的时间进行定位；或者在遇到大范围生产服务不可用时，如何快速定位恢复系统问题，保证系统稳定性，作为一个质控人员和开发经理必须具备的技能。

按照生产问题发生的原因大致可分为两种：服务稳定性、数据一致性

---

服务稳定性

服务请求阻塞
服务请求丢失（中止）
服务假死
服务资源消费异常
外源性服务阻碍

服务稳定性问题是相对隐形的，常规逻辑验证一般无法发现。内部或外部服务受到网络（网络波动）、流量波动（暴增）、物理资源不足等影响，导致偶发性或间歇性服务理能力处下降、丢失。

数据一致性

常规逻辑异常导致数据处理错误
偶发性（隐形）数据异常
外源性数据异常

数据一致性问题相对较容易暴露和定位，常见的都是由于运营配置调整、代码实现、产品业务设计问题导致。外源性数据问题的出现，除了外部数据不严谨外，系统对外接口过滤不足也是应引起重视的问题。

生产问题定位路径

服务可用性（直接与间接）
服务逻辑问题
数据溯源（包含代码）
配置确认
运营日志

在实际定位生产问题的过程中，如果没有大盘数据提供支撑，更多时候是根据经验，简单观察生产聚合日志，临时查询代码、临时编写SQL，单点式定位问题。这种情况下，若经验不足，对相关代码不熟悉，则很难快速准确定位到问题，通常需要很长时间才能定位到问题，而且准确定存疑。
通过合理的数据趋势、纵向数据面板，结合报警信息，跟踪错误日志堆栈信息涉及代码，精确定位到问题。

生产问题发现来源

客服报障
生产验证报障
运维报警
多维数据(异常日志、数据趋势监控)报警
测试环境验证报障

针对不同问题来源及问题场景，定位流程有细微差异。
如客服报障：可能存在客服大范围报障，客服单客户数据异常报障等。

总结历史经验如下：

生产异常的表征往往会多方面展现：如服务宕机往往首先表现就是前端业务功能不可用，访问前端提示异常（往往会触发客服报障）；同时会有运维健康监测的报警；业务异常日志报警；数据流量异常报警。

这些现象的出现可能同时或部分出现，这些现象的出现往往能够决定我们定位问题的手段。

如出现大范围用户前端入口访问异常，检测顺序可以为：网络配置（连通性）、web服务可用性、后端服务可用性、外部服务可用性、运营配置、代码逻辑异常。

快速进行生产问题定位，统一出口的监控平台能够给予我们极大的帮助。++构建监控平台++，不仅仅是某一个组织角色的问题，不但要基础支撑组提供相关物理、中间件、基础服务的实时动态监测视图数据，也需要业务层面提供对应的数据流量、系统异常视图数据。

给予完善的监控平台，就能够构建出系统的快速恢复机制。根据历史数据分析构建指定的服务治理策略模型，并结合人工&机器处理；不断迭代优化，逐步构建一个匹配于当前业务系统的系统治理平台。

数据大盘设计

按照业务特性组织大盘分布视图，主要可以分为两个维度点：趋势数据、多维聚合数据

---

趋势数据

趋势数据：主要指一定周期内（天/周/月）指定维度数据变化趋势，通过对同比数据的观察，能够快速发现问题发生节点，相对快速定位问题发生模块，给问题定位提供快速支持。
如：每天24小时同比借款数、账户开通数。

以生产运营监控为主的趋势数据，周期设置不宜太久，一般保持每小时数据统计。通过同比数据设置警戒值，设置20%波动曲率。可选择的观测维度有：5分钟、15分钟、30分钟、1小时、24小时、7天、15天、1个月、1季度、1年。
不同维度数据适用不同场景，常用作监控报警类的，根据业务流量，建议尽可肯能小的维度（过高会导致灵敏度降低）。

在实现数据大盘时，可以自己开发或选择合适的开源或商业BI工具，不同方案都有自己的优势和劣势。
开源的可能存在支持不足，视图和接口数据多样性不满足业务需求；
商业的视图和接口丰富性能够得到保障，但可能存在成本问题，且基于商业BI系统开发自己治理平台，存在一定风险。
自主开发数据平台则需要一批专业人员进行不短的时间进行开发，可以根据实际需要不断维护定制所需功能，但需要一定时间迭代来完成。

多维聚合数据

多维聚合数据：通过单人/单笔账户、交易数据的纵向挖掘聚合展示，展示单笔数据变迁过程，通过对数据变迁分析，快速定位异常点。
如：账户开通业务流中涉及（实名、认证、授信、账户）

聚合数据要求展示系统业务流转中核心数据流转变迁过程。设计时必须遵循的原则就是检索条件必要性，以用户为维度的必须输入用户编号作为检索条件，以交易为维度的必须要输入源头交易编号作为检索条件。应避免在检索结果包含多用户/多交易数据，容易造成实现难度加大且结果不理想。

检索条件建议：用户编号、交易编号。
检索结果分布建议：用户信息、交易信息、交易回退信息、边缘系统聚合数据。