diff --git a/content/posts/alert-filtering/index.md b/content/posts/alert-filtering/index.md
index 40c61b3a0..84ae45cd1 100644
--- a/content/posts/alert-filtering/index.md
+++ b/content/posts/alert-filtering/index.md
@@ -6,7 +6,6 @@ tags:
   - 项目
 categories:
   - 安全工具
-draft: true
 ---
 
 如何从安全产品的大量误报中筛选出真正有意义的告警。
@@ -15,4 +14,214 @@ draft: true
 
 ## 背景
 
-TODO
+我们团队监测客户当前安全状况的重要手段之一就是监控安全告警。安全告警由各类云安全产品产生，而产品设计时需在漏报率与误报率之间权衡。阿里云安全产品偏向于降低漏报率，因此会存在比较高的误报率，所以我们团队需要对告警进行进一步过滤，避免重要告警被噪声淹没。
+
+团队当前服务 60+ 客户、140+ UID，监控的告警数据源来自 \[数据删除\]。8-9 月期间平均每周产生有效告警 2500+ 条。
+
+## 过滤机制
+
+为尽可能降低误报告警数，团队采用了以下多种告警过滤机制。需要注意**下面的过滤告警数比实际应过滤告警数要少**，因为交付同学在配置过滤前需要先发现大量告警产生，随后与客户确认，才能进行配置。
+
+### 客户侧加白
+
+对于客户确认属于内部操作或无需关注的告警，如果云安全产品控制台支持配置合理的规则以精准地过滤掉这些告警，那么交付同学会引导客户配置加白规则。由于云安全产品加白操作较复杂且条件较严苛，**实际能使用此方法的客户较少**（相关问题已反馈产品，产品迭代中）。**注意此类告警不属于有效告警。**
+
+#### 案例
+
+例：11 月至今，\[数据删除\] 共计产生告警 1800 条，其中 776 条告警（以恶意 DNS 请求拦截为主）因客户侧加白被过滤。
+
+#### 效果
+
+11 月至今（截止至 12-21 00:00，下同），客户侧加白机制过滤的告警共计 907 条，平均每周过滤 130 条告警。
+
+### SOC 平台加白 \[即将废弃\]
+
+对于客户确认属于内部操作或无需关注的告警，如果难以在云安全产品控制台上加白，那么交付同学通常会在 SOC 平台上配置相关加白规则。该过滤机制**过往使用较多**，过往配置的规则仍然生效，但不建议再继续添加新规则，后续将使用告警抑制替代该机制。**注意此类告警不属于有效告警。**
+
+废弃原因：SOC 平台加白粒度较粗，只能选择某一类告警，针对指定的客户不再推送，无法根据告警详情不同选择不同策略。
+
+#### 案例
+
+例：11 月至今，\[数据删除\] 共计产生告警 1765 条，其中 1734 条告警（以不可信程序启动为主）因 SOC 平台加白被过滤。
+
+#### 效果
+
+11 月至今，SOC 平台加白机制过滤的告警共计 4564 条，平均每周过滤 652 条告警。
+
+### 重复告警限流
+
+对于告警 ID 相同且重复产生的告警，在短时间内大量重复推送不仅没有意义，还容易淹没其中的其他重要告警。云安全中心会将同一告警 ID 的告警进行合并，第二次及之后触发时仅仅会更新最新发生时间。因此，我们团队采用类似的机制，限制在 1 小时内同一告警 ID 的告警最多推送 1 次。
+
+需要注意的是，两个告警的告警 ID 相同当且仅当两个告警的所有字段均相同，例如进程路径、进程命令行、IP、域名、资产 ID、文件路径、容器 ID 等等。因此，不会产生同类型的恶意操作涉及的对象不同而导致漏掉告警的情况。
+
+#### 案例
+
+下面的两个例子说明了重复告警限流的两个主要应用场景：
+
+**例 1**：客户内部人员执行一系列高危操作，其中存在部分被拦截，假设时间线如下：
+
+```
+09:00 高危操作 A [已拦截]
+09:01 高危操作 A [已拦截]
+09:02 高危操作 A [已拦截]
+09:03 高危操作 A [已拦截]
+...
+09:30 高危操作 B
+09:35 高危操作 C
+...
+09:59 高危操作 A [已拦截]
+10:01 高危操作 A [已拦截]
+10:02 高危操作 A [已拦截]
+...
+```
+
+如果缺少重复告警限流机制，则会在群内推送：
+
+```
+09:00
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+
+09:01
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+
+09:02
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+
+09:03
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+...
+09:30
+告警机器人：高危操作 B
+告警 B 详情，占据约一屏的长度
+
+09:35
+告警机器人：高危操作 C
+告警 C 详情，占据约一屏的长度
+...
+09:59
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+
+10:01
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+
+10:02
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+...
+```
+
+可以看到，对本次内部高危操作的回溯复盘将会变得冗长而困难，需要经过多个重复的 A 告警详情信息，且容易遗漏中间的 B、C 告警。
+
+使用重复告警限流机制时，会在群内推送：
+
+```
+09:00
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+
+09:30
+告警机器人：高危操作 B
+告警 B 详情，占据约一屏的长度
+
+09:35
+告警机器人：高危操作 C
+告警 C 详情，占据约一屏的长度
+
+10:01
+告警机器人：高危操作 A [已拦截]
+告警 A 详情，占据约一屏的长度
+...
+```
+
+整个告警时间线较为清晰。
+
+**例 2**：在真实攻击事件中，如果没有重复告警限流，攻击者可以利用无效告警来淹没真正的高危告警（例如通过定时任务/脚本不断触发低危告警），如下：
+
+```
+09:00 低危操作 A [已拦截]
+09:01 低危操作 A [已拦截]
+09:02 低危操作 A [已拦截]
+09:03 低危操作 A [已拦截]
+...
+09:30 高危攻击行为 B
+09:35 高危攻击行为 C
+...
+09:59 低危操作 A [已拦截]
+10:01 低危操作 A [已拦截]
+10:02 低危操作 A [已拦截]
+...
+```
+
+#### 效果
+
+该过滤机制主要目的为减少无意义重复告警，而非削减告警数、降低误报等，暂无相关统计数据说明其过滤的告警数。
+
+### 告警抑制
+
+作为当前团队的主要告警过滤机制，告警抑制可以视作 SOC 平台加白功能的增强版，使用场景与前者一致，但能提供更为精细的规则配置，例如可以根据告警详情不同的同一类告警，配置不同的推送规则。
+
+告警抑制规则由五部分组成：告警详情字段、匹配方式、匹配条件、资产范围、抑制类型。告警详情字段取自该告警类型的所有主要字段，例如 ECS 在非常用地登录告警可以选择登录时间、登录账号、登录协议、登录源 IP、登录端口、登录地六个字段。匹配方式固定为包含、不包含、正则匹配、等于、不等于、IP 段内六种方式，可以覆盖绝大部分需要告警抑制的情况。
+
+匹配条件由告警交付同学填写，匹配条件结合匹配方式可以实现非常多样化和细粒度的规则，两者的质量决定了告警抑制的效果。资产范围可以选择应用到当前资产或是全部资产。抑制类型分为临时抑制和长期抑制两种，临时抑制仅会在指定的时间范围内生效，主要用于客户临时进行内部测试的场景。
+
+#### 案例
+
+\[数据删除\]
+
+#### 常见的被抑制告警
+
+\[数据删除\]
+
+#### 效果
+
+11 月至今，去除测试账号/无效账号后总告警量 10691 条，去除自动加白类告警后总有效告警量 5214 条，告警抑制机制过滤的告警共计 2301 条，告警抑制率为 44.1%，平均每周过滤 329 条告警。
+
+由于配置抑制前需要交付同学先观察到大量重复无效告警产生，实际抑制率应能达到 **50% 以上**。例如，\[数据删除\] 账号由于客户内部扫描产生了上千条恶意 DNS 请求拦截告警，随后交付同学才配置了告警抑制，因此窗口期内的告警被标记为“处理完成”状态而非“告警抑制”状态。
+
+### AI 告警处置
+
+此外，团队还借助大模型能力，对云安全中心告警进行分类处理，并对告警风险等级进行判断和分流。目前根据分析对象的不同，将所有告警划分为以下四类：
+
+- 可疑命令行为：主要分析对象为告警中的恶意命令信息
+- 攻击 IP 分析：主要分析对象为告警中的 IP 信息
+- 恶意文件分析：主要分析对象为告警中的文件信息
+- 其他类型分析：所有告警详情中不存在命令、IP、文件的告警会划入此类，此时的分析对象为整个告警详情
+
+针对每种类别的告警，由大模型分析告警上下文信息并给出一个风险分数，分数所在区间决定了该告警的风险等级。风险等级目前分为五级：
+
+- “紧急”：这类告警有很大概率是真实攻击事件，需要升级为应急响应事件
+- “高危”：这类告警存在真实攻击事件的可能性，风险相对较高，需要尽快分析并与客户确认
+- “中危”：这类告警较难判断是否属于攻击事件，存在一定风险，需要与客户确认
+- “低危”：这类告警基本不存在属于攻击事件的可能，风险很低，无需与客户确认
+- “误报”：这类告警可以确定属于产品误报，无需关注，可以视情况反馈至产品
+
+在判断风险时，团队根据日常告警处置经验，会向大模型输入一些预定义的策略，例如：
+
+\[数据删除\]
+
+而对于历史已经出现过的并被加白的告警，显然没有必要再耗费精力去分析，因此设置了如下规则：
+
+> 如果当前告警中包含的信息和该类告警的历史处置加白记录里的情况相匹配，则不需要再考虑其他任何情况，alarms_level 直接标记误报
+
+后续计划将 AI 判定为“低危”与“误报”等级的告警自动闭环，以进一步降低告警总量。
+
+## 结果
+
+11 月至今告警各项数据：
+
+- 应用重复告警限流，并去除测试账号/无效账号后总告警量 10691 条
+- 无效告警 5477 条，占总告警量 51.2%
+  - 客户侧加白告警 907 条，占总告警量 8.5%
+  - SOC 平台加白告警 4564 条，占总告警量 42.7%
+  - 其他无效告警 6 条，SOC 平台历史遗留状态导致
+- 有效告警 5214 条，占总告警量 48.8%
+  - 处理完成状态告警 2913 条，占有效告警量 55.9%
+  - 告警抑制状态告警 2301 条，占有效告警量 44.1%
+
+目前每周平均有效告警 200-400 条，抑制告警率达到 40% 以上。非抑制告警中，超过 30% 的告警可直接参考 AI 告警分析完成闭环。
diff --git a/content/posts/selfhosting/index.md b/content/posts/selfhosting/index.md
index f02a720e1..6491c27c7 100644
--- a/content/posts/selfhosting/index.md
+++ b/content/posts/selfhosting/index.md
@@ -1479,6 +1479,10 @@ networks:
 
 根据 [官方文档](https://containrrr.dev/watchtower/arguments/#time_zone) 中的说明，我们可以挂载 `/etc/localtime` 来同步时区。
 
+### 已知问题
+
+自动升级的潜在风险就是：服务如果被升级到一个带有 Breaking Changes 的版本就会挂，这时只能手动去根据 Breaking Changes 的说明去调整配置再重新创建和启动容器。
+
 ### 备份
 
 - 在 `compose` 备份中完成