北京
一条看似简单的Slack审批消息，背后是一整套防止误删云基础设施的安全设计。当工程师在手机端点击“批准修复”按钮，系统会依次执行快照创建、等待快照完成、删除卷，最后编辑消息说明操作结果。但真正的难点不在于流程串联，而在于如何应对过期的点击、被重放的请求，以及在此期间被人为保护的资源——这些都不会造成破坏。
Slack的交互机制由两个看似对话但实际独立的通道组成。应用通过传入Webhook向频道发送消息，用户点击按钮后，Slack服务器会向应用注册的URL发起一个全新的HTTP POST请求。这个请求来自公网，本身没有任何认证信息，无法证明它真的来自Slack，也无法证明背后是一个人类在操作。这正是整个安全问题的核心，后续所有设计都围绕这一点展开。
Webhook只能向指定频道推送消息，无法读取任何内容。对于通知类机器人而言，这样的权限恰好够用——无需OAuth流程，无需机器人令牌，也无需审核任何权限范围。在Slack应用配置中开启交互与快捷方式选项，设置请求URL后即可开始工作。本地开发时需要使用ngrok等隧道工具，它的免费版每次重启都会更换URL，如果按钮点击后没有任何反应，首先要检查的就是这个地址是否已经更新。
签名密钥是让回调变得可信的关键。在应用凭证中找到Signing Secret并配置到环境变量中，没有它，任何人都可以通过构造格式正确的POST请求来触发基础设施的删除操作。这是整个安全链路中最重要的一环。
Block Kit消息由JSON数组构成，最简实现可以一行代码完成。但工程师在手机上处理告警时，大约只有十秒钟时间做出判断，需要清楚了解这是什么资源、在哪里、涉及多少成本，以及点击按钮的后果。实际的实现需要考虑这些信息密度要求，确保操作者能够在短时间内做出正确决策。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
