促销推荐：阿里云双11促销启动 2核2G3M办事器99元/年 原价续费不限新老使用者
“总不能让我这个上班才 1 周的新人来背锅吧？”
CloudFlare 身为全球最为知名的联网办事提供商之一，有时呈现中断是很普遍的事情，普通来说 CloudFlare 有各式各异的冗余策略，即便挂了作用范围也较为小。
但是前两天 CloudFlare 呈现的技术故障居然持续了 40 个小时，这应该是揭秘支付宝排行 CloudFlare 中断时间最长的一次事故，所以如今重启后 CloudFlare 火速亮相博客确认此事情的前因后果。
故障时间是从 2023 年 11 月 2 日 11:44 到 11 月 4 日 04:25，时间均为 UTC 时间，与中国时间有 + 08:00 时差，下面谈及的所有时间都是 UTC 时间。
直接缘由：机房供电故障、高压线接地故障
时间说明：11:44 UTC 换成太平洋时间 (下面谈及的写给老友的话：清醒文案这个资料中心位于美国俄勒冈州，使用太平洋时间) 是夜里四点前后。
本次中断事故作用了 CloudFlare 的很多商品，可是最严重的是 CloudFlare 控制台和确认办事，其中控制台就是客户登陆 CloudFlare 后用来操控的地方，确认办事则是提供日志和确认报表之类的。
尽管 CloudFlare 已然考虑到核心资料中心或许会挂掉所以做了冗余，但随着时间的推移，操控系统会变得越来越繁琐，所以冗余也不一定能生效。
依据 CloudFlare 说明，最直接的缘由是 CloudFlare 租用的 Flexential 资料中心呈现了一起打算外的供电维护，这导致资料中心的营收增长报道市电供应中断，但资料中心都有备用发电机，即便备用发电机没用那还有 UPS 不间断电源呢。
尽管 Flexential 的资料中心已然经由 Tier III 认证，可是在通用电气开展打算外的市电维护后，这个资料中心还是呈现了一大堆难题。
当呈现供电难题后 Flexential 开启了备用发电机开展供电，但并没有通知他们的客户，含有 CloudFlare，所以 CloudFlare 是不得知核心资料中心呈现了电力难题。
与最佳实践各异的是，Flexential 另外管理仅剩的一个市电设施以及内部的发电机开展供电，普通来说遇到这种状况应该直接切换为备用发电机供电025续航测试专题由于在市电供应难题呈现后，仅剩的这个市电设施也或许会被切断，而 Flexential 既没有通知客户也不得知为什么还要使用剩余的一个市电设施。
但这个市电设施就这么巧呈现了难题，到 11:40，也就是 CloudFlare 故障几分钟前 (这时候还没故障，由于备用发电机还在干活中)，剩余的这个市电设施的前置变压器呈现了接地故障，前置变压器的电源是 12kV 的高压电，高压电呈现了接地是很严重的难题。
呈现了高压电接地后电气操控系统以便确保电气设施的可靠马上自动开启停机保护，不巧的是这种停机保护也把所有发电机都给停了，于是这个资料中心的市电和备用发电机供电整体停掉。
万幸的是还有一组 UPS 电池，大约可以供电 10 分钟，假如在 10 分钟内市电或者发电机能重启岗位，那么 UPS 会停机，这样全部操控系统基础都不会呈现大难题。
但是这组 UPS 电池岗位 4 分钟后就呈现了故障，此时 Flexential 还没修好发电机，于是资料中心彻底断电了。
三件事阻碍发电机重新岗位：
第一，由于高压线接地故障导致电路跳闸，必须物理访问并手动重启各个设施；
第二，Flexential 的门禁操控系统也没有备用电池供电，所以出于离线模式，压根进不去(那最后估计是暴力方式进去的)；
第三，Flexential 资料中心夜班只有保安和一名岗位仅一周的技术人员，没有经验丰富的操控或电气专家。
由于发电机迟迟没有重启，UPS 电源在 12:01 彻底歇菜，此时全部资料中心都歇菜了，但 Flexential 依然没有通知他们的任何客户强调资料中心已然挂了。
CloudFlare 在 11:44 收到了第一个报警通知，这就是 UPS 电源岗位 4 分钟后呈现故障的时间，这时候 CloudFlare 意识到难题了，着手主动联系 Flexential 并期盼派遣 CloudFlare 自己在当地的工程师进入资料中心。
到 12:28 Flexential 总算向客户发出了第一条通知 (此时当地时间是凌晨 5 点前后)，强调资料中心遇到了故障，工程师正积极奋斗解决难题。
12:48 Flexential 总算重启了发电机，若干设施着手重启供电，但是更巧合的是 CloudFlare 所属的电源线路的断路器又损坏了，不得知这是由于接地故障还是浪涌导致的，亦或者说之前就已然坏了，如今察觉发电机重新启动后没法重启供电才察觉断路器坏了。
Flexential 于是又着手使用更换新的断路器，但由于损坏的断路器太多，他们还需要去采购，不得知这会儿 Flexential 有没有打电话让正睡觉的电气工程师进入了实地。但这个点去采购断路器估计有点难度。
由于 Flexential 无法告知重启时间，CloudFlare 确定在 13:40 启动位于欧洲的灾备站点，让办事先重启。
庞大的操控系统能够高效经由冗余站点重启那是不或许的，前提是你已然经过完完全全的评测，否则真正开展切换时肯定会遇到难题。
所以接下来就是 CloudFlare 自己的难题了。
CloudFlare 自己的难题：
直接缘由是资料中心难题，但还有间接缘由，那就是以便高效迭代 CloudFlare 允许团队高效革新，这意味着有一些新东西或许没有经过严格评测就启动了。
在故障转移过程中失利的 API 调用直接起飞了，由于失利的 API 调用太多，CloudFlare 不得不着手限制请求速率，直到 17:57 后灾备站点基础重启管理。
但还有些商品 – 一些较新的商品并没有完全开展灾备评测，所以若干办事依然不可用。
到 11 月 2 日 22:48 Flexential 那边总算换好了断路器并着手使用市电开展供电，此时忙得晕头转向的 CloudFlare 团队确定歇会儿，毕竟灾备站点如今能应对大若干办事的管理。
到 11 月 3 日着手 CloudFlare 着手重启 Flexential 资料中心，先是是物理开启联网设备，然后开启数千台办事器并重启办事，但这些办事器也需要重新参数，而重建治理参数办事器就花了 3 个小时。有些办事之间存在依赖，必须上游办事重启了才能使用，所以必须按照顺序开展操控。
参数办事器能用后工程师着手操控其他办事器，每台办事器重建时间在 10 分钟～2 小时之间，直到 11 月 4 日 04:25 全部办事才被重启。
对运维有兴趣的使用者提议阅读 CloudFlare 原文看看归纳出来的教训：https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/