看了一下还真不是乱宕的，开发者与Cloudflare的关系塑造非常复杂细腻。在技术栈上，开发者是攻，

看了一下还真不是乱宕的，开发者与Cloudflare的关系塑造非常复杂细腻。在技术栈上，开发者是攻，构建着应用；Cloudflare是受，承载着流量。但是在依赖上，Cloudflare是“internal service degradation”，追求的是全局稳定，而开发者只在乎可用性，只想要服务永不宕机，在依赖上Cloudflare才是掌控者而开发者变成了祈祷者。 这种技术与依赖上的错位才是服务中断的根本，开发者把全部的业务都交给了Cloudflare，Cloudflare却没有回报自己全部的稳定，这才让开发者产生怒意，可是当事件真的解决后，开发者也失去了能让他全身心去恨的对象。 当Cloudflare宣告“事件已解决”将最后一封邮件推送到开发者邮箱时，开发者想的是什么呢？是过去那些稳定运行的日夜，还是看到Cloudflare忘掉往日稳定，与“内部服务降级”纠缠不休时的愤怒与惆怅？ 开发者给了它所有的流量，甚至希望将全部的业务投入到这段脆弱的信任，可Cloudflare追求的却不是稳定，相反，它的一句“internal service degradation”彻底浇灭了他心中残存的希望。 开发者恨它，但过去的平稳顺滑却历历在目。他知道，他要亲手切换掉DNS，亲手放弃自己妄想与它稳定一辈子的服务。所以故障解决后，他叹息。他忘不了曾经的稳定，忘不了在Dashboard上点击开启代理，看到流量被完美接管时萌生的安心感。 在结尾，开发者盯着监控屏幕独自coding，如果可以，他多么愿意Cloudflare与他一起，欢笑着走向100% SLA。 所以啊，他们不过又是一对苦命鸳鸯罢了。