上周，UGeek大咖说第八期圆满落幕，由美图SRE负责人石鹏主讲，围绕故障治理浅谈可观测性建设，为大家带来经多年实战经验沉淀总结的故障治理方法论。
石老师从“保障和提升业务稳定性的角度”和我们探讨了可观测性的建设，讲解了可观测在稳定性、效率和成本这几个方向上的作用，也为我们展示了可观测性的主要战场分别都有哪些。
过程中也分析了一些实用案例，比如有些公司已经在监控领域建设了多年，他们应该如何在此基础上去践行和落地可观测性的理念？最后也跟我们分享了建设服务稳定性体系的宏框架以及一些推进的思路。
-精彩内容·节选-
1►VUCA时代下「可观测」的价值
乌卡时代(VUCA )，是volatile，uncertain，complex，ambiguous的缩写。四个单词分别是易变不稳定、不确定、复杂和模糊的意思。描述了企业在展望他们当前和未来的状态的情景，表明了企业在制定政策或计划时的边缘性。这些因素使我们制定计划或者向未来展望的时候变得微不足道。
词语释义：来自百度百科
VUCA起源于这个20世纪90年代的美国军方，它指的是在冷战结束之后出现的一个多边世界的形态。这个时代特征比以往任何时候都更加复杂和不确定，因为这个特征具有比较强的普遍性，这个词的这个应用范围也越来越广。
我们讲计算机系统，讲软件研发的效能，很多时候都会提到乌卡，因为我们面临的很多场景都符合这个特征。
01易变性
在计算机行业，可以非常迅速找到很多的事例来支撑这个易变性，现在技术发展非常快，各个方向的技术都发展的非常迅猛，比如前端技术，组件框架，很多前端工程师都觉得力不从心。当下的外部环境，竞争也非常激烈，已经不再是大鱼吃小鱼的时代，而是快鱼吃慢鱼的时代，各个企业也都在追求急速迭代，在这种背景下，企业的线上的稳定性以及服务的变化与震荡就比以往更加剧烈，具有更强的易变性。
02不确定性
即不可预期，这种事件它会影响到服务的稳定性保障。以微博这样的社交媒体来举例，它所面临的诸如娱乐圈新闻事件，社会重大新闻事件，国际新闻事件等等，都会给微博平台带来这个非常大的流量压力，如果在这这种时候应对不当，可能就会出现故障。
03复杂性
目前的业务架构、业务请求、链路，所用的技术站相比20年前已经发生了翻天覆地的变化，复杂性急剧增加。
04模糊性
对应的是系统里的因果关系，它的边界混乱且不清晰，这样的背景给运维保障工作就提出了更高的要求，对可观测性，也提出了更高的要求。
换言之，我们所做的稳定性保障工作，其实就是在和VUCA在做对抗，就是在一个复杂的、不确定性的环境下，去追求确定结果。因此，可观测性就提供了一个非常有效的切入点，给我们提供了比较客观公正的数据，来帮助我们更快地发现问题，达成追求稳定性的目标！
另外一个2022年新出的词“BANI”（brittle、anxious、nonliner、incomprehensible），总体说的是世界的多变、复杂、不确定，以及在疫情时代之下所面临的脆弱、焦虑、非线性的、难以理解的现状，都是为了概况当今世界所面临的复杂挑战。
2►可观测在这几个方向上的作用
这三者是一个“不可能”三角，它们是相互制约的。然后我们所做的工作，其实就在寻求这三者之间的平衡。在不同的阶段，不同的场景下，我们可能会有所侧重与取舍。
那这三者跟企业发展之间的关系是什么样的呢？我的理解是这样的：
稳定性+安全：就是安全生产，保障企业正常开展工作。
效率+加成本：就是降本增效，它的价值一是让企业活着，二是让企业获得优势。
当然在竞争越来越激烈的场景下，在成本控制方面的差异也有可能会影响企业的存活。而安全生产才是最基本且重中之重的。
3►SRE稳定性建设全景图
这是我们做稳定性保障工作的全景图，以故障治理的视角看我们的运营保障工作都包含哪些内容，在不同的环节我们都需要去做什么。中间带箭头线就是故障生命周期，从故障预防到故障发现、定位、直到故障恢复，再到复盘改进，就是一个故障的生命周期。在这个生命周期里边，每个环节我们都需要去做很多的工作。
4►故障排查/处理的主要过程
Metrics即告诉我们有没有故障，它体现在监控告警和巡检阶段。通过看指标来识别是否故障发生。
Traces即告诉我们故障在哪里，它体现在链路跟踪环节。
Logs即准确告诉我们故障形成的原因，体现在日志分析环节和事件关联。
5►美图可观测建设的演进方向
美图的实践演进过程，从开始广泛建设到归纳梳理，优化治理，最后再与目前所做的都融合贯通起来。
以下是我对开展可观测性建设工作的建议，可按需索取：
01对齐理念，团队协作
选择一个更贴合可观测理念的方案进行融合，工具不仅仅是S R E，它们涉及了很多团队，美图的架构部、CMDB等各小组都需要高效协作。
02贴合业务实际场景，充分评估ROI
结合自身业务场景进行建设，需考虑到用自研抑或是用开源，又或者采用商业化的Saas方案。因为市面上的可观测性Saas已经有相对成熟的产品，比如优维的超融合监控。
03做面向未来的方案
拥抱社区，有了阶段性的成果之后要回馈社区，与社区一起成长。
04保持耐心，持续投入
可观测性是非常大的项目，涉及的范围很广，需要保持足够的耐心，展现拉长到以年为单位。保持足够耐心，贴合业务的场景，逐步去演进，并保持持续的投入。
-精彩问答·摘录-
直播过程中，我们的评论区出现了很多来自同学们的提问，小编已将问答部分整理成文字版，供大家温习。
CMDB与监控数据是联动的还是独立的？
监控数据是独立采集的，联动是与之前提到的拓普原数据做一层关联，两个平台是独立的，但是它在数据上报时，有些标签可以提前打上，有点像我们展示的链路拓谱。链络拓扑是基于所采集的组件之间的关联关系去绘制的动态拓谱图，最后再把监控数据串起来。可以去从头往后钻，按照基础设施的分层去钻。
美图是如何将Metric、Trace、Log数据融合打通的？
这是目前我们正在尝试做的事情，有部分已经实现联动了，但距离理想的状态还有距离。比如Opentelemetry所推荐的方案，其实是把监控数据存到他们推荐的存储Prometheus。Trace数据推荐存储到Jaeger。
而日志方面目前还没有特别多设计，在社区里面优先级略低一些，常见的方案就是ELK Stack, 如果用了Click house或者大数据平台来做日志，怎么做联动？有两个思路，一是Opentelemetry里面所提到的，基于数据上下文信息（源信息）去做关联。
目前我们的实践里边就是基于我们的CMDB和链路拓谱去做串联，后面我们会同时融合这两种方法，因为我们也在对Agent重新做审视，过程中可能会有更贴合Opentelemetry理念的东西落地出来。
数据在建设中建模的思路是什么呢？
目前比较主流的思路叫面向应用，常规的思路就是你的基础设施该怎么建，要更多考虑融合业务层的信息，不管是自建的技术设施，还是云上技术设施，这一部分就是资产的管理。另外业务要有清晰的的结构，目前我们用到的是树状结构，基于一个组织架构树，以此去做这个数据管理啊。
如何做告警收敛和告警降噪？
全：即覆盖全面，避免出现问题需要排查。做故障复盘经常发现覆盖不完整，可以用检查清单SOP去覆盖，也可以从服务的规划阶段，把可观测作为一项必要的特性去做开发。
准：即数据准确，告警通知的人员分发要准，告警等级定义要准。
精：如今信息越建越多，导致信息泛滥，如果没有较好地基于链路拓扑去做降噪，难度就会增加很多。服务的故障发生了，我们就能看到关联关系是怎样的，是否依赖了共同的基础设施，基础设施是否正常。
另外可以用一些机器学习的方法做文本相似性的检测，去做合并。做告警收敛和抑制是需要有一定的建设的，不管是基于机器学习还是基于链路拓扑的关联关系，都是必须有的。
如何从CMDB业务视角去规划管理业务资源？
我们有一棵逻辑树，以树状结来管理我们的资源。具体的管理方式是给资源打标签，目前我们绝大多数的资源都是在云上的，在云上申请创建资源的时候就把标签打上，用这样的方式来来管理。
有些公司会用子账号来管理，用云上的逻辑单元比不同的企业项目来管理，如果是自建的，也会有更多的管理方式。
CMDB树和监控树是同一棵树吗？
监控的时候并不是完全依赖CMDB树，取关联关系时可以用CMDB里面的东西去动态绘制拓扑和链路，可以灵活选择用或者不用，只要观测数据是按照自己的思路去建的就没问题。
有疑问加站长微信联系（非本文作者）
