提示词商城
AI 写作
图片
视频
热门角色
热门业务
模型专用
提示词工具
非会员
非会员
×
¥元
查看详情
首页 / 技术面试问题生成器
🔥 会员专享 文生文 招聘

技术面试问题生成器

👁️ 157 次查看
📅 Nov 23, 2025
💡 核心价值： 本提示词专为求职面试准备场景设计，能够根据特定职位角色生成精准匹配的技术面试问题。通过系统分析职位要求、技术栈和行业特点，生成具有深度和专业性的技术问题，帮助面试官评估候选人的技术能力和专业素养。生成的每个问题都经过精心设计，既考察基础理论知识，又评估实际应用能力，确保问题与目标职位高度相关且具有实际评估价值。

🎯 可自定义参数（4个）

职位角色
目标招聘职位的具体名称
技术领域
职位所属的技术领域或专业方向
经验级别
职位要求的经验水平
技术栈
职位要求的具体技术栈或工具

🎨 效果示例

职位概述

  • 该职位负责基于 Go 语言构建高性能、可扩展的服务端与分布式系统，采用微服务架构（gRPC/REST），运行在 Kubernetes 上，配套 Docker 容器化与 CI/CD 流水线。
  • 重点领域包括：并发与资源治理、数据一致性与可靠消息、缓存与高并发读性能、可观察性与性能优化、以及云原生部署与灰度发布。

