概述

上线规范的作用时尽可能避免（减少）因线上变动造成的事故。主要分为上线前、上线中和上线后的注意事项。

上线前

提前通报

提前通报服务的上下游业务方。上线变更时，可能会造成上下游服务的异常，提前通报能提到提醒作用。一旦出现问题，上下游业务方能及时定位到问题原因，起到及时止损的作用。

Checklist

Checklist可以分作两部分：常规和专项。常规是指一些通用的指标，如cpu利用率，内存使用率，错误日志和核心业务指标；专项是指本次代码变更点，上线后需要及时确认的。通常前者和稳定性的关系更大，因此上线过程中需要优先关注前者，在保证稳定性的前提下，在去验证后者。

Code review

Code review包含两个部分。一是代码更新的作者在上线前需要仔细review代码，防止将和本项目无关的代码带上线。Review代码时需要逐行验证，防止因跳行导致的验证不充分。二是需要其他rd帮助review，从另一个角度读代码可能会发现一些作者没有考虑到的问题。

预案

主要是切流预案和降级预案。切流预案是针对多节点部署的服务，当因上线节点出现故障时，可以及时切流止损。降级预案是在效果有一定受损得情况下，优先保障服务的可用性。事先准备好相关预案，一旦有事故发生，按照流程操作，可以做到不至于慌乱。

上线中

分级发布

先发布预发节点，验证无误后再发布线上节点

对于一个节点，先发布一台服务，验证无误后再发布该节点的其它服务。

当一个节点完成所有服务上线后，也需要double check。存在部分情况，因为未上线的服务服务还能工作正常，导致业务暂时无感知。因此当节点上所有服务均完成上线后，也是一个重要的验证点。

对于有多机房节点的服务，一天只能只发布一个节点，这样即使新上线的节点出问题，可以快速切流止损

服务质检

前面有提到上线可能会导致下游故障。服务质检的作用就是去自动监控下游的核心指标，当该指标在上线过程中出现异常时，强制停止上线，并及时通知上线人。

服务质检的作用是将需要人去关注的重要指标变动交给了监控服务去做，减轻了上线者的负担

指标观察

这一步最为重要。指标主要分为物理指标和业务指标，物理指标是指cpu, memory, network, disk的利用率；业务指标是指每个业务最为关注的和业务强相关的指标，如搜索的成功率，推荐的品类多样性，请求返回的延迟和错误率等等。服务上线最容易导致这些核心指标发生异动，一旦不能及时回滚将造成严重的线上事故。

上线后

先回滚（切流），再定位问题

Rd一个常见的习惯是线上出问题后先去把问题分析清楚，再解决问题。但线上最为核心的是稳定性。及时我们没有查清楚问题，只要是怀疑和线上有关系，我们就要立即操作。要么按照预案操作，要么回滚。先保证稳定性，及时止损；然后再定位问题，解决问题。顺序一定不能搞错！