1. 项目概述当“可观测”遇上“Skill”运维工作流的新范式最近在腾讯云的官方动态里看到一个挺有意思的新玩意儿叫“可观测Skill”。光看名字可能有点云里雾里但如果你是个一线运维或者SRE天天跟监控告警、日志排查、性能分析打交道那这个东西很可能就是你一直在等的“自动化扳手”。简单来说它不是一个全新的监控产品而是给腾讯云现有的可观测平台比如应用性能监控APM、日志服务CLS、云监控Cloud Monitor等装上了一套“智能插件”系统。这套系统的核心是把一些常见的、重复的、需要人工介入的运维操作封装成一个个可复用的“Skill”技能然后通过API或者事件驱动的方式自动执行。这解决了什么问题想象一下这些日常场景凌晨三点告警响了提示某台云服务器CPU持续飙高。你睡眼惺忪地打开电脑登录控制台查看监控图表分析进程可能还得手动执行个重启或者扩容操作。又或者每次发版后都需要人工去检查一遍核心接口的响应时间和错误率做一份简单的健康报告。这些工作技术含量未必多高但极其消耗精力容易出错而且把人牢牢绑在了告警通知上。“可观测Skill”想做的就是把这些“看到问题”之后的“动手处理”环节尽可能地自动化掉让运维人员从重复劳动中解放出来更专注于架构优化和故障根因分析这类高价值工作。它本质上是一种“观测即行动”理念的落地让监控系统不仅会“报警”还能初步“治病”。2. 核心设计思路从“观测”到“行动”的闭环自动化2.1 为什么是“Skill”而不是“脚本”或“工作流”看到“Skill”这个词你可能会联想到Alexa或Google Assistant里的技能。这个类比很贴切。在智能音箱里你说“播放音乐”它调用的是“音乐播放Skill”。在腾讯云可观测的语境下系统“看到”了“CPU使用率超过90%持续5分钟”这个事件它就可以自动调用“重启服务Skill”或“扩容节点Skill”。那么为什么不直接用写脚本或者配置复杂的工作流比如用云函数SCF加消息队列CMQ自己搭呢这里面的核心差异在于封装程度和易用性。开箱即用与场景化封装一个成熟的Skill比如“日志关键词告警并自动提取样本”它内部可能集成了从CLS触发、到日志查询、到关键信息提取、再到通过邮件或钉钉发送结果的全套逻辑。用户无需关心CLS的查询语法、消息格式转换、API限流等问题只需在界面勾选启用、配置几个关键参数如日志主题、关键词、接收人即可。这大大降低了自动化门槛让不擅长编程的运维也能快速搭建自动化流程。标准化与安全管控腾讯云官方或认证伙伴提供的Skill经过了标准化封装和安全审计。相比于个人编写的脚本其在权限管理使用预设角色而非个人密钥、错误处理、日志记录等方面更为规范更易于在团队内部分享和复用也符合企业安全合规的要求。生态与可发现性Skill可以被发布到一个“技能市场”其他用户可以直接搜索、订阅和使用。这形成了一个运维自动化资产的积累和流通平台好的实践能快速推广。你自己写的工作流脚本可能还躺在某个Git仓库里只有团队内少数人知道。2.2 Skill的触发与执行引擎剖析一个Skill要跑起来离不开两个核心部分触发器Trigger和执行器Executor。触发器决定了Skill在什么条件下被激活。目前来看主要基于腾讯云可观测体系内的事件监控告警触发这是最直接的场景。当云监控的告警策略被触发时如CPU使用率 85%该告警事件可以作为一个触发器自动启动关联的Skill。日志事件触发通过日志服务CLS的监控告警功能当检测到日志中出现特定错误码、异常堆栈或频次异常时触发Skill。应用性能指标触发通过应用性能监控APM当某接口的平均响应时间突增或错误率飙升时触发。定时触发虽然不完全是“可观测”事件但定时任务也是一个重要补充比如每天凌晨自动执行一次健康检查Skill生成日报。执行器是Skill真正干活的部分。它通常由一个或多个腾讯云服务编排而成云函数SCF这是最核心的执行单元。Skill的业务逻辑比如调用API、处理数据、判断逻辑以函数的形式运行在SCF中。它无服务器、按需执行、弹性伸缩的特性非常适合这种事件驱动、偶发执行的自动化任务。API网关如果Skill需要对外提供HTTP API接口比如手动触发某个运维操作或者需要调用外部系统的APIAPI网关负责路由、鉴权和流量管理。其他云服务执行过程中可能会调用CVM的API进行重启、调用CLS API查询日志、调用VPC API调整网络配置、调用短信/邮件服务发送通知等。整个流程可以概括为可观测平台发现异常事件 - 事件总线EventBridge或类似机制路由事件 - 触发对应的云函数SCF即Skill- Skill内部逻辑调用各类云API执行具体操作 - 将执行结果记录到日志或通知用户。这样就形成了一个从感知到行动的完整闭环。3. 实战构建你的第一个可观测Skill——自动磁盘扩容概念讲得再多不如动手试一次。我们以一个非常经典且实用的场景为例为云服务器CVM的磁盘配置自动扩容Skill。当监控到磁盘使用率超过85%时自动为其增加50GB容量并发送微信通知。3.1 前置准备与权限配置在开始编排Skill之前我们需要确保有正确的“工具”和“权限”。开通服务确保你的腾讯云账号已开通云监控Cloud Monitor、云函数SCF、访问管理CAM服务。这些都是基础服务通常默认已开通。创建执行角色这是安全的关键。我们不能让云函数直接用账号的主密钥去操作资源。进入CAM控制台创建一个新的自定义角色例如命名为SCF_Autoscale_Operator。在角色载体选择“腾讯云产品服务”关联产品选择“云函数SCF”。为这个角色附加策略。至少需要以下权限QcloudCVMFullAccess或更细粒度的QcloudCVMInnerReadOnlyAccess读 QcloudCVMRunInstances扩容磁盘相关权限。建议从最小权限开始如果操作失败再根据报错信息追加。QcloudMonitorFullAccess用于读取监控数据和告警信息。QcloudCLSReadOnlyAccess如果Skill需要查日志。你还可以创建一个自定义策略精确到cvm:ResizeInstanceDisks这个API动作。准备通知渠道为了接收结果我们需要在腾讯云“访问管理”“消息中心”“消息订阅”里配置好接收通知的邮箱、手机号或者更推荐的方式——绑定微信公众号接收模板消息。这里我们假设已绑定微信。注意权限是自动化脚本的“生死线”。实践中强烈建议遵循最小权限原则为每个Skill创建独立的、权限精确的执行角色。避免使用AdministratorAccess这种万能钥匙一旦函数代码有漏洞或逻辑错误可能导致灾难性的误操作。3.2 Skill逻辑编排与代码实现接下来我们进入云函数SCF控制台创建函数。创建函数函数类型选择“事件函数”。运行环境选择你熟悉的例如 Python 3.7。执行方法填写index.main_handler。执行角色选择上一步我们创建的SCF_Autoscale_Operator。编写函数代码 以下是index.py的一个简化示例它处理从云监控告警触发的事件。# -*- coding: utf8 -*- import json import os from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.cvm.v20170312 import cvm_client, models def send_wechat_notification(instance_id, disk_index, old_size, new_size, is_success, error_msgNone): 发送微信通知此处为模拟实际需调用微信模板消息API或腾讯云告警通道API 在实际生产环境你可以 1. 使用腾讯云“消息服务”的API。 2. 通过“云监控”的告警通道配置回调URL到一个聚合通知服务。 3. 直接调用企业微信、钉钉等机器人的Webhook。 # 这里仅打印日志实际通知逻辑需自行实现 message f 【磁盘自动扩容通知】 实例ID: {instance_id} 磁盘索引: {disk_index} 原大小: {old_size} GB 新大小: {new_size} GB 状态: {成功 if is_success else 失败} {f错误信息: {error_msg} if error_msg else } print(message) # TODO: 调用真实的通知发送API # requests.post(your_webhook_url, json{text: message}) def main_handler(event, context): print(Received event: %s % json.dumps(event)) # 1. 解析告警事件 try: # 云监控告警事件格式固定从中提取实例ID和磁盘信息 # 注意实际事件结构需参考腾讯云官方文档这里为示例 alarm_event json.loads(event[Message]) dimensions alarm_event[Dimensions] instance_id dimensions.get(instanceId) # 假设我们在告警策略的“高级配置”-“回调”中传入了磁盘索引 # 或者可以从告警信息中解析出具体的磁盘设备名如/dev/vdb disk_index int(event.get(Trigger, {}).get(diskIndex, 0)) # 示例实际来源可能不同 if not instance_id: print(Error: Cannot get instanceId from alarm event.) return {error: Invalid alarm data} except Exception as e: print(fError parsing event: {e}) return {error: Event parsing failed} # 2. 获取当前磁盘信息确定扩容大小 try: cred credential.Credential( os.environ.get(TENCENTCLOUD_SECRETID), os.environ.get(TENCENTCLOUD_SECRETKEY), os.environ.get(TENCENTCLOUD_SESSIONTOKEN) ) httpProfile HttpProfile() httpProfile.endpoint cvm.tencentcloudapi.com clientProfile ClientProfile() clientProfile.httpProfile httpProfile client cvm_client.CvmClient(cred, ap-guangzhou, clientProfile) # 查询实例当前配置 req_desc models.DescribeInstancesRequest() req_desc.InstanceIds [instance_id] resp_desc client.DescribeInstances(req_desc) instance resp_desc.InstanceSet[0] # 找到目标磁盘这里简化处理假设按索引找系统盘或数据盘 # 实际生产代码需要更严谨地匹配磁盘设备名或挂载点 target_disk instance.SystemDisk if disk_index 0 else instance.DataDisks[disk_index-1] old_size target_disk.DiskSize new_size old_size 50 # 固定增加50GB except Exception as e: error_msg fFailed to get instance info: {e} print(error_msg) send_wechat_notification(instance_id, disk_index, 0, 0, False, error_msg) return {error: error_msg} # 3. 执行磁盘扩容 try: req_resize models.ResizeInstanceDisksRequest() # 构建扩容参数这里需要根据CVM API文档精确构造 # 示例参数实际请查阅最新API文档 disk_config models.DataDisk() disk_config.DiskSize new_size disk_config.DiskId target_disk.DiskId req_resize.DataDisks [disk_config] req_resize.InstanceId instance_id req_resize.ForceStop False # 是否强制关机生产环境需谨慎 print(fAttempting to resize disk {target_disk.DiskId} from {old_size}GB to {new_size}GB) resp_resize client.ResizeInstanceDisks(req_resize) # 检查异步任务状态此处简化实际应轮询异步任务结果 print(fResize request submitted. RequestId: {resp_resize.RequestId}) # 4. 发送成功通知 send_wechat_notification(instance_id, disk_index, old_size, new_size, True) return { code: 0, message: Disk resize request submitted successfully., instance_id: instance_id, old_size: old_size, new_size: new_size, request_id: resp_resize.RequestId } except Exception as e: error_msg fFailed to resize disk: {e} print(error_msg) send_wechat_notification(instance_id, disk_index, old_size, new_size, False, error_msg) return {error: error_msg}配置环境变量与层在函数配置中添加环境变量TENCENTCLOUD_SECRETID和TENCENTCLOUD_SECRETKEY。注意更安全的做法是使用上面绑定的执行角色SCF会自动注入临时密钥无需显式配置。上述代码中os.environ.get是为了兼容两种方式。由于代码中使用了Tencent Cloud SDK需要在“层管理”中关联对应的Python SDK层或者在部署时打包SDK到代码包中。3.3 关联告警策略完成闭环函数创建好后它还是一个孤立的单元。我们需要用云监控的告警来触发它。创建或修改告警策略进入云监控控制台找到需要监控的CVM实例的磁盘使用率指标创建告警策略。例如磁盘使用率 85%持续5个周期5分钟。在告警策略的“告警通知”部分除了配置常规的通知模板如邮件、短信最关键的是找到“高级配置”或“触发条件”下的“回调”或“触发函数”选项。选择“云函数触发”然后选中我们刚刚创建的disk_auto_expansion函数。传递参数这里有个技巧。告警事件本身会包含实例ID但可能不包含你要扩容的具体磁盘索引。你可以在回调配置里以JSON格式传入自定义参数比如{diskIndex: 1}表示扩容第一个数据盘索引0通常是系统盘。这样函数就能从event参数里解析出这个diskIndex。测试与验证手动将一台测试机的磁盘使用率弄高比如用dd命令写文件触发告警。在云函数SCF控制台查看该函数的“调用日志”观察事件是否被正确触发逻辑是否执行。检查CVM控制台确认磁盘扩容任务是否已下发。注意磁盘扩容通常需要实例重启除非是云硬盘且支持热扩展SCF函数只是调用API发起请求实际扩容操作由后台异步完成。查看你配置的通知渠道是否收到了执行结果的通知。4. 进阶场景与Skill设计模式探讨基础的磁盘扩容只是牛刀小试。可观测Skill的想象力远不止于此。我们可以基于不同的可观测数据源和运维场景设计出更复杂的Skill。4.1 基于日志分析的智能止损Skill场景应用突然出现大量500错误日志中涌现特定的异常堆栈如NullPointerException或数据库连接超时。传统做法运维收到告警登录日志平台搜索关键词分析异常模式可能还需要联系开发最终决定是否回滚或重启服务。Skill实现思路触发器配置CLS日志服务的监控告警对错误日志的每分钟出现次数设定阈值。执行器逻辑函数被触发后首先调用CLS API检索最近5分钟内包含关键错误的日志进行聚合分析判断错误类型和影响的接口范围。如果是已知的、可通过重启缓解的瞬态错误如某个微服务实例内存泄漏则自动调用TKE或CVM的API对特定Pod或实例进行隔离重启。同时立即通过聚合通知渠道如钉钉群发送详细的分析报告和已执行的操作并相关责任人。如果是未知错误或影响面过大则升级告警只通知不自动处理等待人工介入。设计要点分级决策Skill内需要内置简单的决策树区分哪些情况可以自动处理哪些需要上报。切忌“一刀切”的全自动安全永远是第一位。丰富上下文传递给人工告警的信息必须足够详细包括错误样本、影响面评估、已尝试的自动操作等方便人工快速决策。4.2 基于APM指标的应用自愈Skill场景通过APM监控发现某个核心接口的P99响应时间在业务高峰期间持续劣化超过SLA阈值。传统做法运维人员观察图表判断是否需要扩容然后手动在控制台调整副本数或规格。Skill实现思路触发器配置APM的告警策略针对特定接口的P99响应时间或错误率。执行器逻辑函数触发后调用APM和云监控的API获取该接口所在服务近一小时的流量、资源使用率CPU、内存等关联指标。进行简单的根因分析是流量激增导致还是依赖的下游服务变慢或者是本实例资源不足如果判断为资源不足型性能劣化则自动调用TKE的HPAHorizontal Pod AutoscalerAPI修改扩缩容阈值或直接调用CVM/SA2 API增加副本数。扩容后继续监控指标如果一段时间后指标恢复正常可以触发另一个“缩容”Skill在业务低峰期将资源回收以节省成本。设计要点避免震荡自愈逻辑必须加入冷却期Cooldown Period和防抖机制。例如扩容后30分钟内不再触发新的扩容事件防止因监控数据延迟或瞬时抖动导致的频繁、不必要的伸缩。成本意识自动扩容容易自动缩容难。需要设计更保守、更延迟的缩容策略并确保缩容不会影响服务的可用性。4.3 组合Skill构建运维应急预案工作流更复杂的场景可能需要多个Skill按顺序或条件执行形成一个工作流。虽然腾讯云可观测Skill平台可能提供了图形化编排界面但其底层依然是事件驱动。例如一个“数据库主节点故障切换”的应急预案Skill A检测由云监控的数据库存活告警触发。它首先执行深度检测确认是否是真故障如连续ping失败、特定端口无响应。Skill B切换如果Skill A确认故障则发出一个“确认故障”的自定义事件。Skill B监听此事件执行主从切换命令更新DNS或连接串配置。Skill C通知与记录监听“切换完成”或“切换失败”事件向运维团队发送详细切换报告并将本次事件的所有操作日志、时间线记录到CMDB或事故事件管理系统中。这种模式将一个大而复杂的运维操作拆解成一个个职责单一、可独立测试和复用的Skill通过事件流进行串联大大提升了自动化系统的可维护性和可靠性。5. 落地实践中的关键考量与避坑指南将可观测Skill从概念验证推向生产落地会面临一系列工程和运维上的挑战。下面是一些从实践中总结出来的关键点和常见“坑”。5.1 权限管理与安全边界这是自动化脚本的第一道也是最重要的防线。前面提到了最小权限原则这里再强调几个细节角色分离为“只读诊断型Skill”和“可写操作型Skill”创建不同的执行角色。一个只需要查日志的Skill绝不应该拥有重启服务器的权限。资源标签利用腾讯云的标签功能为生产、测试环境的资源打上不同标签如Env:Production,Env:Test。在Skill的执行逻辑里加入环境判断。例如一个自动重启的Skill可以配置为只对带有Env:Test标签的实例生效生产环境仅通知不操作。这为自动化增加了一道安全开关。审批流程集成对于高风险操作如数据库删除、生产环境大规模扩容Skill不应直接执行而是应该触发一个审批流程例如调用腾讯云HiFlow或企业微信的审批API待审批通过后再由另一个Skill或人工执行。这实现了“自动化决策受控化执行”。5.2 可观测Skill自身的可观测性一个用于自动化运维的Skill其本身必须是高度可靠和透明的。否则它就成了一个“黑盒”一旦出错后果可能比它要解决的问题更严重。详尽日志Skill函数内的每一步关键操作、决策依据、API调用请求与响应都必须打印日志。使用SCF内置的日志功能并确保日志等级合理INFO, ERROR, WARN。执行状态追踪对于耗时较长的异步操作如扩容磁盘Skill在发起请求后应该记录一个任务ID如RequestId到外部存储如云数据库TDSQL或对象存储COS。可以再配套一个“任务状态查询Skill”或一个简单的控制台页面让运维能随时查看自动化任务的执行状态。Metrics监控为你的Skill函数本身配置监控。监控其调用次数、失败次数、运行时长、内存使用量等。如果某个Skill频繁失败或超时这本身就是一个需要优先处理的告警。5.3 错误处理与重试机制网络抖动、API限流、依赖服务短暂不可用在生产环境中是常态。Skill必须有健壮的错误处理。分类处理错误在代码中区分不同类型的错误。可重试错误如网络超时、API返回5xx错误、限流429。对于这类错误Skill应实现指数退避的重试逻辑。业务逻辑错误如实例已关机无法扩容、磁盘已达上限。这类错误重试无意义应直接失败并发送明确告警。权限错误如403 Forbidden。这通常是配置问题需要立即失败并通知管理员检查权限。设置合理超时SCF函数有执行超时限制最大900秒。对于可能长时间运行的操作如等待一个异步任务完成不要用函数同步等待。应该采用“触发-查询”分离的模式第一个函数发起操作并返回记录任务ID第二个函数由定时触发器启动轮询任务状态。死信队列对于重试多次仍失败的事件不应丢弃。可以将其内容原始事件和错误信息投递到一个“死信队列”如CMQ主题或另一个CLS日志主题供后续人工排查。这确保了事件不丢失。5.4 版本控制与灰度发布当Skill逻辑需要更新时如何安全地发布别名与版本充分利用SCF的版本和别名功能。生产环境始终指向一个稳定的别名如PROD该别名关联一个具体的函数版本如1。开发新版本2后先将别名切换到2在测试环境验证。验证无误后再在控制台将PROD别名从版本1切换到版本2。一键切换快速回滚。流量染色与灰度对于影响面特别大的Skill可以考虑灰度发布。例如只有带有特定标签Canary: true的实例触发的告警才会路由到新版本的Skill。通过观察这部分实例的自动化效果再决定是否全量发布。5.5 成本控制自动化虽好但也要警惕“失控的自动化”带来的成本激增。设置预算和告警为执行自动化Skill的云函数SCF、可能产生的API调用费用如频繁调用CVM API设置预算告警。避免不必要的触发优化告警策略减少噪音告警。例如磁盘使用率告警可以增加“仅在业务时间段触发”的条件避免夜间低流量时期的误判。清理资源对于自动扩容的Skill一定要配套自动缩容或资源回收的Skill。确保在业务低谷期资源能被释放避免“只增不减”导致的资源浪费。从“人肉运维”到“自动化运维”再到“可观测驱动的自动化运维”腾讯云可观测Skill的推出标志着运维工具链正在向更高阶的“自愈”和“自治”能力演进。它把运维人员从繁琐、重复的“救火”工作中解放出来让他们能更专注于构建更稳定、更高效的系统架构本身。当然这条路需要谨慎地铺就从简单的、风险低的场景开始逐步构建信任完善流程最终让机器成为运维团队最可靠、不知疲倦的助手。 腾讯云可观测Skill实战：从监控告警到自动化运维的闭环设计
1. 项目概述当“可观测”遇上“Skill”运维工作流的新范式最近在腾讯云的官方动态里看到一个挺有意思的新玩意儿叫“可观测Skill”。光看名字可能有点云里雾里但如果你是个一线运维或者SRE天天跟监控告警、日志排查、性能分析打交道那这个东西很可能就是你一直在等的“自动化扳手”。简单来说它不是一个全新的监控产品而是给腾讯云现有的可观测平台比如应用性能监控APM、日志服务CLS、云监控Cloud Monitor等装上了一套“智能插件”系统。这套系统的核心是把一些常见的、重复的、需要人工介入的运维操作封装成一个个可复用的“Skill”技能然后通过API或者事件驱动的方式自动执行。这解决了什么问题想象一下这些日常场景凌晨三点告警响了提示某台云服务器CPU持续飙高。你睡眼惺忪地打开电脑登录控制台查看监控图表分析进程可能还得手动执行个重启或者扩容操作。又或者每次发版后都需要人工去检查一遍核心接口的响应时间和错误率做一份简单的健康报告。这些工作技术含量未必多高但极其消耗精力容易出错而且把人牢牢绑在了告警通知上。“可观测Skill”想做的就是把这些“看到问题”之后的“动手处理”环节尽可能地自动化掉让运维人员从重复劳动中解放出来更专注于架构优化和故障根因分析这类高价值工作。它本质上是一种“观测即行动”理念的落地让监控系统不仅会“报警”还能初步“治病”。2. 核心设计思路从“观测”到“行动”的闭环自动化2.1 为什么是“Skill”而不是“脚本”或“工作流”看到“Skill”这个词你可能会联想到Alexa或Google Assistant里的技能。这个类比很贴切。在智能音箱里你说“播放音乐”它调用的是“音乐播放Skill”。在腾讯云可观测的语境下系统“看到”了“CPU使用率超过90%持续5分钟”这个事件它就可以自动调用“重启服务Skill”或“扩容节点Skill”。那么为什么不直接用写脚本或者配置复杂的工作流比如用云函数SCF加消息队列CMQ自己搭呢这里面的核心差异在于封装程度和易用性。开箱即用与场景化封装一个成熟的Skill比如“日志关键词告警并自动提取样本”它内部可能集成了从CLS触发、到日志查询、到关键信息提取、再到通过邮件或钉钉发送结果的全套逻辑。用户无需关心CLS的查询语法、消息格式转换、API限流等问题只需在界面勾选启用、配置几个关键参数如日志主题、关键词、接收人即可。这大大降低了自动化门槛让不擅长编程的运维也能快速搭建自动化流程。标准化与安全管控腾讯云官方或认证伙伴提供的Skill经过了标准化封装和安全审计。相比于个人编写的脚本其在权限管理使用预设角色而非个人密钥、错误处理、日志记录等方面更为规范更易于在团队内部分享和复用也符合企业安全合规的要求。生态与可发现性Skill可以被发布到一个“技能市场”其他用户可以直接搜索、订阅和使用。这形成了一个运维自动化资产的积累和流通平台好的实践能快速推广。你自己写的工作流脚本可能还躺在某个Git仓库里只有团队内少数人知道。2.2 Skill的触发与执行引擎剖析一个Skill要跑起来离不开两个核心部分触发器Trigger和执行器Executor。触发器决定了Skill在什么条件下被激活。目前来看主要基于腾讯云可观测体系内的事件监控告警触发这是最直接的场景。当云监控的告警策略被触发时如CPU使用率 85%该告警事件可以作为一个触发器自动启动关联的Skill。日志事件触发通过日志服务CLS的监控告警功能当检测到日志中出现特定错误码、异常堆栈或频次异常时触发Skill。应用性能指标触发通过应用性能监控APM当某接口的平均响应时间突增或错误率飙升时触发。定时触发虽然不完全是“可观测”事件但定时任务也是一个重要补充比如每天凌晨自动执行一次健康检查Skill生成日报。执行器是Skill真正干活的部分。它通常由一个或多个腾讯云服务编排而成云函数SCF这是最核心的执行单元。Skill的业务逻辑比如调用API、处理数据、判断逻辑以函数的形式运行在SCF中。它无服务器、按需执行、弹性伸缩的特性非常适合这种事件驱动、偶发执行的自动化任务。API网关如果Skill需要对外提供HTTP API接口比如手动触发某个运维操作或者需要调用外部系统的APIAPI网关负责路由、鉴权和流量管理。其他云服务执行过程中可能会调用CVM的API进行重启、调用CLS API查询日志、调用VPC API调整网络配置、调用短信/邮件服务发送通知等。整个流程可以概括为可观测平台发现异常事件 - 事件总线EventBridge或类似机制路由事件 - 触发对应的云函数SCF即Skill- Skill内部逻辑调用各类云API执行具体操作 - 将执行结果记录到日志或通知用户。这样就形成了一个从感知到行动的完整闭环。3. 实战构建你的第一个可观测Skill——自动磁盘扩容概念讲得再多不如动手试一次。我们以一个非常经典且实用的场景为例为云服务器CVM的磁盘配置自动扩容Skill。当监控到磁盘使用率超过85%时自动为其增加50GB容量并发送微信通知。3.1 前置准备与权限配置在开始编排Skill之前我们需要确保有正确的“工具”和“权限”。开通服务确保你的腾讯云账号已开通云监控Cloud Monitor、云函数SCF、访问管理CAM服务。这些都是基础服务通常默认已开通。创建执行角色这是安全的关键。我们不能让云函数直接用账号的主密钥去操作资源。进入CAM控制台创建一个新的自定义角色例如命名为SCF_Autoscale_Operator。在角色载体选择“腾讯云产品服务”关联产品选择“云函数SCF”。为这个角色附加策略。至少需要以下权限QcloudCVMFullAccess或更细粒度的QcloudCVMInnerReadOnlyAccess读 QcloudCVMRunInstances扩容磁盘相关权限。建议从最小权限开始如果操作失败再根据报错信息追加。QcloudMonitorFullAccess用于读取监控数据和告警信息。QcloudCLSReadOnlyAccess如果Skill需要查日志。你还可以创建一个自定义策略精确到cvm:ResizeInstanceDisks这个API动作。准备通知渠道为了接收结果我们需要在腾讯云“访问管理”“消息中心”“消息订阅”里配置好接收通知的邮箱、手机号或者更推荐的方式——绑定微信公众号接收模板消息。这里我们假设已绑定微信。注意权限是自动化脚本的“生死线”。实践中强烈建议遵循最小权限原则为每个Skill创建独立的、权限精确的执行角色。避免使用AdministratorAccess这种万能钥匙一旦函数代码有漏洞或逻辑错误可能导致灾难性的误操作。3.2 Skill逻辑编排与代码实现接下来我们进入云函数SCF控制台创建函数。创建函数函数类型选择“事件函数”。运行环境选择你熟悉的例如 Python 3.7。执行方法填写index.main_handler。执行角色选择上一步我们创建的SCF_Autoscale_Operator。编写函数代码 以下是index.py的一个简化示例它处理从云监控告警触发的事件。# -*- coding: utf8 -*- import json import os from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.cvm.v20170312 import cvm_client, models def send_wechat_notification(instance_id, disk_index, old_size, new_size, is_success, error_msgNone): 发送微信通知此处为模拟实际需调用微信模板消息API或腾讯云告警通道API 在实际生产环境你可以 1. 使用腾讯云“消息服务”的API。 2. 通过“云监控”的告警通道配置回调URL到一个聚合通知服务。 3. 直接调用企业微信、钉钉等机器人的Webhook。 # 这里仅打印日志实际通知逻辑需自行实现 message f 【磁盘自动扩容通知】 实例ID: {instance_id} 磁盘索引: {disk_index} 原大小: {old_size} GB 新大小: {new_size} GB 状态: {成功 if is_success else 失败} {f错误信息: {error_msg} if error_msg else } print(message) # TODO: 调用真实的通知发送API # requests.post(your_webhook_url, json{text: message}) def main_handler(event, context): print(Received event: %s % json.dumps(event)) # 1. 解析告警事件 try: # 云监控告警事件格式固定从中提取实例ID和磁盘信息 # 注意实际事件结构需参考腾讯云官方文档这里为示例 alarm_event json.loads(event[Message]) dimensions alarm_event[Dimensions] instance_id dimensions.get(instanceId) # 假设我们在告警策略的“高级配置”-“回调”中传入了磁盘索引 # 或者可以从告警信息中解析出具体的磁盘设备名如/dev/vdb disk_index int(event.get(Trigger, {}).get(diskIndex, 0)) # 示例实际来源可能不同 if not instance_id: print(Error: Cannot get instanceId from alarm event.) return {error: Invalid alarm data} except Exception as e: print(fError parsing event: {e}) return {error: Event parsing failed} # 2. 获取当前磁盘信息确定扩容大小 try: cred credential.Credential( os.environ.get(TENCENTCLOUD_SECRETID), os.environ.get(TENCENTCLOUD_SECRETKEY), os.environ.get(TENCENTCLOUD_SESSIONTOKEN) ) httpProfile HttpProfile() httpProfile.endpoint cvm.tencentcloudapi.com clientProfile ClientProfile() clientProfile.httpProfile httpProfile client cvm_client.CvmClient(cred, ap-guangzhou, clientProfile) # 查询实例当前配置 req_desc models.DescribeInstancesRequest() req_desc.InstanceIds [instance_id] resp_desc client.DescribeInstances(req_desc) instance resp_desc.InstanceSet[0] # 找到目标磁盘这里简化处理假设按索引找系统盘或数据盘 # 实际生产代码需要更严谨地匹配磁盘设备名或挂载点 target_disk instance.SystemDisk if disk_index 0 else instance.DataDisks[disk_index-1] old_size target_disk.DiskSize new_size old_size 50 # 固定增加50GB except Exception as e: error_msg fFailed to get instance info: {e} print(error_msg) send_wechat_notification(instance_id, disk_index, 0, 0, False, error_msg) return {error: error_msg} # 3. 执行磁盘扩容 try: req_resize models.ResizeInstanceDisksRequest() # 构建扩容参数这里需要根据CVM API文档精确构造 # 示例参数实际请查阅最新API文档 disk_config models.DataDisk() disk_config.DiskSize new_size disk_config.DiskId target_disk.DiskId req_resize.DataDisks [disk_config] req_resize.InstanceId instance_id req_resize.ForceStop False # 是否强制关机生产环境需谨慎 print(fAttempting to resize disk {target_disk.DiskId} from {old_size}GB to {new_size}GB) resp_resize client.ResizeInstanceDisks(req_resize) # 检查异步任务状态此处简化实际应轮询异步任务结果 print(fResize request submitted. RequestId: {resp_resize.RequestId}) # 4. 发送成功通知 send_wechat_notification(instance_id, disk_index, old_size, new_size, True) return { code: 0, message: Disk resize request submitted successfully., instance_id: instance_id, old_size: old_size, new_size: new_size, request_id: resp_resize.RequestId } except Exception as e: error_msg fFailed to resize disk: {e} print(error_msg) send_wechat_notification(instance_id, disk_index, old_size, new_size, False, error_msg) return {error: error_msg}配置环境变量与层在函数配置中添加环境变量TENCENTCLOUD_SECRETID和TENCENTCLOUD_SECRETKEY。注意更安全的做法是使用上面绑定的执行角色SCF会自动注入临时密钥无需显式配置。上述代码中os.environ.get是为了兼容两种方式。由于代码中使用了Tencent Cloud SDK需要在“层管理”中关联对应的Python SDK层或者在部署时打包SDK到代码包中。3.3 关联告警策略完成闭环函数创建好后它还是一个孤立的单元。我们需要用云监控的告警来触发它。创建或修改告警策略进入云监控控制台找到需要监控的CVM实例的磁盘使用率指标创建告警策略。例如磁盘使用率 85%持续5个周期5分钟。在告警策略的“告警通知”部分除了配置常规的通知模板如邮件、短信最关键的是找到“高级配置”或“触发条件”下的“回调”或“触发函数”选项。选择“云函数触发”然后选中我们刚刚创建的disk_auto_expansion函数。传递参数这里有个技巧。告警事件本身会包含实例ID但可能不包含你要扩容的具体磁盘索引。你可以在回调配置里以JSON格式传入自定义参数比如{diskIndex: 1}表示扩容第一个数据盘索引0通常是系统盘。这样函数就能从event参数里解析出这个diskIndex。测试与验证手动将一台测试机的磁盘使用率弄高比如用dd命令写文件触发告警。在云函数SCF控制台查看该函数的“调用日志”观察事件是否被正确触发逻辑是否执行。检查CVM控制台确认磁盘扩容任务是否已下发。注意磁盘扩容通常需要实例重启除非是云硬盘且支持热扩展SCF函数只是调用API发起请求实际扩容操作由后台异步完成。查看你配置的通知渠道是否收到了执行结果的通知。4. 进阶场景与Skill设计模式探讨基础的磁盘扩容只是牛刀小试。可观测Skill的想象力远不止于此。我们可以基于不同的可观测数据源和运维场景设计出更复杂的Skill。4.1 基于日志分析的智能止损Skill场景应用突然出现大量500错误日志中涌现特定的异常堆栈如NullPointerException或数据库连接超时。传统做法运维收到告警登录日志平台搜索关键词分析异常模式可能还需要联系开发最终决定是否回滚或重启服务。Skill实现思路触发器配置CLS日志服务的监控告警对错误日志的每分钟出现次数设定阈值。执行器逻辑函数被触发后首先调用CLS API检索最近5分钟内包含关键错误的日志进行聚合分析判断错误类型和影响的接口范围。如果是已知的、可通过重启缓解的瞬态错误如某个微服务实例内存泄漏则自动调用TKE或CVM的API对特定Pod或实例进行隔离重启。同时立即通过聚合通知渠道如钉钉群发送详细的分析报告和已执行的操作并相关责任人。如果是未知错误或影响面过大则升级告警只通知不自动处理等待人工介入。设计要点分级决策Skill内需要内置简单的决策树区分哪些情况可以自动处理哪些需要上报。切忌“一刀切”的全自动安全永远是第一位。丰富上下文传递给人工告警的信息必须足够详细包括错误样本、影响面评估、已尝试的自动操作等方便人工快速决策。4.2 基于APM指标的应用自愈Skill场景通过APM监控发现某个核心接口的P99响应时间在业务高峰期间持续劣化超过SLA阈值。传统做法运维人员观察图表判断是否需要扩容然后手动在控制台调整副本数或规格。Skill实现思路触发器配置APM的告警策略针对特定接口的P99响应时间或错误率。执行器逻辑函数触发后调用APM和云监控的API获取该接口所在服务近一小时的流量、资源使用率CPU、内存等关联指标。进行简单的根因分析是流量激增导致还是依赖的下游服务变慢或者是本实例资源不足如果判断为资源不足型性能劣化则自动调用TKE的HPAHorizontal Pod AutoscalerAPI修改扩缩容阈值或直接调用CVM/SA2 API增加副本数。扩容后继续监控指标如果一段时间后指标恢复正常可以触发另一个“缩容”Skill在业务低峰期将资源回收以节省成本。设计要点避免震荡自愈逻辑必须加入冷却期Cooldown Period和防抖机制。例如扩容后30分钟内不再触发新的扩容事件防止因监控数据延迟或瞬时抖动导致的频繁、不必要的伸缩。成本意识自动扩容容易自动缩容难。需要设计更保守、更延迟的缩容策略并确保缩容不会影响服务的可用性。4.3 组合Skill构建运维应急预案工作流更复杂的场景可能需要多个Skill按顺序或条件执行形成一个工作流。虽然腾讯云可观测Skill平台可能提供了图形化编排界面但其底层依然是事件驱动。例如一个“数据库主节点故障切换”的应急预案Skill A检测由云监控的数据库存活告警触发。它首先执行深度检测确认是否是真故障如连续ping失败、特定端口无响应。Skill B切换如果Skill A确认故障则发出一个“确认故障”的自定义事件。Skill B监听此事件执行主从切换命令更新DNS或连接串配置。Skill C通知与记录监听“切换完成”或“切换失败”事件向运维团队发送详细切换报告并将本次事件的所有操作日志、时间线记录到CMDB或事故事件管理系统中。这种模式将一个大而复杂的运维操作拆解成一个个职责单一、可独立测试和复用的Skill通过事件流进行串联大大提升了自动化系统的可维护性和可靠性。5. 落地实践中的关键考量与避坑指南将可观测Skill从概念验证推向生产落地会面临一系列工程和运维上的挑战。下面是一些从实践中总结出来的关键点和常见“坑”。5.1 权限管理与安全边界这是自动化脚本的第一道也是最重要的防线。前面提到了最小权限原则这里再强调几个细节角色分离为“只读诊断型Skill”和“可写操作型Skill”创建不同的执行角色。一个只需要查日志的Skill绝不应该拥有重启服务器的权限。资源标签利用腾讯云的标签功能为生产、测试环境的资源打上不同标签如Env:Production,Env:Test。在Skill的执行逻辑里加入环境判断。例如一个自动重启的Skill可以配置为只对带有Env:Test标签的实例生效生产环境仅通知不操作。这为自动化增加了一道安全开关。审批流程集成对于高风险操作如数据库删除、生产环境大规模扩容Skill不应直接执行而是应该触发一个审批流程例如调用腾讯云HiFlow或企业微信的审批API待审批通过后再由另一个Skill或人工执行。这实现了“自动化决策受控化执行”。5.2 可观测Skill自身的可观测性一个用于自动化运维的Skill其本身必须是高度可靠和透明的。否则它就成了一个“黑盒”一旦出错后果可能比它要解决的问题更严重。详尽日志Skill函数内的每一步关键操作、决策依据、API调用请求与响应都必须打印日志。使用SCF内置的日志功能并确保日志等级合理INFO, ERROR, WARN。执行状态追踪对于耗时较长的异步操作如扩容磁盘Skill在发起请求后应该记录一个任务ID如RequestId到外部存储如云数据库TDSQL或对象存储COS。可以再配套一个“任务状态查询Skill”或一个简单的控制台页面让运维能随时查看自动化任务的执行状态。Metrics监控为你的Skill函数本身配置监控。监控其调用次数、失败次数、运行时长、内存使用量等。如果某个Skill频繁失败或超时这本身就是一个需要优先处理的告警。5.3 错误处理与重试机制网络抖动、API限流、依赖服务短暂不可用在生产环境中是常态。Skill必须有健壮的错误处理。分类处理错误在代码中区分不同类型的错误。可重试错误如网络超时、API返回5xx错误、限流429。对于这类错误Skill应实现指数退避的重试逻辑。业务逻辑错误如实例已关机无法扩容、磁盘已达上限。这类错误重试无意义应直接失败并发送明确告警。权限错误如403 Forbidden。这通常是配置问题需要立即失败并通知管理员检查权限。设置合理超时SCF函数有执行超时限制最大900秒。对于可能长时间运行的操作如等待一个异步任务完成不要用函数同步等待。应该采用“触发-查询”分离的模式第一个函数发起操作并返回记录任务ID第二个函数由定时触发器启动轮询任务状态。死信队列对于重试多次仍失败的事件不应丢弃。可以将其内容原始事件和错误信息投递到一个“死信队列”如CMQ主题或另一个CLS日志主题供后续人工排查。这确保了事件不丢失。5.4 版本控制与灰度发布当Skill逻辑需要更新时如何安全地发布别名与版本充分利用SCF的版本和别名功能。生产环境始终指向一个稳定的别名如PROD该别名关联一个具体的函数版本如1。开发新版本2后先将别名切换到2在测试环境验证。验证无误后再在控制台将PROD别名从版本1切换到版本2。一键切换快速回滚。流量染色与灰度对于影响面特别大的Skill可以考虑灰度发布。例如只有带有特定标签Canary: true的实例触发的告警才会路由到新版本的Skill。通过观察这部分实例的自动化效果再决定是否全量发布。5.5 成本控制自动化虽好但也要警惕“失控的自动化”带来的成本激增。设置预算和告警为执行自动化Skill的云函数SCF、可能产生的API调用费用如频繁调用CVM API设置预算告警。避免不必要的触发优化告警策略减少噪音告警。例如磁盘使用率告警可以增加“仅在业务时间段触发”的条件避免夜间低流量时期的误判。清理资源对于自动扩容的Skill一定要配套自动缩容或资源回收的Skill。确保在业务低谷期资源能被释放避免“只增不减”导致的资源浪费。从“人肉运维”到“自动化运维”再到“可观测驱动的自动化运维”腾讯云可观测Skill的推出标志着运维工具链正在向更高阶的“自愈”和“自治”能力演进。它把运维人员从繁琐、重复的“救火”工作中解放出来让他们能更专注于构建更稳定、更高效的系统架构本身。当然这条路需要谨慎地铺就从简单的、风险低的场景开始逐步构建信任完善流程最终让机器成为运维团队最可靠、不知疲倦的助手。