金融行业基于“变化”的运行风险建立感知能力及应对机制

1.先思考几个问题

在构建系统运行风险感知能力时，需要重点思考一些问题：

• 信息系统的运行风险由什么引发？

• 运行风险通常在哪些时间段出现？

• 风险的发现方法如何转换成“指标+风险策略”模型？

• 如何将一线运维家发现风险的经验沉淀下来？

• 现有风险发现方案是什么？

• 是否可以利用算法、实时计算、海量数据分析等技术手段重塑风险的发现能力？

• 风险发现后如何识别为真正的风险？

• 识别为真正风险后如何跟进风险的应对措施？

• 如何将主动的风险发现、防范、解决量化为运营效能？

2.“变化”是运行发生的关键因素

在反思生产故障时，我们会发现很多因素都可能引发风险事件，比如我之前梳理的一个鱼骨图：

如果将这些因素进一步归纳，可以发现 “变化” 是引发风险的关键因素，找到生产环境的“变化”来源，持续地对“变化”来源进行感知，将有助于在风险源头进行防控。从运维可控的工作范围看，可以从计划性与非计划性两个角度梳理一些“变化”的来源：

（1）计划性的“变化”

此处的“计划性”指针对运维团队可以把控的“计划性”操作，通常围绕“变更管理”，比如：

• 基础设施、网络、计算资源变更，比如：切换、微码、演练、设备接入、线路割接等；

• 平台系统软件变更，比如：平台补丁、版本升级、漏洞扫描等；

• 应用系统变更，比如：软件版本迭代、数据变更、配置发布等；

• 数据维护，比如：技术数据、业务数据、批处理数据等；

• 参数维护，比如：技术、业务参数，用户、账户维护等；

• 上游依赖变更，比如：上游节点变更、外部依赖变更等；

• 下游系统变更，比如：下游对上游请求大幅度增加；

• 其他操作，比如：证书更换、服务重启、机器重启、应急演练、缩扩容等；

• ……

（2）非计划性的“变化”

相应的，非计划性“变化”针对运维无法把控的行为，比如：

• 业务推广活动；

• 市场行情变化；

• 业务功能首次发起；

• 业务报错的首次出现；

• 业务参数配置（业务功能维护）调整；

• 业务维护、导入、执行大量数据操作；

• 下游系统调用量增大；

• 上游基础设施、平台软件、应用系统异常；

• 证书过期、自增长ID达到阀值；

• ……

3.如何落地发现“变化”的策略

梳理变化来源因素后，下一步是如何感知发现变化的发生。由于“变化”有变化前与变化后两个比较面，发现风险的策略可以归纳为“比不同”。相比设置固定阀值的监控策略，采用“比不同”的变化感知方案的策略是规律的，在一定程度可以减少人工经验对每个监控点配置不同监控策略的操作步骤，达到从面角度的感知能力。

从工具层面，一方面需要将具体的变化点的状态转换成数据，保存不同时间切面的数据，并对多个时间切面的数据进行比较，发现“变化”；另一方面需要将专家经验不断地融入到感知策略的调优上，调整通用策略与实际异常发现的准确性。

为了落地比不同的策略，还要确认“变化”的时间点或时间段，可选用特定时点触发，或采用循环调用的方式触发。

对于计划性的“变化”，通常时间可控，可以考虑在触发计划性操作后对变更执行前后的“变化”进行监测，制定相关策略，比如：

• 对关键配置、程序制品的文件进行版本变化比对；

• 对参数的数值进行变化比对；

• 抽象关键黄金指标，在变更前后触发指标变化的分析；

• 将计划变更操作对象、下游关联对象、异常告警等信息相关联，建立变化与异常的关联。

对于非计划性的“变化”，可能来自业务、外部系统、外部依赖等因素，所运维对触发“变化”的操作不可控，需要区别于计划性“变化”在特定时点或时段执行感知策略，而是需要采用循环调度的多时间切面地“比不同”感知。比如：

• 将业务推广活动、市场行情变化触发的业务量指标的变化进行感知；

• 将业务指标增加触发的性能指标进行感知；

• 对关键功能涉及的接口、功能号、交易码的首次执行进行感知；

• 对应用日志的首次报错进行感知；

• 对关键的业务参数配置行为进行感知；

• 对涉及批量操作接口或功能号调用次数进行感知；

• 系统异常后，自动知会下游系统或节点。

4.如何识别“变化”后的风险

运行风险感知并非技术平台的实现，还需要结合具体的工作机制，才能真正落地，并发挥价值。

（1）融入现有工作流程机制

运行风险感知工作可以考虑与现有工作机制相结合。在一些常态化工作任务执行时点触发，比如在盘前巡检、清算批次结束、节假日结束等时点，能够更好落实新增的风险感知工作。同时，风险感知发现的风险可以融入到统一告警中，触发监控告警的处理流程中。

（2）建立新的风险识别工作机制

传统监控是基于已知问题发现的规则，对某个异常点设置监控阀值，假设监控策略准确情况下，告警的事件转化率需要越来越高。而基于“变化”发现的风险可能包括高低风险事件，高风险可以融入到原有监控告警的处理机制，但低风险事件的处置可能需要区别处理，比如以下两个示例。

示例1： 系统交易量、处理时延提高几倍，但系统容量水位与峰值相差较高。

案例中黄金指标出现较大波动，还未引发全局性的性能问题，虽暂未影响业务，但通过运维专家分析变化的原因，可以了解是业务计划性的业务推广行为，还是下游系统在未知会上游系统增大批量调用的行为等，以帮助运维了解变化行为是否合理，是否需要优化管理协同机制，同时，也能更好的了解系统容量水位变化情况，提前推动容量扩容与性能调优。

示例2： 业务功能的首次出现、应用日志出现一个首次出现的报错。

案例中首次出现的业务、报错等变化，可能是一种正常的业务行为，但通过分析，可以让运维专家更好地了解系统功能运行状况。总的来说，由于企业系统越来越多，架构越来越复杂，运维专家负责的系统越来越多，运行数据指数级增长，系统对于运维专家逐渐往黑盒的状态发展。采用识别“变化”的方式，了解系统，可作为一种聚焦系统运行风险的管理方法，纳入技术运营中，并据此建立一个新的工作机制。

点击阅读原文可到社区原文下留言交流

觉得本文有用，请 转发、点赞 或点击 赏 ，让更多同行看到

*本公众号所发布内容仅代表作者观点，不代表社区立场