{#section path-to-node="2"}
"在运维圈，最值钱的不是你会用多少工具，而是你处理'生产灾难'时的底层逻辑。"过去一年，我面试了 150 多位 DevOps 候选人。我发现一个扎心的事实：90% 的人只是"高级工具搬运工"。问起 Prometheus，滔滔不绝；问到数据流如何闭环、SLA 如何量化、安全权限如何穿透，大多人瞬间哑火。这种"认知断层"，就是你年薪 20W 和 50W 之间的真实鸿沟。2026 年，面试官已经不再关心你是否会用工具，他们关心的是：你是否理解生产系统的每一个呼吸。
今天，我们把这 10 个足以定生死的面试真题公开，带你拆解什么是真正的"架构师思维"。
Q1：请梳理一下你目前的日志架构。你是如何在 K8s 环境中收集和存储日志的？
💡 资深回答："我们采用Sidecar 模式。主容器将日志写入共享卷，Fluentd Sidecar 读取并转发至 CloudWatch。随后通过 Kinesis Firehose 流向 OpenSearch 实现秒级检索。存储策略：OpenSearch 保留 7 天热数据，CloudWatch 保留 30 天，最后全部归档至 S3 以满足合规审计。"
面试官点评：优秀回答必须包含完整数据流（Data Flow）。不仅仅是堆砌工具，而是清楚每个组件的定位及数据生命周期管理。
Q2：既然用了 OpenSearch，为什么不直接全存在 CloudWatch 里？
💡 资深回答："这是对查询性能与成本的权衡。CloudWatch 在处理 PB 级数据查询时不仅慢，而且昂贵。OpenSearch 专为大规模分布式搜索设计。小规模应用 CloudWatch 够用，但规模化生产环境必须依靠 OpenSearch 实现实时分析。"
红线警示：千万别说"因为大家都这么用"，这会暴露你缺乏自主决策能力。
Q3：日志（Logs）和指标（Metrics）的区别是什么？你会分别在什么场景下使用？
💡 资深回答：
-
指标（Metrics）：像健康监护仪，告诉你运行得怎么样（如 CPU 80%、延迟 250ms）。它告诉你"哪里着火了"。
-
日志（Logs）：像调查日记，记录发生了什么（如特定用户登录失败、DB 报错）。它告诉你"火是怎么烧起来的"。
架构思维：监控告诉你系统生病了，日志帮你完成临床诊断。
Q4：Prometheus 和 Grafana 有什么区别？为什么需要同时使用？
💡 资深回答：Prometheus 是数据采集和临时存储引擎，通常保留 15-30 天；Grafana 是纯粹的可视化展示层。避坑指南：很多人不知道 Prometheus 不适合长期存储。在生产级架构中，我们通常需要引入Thanos或Cortex来实现历史数据的长期回溯。
Q5：SLA 承诺 99.5% 的可用性，这对应多少停机时间？
💡 资深回答："每月 30 天，99.5% 的可用性意味着允许的停机上限是3.6 小时。我们会将这个技术指标实时展示在看板上，供业务方监控。"
面试官点评：这考查的是你是否具备业务视角。不懂业务价值的 DevOps 永远无法触及核心架构。
Q6：Grafana 如何安全地获取云端数据？
💡 资深回答："禁止使用硬编码 Access Keys！我们通过OIDC将 IAM Role 映射到 Grafana Pod 的Service Account。Pod 自动获取临时凭证，整个链路不落任何明文密钥。"
Q7：Prometheus 抓取间隔（Scrape Interval）设多少合适？
💡 资深回答："通常是15-30 秒。设为 5 秒会导致系统负载过高，产生大量监控噪音。高级玩家会告诉你，他曾经通过合理调优 ServiceMonitor，在监控精度与系统负载之间找到了平衡。"
Q8：Datadog vs Prometheus + Grafana，你怎么选？
💡 资深回答：这是一场成本与人力的较量。
-
Datadog：极致的快，全家桶体验，但账单惊人。
-
P+G：开源免费，但需要顶级团队来维护其稳定性。结论：预算充足选 Datadog 买时间；有技术沉淀选 P+G 深度定制。
Q9：为什么 Sidecar 模式是日志收集的首选？
💡 资深回答：因为它实现了日志逻辑与业务逻辑的物理隔离。我可以随时更换日志存储后端或升级收集引擎，而不需要业务开发重新打包镜像，这对于生产系统的稳定性至关重要。
Q10：微服务上线第一天，你会监控哪些核心指标？
💡 资深回答：我会优先建立RED 指标体系：
-
Rate（速率）：每秒请求数。
-
Errors（错误）：失败请求分布。
-
Duration（耗时）：响应延迟分布。更重要的是：所有的告警策略必须在上线前配置完毕，而不是出事后再补。
总结：如何逃离"工具人"陷阱？
想要拿高薪，就得停止死记硬背。面试官想看的是：
-
数据流追踪能力：你能否画出数据从应用到告警的每一个跳点？
-
决策能力：你是否知道为什么要用这个工具？
-
风险意识：你是否考虑了安全、成本和扩展性？
想要进阶更硬核的 K8s 实战技巧？
我在 B 站同名频道【LeisureLinux】准备了大量关于 Linux 底层优化、K8s 监控架构拆解的实战视频。建议刷完这篇文章的同学直接去视频区"补课"，手把手带你跳出"搬砖"循环，直击架构核心。
下一步：如果你想看文中提到的Prometheus + Thanos 长期存储的实战配置，在评论区留言"架构"，我为你安排！
你会如何回答"如果监控系统本身挂了，你该怎么办？" 欢迎在评论区分享你的高阶方案！
本文部分内容编译自 Akhilesh Mishra（"我"） 的分享
常见问题（FAQ）
Q1：这篇文章主要讲什么？ # {#section path-to-node="2"} Q2：「Q1：请梳理一下你目前的日志架构。你是如何在 K8s 环境中收集和存储日志的？ {#q1请梳理一下你目前的日志架构你是如何在-k8s-环境中收集和存储日志的 path-to-node="8"}」这部分主要讲了什么？ 💡 资深回答："我们采用Sidecar 模式。 Q3：「Q2：既然用了 OpenSearch，为什么不直接全存在 CloudWatch 里？ {#q2既然用了-opensearch为什么不直接全存在-cloudwatch-里 path-to-node="11"}」这部分主要讲了什么？ 💡 资深回答："这是对查询性能与成本的权衡。 Q4：「Q3：日志（Logs）和指标（Metrics）的区别是什么？你会分别在什么场景下使用？ {#q3日志logs和指标metrics的区别是什么你会分别在什么场景下使用 path-to-node="14"}」这部分主要讲了什么？ 💡 资深回答： Q5：「Q4：Prometheus 和 Grafana 有什么区别？为什么需要同时使用？ {#q4prometheus-和-grafana-有什么区别为什么需要同时使用 path-to-node="18"}」这部分主要讲了什么？ 💡 资深回答：Prometheus 是数据采集和临时存储引擎，通常保留 15-30 天；Grafana 是纯粹的可视化展示层。
