Splunk Enterprise Certified Architect 是 Splunk shop 里高级架构师的官方盖章，唯一认可"能拍板 indexer/search head 集群方案"的证书 — 但不做 Splunk 自管部署的公司考了等于白考。
这张认证到底考什么
先把考试形式、适合人群、备考时长和学习范围讲清楚，再决定要不要投入时间。
Splunk Enterprise Certified Architect（SPLK-2002）是 Splunk 认证体系顶端的架构级证书，定位是"能为大型 Splunk Enterprise 部署做容量规划、集群拓扑设计、性能调优"的高级工程师。和 SPLK-1003（Admin，日常运维）不同，2002 考的不是"怎么改 inputs.conf"，而是"10 TB/day、100 个 forwarder、SLA 要求 RPO < 5 分钟时应该用多少 indexer、RF/SF 定多少、search head 要不要 clustering、license 怎么分配"这类方案设计题。
硬性前置：必须先通过 SPLK-1003（Admin）才能报考 SPLK-2002，这是 Splunk 官方在 schedule 系统里强制检查的规则，不是建议。如果你连 1003 都没过，Pearson VUE 直接拒绝约考。考试形式：85 道题，90 分钟，70% 通过，费用 130 USD（Pearson VUE，可线上监考），有效期 3 年。题目以场景题为主，一道题经常给你一段 300 字的部署现状描述，让你选最合适的架构调整方案。
考点核心 5 大领域：(1) 容量规划（Indexer sizing — CPU cores × 100GB/day/core 经验公式，磁盘 IOPS 要求 800+ random read/write，memory 12 GB base + 300 MB/concurrent search）；(2) Indexer Cluster 设计（Replication Factor、Search Factor、Multisite Cluster 的 site_replication_factor 和 site_search_factor，Cluster Master 故障切换）；(3) Search Head Cluster（captain 选举、KV Store replication、deployer 和 cluster 的区别、SHC 最少 3 节点原因）；(4) Distributed Search & Forwarder 架构（intermediate forwarder、load balancing、indexer discovery 通过 cluster master 自动发现 peer）；(5) 性能调优与监控（Monitoring Console、DMC 配置、bucket rolling 瓶颈排查、search concurrency limits）。
Cisco 在 2024 年完成 280 亿美元收购 Splunk 后，大型企业客户（四大行、电信、国防、政府）的自管 Splunk Enterprise 部署继续扩容，而不是迁 SaaS — 这些客户的合规和数据主权要求决定了他们未来 3-5 年内不可能搬到 Splunk Cloud。这意味着 SPLK-2002 对大型 Splunk 合作伙伴（Partner）和企业内部 Splunk Platform Team的架构师仍然是硬通货。但 Cisco 本身在主推 Splunk Cloud + Cisco XDR，新客户走 SaaS 的比例越来越高，纯自管架构师的岗位长期会收缩。
一句话：你做大型 Splunk Enterprise 自管部署的架构设计工作 — 考；在 Splunk Partner 做交付方案 — 考；其他所有场景 — 别浪费 130 美元。
你会反复碰到的核心服务
学完以后你能带走什么
- 掌握 Splunk 企业级分布式架构的核心设计原则
- 能够规划和实施大规模索引器集群与搜索头集群
- 熟练配置多站点集群和灾难恢复方案
- 自信通过 Splunk Enterprise Certified Architect（SPLK-2002）认证考试
考试详情
适合谁考
适合人群
- 负责大规模 Splunk 分布式环境设计与部署的架构师
- 拥有 2-3 年 Splunk 管理经验、希望晋升为架构师的高级工程师
- 已持有 SPLK-1003（Splunk Enterprise Certified Admin）并寻求进阶认证的专业人员
- 负责 Splunk 基础设施规划与容量管理的 IT 运维专家
开始前最好先有
- 强烈建议持有 Splunk Core Certified Power User（SPLK-1002）或 Splunk Enterprise Certified Admin（SPLK-1003）
- 至少 2-3 年 Splunk 实际部署和管理经验
- 深入了解 Linux 系统管理和网络架构
- 熟悉 Splunk 配置文件体系（inputs.conf、outputs.conf、indexes.conf 等）
值不值得考？职业价值
Splunk SPLK-2002 持证人的薪资区间、对应岗位、以及真实的职业影响。
Splunk Architect 是 Observability 赛道里最稀缺的角色之一
在美国和澳洲市场，能独立做 "10 TB/day、multisite cluster、跨 region DR" 级别 Splunk 架构方案的人非常少。原因很简单：这个技能需要同时懂 Splunk 内部机制（bucket lifecycle、replication 算法）+ Linux 存储（NVMe IOPS、ZFS/XFS 选型）+ 分布式系统理论（CAP、quorum、split-brain）。市场上有 Splunk 证书的工程师不少，但能做架构级决策的人凤毛麟角。LinkedIn 上搜 "Splunk Architect" 的美国岗位中位 base 在 170-200k USD，大型 Partner（Accenture Federal、Deloitte、Kyndryl）的 Principal Splunk Consultant 可以到 230k+ base。澳洲四大行和 DXC、Kyndryl 的 Splunk Architect 岗位普遍在 170-200k AUD base。
谁最该考
- Splunk Partner 公司的 Pre-Sales / Solution Architect：Splunk Partner Program 对 Partner Tier（Registered/Silver/Gold/Platinum）有明确的 Certified Architect 数量要求 — 比如 Gold Partner 要求至少 4 名 Architect。挂证 + 实施收入是 Partner 生意模式的基础，公司通常会报销考试费 + 发 1000-3000 USD 的 bonus。
- 已经做 2-3 年 Splunk Admin 想升架构师的工程师：2002 是从 "执行者" 变成 "拍板人" 的那道门槛证。没过 2002 的 Splunk Admin 永远只能做 ticket，过了 2002 才能参与 design review 和客户方案会议。
- 大型企业内部 Splunk Platform Team 的 Lead：银行/电信/国防这类有 50+ indexer 集群的企业，Platform Lead 做容量规划和扩容方案时需要 2002 级别的知识，否则容易做错方案导致集群性能塌方。
谁不应该考
- 公司只用 Splunk Cloud：SaaS 环境里 indexer cluster、SHC、capacity planning 都是 Splunk 内部托管的，用户碰不到这些配置。2002 的 80% 知识在 Splunk Cloud 里用不到。
- SOC 分析师 / Threat Hunter：你要的是 SPLK-1002 + SPLK-1004，2002 的容量规划、集群设计和你日常的威胁狩猎工作毫无关系。
- 没做过生产环境 Splunk 运维的纯小白：2002 考的是场景判断题，不是背概念题。没有实际运维过 indexer cluster 和 search head cluster 的人，看到题目里 "RF=3, SF=2, 3 indexer 挂 1 台会怎样" 这种问题会完全没感觉。先做 1-2 年 Admin 再来考。
- 不做 Splunk 生态的公司：Splunk 的 bucket 架构、replication 算法、SHC 设计和其他 SIEM（QRadar/Sentinel/Elastic）完全不通用，架构知识不能迁移。
Cisco 收购后的趋势观察：2024-2025 年 Cisco 把部分 Splunk Professional Services 并入 Cisco Customer Experience（CX）组织，这部分 Splunk Architect 的薪资体系向 Cisco 高级工程师靠拢，普遍涨 5-10%。另一方面 Cisco 在主推 "Full-Stack Observability" 战略，未来 Splunk Architect 如果同时懂 Cisco AppDynamics + ThousandEyes + Splunk 的集成设计，会比纯 Splunk 背景的人值钱一档。但短期内纯 Splunk Enterprise 自管架构师的需求没有明显下滑。
备考节奏
有 AWS 实操经验
零基础切入
建议日投入
学习路径预览
3 章分阶段备考路径
过来人总结的分阶段备考节奏，按周拆分，不是空话。
第一阶段：确认 SPLK-1003 已过 + 读完《Splunk Validated Architectures》白皮书（1 周）
1003 是硬性前置，没过的话 Pearson VUE 约考直接被拒。第一件事下载并精读 Splunk 官方的《Splunk Validated Architectures》（简称 SVA）白皮书 — 这是 2002 考试最重要的单一资料，考试至少 15-20 道题直接来自这份文档里的 9 种参考架构（S1/S2/M1/M2/M3/M4/L1/L2/L3，按数据量和 HA 要求分层）。SVA 里明确列出每种架构对应的 "单日数据量区间 + indexer 数量 + search head 数量 + 是否需要 clustering + RF/SF 推荐值"，这些是考试场景题判断 "应该推荐哪种架构" 的依据。看完 SVA 做一个自己的速查表，把 9 种架构画在一张 A4 纸上，考前一小时复习一遍。
第二阶段：刷 Architecting Splunk Enterprise Deployments + Troubleshooting Splunk Enterprise 两门官方课（3-4 周）
这两门课是 Splunk 官方唯一对应 2002 考纲的培训，每门约 12-16 小时。Architecting 课重点：容量规划公式（reference hardware、indexer sizing、search head sizing、forwarder throughput）、multisite indexer cluster 的 site_replication_factor 写法（比如 "origin:2, total:3" 的意思）、search head cluster 的 captain 选举算法（Raft）、KV Store replication、deployer 和 cluster 的职责边界。Troubleshooting 课重点：Monitoring Console（MC）的配置和使用、DMC alerts、常见性能瓶颈模式（skipped searches、bucket rolling stall、replication queue 堵塞）、`splunk diag` 命令收集诊断包的方法。这两门课的实验很重要，必须在自己的实验环境里跑一遍，尤其是 multisite cluster 的搭建 — 考试至少 5-6 道题和 multisite 相关。
第三阶段：搭建 multisite indexer cluster + search head cluster 实验环境（2-3 周）
这是 2002 备考最关键的动手环节。最低配置：6 台 Linux VM（每台 4-8 GB 内存）。拓扑：Site1 = 3 indexer + 1 SHC member + 1 cluster master；Site2 = 2 indexer + 2 SHC member + 1 SHC deployer。配 site_replication_factor = "origin:2, total:3"，site_search_factor = "origin:1, total:2"，启动后用 `splunk show cluster-bundle-status` 和 `splunk show shcluster-status` 观察状态。然后故意做破坏性实验：(1) 停掉 Site1 的 cluster master，观察 indexer 是否还能 replicate；(2) 停掉 SHC captain，看新 captain 选举过程；(3) 模拟磁盘满，观察 bucket rolling 行为；(4) 跑一个高并发搜索，观察 Monitoring Console 里的 search scheduler skipped searches 指标。每种破坏性场景做完都记录一次现象 — 考试里 60% 的场景题就是在问这些故障模式该怎么处理。
第四阶段：容量规划公式 + 故障场景题密集训练（2-3 周）
容量规划必须背下来的公式和数字：(1) Indexer sizing — "reference hardware" 为 12 CPU cores、12 GB RAM、800 IOPS，单台 indexer 在 reference hardware 下可处理 ~300 GB/day indexing + 少量 search 负载；(2) Search Head sizing — 16 cores 能支持 ~25 concurrent searches，每个搜索平均消耗 300 MB 内存；(3) Forwarder throughput — Universal Forwarder 在默认 maxKBps 下限速 256 KB/s，生产环境应该改成 0（无限制）；(4) License volume 按 indexed volume 计算（不是 raw data），压缩比约 50%。故障场景题必练类型：RF=3/SF=2 的 3 节点 cluster 挂一台会怎样（仍可搜索、仍可 replicate，但无法维持 RF 所以会 fix-up）；RF=3/SF=2 的 3 节点 cluster 挂两台会怎样（部分 bucket 不可搜索，cluster 进入 degraded）；multisite cluster 整个 site 断网时 cluster master 如何处理（site_mappings 决定故障行为）。
第五阶段：模考 + 错题本 + SVA 速查表最后一遍（1 周）
最后一周每天一套模考。JR Academy 题库 + Splunk 官方 sample test 各刷 2 遍。错题重点回顾的题型：(1) "给你现状 X TB/day，用户要求 Y 天 retention + Z 小时 RPO，应该选哪种架构" — 答案永远看 SVA 分层；(2) "现有集群 skipped searches 过高怎么办" — 优先考虑加 search head 而不是加 indexer；(3) "bucket rolling 慢怎么排查" — 查 IOPS 而不是 CPU；(4) "deployer 和 cluster master 能不能放一台" — 可以但生产环境不推荐；(5) "SHC 最少几个节点" — 3 个（Raft quorum 要求）。考前一晚把 SVA 的 9 种架构速查表再过一遍，考试稳定 78-80% 以上再约考试。
通过者的真实经验
过来人的备考时长、分数、以及踩过的坑。
我之前做了 3 年 Splunk Admin，2002 是从 Admin 升架构师的必考证。考试比 1003 难一个量级 — 题目都是大段场景描述，没有 "定义题"。最重要的备考资料是 Splunk Validated Architectures 白皮书，我打印出来放在床头每晚翻。考试里至少 20 道题是在问 "给定数据量和 HA 要求，从 SVA 的 9 种架构里选一个" — 你必须把 S1/S2/M1/M4/L3 这些编号和对应的 indexer 数量背熟。另外 multisite cluster 的 site_replication_factor 写法 "origin:2, total:3" 这种语法一定要动手配过一次，看文档记不住。
我负责一个 18 节点 indexer cluster + 4 节点 SHC 的生产环境，以为日常运维就够了，结果考试差点挂。最大的坑是 SHC captain 选举 — 考试里至少 3 道题深入问 captain 失联时的行为（dynamic captain 会重新选举，static captain 配置不能再用需要手动干预）。另一个重灾区是 KV Store — 我之前从来没关注过 KV Store 的 replication 机制，结果考试有 4-5 道 KV Store 题，包括 `mongod` 进程崩溃怎么处理、KV Store 和 indexer cluster 的关系（KV Store 只存在于 search head，不复制到 indexer）。建议备考时一定要把 Splunk docs 里 "About the captain" 和 "KV Store troubleshooting" 两页读透。
我做 Splunk 实施 5 年，2002 算是日常工作的总结。最容易错的题不是技术题而是 "方案推荐题" — 比如 "客户现状 2 TB/day、3 年 retention、要求 99.9% 可用性，推荐哪种架构"，这种题必须严格按 SVA 白皮书的分层逻辑答，不能按自己的经验拍。我一开始凭经验答错了好几道。另一个坑是 license master 的架构题 — license master 本身不是 HA 组件（它挂了 72 小时内 indexer 继续工作，超过 72 小时 search 被禁用），所以 license master 不需要配 cluster。考试会给你一个 "license master 挂了怎么办" 的场景，正确答案不是 "搭 HA license master"（Splunk 不支持），而是 "恢复 license master 服务"。
同赛道认证对比
| Splunk SPLK-2002 | Splunk SPLK-1001 | Splunk SPLK-1002 | |
|---|---|---|---|
| 机构 | 其他 | 其他 | 其他 |
| 级别 | 助理级 | 助理级 | 助理级 |
| 考试费 | $0 | $0 | $0 |
| 时长 | 90 min | 90 min | 90 min |
| 题量 | 65 | 65 | 65 |
| 有效期 | 3 年 | 3 年 | 3 年 |
备考技巧与常见失误
**85 题 / 90 分钟，平均 63 秒一题** — 但场景题本身很长（经常 200-300 字背景描述），时间其实相当紧。看到长题目先跳过细节读问题本身，带着问题回头扫背景找关键数据点（数据量、节点数、RF/SF、延迟要求）。
**Splunk Validated Architectures 白皮书是最重要的单一资料** — 至少 15-20 道题直接对应 SVA 的 9 种参考架构（S1/S2/M1-M4/L1-L3）。考前必须能 30 秒内说出每种架构对应的数据量区间和节点数。
**容量规划题先算数据量，再选架构** — 看到 "客户 X TB/day、Y 年 retention、Z 并发搜索" 这类题，先算总存储（TB/day × 365 × years × 0.5 压缩比），然后按 SVA 表格选架构层级，永远不要凭直觉。
**RF/SF 相关题目记住硬约束 SF <= RF** — 任何 SF > RF 的配置都是非法的，cluster master 不会启动。Multisite 场景用 site_replication_factor 语法（origin/total）。
**故障场景题优先排查磁盘 IOPS** — Indexer 性能问题 80% 是 IOPS 瓶颈，不是 CPU/内存。看到 "搜索慢、CPU 30%、内存充足" 的场景，答案永远是 IOPS。
**三个角色别搞混：Deployment Server / SHC Deployer / Cluster Master** — 分别管 Forwarder、SHC members、Indexer peers。任何 "用 Deployment Server 管 Cluster peer" 的选项都是错的。
**License Master 不是 HA 组件** — 挂 72 小时内不影响 indexing，超过 72 小时 search 被禁用但 indexing 继续。Splunk 不支持 License Master cluster。
**费用和约考**：130 USD（Pearson VUE 线上监考或线下考点）。必须**先过 SPLK-1003** 才能 schedule 2002，系统强制检查。挂了 7 天内不能重考，重考全价。考完立即出结果（Pass/Fail + 各 domain 百分比）。
**混淆 Indexer Cluster 的 Replication Factor 和 Search Factor** — Replication Factor（RF）= 数据在 cluster 里保留多少份副本，Search Factor（SF）= 这些副本里有多少份是 "searchable"（即 index 文件完整，可以被搜索）。**硬约束 SF <= RF**。默认 RF=3, SF=2 表示每份数据存 3 份副本，其中 2 份是 searchable、1 份只是 raw data（需要时会被重建为 searchable）。考题陷阱：(1) 配置 RF=2, SF=3 是**非法**的，cluster master 会拒绝启动；(2) RF=3 的 3 节点 cluster 挂 1 台还能继续 indexing 吗？能 —— 但不能再维持 RF，进入 fix-up 状态；(3) Multisite cluster 里 RF/SF 要用 site_replication_factor 和 site_search_factor 语法（如 "origin:2, total:3"），不能用单数字。
**Search Head Cluster 的 captain 选举机制理解错误** — SHC 用 Raft 算法选举 captain，**最少需要 3 个节点**（Raft quorum = (N/2) + 1，2 节点无法容错）。只有 captain 能做 artifact 管理和 scheduled search 调度，member 只负责处理用户搜索。常见错误：(1) 以为 2 节点 SHC 可以跑 —— 不行，Raft 要求多数派投票；(2) 以为可以手动指定哪个节点是 captain —— 只有 static captain 模式可以，但 static captain 挂了集群无法自动恢复，生产环境**绝不使用**；(3) 以为 deployer 是 SHC 的一员 —— **不是**，deployer 是独立节点，负责给 SHC 推送 app 和配置，不参与 captain 选举，也不处理搜索。
**搞混 Deployment Server 和 SHC Deployer 和 Cluster Master 三个角色** — 这三个都是 "推送配置的东西" 但管的对象完全不同：(1) **Deployment Server** 通过 serverclass.conf 给 Universal Forwarder / Heavy Forwarder / 独立 Splunk 实例推送 deployment app；(2) **SHC Deployer** 专门给 Search Head Cluster 的 members 推送 SHC app bundle（通过 `splunk apply shcluster-bundle` 命令）；(3) **Cluster Master**（Indexer Cluster Manager）给 Indexer Cluster 的 peer nodes 推送 indexer cluster bundle（通过 `splunk apply cluster-bundle`）。**绝对禁止**的组合：用 Deployment Server 管 SHC members 或 Indexer Cluster peers —— 配置文件冲突会导致 SHC / cluster 进入异常状态。考试经常出 "以下哪种配置推送方式是错误的" 这类题，答案永远是 "用 Deployment Server 管理 Cluster peer"。
**License Master 的架构角色和故障影响判断错误** — License Master（在 Splunk 9.x 改名为 License Manager）**不是 HA 组件** —— Splunk 官方明确不支持 License Master 集群。License Master 挂了之后，license slave（其他所有 Splunk 实例）仍然可以继续 indexing 数据 **72 小时**，这段时间内没有任何影响；超过 72 小时后，search 功能会被禁用，但 indexing **继续工作不会丢数据**。考题陷阱：(1) 以为 License Master 挂了数据会丢失 —— 错，indexing 继续；(2) 以为应该配 License Master HA —— 错，官方不支持；(3) 以为 License Master 应该和 Cluster Master 分开 —— 对的，生产环境推荐分开部署避免单点压力。正确处理方式是给 License Master 做 VM snapshot 和备份 license 文件，挂了快速恢复即可。
**KV Store 的 replication 机制和故障处理不清楚** — KV Store 是 Splunk 内置的 MongoDB（`mongod` 进程），**只运行在 Search Head**（standalone SH 或 SHC members），**不**存在于 Indexer 或 Forwarder 上。在 SHC 环境里，KV Store 数据会自动在 SHC members 之间 replicate，replication 由 SHC captain 协调。常见错误：(1) 以为 KV Store 数据会复制到 indexer —— 错，indexer 上没有 `mongod`；(2) 以为 indexer cluster 的 RF/SF 控制 KV Store —— 错，KV Store 有自己独立的 replication 机制；(3) `mongod` 进程崩溃后以为要手动 restore —— SHC 环境下会从其他 member 自动同步，standalone SH 则需要从备份恢复。考试会问 "SHC 里一个 member 的 KV Store 损坏怎么处理"，答案是用 `splunk clean kvstore --local` 然后 restart，让它从 captain 重新同步。
**容量规划时忽略 IOPS 要求，只看 CPU 和内存** — Splunk 官方 reference hardware 明确要求 indexer 磁盘的 **800+ IOPS**（random read + write），这是 bucket 写入和搜索的瓶颈。新手最常犯的错是用大容量低速 SATA HDD（100 IOPS）做 indexer 存储，结果数据量稍微一大就出现 bucket rolling 停滞、search 大量 skipped。考题会给你一个 "indexer CPU 使用率只有 30%、内存充足，但搜索延迟严重" 的场景，正确答案永远是 "检查磁盘 IOPS / 升级到 NVMe SSD"，而不是 "加 CPU" 或 "加内存"。容量规划公式：单 indexer 处理能力约等于 `min(CPU_cores × 25 GB/day, disk_IOPS / 3)` — 磁盘经常是瓶颈。
**Multisite Cluster 的 site affinity 和 search affinity 概念错位** — Multisite cluster 有两个关键配置：(1) `site_replication_factor` 控制数据在不同 site 的副本分布（如 "origin:2, total:3" 表示原始 site 保留 2 份、全 cluster 共 3 份）；(2) `site_search_factor` 控制哪些 site 有 searchable copy。**search affinity** 让 search head 优先从本 site 的 indexer 搜索数据（减少跨 site 网络流量），在 `server.conf` 里用 `[clustering]` stanza 的 `multisite = true` 启用。常见错误：(1) 以为 multisite = 双活数据中心 —— 实际上 multisite 主要目的是 DR 和 search affinity，不等于 active-active；(2) 配错 site_replication_factor 导致某个 site 故障时数据不可用 —— 比如 "origin:3, total:3" 在 origin site 挂了之后其他 site 没有副本。
**Monitoring Console（MC）的部署模式选错** — Monitoring Console 是 Splunk 内置的监控工具，有两种部署模式：(1) **Standalone MC** —— MC 作为独立 Splunk 实例或共用 search head 角色，用于小型部署；(2) **Distributed MC** —— MC 作为专门的 search head 连接所有 indexer 和 search head 作为 search peer，用于大型 cluster 部署。常见错误：(1) 把 MC 配在 Cluster Master 上 —— Splunk 官方**不推荐**，因为 Cluster Master 本身负载高；(2) 把 MC 配在 SHC member 上 —— MC 不能运行在 SHC member 上，会导致 SHC 配置冲突；(3) 忘记在 MC 上做 "General Setup" 给各节点分配角色标签（Indexer / Search Head / License Master），导致 dashboard 不显示数据。