服务稳定性保障是一个系统性的工程，建设一个完善的可观测性体系，是稳定性保障的基础，而稳定性保障也是可观测性体系服务的最重要的场景。然而目前企业内部普遍面临着一个痛点，虽然各种观测数据都有了，但在故障发现、故障定位上仍然存在发现慢，定位难，协同难等问题，在稳定性保障上技术团队经常处于被动。很多企业可能已经不缺少数据，但缺少的是将数据价值在稳定性保障领域发挥出来的产品、方法和最佳实践。\n \n 快猫星云团队，过往在一线互联网公司长期负责稳定性保障工作，同时也是国内领先的开源观测平台“夜莺”的创始团队。我们总结了解决企业可观测系统落地问题的三大要素：数据、平台、场景。假如把建设一套面向稳定性保障的可观测系统比喻为做一道好菜，那数据就是食材，平台就是炊具，场景就是厨艺。\n \n 数据：巧妇难为无米之炊，需要做好稳定性保障，备齐各维度的数据在所难免。\n 平台：一套趁手的炊具是好厨师的必备，监控和可观测所需的通用功能和接口需要友好而高效，便于支持上层场景的实现。\n 场景：不是有了食材和炊具就一定能烧好一道菜，稳定性保障的经验、方法、和最佳实践是整个系统最后输出效果的关键。\n \n 本次分享，我们将重点介绍一种面向故障处理的可观测性体系建设的最佳实践，希望能给各位听众带来一些思考和启发。\n \n 主题大纲：\n 可观测性三大支柱是手段而非目标\n 第1步：定义并发现业务故障，圈定影响范围\n 第2步：依托SLO构建技术视角的稳定性视图，圈定故障模块\n 第3步：依托可观测性数据的串联，找到止损依据\n

在可观测性落地过程中，SLO落地是比较微妙的部分，会有比较多的反复和争论。本次分享将介绍一种面向工程师的SLO落地策略。这个机制，通过集成AWS CloudWatch和Datadog，为每一个微服务创建默认的SLO，并且通过Git repo让工程师可以定制指标、阈值、标签和告警方式。像所有SLO项目一样，项目文档比项目代码规模还大，但这是可以理解的：SLO的目的就是为团队所有人创建一个关于可用性的共同语言。同时，我也将介绍落地所需要的前提条件，并且和各位探讨可观测性中的软件工程文化。

Raptor作为美团可观测性平台，不仅融合了前端监控、基础设施监控、应用层监控，同时也给业务提供指标、链路、部分日志监控能力，让业务能够无死角的观测到系统；在耗时检测方面，涵盖了业务端到端耗时、后端整体耗时、中间件耗时等，满足业务各阶段的可观测诉求。作为可观测系统，Raptor每日承载着PB级监控流量，百万的告警策略，覆盖前后端的观测能力，给业务提供及时有效的观测和预警，为业务保驾护航。\n \n 本次分享，主要从Raptor整体视角出发，介绍美团可观测体系的建设之路以及应用实践、从监控系统Cat到可观测系统Raptor的演进过程。以及如何支撑美团PB级监控数据，满足业务低延迟、高可用、低成本的诉求。最后针对当前面临新的诉求和挑战，讨论Raptor下一步的工作重点和方向。\n \n 主题大纲：\n 1.Raptor简介\n Raptor里程碑事件线；\n Raptor监控分层和组成；\n 包含的指标类型。\n \n 2.Raptor平台建设之路\n Raptor前身Cat监控系统；\n 基于Cat演进为Raptor可观测平台的一些工作，涉及到：架构演进、监控场景完善、链路演进、和前端监控融合等。\n \n 3.Raptor平台应用实践\n 业务如何使用Raptor排查故障、观测程序运行状况；\n 如何通过前后端监控，无死角的观测到系统各方面。\n \n 4.挑战和未来规划\n 业务对监控更精细化需求的挑战以及自身冗灾诉求。\n \n 听众收益：\n 1.了解海量数据下可观测性平台的设计\n 2.如何应对业务复杂观测场景，满足业务各种可观测诉求\n 3.可观测平台在建设过程中的取舍权衡，以及自身演进过程中的思考\n

随着企业上云和云原生基础服务的发展，作为需要存储和处理海量传感器数据的时序数据库也需要往云原生架构迁移。在这一过程中面临诸多挑战：\n 面向弹性设计的 ServerlessDB 架构；\n 海量规模的时序数据在高并发读写下的可用性和稳定性挑战；\n 时序数据特有的高基数问题和数据压缩问题；\n 存算分离架构带来的性能挑战；\n 混合时序和分析负载带来的算力隔离和调度问题。\n 我们在实现 GreptimeDB 这个分布式、云原生的时序数据库过程中，直面这些挑战，并将在本次分享中给出我们的设计选择和背后的思考，和大家一起探讨。\n