通过塑造企业文化来进一步构建可观测性是很好的开始，但与此同时，建立可观测性还必须有明确的指导方针。当我们评估可观测性最终的实现结果时，可以将其分解为 3 个关键问题：
- 出现问题时，我多久能收到通知？是在最终用户使用体验已经开始受到影响之前吗？
- 如何快速地对问题进行分类并了解其影响？
- 如何找到根本原因以便解决问题？
无论使用什么样的工具或解决方案，上面三个维度都是构建可观测性应重点关注的地方。而对应着这三个问题，可以将可观测性成熟的程度框架分为 3 个阶段。在每个阶段，重点都是在出现问题的时候，尽可能快地修复问题，或是减轻对最终用户的影响。
1、感知到问题
解决问题的第一步是知道问题的存在，而且最好是在最终用户知道或者是被真正影响之前。通常，知道问题正在发生就足以触发补救的措施。
如果你部署了新版本的服务，而该服务触发了影响用户使用的告警，那么回滚部署就是补救问题的最快途径。我们不需要了解事件的全部影响或者诊断事件的根本原因，因为这些可以等到事后再做检查和修复。对系统进行更改是生产问题的最大来源，因此，在引入这些更改时能够感知到问题出在哪里是很重要的。
在这个阶段的关键动作和考量包括下面几点。
- 快速告警：缩短问题发生和通知触发之间的时间。
- 提高信噪比：确保告警是可操作的。
- 将通知范围仅限于需要采取行动的团队：从一开始就确定问题范围并将其发送给正确的团队。
- 自动化告警设置：让大多数服务或主机产生相同的指标数据，这意味着自动化或模板化告警，它可以帮助工程师了解问题，而无需复杂的设置过程。
2、对问题进行诊断
这一阶段的目标是快速了解问题的背景和影响。一旦告警触发，如果最近对系统的更改不是很明显需要回滚，下一步就要了解业务影响和严重性了。
如果你确定只有一组有限流量切换中的用户受到影响，那么关闭该流量切换就可能解决问题。或者，如果对一个可用区域或集群的请求受到影响，你可以将请求重新路由到其他区域或集群。
为了将问题进行分类，工程师们需要将告警置于上下文中，从而能够快速地了解有多少客户或系统受到影响，以及被影响的程度。出色的可观测性使工程师能够对数据进行透视，并将焦点放在上下文的数据上，以此诊断问题。
在这个阶段的关键动作和考量如下。
- 具备上下文的仪表板：将告警直接链接到仪表板，这些仪表板不仅显示告警的来源，还显示相关的上下文数据。
- 高基数数据：允许工程师对数据进行“切片”，从而进一步明确问题的影响范围。
- 高维度数据：允许工程师通过尽可能多的角度、条件来聚合信息，从而在排查故障时缩小范围，明确方向。
3、理解问题
这个阶段最好发生在问题被修复之后，此时工程师可以花时间定位和理解潜在问题，而不会受到业务和用户影响带来的直接压力。随着微服务数量的不断增加，对事件进行事后分析就像是复杂网络中的导航，它也决定了你需要与哪个服务所有者合作。
出色的可观测性可以让工程师把指标和告警直接与潜在的罪魁祸首联系起来。此外，它还能够预测潜在问题，防止此类事件再次发生。
在这个阶段的关键动作和考量如下。
- 轻松理解服务依赖关系：识别有问题的服务的直接上下游依赖项。
- 在不同数据类型之间进行联合和跳转的能力：对于复杂的问题，你需要综合考量仪表盘上的指标趋势、异常值，跳转到相关的日志和链路追踪信息，需要统一的工具给出数据关联分析结果，而不是人肉地做关联和排查。
- 更进一步的是智能分析和预测：能够自动检测基础设施和应用程序问题，帮助用户提前发现 IT 系统运行过程中潜在的问题，通过根因分析，快速定位异常问题的原因，并进行提前的预警。
可观测性是一个快速发展的领域。如果你的组织和团队还处于规划和发展期间，需要分阶段地实现，逐步完善可观测性的构建。
