346
Suscriptores
Sin datos24 horas
+47 días
+430 días
Archivo de publicaciones
https://www.openwall.com/lists/oss-security/2026/10/15/5 拿到了CVE-2026-99999这样的靓号，让人羡慕。
今年前三个季度：
2026-09-29 FreeBSD-SA-26:69.udp 2026-09-29 FreeBSD-SA-26:68.openssl 2026-09-29 FreeBSD-SA-26:67.ktls 2026-09-29 FreeBSD-SA-26:66.jail 2026-09-29 FreeBSD-SA-26:65.kqueue 2026-09-29 FreeBSD-SA-26:64.sysvsem 2026-08-25 FreeBSD-SA-26:63.posixshm 2026-08-25 FreeBSD-SA-26:62.tty 2026-08-25 FreeBSD-SA-26:61.openssl 2026-08-25 FreeBSD-SA-26:60.ppp 2026-08-25 FreeBSD-SA-26:59.mac_do 2026-08-25 FreeBSD-SA-26:58.sound 2026-08-25 FreeBSD-SA-26:57.unix 2026-08-25 FreeBSD-SA-26:56.hwpmc 2026-07-29 FreeBSD-SA-26:55.elf 2026-07-29 FreeBSD-SA-26:54.sysvsem 2026-07-29 FreeBSD-SA-26:53.ktrace 2026-07-29 FreeBSD-SA-26:52.if_wg 2026-07-29 FreeBSD-SA-26:51.ktimer 2026-07-29 FreeBSD-SA-26:50.kqueue 2026-06-30 FreeBSD-SA-26:49.iconv 2026-06-30 FreeBSD-SA-26:48.compat32 2026-06-30 FreeBSD-SA-26:47.linux 2026-06-30 FreeBSD-SA-26:46.ktls 2026-06-30 FreeBSD-SA-26:45.audit 2026-06-30 FreeBSD-SA-26:44.posixshm 2026-06-30 FreeBSD-SA-26:43.tcp 2026-06-30 FreeBSD-SA-26:42.unlinkat 2026-06-30 FreeBSD-SA-26:41.libalias 2026-06-30 FreeBSD-SA-26:40.zfs 2026-06-30 FreeBSD-SA-26:39.execve 2026-06-30 FreeBSD-SA-26:38.jail 2026-06-30 FreeBSD-SA-26:37.vm 2026-06-09 FreeBSD-SA-26:36.ldns 2026-06-09 FreeBSD-SA-26:35.openssl 2026-06-09 FreeBSD-SA-26:34.vt 2026-06-09 FreeBSD-SA-26:33.unbound 2026-06-09 FreeBSD-SA-26:32.elf 2026-06-09 FreeBSD-SA-26:31.arm64 2026-06-09 FreeBSD-SA-26:30.linux 2026-06-09 FreeBSD-SA-26:29.ip6_multicast 2026-06-09 FreeBSD-SA-26:28.capsicum 2026-06-09 FreeBSD-SA-26:27.sound 2026-06-09 FreeBSD-SA-26:26.ktls 2026-06-09 FreeBSD-SA-26:25.thr 2026-05-20 FreeBSD-SA-26:24.cap_net 2026-05-20 FreeBSD-SA-26:23.bsdinstall 2026-05-20 FreeBSD-SA-26:22.libcasper 2026-05-20 FreeBSD-SA-26:21.ptrace 2026-05-20 FreeBSD-SA-26:20.fusefs 2026-05-20 FreeBSD-SA-26:19.file 2026-05-20 FreeBSD-SA-26:18.setcred 2026-04-29 FreeBSD-SA-26:17.libnv 2026-04-29 FreeBSD-SA-26:16.libnv 2026-04-29 FreeBSD-SA-26:15.dhclient 2026-04-29 FreeBSD-SA-26:14.pf 2026-04-29 FreeBSD-SA-26:13.exec 2026-04-29 FreeBSD-SA-26:12.dhclient 2026-04-21 FreeBSD-SA-26:11.amd64 2026-04-21 FreeBSD-SA-26:10.tty 2026-03-26 FreeBSD-SA-26:09.pf 2026-03-26 FreeBSD-SA-26:08.rpcsec_gss 2026-03-26 FreeBSD-SA-26:07.nvmf 2026-03-26 FreeBSD-SA-26:06.tcp 2026-02-24 FreeBSD-SA-26:05.route 2026-02-24 FreeBSD-SA-26:04.jail 2026-02-10 FreeBSD-SA-26:03.blocklistd 2026-01-27 FreeBSD-SA-26:02.jail 2026-01-27 FreeBSD-SA-26:01.openssl
Repost from Tombkeeper
你买了辆新车，开车带一家人出去玩。到了郊外，停下车，关闭发动机，看着车外，阳光和风都刚刚好。这时候四岁的孩子从后座爬到你身上，和你玩闹。此刻你感觉人生是圆满的。这时候孩子猛的一脚蹬到方向盘，把方向盘蹬断了。
你吓了一跳，先是奇怪方向盘怎么一蹬就断了，然后又感慨万幸现在不是在行驶过程中。
你跟朋友谈起这件事。有个朋友说方向盘不是用来蹬的，你开了一路车，方向盘用着也都很正常，被蹬断属于不当使用，这不怪方向盘。另一个朋友说，在交通事故中，撞击到方向盘是司机最主要的受伤原因，这个方向盘能被蹬掉，那么在发生事故撞击到司机身体时也就会被撞断，能减少司机受到的伤害。
你听了他们的话觉得都很有道理，但总觉得方向盘能被蹬断好像不太对，于是你决定以后离这两个朋友远点。
via tombkeeper
有一天，公司决定重构十年前留下来的核心系统。
技术总监在会上只提了一个要求：「新架构一定不能有单点故障（Single Point of Failure，SPOF）。」资深工程师点点头。「明白。」
于是，原本只有一台服务器、一个数据库、一套程序的系统，正式开始现代化改造。第一个月，团队把单体架构（Monolithic Architecture）拆成了微服务架构（Microservices Architecture）。
原本一套程序，变成了四十七个服务。
用户登录有 Authentication Service，权限验证有 Authorization Service，用户资料有 User Service，订单有 Order Service，支付有 Payment Service，通知有 Notification Service。
甚至连「获取用户名」这样一件小事，也需要经过 API Gateway 调用 User Service。
领导看完架构图，非常满意。
「很好。这样任何一个服务挂了，都不会影响整个系统。」
工程师没有回答。
因为他正在思考：如果 Authentication Service 挂了，用户到底要怎么进去使用那些「没有受到影响」的服务。
第二个月，架构师认为服务之间直接相互调用，耦合度太高。
于是引入了 Kafka。
大家开始谈论事件驱动架构（Event-Driven Architecture）。
OrderCreated。
PaymentCompleted。
InventoryReserved。
ShipmentCreated。
每件事情都变成了一个 Event。
以前，工程师想知道「订单为什么没有发货」，查一下数据库就行。
现在要先问：
「你知道这笔订单的 Correlation ID 吗？」
不知道。
「那 Trace ID 呢？」
也不知道。
「Message Key 呢？」
没有。
「Partition 呢？」
不知道。
工程师沉默了三秒。
「那我们从 Kafka 第一个 Offset 开始找吧。」
第三个月，大家发现四十七个服务部署起来实在太麻烦。于是引入 Kubernetes，简称 K8s。
从此，公司的技术文档里开始出现许多以前没人用过的单词：
Pod。
Deployment。
ReplicaSet。
Service。
Ingress。
ConfigMap。
Secret。
Namespace。
StatefulSet。
DaemonSet。
领导看到 Replica 设置成 3，非常安心。
「很好，同一个服务有三份，就算挂一个也没问题。」
结果三个 Pod 全跑在同一台 Node 上。那台 Node 一挂，三个 Replica 一起消失。
架构师看了一眼 YAML。
「没关系，我们加 Pod Anti-Affinity。」
第二天，Kubernetes Scheduler 因为条件设得太严格，一个 Pod 都调度不上去。
领导问：「所以现在有几个 Replica？」
工程师回答：「理论上三个。」
「实际上呢？」
「零个。」
第四个月，系统开始变慢。
团队决定引入 Redis 做缓存（Cache）。
原本查一次数据库需要 200 ms。
加了 Redis 之后，只需要 5 ms。
所有人都非常高兴。
直到有一天，有人修改了用户资料。
数据库里是新的。
Redis 里是旧的。
另一个服务自己的 Local Cache 里又是更旧的。
领导问：
「到底哪份数据是真的？」
后端工程师回答：
「要看你问的是哪台。」
于是，团队开了三个小时的会，专门讨论 Cache Invalidation。
会议最后的结论是：
「先把 TTL 设成五分钟。」
第五个月，因为系统已经有四十七个服务，大家开始不知道错误究竟发生在哪里。于是引入了一整套可观测性（Observability）系统。
Prometheus 收 Metrics。
Grafana 画 Dashboard。
Loki 收 Logs。
Jaeger 做 Distributed Tracing。
Alertmanager 发告警。
现在，系统只要慢 100 ms，Grafana 上就有十五张图一起变色。
领导看着满墙的监控大屏，非常感动。「我们现在是不是什么问题都能看到了？」
SRE 回答：
「看得到。」
「那问题在哪？」
「不知道。」
「那这些图是干什么的？」
「证明真的有问题。」
第六个月，公司要求做到高可用（High Availability，HA）。
于是数据库做 Primary-Replica。
Redis 做 Cluster。
Kafka 做 Cluster。
Kubernetes 做 Multi-Node。
Ingress 做 Load Balancing。
机房做双线路。
服务跨 Availability Zone 部署。
技术总监再次强调：「我们绝对不能有任何单点故障。」
大家花了半年，把所有看得见的 Single Point of Failure 全部消灭。
最后，整个系统拥有：
47 个 Microservices。
186 个 Pods。
12 台 Kubernetes Nodes。
9 台 Kafka Brokers。
6 台 Redis Nodes。
4 台 Database Servers。
3 组 Load Balancers。
2 个 Availability Zones。
完整的 CI/CD Pipeline。
完整的 Monitoring。
完整的 Distributed Tracing。
完整的 Auto Scaling。
架构文档有两百多页。技术总监非常满意。
正式上线那天，他站在办公室里宣布：「各位，经过半年的努力，我们终于做出了一个没有单点故障的系统。」
全公司鼓掌。
五分钟后。
整个系统全挂了。
不是某一个服务。不是某一个机房。也不是某个 Database。而是所有服务同时失联。
技术总监冲进机房：「Kubernetes 挂了吗？」
「没有。」
「Kafka？」
「正常。」
「Database？」
「正常。」
「Redis？」
「正常。」
「Load Balancer？」
「正常。」
「网络呢？」
「也正常。」
技术总监更紧张了。「那到底哪里坏了？」
资深工程师看着屏幕，沉默了很久。
然后说：
「DNS。」
原来早上有人修改 DNS 配置时，多敲了一个字符。
所有服务其实都还在正常运行。
所有 Pod 都是 Healthy。
所有 Database 都是 Healthy。
Kafka 没有任何异常。
Redis Cluster 完全正常。
CPU 使用率正常。
Memory 正常。
Network 正常。
只有一个小问题：大家找不到彼此。
技术总监看着那份号称「完全没有 Single Point of Failure」的两百页架构文档，问了一句：
「我们不是已经把所有单点故障都消除了吗？」
资深工程师想了想。
「没有。」
「还有什么？」
工程师指了指 DNS。
「我们只是把单点故障藏得更深了。」
会议室安静了十秒。
技术总监又问：
「那 DNS 可以做高可用吗？」
工程师回答：
「可以。」
「那就做。」
一年后，公司拥有了两套 DNS、三层 Load Balancer、两个 Kubernetes Cluster、跨区 Kafka、跨区 Database Replication，以及一套连原作者自己都不敢改的 Terraform。
技术总监再次召开会议。
「现在总没有单点故障了吧？」
这一次，没有人回答。
因为上周，唯一知道整套架构究竟如何运作的那位资深工程师离职了。
技术总监环顾会议室。
「文档呢？」
有人回答：
「有。」
「在哪？」
「公司的 GitLab。」
「很好，那打开。」
工程师操作了一下。
「打不开。」
「为什么？」
「GitLab 的 SSO（Single Sign-On）依赖公司的 Authentication Service。」
技术总监停顿了一下。
「那 Authentication Service 怎么修？」
「部署方法写在 GitLab 里。」
「那 GitLab 怎么修？」
「Kubernetes 的配置也在 GitLab 里。」
「那 Kubernetes 呢？」
「Terraform。」
「Terraform 在哪？」
「GitLab。」
整个会议室再次安静下来。
最后，新来的工程师小心翼翼地问：「所以现在真正的 Single Point of Failure 是什么？」
所有人不约而同地看向资深工程师原来的位置。
桌子已经空了。
旁边只剩下一张便利贴。
上面写着：
「如果你需要看这张纸，说明 Disaster Recovery Plan 已经失败了。」
技术总监看完之后，沉默了很久。
最后，在下一季度的技术战略汇报中，新增了一页：
「2027 年核心架构改进计划」
第一项：「降低 Bus Factor。」
第二项：「建立完整的 Knowledge Transfer 机制。」
第三项：「不要再让所有文档的登录方式，依赖一个只有登录文档之后才能知道怎么修的登录系统。」
「在分布式系统里，真正困难的不是让每一台机器都不会坏，而是当每一台机器都正常的时候，找出为什么整个系统还是不能用。」
投稿日期：2026 年 10 月 4 日 17:30（CST）
给博客做个站内全文搜索：纯前端离线倒排索引的设计与取舍
https://blog.delphij.net/posts/2026/10/sitesearch/
polyxslt：给浏览器补上一个轻量级 XSLT 处理器
https://blog.delphij.net/posts/2026/09/polyxslt/
