OpenAI 史上最长宕机
上周四，OpenAI 旗下 AI 聊天机器人 ChatGPT 、视频生成工具 Sora 及其面向开发人员的 API 自太平洋时间下午 3 点左右起发生严重终端。
OpenAI 最近宕机频繁。上个月，ChatGPT 突发故障，导致服务中断近半小时，超过 19,000 人受到影响。OpenAI CEO Sam Altman 随后在社交媒体 X 上公开致歉。他表示，公 司在可靠性方面比以往有了很大的进步，但仍有许多工作要做。结尾他还加了一句：“根据 Similarweb 的数据，它现在是全球第八大网站”。
没想到只只一个月时间后 ，又发生了全球性质服务中断事件 。社交媒体上充斥着对 ChatGPT 宕机的各种反应，从玩笑、嘲讽到幽默、恼怒，各种情绪应有尽有。有人夸张的说， 全球学术界（留子教育版）倒退了 100 年。还有人调侃说应该试试“静电”的电脑维修方法： “你试过关掉再打开吗？ ” 另一个用户则对付费服务无法正常运行感到不满，“我每月支付 20 美元，却遇上这种服务中断的情况，简直让人抓狂！”这场“狂欢”背后，也折射出人们对 AI 工具的依赖程度日益加深。
经 OpenAI 团队排查发现，此番宕机并非源自安全事件或者近期产品发布，而是因周四 部署的用于收集 Kubernetes 指标的监控服务所引发。Kubernetes 是一款开源程序，可帮助 管理容器以及在隔离环境下运行软件的应用程序包与相关文件。
OpenAI 在事后报告中写道，“监控服务覆盖的范围非常广，因此这项新服务的配置无 意间导致… … 资源密集的 Kubernetes API 操作。我们的 Kubernetes API 服务器不堪重负，导 致我们的大多数规模 Kubernets 集群中的控制平面陷入瘫痪。”
OpenAI 提到，在客户感受到影响的“几分钟”内，公司就检测到了该问题；但由于必须 绕过不堪重负的 Kubernetes 服务器，因此无法快速实施修复。
该公司写道，“这是多个系统和流程同时发生故障，并以意想不到的方式相互影响的结 果。我们的测试未能捕捉到变更对于 Kubernetes 控制平面的影响，并且由于锁定效应，补 救措施的实施非常缓慢。”
OpenAI 表示，该公司将采取多项措施防止未来发生类似事件，包括改进登台发布、更 好地监控基础设施变化，以及采用新机制以确保 OpenAI 工程师在任何情况下都能访问公司 的 Kubernetes API 服务器。
而上周的这次故障，直接原因是他们又新部署了一套监控系统，导致 Kubernetes 控制 面临的负担加重。随后，由于控制面的故障（依赖于 DNS 和 K8S），无法直接回滚此次发 布，进一步放大了故障影响，导致长时间不可用。
鸬鹚科技自研监控Kubernetes 集群设备
而针对 OpenAI 团队所部署的监控 Kubernetes 集群的遥测服务，中国鸬鹚科技所研发的 luccitech 负载均衡设备亦有此项功能。
鸬鹚科技成立于 2015 年，团队重点技术自主研发积累近 20 年，掌握完整内核，具备完 整知识产权，可以自主迭代， 目标第三代负载均衡（云应用交付）和第四代（AI 结合） 的 产品， 目标真正替代 F5 。有丰富美国等海外中高等应用交付市场经验。俄乌交易制裁后， 在俄罗斯打败了华为、迪普、友商、山石网科等国内厂商，目前已经完全垄断俄罗斯高等 应用交付市场（客户：俄罗斯联邦储蓄银行，俄罗斯外贸银行等银行，原 F5 、Citrix 俄罗斯 总代，OCS ，B4COM 等），在美国中端市场有一席之地。
产品集四层负载、七层负载、全局负载、容器负载于一身，同时解决多数据中心、云外、 云内、容器入口的集中控制与管理的高等需求，F5 因为和Citrix 等充分竞争关系会去满足对
应海外的各种如多云联合认证（F5 APM）、多云业务质量监控（netflow 等）、云原生加固 （接管容器入口网络流量，实现四七层负载和全局负载等能力）等高级需求。
目前在全球市场能够达到或接近 F5 技术能力的公司除了鸬鹚和以色列的 radware 其余 都是美国公司。并且开源至大开源技术提供商 2019 年也被 F5 收购。我们所熟悉的 Kong 、 阿里的 Tengine 、腾讯的 STGW 、Cloudflare 的 Openresty 、Apache 的 APISIX 、各种 K8s 容器 的绝大部分等应用网关的开源项目的底层都是 友商 。因为 友商 底层能力限制很难稳定地 将很多功能 ALL-in-One 在一个内核中稳定实现并提供不断的迭代能力。
鸬鹚在全球化市场主要依靠四个方面的深度沉淀（底层、应用诊断和亲合度、自主迭代、 高等经验）
1 、底层工程能力（底层网络操作系统和硬件驱动深度优化的能力）
2 、应用适配并产品化能力（业务除了互联网外，其他行业也需要支持无法割裂）
3 、 自主迭代能力（修补漏洞+能力迭代+业务适配+新技术新架构支持：如分布式云原生等）
4 、高等行业经验（全球化金融中心网络等）
鸬鹚科技针对Kubernetes 负载解决功能
而对于 Kubernetes 负载解决功能，鸬鹚科技产品有着以下 11 项功能：
1 、支持所有四层到七层的 K8S 应用对外发布。
2 、K8S 服务自动发现，POD 自动发现，POD 自动同步。
3 、支持会话保持。
4 、HTTP/2 支持。
5 、高性能的 SSL 卸载，支持 TLS1.3。
6 、支持高级安全功能：WAF 和身份认证。
7 、支持流量管理：对每个 VS 的带宽，并发连接，新建并发进和 HTTP RPS 行限制，支持缓 存和压缩。
8 、支持高级路由：通过内容策略，实现用户访问对 POD 访问的优化。
9 、本身作为流量探针，提供 IPFIX 格式的流数据给第三方 netflow 分析平台，提供网络和应 用的实时统计数据，提供网络和应用的可视化。
10 、解决开发人员和网络人员在 K8S 环境下的接口问题。
11 、可同时提供针对 K8S 应用和传统数据中心应用的负载均衡。
鸬鹚科技关于容器业务质量监控测试关键技术能力
对于鸬鹚科技 luccitech 负载均衡业务质量监控数据点的监控粒度包括多项关键数据， 并可以从历史和实时两个角度分别进行统计数据和及时数据的监控。从应用监控角度，包括 应用状态、应用子节点状态、应用关联服务器状态，从网络监控角度，包括活动应用连接数 量、活动应用数据包数量、活动带宽数量、应用服务首响应时间等。从业务质量及故障诊断， 可以包括应用响应延时，网络抖动，应用健康度等。
鸬鹚科技产品业务质量监控数据点能够对每个分布式入口进行实时/历史的监控，对业 务的响应能力进行实时评估，对业务质量的健康度实时监控。对外部访问，也可以对相应的 DNS 访问信息进行监控统计。在满足监控能力的基础上，也可以在分布式入口处对应用的业 务质量进行诊断、控制、恢复、故障自愈等。
鸬鹚科技产品业务质量监控数据点能够优异适配 kubernetes 容器集群环境，可以自动 发现、自动监控纳管容器 pod ，并进一步对其中运行的应用业务进行监控。自动发现、自动 纳管的能力，满足了对容器集群变化的适应性。实时的监控能力，也可以满足容器集群以秒 级变化的时效需求。
鸬鹚科技针对K8S 服务的运行模式
对于此次 OpenAI 团队搭建的遥测服务所导致的 Kubernetes 控制平面瘫痪，使用鸬鹚产 品将不会出现此次问题，鸬鹚科技产品可对 K8S 服务进行负载均衡，并针对 K8S 服务支持两 种模式：
1 、Ingress：这是传统模式，和 NGINX/ HAProxy 的工作模式一样，只针对 HTTP 应用，通 过和 K8S 的 Ingress 对象进行同步，动态生成 VS 和 POD（映射到负载的 RS）
2 、Service：这是鸬鹚独有的功能，针对 K8S 的 Service 对象同步，支持所有四层到七层 的应用。
基于以上两种功能 ，将不会出现遥测服务配置意外在大规模集群中产生了大量 Kubernetes API 负载，导致控制平面不堪重负并破坏了基于 DNS 的服务发现能力的故障问 题。
鸬鹚科技针对类似OpenAI 此次故障预防措施
1、使用 luccitech 发布机制，更好地监控所有基础设施的变化， 以确保任何故障均不 会造成太大影响且可被及早发现。基础设施相关的配置变更，遵循稳健的登台发布流程；使 用 luccitech 负载所拥有的健康检查策略对服务工作负载和集群进行健康，确保始终保持健 康状态
2、当数据平面对控制平面施加过大压力时，确保仍可正常访问 API 服务器。鸬鹚将使 用应急机制，以保证工程师在任何情况下均可访问 Kubernetes API 服务器。
3、周期性查看 luccitech 负载的日志诊断信息，确保可以提前排查到 K8S 服务出现的 故障信息。