Appearance
01 - ECS 与计算
本章目标：ECS（云服务器）是阿里云最基础的产品，面试必问。要求讲清：实例族命名规则、规格选型思路（挂靠我移动云 7 台机器的真实规划）、镜像/快照、安全组、EIP/ESS、登录方式。水位：产品定位与选型逻辑【必背】，规格细节【理解】，深度调优【了解】。
1.1 ECS 是什么——产品定位【必背】
知识点：ECS（Elastic Compute Service，云服务器）是阿里云的弹性虚拟机产品，本质是运行在阿里云物理集群上的虚拟机，带完整的计算、内存、云盘、网络能力。核心卖点：免采购硬件、分钟级交付、按规格付费、可弹性变配、配合镜像和快照实现快速复制与恢复。它上层还有弹性裸金属（神龙，物理机性能+云上弹性）和 ECI（Serverless 容器实例），构成计算家族。
标准回答（面试官问"讲讲你对 ECS 的理解"）：
ECS 就是阿里云的云服务器，本质是云上虚拟机，但和传统虚拟机最大的区别是它把计算、存储、网络全部标准化了：规格是从实例族里选的、磁盘是独立产品化的云盘、网络是挂在 VPC 里的弹性网卡，所以它可以分钟级交付、随时变配、用镜像批量克隆、用快照回滚。我的理解不只是概念——我在移动云上用同构的云主机产品真实搭了一套 K8s 生产底座：三台 2 核 4G 的 master、三台 8 核 16G 的 worker、一台 4 核 8G 的监控节点，从规格规划、镜像初始化、安全组放行到节点纳管全程是我参与的。所以我讲 ECS 不是背参数，而是能从"这套环境当时怎么选、怎么建、怎么管"一直讲到"出问题怎么查"，阿里云这边我做过逐一的产品对标，命名和规格档位差异我能对齐讲清楚。
追问 1：ECS 和物理机/传统虚拟化的区别？
三个层面说。成本上，ECS 免去了硬件采购和上架周期，按规格付费，规格随时升降；运维上，宿主机、网络、存储的底层维护全部由云厂商负责，我只管实例内部；能力上，它天然带镜像克隆、快照回滚、弹性伸缩这些传统虚拟化要额外搭建的能力。传统虚拟化的优势是数据自主性强、性能可控、没有多租户干扰，所以阿里云也提供弹性裸金属——神龙架构，物理机性能加云产品生态，给核心数据库和大负载用。我在移动云选云主机而不是物理机，核心原因就是项目要快速交付、规格要能跟着业务弹性调。
追问 2：ECS 上部署 K8s 和用托管容器服务，你的取舍？
我的真实选择是在移动云的云主机上自建 K8s。理由有三条：一是项目对成本敏感，托管控制面要额外付费，三 master 自建的 Etcd 高可用成本更低；二是政企项目对平台自主性有要求，kubeconfig、证书、组件版本都自己掌握，出问题不依赖平台侧响应链路；三是团队要补齐 K8s 全栈运维能力，自建过程本身就是最好的学习。代价是控制面的高可用、证书轮换、版本升级这些事全在自己身上，我们用三 master 分摊 etcd 和 apiserver、CLB 统一接入来解决高可用。如果业务规模大、或者要快速扩缩节点，托管版 ACK/云托管容器更合适——控制面托管省心，节点池和 Terway 网络这些生态也成熟。
1.2 实例族命名规则【必背】
知识点：阿里云 ECS 规格命名格式是 规格族 + 代际 + 规格，例如 ecs.g8i.large。读懂命名就等于会选型：
- 首字母 = 定位：
g（general）通用型：CPU 内存比约 1:4，均衡场景（Web 服务、中间件、中小数据库）——默认首选。c（compute）计算型：CPU 内存比约 1:2，CPU 密集（计算、游戏服、高性能前端进程）。r（ram/memory）内存型：CPU 内存比约 1:8，内存密集（Redis、Java 大堆应用、缓存服务、数据库）。- 其他：
t突发性能型（测试，CPU 积分制慎用生产）、e经济型、d本地盘型（大数据）、gnGPU 型、ebm裸金属。
- 数字 = 代际：数字越大代际越新（g6 → g7 → g8i），新代际同价性能更好，优先选新。
- 后缀 = 规格大小：large = 2vCPU，xlarge = 4vCPU，2xlarge = 8vCPU，以此类推。
- 附加字母含义：
i第 Intel 平台、aAMD 平台、se共享型、t安全增强等（了解即可）。
移动云对标：移动云规格命名是"通用型/计算型/计算增强型/内存优化型 + vCPU/内存档位"的风格，逻辑同构——都是按 CPU 内存比划场景，只是命名风格不同（阿里云偏代号，移动云偏描述）。
标准回答（面试官问"你怎么看懂 ECS 规格、怎么选规格"）：
阿里云的规格命名可以拆成三段读：首字母定场景，g 系列通用型是 1 比 4 的 CPU 内存比，Web 服务、中间件这种均衡负载首选；c 系列计算型 1 比 2，给 CPU 密集的场景；r 系列内存型 1 比 8，给 Redis、Java 大堆这种吃内存的；然后中间的数字是代际，越大越新，同价性能更好，选新不选旧；后面的 large、xlarge 是大小，large 是 2 核，xlarge 是 4 核。我的选型习惯是先定 CPU 内存比、再定代际、最后定大小。这个逻辑我在移动云生产上完整走过一遍：K8s 的 master 要跑 apiserver、etcd 和控制器，etcd 对磁盘和内存敏感但整体压力不大，选的是 2 核 4G；worker 承载业务 Pod，按容量评估和压测定的 8 核 16G；监控节点跑 Prometheus 加 Grafana，时序数据内存开销大，给 4 核 8G。三档规格都是按"角色职责 + 负载特征"定的，不是拍脑袋。
追问 1：为什么 master 用 2 核 4G 这么小？
这是按角色负载算出来的：apiserver 单集群几十个节点、几百个 Pod 的规模下，CPU 峰值有限；etcd 默认写瓶颈在 fsync，压力主要来自集群变更频率，我们规模小、变更可控；controller-manager 和 scheduler 也是轻负载。2 核 4G 留有约一倍余量，够用。真正要给足的是三样：master 必须三台做 etcd 仲裁防脑裂、系统盘用 SSD 保证 etcd 磁盘性能、内存别让 Pod 抢——所以我们给 master 打了污点，业务 Pod 不调度上去。如果集群规模上到百节点级，master 规格就要跟着升到 4 核 8G 甚至 8 核 16G，这是容量的线性外推。
追问 2：worker 为什么是 8 核 16G？
反推法：先做业务容量评估，把所有微服务的 Pod 副本数和 requests 加总，估算单节点要承载的 Pod 数和内存水位；再按"单节点负载不超过 70%"的安全水位定规格。8 核 16G 是个均衡档：CPU 够跑两三倍冗余的副本，16G 内存扣掉系统和大数据基础组件预留后还能给业务留 12G 左右；同时 8 核 16G 在云厂商定价里性价比高。上线后我们持续盯节点 Allocatable 使用率和内存水位，如果业务增长到 70% 以上，优先横向加 worker 节点而不是升配单节点——K8s 本来就是为横向扩展设计的。
追问 3：突发性能型 t 系列能用吗？
只适合测试和非核心场景。t 系列是 CPU 积分制：空闲时攒积分、高负载时花积分，积分耗尽会被限流到基线性能。这对生产是不可接受的不确定性——流量高峰恰好积分耗尽，业务直接卡死。生产环境我坚持选共享型以外的独享型规格族（g/c/r 这类），我的移动云生产环境全部是独享型规格。共享型 se 系列同理，存在资源争抢，不适合承载核心业务。
1.3 规格选择思路——真实用例复盘【必背】
知识点：选规格四步法：
- 定场景画像：CPU 密集 / 内存密集 / IO 密集 / 均衡 → 决定实例族（c/r/d/g）。
- 定容量基线：压测或容量评估得出现有负载 → 加 30%-70% 余量。
- 定高可用形态：生产一律多实例 + 跨故障域（AZ/物理机打散），绝不单点。
- 定演进路径：确认该规格族支持在线变配（升配通常要重启，规划停机窗口）。
我的真实用例（移动云 K8s 底座 7 台机器的规格规划，STAR 复述版）：
S（背景）：项目二要基于移动云交付一套 K8s 底座承载微服务集群，资源预算有限，我负责底座资源规划与部署。T（任务）：用尽量小的预算保证控制面高可用和业务节点容量达标。A（行动）：我先做角色拆分——master 承担控制面、worker 承担业务、监控单独一台避免监控自身和被监控对象互相拖垮；然后按各角色负载画像选规格：master 2C4G（控制面轻负载但要三副本仲裁）、worker 8C16G（按业务 requests 加总算出的均衡档）、监控 4C8G（Prometheus 时序内存开销大）；最后是高可用设计：master 三台天然满足 etcd 仲裁，worker 三台配合 Pod 反亲和打散，监控单台但数据落盘加告警兜底。R（结果）：7 台机器撑起整套生产环境平稳运行，集群资源水位长期在 60% 以下，后续业务扩容直接加 worker 节点横向扩展，没有动过已有规格。这套规划逻辑平移到阿里云就是把"计算型/计算增强型"换成"g/c/r 系列"，思路一模一样。
标准回答（面试官问"说说你实际规划云资源规格的经历"）：
我拿移动云 K8s 底座这个真实项目讲。当时预算有限但要求生产级可用，我的做法是先做角色拆分再定规格：三台 master 用 2 核 4G，因为控制面负载轻，关键在 etcd 仲裁所以必须是三台而不是单台大的；三台 worker 用 8 核 16G，这是我做了业务容量评估反推出来的——把所有微服务 Pod 的 CPU 内存 requests 加总，按单节点 70% 水位和副本余量算出来的均衡档；监控单独一台 4 核 8G，因为 Prometheus 是时序数据库，内存开销大，而且监控和业务混部会在故障时互相放大。最后是可用性设计：master 打污点防业务抢占、worker 用反亲和打散、apiserver 用 CLB 四层统一接入做健康检查自动摘除。结果整套环境水位长期 60% 以下，扩容走加节点不动机器。这套四步法——画像、基线、高可用、演进——到阿里云上就是同样的流程，只是规格名字换成 g/c/r 系列。
追问 1：如果预算砍一半，你怎么调整？
我按"保高可用、砍单机冗余"的原则砍：master 绝不能从三台减，etcd 仲裁是底线，最多把 master 规格保持 2C4G 不动（它已经是最低可用档）；worker 可以从三台压到两台先跑，同时把 Pod 反亲和策略放宽，但要把内存水位和 apiserver、CLB 健康检查兜住——两 worker 意味着单节点故障时另一半要接全部流量，水位要在 50% 以下；监控可以和某台低负载节点混部但数据目录独立。同时我会跟项目方明确风险清单：节点故障容忍度下降、扩容窗口变短。这样砍下来的方案是"有明确代价的省钱"，而不是"无声的脆弱"。
追问 2：上云后发现规格买大了/买小了怎么办？
买大了走降配：阿里云和移动云都支持包年包月实例变配，升降配一般要重启，所以放变更窗口做，先做快照或备份兜底，降完观察一个业务周期再释放预算；买小了分两种——CPU 瓶颈在 K8s 场景优先横向加节点而不是升配，单机瓶颈（比如数据库这种有状态服务不能随便加）才走升配。我的习惯是防患于前：上线前压测，上线后云监控配水位告警，CPU 内存连续高于 70% 触发预警，把"规格买错"变成一个有预警的小问题而不是故障。
1.4 镜像与快照【理解】
知识点：
- 镜像：装好操作系统的"磁盘模板"。类型：公共镜像（官方 OS）、自定义镜像（自己环境打包）、镜像市场（预装软件）、共享镜像。用途：批量交付一致性环境、故障重建、环境迁移。
- 快照：某时刻磁盘数据副本，增量存储，用于备份回滚；可以基于快照创建镜像或云盘。运维节奏：重大变更前打快照是云上铁律。
- 关键差异一句话：镜像是"造机器的模板"，快照是"磁盘的历史存档"；快照针对单块盘，镜像可以固化整机（系统盘+数据盘）配置。
- 移动云对标：云主机同样有镜像与快照能力，我项目里初始化 master/worker 用统一镜像保证基线一致，变更前打快照。
标准回答（面试官问"镜像和快照有什么区别，你怎么用"）：
一句话区分：镜像是造新机器的模板，快照是某块盘在某个时刻的存档。镜像解决的是"批量一致性"——我有一批机器要用完全相同的系统基线，先手工调好一台做成自定义镜像，后面全部从镜像创建，交付出来的环境天然一致，不会每台机器配置漂移；快照解决的是"变更回滚"——增量存储、随时可建，重大变更前打一个，改砸了直接回滚到变更前。我在移动云项目里两者都在生产用过：master 和 worker 节点初始化用统一的自定义镜像，把容器运行时、内核参数、时间同步这些基线固化进去，七台机器基线零漂移；升级或调内核参数前一律先打快照，我们出过一次参数调整影响网络转发的险情，靠变更前快照十分钟回滚，这就是打快照纪律的价值。阿里云这边机制同构，公共镜像加自定义镜像加快照，我做过概念对标。
追问：快照和备份是一回事吗？
不完全是。快照是磁盘层面的时点副本，偏"机器级恢复"，粒度是单块盘；而备份体系还包括应用级、数据库级——比如 MySQL 的逻辑备份、binlog 备份，恢复粒度可以到表、到行。我的生产实践是分层做：磁盘层用快照兜整机故障和变更回滚；数据库层用平台托管备份加定期全量加 binlog，RDS 这类托管数据库甚至自动帮我做了；应用配置层用 Git 管理配置文件。三层各管一段，真出故障时按"影响面最小"的原则选恢复路径。快照还要注意生命周期管理，云上快照是持续计费的，我建议按策略定期清理过期快照控制成本。
1.5 安全组详解【必背】
知识点：
- 安全组：ECS 实例级别的虚拟防火墙，作用于实例（网卡）层，控制进出流量的五元组规则。
- 核心规则：
- 有状态：入方向放行的连接，出方向响应流量自动放行（反向理解出方向同理）。
- 默认拒绝：没有显式放行的流量一律丢弃。
- 规则有优先级（数字越小越优先），匹配即停。
- 规则对象可以是 CIDR 网段，也可以是另一个安全组（组间授权，生产利器）。
- 最佳实践：最小开放原则；按角色分安全组（web 组、db 组、k8s 组），组间互相授权而不是到处写 IP；管理端口（22/3389）不开放 0.0.0.0/0，收口到堡垒机或办公网段。
- 安全组 vs 防火墙/ACL：安全组是实例层的分布式有状态防火墙；网络 ACL（如果平台提供）是子网层的无状态规则；两者叠加纵深防御。
- 移动云对标：移动云云主机同样有安全组，我在项目里为 K8s 集群规划了专用安全组组间授权（master 组与 worker 组互通 apiserver 端口）。
标准回答（面试官问"讲讲安全组，你怎么规划的"）：
安全组是云上实例级别的分布式虚拟防火墙，三个关键特性要讲清：它是有状态的，入方向放行的连接响应流量自动回包，不用再写规则；它默认拒绝，没显式放行的流量全丢；它支持把另一个安全组作为授权对象，这条是生产规划的核心。我的规划习惯是按角色分组加组间授权：比如 K8s 集群里 master 一个组、worker 一个组，master 组只放行 worker 组访问 6443，数据库组只放行业务组访问 3306，不写具体 IP，机器扩缩容时规则自动跟随组，不用维护 IP 清单。管理端口绝不开放公网，SSH 收口到堡垒机网段。我在移动云项目里就是这么落地的——master 安全组和 worker 安全组组间放行 apiserver 端口，CLB 网段单独授权，全程最小开放，这套思路搬去阿里云一模一样，阿里云文档里也把它列为安全组应用的标准场景。
追问 1：安全组和传统防火墙、iptables 什么区别？
本质都是包过滤，区别在层级和管理面。iptables 在实例操作系统内部，规则跟着机器走，机器一重建就丢；安全组是云平台虚拟化层实现的，跟实例绑定、和机器生命周期解耦，在控制台统一管理，机器重建规则仍在，而且有审计、可以给安全组打标管理。传统硬件防火墙是网络边界的集中式设备，管的是整个网络出口；安全组是分布式的，贴着每台实例。生产上正确姿势是分层叠用：边界防火墙管南北向大策略，安全组管实例级细粒度，主机层再留 iptables 做主机自有策略，三层纵深。我只把 iptables 当兜底，主策略一定收敛在安全组，因为它是平台托管、有审计、不随重装丢失。
追问 2：端口不通，你的排查思路？
我按链路顺序查四层。第一层查安全组：确认源和目标各自所在安全组的入方向规则、协议端口、授权对象是否正确——大部分"端口不通"都是这里漏放行；第二层查系统内：机器本机的 iptables/firewalld 是否有额外规则，服务是否真的监听在目标地址和端口上，netstat 或 ss 看 LISTEN 状态；第三层查链路：源机器上 telnet 或 nc 探目标端口，中间加 traceroute 看断在哪一跳；第四层查中间设备：负载均衡监听配置、NAT 映射、K8s 的 Service/NetworkPolicy。我在移动云排查过 apiserver 健康检查异常的问题，最后就是 CLB 到新 master 的网段没有在安全组放行，补上组间授权立刻恢复。这套四层排查法能覆盖 90% 的端口类故障。
1.6 EIP 与弹性伸缩 ESS【理解】
1.6.1 EIP（弹性公网 IP）
知识点：EIP 是可独立申请、绑到 ECS/SLB/NAT 网关上的公网 IP，核心价值是 IP 与实例解耦——实例故障换机器，IP 跟着配置走不换；配合 NAT 网关做统一出口。注意点：绑了 EIP 的实例公网流量不经 NAT 网关 SNAT（优先级高于 SNAT 条目，生产上容易造成"出口 IP 不统一"的现象）。
标准回答（面试官问"EIP 什么时候用，注意什么"）：
EIP 的核心价值是把公网 IP 和实例解耦：IP 是独立资源，可以随时绑到 ECS、SLB 或 NAT 网关上，实例故障重建时 IP 不变，对外服务无感知；少量机器需要独立出入公网时直接绑 EIP，大量机器要统一出口时把 EIP 绑到 NAT 网关上做 SNAT。有个生产细节我特别在意：实例一旦绑了 EIP，它的出公网流量优先走 EIP，优先级高于 NAT 网关的 SNAT 条目——如果我有十几台机器本该统一从一个 SNAT 出口上网，某台被临时绑了 EIP，它的出口 IP 就变了，对有 IP 白名单的场景这就是事故。我在移动云项目里就是统一出口模式：业务 ECS 全部无公网 IP，出网走 NAT 网关 SNAT，需要对外暴露的只有 CLB 的 VIP。这套出口收敛的做法直接平移到阿里云同样成立。
1.6.2 弹性伸缩 ESS
知识点：ESS（Auto Scaling）按负载或计划自动增减 ECS 实例数量。核心概念：伸缩组（最小/最大实例数）+ 伸缩配置（用什么镜像/规格创建实例）+ 伸缩规则/触发器（定时、动态指标如 CPU>70%、固定数量）。扩出来的实例自动挂到 SLB 后端。价值：削峰填谷降成本 + 故障自动补齐。与 K8s 的 HPA 对比：ESS 扩的是整机节点，HPA 扩的是 Pod 副本。
标准回答（面试官问"弹性伸缩怎么用"）：
弹性伸缩解决两个问题：一是流量波峰自动扩、波谷自动缩省成本，二是实例故障自动补一台新的顶上。它的核心结构是三件套：伸缩组定义最小最大实例数，伸缩配置定义新实例从什么镜像和规格创建出来，触发规则定义什么时候扩缩——定时规则适合可预测的促销波峰，动态规则适合按 CPU 或负载阈值自动扩缩，扩出来的新实例会自动挂到负载均衡后端承接流量。我的实践视角是在 K8s 场景里对应理解：ESS 扩的是整机节点，相当于 K8s 的节点自动伸缩；Pod 副本级扩容是 HPA 干的事，两层是配合关系——大促场景节点层和副本层一起弹。我在移动云的 K8s 底座是固定规格包年包月，因为政企项目预算制、负载平稳，不需要动态伸缩，但我把 ESS 这套概念对标清楚了，需要时能直接落到阿里云上。
追问：什么业务适合弹性伸缩，什么不适合？
适合的三个特征：负载有明显波峰波谷、实例无状态可以随时增减、新实例能快速进入服务状态——典型是 Web 前端、API 网关层、计算型批任务。不适合的：有状态服务，数据库、消息队列这种数据不能随便迁的，扩容要走专门流程；启动预热很慢的服务，实例拉起来十分钟才能服务，弹性就失去了意义。我的判断标准是"从触发扩容到新实例能承接流量要多久，能不能跟上流量上涨速度"。移动云项目里我们业务是平稳型，就没启用伸缩，这本身也是一种选型——不为用而用。
1.7 登录与密钥对【理解】
知识点：
- 登录方式三种：密码（简单但不安全）、密钥对（SSH 公钥注入实例，私钥本地保管，推荐）、会话管理/Workbench（网页终端，阿里云侧免暴露端口）。
- 生产最佳实践：禁用密码登录、禁 root 直接登录、SSH 收口到堡垒机/跳板机、密钥定期轮换。
- Windows 实例：密码 + RDP，同样要走跳板。
- 移动云对标：云主机同样支持密钥对注入，项目里 master/worker 全部密钥登录 + 堡垒机审计。
标准回答（面试官问"云上登录安全怎么做"）：
我的做法是四条纪律。第一，全部密钥对登录，禁用密码——密码能被爆破，密钥私钥不落网络传输；第二，禁 root 直登，先登普通用户再提权，操作归属到具体责任人；第三，SSH 端口不暴露公网，登录收口到堡垒机或 VPN 网段，安全组里 22 端口的授权对象只写堡垒机所在网段，公网访问一律拒绝；第四，密钥定期轮换、离职即回收。我在移动云项目里就是这么管的：七台 K8s 节点全部密钥登录，安全组只放堡垒机网段访问 22 端口，所有运维操作经堡垒机留痕，这套配置在等保检查里是被认可的。阿里云还有个加分项是会话管理类能力，网页终端免开 SSH 端口就能进机器，连端口暴露的风险都省了，这个概念对标过来很有价值。
1.8 云盘（块存储）类型与选择【理解】
知识点：
- 云盘主流四档，从高到低：ESSD（企业级 SSD，分 PL0/PL1/PL2/PL3 性能等级，高 IOPS 低时延）→ SSD 云盘 → 高效云盘 → 普通云盘。IOPS 与时延逐档下降，价格也逐档下降。
- 系统盘 vs 数据盘：系统盘装操作系统（容量范围受限）；数据盘独立创建、独立挂载，支持卸载后挂到其他实例——这是故障恢复的关键机制。
- 选型依据：业务的 IOPS 与时延要求。etcd、数据库类选 ESSD；普通业务常规档位。
- 容量纪律：磁盘水位告警设 80%，磁盘打满是 Linux 最常见故障源。
- 移动云对标：云硬盘同样分档，我的 Prometheus 数据目录单独规划数据盘——机器重建时监控历史数据整盘迁走。
标准回答（面试官问"云盘怎么选型"）：
阿里云云盘从高到低主流是 ESSD、SSD、高效云盘、普通云盘四档，ESSD 里又分性能等级，IOPS 和时延逐档下降、价格也逐档下降。我的选型看业务对磁盘的两个要求：IOPS 和时延。我的经验锚点是 etcd——它对磁盘 fsync 延迟极其敏感，master 的系统盘我坚持 SSD 档位以上，这既是 K8s 部署的硬要求也是集群稳定性的地基；普通业务节点和监控节点用常规档位就够，不花冤枉钱。另一个我特别重视的机制是数据盘独立挂载：数据盘可以卸载再挂到其他实例，机器故障时数据盘摘下来挂到新机器，数据不丢——这是我做故障恢复预案的关键手段。我在移动云给监控节点的 Prometheus 数据目录单独规划了数据盘，就是为了机器重建时监控历史数据可以整盘迁走，监控曲线连续性不断档。最后是容量纪律：所有盘的水位告警设 80%，磁盘打满是 Linux 系统最常见的故障源，清理和在线扩容的预案都要提前想好。
追问 1：数据盘和系统盘分开有什么好处？
三条。一是数据生命周期独立——机器可以随时从镜像重建，数据盘挂回来数据不丢，重建不再等于灾难；二是容量独立扩容——数据盘支持在线扩容，不用动系统盘、不用重装；三是故障隔离——系统盘满了不影响数据盘上的服务，恢复路径清晰。我的生产习惯是业务数据和系统严格分盘，K8s 场景还要给容器运行时目录和 etcd 目录单独规划，这直接决定故障恢复的速度。
追问 2：磁盘打满的紧急处理？
先止血再治理：止血按"见效快"顺序——清理应用和系统日志（logrotate 或 truncate 当前日志）、清理包管理缓存、找超大临时文件；有数据盘余量的把大目录迁到数据盘；都不行走云盘在线扩容或加挂数据盘，多数云平台支持不重启扩容。治本是找增长根因——日志未轮转、应用写临时文件不清理、监控数据未过期——并把"磁盘水位 80% 告警"和"日志轮转策略检查"固化进巡检。我在移动云遇到过一次监控节点磁盘增长异常，根因是保留策略配置错了导致历史数据不过期，治理后把保留策略检查加进了周巡检。
1.9 ECS 生命周期与变配管理【理解】
知识点：
- ECS 状态：运行中/已停止；包年包月到期未续费会经历宽限期 → 停机 → 释放（数据可能丢失）。
- 变配：升降配大多需要停机重启（部分规格/操作支持热变更），必须规划变更窗口。
- 释放保护：开启后实例不能被误释放，防手滑。
- 生产管理三板斧：资源台账（到期时间/负责人/用途）+ 标签体系（环境/应用/负责人，用于筛选与分账）+ 平台事件订阅（实例重启/迁移等事件通知）。
- 移动云对标：我的项目资源台账 + 标签管理，续费提前一个月走审批。
标准回答（面试官问"云服务器生命周期你怎么管理"）：
ECS 生命周期管理我有两条生产红线和一套机制。红线一：变配要停机——升降配大多数场景要重启实例，所以规格调整必须规划变更窗口，变更前打快照兜底，这条纪律和传统虚机时代一样不能省。红线二：到期释放——包年包月实例到期未续费会经历宽限期、停机、最终释放，数据随之丢失，生产资源必须有到期台账。我的机制是三板斧：资源台账，每台机器的实例 ID、规格、IP、用途、负责人、到期时间全部登记，续费提前一个月走审批；标签体系，给实例打环境和负责人标签，用于筛选统计和分账；平台事件订阅，云平台的实例重启、故障迁移事件会推送通知，接到事件立即检查服务健康，不等用户报障。我在移动云项目里这套台账加标签是实际运行的，也是成本复盘的数据来源。阿里云这套机制完全同构：变配停机、到期释放、释放保护、事件通知都有对应能力。
追问 1：怎么管理几十台机器的到期和配置信息？
台账加自动化核对。台账字段就是上面那套，但光有台账会漂——所以每周用脚本核对台账与云平台实际资源状态，发现台账外资源（有人私开忘关的测试机）或临近到期资源，自动发提醒。配置层面靠标签：环境标签区分生产测试，应用标签区分业务，负责人标签定责，云平台按标签筛选资源和分账。我在移动云就是用标签做了分项目资源统计，这套方法到阿里云不变。
追问 2：平台通知"宿主机故障，实例将迁移"，你要做什么？
先评估影响面：这台机器上跑什么、是否多实例冗余、故障期间服务是否仍然可用；然后按预案执行：迁移期间实例会短暂不可用，确认负载均衡自动摘除、K8s Pod 自动漂移这些机制在位；迁移完成后立即做服务健康检查——节点状态、服务探活、关键指标回归正常才算闭环。更重要的功夫在事前：架构按"单机随时消失"设计，多实例打散、会话集中、数据不依赖本地盘，这样平台动作就是无感事件。我建议定期做单机故障演练验证这套假设，实测恢复时间作为架构可用性的证据。
1.10 镜像标准化与环境基线【理解——我的真实实践】
知识点：
- 基线内容六件套：OS 版本统一+补丁收口、内核参数预设（文件句柄/网络参数/swap）、时间同步（chrony）、容器运行时、监控 agent、安全 agent。
- 方法：一台"黄金镜像"调到满意 → 固化自定义镜像 → 全部节点从镜像创建 → 改基线=重做镜像+滚动替换。
- 版本纪律：基线改动先测试验证，重做镜像打版本号（如 baseimage-v1.2），存量节点滚动替换，绝不边改边发。
- 价值：新节点从创建到可用分钟级；故障重建分钟级；配置零漂移。
- 移动云对标：我的 7 台 K8s 节点同一镜像基线，K8s preflight 一次通过。
标准回答（面试官问"批量交付环境你怎么保证一致性"）：
我在移动云 K8s 项目里把镜像标准化做成一等公民。基线内容六件：OS 版本统一加补丁收口、内核参数预设——文件句柄数、网络参数、swap 策略这些 K8s 的硬要求、时间同步 chrony、容器运行时及版本、监控和安全 agent 预装。做法是先把一台机器调到满意，固化成自定义镜像——黄金镜像，其余节点全部从镜像创建，交付即基线一致，彻底消灭"每台机器手工配一遍"的漂移。基线的演进有版本纪律：改动先在测试机验证，通过后重做镜像打版本号，存量节点滚动替换，绝不边改边发——基线和代码一样要有版本管理。这套方法的价值在后半程显现：新节点加入集群从创建到可用只要几分钟，因为一切预置都在镜像里；故障重建同样分钟级。我在阿里云上对标过同样的做法：自定义镜像加版本管理，配合批量运维编排做滚动替换，机制同构，甚至工具链更完善。
追问 1：基线里哪些内核参数是 K8s 必调的？
必调四类：文件句柄——fs.file-max 和 ulimit，容器高并发的基础；网络参数——bridge-nf-call-iptables 打开让 iptables 能处理桥接流量、ip_forward 打开、conntrack 上限按集群规模调大；swap——K8s 默认要求关闭或 kubelet 明确容忍，关闭更稳；cgroup 由 systemd 管理确保资源限制生效。这些参数我全部固化进镜像，节点交付即合规，加入集群时 preflight 检查一次通过。参数为什么这么设我也讲得出：比如 bridge-nf-call-iptables 不开，Service 转发就会丢包，这是踩过一次就忘不掉的坑——所以我更坚信基线要一次做对。
追问 2：时间同步为什么是生产硬要求？
分布式系统靠时间戳排序一切：日志检索的时间过滤、证书有效性校验、数据库事务顺序、K8s 的证书和 token 都对时间敏感。节点间时钟漂移会导致证书验证失败、日志排序混乱、监控数据错位这类"看起来玄学"的故障。我的做法：全部节点指向统一时间源——云平台内网 NTP 或自建 chrony，配监控校验节点间偏移，超阈值告警。时间同步是"平时没人看、坏了全知道"的基础设施，必须在基线里一次配好，而不是出问题后补。
1.11 实操模板
模板 A：规格选型决策表（通用）
| 决策问题 | 判断依据 | 我的答案示例（移动云 K8s 底座） |
|---|---|---|
| 场景画像 | CPU 密集→计算型 c / 内存密集→内存型 r / 均衡→通用型 g | master 均衡小规格、worker 均衡中大、监控内存型倾向 |
| 容量基线 | requests 加总 + 单节点 ≤70% 水位 | worker 8C16G 为反推结果 |
| 高可用形态 | 控制面 3 副本仲裁、业务多节点打散 | master×3、worker×3 |
| 是否单独占资源 | 监控/中间件是否与业务混部 | 监控独立 4C8G |
| 预算约束 | 预算制项目锁总量 | 全包年包月固定规格 |
| 演进路径 | 扩容走横向加节点 | 加 worker 不升配 |
模板 B：ECS 上线前检查清单（少而精）
- 地域/AZ 确认（创建后不可跨地域迁移）。
- 安全组：角色分组、组间授权、22 端口仅堡垒机网段。
- 登录方式：密钥对 + 禁密码。
- 变更前快照纪律。
- 云监控水位告警（CPU/内存 70%）。
- 出网路径确认：无公网 IP 走 NAT SNAT / 或绑 EIP 并确认白名单影响。
- 主机基线核查：最小化安装、SSH 密钥登录、时间同步、日志与监控 agent 在位。
- 应急预案：单机故障处置路径、关键联系人清单、实测恢复时长在案。
1.12 章末自测（一句话答案）
- g/c/r 系列的 CPU 内存比分别约是多少？——g 通用 1:4、c 计算 1:2、r 内存 1:8。
- 规格名 ecs.g8i.large 中 8、large 分别代表？——8 是代际（越大越新），large 是 2vCPU 规格。
- 镜像和快照一句话区别？——镜像是造新机器的模板，快照是磁盘时点存档用于回滚。
- 安全组有状态是什么意思？——入方向放行的连接，其响应出方向流量自动放行。
- 安全组能授权 IP 之外的对象吗？——能，可以授权另一个安全组（组间授权）。
- 绑了 EIP 的实例出网还走 NAT SNAT 吗？——不走，EIP 优先级高于 SNAT 条目。
- ESS 伸缩组三要素？——伸缩组（最大最小数）、伸缩配置（镜像规格）、触发规则（定时/动态）。
- ESS 和 HPA 扩的东西有何不同？——ESS 扩整机 ECS 节点，HPA 扩 K8s Pod 副本。
- 我移动云 K8s 底座 7 台的规格分别是什么？——master 2C4G×3、worker 8C16G×3、监控 4C8G。
- master 用小规格的底气来自哪里？——控制面负载轻，高可用靠三副本 etcd 仲裁而不是单机规格。
- 主机加固七条清单口诀？——最小化、SSH 三禁、失败限制、sudo 审计、时间同步、日志集中、内核参数进镜像。
- 黄金镜像方法的本质？——把"加固与初始化"从逐台操作变成镜像属性，交付即合规、重建即恢复。
- vCPU 与物理核关系？——vCPU 是超线程线程，独享型承诺不超分性能稳定，共享型允许争抢。
- 新接手一批存量 ECS 的摸底四步？——资产面、安全面、健康面、基线面，产出风险分级清单。
1.13 高频追问补充包（连环追问应对）
追问 A：预留实例券和节省计划了解吗？
概念层了解。这类工具本质是"用承诺换折扣"：预留实例券预付一段周期绑定规格拿折扣，适合长期稳定的负载；节省计划是更灵活的承诺消费额换折扣。我的使用前提是负载水位已被证明长期稳定——先有数据再买承诺，顺序反了就是套牢。移动云项目是预算制包年包月，逻辑相同：预算买稳定。
追问 B：系统盘满了和内存满了，表现有什么不同？
磁盘满：写入类操作报错——日志写不进、数据库写入失败、甚至 ssh 登录异常，服务多表现为"部分功能失败"；内存满：触发 OOM killer 杀进程或 swap 频繁导致整体卡顿，服务表现为"变慢后消失"。排查命令也不同：df/du 查磁盘、free/top 查内存。我在移动云处理过一次磁盘增长异常，根因是监控数据保留策略失效——这类"慢性病"靠水位告警早发现。
追问 C：一台 ECS 的 CPU 突然 100%，你怎么定位？
三步：先 top 定位是哪个进程吃 CPU——业务进程、异常进程还是系统进程；业务进程就往应用层查——是不是流量突增、死循环、正则回溯，结合监控的流量曲线和发布记录判断；未知进程就要警惕——挖矿、木马常见特征是未知二进制和异常外连，这时升级为安全事件处理：隔离、取证、用主机安全产品扫描。定位的过程要用监控曲线佐证，不看曲线凭感觉猜，效率最低。
追问 D：单机故障演练怎么做？
选低峰期、挑一台非关键节点，主动制造故障——停服务、关机或拔掉健康检查端口，然后观察自动恢复链路是否按设计工作：负载均衡摘除、Pod 漂移、告警触发、恢复时间。全程记录时间线，演练后输出报告：哪些符合预期、哪些暴露弱点、改进项进待办。我在移动云项目把演练记录作为可用性证据保存，实测恢复时间写进应急预案，替换掉拍脑袋的 RTO 数字。
追问 E：规格里的"独享型"和"共享型"怎么区分？
独享型规格的 vCPU 不与其他租户争抢，性能稳定可预期，g/c/r 企业级系列都是；共享型存在 CPU 争抢和性能受限，价格便宜，只适合开发测试。我的纪律：生产一律独享型，测试可以用共享型省钱。突发性能 t 系列是积分制独享，要防积分耗尽被限流，生产也不用。
追问 F：跨可用区部署，你的 7 台机器怎么摆？
我的实操：master 三台尽量分散——etcd 仲裁天然要求故障域隔离；worker 三台同样分散，配合 Pod 反亲和让副本跨节点；监控单台但数据可迁。要注意云上跨可用区有内网延迟增加，一般 1-3 毫秒，对 K8s 控制面无感，对强同步数据库要评估。移动云项目里可用区分布是网络规划文档的一部分，评审过的。
追问 G：ECS 上能直接跑生产 MySQL 吗？
技术上能，架构上我不推荐：ECS 自建数据库要自己解决主备切换、自动备份、监控告警、审计合规，这些托管产品全部内置了。只有需要深度内核定制或成本极端敏感时才在 ECS 自建，而且必须把可靠性三件套——切换机制、备份体系、监控告警——自己补齐。我在自建 MySQL 环境做过主从和备份脚本，深知这套的维护成本；云数据库实例费换掉的是一整套 DBA 级自动化，多数情况是划算的。这也是我 RDS vs 自建三笔账的落地判断。
追问 H：镜像市场的镜像能用吗？
谨慎使用。镜像市场是第三方预装环境，方便但有三风险：来源可信度未知、组件版本可能老化、安全基线不可控。我的规则：生产环境用官方公共镜像加自定义基线，来路必须清晰——这也是等保审计的要求；镜像市场仅用于个人实验和快速原型。就算实验用，也要改默认口令、核对组件版本、跑一遍漏洞扫描。生产镜像的供应链安全不是小事，预装环境的便利性不值得用可审计性去换。
追问 I：不登录机器怎么批量执行命令？
云平台有批量运维通道——类似阿里云云助手的能力：在控制台或 API 向一批实例下发脚本执行，不需要 SSH 登录，执行结果集中回收查看，对应传统运维的 Ansible 场景。我的用法：巡检脚本、批量补丁、紧急止血动作走这类通道，效率高且免开登录端口；但纪律是批量能力越强误操作半径越大——批量命令必须走审批和记录，权限收敛到运维变更岗。批量通道是效率工具不是免检通道，这句话我会主动讲。
1.14 专题：容量管理与水位运营【理解】
知识点：
- 容量三层次：单机水位（CPU/内存/磁盘/连接数，80% 告警）→ 集群水位（节点 Allocatable 使用率、Pod 密度，70% 扩容线）→ 业务水位（核心接口吞吐与响应时间）。
- 运营节奏：日看曲线、周出报告、季度容量评审——评审输出"要扩的"和"可回收的"，两边都是钱。
- 扩容决策顺序：水位升高先排除效率问题（慢 SQL/连接泄漏/日志风暴）→ 确认业务增长 → 横向优先于纵向。
- 成本联动：水位与账单放同一份报告。
- 对标：我移动云项目周巡检+水位报告真实执行，扩容决策有证据链。
标准回答（面试官问"容量管理你怎么做"）：
我按三个层次运营容量。单机水位：CPU、内存、磁盘、连接数四项，80% 告警线；集群水位：K8s 场景看节点 Allocatable 使用率和 Pod 密度，单节点长期 70% 以上就触发加节点评估；业务水位：核心接口吞吐和响应时间对容量的映射——这是最接近业务真实的容量语言，机器水位低不代表业务容量够。节奏是日看曲线、周出报告、季度容量评审，评审输出两类结论：需要扩的和可以回收的，两边都直接关联成本。扩容决策有固定顺序：水位升高先排除效率问题——慢 SQL、连接泄漏、日志风暴都会伪装成容量问题，扩容掩盖效率问题是最大的浪费；确认业务增长后才扩，且横向优先于纵向，无状态扩容比升配平滑。我在移动云项目按这套节奏跑了整个周期：周报告里水位和成本放同一页，容量评审直接驱动 worker 扩容决策，从数据到决策有完整证据链。这套方法到阿里云同样成立，数据源换成云监控和账单中心而已。
追问 1：容量报告里你放哪些内容？
五块：资源水位汇总——每类资源当前水位与 90 天趋势；异常项清单——超阈值资源与处置状态，闭环管理；成本页——分项费用与环比，和水位对照着看；容量预测——按增长斜率外推到季度末，叠加已知业务事件修正；行动项——扩容、降配、回收清单带负责人和时限。报告的价值在于驱动决策，没有行动项的报告只是日记，这是我做报告的底线。
追问 2：容量怎么预测够不够？
基础方法是增长斜率：取历史 90 天水位曲线斜率外推，叠加已知业务事件——大促、新功能上线做修正。但我要防两类错误：线性外推忽略突变，所以业务输入必须叠加；告警线当容量死线——80% 告警线是响应时间不是容量极限，真实余量要按故障场景倒推：一台节点挂掉后其余节点接得住全部流量，这才是容量的硬下限。我集群规划时就是按 N-1 存活倒推的 worker 规格，这不是保守，是高可用的算术。
1.15 专题：ECS 安全加固与基线核查【理解】
知识点（主机加固七条清单）：
- 最小化安装：只保留业务必需组件与端口。
- SSH 加固：密钥登录、禁 root 直登、禁密码。
- 登录失败限制与来源收口（安全组只放堡垒机网段）。
- sudo 操作审计。
- 时间同步统一时间源。
- 日志集中（本地保留 + 上报）。
- 内核参数固化进镜像基线。
定位认知：云安全中心类产品管"检测与告警"，主机加固管"底子"——检测发现不了未加固的底子问题；两层都要有。核查自动化：基线扫描定期跑，漂移即告警。
标准回答（面试官问"Linux 主机安全加固你怎么做，云上有什么不同"）：
我的主机加固是七条清单：最小化安装，只留业务必需的组件和端口，攻击面先砍一半；SSH 三禁——密钥登录、禁 root 直登、禁密码；登录失败限制加来源收口，安全组只放堡垒机网段；sudo 全量审计，谁提权干了什么有记录；时间同步统一时间源，日志时间戳才可信；日志本地保留加集中上报，防篡改留证据；内核参数全部固化进镜像基线而不是逐台手配——这最后一条是云上做法和传统的最大区别：加固不是"运维在每台机器上做的事"，而是"镜像里自带的属性"，新机器交付即合规。云上的增量是检测能力：云安全中心这类产品提供入侵检测、漏洞、基线核查的自动化扫描，我的配合方式是"底子自己夯、检测交给平台"——基线扫描发现的漂移项当日整改。我在移动云项目里这套清单全部进了镜像基线和巡检，等保检查时基线核查记录是直接出示的证据。加固的核心思想是确定性：不确定的配置等于未知的暴露面。
追问 1：最小化安装具体怎么做？
三步：装系统时选最小化组件集，不装桌面和无关服务包；盘点确认——ss -tlnp 看监听端口逐个问"这是谁、为什么在听"，答不上的就关；服务自启清单白名单化，systemctl 逐个核对。之后靠基线固化防回潮——加固成果进镜像，新机器不会"长回来"。我在移动云节点初始化时做过完整盘点，监听端口清单写进部署文档，巡检时对照检查新增监听。
追问 2：发现某台机器基线漂移怎么办？
先评估影响再整改：漂移项是高危——SSH 策略被改、出现未知监听端口——按安全事件处理，先排查是否入侵；是普通漂移——有人临时改了参数没回退——当日回滚到基线并追变更记录。防复发靠两个机制：基线进镜像，重建即合规；基线扫描进巡检，漂移早发现。我的原则是"漂移不是故障是信号"——它说明变更流程有绕过的口子，复盘要把口子堵上。
追问 J：新接手一批存量 ECS，你怎么快速摸底？
我有一套摸底清单：先资产面——实例清单导出，规格、镜像、创建时间、标签、安全组归属，画出现状地图；再安全面——安全组规则全量导出审一遍，找 0.0.0.0/0 和高危端口暴露、密钥还是密码登录、EIP 挂载情况；然后健康面——水位曲线看近期负载形态，识别超卖和闲置；最后基线面——抽样登录核查补丁、时间同步、监控 agent 覆盖。产出一份摸底报告：风险清单分级加整改建议，作为后续治理的基线。这套方法我在接手移动云环境时用过，两天内把"不知道有什么"变成"每一台有主有账"。
追问 K：vCPU 和物理核是什么关系，超分会影响我吗？
云上 vCPU 通常是超线程线程，物理核由多个租户的实例共享调度，存在"超分"——同一物理核承载超过其线程数的 vCPU。主流云厂商对独享型规格承诺 vCPU 绑核不超卖，性能稳定；共享型则明确允许争抢。我的实践感受：独享型规格跑基准测试的稳定性可以接受，但极致性能敏感场景（高频交易、低延迟计算）要考虑裸金属或指定代际的独占方案。我的 K8s 节点用独享型规格，CPU 抖动可控，这个水位在监控上长期平稳。
追问 L：规格变更（升降配）的窗口怎么排？
按四步排：前置确认——该规格族是否支持在线变更、变更影响是闪断还是停机；窗口选择——业务低峰加变更公告，避开备份任务和大促日；兜底先行——变更前快照加回滚预案，变更失败回到原规格；变更后验证——服务探活、监控指标回归、变更记录归档。规格变更是"小变更、大影响"的典型：动作只要几分钟，但它重启的是生产机器，流程一步不能省。
参考资料（链接采集时间 2026-10）
以下链接均于 2026 年 10 月通过搜索与抓取核实可用：
- 云服务器 ECS 文档首页（实例、镜像、安全组、网络全目录）：https://help.aliyun.com/zh/ecs
- ECS 实例规格族的特点和指标数据（全部在售规格族与选型参数）：https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families
- 实例规格分类与命名（命名规则详解）：https://help.aliyun.com/zh/ecs/user-guide/instance-specification-naming-and-classification
- ECS 实例规格选型指导（场景化选型最佳实践）：https://help.aliyun.com/zh/ecs/user-guide/best-practices-for-instance-type-selection
- 安全组应用指导和案例（Web/远程/数据库/内网互通场景）：https://help.aliyun.com/zh/ecs/user-guide/security-groups-for-different-use-cases
- ECS 地域和可用区：https://help.aliyun.com/zh/ecs/user-guide/regions-and-zones
- 什么是弹性伸缩 ESS：https://help.aliyun.com/zh/auto-scaling/product-overview/what-is-auto-scaling
- 弹性伸缩 ESS 产品页：https://www.aliyun.com/product/ess