问题列表

  1. 问题题干

    • 设计一个订单聚合 gRPC 服务（Go），输入订单ID并并发调用库存、支付、物流三个下游服务后聚合返回。要求：
      • 整体超时 300ms，并正确传播取消信号至所有下游调用。
      • 针对慢或失败的下游调用实施带指数退避与抖动的重试，且不引发雪崩。
      • 在高并发下实现限流与背压，避免 goroutine 泄漏与连接风暴。
      • 说明关键架构选择与核心伪代码/代码片段（不需要完整实现）。
    • 考察要点
      • Go 并发与资源治理：context.WithTimeout/errgroup.WithContext、bounded worker/信号量、连接复用。
      • 可靠性模式：重试策略（退避+抖动）、幂等性、单点热点请求合并（singleflight）、断路器/隔离舱。
      • gRPC 客户端实践：每次调用不频繁 Dial、deadline/metadata 传播、keepalive、拦截器实现重试与熔断。
      • 可观察性与容量管理：trace/metrics/log 的关联、背压设计、避免 goroutine 泄漏的代码习惯。
    • 预期回答方向
      • 在入口创建 ctx=WithTimeout(300ms)，errgroup.WithContext(ctx) 并发 fan-out；每个子任务使用限流器（x/time/rate）或加权信号量控制并行度。
      • 复用 gRPC 连接（长连），在 per-call 设置 WithTimeout/WithBlock 合理的 deadline；通过客户端/服务端拦截器实现指数退避+抖动的重试，仅对幂等读操作（如查询）重试。
      • 对同一订单ID的重复请求使用 singleflight 合并；为下游设置短路器（gobreaker）与隔离舱，避免级联故障。
      • 背压：bounded channel/worker pool，不做无限制 go；确保 goroutine 在 ctx Done 时退出；清理 timer、避免泄漏；连接池参数合理。
      • 可观察性：OpenTelemetry trace 跨服务传播、RED 指标（Rate/Errors/Duration）；结构化日志携带 traceId；故障注入与压测验证。
    • 难度等级
      • 进阶

  2. 问题题干

    • 在订单创建流程中，服务需写入 MySQL 后向 Kafka 发布“OrderCreated”事件，要求“写库成功必发消息”，并确保下游服务处理幂等、无重复副作用。请给出一种可落地的方案，覆盖：
      • 事务一致性（避免写库成功但消息丢失）。
      • 失败恢复与重复投递的去重策略。
      • Kafka 分区键、消息有序性、消费者幂等与回放策略。
      • Schema 演进与兼容（事件字段变更）。
    • 考察要点
      • Outbox/Transactional Messaging 模式与 CDC（如 Debezium）。
      • Kafka 语义：idempotent producer（enable.idempotence）、事务性生产者（producer/consumer transactions）的边界与误区。
      • 幂等性设计：业务幂等键、去重表/唯一约束、去重窗口、消费者端幂等处理。
      • 失败场景枚举与补偿：发布器崩溃、重复消费、分区重平衡、顺序与一致性权衡。
      • Schema 版本管理（Schema Registry / Protobuf backward compatibility）。
    • 预期回答方向
      • 方案一（推荐）：应用内 Outbox 表（order + outbox 同一本地事务），提交后由异步发布器轮询/拉取未发送记录；发布成功以“外部幂等键（orderId 或事件Id）”更新状态。发布器崩溃/重启通过幂等生产确保不重复副作用。
      • 方案二：CDC（Debezium）订阅 Outbox/事件表，保证写库即产生变更流；同样依赖消费者幂等。
      • Kafka：选择分区键为 orderId 确保同订单有序；使用 enable.idempotence=true；若使用事务性生产者（transactional.id），说明其仅保证 Kafka 内部端到端 EOS，不等同于跨系统“真正的 exactly-once”。
      • 消费端：幂等键 + 去重表（唯一索引）或幂等缓存，保证重复消息不产生副作用；处理回放与死信队列（DLQ）。
      • Schema 演进：新增字段向后兼容（保留默认值），禁止破坏性删除，使用 Schema Registry/Protobuf reserved 字段管理。
    • 难度等级
      • 高级

  3. 问题题干

    • 为商品详情读服务设计多级缓存架构（本地缓存 + Redis Cluster + MySQL），在高 QPS 下需要解决：缓存穿透、击穿、雪崩、热点键。说明关键策略、参数与监控指标，并给出失效与更新路径。
    • 考察要点
      • 多级缓存策略：本地（bigcache/ristretto）、远端 Redis（Cluster/Sentinel）、TTL/刷新策略。
      • 抖动与合并：singleflight/request coalescing、stale-while-revalidate。
      • 穿透/击穿/雪崩防护：负缓存（not found 缓存）、随机 TTL、分批预热、限流。
      • 热点治理：分片/复制、局部热点迁移、分层限速、Lua+锁的谨慎使用。
      • 监控：命中率、延迟、key 分布、热点检测、回源比、Redis 资源利用。
    • 预期回答方向
      • 本地缓存：ristretto（并发友好、近似 LRU）设置容量与 TTL；Redis Cluster 采用 hash tag 保证相关键同分区；关键路径使用 Pipeline。
      • 防穿透：BloomFilter 或负缓存（空对象 TTL 短）；防击穿：单键 singleflight 合并回源，stale-while-revalidate 返回过期但可接受数据并后台刷新。
      • 防雪崩：随机化 TTL、分批失效；限流器对回源 DB 保护；热点键复制到多分区或开启只读副本就近读取。
      • 失效策略：写后删除缓存或事件驱动失效（binlog/CDC 触发）；确保至少一次失效送达并容忍短暂不一致。
      • 指标：命中率、回源比、P99 延迟、TOP 热点键、Redis CPU/内存、网络带宽；告警与自动化降级。
    • 难度等级
      • 基础

  4. 问题题干

    • 在 Kubernetes 上为上述 gRPC 服务设计灰度发布与弹性伸缩方案，要求：
      • Canary 渐进流量切换与自动回滚（基于 SLO）。
      • 正确的 gRPC 就绪/存活探针与连接优雅摘除（drain）。
      • HPA 基于业务指标（QPS/延迟）伸缩，资源请求/限制合理设置，避免 CPU throttle。
      • PDB/反亲和/拓扑分布，减少同时中断与集中风险；同时说明 mTLS 与服务间访问控制的方案。
    • 考察要点
      • 灰度发布：Argo Rollouts/Service Mesh（Istio/Linkerd）流量分割、自动回滚策略。
      • gRPC 健康检查（grpc-health-probe）、preStop + terminationGracePeriod 的连接摘除。
      • HPA 自定义指标（Prometheus Adapter），避免基于 CPU 的单一策略导致抖动。
      • 稳定性：PDB、PodAntiAffinity、TopologySpreadConstraints，Requests/Limits、节点压力。
      • 安全与治理：mTLS、RBAC、NetworkPolicy、Secret/Config 管理。
    • 预期回答方向
      • 使用 Argo Rollouts 定义 Canary（5%→20%→50%→100%），Gate 基于 P95 延迟/错误率/饱和度自动判断回滚；或用 Istio VirtualService 权重切分。
      • 就绪探针采用 gRPC Health Checking Protocol；preStop 调用自定义 /drain 或 envoy 的优雅下线，设置 terminationGracePeriod 以等待长连接结束。
      • HPA 以自定义业务指标为主（如请求速率、队列长度、P95 延迟）；Requests/Limits 设置避免 CPU 限制过低导致 throttle；防止伸缩抖动（稳定窗口）。
      • 设置 PDB 控制可中断 Pod 数；PodAntiAffinity/TopologySpread 分散于不同节点/可用区；配置合理的资源 QoS。
      • mTLS：Istio PeerAuthentication/ DestinationRule；NetworkPolicy 限定东西向访问；RBAC 最小权限；Secrets 使用 KMS 加密与自动轮换；配置采用 GitOps（Argo CD）。
    • 难度等级
      • 高级

  5. 问题题干

    • 线上出现该服务 P99 延迟由 30ms 升至 300ms（持续 30 分钟），主要集中在新版本与某些节点。请给出可执行的定位与修复流程，覆盖：
      • 指标/追踪/日志的关联分析与瓶颈定位。
      • Go 层面：GC 暂停、锁竞争、阻塞 I/O、调度、连接管理。
      • 外部依赖：MySQL 慢查询/连接池、Redis/Kafka 延迟、网络与节点资源。
      • 快速缓解与长期优化。
    • 考察要点
      • 系统化排查：RED/USE 方法、对比实验（旧版 vs 新版，节点 vs 节点）。
      • Tracing/Profiling：OpenTelemetry trace、pprof（CPU/heap/block/mutex）、GC 日志分析。
      • 资源与配置：Requests/Limits、HPA 抖动、CPU throttle、磁盘/网络拥塞。
      • 依赖排查：DB 索引/执行计划、连接池饱和、重试风暴、队列背压。
      • 修复策略：先降级/限流/回滚，再进行代码与架构优化。
    • 预期回答方向
      • 先关联版本/节点维度：看错误率/饱和度（队列长度、并发）、Throttle 指标；确认是否资源不足或伸缩抖动。
      • Trace 定位慢 span 属于下游还是本地；pprof 捕获热点与阻塞（mutex/block）；检查 GC（STW 次数与时间，heap 增长、GOGC 配置）。
      • Go 优化：减少分配（池化、预分配）、避免大对象逃逸、优化锁粒度，合理设置 gRPC 连接池与 keepalive，避免重试放大。
      • 数据库：EXPLAIN 排查慢 SQL，补充索引、降低 N+1；连接池上限/等待时间、超时；Redis/Kafka 延迟与重试策略调整。
      • 快速缓解：回滚至稳定版本、限流/熔断、降级部分功能；中期修复：压测（ghz/wrk）、基线试验、容量规划、增加 SLO 驱动的自动回滚。
    • 难度等级
      • 进阶

