维护外包到底包哪些事
系统维护外包的范围，不同服务商给出的定义差别很大。在金边这12年，我接触过的客户里，有不少人最初以为维护就是“服务器别挂、网站能打开”，等真出了问题才发现根本说不清该找谁、该修哪一层。我们团队28人，每年交付约100个项目，维护需求通常从项目上线后第二个月开始冒出来。我们倾向于把工作内容分成四块：基础设施层、应用层、安全层和数据层。基础设施层负责服务器、网络与中间件的健康状态；应用层处理代码层面的热修复、异常日志分析；安全层覆盖漏洞扫描与入侵检测；数据层则管备份、恢复和归档。
这四块经常交叉。比如一次数据库慢查询，可能同时涉及应用层SQL改写和基础设施层的磁盘IO排查。如果外包团队只盯着自己熟悉的某一层，问题就会在层与层之间来回踢皮球。我们按这四块做了内部分工，客户不需要自己去判断“这个问题该找谁”——报过来，内部转到对应的人。
响应机制上，我们的做法是分级处理：服务完全不可用属于最高优先级，高级工程师需要立即介入；非关键功能降级这类问题，在两小时内进入处理流程。日常沟通走TG，分钟级响应，客户不需要等工单系统排半天。这个响应承诺不是写在合同里好看的，而是和监控告警直接挂钩——告警触发后自动通知到值班工程师，夜间也一样。能做到这一点，前提是团队有明确的值班轮换表，而不是靠某个工程师“随时待命”。
监控告警体系怎么搭才不吵
很多团队做监控，最后都栽在“告警太多”上。CPU瞬时飙高就发通知，时间一长没人看了，真正的故障反而被淹没。我们的做法是让监控服务于可观测性，而不是简单地检测“能不能访问”。实际操作中采用Prometheus + Grafana + Alertmanager的组合，同时采集三层指标：基础设施的CPU、内存、磁盘IO；应用层的请求延迟和错误率；业务层的用户并发量。
告警必须做收敛和分级。比如CPU使用率超过90%持续5分钟，先触发Warning级别；超过95%持续2分钟，升级为Critical并自动创建工单。这里的关键是“持续”这个条件——能过滤掉大量瞬时抖动，避免值班人员被无效通知刷到麻木。监控数据本身也有生命周期管理：原始数据保留7天，聚合数据保留30天，足够支撑后续的容量规划，又不至于让存储成本失控。我们在这套体系上叠加了AI运维，告警触发后先由AI做初步归因和日志摘要，再推送给值班工程师，减少人工翻日志的时间。AI归因在基础设施层告警上效果比较稳定，但应用层异常经常需要人看上下文，AI只能起到辅助定位的作用，不能替代判断。
漏洞扫描和补丁不能只扫不修
安全运维最容易出现的问题是扫描做得很热闹，修复却跟不上。我们的工具链分三层推进：Nmap做网络层扫描，OpenVAS处理系统层漏洞检测，OWASP ZAP对Web应用做动态分析。扫描频率按环境区分，生产环境每周全量扫一次，预发布环境每日增量扫，目的是在上线前就把问题拦下来。
补丁管理比扫描更考验执行力。我们坚持灰度发布：先在少量测试节点上验证补丁兼容性，确认没有性能回退，再分批推到生产环境，每批次控制在一定比例以内。这样即使补丁有问题，影响面也可控。遇到无法立即修复的高危漏洞，先用WAF规则做虚拟补丁临时拦截，然后尽快完成复测和正式修复。这个时效承诺是我们内部考核的硬指标，不是“尽量”。在金边这边做金融/交易类客户的系统时，漏洞修复的时效性尤其敏感，客户自己的合规团队也会定期抽查，修复记录和扫描报告都要留档。
备份和灾备不是“备了就行”
数据备份的底线是3-2-1原则：3份副本，2种不同介质，1份异地存放。但光有策略不够，执行细节决定恢复能力。我们的备份窗口避开业务高峰，具体时间点根据客户业务峰值来定，全量和增量备份按策略交替执行。灾备方案必须落到RTO和RPO两个数字上：核心业务系统要求RTO和RPO都控制在分钟级，需要主从复制加异地多活的架构支撑；非核心系统允许小时级恢复，冷备恢复即可。
灾备演练是最容易被忽略的一环。很多公司做了备份，但从来没真正恢复过，等真出事了才发现备份文件损坏或恢复流程跑不通。我们要求每季度执行一次容灾切换演练，记录实际恢复时间，和SLA里的承诺做对比。在金边这12年，我们见过太多客户第一次演练时才发现备份脚本早就静默失败——有个客户的每日备份任务因为磁盘写满中断了将近两个月，期间没有任何报错，直到演练时才发现最近能恢复的数据停留在两个月前。这种问题不演练永远不会暴露，等真出事就晚了。现在我们接手维护项目，第一周就会做一次恢复演练，先确认现有备份能不能用，再谈怎么优化。
性能优化和版本迭代的实操路径
性能优化通常从两个方向切入：数据库查询和缓存策略。慢查询的处理方式是用Explain分析执行计划，然后决定加复合索引还是改写SQL。热点数据则引入Redis Cluster做二级缓存，配合本地缓存减少网络开销。这些动作听起来常规，但每个系统的问题点不同，需要有人能快速定位瓶颈而不是套模板。东南亚这边的客户系统，很多问题不是技术架构导致的，而是业务增长太快——比如电商大促期间并发量突然上来，原本没问题的SQL开始拖垮整个库，这种时候需要的是经验判断而不是按文档排查。我们做过的电商类系统有成品，开箱即用，交付快，但成品系统在客户业务量上来之后同样需要针对性的性能调优，没有一套配置能通吃所有场景。
版本迭代必须有CI/CD流水线支撑：代码提交后触发单元测试和集成测试，通过后自动部署到Staging环境做冒烟测试，最后由人工确认发布到生产。回滚预案是发布流程的硬性要求，发布后短时间内如果发现异常，必须能快速回退到上一个稳定版本。没有回滚能力的迭代，本质上是在拿生产环境赌博。我们团队在交付新功能时，会把回滚脚本和发布脚本放在同一个包里，不会出现“上线成功了但回滚步骤要临时想”的情况。
定价逻辑与SLA条款设计
维护外包的定价模式一般有三种：固定月费适合需求稳定的系统；按工单计费适合偶发性维护需求；混合模式则把基础运维做成固定收费，增值服务按量计费。无论选哪种，SLA条款都要把关键指标写清楚。下面是一张我们建议客户参考的SLA指标表：
| 指标 | 目标值 | 违约赔偿 |
|---|---|---|
| 系统可用性 | ≥99.95% | 减免当月10%服务费 |
| P0故障响应 | ≤15分钟 | 每次延迟减免5%服务费 |
| 漏洞修复周期 | 高危48小时 | 超时按日抵扣服务费 |
| 数据恢复测试 | 每季度1次 | 未执行则扣除5%年费 |
这张表里的赔偿条款是我们建议客户在合同中明确的方向，具体比例和金额需要根据项目规模和客户预算来谈。实际谈判中，客户对赔偿条款的态度差别很大。有的客户看到“减免当月10%服务费”会觉得数字不够狠，希望把赔偿比例拉高；但反过来，赔偿比例拉高之后，服务商必然会把风险成本摊进报价里，最后总价反而上去了。我们一般会跟客户解释清楚这个逻辑，把赔偿条款定在一个双方都能接受的位置，而不是单方面“惩罚性”地堆数字。
合同里还有两条边界必须明确：数据所有权和知识产权归属。外包方不得将运维过程中接触到的业务数据用于任何其他用途，所有运维脚本、监控配置的知识产权归客户方。这些条款写进合同，才能避免后续扯皮。
我们自己的报价方式是面谈或TG详谈，按功能清单逐项评估，不搞一口价打包。付款先付30%，验收后结清尾款。系统bug修复免费，新增功能按工作量单独评估，不会混在维护费里含糊带过。支付通道这一块，由客户提供资源，我们负责对接，不提供支付通道。客户覆盖柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚，主攻电商、娱乐、金融/交易、地产、物流五个行业。开发周期上，小项目几天就能上线，大项目大约2个月交付，服务语言为中文。