核心思路：桶策略限定到单个桶，IAM 策略只给最小 Action，两者取交集。 1) 先给桶加 Bucket Policy：Principal 填该 IAM 用户的 URN，Action 只给 GetObject / PutObject / ListBucket，Resource 写两条——桶本身 arn:...:obs:::bucket-name 和对象 arn:...:obs:::bucket-name/*。 2) IAM 侧不要给 OBSFullAccess，建一条自定义策略，Action 用 obs:object:GetObject、obs:bucket:ListBucket，Resource 同样限定该桶。 3) 关键坑：ListBucket 的 Resource 是桶本身（不带 /*），GetObject/PutObject 的 Resource 是对象（必须带 /*）。写反了会出现「能列目录但读不了文件」或反过来。 4) 更安全的做法：不直接给长期 AK，给用户 AssumeRole 权限，程序走 STS 临时凭证（15 分钟~24 小时），泄露窗口小，也便于审计。 5) 验证一定用该用户自己的凭证跑 obsutil ls obs://bucket 和一次上传下载，别用管理员账号验证——管理员永远通，验证不出权限问题。 6) 如果这个用户只做程序访问，把控制台登录关掉，只保留 AK，减少被盗用面。

报「超级块读取失败 / Bad magic number in super-block」通常是 resize2fs 没找到文件系统，不是盘坏了。按顺序查： 1) 设备名和内核识别：lsblk 看 /dev/vdb 的容量是否已经是新大小。云上扩容后内核不一定立刻刷新，执行 partprobe /dev/vdb 或 echo 1 > /sys/class/block/vdb/device/rescan 再试。这是最常见原因。 2) 有分区表的情况：如果实际是 /dev/vdb1，直接 resize2fs /dev/vdb 会失败（那是整盘没有文件系统）。先 growpart /dev/vdb 1 扩分区，再 resize2fs /dev/vdb1。 3) LVM 场景：pvresize /dev/vdb → lvextend -l +100%FREE /dev/vg/lv → resize2fs /dev/vg/lv。 4) 先确认文件系统类型：blkid /dev/vdb1。xfs 不能用 resize2fs，要用 xfs_growfs /mountpoint（xfs 只能扩不能缩）。 5) 如果 blkid 显示没有文件系统，别继续操作，先 dd 备份分区头 1MB 再排查，避免误伤数据。 标准顺序：lsblk → partprobe → growpart → blkid 确认类型 → 选对工具扩容 → df -h 验证。

容器默认继承 UTC，镜像里没设时区，cron 就按 UTC 跑，日志也跟着差 8 小时。三种做法按推荐度排序： 1) 构建时固化（生产推荐）：Dockerfile 里加 RUN ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo Asia/Shanghai > /etc/timezone 所有实例一致，不依赖启动参数。 2) 启动时注入环境变量：-e TZ=Asia/Shanghai（compose 里 environment: - TZ=Asia/Shanghai）。前提是镜像里有 /usr/share/zoneinfo，alpine 必须先 apk add --no-cache tzdata，否则 TZ 设了也不生效，这是最常见的坑。 3) 挂载宿主机时区：-v /etc/localtime:/etc/localtime:ro，简单但和宿主机耦合，跨机器迁移容易忘。 验证：进容器跑 date 看是不是 CST，再等定时任务实际触发看日志时间戳。 另外两个连带问题：如果 cron 里启动的是 Java 应用，JVM 会缓存时区，要加 -Duser.timezone=Asia/Shanghai；数据库连接串也要带 serverTimezone=Asia/Shanghai，否则 JDBC 会再帮你转一次，变成差 16 小时。

选型本质是先摸清业务画像，再按瓶颈维度选，别一上来只看核数。 1) 先定位瓶颈类型：CPU 密集（编译、转码、加解密）看主频和 vCPU，选计算型 c 系列；内存密集（Redis、大 JVM 堆、ES）看内存核比，选内存型 m 系列（常见 1:8）；IO 密集（数据库、大数据、消息队列）看磁盘 IOPS 和网络带宽，选本地盘/高 IO 型；普通 Web 业务用通用型 s 系列就够。同代同系列里主频越高单核越强，PHP/Node 这类单线程敏感业务优先高主频，而不是堆核数。 2) 别只看单价，算单位性能成本：用业务真实压测（不是 sysbench 跑分）测出每元能扛多少 QPS。常见误区是买 16 核但 CPU 长期只跑 15%，不如 4 核 × 4 台水平扩展，还顺带消掉了单点。 3) 弹性优先：无状态服务用弹性伸缩 + 按需实例扛峰，包年包月只覆盖基线；竞价实例能省 70% 以上，但可被回收，适合 CI、离线计算、批处理这类可重试任务。 4) 存储和带宽最容易被忽略：云盘 IOPS 通常随容量线性增长，小容量高性能盘往往不够用，宁可买大一点；公网带宽按峰值包月很浪费，用按流量计费 + CDN 更省。 5) 留 30% 余量：CPU 长期跑 70% 以上，一次突发就雪崩；长期低于 20% 就该降配，别为了「以后可能用得上」多花钱。 一句话总结：先压测定位瓶颈，再按单位性能成本选系列，最后用弹性扛峰值。

按 VPC 数量和使用场景分三种，别一上来就上最重的方案： 1) 同区域、VPC 少（3~5 个）→ 用对等连接（VPC Peering）。免费、时延最低、配置直观，缺点是两两互联，n 个 VPC 要建 n(n-1)/2 条连接，且对等连接路由不能传递，超过 5 个 VPC 后路由表基本没法维护。 2) 同区域、VPC 多或会持续新增 → 上企业路由器（ER）。每个 VPC 挂一次 ER，全互通只配一遍，路由自动传播，还能接 VPN / 云专线 / Direct Connect，后面加混合云不用重构。注意两个坑：VPC 关联到 ER 后，默认路由必须在 ER 路由表里显式放通，否则只在 ER 内部通、出不了公网；ER 是按连接数 + 流量计费的，VPC 很少时比对等连接贵。 3) 跨区域（比如上海 ↔ 北京）→ 对等连接不支持跨区域，要用两个区域的 ER 通过云连接 CC / 全球接入网关打通。 选型结论：如果只是生产/测试/预发隔离、VPC 数量固定，直接对等连接，最省事也最省钱；如果 VPC 会增长或者以后要接 IDC，一步到位上 ER，避免后期迁移路由。 另外无论选哪种，先确认各 VPC 子网网段不重叠——网段重叠时以上方案全都不通，只能靠 NAT 或重新规划网段。安全组和网络 ACL 也要逐跳放通，很多人只配了路由忘了安全组，表现为 ping 不通但路由表看着没问题。

用 CRD 扩展调度逻辑，OpenShift 上走 Operator 模式更稳，不要改 kube-scheduler 源码。核心是把"任务"抽象成自有资源，让调度决策落在控制器里。 1）定义 CRD：group scheduling.example.com、version v1，kind PlanningTask。spec 放优先级、前置任务依赖（dependsOn）、资源画像（cpu/内存/GPU）、可执行时间窗、节点亲和；status 放 phase、assignedNode、conditions，好处是 kubectl get planningtask 就能看排队与分配进度，operator 只做状态机。 2）轻量实现：CRD + 控制器做"二次调度"——监听 spec.nodeName 为空的 Pod，按业务规则算完分后直接调 Pods/Binding 子资源把 Pod 绑到节点，绕过默认调度器的 FIFO 队列。多调度器并存时给 Pod 打 schedulerName 区分职责。 3）复杂场景用调度框架（Scheduling Framework）插件：实现 Filter/Score 扩展点并注册成第二个调度器，能复用 NodeResourcesFit、InterPodAffinity、TaintToleration 等已有插件，比旁路绑定更稳，也不影响默认调度器行为。 4）动态规划任务要处理抢占与回填：用 PriorityClass 区分在线/批处理，批处理配 preemptionPolicy: Never 防止误驱逐在线业务；任务加 activeDeadlineSeconds 与 backoffLimit，控制器在失败时重建 CRD 对象而不是重试同一个 Pod，避免脏状态。 5）OpenShift 侧注意两点：控制器跑在专用 ServiceAccount 上，只给 pods/binding 与自定义资源读写的最小 RBAC，并确认 SCC 允许该 SA 的 securityContext；CRD 的 schema 上线前用 oc explain 校验，后续只做加字段的向后兼容变更，否则既有对象会校验失败被拒。 一句话总结：CRD 只是数据面，真正的调度语义要落在控制器或调度框架插件里，二者配合才能在 OpenShift 上实现可预测的动态调度。

用 CRD 扩展调度逻辑，OpenShift 上走 Operator 模式更稳，不要改 kube-scheduler 源码。核心是把"任务"抽象成自有资源，让调度决策落在控制器里。1）定义 CRD：group scheduling.example.com、version v1，kind PlanningTask。spec 放优先级、前置任务依赖（dependsOn）、资源画像（cpu/内存/GPU）、可执行时间窗、节点亲和；status 放 phase、assignedNode、conditions，好处是 kubectl get planningtask 就能看排队与分配进度，operator 只做状态机。2）轻量实现：CRD + 控制器做"二次调度"——监听 spec.nodeName 为空的 Pod，按业务规则算完分后直接调 Pods/Binding 子资源把 Pod 绑到节点，绕过默认调度器的 FIFO 队列。多调度器并存时给 Pod 打 schedulerName 区分职责。3）复杂场景用调度框架（Scheduling Framework）插件：实现 Filter/Score 扩展点并注册成第二个调度器，能复用 NodeResourcesFit、InterPodAffinity、TaintToleration 等已有插件，比旁路绑定更稳，也不影响默认调度器行为。4）动态规划任务要处理抢占与回填：用 PriorityClass 区分在线/批处理，批处理配 preemptionPolicy: Never 防止误驱逐在线业务；任务加 activeDeadlineSeconds 与 backoffLimit，控制器在失败时重建 CRD 对象而不是重试同一个 Pod，避免脏状态。5）OpenShift 侧注意两点：控制器跑在专用 ServiceAccount 上，只给 pods/binding 与自定义资源读写的最小 RBAC，并确认 SCC 允许该 SA 的 securityContext；CRD 的 schema 上线前用 oc explain 校验，后续只做加字段的向后兼容变更，否则既有对象会校验失败被拒。一句话总结：CRD 只是数据面，真正的调度语义要落在控制器或调度框架插件里，二者配合才能在 OpenShift 上实现可预测的动态调度。

ASM 的流量治理和安全通信是两层能力叠在一起用的，落地可以按四步走。第一，流量治理靠 VirtualService + DestinationRule：VirtualService 管路由（按 header、权重、uri 前缀做灰度），DestinationRule 管 subset 定义、负载均衡策略和熔断（outlierDetection、connectionPool）。灰度发布就是给同一 host 定义 v1/v2 两个 subset，用权重从 10% 起阶梯放量。第二，安全通信分三块：mTLS 用 PeerAuthentication 控制（STRICT 模式强制双向证书），证书由 istiod 通过 SDS 自动签发轮换，业务代码零改造；授权用 AuthorizationRule，按 source 的 namespace、serviceAccount、JWT claim 做 ALLOW/DENY。第三，入口用 Gateway 绑定 ingress gateway 的 80/443，TLS 证书用 credentialName 挂到 gateway 上，内外流量统一走 mTLS。第四，可观测性：Kiali 看拓扑和配置校验，Jaeger 看跨服务调用链，Prometheus 抓 istio_requests_total 做错误率告警。踩坑提醒：STRICT mTLS 打开前先确认所有调用方都在网格内，集群外调用要走 egress gateway 或先开 PERMISSIVE 过渡；AuthorizationRule 一旦有 ALLOW 规则，其余请求隐式拒绝，新增规则时容易把自己锁死，建议先在测试命名空间演练。

HNSW 把「小世界图」和「跳表分层」叠在一起：构建时给每个向量随机分配最大层级（指数衰减，绝大多数点只在第 0 层），每个节点在自己所在层与 M 个近邻连边。查询从最高层入口点做贪心搜索，先在稀疏的高层快速逼近目标区域，再逐层下降，上一层命中点作为下一层入口，最后在第 0 层用 efSearch 大小的候选队列做精细搜索。高层每条边跨度大，一跳就能排除大片不可能区域，搜索范围逐层指数收缩，每层只访问少量节点，总访问量近似 O(log N)，所以亿级向量也能毫秒级返回。分层的本质是粗到细的导航骨架：高层负责长距离跳跃，第 0 层负责精度兜底，efSearch 调大召回上升、延迟也上升。代价是内存高于 IVF（每层存邻居表）、构建慢、删除只能标记删除后重建索引。

建议先检查网络代理设置，再确认API地址和密钥是否正确，同时看下浏览器控制台的具体报错信息，一般都能定位问题。如果还不行可以把报错截图发出来，大家帮你分析。