职位概述

数据工程师（实时计算）主要负责在大数据与数据平台环境中构建与运维低延迟、高可靠的数据处理链路。该岗位围绕 Kafka 作为消息入口、Flink 进行事件时序与状态计算、Hadoop/HDFS 作为存储基础，结合 HBase/ClickHouse 作为 OLTP/OLAP 落地与查询层；通过 Airflow 编排批流协同任务与数据依赖，并建立完善的监控告警体系保障生产稳定性与数据质量。

问题列表

  • 问题题干： 设有 Kafka 主题承载乱序事件，需在 Flink 中按事件时间做滚动 10 分钟窗口的汇总统计，允许 5 分钟迟到数据，并将严重迟到（超出 5 分钟）事件侧输出。请给出完整的设计方案，包括 watermark 策略、窗口类型与触发器、迟到数据处理、状态管理与资源配置。
  • 考察要点：
    • 事件时间语义、Watermark 生成策略（有界/自定义）
    • Window 类型（Tumbling/Sliding/Session）与 allowedLateness、side output
    • 乱序与迟到数据的权衡与一致性影响
    • 状态后端（RocksDB）与 state TTL、checkpoint 配置
    • 性能与内存管理（并行度、keyBy 选择）
  • 预期回答方向：
    • 选择事件时间语义（assignTimestampsAndWatermarks），使用有界乱序水位线（例如最大乱序 5 分钟）或基于观察延迟的自定义 watermark。
    • 使用滚动窗口（TumblingEventTimeWindows.of(10 min)），配置 allowedLateness(5 min)；超窗后数据通过 sideOutputLateData 输出。
    • 对迟到数据的处理策略：侧输出再做补数或补写日志，并说明与最终一致性要求的关系。
    • 状态后端使用 RocksDB，开启增量 checkpoint，设置合理 state TTL（依据窗口长度与迟到容忍度）与 checkpoint 间隔（例如 1–2 分钟），并考虑 checkpoint timeout/alignment。
    • keyBy 维度选择与并行度与 Kafka 分区对齐，避免数据倾斜；必要时引入预聚合或局部聚合（combine）降低跨网络 shuffle。
  • 难度等级：进阶

