云上应用先想清楚这三件事：资源、网络与可观测性

很多应用上云的第一步并不是写代码，而是先把部署环境想清楚。代码可以在本地跑通，但一上云就会遇到新的问题：资源选大了浪费、选小了扛不住峰值；网络默认能通，却分不清哪些入口应该对外开放；出了问题找不到日志，只能凭感觉排查。

本文围绕三个最容易被忽略、又最影响后续运维成本的方面展开：资源、网络与可观测性。内容偏向通用思路，适用于把 Web 应用、接口服务或定时任务部署到云上的场景，产品名称以华为云为例，思路也可以迁移到其他云平台。

一、资源：先算清楚，再选规格

1. 先分清四类资源

上云前先把应用的资源需求拆开看，而不是只看“需要几台服务器”：

• 计算：CPU 和内存。Web 接口、定时任务、数据处理任务对 CPU 和内存的需求差别很大，接口服务通常更看重并发下的响应，数据处理则更看重内存和磁盘吞吐。
• 存储：系统盘、数据盘和对象存储。数据库、日志和用户上传的文件应该分开存放，不要都挤在系统盘里。
• 网络带宽：对外提供服务的应用要看出口带宽，内部调用多、拉取数据多的应用则要看内网带宽。
• 弹性能力：流量是否有明显的波峰波谷，例如白天高、夜间低，或者活动期间突然放量。

把这四类需求写下来，再去对照云服务器的规格选型，比直接凭经验选一个“看起来够用”的规格更可靠。

2. 用峰值做设计，用平均值做成本估算

一个常见的误区是只按平均负载选规格。平均负载够用，不代表峰值时不会出问题；只按峰值选，又容易长期闲置。

更合理的做法是：

• 用历史峰值或压测结果确定单台实例需要扛住的上限；
• 用平均负载估算日常成本；
• 对有明显波动的服务，优先考虑弹性伸缩或按需计费，而不是长期锁定过高的固定规格。

例如一个白天访问量高、夜间很低的内部工具，如果长期按峰值配置，就是在为夜间的空闲时间付费。把无状态的服务做成可以横向扩展，峰值时多起实例、平时回收实例，往往比一台大规格实例更划算。

3. 给资源打标签，定期复盘

资源一多，最容易出现的问题就是“不知道这台服务器是干什么的”。建议从一开始就做好两件事：

• 按项目、环境和负责人打标签，例如项目名、生产或测试、归属团队；
• 每个月复盘一次：哪些实例长期 CPU 利用率很低，哪些磁盘长期没有增长，哪些带宽长期用不满。

复盘的目的不是一次省多少钱，而是让资源使用情况始终可见。看不见的资源，最容易在不知不觉中变成浪费。

二、网络：默认能通，不等于设计合理

1. 先划虚拟私有云和子网，再放应用

云上的网络建议按“隔离”和“分层”来规划：

• 不同项目、不同环境尽量使用不同的虚拟私有云（VPC）或子网隔离，生产环境和测试环境不要共用同一个子网；
• 把数据库、缓存等只供内部访问的组件放在私有子网，不分配公网地址；
• 对外提供服务的部分集中放在一个明确的入口，例如负载均衡，后面再接应用实例。

这样做的好处是出问题时影响范围可控，排查时也更容易定位是哪一层出了问题。

2. 安全组遵循最小权限

安全组的规则建议只放行确实需要的端口和来源：

• 对外只开放 80、443 等业务必需的端口，管理端口不要直接对公网开放；
• 内部调用只允许来自指定子网或指定安全组的访问；
• 每条规则都写清楚用途，定期清理已经不再使用的放行规则。

“先全部放开、以后再收紧”往往没有以后。权限一旦放开，就很难再确认哪些访问是真正必要的。

3. 内外流量分开走

应用访问对象存储、数据库等云服务时，优先走内网。这样既可以减少公网带宽占用，也能降低经过公网带来的不确定性。用户上传的文件、静态资源可以放在对象存储服务（OBS）上，再通过内容分发或负载均衡对外提供访问，而不是让应用服务器既处理业务逻辑，又承担大量静态文件的传输。

一句话总结网络部分：入口要收敛，内部要隔离，规则要可解释。

三、可观测性：上线前就把“看得见”做好

1. 日志、指标、告警三件套

很多系统不是没有日志，而是出问题时找不到日志。建议上线前就确认三件事：

• 日志：应用日志、访问日志和错误日志分别存放在哪里，保留多久，能不能按时间、请求编号或错误类型快速检索。
• 指标：至少覆盖 CPU、内存、磁盘、网络，以及业务层面的请求量、错误率和响应时间。只看 CPU 是不够的，很多故障先表现在响应时间或错误率上。
• 告警：对关键指标设置阈值和通知方式，例如磁盘使用率超过 80%、错误率持续上升、实例不可用时要能及时收到通知。

华为云的云监控服务（CES）可以采集云服务器、数据库、负载均衡等资源的运行指标，并支持设置告警规则。把告警接进来之后，值班人员才能在用户反馈之前发现问题。

2. 告警要分级，不要什么都报

告警太多和没有告警一样糟糕。如果每一条告警都要人工处理，人很快就会对告警麻木。建议把告警分成两级：

• 需要立即处理：服务不可用、错误率突增、磁盘即将写满；
• 需要关注和跟进：CPU 持续偏高、慢请求比例上升、磁盘增长趋势异常。

前者直接通知到人，后者可以先汇总、定期复盘。告警规则也要定期调整，长期不触发的规则要检查是不是阈值设得太松，频繁误报的规则要检查是不是条件设得不合理。

3. 留一个最小可用的排查路径

上线前可以自己先演练一次：如果某个接口突然变慢，应该先看什么？

一个可用的排查顺序是：先看监控指标确认是计算、内存、磁盘还是网络到了瓶颈，再看应用日志确认是哪个接口、哪类请求出了问题，最后看依赖的数据库或下游服务是否正常。

如果这条路径在平时演练过，真实故障发生时就不需要临时去找日志位置、确认监控地址，能把更多时间花在解决问题上。

四、上线前的检查清单

把上面三部分收敛成一张清单，上线前逐项确认：

这张表不需要一次全部做到满分，但每一项都应该有明确的答案，而不是“大概没问题”。

结语

上云的难度很少在“能不能跑起来”，而在“跑起来之后能不能稳定、可控、可复盘”。资源选得合理，成本才不会失控；网络划得清楚，故障影响才可控；可观测性做得扎实，问题才能被及时发现。

如果正在准备把一个应用部署到云上，不妨先花半天时间，按资源、网络、可观测性这三个方面写一份简单的设计说明。写清楚的过程，本身就是一次很好的检查。等真正上线之后，再根据实际运行数据回头调整规格、规则和告警，这套设计才会越来越贴合业务的真实情况。