对生产稳定的一些思考

这里结合自己负责的过保迁移项目、之前的生产经验，和处理过的一些case记录一下自己的一些思考。

首先3个前提

• 原则1: 牢记安全生产红线。安全生产红线的意义在于
  • 提变更的时候更慎重的审视自己的变更方案，也可以让更多的人交叉review；
  • 信息广播，有助于变更执行人评估是否有交叉影响的变更；
  • 一旦出问题，也能够根据变更列表迅速关联到根因。违反安全生产红线的变更，神仙都救不了。
• 原则2: 笔记本+手机时刻带着。“上线时长的80分位在5分钟左右，超过10分钟上线的故障，其中1个发生在节假日、1个发生在9点之前，可见非工作时间的值守规则很重要” 。时刻备战状态是一个技术人的尊严。
• rule 3: 避免surprise。好的运营方案能够补救技术上的不足。尤其在面对客户的操作，公告、外呼能够有效的提高客户对阿里云操作的谅解，降低PR和舆情风险。

接下来正式开始

1. 所有操作均需要得到客户的知晓和允许。这个也是底线一般的原则，没有得到客户的允许而操作服务器（在法务许可之外的），是超级低级的错误。
2. 数据备份、数据备份、数据备份。重要的事情说多少遍都不为过，操作客户的实例或系统或数据时，提醒打快照。数据千金不换。
3. 交叉review/double check。某次网络团队进行网段资源回收，由于仅靠ping探测手段判断是否有业务，探测结果不准，导致客户实例网络中断。合理的做法应该是
   • 1 通过arp探测来判断是否有业务；
   • 2 和业务方做交叉review，从流程上确认是否有在使用。如果资源找不到责任人怎么办，走标准流程变更，设置静默期，出问题了要快速恢复。
4. 灰度策略。灰度策略的意义在于用尽可能小的样本验证方案的稳定性，将可能的影响面降低到最低。切不可以为了灰度而灰度。好的灰度策略应当包括：
   • 1 灰度样本很重要，梳理出关键路径，确定灰度case选取的维度；
   • 2 流程闭环，预检、post检查、回滚策略、正确性检查等；
   • 3 合理的灰度节奏。
5. 熔断/及时止损。在规模化迁移过程中，一旦出现问题，需要有快速的手段及时止损。最好有批量化的工具，可以做的更好。
6. 容量水位。曾经发生过一次短期内过保迁移量太大，达到存储水位触发关闭售卖，导致无法创建磁盘，售卖实例生产失败，触发P4等级故障。容量评估在任何操作前都需要评估好，如果针对这个具体的case而言，则有更好的解决办法，比如虚拟库存，把过保迁移和正常售卖的库存隔离开。
7. 线上常态化运行测试case。2018年11月存储某版本发布，跨az迁移磁盘会失败。但线上一直没有碰到这种场景，于是一直也没有发现问题。直到2周后线上的客户实例碰到了这种场景，妥妥的失败。这种情况可以通过在线上常态化运行测试case来解决。与chaos monkey不同，猴子是一种随机的故障注入，通过微小而可控的破坏验证系统的稳定性，发现问题；而这里类似于探针，通过运行正常的e2e case来验证服务的可用性，在某些时候确实能帮助我们早于客户之前发现问题。
8. 限流/过载降级。瑶池任务并发度100，超过的则要排队；批量磁盘迁移单个集群有并发度限制并且可调整；
9. 雪崩效应。雪崩效应是指系统中微小的服务不可用被逐步放大，最终导致整个服务不可用。近期发生的某服务client不断重启将server打挂，更多的client重启。改进方案可以参考如下两个场景：1）我在服务器部门的时候，记得当时对服务器的出厂配置是要求上电不自启动的，或者配置成随机时间启动，为的就是防止IDC断电又上电，瞬间大量服务器启动对整个供电系统的脉冲影响。2）随机缓慢增加重启的间隔，并设置重试次数直至超时不再重启。当然server端的限流和降级也是有效的手段。