summerfield-336672_640.jpg
背景
在三个月前，我们就已经搭建了一套生产环境，运行在K8s上。只不过，它没有承载流量。像下图：
1.png
昨晚，我们将正式流量切到K8s环境，就变成了以下情况：
2.png
实际上，这个切换过程，只要一分钟，因为域名解析的生效只需要一分钟。但是，我们原计划是当晚十点进行的，结果却是，我们第二天凌晨四点才回家。本文尝试将当晚的经过记录下来，并找到改善点。
事发当晚
以下是迁移的大致经过：
原计划三月二十九号晚上十点切换流量，全量验证一个小时，十一点下班。
然而晚上九点左右，测试人员在类生产（staging）环境发现了一个严重的Bug。
开发人员发现问题，讨论方案。然后经过多次修改代码并重新构建代码，最部署到测试环境。测试人员在测试环境进行一次全量测试。一次全量测试需要一个小时。
我们的办公室在园区的一楼，这个点方圆一公里内的蚊子似乎都找上了我们，不断扑面而来。我们只好把空调温度调到最低，妄想使用低温驱赶走蚊子。
Bug修复已经是凌晨两点。运维人员开始修改六个域名的解析，指向K8s环境。同时，也将VM环境的负载均衡关闭。这个过程只花了一分钟。当看到有流量进入K8s环境，测试人员开始测试。
测试不到十分钟，测试人员反馈ABC功能不可用。所有人介入。
通过查日志，让测试人员多次运行测试脚本，运维发现ABC功能的流量并没有流入到K8s环境。运维人员开始思考，如果流量没有流入到K8s环境，那是去哪里了呢？运维人员用力搅着像浆糊的大脑。
“不会是第三方请求到了老的环境吧？”运维突然想到。运维打开已经关闭了的VM环境的负载均衡，发现ABC功能的流量真的跑进来了。现回头来看，我们当时忘记检查DNS解析环节了。
这个时候已经是凌晨三点多。运维让测试人员测一下。结果，ABC功能意外的好了。我们也管不了那么多。赶紧进行全量测试。
在测试过程中，我们分析了ABC功能为什么工作。原因是ABC功能不涉及跨环境，所以它能正常工作。
这个时候，运维人员还认为是第三方服务的问题。大家的大脑也都糊了一样，没有深究。毕竟ABC功能能正常运行，如下图：
3.png
凌晨四点，全量测试通过。经过七小时的奋战，我们的系统终于云原生。
但是，我们并没有庆祝。因为，此刻我们不需要香槟，不需要欢呼，我们只需要床和枕头。
然后，早上八点多，我们接到客诉，说他家设备的KK功能无法使用了。大家的第一反应是和此次的迁移有关。经过排查，该设备的KK功能在一个月前就应该有问题了，只不过恰巧在我们迁移完成的当天发现。
大家都捻一把汗，为什么这么巧。虚惊一场。
也是在第二天，切换当晚提前回家的同学（我们提前让两位同学回家，第二天好值班），找到了当晚ABC功能无法正常工作的原因。
具体改善点
- 构建速度需要提高：开发人员，在测试环境每修改一次并发布到测试环境的总时间是七分钟左右。而代码编译打包过程就花了6分钟。从Gradle切换到Bazel，构建速度应该可以提高十倍。但是，需要准备好Bazel的推广。
- 运维过程中的手工操作必须要结对：这次的ABC功能不可用，是运维人员粗心导致。
- DNS的切换需要自动化，同时也要加上监控。
- 所有人都应该能自助运行测试脚本。在事故中，能更好发挥所有的人能力。
后记
3月到4月之间是我们评职级的时间，所以，这次迁移给我们的压力很大。但是，我们还是抗住了压力。我深知保持原地不动并不能让我们的系统更具反脆弱能力。
此次经历，也说明另一个问题，将系统可用性作为KPI是双刃剑。
今天已经是迁移到K8s上的第三天晚上，出现了两次小事故，基本能很快解决，因为我们提高了系统的可观测性。
网友评论