2. Kafka → Flink → HBase/ClickHouse 的端到端一致性设计

  • 问题题干： 需要构建从 Kafka 经 Flink 处理，分别落地到 HBase（明细/查询）与 ClickHouse（分析报表）的数据链路，并尽可能实现端到端的“精确一次”或等效语义。请阐述方案选择与权衡，包括 Source/Sink 语义、两阶段提交、幂等/去重策略、失败恢复与回滚。
  • 考察要点：
    • Flink 与 Kafka 的 EOS（exactly-once）支持与 checkpoint 提交偏移的机制
    • HBase 写入的幂等性设计（RowKey、CheckAndPut）与 Region 分布
    • ClickHouse 的 MergeTree 引擎选择与去重策略（Replacing/Collapsing/Aggregating/Summing）
    • 两阶段提交（TwoPhaseCommitSinkFunction）适用性与替代方案
    • 失败场景恢复与数据一致性保证（事务边界、回放、去重键）
  • 预期回答方向：
    • 使用 Flink 新版 KafkaSource + checkpoint 对齐实现 Source 端 EOS；解释 offset 在 checkpoint 成功后提交的流程。
    • HBase：设计全局唯一 RowKey（如业务主键+事件时间+随机盐），通过 CheckAndPut/Put 幂等化；预分裂与热点规避；必要时借助异步 I/O（AsyncDataStream）提高吞吐。
    • ClickHouse：选择 ReplacingMergeTree（携带 version 或写入时间戳）或 CollapsingMergeTree（sign 列）实现去重/折叠；排序键包含高选择性维度 + 事件时间，分区按天/小时；说明最终一致性与后台合并的影响。
    • 两阶段提交：如果 Sink 不支持真正事务，解释为何难以端到端 EOS；提出折中方案（写入中间层如 HDFS 再批量导入、或引入去重键/幂等写）并给出恢复策略。
    • 失败恢复：以“可重放+去重”为核心，保证多次写入不产生重复统计；说明在 Flink 重启后如何保证 Kafka offset 对齐与下游幂等。
  • 难度等级：高级

3. 实时作业的反压诊断与性能调优

  • 问题题干： 某 Flink 流作业在高峰期出现端到端延迟上升与吞吐下降。描述你会如何定位与缓解反压，包括具体监控指标、常见瓶颈点以及调优措施（Kafka、Flink 运算符、网络与状态、下游 HBase/ClickHouse）。
  • 考察要点：
    • 监控与告警：Kafka 消费延迟（lag）、Flink backPressuredTime/busyTime/numRecordsInOut、checkpoint 时间、网络缓冲、垃圾回收
    • 瓶颈定位方法：上游分区、下游写入速率、异步 I/O、数据倾斜
    • 性能优化：并行度与资源、operator chaining、rocksdb/timer、网络与缓冲、批量/异步写
    • 降级与限流策略：背压传播、重试与失败隔离
  • 预期回答方向：
    • 指标：Kafka consumer lag、Flink operator backPressuredTime/busyTime、checkpoint duration/alignment、numBytesIn/Out、网络 buffer 使用、GC 时间、HBase/ClickHouse 写入队列长度与拒写率。
    • 定位：从 sink 向上游回溯，检查下游写入耗时（HBase RPC、ClickHouse insert）、是否启用 async I/O 与批量写；识别 keyBy 倾斜（TopN key）。
    • 优化：提高并行度与与 Kafka 分区对齐；启用 operator chaining 与 buffer timeout 合理配置；RocksDB 调优（write buffer、压实参数、state TTL）；Kafka fetch/消费批量参数；HBase 使用批量 Put/客户端写缓冲；ClickHouse 使用多行批量 insert/分区导入。
    • 限流与降级：在 sink 端加速失败重试退避，设置最大等待与队列；必要时按维度降采样或延迟非核心计算；配置告警阈值与自动扩缩容策略。
  • 难度等级：进阶

