大数据运维 面试准备稿
大数据运维工程师| 杭州 JD 核心：CDH/Hadoop 生态运维 + HBase 集群（百台级）+ K8s 容器化大数据服务 + 自动化运维
一、自我介绍（2 分钟版）
口语化，控制在 2 分钟内，约 400 字，训练到流畅再上场。
"我在华为做了 6 年 HCS 产品技术 TD。TD 这个岗位是项目全生命周期的技术责任人——前期和 SA 一起做需求调研和方案设计，中期主导技术实施和现场落地，后期负责试运行转维，技术侧全程由我主导。累计交付了 50 多个政企云项目，覆盖政务、电力、金融等行业。
技术方向上，大数据平台是我的核心交付内容之一。华为 MRS 平台覆盖 Hadoop、HBase、Kafka、Flink、Elasticsearch 等组件，部署、调优、故障排查都有现网经验。容器平台方面，在交付阶段和驻场支持期间处理过多套 K8s 集群的 Pod 调度、存储挂载、网络等各类故障，在 K8s 上管理容器化大数据服务有完整实践。自动化运维方面，针对客户自建业务虚机用 Ansible 做批量配置管理和合规巡检，Python/Shell 写巡检和告警联动脚本，在政务云项目中落地了一套完整的自动化运维体系。
代表项目是国网浙江电力禾城外网云，我主导大数据平台 MRS 的交付与版本演进，涵盖 Hadoop/Kafka/Flink 组件调优与容量治理，平台稳定支撑 500+ 核心业务，实现生产变更零事故。
我来面试这个岗位，是因为 JD 里的核心职责——Hadoop 生态集群运维、HBase 集群管理、K8s 容器化大数据服务、自动化运维工具建设——和我过去做的事情本质上是一样的，技术栈可以直接复用，只是从交付侧转到产品侧的日常运维，我认为这正是我接下来想深耕的方向。"
三个擅长点（结尾提炼，对应 JD）：
- 大数据集群故障排查——有 HBase 热点、Kafka 积压、Flink 背压等完整案例
- 可观测体系建设——从零构建 Prometheus+ELK 监控，治理过告警风暴
- 自动化运维落地——Ansible Playbook + Python 脚本，有等保审计交付物
二、必备技能逐条准备
技能 1：HBase 集群运维（JD 核心必备）
一句话定位：在电力云和警务云项目中，负责 MRS HBase 集群的交付与运维，处理过 Region 热点、容灾 Replication 延迟、跨版本兼容等问题。
案例 A：HBase Region 热点排查与治理（电力云大数据平台，2023）
S：电力云大数据平台上线后，HBase 写入性能持续下降，监控显示某一台 Region Server 的 CPU 和磁盘 IO 持续飙高，其他节点几乎空闲，写入延迟从正常的 5ms 涨到 200ms 以上，下游 Flink 作业开始出现背压。
T：定位热点根因，在不停服的前提下恢复写入性能，同时给出长期治理方案。
A：第一步，用 HBase Web UI（Master 的 16010 端口）查看各 Region Server 的 Request Count 分布，确认写入请求 90% 以上集中在同一台 RS，热点确认。第二步，查 RowKey 设计，发现业务写入的 RowKey 是"设备ID + 时间戳"拼接，时间戳在后、设备 ID 前缀固定，导致同一设备的所有写入顺序落在同一个 Region，形成热点。第三步，短期止损：用
hbase shell手动触发热点 Region 的 split（split 'table_name', 'split_key'），把大 Region 切成多个分散到不同 RS，写入压力立即下降。第四步，长期治理：与业务团队协商改造 RowKey，在前缀加 2 位哈希盐值（取设备 ID 的 MD5 后两位），把写入打散到 16 个桶，同时做预分区（create 'table', ..., SPLITS => ['10','20',...,'f0']），避免初期数据全落在一个 Region。改造后用hbase pe --nomapred --rows=100000 sequentialWrite 10压测，各 RS 写入均匀。R：写入延迟恢复到 5ms 以内，Flink 背压消除。事后把 RowKey 设计规范（禁止单调递增前缀）列入了大数据平台上线前的数据模型审查清单。
衍生追问准备：
- 创新点：把 RowKey 设计规范前置到上线审查环节，从"出了问题再治"变成"上线前就卡住"，工程化沉淀
- 如果重做：更早介入数据模型设计评审，不等到上线后出问题再改造，改造成本高且有业务风险
- 遇到的困难：业务团队改造 RowKey 有阻力，担心影响已有数据查询。我的做法是先在测试环境跑完整的读写压测，用数据说话，同时给出双写过渡方案降低改造风险，最终推动落地
案例 B：HBase 容灾集群 Replication 延迟排查（电力云，2023）
S：电力云配置了主备两套 HBase 集群做容灾，监控告警显示 Replication lag 持续增长，备集群数据落后主集群约 30 分钟，不满足 RPO 要求。
T：定位 Replication 延迟根因，恢复正常同步，RPO 要求 5 分钟以内。
A：先用
hbase shell执行status 'replication'查看各 Peer 的同步状态，发现备集群的 Peer 状态显示AgeOfLastShippedOp持续增长，说明 WAL 日志在主集群侧已经生成，但没有及时发送到备集群。检查主集群的 ReplicationSource 线程日志（hbase-master.log），发现大量Failed to replicate报错，原因是备集群某台 Region Server 的 ZooKeeper 会话超时，导致主集群的 Replication 连接断开后没有自动重连。临时处理：重启备集群问题 RS 的 ZooKeeper 客户端连接，Replication 自动恢复。根因分析：备集群 RS 的 JVM GC 出现了 Stop-the-World 停顿（Full GC 超过 30 秒），导致 ZK 心跳超时，会话失效。调整 RS 的 JVM 参数，把 G1GC 的MaxGCPauseMillis从默认 200ms 调到 100ms，同时增大hbase.zookeeper.session.timeout（从 90000ms 调到 120000ms）给 GC 留出余量。R：Replication lag 恢复到 1 分钟以内，满足 RPO 要求。事后把 Replication lag 和 RS GC 停顿时间列入了监控告警规则。
冷热数据分层（常见追问）：
- 热数据留在 SSD 存储池，冷数据通过 HBase 的 MOB（Medium Object Block）存储大对象，或定期用
Export+distcp归档到 HDFS 冷存储目录 - 也可以用 HBase 的 TTL 机制自动过期历史数据，配合
COMPRESSION => 'SNAPPY'压缩降低存储成本
常见追问：
hbase hbck -details检查集群一致性，发现 Region 空洞或重叠- Region 分裂频繁：调大
hbase.hregion.max.filesize（默认 10GB），或提前做预分区 - RS 宕机后 Region 重新分配慢：检查
hbase.master.wait.on.regionservers.timeout参数
技能 2：Kafka 集群运维与故障排查
一句话定位：在电力云大数据平台项目中，负责 Kafka 集群的运维支持，处理过消费积压、Broker 磁盘告警、消费者重平衡等问题。
案例：Kafka 消费积压排查（电力云大数据平台，2023）
S：电力云大数据平台监控告警，某 Kafka topic 的消费 lag 持续增长，已经积压了几十万条消息，下游数据处理延迟越来越大。
T：积压消息不能丢，需要消化完；不能影响正常消费的分区；需要找到根因，防止再次发生。
A：第一步，用
kafka-consumer-groups.sh --bootstrap-server <broker>:9092 --describe --group <consumer-group>查看各分区的 lag 分布，发现 lag 集中在分区 2 和 3，其他分区正常。说明不是消费者整体能力不足，而是这两个分区对应的消费者线程出了问题。第二步，查这两个分区对应的消费者线程日志，发现同一条消息反复出现ParseException: Unexpected format at offset 500，异常被 catch 住了没有退出，也没有跳过这条消息，导致 offset 不推进，后续所有消息全部积压。第三步，修复消费逻辑：对无法解析的消息记录详细日志（含 partition/offset/消息摘要），发到死信队列（data-topic.DLQ），提交 offset 跳过，不阻塞主流程。第四步，补充监控：增加 lag 超过 10000 条且持续增长 5 分钟触发告警；同一 offset 被消费超过 3 次触发卡死预警。R：积压消息约 2 小时内消化完毕，死信队列机制上线，后续再没出现类似积压。整理成故障排查指南，后续 ISV 接入 Kafka 前必须提交消费者异常处理方案审核。
衍生追问准备：
- 创新点：引入死信队列机制，把"消费者卡死"这类问题从被动发现变成主动防御，同时把 ISV 接入规范化
- 如果重做：在 ISV 接入阶段就做消费者代码 review，把异常处理规范前置，不等到生产出问题再补
- 遇到的困难：积压期间下游业务方压力很大，要求立刻恢复。我的判断是不能直接跳过消息，因为不知道哪些消息是有效的，先定位根因再处理，最终用死信队列方案既保住了数据又恢复了消费
Kafka Broker 磁盘告警处理：
- 先用
kafka-log-dirs.sh --bootstrap-server <broker>:9092 --describe查各 topic 的日志大小分布，找出占用最大的 topic - 检查
log.retention.hours（默认 168 小时）和log.retention.bytes配置，对日志量大的 topic 单独设置更短的保留时间：kafka-configs.sh --alter --entity-type topics --entity-name <topic> --add-config retention.ms=86400000 - 紧急情况下可以手动触发日志清理：
kafka-delete-records.sh，但要确认下游消费者已经消费完
常见追问：
- Rebalance 频繁：消费者处理时间超过
max.poll.interval.ms（默认 5 分钟），减少单次max.poll.records或把耗时处理异步化 - 消息重复消费：消费者在处理完消息后、提交 offset 前崩溃，重启后从上次 offset 重新消费；用幂等消费逻辑（业务侧去重）解决
- 生产者发送失败：检查
acks配置，acks=all时需要所有 ISR 副本确认，ISR 缩减会导致发送超时
技能 3：Hadoop 生态（Hive / Spark / HDFS）运维调优
一句话定位：在电力云和政务云项目中，负责 MRS 平台 Hadoop 生态组件的交付与调优，处理过 Hive 慢查询、Spark 数据倾斜、HDFS NameNode 压力等问题。
案例 A：Hive 慢查询导致数据报表延迟（电力云，2023）
S：电力云能源大数据平台，每天凌晨跑的日报 Hive 作业，原来 30 分钟跑完，某次数据量增长后开始跑 3 小时以上，影响早上 8 点的报表准时发布。
T：定位慢查询根因，把作业时间压回 1 小时以内，不能改变业务逻辑。
A：第一步，在 Hive 的 Web UI（HiveServer2 的 10002 端口）查看作业执行计划，发现某个 JOIN 操作产生了大量 Map 任务，每个 Map 处理的数据量差异极大，典型的数据倾斜。用
EXPLAIN看执行计划，发现 JOIN 的 key 是状态字段，只有 3 个枚举值，其中一个值占了 80% 的数据，导致对应的 Reducer 处理量远超其他。第二步，针对数据倾斜的 key 做 salting：在 SQL 里对大 key 加随机后缀打散，JOIN 完再聚合，把一个 Reducer 的工作量分散到多个。同时开启hive.optimize.skewjoin=true，让 Hive 自动识别倾斜 key 并做两阶段 JOIN。第三步，检查表的存储格式，发现是 TextFile 格式，改为 ORC 格式并开启 Snappy 压缩（STORED AS ORC TBLPROPERTIES ("orc.compress"="SNAPPY")），同时开启向量化执行（set hive.vectorized.execution.enabled=true）。第四步，开启分区裁剪（hive.optimize.pruner=true），确认查询条件里的分区字段被正确识别，避免全表扫描。R：作业执行时间从 3 小时压缩到约 45 分钟，报表准时发布。事后把 ORC 格式和分区设计列入了新建 Hive 表的规范要求。
案例 B：Spark 作业 OOM 排查（电力云，2023）
S：电力云某 Spark Streaming 作业在高峰期频繁报
java.lang.OutOfMemoryError: GC overhead limit exceeded，作业自动重启，导致数据处理出现间歇性延迟。T：定位 OOM 根因，在不增加硬件的前提下解决问题。
A：先看 Spark Web UI（4040 端口）的 Executor 内存使用情况，发现 Executor 的 Storage Memory 占用接近上限，而 Execution Memory 不足。根因是作业里有一个
cache()操作把中间结果缓存在内存里，但缓存的数据量随时间增长，最终把 Executor 内存撑满。处理方式：① 把不必要的cache()改为persist(StorageLevel.MEMORY_AND_DISK)，内存不够时溢写到磁盘，不再 OOM；② 调整spark.memory.fraction（从默认 0.6 调到 0.7）和spark.memory.storageFraction（从 0.5 调到 0.3），给 Execution Memory 更多空间；③ 对 Streaming 的 batch interval 从 10 秒调到 30 秒，减少每批次的数据量，降低内存峰值压力。R：OOM 消除，作业稳定运行。
HDFS 常见问题：
- NameNode 内存压力：每个文件/Block 在 NameNode 内存里占约 150 字节，小文件过多会撑爆 NameNode。用
hdfs dfsadmin -report查 Block 数量，用hadoop archive或CombineFileInputFormat合并小文件 - DataNode 磁盘告警：
hdfs dfsadmin -report查各节点剩余空间，hdfs balancer -threshold 10触发数据均衡，把数据从高水位节点迁移到低水位节点
常见追问：
- CDH 和华为 MRS 的区别：MRS 是基于开源 Hadoop 生态（包含 CDH 的核心组件）做了华为的商业化封装，核心组件（HDFS、HBase、Kafka、Hive、Spark）的原理和 CDH 一致，运维思路完全相通，差异主要在管理界面和部分配置路径上
- Hive on Spark vs Hive on MR：Spark 引擎内存计算，适合迭代型作业；MR 适合超大数据量的稳定批处理，不容易 OOM
技能 4：K8s 管理容器化大数据服务
一句话定位：在交付阶段和驻场支持期间，处理过 K8s 上容器化大数据服务的 PVC 挂载、容器权限、跨节点通信等故障。
案例 A：容器化 ES 集群 PVC 挂载失败（衢州警务云，2024）
S：警务云 K8s 上部署的 Elasticsearch 集群，某次节点重启后，ES Pod 无法启动，日志显示数据目录挂载失败。
T：当天恢复，ES 集群不可用会影响警务数据检索业务。
A：先看 Pod 事件（
kubectl describe pod <es-pod>），发现MountVolume.SetUp failed，PVC 处于 Pending 状态。检查 PVC 的 StorageClass，发现引用的 StorageClass 名称拼写错误（csi-disk写成了csi-disk-s），导致找不到对应的 provisioner，PV 无法动态创建。修正 StorageClass 名称后，PV 自动创建，PVC 绑定成功。但 ES Pod 还是起不来——再看容器日志，报Permission denied无法写入数据目录。ES 容器用非 root 用户（uid=1000）运行，但挂载进来的 PV 属主是 root。在 Pod 的securityContext里加fsGroup: 1000，K8s 会在挂载后自动把卷的属组改为该 GID，ES 进程就能写入了。R：ES 集群恢复正常。事后把 StorageClass 名称校验和 securityContext 配置列入了大数据服务上 K8s 的检查清单。
衍生追问准备：
- 创新点：把两层问题（StorageClass 拼写 + 容器权限）都沉淀进了上线检查清单，后续同类问题不再重复出现
- 如果重做：在 Helm Chart 或 YAML 模板里做 StorageClass 名称的参数化管理，避免手写出错
案例 B：K8s 扩容节点后大数据 Pod 跨节点通信不通（电力云，2023）
S：电力云 K8s 集群新扩容了 3 个工作节点，扩容后新节点上的大数据 Pod 无法访问其他节点的 Pod，但同节点 Pod 之间通信正常。
T：定位网络不通原因，恢复跨节点通信，不能影响存量业务。
A：分层排查。在新节点上 ping 其他节点宿主机 IP，通；ping 其他节点上 Pod IP，不通，说明是 overlay 网络问题。检查新节点路由表（
ip route），发现没有 Pod 网段（10.244.x.x/24）的路由条目，老节点上有。查 CNI（Calico）的 Pod 日志，发现新节点上的 calico-node Pod 处于 CrashLoopBackOff，报错bird: Unable to open configuration file。原因是扩容时新节点的 hostname 格式和集群其他节点不一致（老节点是node-001格式，新节点是完整 FQDN），Calico 的 BGP 配置模板用 hostname 做节点标识，格式不匹配导致 bird 进程启动失败，路由无法建立。修正新节点 hostname 格式后，calico-node 重启，路由自动同步。R：跨节点通信恢复正常。事后把"扩容节点后验证 CNI Pod 状态"列入扩容 SOP 必检步骤。
容器化大数据服务常见追问：
- StatefulSet vs Deployment：大数据服务（ES、HBase、Kafka）用 StatefulSet，保证 Pod 有稳定的网络标识和持久化存储，重启后 Pod 名称不变，数据不丢
- 大数据 Pod 资源限制：
requests和limits要合理设置，ES 的 JVM heap 要和容器limits.memory匹配，避免容器被 OOM Kill - 滚动升级大数据集群：用
kubectl rollout配合maxUnavailable=1，逐个 Pod 升级，保证集群始终有足够副本提供服务
技能 5：大数据监控体系建设与告警治理
一句话定位：主导构建过统一监控告警体系，覆盖大数据组件、K8s 层、基础设施层三个维度，设置 200+ 项告警阈值，治理过告警风暴问题。
案例：监控体系从零构建 + 告警风暴治理（衢州政务云，2023/12）
S：政务云上线前没有统一监控，出了问题靠人工发现，平均故障发现时间超过 30 分钟。搭完监控之后又出现了新问题——一旦某个核心服务挂掉，几十条告警同时触发，运维人员根本看不过来，反而更乱。
T：构建统一可观测体系，同时解决告警风暴问题，让告警真正有用。
A：分两阶段做。第一阶段搭体系：
node-exporter采主机指标，kube-state-metrics采 K8s 对象状态，大数据组件侧用各自的 JMX Exporter（Kafka、HBase、HDFS 都暴露了 JMX 指标）接入 Prometheus，日志链路走Filebeat → Kafka → Logstash → ES，设了 200 多条告警规则。第二阶段治告警风暴：在 AlertManager 里配置两个关键规则——group_by: ['service', 'severity']把同一服务的告警合并成一条；inhibit_rules做根因抑制，比如 HDFS NameNode 不可用这条根因告警触发后，自动压制下游的 HBase 写入失败、Hive 作业超时等衍生告警，运维人员只看到一条根因。R：故障发现时间从 30 分钟降到 3 分钟，告警数量减少约 60%。
衍生追问准备：
- 创新点：inhibit_rules 根因抑制是这套体系的核心设计，把"告警风暴"变成"根因单条告警"，运维人员不再被淹没
- 如果重做：更早引入 SkyWalking 做链路追踪，把指标/日志/链路三维打通，故障定位会更快
- 遇到的困难：200 多条告警规则的阈值怎么定？我的做法是先跑两周收集基线数据，用 P95 作为告警阈值起点，再根据实际误报率调整，不拍脑袋定数字
大数据组件关键监控指标：
- Kafka：
kafka_consumer_group_lag（消费积压）、kafka_server_BrokerTopicMetrics_MessagesInPerSec（写入速率）、磁盘使用率 - HBase：
hbase_regionserver_requests（各 RS 请求分布，用于热点检测）、hbase_replication_ageOfLastShippedOp（容灾同步延迟）、hbase_regionserver_memStoreSize（MemStore 大小，接近上限会触发 flush 影响写入） - HDFS：
hadoop_namenode_filesTotal（文件数，过多会压垮 NameNode）、hadoop_datanode_dfsUsedPercent（各节点磁盘水位） - Spark/Flink：作业 checkpoint 延迟、背压指标、失败重试次数
技能 6：Ansible 自动化运维 + Python/Shell 脚本
一句话定位：在政务云项目中，针对客户自建业务虚机，用 Ansible 做批量配置核查、合规巡检和变更下发；用 Python 写日志异常分析脚本，实现主动告警推送。
案例 A：Ansible 大数据节点批量巡检（衢州政务云，2023/12）
S：政务云上跑着几十台大数据节点和业务虚机，等保审计前需要做合规检查，包括内核参数基线、时钟同步状态、磁盘水位、关键进程存活等。之前全靠人工逐台 SSH 检查，一次要花大半天，而且容易遗漏。
T：把这部分巡检自动化，输出标准化报告，支撑等保审计。
A：用 Ansible 写了一套巡检 Playbook，对所有节点并发执行：用
sysctl模块检查内核参数基线（net.ipv4.tcp_syncookies、vm.swappiness等），用systemd模块检查关键服务运行状态（HBase RegionServer、Kafka Broker、HDFS DataNode 等），用shell检查磁盘水位和 NTP 同步状态。结果通过register收集后，用 Jinja2 模板渲染成 HTML 报告，不合规项高亮标红，自动发给运维负责人。R：巡检时间从大半天压到 10 分钟，覆盖率 100%。这套 Playbook 后来作为交付物留给客户，他们自己维护基线配置项。
案例 B：Python 大数据作业异常监控脚本（衢州政务云）
S：政务云 ES 里每天有大量大数据作业日志，运维团队需要人工翻日志找 ERROR，效率很低，容易漏掉低频但重要的异常。
T：自动化识别日志中的异常模式，主动推送给运维团队。
A：写了一个 Python 脚本，每小时通过 ES 的 REST API 用
terms aggregation查询最近一小时内level=ERROR的日志，按error_code和service字段分组统计各类异常出现次数。把这次统计结果和上一小时对比，如果某个 error_code 数量增长超过 3 倍，或者是首次出现的新异常类型，就触发推送。通过企业微信 Webhook 发送告警，消息里附上异常摘要和 Kibana 跳转链接，运维人员点链接直接看原始日志上下文。R：运维团队不再需要每天手动翻日志。有一次靠这个脚本提前发现了某大数据服务的数据库连接异常，在影响业务之前就处理掉了。
Shell 典型场景：
- 大数据集群健康检查脚本：循环检查各组件进程存活 + 端口可达 + 关键日志 ERROR 数量，汇总输出健康报告
- Kafka topic 磁盘清理：定期检查各 topic 的日志大小，超过阈值自动调整
retention.ms - HDFS 小文件合并：定期扫描小文件目录，用
hadoop archive打包归档，减少 NameNode 内存压力
常见追问：
- Playbook 幂等性：用声明式模块（
sysctl、service、file）而不是直接 shell，重复执行结果一致 - 敏感变量：用
ansible-vault encrypt_string加密后存入变量文件，运行时解密，不明文存密码 - 执行失败处理：关键变更步骤用
block/rescue结构，block 里做操作，rescue 里把备份还原回去
技能 7：Linux 系统调优与容量规划
一句话定位：在多个大数据平台项目中，负责 Linux 系统调优、容量规划和性能基线建立。
大数据节点 Linux 关键调优项：
vm.swappiness=1：大数据节点禁止 swap，JVM 进程被 swap 到磁盘会导致 GC 停顿暴增net.core.somaxconn=65535+net.ipv4.tcp_max_syn_backlog=65535：Kafka/HBase 高并发连接场景ulimit -n 65536：大数据进程打开文件数限制，不够会报Too many open files- 关闭透明大页（
echo never > /sys/kernel/mm/transparent_hugepage/enabled）：THP 会导致 JVM GC 停顿不稳定，HBase/Kafka 官方文档明确要求关闭
容量规划思路（被问到时）：
- Kafka：根据消息峰值速率 × 副本数 × 保留时间估算磁盘容量；根据消费者数量和分区数规划 Broker 数量
- HBase：根据数据量 / 压缩比估算 HDFS 存储；NameNode 内存按每个文件 150 字节估算，文件数超过 1 亿需要扩容
- K8s 节点：大数据 Pod 的
requests要准确，避免节点超卖导致 OOM Kill
三、加分项准备
数据中台规划与部署（JD 第1条）
在电力云项目中，MRS 大数据平台承担了数据中台的核心职能——数据采集（Kafka）、存储（HDFS/HBase）、计算（Hive/Spark/Flink）、服务（ES 检索）全链路都在这套平台上跑。我参与了从规划到交付的全流程：前期做容量规划和组件选型，中期主导部署和调优，后期负责版本演进和容量治理。如果被问到"数据中台"的理解，可以从这个角度展开，不需要单独包装。
自动化工具（Ansible / Jenkins）
Ansible 有实际落地案例（见技能 6）。Jenkins 在 CodeArts 项目中接触过 CI/CD 流水线设计，了解 Pipeline as Code（Jenkinsfile）的写法，触发器配置（代码提交触发、定时触发），以及构建失败通知机制。
云计算平台经验
华为云用得最深，6 年原厂经验，私有云场景下从底层 OpenStack 到上层 CCE、MRS、DMS 全栈都用过。阿里云相对用得少，主要是 ECS、RDS、OSS 这些基础服务，在对接外部系统时接触过。如果被问到 CDH 和华为 MRS 的区别：MRS 是基于开源 Hadoop 生态（包含 CDH 的核心组件）做了华为的商业化封装，核心组件（HDFS、HBase、Kafka、Hive、Spark）的原理和 CDH 一致，运维思路完全相通，差异主要在管理界面和部分配置路径上。
技术文档编写（JD 第7条）
在政务云项目中，制定了 33 项核心运维流程文档和 50+ 个标准交付物，包括《服务发布管理流程》《应急操作手册》《变更操作 SOP》等。在电力云项目中，把 HBase 热点治理、Kafka 消费积压等故障案例整理成排查指南，作为团队知识库沉淀。这个能力可以直接迁移到新岗位的操作手册和配置指南编写。
分布式系统设计理解（JD 任职要求第10条）
被问到分布式系统设计时，可以从实际运维经验切入：
- CAP 理论在大数据组件里的体现：HBase 选 CP（强一致性 + 分区容忍），牺牲了部分可用性；Kafka 通过 ISR 机制在 C 和 A 之间做权衡，
acks=all偏 C，acks=1偏 A- 数据分片与负载均衡：HBase 的 Region 分片机制，RowKey 设计直接决定数据分布是否均匀，这是我在热点治理案例里深刻体会到的
- 容错与高可用：HDFS 的 3 副本机制、HBase 的 WAL + MemStore 双写保证数据不丢、Kafka 的 ISR 副本同步——这些都是分布式系统容错设计的具体实现
四、STAR 案例库
✅ 成功/骄傲案例：电力云大数据平台 HBase 热点治理
S：电力云 HBase 写入热点，单台 RS 承载 90% 以上写入，写入延迟从 5ms 涨到 200ms，下游 Flink 出现背压，影响实时数据处理。
T：不停服恢复写入性能，给出可落地的长期治理方案。
A：短期手动 split 热点 Region 止损；长期改造 RowKey 加 2 位哈希盐值打散写入，配合预分区，压测验证各 RS 写入均匀。
R：写入延迟恢复到 5ms 以内，Flink 背压消除，RowKey 设计规范列入平台上线审查清单，从"救火"变成"防火"。
这个项目的创新点：把 RowKey 设计规范前置到上线审查环节，工程化沉淀，后续新表上线前必须通过数据模型审查，从根源上避免热点问题。
✅ 成功案例：衢州政务云自动化运维体系建设
S：政务云上线后，几十台大数据节点和业务虚机全靠人工运维，等保审计前合规检查要花大半天，变更出错率高，客户对运维效率不满意。
T：把重复性运维工作自动化，同时帮客户建立自主运维能力，通过等保测评。
A：用 Ansible 写巡检 Playbook，制定 33 项核心运维流程和 50+ 个标准交付物，构建 ELK 日志平台和 200+ 项告警阈值的监控体系，给客户运维团队做分层培训。
R：巡检时间从大半天压到 10 分钟；运维团队独立完成日常运维任务占比从 30% 提升至 80%；通过等保测评。
这个项目的创新点：不只是交付工具，而是帮客户建立了自主运维能力——Playbook 作为交付物留给客户，他们自己维护基线配置项，实现了"授人以渔"。
❌ 失败案例：电力云跨大版本升级变更事故
S：国网电力云 HCS 跨大版本升级，存储组件升级后新版本默认 IO 调度策略从 deadline 改为 mq-deadline，和旧版本行为不一致。
T：维护窗口 8 小时内完成升级，业务不中断。
A：我当时的判断是这类参数变化影响不大，没有在完全一致的测试环境充分验证，直接在生产升级。发现问题后紧急回滚，回滚过程中部分虚机出现短暂 IO 中断。
R：业务恢复正常，但出现了不该有的中断。教训：跨大版本升级，"隐性"的默认参数变化比显性的功能变化更危险，因为它不会报错，只会在特定负载下才暴露。事后制定了"版本升级变更检查清单"，把新旧版本参数对比（包括默认值）列为必检项，用
fio做 IO 基准测试作为升级前后的对比基线。
这次失败对我的成长：让我深刻认识到，变更管控里最难的不是已知风险，而是"你不知道你不知道"的隐性变化。所以我现在对任何跨版本变更，都会先做完整的 diff 对比，不只看 changelog，还要对比默认配置项。
🔍 有趣案例：Kafka 消费积压定位
监控告警消费 lag 持续增长，但只集中在特定分区，其他分区正常。这个现象很关键——如果是消费者整体能力不足，所有分区都会积压；只有特定分区积压，说明是那几个分区的消费者线程出了问题。排查发现消费者线程处理异常消息时，异常被 catch 住反复重试，offset 不推进，后续消息全部卡住。引入死信队列机制后，积压消息 2 小时内消化完毕。
有趣的地方在于：这个 bug 在低流量时完全不会暴露，因为异常消息出现频率很低，偶尔卡一下很快就被正常消息"冲走"了。只有在高流量下，异常消息密集出现，才会触发积压。这让我意识到，消费者的异常处理逻辑是 Kafka 接入最容易被忽视的风险点，后来把它列入了 ISV 接入规范的必检项。
五、软性问题
职业发展方向
"我的方向是大数据平台运维工程化。过去 6 年在华为做的是偏交付侧，每个项目做完就转维，缺少在一个平台上持续深耕、把运维做精做深的机会。接下来我希望在一个产品化的公司，把大数据平台的运维做得更标准、更稳定——不只是救火，而是建立一套能预防问题、快速定位、自动化处理的运维体系。这个岗位的 Hadoop 生态 + K8s 容器化方向，正好是我想深耕的。"
优缺点
优点（三点，对应 JD 的 ownership + 故障排查 + 技术文档）：
故障排查有方法论，不靠直觉：我处理问题的习惯是先分层缩小范围，再逐步下钻，不会一上来就乱改配置。HBase 热点、Kafka 积压、K8s 网络不通这些案例，都是这个思路的体现。有一次客户凌晨打电话说服务挂了，我在电话里引导他们一步步排查，20 分钟内定位到根因，客户后来说这是他们见过最有条理的故障处理。
喜欢把经验沉淀成规范：每次处理完问题，我的习惯是把根因、排查步骤、预防措施整理成文档，列入 SOP 或检查清单。政务云项目里的 33 项运维流程、电力云的 RowKey 设计规范，都是这样来的。这样做的好处是，同类问题不会在同一个地方踩两次坑。
主动性强，不等问题来找我：在政务云项目里，我主动写了 Python 脚本做日志异常趋势分析，在业务感知到问题之前就推送告警。这不是 JD 要求的，是我觉得"被动响应"不够，主动做的。
缺点（两点，坦诚但不触碰岗位核心要求）：
有时候对"做对"的执念会影响效率：遇到问题我会想把根因彻底搞清楚再给方案，有时候客户只想要一个快速止损的临时方案，我会花时间解释为什么临时方案有风险。这个习惯在技术上是对的，但在沟通节奏上有时候会让对方觉得慢。我现在的改进是先给止损方案，同时并行排查根因，两件事分开推进。
CDH 没有直接操作经验，只有 MRS：华为 MRS 和 CDH 底层原理一致，但管理界面和部分配置路径不同。我需要一段时间熟悉 CDH 的操作习惯。我的计划是入职前在本地搭一套 CDH 环境，把常用运维操作跑一遍，消除这个差距。
离职原因
"家庭原因，我妈身体出了点状况需要手术，我是独子，当时需要频繁就医陪护，就申请离职了。现在家里情况已经稳定了，可以全身心投入新工作，随时可以到岗。"
追问"后续还会影响工作吗"：
"最难的阶段已经过去，后续定期复查不影响正常上班，这个我可以承诺。"
薪资期望
先反问："请问这个岗位的薪资范围大概是什么区间？"
了解后再报区间，主动解释：上份是项目制结构，薪资里包含项目奖金和补贴，稳定性不如产品公司。现在优先考虑稳定性和长期发展，薪资上有一定的灵活空间，但也希望和我的经验匹配。
到岗时间
"已经离职了，到岗时间比较灵活，可以结合贵司的节奏来定，到时我们双向沟通一下就行。"
对公司/岗位的问题（面试最后反问）
- 目前大数据集群的规模大概是多少台，主要跑哪些业务场景？
- 运维团队现在的自动化程度怎么样，有没有在推 SRE 方向？
- 这个岗位最近半年最大的挑战是什么？
六、面试注意事项
- 语速放慢，说清楚比说快更重要
- 没听懂先确认："您的意思是问 xxx 吗？"
- 复杂问题先思考："我稍微整理一下思路"
- 先说要点再展开，问面试官是否需要补充
- 真不会就说不了解，补一句"我会主动去研究，跑通流程"
- 案例说自己做了什么，不说"我们团队做了"