线上运维一般是 SRE（Site Reliability Engineer）的职责。但是，架构师需要知道线上运维基本的概念和工作职责，同时需要在架构设计中预铺部分能力（可运维性）。

线上运维的职责是保证系统在线上的稳定性，并达到一定的 SLO（Service Level Objective）。

对于线上运维，一般从发布开始，包括线上运行状况的观测、线上事件的定位和解决。

发布

首先来聊一下发布。未来保障线上系统的稳定性，发布一定不能让变更后的服务接受 100%的流量。所以发布大致会有两种方式：

1. 通过蓝绿集群的方式，将发布和服务隔离开，通过引发流将流量逐步从老代码转向新代码。具体做法就分为蓝绿两个集群。初始状态两个集群都是老代码。发布前先将流量都切换到其中一个集群比如蓝集群；然后发布没有流量的绿集群，发布后逐步将流量缓慢引流到绿集群，并观察。绿集群发布后观察没问题再发布没有流量的蓝集群，再逐步将 50%流量引流回蓝集群。

2. 通过单应用的灰度：应用和应用之间没有影响，单个应用进行按照服务器的灰度发布，同时观察。有问题会滚代码，没有问题继续。

由于蓝绿发布的方式需要额外的引流模块，同时需要部署两倍容量的服务器，所以现在一般都考虑通过单应用的灰度来进行发布。

单应用的灰度，存在新老代码同时提供服务的情况，所以需要考虑上游的兼容性和应用自身内部的兼容性。

上游兼容性，意味着上游可以自由选择是调用新服务还是老服务。这个要求我们架构设计时做到新老服务的兼容：

1. 在上游没有完全切流时，不能下线老服务。

2. 在发布完成前，上游不能有新服务流量下来。这个可以通过开关控制报错，也可以由上游控制。

3. 新服务需要兼容老服务。

自身内部的兼容性，意味着新老服务的模型需要完全兼容。一般有两种实现方式：

1. 新老服务是统一的模型，新服务存储的模型老服务可以解析，反之亦然。这个需要有兼容性测试保证。

2. 新老服务是两套模型，分别进行处理。

运维

接下来说一下线上的运维，这里分成运行监测和事件处理两部分。

其中运行监测在前面的可观测性（https://xie.infoq.cn/article/7807cb9f502b44ec3d7c41c45）文中已经有详细描述。

事件处理最重要的需要有一个事件处理的流程，包括：

1. Who：发现问题后谁来主导处理、每个系统由谁来负责处理。

2. When：多久需要完成止血，多久需要完成数据恢复。

3. What：怎么进行快速恢复。这个对于不同的情况需要有详细的预案。所谓有备无患，没有预案的应急一般都无法快速恢复，同时比较容易出现次生故障。

4. How：怎么进行信息同步，怎么协调各方的处理（会议还是 IM）。

5. Why：事后需要分析故障产生的原因和改进。

流程和流程中需要的 IT 系统 SRE 负责建设，架构师需要参与到流程制定和应急的决策中。