4. 即席查询与报表场景的数据建模（ClickHouse 与 HBase）

  • 问题题干： 针对高并发实时指标查询与明细追溯的双场景，分别设计在 ClickHouse 与 HBase 的数据模型，包括分区/排序键、引擎选择、TTL 与聚合策略，以及在高基数维度与时间序列场景下的查询优化与成本控制。
  • 考察要点：
    • ClickHouse MergeTree 家族选择与分区/排序键设计
    • 明细与聚合并存策略（原子事实表、预聚合表/物化视图）
    • 高基数维度存储与字典/编码优化
    • HBase 行键设计、列族划分、预分裂与热点规避
    • TTL、冷热分层与归档策略
  • 预期回答方向：
    • ClickHouse：事实明细表使用 MergeTree，分区按天/小时，排序键包含查询过滤常用维度和事件时间；高并发指标可配置 Aggregating/SummingMergeTree 的预聚合表，物化视图同步；高基数维度用低基数编码、字典表或外部字典；合理 TTL 与分区裁剪。
    • HBase：RowKey 设计采用盐前缀 + 业务主键 + 时间倒序，避免热点；列族按访问模式拆分；预分裂与 region 调整；必要时用二级索引（Phoenix）或反向索引表支持多维检索。
    • 成本与性能：ClickHouse 控制分区数量与 merge 压力；批量插入、避免小分片；HBase 限制列族数量、压缩与 BloomFilter 配置。
  • 难度等级：基础

5. 批流协同与运维编排（Airflow + Flink）与监控告警设计

  • 问题题干： 需要以 Airflow 管理维表批量更新与 Flink 实时作业的发布/升级，并建立端到端监控告警。请描述 DAG 设计、依赖与一致性策略（含维表变更与流作业的兼容）、零停机滚动升级（savepoint）、以及关键告警项与自动化恢复措施。
  • 考察要点：
    • Airflow DAG 设计：任务依赖、重试与幂等、SLA/回填
    • Flink 作业升级：savepoint、兼容性（状态 schema 与算子 UID）
    • 维表与流作业一致性：广播状态更新、版本切换与灰度
    • 监控告警：数据延迟、异常率、作业健康、资源与存储
    • 自动化：失败恢复、告警联动、变更回滚
  • 预期回答方向：
    • Airflow：将维表生成与发布（到 HBase/ClickHouse 或 HDFS）作为独立 DAG，任务幂等（按分区/版本号写入），设置 SLA 与回填；用 Sensors/ExternalTaskSensor 协调与流作业的同步点。
    • Flink 升级：先触发 savepoint，确保算子 UID 稳定与状态兼容；滚动发布新版本，从 savepoint 恢复；灰度上线与快速回滚策略。
    • 维表一致性：在 Flink 使用 Broadcast State 持续更新维表快照；引入版本字段，流侧按版本生效时间切换，避免半更新导致的错配。
    • 告警项：Kafka lag、端到端延迟、异常率（如脏数据比）、checkpoint 失败率与耗时、反压时间、HBase/ClickHouse 写入错误率与队列长度、资源使用（CPU/内存/磁盘/网络）。
    • 自动化恢复：Airflow 失败自动重试与告警、Flink 自动重启策略（restart strategy）、达到阈值触发扩容或降级策略，必要时触发回滚到上一 savepoint。
  • 难度等级：进阶

职位概述

  • 岗位：安全架构师（云原生）
  • 技术方向：信息安全与云原生安全
  • 关键栈：Kubernetes 安全、Istio、eBPF、OPA/Gatekeeper、KMS、SAST/DAST、漏洞管理、零信任
  • 职责要点：在多云/多集群环境中设计并落地零信任安全体系，覆盖供应链、集群基线、运行时防护、策略治理与密钥管理，形成可审计、可度量、可持续演进的安全架构与工程实践

问题列表

  1. 问题题干 你需要为一个面向多租户的多集群 Kubernetes 平台设计“端到端零信任”架构。请描述：
  • 身份与信任锚：工作负载身份（SPIFFE/SPIRE 或等价）、服务间 mTLS（Istio）、人机访问与短期凭据
  • 授权与策略：Kubernetes RBAC、OPA/Gatekeeper 治理（镜像来源、特权、资源限额、命名空间隔离、签名/SBOM要求）、Pod Security Admission（PSA）与安全上下文、NetworkPolicy/L7 策略（如 Cilium）
  • 供应链与镜像信任：SBOM、签名（Sigstore/cosign）、准入校验与豁免流程
  • 数据与密钥：etcd/K8s Secret 加密（KMS 插件/Envelope）、Secrets Store CSI Driver、密钥轮换/审计
  • 可观测与审计：审计日志、策略命中、服务网格与工作负载审计的统一追踪 给出关键控制面的串联关系与最小可行实施顺序（Phased rollout）。

考察要点

  • 零信任原则在云原生的落地映射（强身份、最小权限、持续验证、显式信任边界）
  • 控制面/数据面的清晰分层与信任链引导（Bootstrap/轮换/撤销）
  • K8s 准入、PSA、NetworkPolicy、Istio AuthZ 的职责边界与组合
  • 供应链与运行时的闭环（签名→准入→运行时观测/响应）
  • 可演进、可审计与灰度发布策略（Policy 从 audit→warn→enforce）

