2022 年 7 月 4 日，【可观测，才可靠——云上自动化运维 CloudOps 系列沙龙_第一弹】正式推出，第二位分享的讲师是阿里云弹性计算技术专家郝晨栋，他带来的分享主题是《云上可观测能力：问题的发现与定位实践》，以下是他的演讲内容整理，供大家阅览：
01 云服务器可观测能力价值
云服务器可观测性是指，客户能够感知到服务器内部运行情况的能力，从而保证云上资源的可靠性。与传统 IT 运维相比，上云 IT 的使用方式和运维方式发生了一些变化。比如，传统 IT 运维场景下，客户会自购机房、自购机器，操作的是硬件资源；而上云后，客户通过 OpenAPI 操作各种计算资源。同时，传统场景下，业务规模受限于机房或物理机；而得益于云上的弹性能力，客户能够轻松将业务规模扩大到上百台或上千台服务器。
上云后的运维也增加了诸多挑战和难度，需要云服务器的可观测性来解决。
云服务器可观测的价值主要有以下三点：
① 提升问题定位效率。通过自助服务快速定位问题，能够做到有据可依。
② 简化运维，方便掌握云服务器的运行细节。
③ 提升资源可靠性，及时掌握云服务器客户 OS 内部以及底层状态，避免黑盒。
阿里云针对提升云服务器的可观测能力提供了很多主流工具集，包含健康诊断、系统事件、云监控、ARMS 和操作审计。这些工具虽然定位和角度不一样，但其目的都是一致的，即为了让客户清晰感知到当前实例的健康状态，帮助快速发现问题，降低运维成本。
02 使用自服务工具定位和分析典型问题
自服务工具 On-demand self-service 指用户能够自助获取计算资源或服务，而不必与服务供应商打交道。
客户在云上经常面临的典型问题有比如实例无法启动、实例无法连接、操作不生效等。传统场景下，客户只能提交工单寻求售后支持，问题解决速度取决于客服对问题的理解程度或回复效率。
而在自服务场景下，我们将典型的客户问题全部收纳到健康诊断工具集里，客户可以在控制台上自助发起诊断，进行问题解决，只需分钟级即可定位问题。
实例无法启动一般有两方面原因：
其一是操作系统内问题，比如客户操作系统中病毒，一些关键文件被破坏或删除，客户的误操作导致操作系统一些核心系统服务没有开机启动，Fstab 文件配置错误，也可能是镜像与规格冲突导致。针对操作系统内问题，目前健康指南工具可以快速定位问题，并将对应修复方案推送给客户。
其二是云平台底层问题，此类问题较为少见，主要有库存不足、宿主机告警、控制系统异常、虚拟化异常以及磁盘扩缩容异常等。针对此类问题，诊断工具会向客户推送人工服务直达入口。同时，针对一些较为严重的错误，会向客户推送问题上报入口，如果运维团队确认客户上报的问题非常严重，会主动触发运维动作，且步骤对客户完全透明。
实例无法启动的情况下，阿里云诊断工具如何实现对实例操作系统内部的探测？
以个人电脑操作系统为例，比如个人电脑坏了以后，通常会使用 U 盘作为修复盘，启动时进行调整，启动 U 盘再进行重装系统或修复，最后将修复盘卸载，电脑即可正常启动。
诊断工具的工作原理类似，如上图左下方所示。如果客户操作系统无法正常启动，诊断工具会为客户挂载一块修复盘，并且会生成用于登录修复盘的临时密码等。修复盘挂载好以后，自动为客户启动实例，原先的系统盘会作为数据盘挂在现在的实例下，然后进行实时探测。如果发现问题，会给客户推荐具体的修复方案，客户可以根据修复方案解决问题。原先系统盘内的问题解决以后，将修复盘卸载，即可正常启动，整个流程对客户完全透明。
实例无法远程链接主要原因为 ECS 两个服务器之间无法连通以及 ECS 实例与公网 IP 无法连通。诊断工具支持三种类型输入，可以选择 ECS 实例、网卡或公网 IP。
诊断工具会列出发起端和目的端之间的关键路径，比如实例账户本身状态、实例操作系统、当前实例所在交换机等关键路径，依次探测每个关键路径是否连通，最终得出结论。
关键路径可以分为两大类，实例配置类和操作系统内配置，其中实例配置类包括实例欠费、Vswitch 未放行流量、实例被锁定等；操作系统类主要借助云助手实时下发开源诊断命令，如果发现操作系统内存在问题，则会在修复方案里告知用户。网络连通性诊断报告里会显示无法连通的关键路径及其原因。
实例变更操作不生效指客户在控制台上做了一些变更，但结果与预期不符。这一类的问题难度较大，变更动作非常多，没有生效的原因也非常多。目前自服务诊断工具已经支持的诊断能力有云盘扩容未生效、重置密码不生效、实例变配不生效以及实例续费失效。
比如客户云盘超过容量，在控制台上做了扩容，从 40G 扩容到 100G 。控制台上已经显示为 100G，但依然需要客户进入 OS 里做一些扩容命令才能真正生效，否则会导致业务受损。诊断工具有专门针对云盘扩容的专项诊断，如果发现客户实际生效磁盘与扩容大小不一致，会给用户推送扩容建议，避免客户业务受到损害。
还有一类实例变更操作不生效是由于客户对产品规则不熟悉导致，诊断工具会给客户推送现在的产品规则。
上述典型问题都需要依靠客户在控制台上主动发起诊断，属于被动服务。而自服务能力背后的主动探测工具是对账系统。如果客户在云上使用的服务与实际运行的不一致，则会影响业务。因此，可以通过对账工具来保证客户在控制台上看到的与实际运行值一致。比如会比对控制台上客户看到的 IP 与实际 IP 是否一致等。
通过客户主动发起诊断，再加上自服务工具背后的主动服务，来确保客户可观测到的数据与实际运行一致。
上图为自服务诊断工具的诊断能力总览和用户场景。
诊断能力主要分为两大类，分别是问题排查和规则类。问题排查类又细分为操作系统和云平台类，目前已有大约 80 多种诊断能力；产品规则类目前已经提供了 30 多种能力。
阿里云平台诊断分析依赖于阿里云底层的数据采集。阿里云在全球有接近 30 多个地域、上百个可用区，每时每刻都有实时数据被采集上来，比如物理机、IDC 有机房、操作性能、串口日志等。这些基础日志是健康诊断工具的输入，有了这些底层数据，诊断才能做数据清洗、聚合计算、抽取与异常相关的特征，最后产出诊断根因。
另一部分诊断能力与操作系统内客户的关系较为密切，通过在实例内安装云助手服务实现。客户发起诊断时，通过云助手在客户实例上执行开源脚本，进行实时数据收集，包括负载类和配置类，比如实时探测当前客户 OS 内的 CPU 、内存、 iOS 等负载类，或 DHCP、 IP 等配置类。
阿里云平台诊断和操作系统内诊断两大能力共同组成了健康诊断服务。目前健康诊断服务已经输出到控制台上供云客户使用，也输出到内部给云产品使用，近期也将推出 OpenAPI。
03 集成诊断实现自动化运维
对于没有自己运维平台的中小型客户，我们推荐直接在控制台上使用诊断产品，既方便又快捷，诊断产品还提供了诸多详细方案供客户参考。
对于有自己运维系统的中大型用户，建议通过 API 的形式集成到自己的运维系统中，高效便捷。比如可以将监控系统与诊断做整合，监控系统发现实例负载不正常时，会直接调用诊断 API 并根据诊断结果做处理；可以将诊断服务集成到巡检系统里，每天对一些集群的核心实例做实时诊断，如果有异常则及时更换或扩容；可以将诊断服务集成到后台运维系统里，供值班人员使用，比如 RDS 实例发起诊断时，也可以同时对 ECS 层面发起诊断。
此外，诊断产品还结合了运维编排能力，开放了很多运维编排的公共模板，可以快速实现定时运维、事件驱动型运维，也提供了批量操作的能力，比如批量发起诊断或跨地域发起诊断等，以上能力都可以在 OS 控制台上直接使用公共脚本来实现。同时，还支持 ECS 产品根据诊断按结果来触发操作，比如诊断结果为当前实例负载过高，可以触发创建新实例或升配；如果诊断结果为云盘容量已经占满，可触发扩容命令等。
04 展望
自服务诊断工具期望成为 ECS 产品问题定位和排查的总入口。近期我们会发布健康诊断的 Open API ，目前也正在密集开发更多的诊断能力。此外，在阿里云官方社区里也有建立了技术圈，供业内同仁在专业上的交流分享。
Q&A 环节，观众提问
Q1 自动诊断后为什么不执行自动修复？
答：我们曾做过一些自动修复的尝试，但效果并不好。首先，部分修复动作存在风险；其次，修复动作可能需要用户授权。因此，最终我们决定只将修复方案方提供给客户。
Q2 问题发现和定位的精准度如何？
答：诊断工具无法做到全面覆盖，目前主要以保证发生频率较高的问题为主。问题来源有三个渠道：第一类为客户工单，从发生频率较高的问题里评估哪些可以集成到诊断工具里；第二类是定期拜访一些 GC 3 以上的客户；第三类是平时团队内部的管控值班周报。
点击这里，观看嘉宾的演讲视频回放。
近期活动预告
【自动化，才高效——云上自动化运维 CloudOps 系列沙龙_第二弹】来袭，就在 7 月 25 日-27 日，敬请期待。
自动化即是通过运用工具或系统达到减少、甚至是完全取代人工的操作。在研发效能与运维工作中，自动化是降低成本、提升效率必不可少的方式，自动化还能减少人工带来的错误，提升团队满意度。因此，阿里云弹性计算云上自动化运维 CloudOps 系列沙龙，将以“自动化与智能化”作为第二弹的主题，分享相关思考与实践。免费报名通道已经开启！即刻扫描下方海报中的二维码报名，进群还能获得最新讲师 PPT 资料。
沙龙小 Tips：观看直播时在弹幕区提出自己的疑问，被讲师抽中回答问题的同学，还会获得加湿器等精美礼品哦！同时在直播结束时填写问卷，也有机会获得便携玻璃杯等多重好礼。
