核心用法
SIGNL4 是一款面向 DevOps、IT 运维和现场服务的移动告警与值班管理 SaaS 平台，通过入站 webhook 接收外部系统的告警推送，并将通知分发给值班人员。
本 Skill 封装了 SIGNL4 的完整 webhook 交互能力：
- 发送告警：构造 JSON 负载，携带标题、详情、外部关联 ID、服务名、地理位置、告警场景等元数据，推送至团队 webhook 端点。
- 关闭告警：利用创建时指定的
X-S4-ExternalID，将状态置为resolved，实现告警生命周期的闭环管理。 - 认证方式：采用 URL 内嵌的 team secret（
SIGNL4_TEAM_SECRET），无需 OAuth 或 API Key 的额外头部。
关键 HTTP 头包括 X-S4-Status（new/resolved）、X-S4-AlertingScenario（支持 single_ack/multi_ack/emergency 等策略）、X-S4-Location（经纬度坐标）。外部 ID 是关闭告警的必要条件，强烈建议在创建时始终携带。
显著优点
1. 极简集成：纯 webhook 调用，无需 SDK 或复杂认证流程，curl 即可调试。
2. 告警闭环：支持通过外部 ID 关闭告警，适合与 CMDB、ITSM 或监控系统的自动恢复联动。
3. 移动优先：SIGNL4 原生提供 iOS/Android 应用，支持推送、短信、电话、邮件多渠道触达。
4. 场景化策略：内置 single_ack（单人确认）、multi_ack（多人确认）、emergency（紧急模式）等策略，适配不同 SLA 要求。
5. 地理位置感知：可携带 GPS 坐标，适用于现场服务或 IoT 设备的物理位置告警。
潜在缺点与局限性
1. URL 密钥风险：team secret 直接暴露在 webhook URL 中，若泄露则任何知道 URL 的实体均可向团队推送告警，需严格保密。
2. 无内置重试机制：curl 调用失败需自行实现重试逻辑，网络抖动可能导致告警丢失。
3. 功能边界：仅支持告警的创建与关闭，无法查询历史告警、管理用户或配置排班，需通过 SIGNL4 管理后台或 REST API 补充。
4. 外部 ID 依赖：关闭操作强依赖创建时的外部 ID，若 ID 丢失或拼写错误，告警将滞留未关闭。
5. 地区可用性：SIGNL4 服务器位于德国/欧盟，对国内用户可能存在网络延迟或合规顾虑。
适合人群
- DevOps / SRE 团队：需要将 Jenkins、GitHub Actions、Prometheus Alertmanager 等 CI/CD 或监控系统的告警推送给值班人员。
- IT 运维工程师：希望实现告警的自动创建与基于工单系统的自动关闭。
- IoT / 现场服务团队：需要结合 GPS 位置推送设备异常告警。
常规风险
- 密钥泄露：
SIGNL4_TEAM_SECRET一旦暴露，攻击者可向团队发送垃圾告警或伪造关闭请求，导致告警疲劳或真实事件被掩盖。 - 误操作关闭：错误的外部 ID 可能误关闭他人创建的告警。
- 网络不可达： webhook 调用失败时无本地持久化，需调用方确保可靠投递。