预期回答方向

  • 身份：SPIFFE ID 映射 ns/sa，Istio mTLS 严格模式，JWT/OIDC 人机访问；短时凭据与 Token 投射（Audience/过期）
  • 策略：Gatekeeper 模板约束（禁止特权/hostPath/NET_RAW、强制 imageDigest、资源限额、命名空间标签隔离）；PSA enforce=restricted；NetworkPolicy 默认拒绝+基于标签的租户边界；Istio AuthorizationPolicy 基于 principal 实现 L7 最小权限
  • 供应链：CI 生成 SBOM（SPDX/CycloneDX）、cosign 签名（keyless/OIDC+Rekor），准入侧验证（Sigstore policy-controller 或 Gatekeeper+external data），带时效的风险豁免
  • 数据与密钥：EncryptionConfiguration+KMS v2 Provider，Secrets Store CSI（云厂商 KMS/HSM），密钥/证书轮换与撤销流程，备份/快照加密
  • 实施顺序：审计→标签治理→默认拒绝网络→PSA enforce→准入签名校验→mTLS 严格→细粒度 AuthZ→运行时检测与自动化响应

难度等级 高级

  1. 问题题干 为 Kubernetes 运行时威胁检测与自动化处置设计基于 eBPF 的方案。要求：
  • 采集：关键 Hook（kprobe/tracepoint、BPF LSM）的选择、CO-RE/BTF 兼容性、内核/托管集群限制
  • 检测：容器逃逸/提权/横向移动的行为特征（execve 高危二进制、mount/ptrace/setns、可写 proc/sys、cap 提升）
  • 关联：容器与 K8s 元数据的关联（Pod/NS/SA），降噪与基线白名单
  • 响应：自动化隔离/处置（打补丁 NetworkPolicy、给 Pod 打隔离标签/驱逐、镜像拉黑）、证据留存
  • SLO：开销与告警质量（最大 CPU/内存开销、延迟预算、误报/漏报目标）

考察要点

  • eBPF 技术约束与安全性（Verifier、Map 大小、ring buffer、cgroup v2、托管节点权限）
  • 行为检测优先级与可解释性（规则分层、阶段化上线）
  • 联动控制面的安全编排（Admission 阻断、镜像阻断、标记/隔离）
  • 性能与鲁棒性（退化策略、内核版本跨度、观测盲区）

预期回答方向

  • 工具链：Tetragon/Falco eBPF/Tracee 方案比较；在 GKE/EKS/AKS 的权限与内核前置检查
  • 关键信号：execve 链、敏感 syscalls、可疑网络模式（反连/端口扫描）、写入 cgroup/ns、容器文件系统突增
  • 降噪：基于 ns/sa/镜像哈希的 allowlist，学习期与规则分组（audit→enforce）
  • 响应编排：隔离 NetworkPolicy（同 ns 限流/阻断）、驱逐并禁止重建（准入与镜像仓库策略联动）、证据（eBPF 事件+容器文件快照+pcap）保全
  • SLO：节点级 <2% CPU/<150MB 内存、P50 事件延迟<1s；退化为 auditd/内核版本黑名单

难度等级 高级

  1. 问题题干 在 CI/CD 中落地供应链安全与镜像信任门禁。请设计：
  • 构建环节：SAST/依赖扫描（SCA）、容器镜像扫描、SBOM 生成与存证
  • 完整性：cosign 签名（含 keyless/OIDC 与 Rekor 透明日志），多签名策略（构建器+安全门禁）
  • 准入策略：基于签名/来源/时间戳/脆弱性阈值的 Gatekeeper/Kyverno/Sigstore policy-controller 校验与豁免
  • 漏洞管理：基于风险的分级治理（CVSS/EPSS/可利用性、CISA KEV、可达性分析），SLA 与例外到期 附：请给出一个最小化的 Rego 片段，禁止使用 :latest 且仅允许来自受信仓库及签名通过的镜像（可描述调用外部数据/签名验证的思路）。

考察要点

  • 供应链闭环与证据链（SBOM、Rekor、构建可追溯/SLSA）
  • 策略在准入侧的实现与例外治理（双人复核、时效、命名空间范围）
  • 风险基线与分层门禁（开发、预发、生产不同阈值）
  • 与发布工程集成（回滚、金丝雀、镜像不可变性）

