小米科技|阿里巴巴超大规模 Kubernetes 基础设施运维体系揭秘( 三 ) 耳机

1 集群全托管运维能力
当我们在运维大规模Kubernetes集群的时候，最深的感受就是：规模化既会给单个运维操作带来很大的复杂度，也会将单个运维操作的风险爆炸半径大大扩大。我们也是经常会被下面的问题挑战：
所有变更是不是都有变更风险管控？这么多的集群，这么多的节点（ASI单集群已经超过了上万节点），怎么做灰度稳定性风险最小？黑屏变更无法杜绝，如何把控风险？单个运维动作虽然不难，但是我们经常面临的是多个运维操作组合的复杂操作，系统如何方便的去编排这些运维操作？带着这四个问题，接下来我会详细介绍，我们如何在实践中不断抽象和优化我们的系统能力，并沉淀出目前对ASI全托管服务非常重要的稳定性系统能力。
统一变更风险管控
2019年，当我们刚成立ASI SRE团队的时候，就在探索如何把控变更带来的风险。当时的稳定性系统能力还非常弱，真的是百废待兴，新的SRE团队的同学都是从阿里云自研的Sigma调度系统各个子研发团队抽调出来的，所以大家对容器、k8s、etcd这些技术都非常精通，但是对如何做SRE ，如何做稳定性都是一脸懵。记得刚开始，我们在ASIOps系统（当时还叫asi-deploy）里接入ChangeFree变更审批都花了2～3周的时间。面对新的架构（Sigma -ASI）、新的场景（集团业务上云）和如此复杂、庞大的Kubernetes业务体量，我们也没有太多外界的经验可以借鉴。
当时我们想的是靠系统来做变更风险管控肯定是来不及的（集团业务全面上云已经开展起来，大量新的技术方案出来、大量线上变更），只能先靠“人治” 。所以我们就在整个ASI团队宣导任何变更都要让SRE审批，但是SRE并不能了解ASI所有技术架构细节，做完善的风险评估。为此，我们又开始组建“变更评审”会议，在评审会上邀请每一个领域的专家同学参与进行变更方案的风险评审。也是因为这个变更评审机制，帮助ASI在变更风险阻断系统能力非常不足的情况下稳定的渡过了那段“艰难”的时期。 ASI的变更评审会议也一直延续到今天，没有封网特殊时期，都会如期召开。也是那段时间， SRE通过参加每一次线上变更的审批，也沉淀了非常多的安全生产规则：

与此同时，我们开始将这些已经非常明确的变更风险阻断的规则实现到ASIOps系统中。刚开始是实现ASI底层系统架构层面的风险阻断能力，后来发现很多变更只通过底层ASI的指标/探测是没办法发现问题的，需要有一种机制能联动上层业务系统来触发业务层面的一些风险阻断规则判断，这样才能尽可能的确保我们的变更不会对上层业务带来影响。所以，我们开始在ASIOps实现变更风险规则库的管理，并实现了一种webhook的机制，来联动上层业务方的巡检检测/E2E测试。

ASI有了这套在线变更风险阻断系统能力之后，我们再也没有出现过封网期私自变更，变更不做灰度、不验证等这类触犯变更红线的行为。
变更灰度能力
从实际经验来看，每一次线上变更，不管我们前期方案评审多么仔细、多么严格，风险阻断做的多么完善，运维功能写的多好。代码上线之后，总是会出现我们“意想不到”的情况。对于已经知道的事情，我们一定会做的很好，可怕的是我们考虑不到的事情，这不是能力问题，现实架构他就是足够复杂。
所以功能上线一定要灰度。当然，我们还要保证变更动作的确定性，不能说张三变更是这样顺序去灰度的，李四同样的变更又是另外的一个灰度顺序。 ASI变更灰度能力，我们也是经过了好多次迭代。