从发布与可观测看K8s应用架构师——让变更可控、让问题可查
在云原生环境里，变更才是最大的风险来源。发布频率越高，越需要架构师设计"可控的变更"和"可查的系统"。发布策略与可观测体系，是架构师的两项基本功。
先说发布。滚动更新是默认能力，但默认不等于正确。架构师要设计：maxSurge与maxUnavailable如何取舍、就绪探针是否真能反映可用、发布期间容量是否足够。对关键服务，要升级到灰度发布：按流量比例或用户标签逐步放量，观察指标再决定继续或回滚。金丝雀发布需要流量治理能力配合，架构师要评估网关或服务网格是否支持。
回滚要设计成"一键且可信"。镜像版本、配置版本、数据库变更都要可回退。数据库迁移是最难回滚的部分，架构师要推动"向前兼容"的迁移规范：先加字段后改代码、先双写后切换，避免"代码能回滚、数据回不去"。
配置变更同样要管控。ConfigMap更新不会自动重启Pod，可能导致配置与运行不一致。架构师要设计配置发布流程：版本化、校验、灰度、触发滚动重启，把配置当代码管理。
再说可观测。三支柱是日志、指标、追踪。日志要结构化、带上下文、可检索；指标要覆盖黄金信号（延迟、流量、错误、饱和度）和业务指标；追踪要串起跨服务调用，定位慢在哪一环。架构师要定规范：日志格式、指标命名、追踪埋点位置，避免"各写各的，出事查不动"。
告警设计要防噪声。基于SLO的告警比基于阈值的告警更有意义：错误预算消耗过快才告警，而不是CPU一过80%就响。架构师要推动告警分级、抑制规则、值班流程，让告警"少而准"。
可观测还要覆盖K8s自身：节点状态、Pod重启、调度失败、资源压力。应用指标与集群指标要能关联分析，否则定位问题时会在两个系统间来回跳。
发布与可观测是一体两面：发布制造变化，可观测验证变化。架构师把两者串成闭环——发布前有基线，发布中有观察，发布后有对比，出问题能快速定位与回滚。变更不可怕，可怕的是变更不可见、不可控、不可退。