预期回答方向

  • CI：SAST+SCA（Trivy/Grype/CodeQL）、DAST（API 优先，基于 OAS 的负面测试），SBOM 产出与制品绑定
  • 签名：cosign keyless（OIDC），记录 Rekor；多签名策略（builder+security），镜像 digest 固定化
  • 准入：生产仅允许来自 allowlist registry 且通过签名/时间戳/issuer 校验；Sigstore policy-controller 验证，Gatekeeper 管其它约束与例外标签
  • 漏洞管理：基于 EPSS/KEV/可达性设置门槛；高危阻断，中危带工单观测；例外需到期与风险说明
  • 示例 Rego（伪代码，签名校验可经外部数据适配器）:
    • 禁止 latest：deny if endswith(image, ":latest")
    • 受信仓库：deny if not startswith(image, "registry.trust.local/")
    • 签名外部校验：violation if not external_data.sigstore_verified(image_digest)

难度等级 进阶

  1. 问题题干 事故演练：你怀疑 Istio 信任根（Mesh CA/中级 CA）在一个多集群环境中泄露。请在2小时内完成初步遏制并在24小时内实现安全恢复。请阐述：
  • 即时遏制：流量与身份层面如何降权与隔离（mTLS 模式、AuthZ 收紧、东西向网关控制）
  • 证书与信任域：根/中级 CA 轮换策略、trustDomain 与 trustDomainAliases 调整
  • 身份再发行：工作负载证书的批量失效与重新颁发（滚动、影响面控制）
  • 监控与验证：变更后可用性/安全性验证、回退预案
  • 事后：根因分析、证据保全与长期加固

考察要点

  • Mesh PKI 生命周期与密钥撤销/轮换流程
  • 授权策略的快速收敛（基于主体/路径/方法的最小权限）
  • 多集群信任边界与网关策略（east-west 隔离、临时阻断跨集群）
  • 业务连续性与风险权衡（双轨 CA、灰度替换、证书 TTL）

预期回答方向

  • 遏制：切换 PeerAuthentication 为 STRICT；临时关闭跨集群发现/网关或仅允许白名单；收紧 AuthorizationPolicy（仅允许必要 principals 与路径）
  • 轮换：引入新根 CA（双根并行短期过渡），逐集群替换中级 CA；缩短证书 TTL，加速旧证书淘汰；禁用旧 trustDomain 或移除 trustDomainAliases
  • 再发行：逐命名空间滚动重启（按优先级），对无损服务先行；自动化校验工作负载证书与链
  • 验证：金丝雀探针+SLO 监控；证书覆盖率与失败率看板；出现大面积失败时回退到过渡阶段
  • 事后：密钥来源溯源、HSM/KMS 保护、签发审计、最小化 CA 权限与隔离签发面

难度等级 高级

  1. 问题题干 在混合云环境设计与实现密钥与机密管理方案，要求：
  • K8s Secret 加密：etcd 加密（EncryptionConfiguration）与 KMS v2 Provider 集成、轮换流程与性能评估
  • 运行时取密：Secrets Store CSI Driver 对接云厂商 KMS/外部保管库、工作负载身份到 KMS 的授权（GKE Workload Identity/EKS IRSA/AKS Workload Identity）
  • 最小权限与审计：命名空间/SA 到密钥的细粒度授权、审计与访问上报
  • 风险控制：节点妥协/快照泄露的防护、密钥停用与紧急轮换、备份加密与跨域复制 给出跨云一致性的抽象与例外处理策略。

考察要点

  • KMS/Envelope 加密与性能、可用性与限流
  • 工作负载身份联动与最小权限策略
  • 机密分发平面选择（K8s Secret vs CSI vs 应用层）与取舍
  • 轮换、撤销与审计闭环

预期回答方向

  • etcd/KMS：AES-CBC+KMS v2 插件，分层加密；灰度轮换（写新读旧→强制新→清理旧）；性能/可用性（KMS 限流/缓存/断路器）
  • CSI：以应用拉取（不落盘/内存映射），密钥不入 etcd；基于 SA→KMS 策略绑定；禁用节点元数据访问
  • 最小权限：每 NS/SA 绑定到最少的密钥路径；审计对齐 KMS/CSI 日志与 K8s 审计
  • 风险控制：节点妥协时自动撤销 SA 绑定、轮换密钥、隔离工作负载；备份与快照采用独立 KMS 密钥；跨云以统一抽象（如 External Secrets Operator）管理差异与异常分支

难度等级 进阶

示例详情

📖 如何使用

