真的很重要
接入层网关，承接了所有对外服务的入口流量，其重要程度不言而喻。稍不注意就出搞个故障，如果不幸赶上黑天鹅，全站故障，那就是整个公司都下线了。
从事网关开发这么些年，也经历过一些故障，全网下线的经历过两次，都是上市公司，故障时间小时级。这种级别的故障，半小时内就会惊动公司最高层，现场排查恢复的压力可能而知。而且，故障恢复之后，还有各种漫长的复盘和改进讨论。
一场故障搞下来耗时耗力，所以稳定性是第一位的。简单谈谈我的想法
bug 与 故障
首先，bug 并不等同于故障，bug 常有，而故障不常有。
对于一个复杂的软件，bug 是很难完全避免的。有时候，面对一个长期稳定运行的软件，人们容易误以为没有 bug 了，其实不然，可能只是规模还没到，还碰到触发 bug 的场景，亦或是，软件多个模块之间的配合，刚好能够让 bug 不容易出现而已，比如这张经典的图
当潮水褪去，才能发现原来 bug 一直在裸泳 …
虽然 bug 一直都有，但是大部分系统通常还是正常运行的，因为系统稳定运行并不要求完全没 bug，而只需要当前用到的场景下，没有 bug 也就够了。
实际上，我们认为很稳定的系统，可能就像以上面的图那样在运行着的，看起来很魔幻，可是现实世界有时候就是这么魔幻，且真实…
接下来，从两个视角来聊聊（仅仅是两个视角，并非特指两个工种）
开发视角
开发会认为，最重要的是，产出优秀的代码。
从软件架构，模块化设计，到测试用例的设计，甚至到编程语言的选择，等等，这些是产出优秀代码应该多关心的。
核心就一点，让代码尽量少 bug，就是开发对稳定性最大的贡献。
另外，即使故障发生时，开发视角最关心的是如何定位 bug，甚至来个 hotfix 直接修复上线就更好了。
所以，在故障发生时，最希望是能够保留现场，甚至可以上线 debug …
运维视角
运维视角最关心一个问题，为什么原来是正常的，现在就有问题了。
也就是说，运维并不关心 bug 是什么，只关心是什么触发了 bug，只要触发条件没了，那就能恢复正常。
以运维视角来看，变更是一切故障的起因，这里的变更，包括了软件版本更新，软件配置更新，软件使用场景的更新。
所以，运维会构建一套系统来追踪这些变更，当故障发生时，通过时间线来推导是哪个变更产生的，以便回滚恢复。
简单点说，故障发生的时候，运维第一反应是，看看哪个变更最可疑，回滚掉 …
变更三板斧
为了能否快速 & 精确的回滚，运维会有一整套完善的系统，从变更发布，到监控报警，甚至自动回滚止血。
其中，对于发布变更，最核心的就是变更三板斧：可灰度，可监控，可回滚。
- 可灰度
一方面可以控制影响范围，另一方面也可以作为对比因素，用于故障到变更的的推导，比如故障的发生范围，跟变更的灰度范围是否一致。 - 可监控
有两层含义，一是：如果产生了故障，至少可以知道；二来，变更产生了某些变化，也需要能被看到 - 可回滚
这可是救命操作，如果确认是某个变更产生的故障，不能回滚，或者因为回滚产生另外的故障，那就是个大写的悲剧了。
接入层网关的变更
就接入层网关而言，很关键的一个点，配置变更的管理，同样需要三板斧。
因为软件版本更新的三板斧能力，通常在运维系统中就已经有很好的支撑了。
而以网关目前的演进状态来说，也就是抽离了控制面这个单独的概念，来控制网关的运行配置的状态，配置变更是很频繁的操作，而且可能会有多个的控制面来控制配置。这种情况下，配置变更产生故障的风险就高很多了。
也是目前演进状态中，可能容易不被重视的一个点，而且以常见的网关软件架构，也是比较难做到的一个点。
至于接入流量的变更，这种很难被纳入运维系统管理了（除了新接入业务流量），因为变更来源是来自外部，甚至可能就是突然来一波黑客攻击。
这种可能需要系统具备快速的流量拆分调度能力，能把“坏流量”摘出来，尽量减少影响面，也缩小问题范围。
黑天鹅
运维系统完善，三板斧做得好，可以大幅降低故障风险。不过，黑天鹅要来，谁也挡不住。
如果发生了大面积故障，一通操作猛如虎，一看还是没有恢复，能咋办呢？
这种时候，另外开一条支线，拉上开发直接 online debug，没准也能提供一些有用的线索，比如某些流量特征会导致故障，可以指导快速切分“坏流量”；甚至来个 hotfix，直接一把修复了。
当然，online debug 也不是好干的活，也需要一套的系统来支持，生产环境通常是最小化的，缺少很多开发依赖的 debug 工具。
那么，作为开发，紧急 online debug，我想可能需要的两类工具：
- 快速看到当前软件运行全景图的，比如 CPU 火焰图工具；这样可以有一个大致的定性认识
- 快速动态加 debug log，在某些关键路径上，动态打印一些信息；这样可以确认/排除某些原因，从而确认/缩小问题
这里必须得说，OpenResty XRay 在这方面是走得很前沿的商业产品
如果只论技术方案的话，基于 ebpf 的工具链，比如 bpftrace，个人感觉会比较有前途
保持敬畏之心
稳定性是系统的一部分，需要用系统性思维来解决，也没有银弹。
需要的是，保持敬畏之心，敬畏每一个环节，每一个视角；学习新技术，有思考，有总结，学而时习之~