大型网站开发流程

去年双十一，大型某头部电商平台在零点峰值时，网站订单系统每秒要吞下58万笔请求。流程这个数字背后，大型不是网站一台超级计算机在扛，而是流程一套从代码提交到上线部署被拆成二十多个环节的流水线。任何一个环节卡住，大型零点那几秒就会变成灾难现场。网站

写代码只是流程最不起眼的一步。真正决定网站能不能活过流量洪峰的大型，是网站代码写完之后的事。我见过一个团队花了三个月打磨推荐算法，流程上线当天却发现数据库连接池只有50个，大型连内部测试的网站并发都撑不过去。问题不出在算法，流程出在没人提前算过连接池该配多大。

需求评审阶段就得把“非功能需求”钉死。日活多少、峰值QPS、数据一致性要求、可接受的故障恢复时间——这些数字不写进文档，后面所有技术选型都是瞎猜。有个做在线教育的朋友，初期用户不到一万，技术负责人坚持上微服务，结果运维成本吃掉大半预算，团队一半时间在修服务间调用超时。架构不是越先进越好，是越匹配当前阶段越好。

开发环节有个容易被忽略的细节：分支管理策略。用Git Flow还是Trunk-Based，直接决定上线频率。我参与过一个金融项目，坚持用Git Flow，每次发版要合并四个分支，光解决冲突就耗掉两天。后来换成主干开发加特性开关，上线从两周一次变成一天三次。工具没变，流程变了，效率差出十倍。

测试不是“开发完再测”。单元测试覆盖率低于60%的模块，集成测试阶段必然爆雷。有个做SaaS的团队，接口测试全过了，上线后用户上传Excel却频繁超时。查了两天才发现，测试用的都是几百行的小文件，生产环境用户传的是几万行的报表。测试数据失真，比不测更危险。

部署环节最怕“手动操作”。任何需要人登录服务器敲命令的步骤，迟早会出错。用Ansible还是Kubernetes，用Jenkins还是GitLab CI，选哪个都行，关键是整个流程能一键回滚。去年有个社交App更新版本，运维手动改了Nginx配置，少写一个分号，服务挂了四十分钟。四十分钟对社交产品意味着什么，做这行的人都清楚。

监控和告警是上线后的眼睛。但告警太多等于没有告警。我见过一个系统配了三千条告警规则，值班同学直接开静音。有效的做法是分层：业务指标（订单量、支付成功率）走电话告警，系统指标（CPU、内存）走IM通知，日志异常走邮件日报。别让运维被噪音淹没。

容量规划得按“最坏情况”做。双十一的流量不是均匀分布的，前十分钟可能吃掉全天30%的请求。提前做全链路压测，从CDN到数据库逐层加压，找到第一个瓶颈就扩容，然后继续压。这个过程通常要反复五六轮。有个团队只压到网关层就停了，结果数据库先挂了。

最后说个反直觉的观察：大型网站开发流程里，最贵的不是服务器，是沟通成本。一个需求从产品到开发到测试到运维，每过一手信息就衰减一次。用Confluence写文档不如拉个群当面吵十分钟。流程越复杂，越需要给“非正式沟通”留空间。那些跑得快的团队，往往不是工具多先进，是人与人之间废话少。