⚡ 30秒出活：复制 → 粘贴 → 搞定
与其花几十分钟和AI聊天、试错，不如直接复制这些经过千人验证的模板，修改几个 {{变量}} 就能立刻获得专业级输出。省下来的时间，足够你轻松享受两杯咖啡！
加载中...
💬 不会填参数？让 AI 反过来问你
不确定变量该填什么？一键转为对话模式，AI 会像资深顾问一样逐步引导你，问几个问题就能自动生成完美匹配你需求的定制结果。零门槛，开口就行。
转为对话模式 →
🚀 告别复制粘贴，Chat 里直接调用
无需切换，输入 / 唤醒 8000+ 专家级提示词。 插件将全站提示词库深度集成于 Chat 输入框。基于当前对话语境，系统智能推荐最契合的 Prompt 并自动完成参数化，让海量资源触手可及，从此彻底告别"手动搬运"。
即将推出
🔌 接口一调，提示词自己会进化
手动跑一次还行，跑一百次呢？通过 API 接口动态注入变量，接入批量评价引擎，让程序自动迭代出更高质量的提示词方案。Prompt 会自己进化，你只管收结果。
发布 API →
🤖 一键变成你的专属 Agent 应用
不想每次都配参数？把这条提示词直接发布成独立 Agent，内嵌图片生成、参数优化等工具，分享链接就能用。给团队或客户一个"开箱即用"的完整方案。
创建 Agent →

✅ 特性总结

一键根据岗位、技术栈与经验级别，生成5道高匹配技术问题，立即投入面试使用。
自动覆盖理论、实践与问题解决三层，确保全方位检验候选人的真实能力。
每题自带考察要点与评分参考，面试官可快速对齐标准，减少主观偏差。
内置难度梯度设计，从基础到高级递进，轻松区分不同水平候选人。
针对行业热点与新技术场景自动更新题面，避免过时题库影响判断。
可按岗位角色灵活定制维度与题型，适配研发、数据、架构、安全等多场景。
一键导出标准化问题清单，支持多人协同复用，统一团队面试流程。
通过结构化题干与清晰表述，降低歧义与偏见风险，提升候选人体验。
以职位相关性为核心筛选题目，杜绝泛问与跑题，提高面试有效时长。
作为候选人练习提示词，模拟真实问答，针对性打磨回答与思路。

🎯 解决的问题

面向技术招聘与面试筹备场景，帮助招聘方在极短时间内生成“岗位强相关”的技术面试问题包：一次输入岗位、技术领域、经验级别与技术栈，即可获得5道分层设计的问题，配套考察要点、预期回答方向与难度标注，形成可直接上手的结构化面试清单。目标是提升面试命中率与可比性，缩短准备时间，减少主观随意和题目失焦，支持开发、数据、架构、安全等多类技术岗位的标准化评估与快速落地。

🕒 版本历史

当前版本
v2.1 2024-01-15
优化输出结构，增强情节连贯性
  • ✨ 新增章节节奏控制参数
  • 🔧 优化人物关系描述逻辑
  • 📝 改进主题深化引导语
  • 🎯 增强情节转折点设计
v2.0 2023-12-20
重构提示词架构，提升生成质量
  • 🚀 全新的提示词结构设计
  • 📊 增加输出格式化选项
  • 💡 优化角色塑造引导
v1.5 2023-11-10
修复已知问题，提升稳定性
  • 🐛 修复长文本处理bug
  • ⚡ 提升响应速度
v1.0 2023-10-01
首次发布
  • 🎉 初始版本上线
COMING SOON
版本历史追踪，即将启航
记录每一次提示词的进化与升级，敬请期待。

💬 用户评价

4.8
⭐⭐⭐⭐⭐
基于 28 条评价
5星
85%
4星
12%
3星
3%
👤
电商运营 - 张先生
⭐⭐⭐⭐⭐ 2025-01-15
双十一用这个提示词生成了20多张海报，效果非常好！点击率提升了35%，节省了大量设计时间。参数调整很灵活，能快速适配不同节日。
效果好 节省时间
👤
品牌设计师 - 李女士
⭐⭐⭐⭐⭐ 2025-01-10
作为设计师，这个提示词帮我快速生成创意方向，大大提升了工作效率。生成的海报氛围感很强，稍作调整就能直接使用。
创意好 专业
COMING SOON
用户评价与反馈系统，即将上线
倾听真实反馈，在这里留下您的使用心得，敬请期待。
加载中...
敬请期待...
📋
提示词复制
在当前页面填写参数后直接复制：