2. 企业云原生平台现状评估
云原生平台演进不是从零开始的重建，而是在既有业务、应用、基础设施和组织能力之上做“有依据的改造”。因此，现状评估的目标不是产出一份漂亮的资产清单，而是回答四个决定演进路线的问题：业务战略需要平台提供什么能力、现有应用组合中哪些值得优先云原生化、基础设施在哪些环节会成为瓶颈、组织与技能能否支撑目标架构落地。这四个维度相互约束，任何一项被忽略，后续的迁移与重构都会在某个阶段被迫返工。
一、业务与IT战略对齐：把战略诉求翻译成平台能力需求
战略对齐的核心动作是建立“业务目标—IT能力—平台能力”的映射链。实际操作中，建议从业务侧收集3～5个未来12～18个月的关键目标，例如“新品上线周期从8周缩短到2周”“支撑大促期间5倍流量弹性”“将客户数据服务化以支持跨渠道复用”。每个目标都要追问：它依赖哪些IT能力？这些能力当前由什么系统承载？平台层需要提供什么才能让这些能力可复用、可度量？
以“新品上线周期缩短”为例，其依赖的IT能力可能包括：环境快速交付、持续集成与持续交付流水线、配置与密钥管理、灰度发布。对应到平台能力，就是命名空间即服务、流水线模板、配置中心、发布策略引擎。评估时对每项能力标注“已具备/部分具备/缺失”，并给出证据，例如“环境交付目前平均3天，依赖人工工单”。这样得到的不是抽象结论，而是一张可排序的能力差距表。
二、应用组合分析：用可量化维度决定改造优先级
应用组合分析要避免“按部门轮流迁移”或“先易后难”的直觉决策。更可靠的方式是选取与云原生改造直接相关的维度，对每个应用打分。建议维度包括：业务关键度（收入或合规影响）、架构耦合度（是否可独立部署）、技术栈陈旧度（运行时与依赖版本）、变更频率（发布频次）、状态化程度（是否有本地持久化状态）、可观测性基础（日志/指标/追踪覆盖）。
打分可采用1～5分制，并明确每个分值的判定标准。例如变更频率：每月少于1次为1分，每周1～3次为3分，每日多次为5分。将各维度加权求和后，应用会自然分化为几类：高业务关键度且高耦合的，适合先做服务拆分与接口治理；低关键度且技术栈陈旧的，可优先容器化并借机下线；变更频繁且已具备可观测性的，适合优先接入流水线与弹性调度。
下面这张图展示了一个应用组合分析的分层判断结构：从应用清单出发，经过六个维度的评分，落入四个处置象限，最终对应不同的演进动作。
三、基础设施盘点：识别容量、网络与依赖瓶颈
基础设施盘点不能停留在“有多少台虚拟机、多少核CPU”。对云原生演进而言，真正需要盘清的是四类约束：计算资源的可调度余量、网络连通性与带宽、存储类型与性能、以及外部依赖的接口与SLA。建议按集群或机房为单位，记录以下字段：节点数量与规格、CPU/内存分配率与实际使用率、存储卷类型与IOPS上限、跨网段延迟、负载均衡与DNS能力、镜像仓库与制品库位置。
一个常见的判断依据是“分配率与使用率的差值”。若某集群CPU分配率已达75%，但实际使用率仅30%，说明存在大量资源预留但未被有效利用，这通常是调度策略和资源请求设置不合理，而非容量不足。此时优先动作是调整requests/limits和引入弹性伸缩，而不是采购新节点。反之，若使用率接近分配率且持续高于70%，则需要在演进路线中安排扩容或迁移。
网络方面要特别关注东西向流量路径。若应用间调用需要经过多层防火墙或跨机房专线，服务网格和微服务拆分带来的延迟与故障面会显著放大。盘点时应记录典型调用链的跳数和延迟基线，作为后续改造的对比依据。
四、组织与技能成熟度评估：从“能不能做”到“谁来持续做”
组织与技能评估要回答三个问题：平台团队是否具备交付自服务能力、应用团队是否具备容器化与声明式运维基础、运维与安全团队是否愿意从审批者转为赋能者。评估方式可采用“角色—能力—证据”三列法。角色包括平台工程师、应用开发、SRE/运维、安全合规；能力项包括容器与编排、CI/CD、可观测性、基础设施即代码、安全策略即代码；证据则是可验证的事实，例如“过去3个月有2个应用通过流水线自动发布到生产”。
成熟度可分为四级：L1依赖人工与工单，L2有脚本但未标准化，L3有平台化能力但覆盖有限，L4自服务且可度量。评估结果不用于考核，而用于决定演进节奏。若应用团队普遍处于L1，直接推行服务网格和GitOps会失败；更合理的路径是先建立流水线模板和基础可观测性，让团队在低门槛下获得正反馈，再逐步引入更复杂的平台能力。
五、评估成果的落地形式
建议将上述四类评估收敛为一份“现状基线表”，每个条目包含：对象、当前状态、目标状态、差距、证据、优先级。优先级可按“业务影响×实现可行性”排序，避免只按技术难度排序。基线表不是一次性文档，而应在每个演进阶段结束后更新，作为下一阶段路线调整的输入。只有把现状评估做成可追踪、可复核的工程活动，云原生平台演进才不会退化为一系列孤立的工具引入。