一、前言

一起黑天鹅事件后，我重新开始思考为什么要做前端应用稳定性，就有了下面这篇 👇🏻 我们为什么要关注前端稳定性？ 明确了为什么要做以后，接下来就是怎么做：

• 明确应用风险梳理范围
• 定义风险类型
• 制定风险优先级
• 讨论识别到风险后如何解决

梳理范围已在上文中解答，本文主要论述其他三个要点。

二、风险类型定义

风险项将以提问的形式呈现，试问自己是否能够解答这个问题，如果无法解答就去找到答案（无论是自主解决或是请求协助）。

2.1 可观测能力

对于前端稳定性其实在整个用户访问到页面到请求都需要全链路的监控与追踪，每一个环节都值得我们深究。
数据是没有用的，只有把数据关联起来才有意义。数据关联了以后，才叫信息，我们不是做数据，我们是做信息。信息里面找到因果关系，我们才能有知识，比如说因为这个所以那个，这叫知识；有了知识以后，才能导出公式，我们才能通过公式去完成一些事情。
所有做科学实验都是走这条路的，不断地做实验、拿数据，在数据里面把它标注好，关联起来，然后找信息，从信息里面找因果关系，从因果关系里看看能不能推出一些公式。大概就是这么一个逻辑。
前端是应用层异常的最好呈现。

Q：应用包括哪些业务模块？哪些是核心重要的，哪些是边缘的？

Q：当前日志能否满足核心模块、核心业务流程的用户行为回溯（如点击、页面跳转、网络请求）？

Q：核心功能点不可用的场景，是否有异常处理？如何提前于工单发现？（同 2.2 Q1 前端不可用大多为依赖不可用）

Q：应用错误日志是否定期巡检？如何过滤误报噪音？

2.2 依赖风险

Q：接口是否强依赖？哪些接口可以挂？挂了以后是什么业务表现？

Q：三方 CDN 资源依赖是否可解耦？如不可解耦如何做到快速降级？

Q：是否存在依赖项动态发布影响应用本身稳定性的风险？（同为「变更风险」）

2.3 兼容性风险

Q：是否了解应用的兼容性标准？能否准确评估迭代过程中的兼容性影响面？

Q：除应用本身的兼容性要求外，是否了解依赖项的兼容风险？

2.4 代码质量

Q：CodeReview 执行是否到位？

2.5 变更风险

Q：应用是否具备灰度发布能力？（满足小流量场景能够及时暴露问题，区分环境和标签）

2.6 用户体验

Q：弱网状态下是否会影响应用可用性？

Q：异常情况下的用户提示是否到位？是否会有理解困难导致工单？

2.7 人员素养

Q：是否有能力评估上下游依赖影响面？

Q：是否能够承担救火队员职责？

Q：是否了解自身应用的网络拓扑？