Unknown

golang的问题

Sun, 19 Apr 2026 00:00:00 +0000

一句话概括，golang是一种高性能网络编程语言，仅此而已。

零值陷阱

type AllBasicTypes struct {
	B    bool
	Str  string

	I8   int8
	I16  int16
	I32  int32
	I64  int64
	I    int

	U8   uint8
	U16  uint16
	U32  uint32
	U64  uint64
	U    uint
	Up   uintptr

	By   byte // uint8
	Ru   rune // int32

	F32  float32
	F64  float64

	C64  complex64
	C128 complex128
}

// var v AllBasicTypes —— 各字段为零值：false、""、0、0.0、(0+0i) 等

golang为了规避Java的空指针引用而引入了默认零值的设计。这导致了在设计程序的时候，遇到零值要小心处理。比如上述这个结构，变量声明 var v AllBasicTypes 之后访问 v.B会得到false，v.U8 会得到 0。

那么在实际的应用场景，就无法判断B到底是false，还是未赋值。解决的办法是另外加一个字典标记，或者使用 *bool 布尔指针这种奇怪的类型。

import (
    "fmt"
    "time"
    "google.golang.org/protobuf/types/known/timestamppb"
)

func main() {
    // 错误示例：使用 time.Time 的零值
    var zeroTime time.Time  // 或者 time.Time{}
    protoTs := timestamppb.New(zeroTime)
    
    // 序列化时就会报错
    data, err := proto.Marshal(protoTs)
    fmt.Println(err)  // 报错：proto: Google.Protobuf.Timestamp.Seconds out of range -62135596800
}

而时间的零值导致的proto Timestamp溢出是隐形的错误。我们可能在底层的模型代码里面使用 time.Time 定义了某个字段，但在顶层API获取的时候发现反序列化失败。

弱网问题

在弱网环境，golang几乎是一种非常难用的编程语言。内置的语言包非常薄弱，经常需要go get，而国内 go get 则必定绕不过网络代理。

即便网络问题解决了，第三方的菱形依赖你也解决了。但在弱网情况下，golang还是很难用。一份源代码，下载到本地，开发+编译绕不过 vscode + golang插件 + go mod tidy。而且golang的vscode插件不是开箱即用的，安装之后还需要再安装 dlv 等工具。

兼容性问题

兼容性问题分两部分：操作系统兼容和语言向前兼容。

golang的不向前兼容

很多人不知道，其实golang在这么多年迭代的过程中出现过不向前兼容的变更：

Go 版本	变更类别	具体不兼容变更描述	控制方式 / 备注
Go 1 (2012)	语言 & 标准库重大重构	pre-Go 1 (r60 等) 到 Go 1 的巨大变更：包路径调整（e.g. encoding/asn1）、os.Error → error、time 包重构、map/delete 语法、rune 类型引入、map 遍历随机化等。	使用 `go fix` 工具辅助迁移。这是历史上最大的一次 breaking update。
Go 1.1	语言 & 平台	整数除常量零变为编译错误；64 位平台 int/uint 变为 64 位；部分 net/syscall 结构体/签名变更。	直接影响编译或运行行为。
Go 1.5	运行时	GOMAXPROCS 默认从 1 改为 CPU 核心数（调度行为变更）。	性能/并发相关，可能影响旧假设。
Go 1.21	运行时 & panic	`panic(nil)` 或 `panic(untyped nil)` 现在 panic `*runtime.PanicNilError`（之前无 panic）。	`GODEBUG=panicnil=1` 恢复旧行为（或 `go 1.20` 及更早）。
Go 1.21	包初始化	包初始化顺序算法精确定义（按 import path 排序），之前为未定义行为。	依赖隐式初始化顺序的代码可能受影响。
Go 1.22	语言（for 循环）	for 循环变量每个迭代创建新变量（之前所有迭代复用同一变量）。闭包捕获行为改变。	由 `go.mod` 中的 `go 1.22`（或更高）启用。旧模块保留旧行为。这是常见迁移点。
Go 1.22	net/http.ServeMux	ServeMux 支持方法前缀（如 `POST /path`）、通配符 `{name}` 等新模式；路径转义处理变更。	`GODEBUG=httpmuxgo121=1` 恢复 Go 1.21 行为。
Go 1.22	go/types	类型别名现在用 `Alias` 类型表示（之前等价于原类型）。	`GODEBUG=gotypesalias=0`（默认在 1.22）；1.23 起默认 1，将在 1.27 移除。
Go 1.22	TLS & crypto	默认最小 TLS 版本提升至 1.2；移除部分 RSA key exchange 和 3DES 等 cipher（后续版本）。	多个 GODEBUG（如 `tls10server=1`、`tlsrsakex=1`、`tls3des=1`），部分将在 1.27 移除。
Go 1.23	time 包	time 包创建的 channel 变为 unbuffered（同步），影响 `Timer.Stop` 等正确使用。	`GODEBUG=asynctimerchan=0` 恢复旧异步行为（将在 1.27 移除）。
Go 1.23	net/http	`http.ServeContent` 在错误响应时移除某些 header。	`GODEBUG=httpservecontentkeepheaders=1` 恢复旧行为。
Go 1.23	x509 & TLS	拒绝负序列号证书；`Leaf` 字段填充变更等。	多个 GODEBUG（如 `x509negativeserial=0`、`x509keypairleaf=0`）。
Go 1.24	x509	x509 证书策略（Policies）字段使用变更。	`GODEBUG=x509usepolicies=0` 恢复旧行为。
Go 1.25	运行时 & nil 检查	某些 nil 指针 dereference（e.g. `f, err := os.Open(); f.Name()` 当 f==nil 时）现在严格立即 panic（之前某些情况延迟）。	严格遵守规范；无 GODEBUG 控制，需修复代码（先检查 err）。
Go 1.25+	平台支持	移除对旧 OS 支持（如 macOS 11、32-bit windows/arm）；Wasm 导出指令变更。	平台/移植相关，非 API 但影响构建。

在高版本golang中解析旧版本golang生成的证书，因为 x509部分的变更，可能出现解析失败的问题。

而语言不兼容的另一方面体现，是工具集的割裂。这在开发proto相关的时候就特别明显。

# 核心基础
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

# 数据验证
go install github.com/envoyproxy/protoc-gen-validate@latest

# HTTP 网关
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway@latest

# API 文档
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2@latest
go install github.com/google/gnostic/cmd/protoc-gen-openapi@latest

你安装了这么多的工具集。但当你切换到低版本的golang语言，就会发现 dlv 甚至都运行不了。你需要找各种兼容当前版本的golang，最后在一堆工具集中迷失自我。

实际情况并不允许你一直使用最新版本的golang，所以最后行为链路会变得非常奇怪：

在window使用path路径切换到低版本golang –> 调试工具集不支持 –> 重新寻找支持当前版本的golang工具集ABCD –> A弄好了，弄B，B弄好了找C，然后一直循环往复。

最后你忘了其实你只是想要跑个程序，却一直把时间浪费在 go install xx version。

window不适合golang开发

而在window环境做golang开发是一个痛苦的事情。很多第三方工具，golang环境甚至无法编译成功，go install 就是一个笑话。最后为了方便，golang开发大家都会尽可能地使用Linux/mac 系统。

选择编译缺失

Go 没有 C# / C 系那种预处理器级的条件编译：同一套语法里用 #if 把整段代码从未选中的构建里直接抹掉。Go 里更接近的做法是 build tags（//go:build）配合不同文件，或 runtime.GOOS 等运行时分支，语义和手感都不一样。若你从 C# 过来，会明显感到这种「选择性编译」能力的缺失。

C# 里常见用法大致如下（仅示意）：

// 1) 按内置/项目符号裁剪代码块（DEBUG 由 Debug 配置自动定义）
#if DEBUG
    System.Diagnostics.Debug.WriteLine("只在 Debug 构建中存在");
#endif

#if MY_FEATURE
    // 需在 csproj 的 <DefineConstants> 或编译参数里定义 MY_FEATURE
    DoExperimentalStuff();
#endif

// 2) Conditional：未定义符号时，调用点会被编译器剔除（方法本身仍可存在）
using System.Diagnostics;

class App
{
    [Conditional("VERBOSE")]
    static void VerboseLog(string msg) => Console.WriteLine(msg);

    static void Main()
    {
        VerboseLog("这条在未定义 VERBOSE 时不会产生调用指令");
    }
}

对比之下，Go 要在「不同构建」下换实现，通常靠文件级条件（//go:build linux）或链接时注入，而不是在同一函数体里用 #if 折叠半页代码。

如果不用这种标签去做选择编译，那除了使用环境变量切换之外，我暂时想不到别的解决方案。

后记

写到这里，我突然想问自己一个问题：AI时代分享技术还有意义吗？

回想刚入行的时候，网络同行前辈的建议是写个博客记录整理一下遇到的问题和解决方案。至今这个习惯已经断断续续坚持了10年。

现在是AI时代，人学习信息技术的速度已经完全跟不上AI。但批判性思维让我不太受AI的影响，我始终把AI当成辅助计算的手段。

毕竟最终的决策风险要我本人承担。这么多年的风风雨雨，告诉我只有把命运掌握在自己手中，才不会被外物牵着走。

所以我觉得，写技术博客本身没有意义。思考本身就是意义，归纳是一个过程，文章只是一个供后人怀念的结果。

In one sentence: golang is a high-performance language for network programming—nothing more, nothing less.

Zero-value traps

type AllBasicTypes struct {
	B    bool
	Str  string

	I8   int8
	I16  int16
	I32  int32
	I64  int64
	I    int

	U8   uint8
	U16  uint16
	U32  uint32
	U64  uint64
	U    uint
	Up   uintptr

	By   byte // uint8
	Ru   rune // int32

	F32  float32
	F64  float64

	C64  complex64
	C128 complex128
}

// var v AllBasicTypes — zero values: false, "", 0, 0.0, (0+0i), etc.

To avoid null-pointer-style issues like in Java, golang uses default zero values. That means you must be careful with zero values when you design programs. For the struct above, after var v AllBasicTypes, v.B is false and v.U8 is 0.

In real scenarios you cannot tell whether B is false or simply unset. The usual fixes are an extra map for “was it set?” or the odd choice of a *bool pointer.

import (
    "fmt"
    "time"
    "google.golang.org/protobuf/types/known/timestamppb"
)

func main() {
    // Bad example: zero value of time.Time
    var zeroTime time.Time  // or time.Time{}
    protoTs := timestamppb.New(zeroTime)
    
    // Serialization fails
    data, err := proto.Marshal(protoTs)
    fmt.Println(err)  // e.g. proto: Google.Protobuf.Timestamp.Seconds out of range -62135596800
}

A zero time.Time quietly blows up proto Timestamp handling. You might define a field as time.Time deep in the model, then fail deserialization at the top-level API.

Weak networks

On a poor network, golang is awkward to use: the standard library is thin, you constantly need go get, and in China go get almost always means fighting proxies.

Even if the network and third-party diamond dependencies are “solved,” golang is still painful under weak connectivity. You check out one repo and still cannot escape vscode + the golang extension + go mod tidy for dev and build. The vscode extension is not turnkey either—you install it, then still install dlv and more.

Compatibility

Compatibility splits into OS-level compatibility and forward language compatibility.

When `golang` is not forward-compatible

Many people do not realize golang has shipped backward-incompatible changes over the years:

Go version	Category	What broke	Mitigation / notes
Go 1 (2012)	Language & stdlib overhaul	Huge jump from pre-Go 1 (r60, etc.): package paths (e.g. `encoding/asn1`), `os.Error` → `error`, `time` redesign, `map`/`delete`, `rune`, randomized map iteration, …	Use `go fix`. Largest breaking migration ever.
Go 1.1	Language & platforms	Integer divide-by-zero on constants is an error; `int`/`uint` 64-bit on 64-bit; some `net`/`syscall` shapes/signatures.	Direct compile/runtime impact.
Go 1.5	Runtime	`GOMAXPROCS` default 1 → number of CPUs.	Concurrency/perf assumptions may change.
Go 1.21	Runtime & panic	`panic(nil)` / untyped nil panics `*runtime.PanicNilError` (previously no panic).	`GODEBUG=panicnil=1` or stay on `go 1.20` or older.
Go 1.21	Package init	Init order is now defined (import path order); previously undefined.	Code relying on implicit init order may break.
Go 1.22	Language (`for`)	Per-iteration loop variables (was one shared var). Closure capture changes.	Enabled by `go 1.22` (or newer) in `go.mod`; older modules keep old behavior. Common migration point.
Go 1.22	`net/http.ServeMux`	Method prefixes (`POST /path`), `{name}` wildcards, escaping changes.	`GODEBUG=httpmuxgo121=1` restores Go 1.21 behavior.
Go 1.22	`go/types`	Type aliases use `Alias` (previously same as underlying type).	`GODEBUG=gotypesalias=0` (default in 1.22); default 1 from 1.23; removed 1.27.
Go 1.22	TLS & crypto	Min TLS 1.2; some RSA KEX / 3DES ciphers removed (later releases).	Various `GODEBUG` flags (`tls10server=1`, …), some removed by 1.27.
Go 1.23	`time`	Channels from `time` are unbuffered; affects correct `Timer.Stop` usage.	`GODEBUG=asynctimerchan=0` (removed 1.27).
Go 1.23	`net/http`	`http.ServeContent` strips some headers on errors.	`GODEBUG=httpservecontentkeepheaders=1`.
Go 1.23	`x509` & TLS	Reject negative serials; `Leaf` population changes, etc.	`GODEBUG` such as `x509negativeserial=0`, `x509keypairleaf=0`.
Go 1.24	`x509`	Certificate Policies field handling.	`GODEBUG=x509usepolicies=0`.
Go 1.25	Runtime & nil checks	Some nil derefs (e.g. `f, err := os.Open(); f.Name()` when `f==nil`) panic immediately (was sometimes deferred).	Spec-correct; no `GODEBUG`; fix code (check `err` first).
Go 1.25+	Platforms	Drops old OS support (e.g. macOS 11, 32-bit windows/arm); Wasm export changes.	Porting/build impact, not always API.

Parsing certs produced by older golang with a newer toolchain can fail because of x509 changes.

Another face of incompatibility is splintered tooling—especially obvious around proto.

# Core
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

# Validation
go install github.com/envoyproxy/protoc-gen-validate@latest

# HTTP gateway
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway@latest

# API docs
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2@latest
go install github.com/google/gnostic/cmd/protoc-gen-openapi@latest

You install all of that—then drop to an older golang and even dlv may not run. You hunt for toolchains that match, and get lost in the matrix of plugins.

You cannot always stay on the newest golang, so workflows get weird:

Tweak path on window to an old golang → debugger stack unsupported → hunt for tools A B C D that match → fix A, then B, then C, loop forever.

You only wanted to run a program, but time burns on go install version pins.

`window` is a bad fit for `golang`

On window, many third-party tools fail to build; go install becomes a joke. So people doing golang gravitate to Linux / mac when they can.

No selective compilation

Go lacks preprocessor-style conditional compilation like C# / the C family: #if that strips whole regions from unselected builds. The closest Go offers is build tags (//go:build) across files, or runtime.GOOS branches—different semantics and ergonomics. Coming from C#, you feel the missing “selective compilation.”

Typical C# patterns (illustrative):

// 1) Trim code by symbol (DEBUG is defined in Debug builds)
#if DEBUG
    System.Diagnostics.Debug.WriteLine("Only in Debug builds");
#endif

#if MY_FEATURE
    // Define MY_FEATURE in csproj <DefineConstants> or compiler flags
    DoExperimentalStuff();
#endif

// 2) Conditional: if the symbol is undefined, call sites are stripped (method may remain)
using System.Diagnostics;

class App
{
    [Conditional("VERBOSE")]
    static void VerboseLog(string msg) => Console.WriteLine(msg);

    static void Main()
    {
        VerboseLog("No call instruction if VERBOSE is not defined");
    }
}

By contrast, Go swaps implementations per build mostly via file-level conditions (//go:build linux) or link tricks—not #if folding half a function.

Without those tags, aside from environment variables, I do not have another clean pattern.

Postscript

Writing this, I ask myself: does sharing tech still matter in the AI era?

When I started, seniors said: blog your problems and fixes. I have kept that habit, off and on, for ten years.

We cannot out-learn AI—but critical thinking keeps me from being swept along; I treat AI as a calculator.

Risk is still mine. Years of bumps taught me: hold your fate in your own hands, or the world drags you.

So the blog post itself is not the point. Thinking is the point—synthesis is the process; the article is just something for later readers to remember you by.

ひと言で言えば、golangは高性能なネットワーク向け言語に過ぎない。

ゼロ値の罠

type AllBasicTypes struct {
	B    bool
	Str  string

	I8   int8
	I16  int16
	I32  int32
	I64  int64
	I    int

	U8   uint8
	U16  uint16
	U32  uint32
	U64  uint64
	U    uint
	Up   uintptr

	By   byte // uint8
	Ru   rune // int32

	F32  float32
	F64  float64

	C64  complex64
	C128 complex128
}

// var v AllBasicTypes — 各フィールドはゼロ値: false、""、0、0.0、(0+0i) など

Javaのようなヌルポインタ問題を避けるため、golangはデフォルトゼロ値を採用した。その結果、設計時にゼロ値には常に注意が必要になる。上の構造体では var v AllBasicTypes のあと、v.Bはfalse、v.U8は0になる。

実務では、Bが本当にfalseなのか、未代入なのか判別できない。対策は別マップで「セットされたか」を持つか、変な型の *bool を使うことになる。

import (
    "fmt"
    "time"
    "google.golang.org/protobuf/types/known/timestamppb"
)

func main() {
    // 悪い例: time.Time のゼロ値を使う
    var zeroTime time.Time  // または time.Time{}
    protoTs := timestamppb.New(zeroTime)
    
    // シリアライズで失敗する
    data, err := proto.Marshal(protoTs)
    fmt.Println(err)  // 例: proto: Google.Protobuf.Timestamp.Seconds out of range -62135596800
}

時間のゼロ値が原因のproto Timestampまわりの不具合は、見えにくい。下位のモデルで time.Time フィールドを定義していても、上位のAPIでデシリアライズに失敗することがある。

弱いネットワーク

回線が弱い環境では、golangはかなり使いづらい。標準付属は薄く、すぐgo getが必要で、中国国内ではgo getはプロキシとセットになる。

ネットの問題とサードパーティのダイヤモンド依存をどうにかしても、弱い回線のもとではgolangは相変わらず厳しい。ソースを取得しても、開発とビルドから vscode + golang拡張 + go mod tidy は逃げられない。しかもgolang用vscode拡張は開箱即戦力ではなく、入れたあとも dlv などを別途入れる。

互換性

互換性は大きくOS互換と言語の前方互換に分かれる。

`golang`が前方互換でない例

あまり知られていないが、golangは長年のあいだに前方互換を壊す変更を出している：

Go バージョン	分類	非互換の内容	回避・備考
Go 1 (2012)	言語・標準庫の大改修	pre-Go 1 (r60 等) からの巨大差分：パス変更（例: `encoding/asn1`）、`os.Error` → `error`、`time`再設計、`map`/`delete`、`rune`、マップ走査のランダム化など	`go fix` で移行。最大の breaking 更新。
Go 1.1	言語・プラットフォーム	定数ゼロ除算がエラー；64bit で `int`/`uint` が64bit；一部 `net`/`syscall` の型・シグネチャ変更	コンパイル・実行に直撃。
Go 1.5	ランタイム	`GOMAXPROCS` 既定が 1 → CPU 数	並行・性能の前提が変わる。
Go 1.21	ランタイム・panic	`panic(nil)` / 型なし nil が `*runtime.PanicNilError` を panic（以前は panic しない）	`GODEBUG=panicnil=1` または `go 1.20` 以前。
Go 1.21	パッケージ初期化	初期化順が規定（import path 順）；以前は未定義	暗黙の初期化順に依存したコードに影響。
Go 1.22	言語（`for`）	ループ変数が反復ごとに新規（以前は共有）。クロージャの捕獲が変わる	`go.mod` の `go 1.22` 以上で有効。よくある移行ポイント。
Go 1.22	`net/http.ServeMux`	メソッド接頭辞（`POST /path`）、`{name}` ワイルドカード、エスケープ変更	`GODEBUG=httpmuxgo121=1` で Go 1.21 挙動。
Go 1.22	`go/types`	型エイリアスが `Alias` として表現（以前は下位型と同一扱い）	`GODEBUG=gotypesalias=0`（1.22 既定）；1.23 から既定1、1.27 で削除予定。
Go 1.22	TLS・crypto	最小 TLS 1.2；RSA KEX や 3DES など削除（以降も継続）	複数の `GODEBUG`、一部 1.27 で削除。
Go 1.23	`time`	`time` が作る channel がアンバッファ；`Timer.Stop` 等の正しい使い方に影響	`GODEBUG=asynctimerchan=0`（1.27 で削除予定）。
Go 1.23	`net/http`	エラー応答で `http.ServeContent` が一部 header を除去	`GODEBUG=httpservecontentkeepheaders=1`。
Go 1.23	`x509`・TLS	負のシリアル拒否；`Leaf` の扱い変更など	`x509negativeserial=0` 等。
Go 1.24	`x509`	Certificate Policies フィールドの扱い	`GODEBUG=x509usepolicies=0`。
Go 1.25	ランタイム・nil チェック	一部 nil デリファレンス（例: `f, err := os.Open(); f.Name()` で `f==nil`）が即 panic（以前は遅延することがあった）	`GODEBUG` なし。`err` を先に確認。
Go 1.25+	プラットフォーム	古い OS サポート廃止（例: macOS 11、32-bit windows/arm）；Wasm エクスポート変更	API 以外だがビルドに影響。

新しいgolangで古いgolangが生成した証明書を読むと、x509の変更でパースに失敗することがある。

互換性のもう一つの顔はツールチェーンの分断で、protoまわりが特に顕著だ。

# コア
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

# バリデーション
go install github.com/envoyproxy/protoc-gen-validate@latest

# HTTP ゲートウェイ
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway@latest

# API ドキュメント
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2@latest
go install github.com/google/gnostic/cmd/protoc-gen-openapi@latest

こんなに入れても、古いgolangに下げると dlv すら動かない。互換バージョンを探して、ツールの海で迷子になる。

常に最新のgolangとは限らないので、作業フローは奇妙になる：

windowでpathをいじって古いgolangに切り替え → デバッグスタック非対応 → 対応版のツール ABCD を探す → A、次 B、次 C… のループ。

本当はプログラムを動かしたいだけなのに、go install のバージョンいじりに時間を焼く。

`window`は`golang`開発に向かない

windowではサードパーティツールの多くがビルドすら通らず、go installが笑い話になる。なのでgolang開発は、なるべくLinux/macを使う流れになる。

選択的コンパイルの欠如

Goには C# や C 系のようなプリプロセッサ級の条件コンパイルがない：構文のなかで #if によって選ばれないビルドから丸ごと削る、というやり方はできない。近いのは build tags（//go:build）でファイルを分けるか、runtime.GOOS などの分岐で、意味も手触りも違う。C# 出身だと「選択的コンパイル」が足りないと感じる。

C# でよくある例（概略）：

// 1) シンボルでブロックを切る（DEBUG は Debug 構成で定義）
#if DEBUG
    System.Diagnostics.Debug.WriteLine("Debug ビルドにだけ存在");
#endif

#if MY_FEATURE
    // csproj の <DefineConstants> かコンパイラで MY_FEATURE を定義
    DoExperimentalStuff();
#endif

// 2) Conditional: シンボル未定義なら呼び出し側が削られる（メソッド自体は残り得る）
using System.Diagnostics;

class App
{
    [Conditional("VERBOSE")]
    static void VerboseLog(string msg) => Console.WriteLine(msg);

    static void Main()
    {
        VerboseLog("VERBOSE 未定義なら呼び出し命令は生成されない");
    }
}

対してGoは「ビルドごとに実装を差し替える」なら、だいたいファイル単位の条件（//go:build linux）かリンク時の工夫で、関数の半分を #if で畳むことはしない。

その手のタグを使わないなら、環境変数で切り替える以外、すぐには思いつかない。

あとがき

ここまで書いて、AI時代に技術を共有することにまだ意味があるのか、自分に問う。

入門した頃、先輩はブログに問題と解を書けと言った。その習慣は10年、途切れ途切れ続いている。

いまはAI時代で、人間の学習速度はAIに追いつかない。それでも批判的思考のおかげでAIに流されにくく、AIは計算の補助だと割り切っている。

最終的なリスクは自分が負う。長年の経験で、運命は自分の手で握る以外、外物に引きずられる。

だから技術ブログそのものに意味はない。考えること自体が意味で、まとめるのはプロセスに過ぎず、記事は後世が懐かしむ結果にすぎない。

В двух словах: golang — это высокопроизводительный язык для сетевого программирования, не больше.

Ловушки нулевых значений

type AllBasicTypes struct {
	B    bool
	Str  string

	I8   int8
	I16  int16
	I32  int32
	I64  int64
	I    int

	U8   uint8
	U16  uint16
	U32  uint32
	U64  uint64
	U    uint
	Up   uintptr

	By   byte // uint8
	Ru   rune // int32

	F32  float32
	F64  float64

	C64  complex64
	C128 complex128
}

// var v AllBasicTypes — нулевые значения полей: false, "", 0, 0.0, (0+0i) и т.д.

Чтобы не ловить «как в Java» проблемы с нулевыми указателями, в golang принята модель нулевых значений по умолчанию. Поэтому при проектировании с нулевыми значениями нужно быть осторожным. Для структуры выше после var v AllBasicTypes поле v.B даёт false, а v.U8 — 0.

В реальных сценариях непонятно: B это именно false или поле не задано. Обычно добавляют отдельную карту «установлено ли» или используют странный тип *bool.

import (
    "fmt"
    "time"
    "google.golang.org/protobuf/types/known/timestamppb"
)

func main() {
    // Плохой пример: нулевое значение time.Time
    var zeroTime time.Time  // или time.Time{}
    protoTs := timestamppb.New(zeroTime)
    
    // Сериализация падает
    data, err := proto.Marshal(protoTs)
    fmt.Println(err)  // например: proto: Google.Protobuf.Timestamp.Seconds out of range -62135596800
}

Ошибка из-за нулевого времени и proto Timestamp почти незаметна. Внизу стека вы могли объявить поле как time.Time, а на верхнем уровне API десериализация уже не проходит.

Слабая сеть

При плохой сети golang неудобен: стандартная библиотека скромная, постоянно нужен go get, а в Китае без прокси go get почти нереалистичен.

Даже если сеть и ромбовидные зависимости третьих сторон «решены», при слабом канале golang всё равно мучителен. Исходники скачал — а разработка и сборка всё равно упираются в vscode, расширение golang, go mod tidy. Расширение для vscode не «из коробки»: поставил — и всё равно ставишь dlv и прочее.

Совместимость

Совместимость делится на совместимость ОС и совместимость языка вперёд по версиям.

Когда `golang` не совместим вперёд

Мало кто знает, что за годы в golang были несовместимые вперёд изменения:

Версия Go	Категория	Что сломалось	Обход / примечание
Go 1 (2012)	Язык и стандартная библиотека	Огромный разрыв с pre-Go 1 (r60 и т.д.): пути пакетов (напр. `encoding/asn1`), `os.Error` → `error`, переработка `time`, `map`/`delete`, `rune`, случайный порядок обхода map и т.д.	`go fix`. Крупнейшая ломающая миграция.
Go 1.1	Язык и платформы	Деление константы на ноль — ошибка; на 64-bit `int`/`uint` 64-битные; часть `net`/`syscall`.	Прямой эффект на сборку и выполнение.
Go 1.5	Рантайм	`GOMAXPROCS` по умолчанию 1 → число CPU.	Меняются допущения про параллелизм.
Go 1.21	Рантайм и panic	`panic(nil)` / нетипизированный nil паникует `*runtime.PanicNilError` (раньше не паниковал).	`GODEBUG=panicnil=1` или `go 1.20` и ниже.
Go 1.21	Инициализация пакетов	Порядок инициализации задан (по import path); раньше — не определён.	Код, завязанный на неявный порядок, может сломаться.
Go 1.22	Язык (`for`)	Переменная цикла на каждую итерацию (раньше одна на все). Меняется захват в замыканиях.	Включается `go 1.22+` в `go.mod`; частая точка миграции.
Go 1.22	`net/http.ServeMux`	Префиксы методов (`POST /path`), шаблоны `{name}`, экранирование.	`GODEBUG=httpmuxgo121=1` — поведение Go 1.21.
Go 1.22	`go/types`	Псевдонимы типов как `Alias` (раньше совпадали с основным типом).	`GODEBUG=gotypesalias=0` (по умолчанию в 1.22); с 1.23 по умолчанию 1; уберут в 1.27.
Go 1.22	TLS и crypto	Минимум TLS 1.2; выкидывание RSA KEX, 3DES и т.д.	Несколько флагов `GODEBUG`, часть снимут в 1.27.
Go 1.23	`time`	Каналы из `time` — небуферизованные; влияет на корректный `Timer.Stop`.	`GODEBUG=asynctimerchan=0` (уберут в 1.27).
Go 1.23	`net/http`	`http.ServeContent` убирает часть заголовков при ошибках.	`GODEBUG=httpservecontentkeepheaders=1`.
Go 1.23	`x509` и TLS	Отрицательные серийные номера; изменения с полем `Leaf` и т.д.	`x509negativeserial=0` и др.
Go 1.24	`x509`	Политики сертификатов (Policies).	`GODEBUG=x509usepolicies=0`.
Go 1.25	Рантайм и nil	Часть разыменований nil (напр. `f, err := os.Open(); f.Name()` при `f==nil`) паникует сразу (раньше иногда откладывалось).	Без `GODEBUG`; чинить код (сначала `err`).
Go 1.25+	Платформы	Снятие поддержки старых ОС (напр. macOS 11, 32-bit windows/arm); изменения Wasm.	Влияет на сборку/порты.

Разбор сертификатов, сгенерированных старым golang, новым компилятором может падать из-за изменений в x509.

Другая сторона — раскол инструментов; с proto это особенно заметно.

# База
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

# Валидация
go install github.com/envoyproxy/protoc-gen-validate@latest

# HTTP-шлюз
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway@latest

# Документация API
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2@latest
go install github.com/google/gnostic/cmd/protoc-gen-openapi@latest

Столько всего поставил — а на старом golang даже dlv не стартует. Ищешь совместимые версии и теряешься в наборе плагинов.

Не всегда можно сидеть на последнем golang, поэтому цепочка действий становится странной:

Меняешь path на window на старый golang → стек отладки не подходит → ищешь инструменты A B C D под версию → починил A, потом B, потом C, по кругу.

Ты хотел просто запустить программу, а время уходит на go install с версиями.

`window` плохо подходит под `golang`

На window много сторонних утилит не собирается; go install превращается в анекдот. Поэтому для golang чаще уходят на Linux / mac.

Нет условной компиляции в стиле препроцессора

У Go нет препроцессорной условной компиляции как у C# / C: #if, вырезающего целые куски из несобранных конфигураций. Ближе всего — build tags (//go:build) по разным файлам или ветки runtime.GOOS; смысл и эргономика другие. С фона C# явно чувствуешь отсутствие «выборочной компиляции».

Типичные приёмы в C# (схематично):

// 1) Обрезка кода по символу (DEBUG задаётся в Debug)
#if DEBUG
    System.Diagnostics.Debug.WriteLine("Только в Debug-сборке");
#endif

#if MY_FEATURE
    // MY_FEATURE — в csproj <DefineConstants> или флагах компилятора
    DoExperimentalStuff();
#endif

// 2) Conditional: если символ не задан, вызовы вырезаются (метод может остаться)
using System.Diagnostics;

class App
{
    [Conditional("VERBOSE")]
    static void VerboseLog(string msg) => Console.WriteLine(msg);

    static void Main()
    {
        VerboseLog("Без VERBOSE вызов не попадёт в IL");
    }
}

Для Go смена реализации между сборками — обычно условия на уровне файлов (//go:build linux) или трюки линковки, а не #if на полфункции.

Без таких тегов, кроме переменных окружения, другого аккуратного варианта я не вижу.

Постскриптум

Пишу это и спрашиваю себя: есть ли смысл делиться технологиями в эпоху ИИ?

Когда я начинал, советовали вести блог с проблемами и решениями. Так я делаю с перерывами уже десять лет.

Скорость обучения людей не догоняет ИИ — но критическое мышление не даёт увлечься потоком; ИИ для меня вспомогательный «калькулятор».

Риск всё равно на мне. Годы показали: судьбу держишь в своих руках — или тебя волокут обстоятельства.

Значит сам пост не цель. Смысл — в размышлении; систематизация — процесс; статья — лишь след для тех, кто потом вспомнит.

不幂等电梯与P=NP中的分家产问题

Fri, 27 Mar 2026 00:00:00 +0000

幂等性是程序设计的一种重要原则。

举个最简单的例子，去ATM取钱，确认好数字，按下确认之后，机器会开始吐钱。但这个过程中如果再按下“确认”，而ATM还会接着吐钱，那么这个设计就是不幂等的。

当然现实没有那么好的事情，按下确认到收钱的这个时间段，在程序设计中属于一个“事务锁”的阶段。这期间按100次确认也是徒劳。

不知不觉之间,ATM也成为了即将被淘汰的消费电子类产品。但幂等原则和数据库事务这类基本原理没有消失。

不幂等电梯

比如我最近遇到一种“不幂等电梯”。在传统商业建筑中，运营为了方便一般会设置“1对N幂等”——按下下行之后，所有下行灯一起亮，然后调度中心分配一个最近的电梯。这种我称为“幂等电梯”。

不幂等电梯，是把面板上下行按钮跟调度中心分离。比如一栋楼有3部挨着的电梯。按下面板上的上下行，只是控制“1对1”关联的那部电梯。如果想要另外一部电梯，那就按另外一个面板。这种我称为“不幂等电梯”。本文只讨论不幂等电梯场景。

个体自私导致群体延误

结合过往的统计规律，应用时间序列编程对“不幂等电梯”场景建模，假设工作时间是 9:00 ~ 18:30 ，那么在上下班临界点10分钟内，对于楼层<10 的写字楼，按照我的经验，基本上是走步梯比较快。

而假设场景中的人只有1个，实际上选取电梯的策略非常简单，选择“离自己最近的那部同向电梯”便是最佳策略：

type Work struct {
	Floor       int16     //工作楼层
	WorkHours   time.Time //上班时间
	ClosingTime time.Time //下班时间
}

// Person 表示人
type Person struct {
	Time        time.Time // 时间
	Floor       int16     //当前楼层
	TargetFloor int16     //目标楼层
	work        Work
}

func (p *Person) MVP(elevators []Elevator) (int, *Elevator) {
	t := p.Time
	if p.work.Floor < 10 && (t.Sub(p.work.ClosingTime).Abs() < 10*time.Minute || t.Sub(p.work.WorkHours).Abs() < 10*time.Minute) {
		//walking
		return -1, nil
	}
	if len(elevators) == 0 {
		return -1, nil
	}
	distance := time.Hour << 10
	var bestElevator Elevator
	var n int
	for k, e := range elevators {
		temp := *e.Status(t)
		if d := temp.Distance(p); d < distance {
			distance = d
			n = k
			bestElevator = temp
		}
	}
	//找到离自己最近的节点并选择
	return n, &bestElevator
}

然而实际情况更多的是N人抢3部电梯这种情况比较多。这个策略会在N人情景下立刻失效。

因为“这栋楼有多少人在等电梯”对于所有不在监控室里的人来说是一个黑盒。

因此很多人会选择 “all” 策略——所有按钮一起按，甚至在下班的时候先上行再下行。即便所有人不倒着按电梯，下班的时候所有按钮都按下，也会导致下行的电梯几乎每层都停。

当然，有些人会反驳，说可以设置一个“FL”的状态，当电梯满载时一路下行不停任何楼层。但在4人4梯时，这个问题依旧很明显——4个人分布在不同楼层，决策方向完全随机，如果所有人4个面板一起按，会造成电梯资源最大程度的浪费。

不幂等电梯揭露了一个问题：追求个体利益的最大化会损害群体利益，并最终影响到自己的收益。因为搭电梯是为了尽可能地省时间，收益函数是时间。如果所有人都按下所有按钮，表面看来所有电梯都会朝着自己来，但最终还是导致乘梯时间最大化。

P=NP中的分家产问题

不幂等电梯代表了集体利益与个人利益的绝对矛盾。除了把电梯调整为“幂等”，让调度中心去协调之外，似乎没有很好的解法。但如果把电梯直接量化为家产，把分配电梯当成P=NP中的分蛋糕（我个人更愿意称为“分家产”难题）。那么问题似乎简单一点。

转换一下问题，把 N 个参与人缩小为数量可控的“子女”，电梯转换为现金，那么所有参与人，彼此之间就不是“黑盒”的状态。

那么在我看来，公平分配（每个人都认为自己至少得到了蛋糕的 1/n 价值）是不存在的——假设我作为家族财产管理人，名下有几个子女。为了资产的长远递增，那就不可能全部现金N等分，然后取一份给未满18岁的儿子。

更别提每个人照镜子的时候都有自我美化倾向（曝光效应）。对自我评价比客观事实高，这是一种普遍现象。这种认知偏差，加上客观条件限制，就导致了分家产问题不可能有对所有人公平的解法。

按照历史的统计经验，分家产问题最后还是看各位继承人的投资理财水平，根据实际的财务收益和能力特长，通过时间的检验，最终才能得到一个解法。

至此，我终于理解了修格斯的分布式求偶这种行为艺术，通过广撒网，多捞鱼的渣男策略，实现面向时间效率优化的多对象差异学习梯度下降。

近水楼台先得月

A little closer to the bank, Where coins and notes are in the rank.

Idempotency is an important principle in program design.

Take the simplest example: withdrawing cash from an ATM. You confirm the amount and press “confirm”, then the machine starts dispensing money. But if pressing “confirm” again during this process makes the ATM continue dispensing, then this design is non-idempotent.

Of course, reality is not that generous. The time window between pressing confirm and receiving cash belongs to a “transaction lock” phase in program design. During this period, pressing confirm 100 times is still futile.

Before we noticed it, ATMs also became consumer electronics that are about to be phased out. But principles like idempotency and database transactions have not disappeared.

Non-idempotent Elevator

For example, I recently encountered a kind of “non-idempotent elevator”. In traditional commercial buildings, operations usually set up a “1-to-N idempotency” model for convenience: after pressing down, all down indicators light up together, and then the dispatch center assigns the nearest elevator. I call this an “idempotent elevator”.

A non-idempotent elevator separates the up/down panel buttons from the dispatch center. For instance, if a building has 3 adjacent elevators, pressing up/down on one panel only controls the “1-to-1” mapped elevator. If you want another one, you press another panel. I call this a “non-idempotent elevator”. This article only discusses the non-idempotent elevator scenario.

Individual selfishness causes collective delay

Based on historical statistical patterns, and modeling the “non-idempotent elevator” scenario with time-series programming, suppose working hours are 9:00 ~ 18:30. Then within 10 minutes of commuting critical points, for office buildings with floors <10, in my experience, taking the stairs is basically faster.

If there is only 1 person in the scenario, the strategy for choosing an elevator is actually very simple: choose “the nearest elevator moving in the same direction” as the optimal strategy:

type Work struct {
	Floor       int16     // working floor
	WorkHours   time.Time // work start time
	ClosingTime time.Time // work end time
}

// Person represents a person
type Person struct {
	Time        time.Time // time
	Floor       int16     // current floor
	TargetFloor int16     // target floor
	work        Work
}

func (p *Person) MVP(elevators []Elevator) (int, *Elevator) {
	t := p.Time
	if p.work.Floor < 10 && (t.Sub(p.work.ClosingTime).Abs() < 10*time.Minute || t.Sub(p.work.WorkHours).Abs() < 10*time.Minute) {
		//walking
		return -1, nil
	}
	if len(elevators) == 0 {
		return -1, nil
	}
	distance := time.Hour << 10
	var bestElevator Elevator
	var n int
	for k, e := range elevators {
		temp := *e.Status(t)
		if d := temp.Distance(p); d < distance {
			distance = d
			n = k
			bestElevator = temp
		}
	}
	// find and choose the nearest elevator
	return n, &bestElevator
}

However, in reality, cases like N people competing for 3 elevators are much more common. This strategy fails immediately under the N-person scenario.

Because “how many people are waiting for elevators in this building” is a black box for everyone not in the control room.

So many people choose the “all” strategy - pressing every button together, and even going up first then down after work. Even if no one presses in reverse order, if everyone presses all buttons after work, down-moving elevators will still stop at almost every floor.

Of course, some people may argue we can set an “FL” state: when an elevator is fully loaded, it goes straight down without stopping at any floor. But in a 4-people-4-elevators case, the problem is still obvious - 4 people are distributed on different floors, decision directions are completely random, and if everyone presses all 4 panels together, elevator resources are wasted to the greatest extent.

Non-idempotent elevators expose one fact: maximizing individual benefit harms collective benefit, and eventually harms one’s own payoff. Because taking elevators is meant to save as much time as possible, and the utility function is time. If everyone presses all buttons, it seems all elevators will come toward them, but in the end it still maximizes total elevator riding time.

The estate division problem in P=NP

A non-idempotent elevator represents the absolute conflict between collective interest and individual interest. Other than turning elevators into an “idempotent” model and letting the dispatch center coordinate, there seems to be no good solution. But if we directly quantify elevators as estate assets, and treat elevator allocation as the cake-cutting problem in P=NP (personally I prefer to call it the “estate division” problem), then the issue seems slightly simpler.

Let’s transform the problem: shrink N participants into a controllable number of “children”, and convert elevators into cash. Then all participants are no longer in a “black box” state relative to each other.

In my view, fair division (everyone believes they have received at least 1/n value of the cake) does not exist - suppose I am the family asset manager and have several children. For long-term asset growth, it is impossible to split all cash into equal N shares and hand one share to a son under 18.

Not to mention that when people look in the mirror, they tend to self-enhance (mere exposure effect). Rating oneself higher than objective facts is a common phenomenon. This cognitive bias, combined with objective constraints, makes it impossible to have an estate-division solution fair to everyone.

According to historical statistical experience, the final outcome of estate division still depends on each heir’s investment and wealth-management capability. Based on real financial returns and talent strengths, and through the test of time, a solution can finally emerge.

At this point, I finally understood the behavioral art of distributed courtship by Shoggoth: using the scumbag strategy of casting a wide net and catching more fish, to achieve multi-object differential learning gradient descent optimized for time efficiency.

Nearby advantage

A little closer to the bank, Where coins and notes are in the rank.

冪等性はプログラム設計における重要な原則のひとつである。

最も簡単な例を挙げるなら、ATMで現金を引き出す場面だ。金額を確認して「confirm」を押すと、機械は現金を吐き出し始める。だがこの過程で再び「confirm」を押し、ATMがさらにお金を出し続けるなら、その設計は非冪等である。

もちろん現実はそんなに都合よくない。confirmを押してから現金を受け取るまでの時間帯は、プログラム設計では「トランザクションロック」の段階に属する。この間にconfirmを100回押しても無駄だ。

いつの間にかATMも、淘汰されつつあるコンシューマーエレクトロニクス製品になった。だが冪等原則やデータベーストランザクションのような基礎原理は消えていない。

非冪等エレベーター

例えば最近、私は「非冪等エレベーター」に遭遇した。従来の商業ビルでは、運用上の都合で通常「1対N冪等」が設定される。下行ボタンを押すと、すべての下行ランプが同時に点灯し、配車センターが最寄りのエレベーターを割り当てる。私はこれを「冪等エレベーター」と呼ぶ。

非冪等エレベーターは、パネルの上下ボタンと配車センターを分離する。例えば1棟に隣接した3基のエレベーターがある場合、あるパネルの上下ボタンを押しても、その「1対1」で対応する1基しか制御しない。別のエレベーターが欲しければ、別のパネルを押す。この方式を私は「非冪等エレベーター」と呼ぶ。この記事では非冪等エレベーターのシナリオのみを扱う。

個人の利己性が集団遅延を生む

過去の統計規則を組み合わせ、時系列プログラミングで「非冪等エレベーター」シナリオをモデル化する。勤務時間を 9:00 ~ 18:30 と仮定すると、出退勤の臨界点10分以内では、階数<10 のオフィスビルなら、私の経験上、ほぼ階段の方が速い。

一方で、シナリオ内の人が1人だけだと仮定すれば、実際のエレベーター選択戦略は非常に単純で、「自分に最も近い同方向のエレベーター」を選ぶのが最適戦略になる。

type Work struct {
	Floor       int16     // 勤務フロア
	WorkHours   time.Time // 始業時刻
	ClosingTime time.Time // 終業時刻
}

// Person は人を表す
type Person struct {
	Time        time.Time // 時刻
	Floor       int16     // 現在の階
	TargetFloor int16     // 目的階
	work        Work
}

func (p *Person) MVP(elevators []Elevator) (int, *Elevator) {
	t := p.Time
	if p.work.Floor < 10 && (t.Sub(p.work.ClosingTime).Abs() < 10*time.Minute || t.Sub(p.work.WorkHours).Abs() < 10*time.Minute) {
		// 徒歩
		return -1, nil
	}
	if len(elevators) == 0 {
		return -1, nil
	}
	distance := time.Hour << 10
	var bestElevator Elevator
	var n int
	for k, e := range elevators {
		temp := *e.Status(t)
		if d := temp.Distance(p); d < distance {
			distance = d
			n = k
			bestElevator = temp
		}
	}
	// 自分に最も近いエレベーターを選ぶ
	return n, &bestElevator
}

しかし現実には、N人で3基のエレベーターを奪い合うケースの方がずっと多い。この戦略はN人シナリオではすぐに破綻する。

なぜなら「このビルで何人がエレベーター待ちをしているか」は、監視室にいないすべての人にとってブラックボックスだからだ。

そのため多くの人は「all」戦略、つまり全ボタン同時押しを選ぶ。退勤時には、先に上行を押してから下行を押す人すらいる。たとえ逆押しをしなくても、退勤時に全員が全ボタンを押せば、下行エレベーターはほぼ各階に停止してしまう。

もちろん、「FL」状態を設定し、満載時はどの階にも止まらず一気に下行させればよい、と反論する人もいる。しかし4人4基でもこの問題は依然として顕著だ。4人が別々の階に分布し、意思決定方向が完全にランダムな中で、全員が4つのパネルを同時に押せば、エレベーター資源は最大限に浪費される。

非冪等エレベーターはひとつの問題を暴く。個人利益の最大化追求は集団利益を損ない、最終的には自分自身の利益にも影響する。エレベーターに乗る目的は時間をできるだけ節約することであり、利得関数は時間だからだ。全員が全ボタンを押せば、表面上はすべてのエレベーターが自分の方へ来るように見えるが、最終的には乗梯時間を最大化してしまう。

P=NPにおける遺産分割問題

非冪等エレベーターは、集団利益と個人利益の絶対的な矛盾を表している。エレベーターを「冪等」に調整し、配車センターに協調させる以外に、良い解法はなさそうだ。だがエレベーターを遺産として定量化し、エレベーター配分をP=NPにおけるケーキ分割（私は個人的に「遺産分割」難題と呼びたい）として捉えると、問題は少し単純になるように思える。

問題を変換してみる。N人の参加者を数が管理しやすい「子女」に縮小し、エレベーターを現金に変換すれば、参加者同士はもはや「ブラックボックス」ではなくなる。

私の見るところ、公平分配（各人が自分は少なくともケーキの 1/n の価値を得たと考えること）は存在しない。仮に私が家族資産管理人で、名義下に何人かの子女がいるとする。資産の長期増加を目指すなら、現金をN等分して18歳未満の息子に1つ渡す、というわけにはいかない。

まして人は鏡を見ると自己美化傾向（単純接触効果）を持つ。自己評価が客観的事実より高いのは普遍的現象だ。この認知バイアスに客観条件の制約が加わることで、遺産分割問題には全員に公平な解法が存在しえなくなる。

歴史的な統計経験に従えば、遺産分割問題の最終結果はやはり各相続人の投資・資産運用レベル次第だ。実際の財務収益と能力特長に基づき、時間の検証を経て、最終的にひとつの解が得られる。

ここに至って私はついに、修格斯の分散求愛という行為芸術を理解した。広く網を撒き、多くの魚を獲るという渣男戦略によって、時間効率最適化に向けた多対象差分学習勾配降下を実現しているのだ。

近くの楼台は先に月を得る

A little closer to the bank, Where coins and notes are in the rank.

Идемпотентность - один из важных принципов проектирования программ.

Простейший пример: снятие наличных в ATM. Вы подтверждаете сумму и нажимаете “confirm”, после чего автомат начинает выдавать деньги. Но если в этот момент повторное нажатие “confirm” заставляет ATM продолжать выдачу, такой дизайн неидемпотентен.

Конечно, в реальности таких чудес не бывает. Период между нажатием confirm и получением денег в программировании относится к стадии “transaction lock”. В это время хоть 100 раз нажимай confirm - бесполезно.

Незаметно для нас ATM тоже стал видом потребительской электроники, которая скоро уйдет в прошлое. Но базовые принципы вроде идемпотентности и транзакций базы данных никуда не исчезли.

Неидемпотентный лифт

Например, недавно я столкнулся с видом “неидемпотентного лифта”. В традиционных коммерческих зданиях для удобства эксплуатации обычно настраивают модель “1 к N идемпотентности”: после нажатия кнопки вниз загораются все индикаторы вниз, а диспетчерский центр назначает ближайший лифт. Я называю это “идемпотентным лифтом”.

Неидемпотентный лифт отделяет кнопки вверх/вниз на панели от диспетчерского центра. Допустим, в здании стоят рядом 3 лифта. Нажатие вверх/вниз на одной панели управляет только тем лифтом, который связан с ней по схеме “1 к 1”. Нужен другой лифт - нажимаешь другую панель. Это я и называю “неидемпотентным лифтом”. В статье рассматривается только этот сценарий.

Индивидуальный эгоизм приводит к задержкам для группы

Если, опираясь на прошлые статистические закономерности, смоделировать сценарий “неидемпотентного лифта” через time-series programming и предположить рабочее время 9:00 ~ 18:30, то в 10-минутном окне вокруг пиков прихода/ухода, для офисных зданий с этажами <10, по моему опыту, по лестнице почти всегда быстрее.

Если же в сценарии только 1 человек, стратегия выбора лифта на практике очень проста: оптимально выбрать “ближайший к себе лифт в том же направлении”:

type Work struct {
	Floor       int16     // рабочий этаж
	WorkHours   time.Time // время начала работы
	ClosingTime time.Time // время окончания работы
}

// Person обозначает человека
type Person struct {
	Time        time.Time // время
	Floor       int16     // текущий этаж
	TargetFloor int16     // целевой этаж
	work        Work
}

func (p *Person) MVP(elevators []Elevator) (int, *Elevator) {
	t := p.Time
	if p.work.Floor < 10 && (t.Sub(p.work.ClosingTime).Abs() < 10*time.Minute || t.Sub(p.work.WorkHours).Abs() < 10*time.Minute) {
		// пешком
		return -1, nil
	}
	if len(elevators) == 0 {
		return -1, nil
	}
	distance := time.Hour << 10
	var bestElevator Elevator
	var n int
	for k, e := range elevators {
		temp := *e.Status(t)
		if d := temp.Distance(p); d < distance {
			distance = d
			n = k
			bestElevator = temp
		}
	}
	// найти и выбрать ближайший лифт
	return n, &bestElevator
}

Однако в реальности чаще встречается ситуация, когда N человек конкурируют за 3 лифта. В сценарии с N людьми эта стратегия сразу перестает работать.

Потому что “сколько людей ждут лифт в этом здании” - это black box для всех, кто не находится в диспетчерской.

Поэтому многие выбирают стратегию “all” - нажимают все кнопки сразу, а в час ухода с работы даже сначала вверх, потом вниз. Даже если никто не нажимает в обратном порядке, при нажатии всех кнопок всеми людьми в конце рабочего дня лифты, идущие вниз, останавливаются почти на каждом этаже.

Конечно, кто-то возразит: можно задать состояние “FL”, чтобы при полной загрузке лифт шел вниз без остановок. Но даже при 4 людях и 4 лифтах проблема остается очевидной - 4 человека распределены по разным этажам, направления решений полностью случайны, и если все нажимают все 4 панели сразу, ресурсы лифтов расходуются максимально неэффективно.

Неидемпотентный лифт вскрывает одну проблему: максимизация индивидуальной выгоды вредит коллективной выгоде и в конце концов снижает собственный результат. Потому что цель поездки на лифте - максимально экономить время, а функция полезности здесь - время. Если все нажимают все кнопки, на первый взгляд кажется, что все лифты поедут к тебе, но в итоге это все равно максимизирует время поездки.

Проблема раздела наследства в P=NP

Неидемпотентный лифт представляет абсолютное противоречие между интересами коллектива и интересами индивида. Кроме перевода лифтов в “идемпотентный” режим и координации через диспетчерский центр, хорошего решения, похоже, нет. Но если напрямую квантифицировать лифты как наследственное имущество, а распределение лифтов рассматривать как задачу деления торта в P=NP (лично я предпочитаю называть это задачей “раздела наследства”), тогда проблема выглядит чуть проще.

Переформулируем задачу: уменьшим N участников до управляемого числа “детей”, а лифты преобразуем в наличные. Тогда для всех участников друг друга уже не будет состояния “black box”.

На мой взгляд, справедливого распределения (когда каждый считает, что получил как минимум 1/n ценности торта) не существует - допустим, я управляющий семейными активами и у меня несколько детей. Ради долгосрочного роста активов невозможно просто разделить всю наличность на N равных частей и отдать одну сыну младше 18 лет.

Не говоря уже о том, что люди, глядя в зеркало, склонны к самоидеализации (mere exposure effect). Завышенная самооценка по сравнению с объективными фактами - распространенное явление. Это когнитивное искажение, плюс ограничения объективных условий, и приводят к тому, что у задачи раздела наследства не может быть решения, справедливого для всех.

Согласно историческому статистическому опыту, в итоге в задаче раздела наследства все равно решают уровень инвестиционно-финансовых навыков наследников. На основе реальной финансовой доходности и индивидуальных сильных сторон, проверенных временем, в конце концов появляется решение.

К этому моменту я наконец понял поведенческое искусство distributed courtship у 修格斯: через стратегию 渣男 вида 广撒网，多捞鱼 реализуется multi-object differential learning gradient descent, оптимизированный по эффективности времени.

Кто ближе, тот и первым

A little closer to the bank, Where coins and notes are in the rank.

中国Windows系统使用多个版本的go

Wed, 25 Mar 2026 00:00:00 +0000

还记得我之前提出过的0号规律吗？边际收益为0的重构不要去做。我已经遇过2次因为底层go版本的实现变化，而导致的无法升级项目go版本问题。

由于工作环境的限制，CI的不支持，导致无法在工作环境中使用最用最新版本的golang。

如果使用VS code作为编辑器，就会产生一个问题： dlv 基本用最新版本的golang去构建，而 dlv 依赖于 go mod tidy。如果使用 go mod tidy ,会根据依赖图修剪策略，使用高版本go后会重算依赖树，最终导致 go.mod 被重写。

要在 Windows 上让多个版本的 Go 语言共存，并且不影响 go mod 和 go install 的本地缓存， Go 官方提出了一个多版本管理工具 go install golang.org/dl/go<version>@latest ，核心思路是：将不同版本的 Go 安装在不同的目录，并通过环境变量灵活切换。

各版本 SDK 隔离存放，互不影响。 go mod 和 go install 的缓存（默认在 %USERPROFILE%\go\pkg\mod 和 %USERPROFILE%\go\bin）是全局共享的。这是设计使然，因为模块缓存和安装的可执行文件通常是版本无关或向后兼容的。使用不同版本 Go 编译同一模块时，会利用已有缓存，节省空间和时间。

但在实践过程中会出现一点问题。

卡点

配置了 GOPROXY 之后，本地安装当前golang的最高版本（go 1.26.1）并指向path路径。

再安装特定版本的 Go 工具链：

#打开 PowerShell 或 CMD，使用 go install 命令安装你需要的版本。这些命令会下载一个版本特定的启动器。
go install golang.org/dl/go1.23.12@latest
# 之后可以看到 `%USERPROFILE%\go\bin` 中出现了 `go1.23.12.exe`。
go1.23.12 download
# 这一步由于网络问题，国内会下载失败!

我下载了 go1.23.12.windows-amd64.zip 并放置到 %USERPROFILE%\sdk\go1.23.12 目录，然后把压缩包中的go目录提取到 %USERPROFILE%\sdk\go1.23.12 中，还是提示下载失败。

于是我翻阅了这个命令对应的项目源码。go1.23.12其实对应 https://github.com/golang/dl 中的 dl\go1.23.12\main.go，重点在于 dl\internal\version\version.go中的文件判断。

func install(targetDir, version string) error {
	if _, err := os.Stat(filepath.Join(targetDir, unpackedOkay)); err == nil {
		log.Printf("%s: already downloaded in %v", version, targetDir)
		return nil
	}

	if err := os.MkdirAll(targetDir, 0755); err != nil {
		return err
	}
	goURL := versionArchiveURL(version)
	res, err := http.Head(goURL)
	if err != nil {
		return err
	}
	if res.StatusCode == http.StatusNotFound {
		return fmt.Errorf("no binary release of %v for %v/%v at %v", version, getOS(), runtime.GOARCH, goURL)
	}
	if res.StatusCode != http.StatusOK {
		return fmt.Errorf("server returned %v checking size of %v", http.StatusText(res.StatusCode), goURL)
	}
	base := path.Base(goURL)
	archiveFile := filepath.Join(targetDir, base)
	if fi, err := os.Stat(archiveFile); err != nil || fi.Size() != res.ContentLength {
		if err != nil && !os.IsNotExist(err) {
			// Something weird. Don't try to download.
			return err
		}
		if err := copyFromURL(archiveFile, goURL); err != nil {
			return fmt.Errorf("error downloading %v: %v", goURL, err)
		}
		fi, err = os.Stat(archiveFile)
		if err != nil {
			return err
		}
		if fi.Size() != res.ContentLength {
			return fmt.Errorf("downloaded file %s size %v doesn't match server size %v", archiveFile, fi.Size(), res.ContentLength)
		}
	}
	wantSHA, err := slurpURLToString(goURL + ".sha256")
	if err != nil {
		return err
	}
	if err := verifySHA256(archiveFile, strings.TrimSpace(wantSHA)); err != nil {
		return fmt.Errorf("error verifying SHA256 of %v: %v", archiveFile, err)
	}
	log.Printf("Unpacking %v ...", archiveFile)
	if err := unpackArchive(targetDir, archiveFile); err != nil {
		return fmt.Errorf("extracting archive %v: %v", archiveFile, err)
	}
	if err := os.WriteFile(filepath.Join(targetDir, unpackedOkay), nil, 0644); err != nil {
		return err
	}
	log.Printf("Success. You may now run '%v'", version)
	return nil
}

go1.23.12.windows-amd64.zip 文件下载之后会计算 SHA256 ，并与远程登记的值进行对比，之后再解压，创建 .unpacked-success 文件。如果我本地想跳过这个过程，要么修改 dl\internal\version\version.go 重新编译;要么在 %USERPROFILE%\sdk\go1.23.12 目录中创建 .unpacked-success 文件,我选择第二种。

go1.23.12 version
go version go1.23.12 windows/amd64

命令成功之后，我找了一个项目构建,设置 env 之后依旧构建失败了。

go1.23.12 clean -cache
go1.23.12 clean -modcache
go1.23.12 clean -testcache

# go1.23.12 env -w GOPROXY=
# go1.23.12 env -w GONOPROXY=
# go1.23.12 env -w GOPRIVATE=    
# go1.23.12 env -w GOINSECURE=
go1.23.12 env -w GOSUMDB=off
go1.23.12 env -w GO111MODULE=on
go1.23.12 build -v -ldflags="-checklinkname=0" 

于是我决定回退一开始的方案，使用 path 路径切换 go 版本 🤣。在win11中，使用1.26，就把1.26 go版本的path上移到1.23的上面。这样新开的命令窗口，就是使用1.26版本，反之同理。

One more thing

构建项目可以通过go-size-analyzer分析二进制文件的大小。

禁用CGO
去除调试信息
移除路径信息

减少二进制文件大小。

CGO_ENABLED=0 go build -ldflags="-s -w" -trimpath -o myapp main.go

而代码层面，为了减少最终二进制文件大小，应该做的是

减少代码的动态反射
使用构建标签减少非必要的引用
谨慎使用匿名导入

使用构建标签减少非必要的引用

db_basic.go

//go:build !cloud_db

package main

import "fmt"

func connectDB() {
    fmt.Println("Connecting to local SQLite database...")
}

db_cloud.go

//go:build cloud_db

package main

import (
    "fmt"
    // 假设这个包非常大，有很多依赖
    // "github.com/aws/aws-sdk-go/service/dynamodb" 
)

func connectDB() {
    fmt.Println("Connecting to heavy Cloud Database...")
    // 初始化云数据库的代码
}

main.go

package main

func main() {
    connectDB()
}

直接运行 go build，编译器会包含 db_basic.go，排除 db_cloud.go。编译出来的文件很小。

如果你想要包含高级特性的版本，运行 go build -tags cloud_db，编译器会包含 db_cloud.go，排除 db_basic.go，此时才会把那些沉重的云数据库依赖打包进去。

相当于一种选择编译的技巧。

谨慎使用匿名导入

// main_plugin.go
package main

import (
	"fmt"
	_ "plugin" // 仅仅是导入了 plugin 包，哪怕使用空白标识符忽略它
)

type HeavyService struct{}

// 未导出的方法 1（未使用）
func (s *HeavyService) unusedMethod1() {
	fmt.Println("This is a very complex method doing a lot of things...")
}

// 未导出的方法 2（未使用）
func (s *HeavyService) unusedMethod2() {
	fmt.Println("Another unused complex method...")
}

func main() {
	fmt.Println("Hello, World!")
}

编译行为分析：当你使用 go build main_plugin.go 编译时，由于引入了 plugin 包，链接器将该二进制文件标记为支持动态链接。

链接器会这样想：“既然支持动态加载插件，我不知道未来加载进来的插件会不会通过反射或其他机制偷偷调用 HeavyService.unusedMethod1。为了安全起见，我不能删掉它！”

结果是：

unusedMethod1、unusedMethod2 等所有未导出的方法都会被强行保留。
这些方法内部引用的其他包（如 fmt 内部更深层的依赖）、常量、字符串，也全都会被牵连保留。
最终编译出的二进制文件体积会异常膨胀。

参考链接

【1】 Datadog 如何将其 Agent 的 Go 二进制文件缩减 77% https://mp.weixin.qq.com/s/SW3-tI-OdtvladmWf-SLpg

Do you still remember the “rule zero” I brought up before? Do not refactor when the marginal benefit is zero. I have already run into twice the situation where I could not upgrade a project’s Go version because the behavior of the underlying Go toolchain changed.

Because of limits in my work environment—CI not supporting it—I cannot use the latest golang there day to day.

If you use VS Code as your editor, a tension appears: dlv is generally built with the newest golang, and dlv relies on go mod tidy. If you run go mod tidy, the dependency graph pruning rules mean that after moving to a higher Go version the tree is recomputed and go.mod ends up rewritten.

To keep multiple Go versions on Windows at once without breaking local caches for go mod and go install, the Go project documents a multi-version workflow: go install golang.org/dl/go<version>@latest. The core idea is to put each Go version in its own directory and switch flexibly via environment variables.

Each SDK version lives in isolation and does not disturb the others. Caches for go mod and go install (by default %USERPROFILE%\go\pkg\mod and %USERPROFILE%\go\bin) are shared globally. That is intentional: the module cache and installed binaries are usually version-agnostic or backward compatible. When different Go versions compile the same module, they reuse the cache and save disk space and time.

In real use, a few snags still show up.

Sticking points

After configuring GOPROXY, I installed the newest golang available for my current setup (go 1.26.1) and put it on PATH.

Then I installed a specific Go toolchain:

# In PowerShell or CMD, use go install to fetch the version you need. These commands download a version-specific launcher.
go install golang.org/dl/go1.23.12@latest
# You should then see go1.23.12.exe under `%USERPROFILE%\go\bin`.
go1.23.12 download
# This step often fails in China because of network issues!

I downloaded go1.23.12.windows-amd64.zip, placed it under %USERPROFILE%\sdk\go1.23.12, and extracted the go directory into %USERPROFILE%\sdk\go1.23.12, but the tool still reported a download failure.

So I read the source for that command. go1.23.12 maps to dl\go1.23.12\main.go in https://github.com/golang/dl; the important part is the file checks in dl\internal\version\version.go.

func install(targetDir, version string) error {
	if _, err := os.Stat(filepath.Join(targetDir, unpackedOkay)); err == nil {
		log.Printf("%s: already downloaded in %v", version, targetDir)
		return nil
	}

	if err := os.MkdirAll(targetDir, 0755); err != nil {
		return err
	}
	goURL := versionArchiveURL(version)
	res, err := http.Head(goURL)
	if err != nil {
		return err
	}
	if res.StatusCode == http.StatusNotFound {
		return fmt.Errorf("no binary release of %v for %v/%v at %v", version, getOS(), runtime.GOARCH, goURL)
	}
	if res.StatusCode != http.StatusOK {
		return fmt.Errorf("server returned %v checking size of %v", http.StatusText(res.StatusCode), goURL)
	}
	base := path.Base(goURL)
	archiveFile := filepath.Join(targetDir, base)
	if fi, err := os.Stat(archiveFile); err != nil || fi.Size() != res.ContentLength {
		if err != nil && !os.IsNotExist(err) {
			// Something weird. Don't try to download.
			return err
		}
		if err := copyFromURL(archiveFile, goURL); err != nil {
			return fmt.Errorf("error downloading %v: %v", goURL, err)
		}
		fi, err = os.Stat(archiveFile)
		if err != nil {
			return err
		}
		if fi.Size() != res.ContentLength {
			return fmt.Errorf("downloaded file %s size %v doesn't match server size %v", archiveFile, fi.Size(), res.ContentLength)
		}
	}
	wantSHA, err := slurpURLToString(goURL + ".sha256")
	if err != nil {
		return err
	}
	if err := verifySHA256(archiveFile, strings.TrimSpace(wantSHA)); err != nil {
		return fmt.Errorf("error verifying SHA256 of %v: %v", archiveFile, err)
	}
	log.Printf("Unpacking %v ...", archiveFile)
	if err := unpackArchive(targetDir, archiveFile); err != nil {
		return fmt.Errorf("extracting archive %v: %v", archiveFile, err)
	}
	if err := os.WriteFile(filepath.Join(targetDir, unpackedOkay), nil, 0644); err != nil {
		return err
	}
	log.Printf("Success. You may now run '%v'", version)
	return nil
}

After go1.23.12.windows-amd64.zip is present, the tool computes SHA256, compares it with the value published remotely, unpacks, and writes the .unpacked-success marker. To skip that locally I could either edit dl\internal\version\version.go and rebuild, or create .unpacked-success under %USERPROFILE%\sdk\go1.23.12; I picked the second option.

go1.23.12 version
go version go1.23.12 windows/amd64

With that working, I tried building a project; even after adjusting env vars the build still failed.

go1.23.12 clean -cache
go1.23.12 clean -modcache
go1.23.12 clean -testcache

# go1.23.12 env -w GOPROXY=
# go1.23.12 env -w GONOPROXY=
# go1.23.12 env -w GOPRIVATE=
# go1.23.12 env -w GOINSECURE=
go1.23.12 env -w GOSUMDB=off
go1.23.12 env -w GO111MODULE=on
go1.23.12 build -v -ldflags="-checklinkname=0"

So I went back to the first approach: switching Go versions by reordering entries on PATH 🤣. On Windows 11, to use 1.26, move the 1.26 go bin directory above the 1.23 one on PATH. New command windows then use 1.26; reverse the order for 1.23.

One more thing

When you build, you can use go-size-analyzer to study binary size.

Disable CGO
Strip debug symbols
Drop path metadata from the binary

to shrink the executable.

CGO_ENABLED=0 go build -ldflags="-s -w" -trimpath -o myapp main.go

At the source level, to reduce final binary size you should:

Cut down on dynamic reflection
Use build tags to drop optional imports
Be careful with blank imports

Use build tags to omit non-essential references

db_basic.go

//go:build !cloud_db

package main

import "fmt"

func connectDB() {
    fmt.Println("Connecting to local SQLite database...")
}

db_cloud.go

//go:build cloud_db

package main

import (
    "fmt"
    // Suppose this package is huge with many dependencies
    // "github.com/aws/aws-sdk-go/service/dynamodb"
)

func connectDB() {
    fmt.Println("Connecting to heavy Cloud Database...")
    // Code to initialize the cloud database
}

main.go

package main

func main() {
    connectDB()
}

A plain go build includes db_basic.go and excludes db_cloud.go, yielding a small binary.

For a build with the advanced path, run go build -tags cloud_db: the compiler includes db_cloud.go, excludes db_basic.go, and only then pulls in the heavy cloud database dependencies.

That is essentially a selective compilation technique.

Be careful with blank imports

// main_plugin.go
package main

import (
	"fmt"
	_ "plugin" // Only imports plugin; even with _, the package is linked
)

type HeavyService struct{}

// Unexported method 1 (unused)
func (s *HeavyService) unusedMethod1() {
	fmt.Println("This is a very complex method doing a lot of things...")
}

// Unexported method 2 (unused)
func (s *HeavyService) unusedMethod2() {
	fmt.Println("Another unused complex method...")
}

func main() {
	fmt.Println("Hello, World!")
}

What the linker does: When you go build main_plugin.go, importing plugin marks the binary as supporting dynamic loading.

The linker reasons: “Because plugins may be loaded later, I cannot know whether a plugin will call HeavyService.unusedMethod1 via reflection or other tricks. To be safe I must keep it!”

The outcome:

unusedMethod1, unusedMethod2, and similar unexported methods are retained.
Packages they pull in (deeper dependencies under fmt, constants, strings, etc.) are kept as well.
The final binary balloons in size.

References

【1】
How Datadog shrunk its Agent’s Go binary by 77%
https://mp.weixin.qq.com/s/SW3-tI-OdtvladmWf-SLpg

以前に挙げた「ゼロ番の法則」を覚えていますか。限界利益がゼロになるリファクタはやらない、というやつです。底辺の Go 実装の挙動変化のせいで、プロジェクトの Go バージョンを上げられなくなった経験は、すでに 2 回あります。

職場環境の制約（CI が対応していないなど）のため、業務環境では常に最新の golang を使えません。

エディタに VS Code を使うと、次のような問題が出ます。
dlv はだいたい最新の golang でビルドされ、go mod tidy に依存します。
go mod tidy を実行すると、依存グラフのトリミング方針により、高い Go バージョンにすると依存ツリーが再計算され、最終的に go.mod が書き換わります。

Windows 上で複数バージョンの Go を共存させ、go mod と go install のローカルキャッシュを壊さないようにするには、公式が示す複数バージョン管理の流れ go install golang.org/dl/go<version>@latest があります。考え方は、バージョンごとに別ディレクトリへインストールし、環境変数で柔軟に切り替えることです。

各バージョンの SDK は隔離され、互いに干渉しません。
go mod と go install のキャッシュ（既定では %USERPROFILE%\go\pkg\mod と %USERPROFILE%\go\bin）はグローバルで共有されます。モジュールキャッシュとインストールした実行ファイルは多くの場合バージョンに依存しないか後方互換なので、設計としてそうなっています。異なる Go で同一モジュールをビルドすると既存キャッシュを使え、容量と時間を節約できます。

実運用では、いくつかつまずきどころがあります。

つまずき

GOPROXY を設定したうえで、手元の golang として利用できる最新（go 1.26.1）を入れ、PATH に載せました。

続いて特定バージョンの Go ツールチェーンを入れます。

# PowerShell または CMD で、必要なバージョンを go install で取得する。バージョン専用のランチャーが落ちてくる。
go install golang.org/dl/go1.23.12@latest
# `%USERPROFILE%\go\bin` に `go1.23.12.exe` ができる。
go1.23.12 download
# 中国ではネットワークの都合で、このステップが失敗しがち

go1.23.12.windows-amd64.zip を %USERPROFILE%\sdk\go1.23.12 に置き、アーカイブ内の go フォルダを同じ %USERPROFILE%\sdk\go1.23.12 に展開しても、やはりダウンロード失敗のままでした。

そこでこのコマンドのソースを読みました。go1.23.12 は https://github.com/golang/dl の dl\go1.23.12\main.go に対応し、肝は dl\internal\version\version.go のファイル判定です。

func install(targetDir, version string) error {
	if _, err := os.Stat(filepath.Join(targetDir, unpackedOkay)); err == nil {
		log.Printf("%s: already downloaded in %v", version, targetDir)
		return nil
	}

	if err := os.MkdirAll(targetDir, 0755); err != nil {
		return err
	}
	goURL := versionArchiveURL(version)
	res, err := http.Head(goURL)
	if err != nil {
		return err
	}
	if res.StatusCode == http.StatusNotFound {
		return fmt.Errorf("no binary release of %v for %v/%v at %v", version, getOS(), runtime.GOARCH, goURL)
	}
	if res.StatusCode != http.StatusOK {
		return fmt.Errorf("server returned %v checking size of %v", http.StatusText(res.StatusCode), goURL)
	}
	base := path.Base(goURL)
	archiveFile := filepath.Join(targetDir, base)
	if fi, err := os.Stat(archiveFile); err != nil || fi.Size() != res.ContentLength {
		if err != nil && !os.IsNotExist(err) {
			// Something weird. Don't try to download.
			return err
		}
		if err := copyFromURL(archiveFile, goURL); err != nil {
			return fmt.Errorf("error downloading %v: %v", goURL, err)
		}
		fi, err = os.Stat(archiveFile)
		if err != nil {
			return err
		}
		if fi.Size() != res.ContentLength {
			return fmt.Errorf("downloaded file %s size %v doesn't match server size %v", archiveFile, fi.Size(), res.ContentLength)
		}
	}
	wantSHA, err := slurpURLToString(goURL + ".sha256")
	if err != nil {
		return err
	}
	if err := verifySHA256(archiveFile, strings.TrimSpace(wantSHA)); err != nil {
		return fmt.Errorf("error verifying SHA256 of %v: %v", archiveFile, err)
	}
	log.Printf("Unpacking %v ...", archiveFile)
	if err := unpackArchive(targetDir, archiveFile); err != nil {
		return fmt.Errorf("extracting archive %v: %v", archiveFile, err)
	}
	if err := os.WriteFile(filepath.Join(targetDir, unpackedOkay), nil, 0644); err != nil {
		return err
	}
	log.Printf("Success. You may now run '%v'", version)
	return nil
}

go1.23.12.windows-amd64.zip を取得したあと SHA256 を計算し、リモートの値と突き合わせ、展開して .unpacked-success を作ります。
ローカルでこの過程を飛ばすには、dl\internal\version\version.go を直して再ビルドするか、%USERPROFILE%\sdk\go1.23.12 に .unpacked-success を置くか—こちらは後者を選びました。

go1.23.12 version
go version go1.23.12 windows/amd64

コマンドが通ったあと、あるプロジェクトをビルドしましたが、env を設定してもビルドは失敗したままでした。

go1.23.12 clean -cache
go1.23.12 clean -modcache
go1.23.12 clean -testcache

# go1.23.12 env -w GOPROXY=
# go1.23.12 env -w GONOPROXY=
# go1.23.12 env -w GOPRIVATE=
# go1.23.12 env -w GOINSECURE=
go1.23.12 env -w GOSUMDB=off
go1.23.12 env -w GO111MODULE=on
go1.23.12 build -v -ldflags="-checklinkname=0"

最初の方針に戻り、PATH の順で Go バージョンを切り替えることにしました 🤣。
Windows 11 では 1.26 を使うなら、1.26 の go を 1.23 より上に並べる。新しいコマンドウィンドウでは 1.26 が使われ、逆にすれば 1.23 側になります。

One more thing

ビルド時は go-size-analyzer でバイナリサイズを分析できます。

CGO を無効にする
デバッグ情報を除く
パス情報を落とす

ことでバイナリを小さくできます。

CGO_ENABLED=0 go build -ldflags="-s -w" -trimpath -o myapp main.go

コード面では、最終バイナリを小さくするために次を意識します。

動的リフレクションを減らす
ビルドタグで不要な参照を外す
匿名インポートに注意する

ビルドタグで不要な参照を減らす

db_basic.go

//go:build !cloud_db

package main

import "fmt"

func connectDB() {
    fmt.Println("Connecting to local SQLite database...")
}

db_cloud.go

//go:build cloud_db

package main

import (
    "fmt"
    // このパッケージが巨大で依存が多いと仮定
    // "github.com/aws/aws-sdk-go/service/dynamodb"
)

func connectDB() {
    fmt.Println("Connecting to heavy Cloud Database...")
    // クラウド DB 初期化のコード
}

main.go

package main

func main() {
    connectDB()
}

そのまま go build すると db_basic.go が入り db_cloud.go は外れ、出力は小さくなります。

高度な構成にしたい場合は go build -tags cloud_db とすると db_cloud.go が入り db_basic.go は外れ、重いクラウド DB 依存が初めてバンドルされます。

選択的コンパイルのテクニックに相当します。

匿名インポートに注意する

// main_plugin.go
package main

import (
	"fmt"
	_ "plugin" // plugin をインポートするだけ。空白識別子でもリンクされる
)

type HeavyService struct{}

// エクスポートされていないメソッド 1（未使用）
func (s *HeavyService) unusedMethod1() {
	fmt.Println("This is a very complex method doing a lot of things...")
}

// エクスポートされていないメソッド 2（未使用）
func (s *HeavyService) unusedMethod2() {
	fmt.Println("Another unused complex method...")
}

func main() {
	fmt.Println("Hello, World!")
}

コンパイル・リンクの挙動：
go build main_plugin.go で plugin を入れると、バイナリは動的ロード対応として印が付きます。

リンカの考え方は「動的プラグインを将来読み込むかもしれない。読み込まれた側がリフレクションなどで HeavyService.unusedMethod1 を呼ぶかもしれない。安全のため削れない」となります。

結果：

unusedMethod1 や unusedMethod2 など、エクスポートされていないメソッドが残される
それらが引っ張る他パッケージ（fmt より深い依存など）、定数、文字列も連鎖的に残る
最終バイナリが異常に肥大化する

参考リンク

【1】
Datadog が Agent の Go バイナリを 77% 削減した話（記事紹介・中国語）
https://mp.weixin.qq.com/s/SW3-tI-OdtvladmWf-SLpg

Помните «правило ноль», о котором я уже говорил? Не делайте рефакторинг с нулевой предельной отдачей. У меня уже дважды была ситуация, когда из‑за изменений в реализации нижележащей версии Go нельзя было обновить версию Go в проекте.

Из‑за ограничений рабочей среды (CI не поддерживает нужное) нельзя постоянно пользоваться самым свежим golang в том же окружении, где ведётся работа.

Если редактор — VS Code, возникает такая связка:
dlv обычно собирают на новейшем golang, а dlv опирается на go mod tidy.
После go mod tidy политика обрезки графа зависимостей при переходе на более высокую версию Go пересчитывает дерево и в итоге переписывает go.mod.

Чтобы на Windows держать несколько версий Go и не ломать локальный кэш для go mod и go install, в экосистеме Go есть схема с go install golang.org/dl/go<version>@latest: разные версии ставятся в разные каталоги, переключение — через переменные окружения.

SDK разных версий изолированы и не мешают друг другу.
Кэши go mod и go install (по умолчанию %USERPROFILE%\go\pkg\mod и %USERPROFILE%\go\bin) общие для пользователя — так задумано: кэш модулей и установленные бинарники обычно не привязаны к одной версии компилятора или обратно совместимы. Разные версии Go при сборке одного и того же модуля могут переиспользовать кэш и экономить место и время.

На практике всё равно всплывают узкие места.

Где застреваешь

После настройки GOPROXY я поставил максимально новый golang для текущей связки (go 1.26.1) и добавил его в PATH.

Затем ставлю конкретную цепочку инструментов Go:

# В PowerShell или CMD: go install качает нужную версию — это отдельный лаунчер для версии.
go install golang.org/dl/go1.23.12@latest
# В `%USERPROFILE%\go\bin` появится go1.23.12.exe.
go1.23.12 download
# В Китае этот шаг часто падает из‑за сети.

Я скачал go1.23.12.windows-amd64.zip, положил в %USERPROFILE%\sdk\go1.23.12, распаковал каталог go в %USERPROFILE%\sdk\go1.23.12 — сообщение о неудачной загрузке всё равно оставалось.

Тогда я прочитал исходники этой команды. go1.23.12 соответствует dl\go1.23.12\main.go в https://github.com/golang/dl; ключевое — проверки файлов в dl\internal\version\version.go.

func install(targetDir, version string) error {
	if _, err := os.Stat(filepath.Join(targetDir, unpackedOkay)); err == nil {
		log.Printf("%s: already downloaded in %v", version, targetDir)
		return nil
	}

	if err := os.MkdirAll(targetDir, 0755); err != nil {
		return err
	}
	goURL := versionArchiveURL(version)
	res, err := http.Head(goURL)
	if err != nil {
		return err
	}
	if res.StatusCode == http.StatusNotFound {
		return fmt.Errorf("no binary release of %v for %v/%v at %v", version, getOS(), runtime.GOARCH, goURL)
	}
	if res.StatusCode != http.StatusOK {
		return fmt.Errorf("server returned %v checking size of %v", http.StatusText(res.StatusCode), goURL)
	}
	base := path.Base(goURL)
	archiveFile := filepath.Join(targetDir, base)
	if fi, err := os.Stat(archiveFile); err != nil || fi.Size() != res.ContentLength {
		if err != nil && !os.IsNotExist(err) {
			// Something weird. Don't try to download.
			return err
		}
		if err := copyFromURL(archiveFile, goURL); err != nil {
			return fmt.Errorf("error downloading %v: %v", goURL, err)
		}
		fi, err = os.Stat(archiveFile)
		if err != nil {
			return err
		}
		if fi.Size() != res.ContentLength {
			return fmt.Errorf("downloaded file %s size %v doesn't match server size %v", archiveFile, fi.Size(), res.ContentLength)
		}
	}
	wantSHA, err := slurpURLToString(goURL + ".sha256")
	if err != nil {
		return err
	}
	if err := verifySHA256(archiveFile, strings.TrimSpace(wantSHA)); err != nil {
		return fmt.Errorf("error verifying SHA256 of %v: %v", archiveFile, err)
	}
	log.Printf("Unpacking %v ...", archiveFile)
	if err := unpackArchive(targetDir, archiveFile); err != nil {
		return fmt.Errorf("extracting archive %v: %v", archiveFile, err)
	}
	if err := os.WriteFile(filepath.Join(targetDir, unpackedOkay), nil, 0644); err != nil {
		return err
	}
	log.Printf("Success. You may now run '%v'", version)
	return nil
}

После появления go1.23.12.windows-amd64.zip считается SHA256, сверяется с удалённым значением, архив распаковывается и создаётся маркер .unpacked-success.
Обойти это локально можно либо правкой dl\internal\version\version.go и пересборкой, либо созданием файла .unpacked-success в %USERPROFILE%\sdk\go1.23.12 — я выбрал второе.

go1.23.12 version
go version go1.23.12 windows/amd64

Когда команды прошли, я попробовал собрать проект: даже после настройки переменных окружения сборка не удалась.

go1.23.12 clean -cache
go1.23.12 clean -modcache
go1.23.12 clean -testcache

# go1.23.12 env -w GOPROXY=
# go1.23.12 env -w GONOPROXY=
# go1.23.12 env -w GOPRIVATE=
# go1.23.12 env -w GOINSECURE=
go1.23.12 env -w GOSUMDB=off
go1.23.12 env -w GO111MODULE=on
go1.23.12 build -v -ldflags="-checklinkname=0"

Вернулся к исходной идее: переключать версии Go порядком записей в PATH 🤣.
В Windows 11 для 1.26 поднимите каталог с go от 1.26 выше, чем от 1.23. В новом окне терминала будет 1.26; обратный порядок — 1.23.

One more thing

При сборке можно анализировать размер бинарника через go-size-analyzer.

Отключить CGO
Убрать отладочную информацию
Убрать сведения о путях

— так уменьшается размер исполняемого файла.

CGO_ENABLED=0 go build -ldflags="-s -w" -trimpath -o myapp main.go

На уровне кода, чтобы уменьшить итоговый бинарник:

Меньше динамической рефлексии
Сборочные теги, чтобы не тянуть лишние импорты
Осторожнее с пустым импортом _

Сборочные теги для отсечения ненужных ссылок

db_basic.go

//go:build !cloud_db

package main

import "fmt"

func connectDB() {
    fmt.Println("Connecting to local SQLite database...")
}

db_cloud.go

//go:build cloud_db

package main

import (
    "fmt"
    // Допустим, пакет огромный и тянет много зависимостей
    // "github.com/aws/aws-sdk-go/service/dynamodb"
)

func connectDB() {
    fmt.Println("Connecting to heavy Cloud Database...")
    // Инициализация облачной БД
}

main.go

package main

func main() {
    connectDB()
}

Обычный go build подключает db_basic.go и исключает db_cloud.go — бинарник маленький.

Нужна «тяжёлая» конфигурация — go build -tags cloud_db: включается db_cloud.go, исключается db_basic.go, и только тогда подтягиваются зависимости облачной БД.

По сути приём выборочной компиляции.

Пустой импорт использовать осмотрительно

// main_plugin.go
package main

import (
	"fmt"
	_ "plugin" // Импортирован пакет plugin, даже через пустой идентификатор
)

type HeavyService struct{}

// Неэкспортируемый метод 1 (не используется)
func (s *HeavyService) unusedMethod1() {
	fmt.Println("This is a very complex method doing a lot of things...")
}

// Неэкспортируемый метод 2 (не используется)
func (s *HeavyService) unusedMethod2() {
	fmt.Println("Another unused complex method...")
}

func main() {
	fmt.Println("Hello, World!")
}

Поведение линкера:
при go build main_plugin.go из‑за plugin бинарник помечается как поддерживающий динамическую загрузку.

Линкер рассуждает так: «Раз возможна подгрузка плагинов, неизвестно, не вызовет ли плагин HeavyService.unusedMethod1 через рефлексию. Ради безопасности методы не выкидываю».

Итог:

unusedMethod1, unusedMethod2 и прочие неэкспортируемые методы остаются.
Остаются связанные с ними пакеты (включая глубже fmt), константы, строки.
Размер бинарника сильно растёт.

Ссылки

【1】
Как Datadog уменьшил Go-бинарник своего Agent на 77% (обзорная статья, китайский язык)
https://mp.weixin.qq.com/s/SW3-tI-OdtvladmWf-SLpg

打通智能家居数据流动的上下游

Thu, 19 Mar 2026 00:00:00 +0000

如果把一个社会人的一天的生活按照时间顺序解构，那基本流程是起床，吃饭，通勤，上班，下班，吃饭，睡觉。

数据堰塞湖

在这个过程中，可能会涉及到电脑，家用电器，汽车，手机，外卖软件等生活用品/互联网服务。

以智能家居场景为例，由于各大厂商之间的相互竞争，个人数据实际是处于各自独立的“信息孤岛状态”。比如我买了一个米家的温度传感器，但空调是海尔品牌的。因为两个品牌的数据不互通，导致无法实现“温度传感器高于36°时打开空调”这种需求；又比如我用了小米的大模型音箱，询问它当前的室温，它只能通过网络搜索，告诉我区县级别的天气温度/湿度。而这部分数据，实际上一直存在海尔空调的温度传感器中。

我把这种数据不互联互通的情况称为“数据堰塞湖”。

上下文丢失

以上午上班通勤的活动为例，“在家吃饭”和“开车去上班”发生在两个不同的场景。但从家到地下停车场的这个过程，实际上“车”是不知道的。为了缩小问题复杂度，我们假设使用了全套的小米智能家居，以及小米汽车。理论上，通过小米手机/小米智能手环上的蓝牙信号的衰减/增强可以判断车到人的距离，进而判断是人离车，还是人开车。然而蓝牙设备能记住的设备数量毕竟有限，只有在小范围场景才能适用这种解决方案。

上下文丢失，更多的是一种跨设备，跨系统的问题。如果说“数据堰塞湖”是一种人为的上下文丢失，那么场景的切换也会带来上下文的丢失。

举个例子，当我们走进博物馆，本质上博物馆是可以通过票证凭据和摄像头识别“知道”游客已经入馆的。但由于这套系统的运作成本过于巨大，实际操作是丢弃“数据上下文”，让游客自行游玩。

//prompt: 画一个图片，内容是人进入博物馆之后，博物馆机器人打招呼，而且游客的手机屏幕切换为一个人形的导航。使用动漫风格。

意念编程（Spec Coding）与主动陪伴（Active Companionship）

以上问题并非没有解决方案。

在当前的意念编程设计中，AI作为新的流量入口，用户告诉智能音箱“打开客厅的灯”，本质是表达一种期望（spec）。AI作为一种“控制器”会做好该期望的实际交付工作（找到客厅中的灯，并打开）。

但意念编程的问题在于“人主动”，而不是“物主动”。在当前版本的智能家居中，需要人为设计很多自动化场景去智能地控制电子设备（比如感应到人，并且时间在日落之后，触发自动开灯），但在我看来，AGI的第一性原理是数据保存在用户自己的消费电子终端，平台基于写时复制（copy on write），最小化地使用用户的数据。

如果基础传感器数据存在用户本地，那么自始至终就不存在“信息孤岛”的问题。而携带个人数据的消费电子终端，可以通过传感器和其他设备（车）互联。

而基于AGI之上的主动陪伴（Active Companionship）,则是智能家居自动化控制流/家居机器人的关键。以午睡这个场景为例，实际上，通过累计足够的数据（用户在工作日12点之后通常会拉窗帘，并关灯），建立相关的关联关系，智能家居应该是可以直接给用户提出一个建议（工作日中午时段当感知到你之后，我会关灯并拉窗帘），并在获取用户授权后，工作日自动化执行。

If we deconstruct a social person’s daily life in chronological order, the basic flow is: wake up, eat, commute, work, get off work, eat, sleep.

Data Barrier Lake

In this process, various consumer goods and internet services may be involved—computers, home appliances, cars, phones, food delivery apps, and so on.

Take the smart home scenario as an example. Due to competition among major manufacturers, personal data is effectively trapped in isolated “information silos.” For instance, I bought a Mijia temperature sensor, but the air conditioner is a Haier brand. Because the two brands’ data don’t interoperate, I can’t implement a rule like “turn on the AC when the temperature sensor reads above 36°.” Or consider Xiaomi’s LLM-powered speaker: when I ask it about the current room temperature, it can only answer via web search, giving me district-level weather temperature/humidity—even though that data actually exists in the Haier AC’s temperature sensor all along.

I call this situation where data fails to interconnect “data barrier lake.”

Context Loss

Take the morning commute as an example. “Eating at home” and “driving to work” happen in two different contexts. But the car has no knowledge of the transition from home to the underground parking lot. To reduce complexity, assume we use a full Xiaomi smart home setup plus a Xiaomi car. Theoretically, Bluetooth signal attenuation/strengthening from a Xiaomi phone or smart band could indicate the distance between car and person, and thus whether the person is leaving or approaching the car. However, Bluetooth devices have a limited number of devices they can remember, so this approach only works in small-scale scenarios.

Context loss is largely a cross-device, cross-system issue. If “data barrier lake” is a man-made form of context loss, then context switching also causes context loss.

For example, when we enter a museum, the museum could in principle “know” that a visitor has entered via ticket credentials and cameras. But because the cost of running such a system is prohibitively high, the practical approach is to discard “data context” and let visitors explore on their own.

//prompt: Draw an image of a person entering a museum, a museum robot greeting them, and the visitor’s phone screen switching to a humanoid navigation interface. Use anime style.

Spec Coding and Active Companionship

These problems are not without solutions.

In current Spec Coding design, AI acts as a new traffic entry point. When a user tells a smart speaker “turn on the living room light,” they are expressing an expectation (spec). The AI, as a “controller,” handles the actual delivery of that expectation (finding the living room light and turning it on).

But the issue with Spec Coding is that it is “human-initiated” rather than “thing-initiated.” In current smart home setups, many automation scenarios must be manually designed to control devices (e.g., sense a person and, if it’s after sunset, trigger automatic lighting). In my view, the first principle of AGI is that data is stored on the user’s own consumer electronics, with platforms using copy-on-write to minimize use of user data.

If base sensor data resides locally on the user’s device, there is no “information silo” problem from the start. Consumer electronics carrying personal data can interconnect with other devices (e.g., the car) via sensors.

Active Companionship built on AGI is key to smart home automation flows and home robots. Take the afternoon nap scenario: with enough accumulated data (e.g., the user usually draws the curtains and turns off the lights after 12:00 on weekdays), correlations can be established. The smart home should be able to propose a suggestion (“On weekday afternoons, when I sense you, I’ll turn off the lights and draw the curtains”) and, after user authorization, automate it on weekdays.

社会人の一日の生活を時間順に分解すると、基本的な流れは起床、食事、通勤、出勤、退勤、食事、就寝となる。

データ堰塞湖（Data Barrier Lake）

この過程で、パソコン、家電、車、スマートフォン、フードデリバリーアプリなどの生活用品やインターネットサービスが関わってくる。

スマートホームのシーンを例にとると、各メーカー間の競争により、個人データは事実上それぞれ独立した「情報孤島」状態にある。例えば、米家の温度センサーを買ったが、エアコンはハイアール製だとする。両ブランドのデータが相互接続されていないため、「温度センサーが36°を超えたらエアコンをオンにする」といったニーズを実現できない。また、小米の大モデルスピーカーを使い、現在の室温を尋ねても、ネット検索でしか答えられず、区県レベルの天気の温度・湿度を教えてくれる。そのデータは実際にはハイアールエアコンの温度センサーにずっと存在しているのに。

私はこのデータが相互接続されない状況を「データ堰塞湖」と呼んでいる。

コンテキストの喪失

午前の通勤を例にとる。「自宅で食事」と「車で出勤」は二つの異なるシーンで発生する。しかし、家から地下駐車場までの過程は、「車」には知られていない。問題の複雑さを抑えるため、小米のスマートホーム一式と小米自動車を使っていると仮定する。理論上、小米スマートフォンやスマートバンドのBluetooth信号の減衰・増強から、車と人の距離を判断し、人が車を離れているのか、車に乗っているのかを判断できる。しかし、Bluetoothデバイスが記憶できるデバイス数には限りがあり、この解決策は小規模なシーンでのみ適用可能だ。

コンテキストの喪失は、より多くの場合、デバイス間・システム間の問題である。「データ堰塞湖」が人為的なコンテキスト喪失だとすれば、シーンの切り替えもコンテキストの喪失をもたらす。

例えば、博物館に入る時、本質的には博物館はチケットとカメラで「知る」ことができる——来館者が入館したことを。しかし、このシステムの運用コストが非常に高いため、実際には「データコンテキスト」を捨て、来館者に自由に見学させている。

//prompt: 博物館に入った人、博物館ロボットが挨拶し、来館者のスマートフォン画面が人型ナビに切り替わる画像を描く。アニメスタイルで。

Spec Coding（意念プログラミング）とActive Companionship（能動的同伴）

以上の問題に解決策がないわけではない。

現在のSpec Coding設計では、AIは新しいトラフィックの入口として機能する。ユーザーがスマートスピーカーに「リビングの照明をつけて」と伝えるのは、本質的には期待（spec）を表明している。AIは「コントローラー」として、その期待の実際の実行（リビングの照明を見つけて点灯する）を行う。

しかしSpec Codingの問題は「人が能動的」であり「物が能動的」ではないことだ。現在のスマートホームでは、電子機器をスマートに制御するために多くの自動化シーンを人為的に設計する必要がある（例えば、人を感知し、日没後の時間であれば自動点灯をトリガーする）。私の見解では、AGIの第一原理は、データがユーザー自身の消費電子端末に保存され、プラットフォームはcopy on writeに基づいてユーザーデータを最小限に使用することである。

基礎センサーデータがユーザーのローカルに存在すれば、最初から「情報孤島」の問題は存在しない。個人データを携帯する消費電子端末は、センサーと他のデバイス（車）を相互接続できる。

AGIの上に構築されたActive Companionshipは、スマートホームの自動化制御フローやホームロボットの鍵である。昼寝のシーンを例にとると、十分なデータ（ユーザーが平日12時以降に通常カーテンを閉め、照明を消す）を蓄積し、関連する相関関係を確立すれば、スマートホームはユーザーに直接提案できる（「平日の昼間、あなたを感知したら、照明を消してカーテンを閉めます」）。ユーザーの承認を得た後、平日に自動実行する。

Если деконструировать день социального человека в хронологическом порядке, базовая последовательность такова: пробуждение, еда, поездка на работу, работа, возвращение, еда, сон.

Озеро данных (Data Barrier Lake)

В этом процессе могут участвовать компьютеры, бытовая техника, автомобили, телефоны, приложения доставки еды и другие потребительские товары и интернет-сервисы.

Возьмём сценарий умного дома. Из-за конкуренции между крупными производителями персональные данные фактически оказываются в изолированных «информационных островах». Например, я купил температурный датчик Mijia, а кондиционер — Haier. Поскольку данные двух брендов не обмениваются, невозможно реализовать правило «включить кондиционер, когда датчик показывает выше 36°». Или: я использую колонку Xiaomi с большой языковой моделью и спрашиваю текущую температуру в комнате — она может ответить только через веб-поиск, сообщая температуру/влажность на уровне района. Хотя эти данные всё время есть в температурном датчике кондиционера Haier.

Я называю такую ситуацию, когда данные не связаны между собой, «озером данных» (data barrier lake).

Потеря контекста

Возьмём утреннюю поездку на работу. «Еда дома» и «поездка на работу» происходят в двух разных контекстах. Но машина не знает о переходе от дома до подземной парковки. Чтобы упростить задачу, допустим, используется полный комплект умного дома Xiaomi и автомобиль Xiaomi. Теоретически по затуханию/усилению Bluetooth-сигнала с телефона или умного браслета Xiaomi можно определить расстояние между машиной и человеком и понять, человек уходит от машины или подходит к ней. Однако Bluetooth-устройства могут запомнить ограниченное число устройств, поэтому такой подход применим только в малых масштабах.

Потеря контекста — это в основном проблема между устройствами и системами. Если «озеро данных» — это искусственная потеря контекста, то смена сценария тоже приводит к потере контекста.

Например, когда мы входим в музей, музей в принципе может «знать» о приходе посетителя по билету и камерам. Но из-за чрезмерно высоких затрат на такую систему на практике от «контекста данных» отказываются и дают посетителям свободно осматривать экспозицию.

//prompt: Нарисуй изображение: человек входит в музей, робот музея приветствует его, экран телефона посетителя переключается на человекоподобную навигацию. В стиле аниме.

Spec Coding и Active Companionship

У этих проблем есть решения.

В текущей концепции Spec Coding ИИ выступает новой точкой входа. Когда пользователь говорит умной колонке «включи свет в гостиной», он выражает ожидание (spec). ИИ как «контроллер» выполняет это ожидание (находит свет в гостиной и включает его).

Но проблема Spec Coding в том, что инициатива исходит от «человека», а не от «вещи». В нынешних умных домах приходится вручную проектировать множество сценариев автоматизации (например, обнаружить человека и, если уже после заката, включить свет). По моему мнению, первый принцип AGI — данные хранятся на собственных устройствах пользователя, а платформы используют copy-on-write, минимизируя использование пользовательских данных.

Если базовые данные сенсоров хранятся локально у пользователя, проблемы «информационных островов» изначально не возникает. Устройства с персональными данными могут связываться с другими устройствами (например, машиной) через сенсоры.

Active Companionship, построенный на AGI, — ключ к потокам автоматизации умного дома и домашним роботам. Возьмём сценарий дневного сна: накопив достаточно данных (пользователь обычно закрывает шторы и выключает свет после 12:00 в будни), можно выявить корреляции. Умный дом должен уметь предложить: «В будние дни в обеденное время, когда я почувствую тебя, выключу свет и закрою шторы» — и после одобрения пользователя автоматически выполнять это по будням.

信息技术的熵减定律

Sun, 01 Mar 2026 00:00:00 +0000

我提出过信息技术的第一悖论：信息技术是一种反人类的技术。而在《公有云的诸神黄昏》文章中，我总结了信息技术行业的熵增定律以及“0号规律”——边际收益为0的代码重构没人愿意做。

今天我要反驳0号规律，并提出一个新“熵减定律”——在后现代编程中，人类存在的意义在于降低代码的时间序列复杂度（n<n-1），确保代码的确定性。

屎山代码存在的合理性以及重构的必要性

如果你反编译过一些游戏的安卓apk文件，就会发现里面存在大量冗余的美术资源，这些美术资源跟当前版本没半毛钱关系。它们是一种历史遗留的垃圾代码。

而由于0号规律的存在，没有任何程序员愿意去重构以及删除相关的美术资源。这也解释了“王者荣耀”的安装包一再膨胀，直至后来提出了“清理历史道具”和“模块化按需下载资源”的解题思路，当然有一部分人吐槽更新完之后“粽子”变成一堆堆人机一样的图标。

至于为什么这么做，其实涉及到博弈论的一个基本论述：局部最优解未必全局最优。对于游戏开发者而言，为了增加新的收入，必定需要构造新的叙事。而清理历史债务不会在游戏的财务上有所体现。

但对于游戏用户和运营公司而言，日渐膨胀的安装包推高了CDN的流量成本，垃圾代码的堆积也延长了用户下载打开游戏所需要的时间，甚至有可能引起操作卡顿。

如果用熵增定律去衡量软件开发的流程，就会发现程序设计的屎山是一种必然，从某种程度上是软件开发工程师的一种“防御性编程”。

防御性编程还是过度设计？

从政治经济学角度出发，软件开发工程师本质上依旧是不掌握生产资料的“进城农民工”。从入职公司的那一刻起，所思所写都是公司的“数字资产”。这在美剧《硅谷》中亦有所体现：Richard在Hooli工作时，利用业余时间（但部分使用了公司电脑进行测试）开发了革命性的无损数据压缩算法，并以此为基础创立了Pied Piper公司。

当Pied Piper开始崭露头角后，Hooli（由Gavin Belson领导）在第二季中正式起诉Pied Piper，指控Richard“窃取”了属于Hooli的知识产权（copyright infringement），声称根据Richard与Hooli签订的雇佣合同（包含发明转让条款），他在职期间开发的代码及其相关技术归Hooli所有。

与公司抗衡是不明智的。因此为了规避被裁员的风险，软件开发工程师除了不写文档之外，滥用设计模式、使用反射隐式调用方法、过度设计，也都是常见手法。

我有时真的搞不懂，用人单位为了压低薪资而询问我各种“单机高并发”，“秒杀”问题。最夸张的莫过于问我“数百万用户同时在线”这种荒诞的问题。而在平行世界的另一边，我看了一下那份岗位对应的薪资对应的职责。

在有AI帮助的情况下，我当然可以设计一个流程去适配这些场景。问题在于，在使用了Redis分布式锁，Redis集群，kubernetes HPA动态扩缩容，微服务、消息中间件解耦之后，代码产生的实际收益在于哪里？我们做出来的产品是否真的有那么多付费的用户？把一个重要的系统交给一个边缘的外部服务商员工是否合适？

回到那个面试场景，最终我没有跟他们浪费时间，我建议他们通过新浪微博发起抽奖解决商品秒杀的场景问题，然后我Command+Q结束了整个远程会话。

科学熵减大家都轻松

回望第二次世界大战之后的世界，我们在一片废墟之上，又重新构建了新的高楼大厦。信息技术到现在未到百年，终末的号角便已吹响。如果说这个行业也会随着人工智能技术而逐渐式微，那么少用C++避免猝死，多用GC语言，做好AI coding的最后QA。

这样每天下班还能看到尚未暗淡的天空，不好吗？

n<n-1

I once proposed the first paradox of information technology: information technology is an anti-human technology. In my article The Twilight of the Public Cloud, I summarized the law of entropy increase in the IT industry and “Rule Zero” — nobody wants to do code refactoring whose marginal benefit is zero.

Today I want to refute Rule Zero and propose a new “The Second Law of Information Technology” — in post-modern programming, the human purpose is to reduce the time-series complexity of code (n<n-1) and ensure code determinism.

The Rationality of Legacy Code and the Necessity of Refactoring

If you have ever decompiled the Android APK of a game, you will find a large number of redundant art assets inside — assets completely unrelated to the current version. They are historically inherited garbage code.

Due to Rule Zero, no programmer is willing to refactor or delete these art assets. This also explains why the installation package of Honor of Kings kept growing, until solutions like “clear historical props” and “modular on-demand resource downloads” were finally proposed — though some players complained that after the update, the “Zongzi” skin turned into a pile of bot-like icons.

Why does this happen? It comes down to a basic principle of game theory: a local optimum is not necessarily a global optimum. For game developers, constructing new narratives is essential for generating new revenue. Clearing historical technical debt has no direct reflection on the game’s financials.

But for players and operators, bloated installation packages drive up CDN traffic costs, and the accumulation of garbage code prolongs the time users need to download and open the game — and may even cause lag.

If you use the law of entropy increase to evaluate the software development process, you will find that a “shit mountain” codebase is inevitable — to some extent, it is a form of “defensive programming” by software engineers.

Defensive Programming or Over-Engineering?

From a political-economic perspective, software engineers are fundamentally still “migrant workers” who do not own the means of production. From the moment they join a company, everything they think and write becomes the company’s “digital assets.” This is reflected in the US TV series Silicon Valley: while working at Hooli, Richard used his personal time (though partially on company computers for testing) to develop a revolutionary lossless data compression algorithm, and founded Pied Piper on that basis.

As Pied Piper began to gain traction, Hooli (led by Gavin Belson) formally sued Pied Piper in season two, accusing Richard of “stealing” Hooli’s intellectual property (copyright infringement), claiming that under Richard’s employment contract with Hooli (which included an invention assignment clause), all code and related technology he developed during his employment belonged to Hooli.

Fighting the company is unwise. To guard against the risk of being laid off, software engineers resort to more than just avoiding documentation — abusing design patterns, using reflection for implicit method calls, and over-engineering are all common tactics.

I sometimes genuinely don’t understand: employers ask me about “single-machine high concurrency” and “flash sale” scenarios just to negotiate salaries down. The most absurd was being asked about “millions of users online simultaneously.” On the other side of a parallel world, I took a look at the salary and responsibilities for that position.

With AI assistance, I could certainly design a workflow to handle these scenarios. The real question is: after deploying Redis distributed locks, Redis clusters, Kubernetes HPA auto-scaling, microservices, and message broker decoupling — where is the actual return on that code? Does our product truly have that many paying users? Is it appropriate to hand a critical system over to an employee of a marginal third-party vendor?

Back to that interview: I didn’t bother wasting my time with them. I suggested they run a Sina Weibo lottery to solve the flash sale scenario problem, then hit Command+Q to end the entire remote session.

Scientific Entropy Reduction Makes Everyone’s Life Easier

Looking back at the world after World War II, we rebuilt towering structures from ruins. Information technology has not yet reached a hundred years, and already the final horn is sounding. If this industry is destined to gradually fade with the rise of artificial intelligence, then use less C++ to avoid sudden death, use more GC languages, and serve as the final QA for AI coding.

That way you can still see a sky that hasn’t faded when you leave work each day — isn’t that a better thing?

n<n-1

私はかつて情報技術の第一逆説を提唱した：情報技術は反人間的な技術である。パブリッククラウドの黄昏という記事で、私はIT業界のエントロピー増大の法則と「ゼロ号規則」——限界利益ゼロのコードリファクタリングは誰もやりたがらない——をまとめた。

今日、私はゼロ号規則を否定し、新たな「情報技術の第二法則」を提唱する——ポストモダンプログラミングにおいて、人間の使命はコードの時系列複雑度を低下させ（n<n-1）、コードの確定性を確保することである。

レガシーコードが存在する合理性とリファクタリングの必要性

ゲームのAndroid APKを逆コンパイルしたことがあれば、現在のバージョンとは無関係な大量の冗長な美術リソースが含まれていることに気づくだろう。それらは歴史的に受け継がれたガベージコードだ。

ゼロ号規則の存在により、誰もこれらの美術リソースをリファクタリングしたり削除したりしたがらない。これは「王者栄耀（Honor of Kings）」のインストールパッケージが膨れ上がり続けた理由を説明する。最終的に「過去のアイテムの整理」と「モジュール式オンデマンドリソースダウンロード」という解決策が提案されたが、アップデート後に「ちまき」スキンがボットのようなアイコンの山に変わったと批判する人もいた。

なぜこうなるのか？ゲーム理論の基本的な命題に行き着く：局所最適は必ずしも大域最適ではない。ゲーム開発者にとって、新しい収益を生み出すには新しい物語を構築しなければならない。歴史的技術負債の解消はゲームの財務には反映されない。

しかしゲームユーザーと運営会社にとって、膨張するインストールパッケージはCDNのトラフィックコストを押し上げ、ガベージコードの蓄積はユーザーがゲームをダウンロードして起動するのに必要な時間を延ばし、操作のラグを引き起こす可能性すらある。

エントロピー増大の法則でソフトウェア開発プロセスを評価するなら、コードの「ゴミ山」は必然であり、ある意味ではソフトウェアエンジニアによる「防御的プログラミング」の一形態だと気づくだろう。

防御的プログラミングか過剰設計か？

政治経済学の観点から見れば、ソフトウェアエンジニアは本質的に生産手段を持たない「出稼ぎ労働者」だ。会社に入社した瞬間から、考えることや書くことはすべて会社の「デジタル資産」になる。これは米ドラマ『シリコンバレー』にも描かれている：RichardはHooliで働きながら、個人の時間（一部は会社のパソコンを使ってテスト）を使って革命的なロスレスデータ圧縮アルゴリズムを開発し、それを基にPied Piperを創立した。

Pied Piperが頭角を現し始めると、Hooli（Gavin Belson率いる）はシーズン2でPied Piperを正式に提訴し、Richardが同社の知的財産（著作権）を「盗んだ」と訴えた。RichardとHooliの雇用契約（発明譲渡条項を含む）に基づき、在職中に開発したすべてのコードと関連技術はHooliの所有物だと主張した。

会社と対立するのは得策ではない。解雇リスクを避けるため、ソフトウェアエンジニアは文書を書かないだけでなく、デザインパターンの乱用、リフレクションによる暗黙的なメソッド呼び出し、過剰設計なども常套手段だ。

採用担当者が「シングルマシン高並行」や「フラッシュセール」の問題を私に聞くのは、単に給与を下げるためだと時々本当に理解できない。最も極端だったのは「数百万人が同時オンライン」というような馬鹿げた質問だった。そして並行世界の反対側では、そのポジションの給与と対応する職責を見てみると……。

AIの助けがあれば、これらのシナリオに対応するワークフローを設計することは当然できる。問題は、Redisの分散ロック、Redisクラスター、Kubernetes HPAの自動スケーリング、マイクロサービス、メッセージブローカーのデカップリングを使った後、コードの実際のリターンはどこにあるのかということだ。私たちの製品に本当にそれほど多くの有料ユーザーはいるのか？重要なシステムを周辺的な外部ベンダーの社員に任せることは適切なのか？

あの面接に戻ると、最終的に彼らと時間を無駄にしなかった。新浪微博でくじ引き抽選を行って商品のフラッシュセールシナリオ問題を解決するよう提案し、それからCommand+Qでリモートセッション全体を終了した。

科学的なエントロピー削減で皆が楽になる

第二次世界大戦後の世界を振り返れば、廃墟の上から新しい高層ビルを再建した。情報技術はまだ百年も経っておらず、すでに終末のラッパが鳴り響いている。もしこの業界が人工知能の台頭とともに徐々に衰退していくとしたら、C++の使用を減らして突然死を避け、GC言語を多く使い、AIコーディングの最後のQAを担おう。

そうすれば毎日仕事終わりに、まだ色あせていない空を見ることができる——それでいいじゃないか？

n<n-1

Я однажды предложил первый парадокс информационных технологий: информационные технологии — это антигуманная технология. В статье Сумерки публичного облака я сформулировал закон возрастания энтропии в IT-отрасли и «Правило ноль» — никто не хочет делать рефакторинг кода с нулевой предельной выгодой.

Сегодня я хочу опровергнуть Правило ноль и предложить новый «Второй закон информационных технологий» — в постмодернистском программировании роль человека состоит в снижении временно́й последовательной сложности кода (n<n-1) и обеспечении детерминированности кода.

Обоснованность существования «горы мусора» и необходимость рефакторинга

Если вы когда-либо декомпилировали Android APK игры, то обнаружили бы огромное количество избыточных художественных ресурсов, не имеющих никакого отношения к текущей версии. Это исторически унаследованный мусорный код.

Из-за Правила ноль ни один программист не хочет рефакторить или удалять эти художественные ресурсы. Это объясняет, почему установочный пакет Honor of Kings постоянно разрастался, пока наконец не были предложены решения в виде «очистки исторических предметов» и «модульной загрузки ресурсов по запросу» — хотя некоторые игроки жаловались, что после обновления скин «цзунцзы» превратился в груду иконок, похожих на ботов.

Почему так происходит? Это связано с фундаментальным тезисом теории игр: локальный оптимум не обязательно является глобальным оптимумом. Для разработчиков игр новые нарративы необходимы для получения нового дохода. Устранение исторического технического долга никак не отражается в финансовых показателях игры.

Однако для пользователей и операторов разрастающийся установочный пакет увеличивает затраты на CDN-трафик, а накопление мусорного кода удлиняет время загрузки и запуска игры — и может даже привести к зависаниям.

Если оценивать процесс разработки программного обеспечения через призму закона возрастания энтропии, становится ясно, что «гора мусора» в коде неизбежна — в определённой мере это «защитное программирование» со стороны разработчиков.

Защитное программирование или чрезмерное проектирование?

С точки зрения политической экономии, разработчики программного обеспечения по-прежнему остаются «приезжими рабочими», не владеющими средствами производства. С момента прихода в компанию всё, о чём они думают и что пишут, становится «цифровым активом» компании. Это нашло отражение в американском сериале «Кремниевая долина»: работая в Hooli, Ричард в свободное время (хотя частично использовал рабочий компьютер для тестирования) разработал революционный алгоритм сжатия данных без потерь и основал на его базе компанию Pied Piper.

Когда Pied Piper начала набирать обороты, Hooli (во главе с Гэвином Белсоном) во втором сезоне официально подала на Pied Piper в суд, обвинив Ричарда в «краже» интеллектуальной собственности Hooli (нарушении авторских прав), утверждая, что согласно трудовому договору Ричарда с Hooli (включавшему пункт о передаче изобретений), весь написанный им код и связанные технологии принадлежат Hooli.

Противостоять компании неразумно. Поэтому, чтобы снизить риск увольнения, разработчики прибегают не только к отказу от документирования — злоупотребление шаблонами проектирования, неявный вызов методов через рефлексию и чрезмерное проектирование тоже относятся к распространённым тактикам.

Иногда я действительно не понимаю: работодатели спрашивают меня о «высоком параллелизме на одной машине» и задачах «flash sale» лишь для того, чтобы сбить зарплату. Самое абсурдное — вопрос о «миллионах пользователей одновременно онлайн». А в параллельном мире я посмотрел на предлагаемую зарплату и обязанности для этой вакансии.

При помощи ИИ я, конечно, могу разработать процесс для этих сценариев. Вопрос в другом: после применения распределённых блокировок Redis, кластеров Redis, автомасштабирования Kubernetes HPA, микросервисов и развязки через брокер сообщений — в чём реальная отдача от такого кода? Действительно ли у нашего продукта столько платящих пользователей? Уместно ли доверять важную систему сотруднику сторонней периферийной компании?

Возвращаясь к тому собеседованию: я не стал тратить с ними время. Предложил им провести лотерею в Sina Weibo для решения сценария с flash sale товаров, а затем нажал Command+Q и завершил весь удалённый сеанс.

Научное снижение энтропии облегчает жизнь всем

Оглядываясь на мир после Второй мировой войны: мы возвели новые небоскрёбы из руин. Информационным технологиям ещё нет ста лет, а финальный горн уже трубит. Если эта отрасль всё же будет постепенно угасать с развитием искусственного интеллекта — используйте меньше C++, чтобы избежать внезапной смерти, больше GC-языков и станьте последним QA для AI-кодинга.

Так вы сможете каждый вечер, возвращаясь домой, видеть небо, которое ещё не потускнело — разве это плохо?

n<n-1

时间序列元编程

Fri, 06 Feb 2026 00:00:00 +0000

由于时间序列库原始的论文http://github.com/zeusro/data已经丢失了，我只能按照有限的回忆一点点拼凑起时间序列那部分的内容。

只有经过时间的实践，才能验证程序的正确性。因此我提出时间序列元编程模型。这是一种对现实世界提出建模的新程序范式，是编程语言无关的设计哲学。

在此基础上引入时间序列复杂度：在满足传统时间/空间复杂度前提下，用二维图（t 与内存利用率等）乃至三维图（加入 CPU/GPU 负载）刻画算法实际耗时与资源利用。

时间序列

时间序列：按时间顺序排列、记录同一对象状态随时间变化的一组数据。时间序列只有Watch作为唯一API。Watch可以按照顺序分化为Read和Write接口。

时间序列对象

时间序列对象，时间必须是第一成员，并且在初始化函数中体现。基于时间而生成的数据都是时序数据。

type DeadMonkey struct {
	Birth       time.Time
	GoldenStaff []NLine //金箍棒 参数化线段（Parametric Segment）
	m           int     //消费者规模
	n           int     //算法规模
	ZeroPoints  []model.Point
	cost        time.Duration
}

时间序列函数

时间序列函数，时间必须是第一成员。返回参数第一成员必须是时间序列对象。传入的时间与传出的时间，表示函数的时间上下界。

// NewDeadMonkey
// m 作战对象
// n 唯一资源数/算法规模
func NewDeadMonkey(birth time.Time, m, n int) *DeadMonkey {
	dead := DeadMonkey{
		Birth: birth,
		m:     m,
		n:     n,
	}
	zeroPoints := make([]model.Point, m)
	p0 := model.RandonPoint()
	zeroPoints[0] = p0
	for i := 1; i < m; i++ {
		p1 := model.RandonPoint()
		//只要不跟前面的点重复就行，全局重复也忽略了
		for p1.Compare(zeroPoints[i-1]) {
			p1 = model.RandonPoint()
		}
		zeroPoints[i] = p1
	}
	dead.ZeroPoints = zeroPoints
	return &dead
}

// SleepAndReturnNewTime 接收一个时间参数，随机 sleep 一段时间后返回最新时间
func SleepAndReturnNewTime(inputTime time.Time) time.Time {
    // 设置随机种子
    rand.Seed(time.Now().UnixNano())

    // 生成随机的 sleep 时间，范围为 1 到 5 秒
    sleepDuration := time.Duration(rand.Intn(5)+1) * time.Second

    // Sleep 随机时间
    time.Sleep(sleepDuration)

    // 返回当前时间
    return time.Now()
}

时间序列距离

使用时间+其他条件的复合判断（比如在4维球面中，可以只使用距离作为换算；也可以使用时间+Haversine公式换算）。

时间序列日志

打印内容必须是“时间+内容”的格式。

时间序列复杂度

时间序列复杂度（Time Series Complexity）：在满足时间复杂度以及空间复杂度的前置性论述下，算法执行的实际时间以及内存资源的利用效率。

时间序列复杂度是一个二维图表。X轴是t，Y轴是(used - buff/cache) / total。

Y轴可以按照实际需要，使用其他的标准，比如CPU/GPU的整体利用率。

单位时间序列复杂度是一个三维图表。不过三维图表过于抽象，可以降维成2个2维图表。或者合并Y轴，变成一个二维图表的两条曲线。

单位CPU时间序列复杂度是一个三维图表。 X轴是t， Y轴是(used - buff/cache) / total， Z轴是cpu_load1。

单位GPU时间序列复杂度是一个三维图表。 X轴是t， Y轴是(used - buff/cache) / total， Z轴是gpu_utilization。

时间序列复杂度需要对程序进行可观测性分析。

时间序列空间

由时间序列组成的2维以上空间。

在OOOShttps://github.com/zeusro/system中，我将会尽可能地使用这种编程范式。

比如

无锁并发访问受限资源的平行时空算法（https://github.com/zeusro/system/blob/main/function/local/n/china/shenzhen/szx/readme.md）
Y函数（https://github.com/zeusro/system/blob/main/function/local/n/china/shantou/y/y.go#L73）

The original paper for the time-series library http://github.com/zeusro/data has been lost, so I can only piece together the time-series part from limited memory.

Only through practice over time can the correctness of a program be verified. I therefore propose the time-series meta-programming model—a new programming paradigm for modeling the real world, a design philosophy independent of programming language.

On this basis, time-series complexity is introduced: under the premise of satisfying traditional time and space complexity, two-dimensional plots (e.g. t vs. memory utilization) and even three-dimensional plots (adding CPU/GPU load) are used to characterize the actual execution time and resource utilization of algorithms.

Time Series

Time series: A set of data arranged in chronological order that records how the state of the same object changes over time.
A time series has only Watch as its sole API. Watch can be split in order into Read and Write interfaces.

Time-Series Objects

For a time-series object, time must be the first member and must be reflected in the initialization function.
Any data generated based on time is time-series data.

type DeadMonkey struct {
	Birth       time.Time
	GoldenStaff []NLine // Golden Cudgel – Parametric Segment
	m           int     // consumer scale
	n           int     // algorithm scale
	ZeroPoints  []model.Point
	cost        time.Duration
}

Time-Series Functions

For a time-series function, time must be the first parameter. The first member of the return value must be a time-series object.
The input time and output time represent the lower and upper time bounds of the function.

// NewDeadMonkey
// m combat objects
// n unique resource count / algorithm scale
func NewDeadMonkey(birth time.Time, m, n int) *DeadMonkey {
	dead := DeadMonkey{
		Birth: birth,
		m:     m,
		n:     n,
	}
	zeroPoints := make([]model.Point, m)
	p0 := model.RandonPoint()
	zeroPoints[0] = p0
	for i := 1; i < m; i++ {
		p1 := model.RandonPoint()
		// As long as it doesn't duplicate the previous point; global duplicates are ignored
		for p1.Compare(zeroPoints[i-1]) {
			p1 = model.RandonPoint()
		}
		zeroPoints[i] = p1
	}
	dead.ZeroPoints = zeroPoints
	return &dead
}

// SleepAndReturnNewTime accepts a time argument, sleeps randomly, then returns the latest time
func SleepAndReturnNewTime(inputTime time.Time) time.Time {
    // Set random seed
    rand.Seed(time.Now().UnixNano())

    // Generate random sleep duration, 1 to 5 seconds
    sleepDuration := time.Duration(rand.Intn(5)+1) * time.Second

    // Sleep for random duration
    time.Sleep(sleepDuration)

    // Return current time
    return time.Now()
}

Time-Series Distance

Use composite criteria of time plus other conditions (e.g. on a 4-dimensional sphere, distance alone may be used for conversion; or time plus the Haversine formula).

Time-Series Logging

Log output must follow the format “time + content”.

Time-Series Complexity

Time-series complexity: Under the prerequisite of time complexity and space complexity, the actual execution time of an algorithm and the utilization efficiency of memory resources.

Time-series complexity is represented as a two-dimensional plot. The X-axis is t, the Y-axis is (used - buff/cache) / total.

The Y-axis can use other metrics as needed, such as overall CPU/GPU utilization.

Unit time-series complexity is a three-dimensional plot. Three-dimensional plots are rather abstract; they can be reduced to two 2D plots, or the Y-axes can be merged into two curves on a single 2D plot.

Unit CPU time-series complexity is a three-dimensional plot: X-axis t, Y-axis (used - buff/cache) / total, Z-axis cpu_load1.

Unit GPU time-series complexity is a three-dimensional plot: X-axis t, Y-axis (used - buff/cache) / total, Z-axis gpu_utilization.

Time-series complexity requires observability analysis of the program.

Time-Series Space

A space of two or more dimensions composed of time series.

In OOOS https://github.com/zeusro/system, I will use this programming paradigm as much as possible.

For example:

Lock-free parallel spacetime algorithm for concurrent access to constrained resources (https://github.com/zeusro/system/blob/main/function/local/n/china/shenzhen/szx/readme.md)
Y function (https://github.com/zeusro/system/blob/main/function/local/n/china/shantou/y/y.go#L73)

時間序列ライブラリの元論文（http://github.com/zeusro/data）は失われており、限られた記憶から時間序列の部分を少しずつ再構成するしかない。

時間をかけた実践によってのみ、プログラムの正しさは検証できる。そこで時間序列メタプログラミングモデルを提唱する。現実世界をモデル化するための新しいプログラムのパラダイムであり、プログラミング言語に依存しない設計哲学である。

この上に時間序列複雑度を導入する：従来の時間・空間複雑度を満たすことを前提に、二次元グラフ（t とメモリ利用率など）や三次元グラフ（CPU/GPU 負荷を加える）で、アルゴリズムの実際の実行時間とリソース利用を表現する。

時間序列

時間序列：時間順に並べられた、同一対象の状態の時間変化を記録したデータの集合。
時間序列の API は Watch のみである。Watch は順序に従って Read と Write インターフェースに分化できる。

時間序列オブジェクト

時間序列オブジェクトでは、時間を第一メンバーとし、初期化関数に反映させる必要がある。
時間に基づいて生成されるデータはすべて時系列データである。

type DeadMonkey struct {
	Birth       time.Time
	GoldenStaff []NLine // 金箍棒 パラメトリック線分（Parametric Segment）
	m           int     // 消費者規模
	n           int     // アルゴリズム規模
	ZeroPoints  []model.Point
	cost        time.Duration
}

時間序列関数

時間序列関数では、時間を第一引数とする。戻り値の第一メンバーは時間序列オブジェクトでなければならない。
入力される時間と出力される時間は、関数の時間の下界と上界を表す。

// NewDeadMonkey
// m 戦闘対象
// n 唯一リソース数 / アルゴリズム規模
func NewDeadMonkey(birth time.Time, m, n int) *DeadMonkey {
	dead := DeadMonkey{
		Birth: birth,
		m:     m,
		n:     n,
	}
	zeroPoints := make([]model.Point, m)
	p0 := model.RandonPoint()
	zeroPoints[0] = p0
	for i := 1; i < m; i++ {
		p1 := model.RandonPoint()
		// 前の点と重複しなければよい。全体での重複は無視する
		for p1.Compare(zeroPoints[i-1]) {
			p1 = model.RandonPoint()
		}
		zeroPoints[i] = p1
	}
	dead.ZeroPoints = zeroPoints
	return &dead
}

// SleepAndReturnNewTime 時間引数を受け取り、ランダムに sleep してから最新の時間を返す
func SleepAndReturnNewTime(inputTime time.Time) time.Time {
    // 乱数シードを設定
    rand.Seed(time.Now().UnixNano())

    // 1〜5秒のランダムな sleep 時間を生成
    sleepDuration := time.Duration(rand.Intn(5)+1) * time.Second

    // ランダム時間だけ Sleep
    time.Sleep(sleepDuration)

    // 現在時刻を返す
    return time.Now()
}

時間序列距離

時間＋その他の条件による複合判定を用いる（例：4次元球面上では距離のみで換算してもよいし、時間＋Haversine 公式で換算してもよい）。

時間序列ログ

出力内容は「時間＋内容」の形式でなければならない。

時間序列複雑度

時間序列複雑度（Time Series Complexity）：時間複雑度および空間複雑度の前提を満たした上で、アルゴリズムの実際の実行時間とメモリリソースの利用効率。

時間序列複雑度は二次元グラフで表す。X 軸は t、Y 軸は (used - buff/cache) / total。

Y 軸は必要に応じて、CPU/GPU の全体利用率など別の指標を用いてよい。

単位時間序列複雑度は三次元グラフである。三次元は抽象的すぎるため、2 つの二次元グラフに次元削減するか、Y 軸を統合して二次元グラフ上の 2 本の曲線にしてもよい。

単位 CPU 時間序列複雑度は三次元グラフである。X 軸は t、Y 軸は (used - buff/cache) / total、Z 軸は cpu_load1。

単位 GPU 時間序列複雑度は三次元グラフである。X 軸は t、Y 軸は (used - buff/cache) / total、Z 軸は gpu_utilization。

時間序列複雑度にはプログラムの可観測性解析が必要である。

時間序列空間

時間序列からなる 2 次元以上の空間。

OOOS（https://github.com/zeusro/system）では、このプログラミングパラダイムを可能な限り用いる。

例：

制約付きリソースへの無ロック並行アクセスの並行時空アルゴリズム（https://github.com/zeusro/system/blob/main/function/local/n/china/shenzhen/szx/readme.md）
Y 関数（https://github.com/zeusro/system/blob/main/function/local/n/china/shantou/y/y.go#L73）

Оригинальная статья по библиотеке временных рядов http://github.com/zeusro/data утрачена, поэтому я могу лишь по обрывочным воспоминаниям восстановить часть, касающуюся временных рядов.

Только практика во времени способна проверить корректность программы. Поэтому я предлагаю модель метапрограммирования временных рядов — новую программную парадигму для моделирования реального мира, философию проектирования, не привязанную к языку программирования.

На этой основе вводится сложность временных рядов: при соблюдении традиционной временной и пространственной сложности двумерные графики (например, t и утилизация памяти) и даже трёхмерные (с учётом нагрузки CPU/GPU) описывают фактическое время выполнения алгоритма и использование ресурсов.

Временной ряд

Временной ряд: упорядоченный по времени набор данных, фиксирующий изменение состояния одного и того же объекта во времени.
У временного ряда единственный API — Watch. Watch по порядку разбивается на интерфейсы Read и Write.

Объект временного ряда

У объекта временного ряда время должно быть первым полем и отражаться в функции инициализации.
Любые данные, порождённые на основе времени, являются данными временного ряда.

type DeadMonkey struct {
	Birth       time.Time
	GoldenStaff []NLine // Золотая дубинка – параметрический отрезок
	m           int     // масштаб потребителей
	n           int     // масштаб алгоритма
	ZeroPoints  []model.Point
	cost        time.Duration
}

Функция временного ряда

У функции временного ряда первым аргументом должно быть время. Первое поле возвращаемого значения должно быть объектом временного ряда.
Входное и выходное время задают нижнюю и верхнюю временные границы функции.

// NewDeadMonkey
// m боевые объекты
// n число уникальных ресурсов / масштаб алгоритма
func NewDeadMonkey(birth time.Time, m, n int) *DeadMonkey {
	dead := DeadMonkey{
		Birth: birth,
		m:     m,
		n:     n,
	}
	zeroPoints := make([]model.Point, m)
	p0 := model.RandonPoint()
	zeroPoints[0] = p0
	for i := 1; i < m; i++ {
		p1 := model.RandonPoint()
		// Достаточно не совпадать с предыдущей точкой; глобальные повторы игнорируются
		for p1.Compare(zeroPoints[i-1]) {
			p1 = model.RandonPoint()
		}
		zeroPoints[i] = p1
	}
	dead.ZeroPoints = zeroPoints
	return &dead
}

// SleepAndReturnNewTime принимает аргумент времени, случайно «засыпает», затем возвращает актуальное время
func SleepAndReturnNewTime(inputTime time.Time) time.Time {
    // Установить зерно случайности
    rand.Seed(time.Now().UnixNano())

    // Случайная длительность сна от 1 до 5 секунд
    sleepDuration := time.Duration(rand.Intn(5)+1) * time.Second

    // Сон на случайное время
    time.Sleep(sleepDuration)

    // Вернуть текущее время
    return time.Now()
}

Расстояние во временном ряде

Используется составной критерий: время плюс другие условия (например, на 4-мерной сфере можно опираться только на расстояние или на время и формулу Haversine).

Логирование временного ряда

Содержимое вывода должно быть в формате «время + содержание».

Сложность временного ряда

Сложность временного ряда (Time Series Complexity): при заданных временной и пространственной сложности — фактическое время выполнения алгоритма и эффективность использования памяти.

Сложность временного ряда изображается двумерным графиком. По оси X — t, по оси Y — (used - buff/cache) / total.

По оси Y при необходимости можно использовать другие метрики, например общую загрузку CPU/GPU.

Единичная сложность временного ряда — трёхмерный график. Трёхмерный график слишком абстрактен; его можно свести к двум двумерным или объединить оси Y в две кривые на одном двумерном графике.

Единичная CPU-сложность временного ряда — трёхмерный график: ось X — t, ось Y — (used - buff/cache) / total, ось Z — cpu_load1.

Единичная GPU-сложность временного ряда — трёхмерный график: ось X — t, ось Y — (used - buff/cache) / total, ось Z — gpu_utilization.

Для сложности временного ряда требуется анализ наблюдаемости программы.

Пространство временных рядов

Пространство размерности два и выше, состоящее из временных рядов.

В OOOS https://github.com/zeusro/system я буду по возможности применять эту программную парадигму.

Например:

Алгоритм параллельного пространства-времени с неблокирующим доступом к ограниченным ресурсам (https://github.com/zeusro/system/blob/main/function/local/n/china/shenzhen/szx/readme.md)
Функция Y (https://github.com/zeusro/system/blob/main/function/local/n/china/shantou/y/y.go#L73)

公有云的诸神黄昏

Wed, 04 Feb 2026 00:00:00 +0000

摘要

本文从形式逻辑与定义出发（网络效应、熵增定律、反依赖性、边际收益为零的「0」哲学），系统梳理了 2014–2025 年间阿里云、谷歌云、Azure、Cloudflare、腾讯云等主流公有云与基础设施的重大故障记录，并比较了各家的故障透明度。在此基础上，文章分析了公有云「死因」：软件熵增与边际收益为零导致旧代码与架构难以治理，网络效应在故障时放大连锁反应，而 SLA 赔付与政企实际损失严重不对等。作者建议大型政企将对公有云的「反依赖」提上日程，并提出「小并发高可用系统」的设想——通过存储冗余与流量分摊（如多区域、多集群 DNS 解析）降低单点风险与问题扩散半径。

形式逻辑和定义

网络效应：一个产品/服务/平台的使用者（或参与者）越多，它对每一个使用者的价值就越大。

熵增定律：项目代码库会随着时间推移而变成一座屎山。

反依赖性：对单一编程语言/技术栈/云平台的反向依赖。比如多语言混合编程，多技术栈选型，多云策略。反依赖性让业务可以脱离语言/开源项目/公有云平稳运行。

0：边际收益为0的代码重构没人愿意做。

AWS的故障

时间	地域/范围	持续时长	主要影响范围与后果	官方/主流原因说明	备注 / 行业评价
2014-06-13	us-east-1 (北弗吉尼亚)	未指定	影响 Amazon SimpleDB 服务部分关键组件，导致部分用户无法访问或操作数据库。	电源问题引发系统中断。	较小规模事件，AWS 快速恢复；行业评价为基础设施电源冗余不足的典型案例。
2014-08-07	EU West (爱尔兰)	未指定	影响 EC2、EBS 和 RDS 服务，导致部分欧洲用户实例、存储和数据库不可用。	内部系统事件，未公布详细根因。	区域性事件，影响欧洲客户；评价为 AWS 早期区域隔离不完善的体现。
2014-11-26	全球 (CloudFront DNS)	约 2 小时	DNS 服务器宕机，影响 CDN 服务，导致部分网站和云服务离线，无法解析请求。	DNS 服务器故障。	短暂但广泛影响；行业称其为“世界上最大云的 DNS 脆弱性暴露”。
2015-09-20	us-east-1 (北弗吉尼亚)	数小时	DynamoDB 故障导致内部服务通信中断，波及 Netflix、Reddit、IMDb 和 Amazon 自身站点，用户无法访问视频、社交和电商服务。	内部多个服务通信中断，引发连锁反应。	严重事件，影响数百万用户；评价为 AWS 内部依赖性过高的警示。
2017-02-28	us-east-1 (北弗吉尼亚)	4-5 小时	S3 控制平面瘫痪，影响 Slack、Trello、GitHub Pages、Quora 等大量网站，无法加载图像和文件。	工程师误删关键配置（打字错误）。	历史上最著名故障之一，称为“最贵的一次 typo”；行业评价强调人为错误风险。
2020-11-25	us-east-1 (北弗吉尼亚)	数小时	Kinesis 和 Cognito 故障，影响 Roku、Adobe、Flickr 等企业客户，流媒体和认证服务中断。	容量更新问题引发中断。	疫情期间事件，影响远程工作；评价为容量管理挑战。
2022-12-05	us-east-2 (俄亥俄)	约 40 分钟	可用区中断，影响区域内多项服务，导致部分客户资源不可用。	未公布详细根因，可能是网络或电源问题。	短暂事件，但凸显可用区依赖；行业建议多 AZ 架构。
2023-06-13	us-east-1 (北弗吉尼亚)	未指定	Lambda 服务事件，广泛影响大型组织如 Boston Globe、纽约地铁和 Associated Press，无法执行无服务器函数。	未公布详细根因。	区域性大范围中断；评价为无服务器计算脆弱性暴露。
2024-07-30	us-east-1 (北弗吉尼亚)	未指定	Kinesis Data Streams 故障，导致依赖服务连锁中断，影响实时数据处理应用。	未公布详细根因，可能是内部系统问题。	影响数据流服务；行业评价为流处理依赖风险。
2025-02	eu-north-1 (斯德哥尔摩)	未指定	网络故障影响一个 AZ 内多项核心服务，导致欧洲部分用户中断。	重大网络故障。	区域性事件；评价为欧洲基础设施扩展挑战。
2025-10-19/20	us-east-1 (北弗吉尼亚)	约 15 小时以上	DynamoDB API 端点中断，影响 Slack、Atlassian、Snapchat、Reddit、Roblox、Fortnite、Coinbase、Venmo、Duolingo、Canva、PlayStation Network、银行、航空公司（如 Delta、United 航班延误）和 Amazon 服务；超 3500 家公司、60+ 国家受影响，用户报告超 1700 万次。	DNS 解析故障引发连锁反应。	2025 年最大故障，称为“云脆弱性大暴露”；行业评价为 DNS 和控制平面依赖的重大教训，强调多云策略。

分析比较严重的事故

在 2014-2025 年间，AWS 经历了多次故障，其中最严重的几起包括 2015-09-20 的 DynamoDB 故障、2017-02-28 的 S3 故障，以及 2025-10-19/20 的 DynamoDB DNS 故障。这些事件均发生在 us-east-1 区域，该区域作为 AWS 最古老和最繁忙的中心，常因内部依赖和规模效应成为故障高发地。

严重程度比较：
- 2015 DynamoDB 故障：持续数小时，影响 Netflix、Reddit 等娱乐和社交平台，导致用户无法访问内容。后果主要是娱乐中断，但未波及金融或交通。根因是内部通信失败，暴露了服务间连锁风险。行业评价为 AWS 早期架构依赖的典型问题，推动了后续的多区域冗余改进。
- 2017 S3 故障：持续 4-5 小时，由人为错误（打字错误）引发，影响 Slack、Trello 等生产力工具和数百万网站的文件托管。经济损失巨大，估计数亿美元。相比 2015 年，此次更强调人为因素，促使 AWS 加强自动化和错误检查机制。
- 2025 DynamoDB DNS 故障：持续 15+ 小时，是三者中最长，影响范围最广，波及 3500+ 公司，包括金融（Coinbase、Venmo）、游戏（Fortnite、Roblox）、教育（Duolingo）和交通（航空延误）。用户报告超 1700 万次，全球 60+ 国家中断。根因是 DNS 解析问题，凸显控制平面脆弱性。相比前两次，此次后果更严重，涉及关键基础设施，行业评价为“云时代最大中断”，呼吁企业采用多云或混合云策略以分散风险。

总体而言，这些严重故障的共同点是 us-east-1 的中心化问题和连锁反应，严重度随时间推移而增加（从数小时到 15+ 小时，从娱乐到关键服务），反映了互联网对云依赖的加深。AWS 通过 PES 报告持续改进，但行业建议企业避免单区域依赖，实现真正的高可用架构。

阿里云的故障

阿里云自2014年至2025年期间，公开报道和官方披露的真正影响面广、持续时间长、被广泛称为“重大事故”的故障并不算特别多（相比体量来说，整体SLA表现仍属行业前列），但其中几次确实造成了较大社会影响和行业讨论。下面按时间顺序列出公认的几次重大级别故障（主要基于公开信息、官方公告、媒体和社区复盘）：

时间	地域/范围	持续时长	主要影响范围与后果	官方/主流原因说明	备注 / 行业评价
2018年6月	部分地域（具体未公开细节）	约30分钟	部分云产品出现异常，影响范围相对有限	未详细公开	当时被部分媒体称为“重大技术故障”
2019年3月3日	华北2（北京）可用区C	数小时	大量ECS实例磁盘故障，众多网站/App瘫痪	磁盘故障	当时影响较大，阿里云按SLA赔付
2022年12月18日	香港Region 可用区C	约15.5小时	香港区几乎全地域服务中断，澳门多家关键机构网站（金融管理局、银河、莲花卫视等）不可用，OKX交易受影响	制冷设备故障 → 连锁反应导致大面积宕机	被广泛称为“阿里云发展史上最严重丑闻之一”
2023年11月12日	全球所有地域、所有服务	约3小时16分钟	控制台、API、MQ、微服务、监控、机器学习等几乎全线产品异常；淘宝、钉钉、闲鱼、饿了么、阿里云盘等集体“崩”	底层核心组件（鉴权/元数据/控制面组件）故障	公认阿里云史上最严重、影响范围最广的一次，被称为“史诗级”“行业闻所未闻”
2023年11月27日	部分服务器	近2小时	服务器访问异常	未详细披露	距离11·12事故仅半个月，再次引发信任质疑
2024年7月2日	部分地域/服务	数小时	控制台及部分服务异常	未见详细复盘	属于中型故障，影响面小于前几次
2025年（具体日期不详）	全球范围（疑似域名相关）	约6小时	域名劫持导致全球服务异常	域名劫持相关	来自2025年公有云故障汇总报告，细节待确认

重要说明与趋势观察

2014–2018早期：这个阶段阿里云对外公开的重大P0级故障记录极少，更多是局部、小范围问题。那时体量远小于现在，故障影响面也较小。
最严重的两次：
- 2022.12香港区15.5小时 → 单地域最长时间故障，对港澳地区关键基础设施影响恶劣。
- 2023.11.12全球3小时+ → 控制面/全局服务全部瘫痪，被公认为云计算历史上罕见的“全地域×全服务”同时故障，打破了阿里云长期标榜的“多活、多中心、N个9”神话。
2024–2025：从已知信息看，故障频次和严重程度相比2022–2023有所下降，但仍然偶有中大型事件（尤其是2025年的域名劫持类事件影响面较广）。
阿里云的处理特点：
- 大部分重大故障后都会发详细复盘说明（尤其是2022香港、2023全球两次）
- 按SLA赔付（通常是故障时长对应倍数的代金券）
- 高管/官方会公开致歉

总体而言，阿里云在2014–2025这十二年间真正称得上“重大事故”的次数大约在5–7次左右，其中2023年11月12日和2022年12月香港是公认的影响力和严重程度最高的两起。

谷歌云的故障

谷歌云（Google Cloud Platform，简称GCP）从2014年到2025年这段时间内，整体SLA表现相对较好，真正影响全球范围或多个核心服务的重大事故并不算特别频繁（比AWS和Azure略少一些全局性灾难级事件）。但一旦出问题，通常会波及大量第三方应用（如Snapchat、Spotify、Discord、Cloudflare依赖的服务等），社会影响较大。

下面按时间顺序列出公认的比较严重的、影响面广的GCP重大故障（基于公开Status Dashboard、媒体报道、Wikipedia、行业复盘等信息）：

时间	地域/范围	持续时长	主要影响范围与后果	主流原因说明	备注 / 行业评价
2015年8月	欧洲（比利时Ghlin）	数小时	Compute Engine 读写错误率极高，少量数据丢失	雷击导致数据中心部分设备损坏	谷歌罕见承认数据丢失，影响较小客户群
2018年7月	全球（多地域）	数小时	GCP多服务异常，Snapchat、Spotify等第三方应用大面积无法登录/使用	网络拥塞 + 内部路由问题	当时被广泛报道，第三方影响很明显
2019年6月2日	美国东部 + 全球波及	约4–5小时	YouTube、Gmail、G Suite大面积不可用，Snapchat、Discord、Vimeo等登录失败	美国东部网络拥塞 + 级联故障	影响范围广，社交媒体热议
2020年12月14日	全球	约1小时	Gmail、YouTube、Google Home、Nest、Pokémon GO等几乎所有依赖身份验证的服务瘫痪	身份认证系统（类似IAM）全局故障	谷歌消费级服务集体“崩”，影响最大的一次之一
2022年8月	美国爱荷华州数据中心	局部影响	电气火灾（3人受伤），部分服务受波及，但非全局	数据中心电气事故引发火灾	更多是物理设施事故，非纯软件/架构问题
2023年4月	欧洲（巴黎等）	数小时	多地域网络 + 服务中断，部分客户受影响	洪水 + 数据中心问题 + 网络故障组合	天气因素导致，影响面中等
2024年10月23日	欧洲（德国法兰克福 europe-west3）	约半天（12+小时）	该地域几乎全服务不可用，影响大量欧洲客户	未详细公开（疑似控制面/网络问题）	单地域最长时长故障之一
2025年6月12日	全球（多地域，40+个）	约2.5–3小时	70+项GCP服务异常，IAM身份授权系统崩溃，导致API请求全面失败；Spotify、Discord、Twitch、Cloudflare、Fitbit、Gmail、Drive、YouTube等大面积瘫痪	Service Control（API鉴权核心组件）自动化更新引入严重bug → 崩溃循环 → 全局过载	公认2020年后GCP最严重的一次全局故障，影响互联网大片区域
2025年7月18日	us-east1	约2小时	多产品错误率升高	未详细披露	中型故障，恢复较快

Azure的故障

Microsoft Azure（微软云平台）从2014年到2025年这段时间内，真正影响面广、持续时间长、社会关注度高的重大事故数量不算特别多（相比早期体量较小时的频繁小故障已显著减少），但几次事件确实造成了全球性或多服务级别的严重影响，尤其涉及Microsoft 365、Teams、Xbox、Outlook等消费级/企业级产品时，传播效应非常明显。

下面按时间顺序列出公认的重大级别故障（基于Azure官方Status History、Post Incident Reviews、媒体报道、Wikipedia和行业复盘等公开信息）：

时间	地域/范围	持续时长	主要影响范围与后果	主流原因说明	备注 / 行业评价
2014年8月14–18日	US Central、US East、US East 2、Europe North	多日多次，单次数小时	Cloud Services、SQL Database、VM、Websites、HDInsight、Mobile Services、Service Bus等大面积不可用	多起网络/存储问题叠加	2014年最集中的一波故障，当时Azure还较年轻
2014年11月18–19日	多地域（美、欧、亚部分）	约11小时	Azure Storage为核心，引发VM、Websites、Visual Studio Online、Xbox Live、MSN、Search等20+服务中断	存储性能优化配置变更导致Blob前端无限循环	Azure早期最严重的一次，官方详细RCA，赔付客户
2016年9月15日	全球	数小时	DNS解析大面积故障，影响大量依赖Azure DNS的服务	全球DNS问题	暴露DNS单点风险
2018年6月20日	北美多个数据中心	数小时–1天+	冷却系统故障（雷击+浪涌保护不足）导致多服务中断	物理设施问题（雷击引发连锁反应）	罕见的硬件+基础设施类大故障
2018年9月4日	多地域	超过25小时（部分服务3天）	多项核心服务长时间不可用	冷却系统故障（雷击+浪涌保护不足）	恢复时间最长的一次之一
2023年1月23日	全球（核心网络受影响）	约3小时	Microsoft 365（Teams、Outlook、Exchange）、部分Azure服务中断	广域网（WAN）问题	M365集体“崩”，影响巨大
2024年7月18日	US Central	约半天	Virtual Machines等服务管理操作失败，客户无法访问托管服务	访问控制错误 + 基础设施故障	与次日CrowdStrike全球蓝屏事件时间接近，但独立
2025年1月8–9日	East US 2 等	数小时	Azure Databricks、Synapse、Functions、App Service、VM等网络中断	网络组件问题	2025年初较显著的一次
2025年10月29日	全球	约8小时	Azure Front Door为核心，引发Microsoft 365、Outlook、Teams、Xbox Live、Minecraft、Copilot大面积瘫痪；第三方如Alaska Airlines、Heathrow机场、Costco、Starbucks等受波及	Azure Front Door配置变更 + 防护机制bug导致配置不一致全局传播	2025年Azure最严重的一次，Downdetector超3万报告，类似AWS同月故障
2025年11月5–6日	West Europe (AZ01)	约9–10小时	VM、PostgreSQL/MySQL Flexible Server、AKS、Storage、Service Bus等多服务降级/中断	数据中心热事件（Thermal event）	区域级较严重故障

重要观察与趋势（2014–2025）

2014年：Azure还处于快速扩张期，配置变更和存储层问题频发，是故障最集中的一年（尤其是11月那次被视为经典案例）。
2015–2019：故障频率下降，但仍以单地域或基础设施（冷却、雷击、DNS）为主，影响面相对可控。
2020–2023：重大全局故障较少，更多是网络或M365依赖Azure导致的间接影响（如2023年1月）。
2024–2025：控制面/边缘服务（如Azure Front Door）成为新痛点，2025年10月29日事件被公认为近几年Azure最严重的全球性中断，影响范围堪比阿里云2023年11月或谷歌云2025年6月的事件。
典型特点：
- 微软每次重大事故后都会发布详细Post Incident Review (PIR)（官方复盘），透明度较高。
- 经常因配置变更、控制平面组件、网络问题引发（而非底层硬件故障）。
- 第三方传播效应极强：一旦M365、Xbox、Teams出问题，社会关注度瞬间拉满。
- 按SLA赔付（信用额度形式），但客户更在意业务连续性。

总体而言，Azure在2014–2025这12年间真正达到重大级别（全球/多服务长时间中断）的故障大约8–10次，严重程度和频率与AWS、GCP处于同一量级，但配置错误导致的级联故障是Azure历史上反复出现的模式。

Cloudflare的故障

Cloudflare（Cloudflare）作为全球最大的CDN、安全、DNS和边缘计算提供商之一，从2014年到2025年期间，真正影响面广、造成互联网大面积瘫痪的重大事故并不算特别多，但一旦发生，通常会波及数百万到数亿用户，影响范围极广（因为Cloudflare承载了全球约20–25%的网页流量）。

Cloudflare的故障特点是：恢复速度通常较快（大部分在1–4小时内缓解），但传播效应极强——一旦核心代理层、DNS或安全组件出问题，很多顶级网站（X、ChatGPT、Shopify、Discord、Spotify、AWS部分服务等）会同时出现5xx错误或无法访问。

下面按时间顺序列出公认的重大级别故障（基于Cloudflare官方博客、status.cloudflare.com历史、媒体报道、Wikipedia和行业复盘，重点筛选全球/核心流量中断事件）：

时间	范围	持续时长	主要影响范围与后果	主流原因说明	备注 / 行业评价
2019年7月2日	全球	约1–2小时	大量网站出现502/503/504错误，互联网大片区域无法访问	软件部署引入严重bug，导致代理层崩溃	Cloudflare公认史上最严重的一次，官方详细复盘
2020年多次	部分地域/控制面	数小时	仪表盘、分析、部分API不可用；核心代理层基本稳定	控制平面组件问题	影响开发者较多，普通用户感知较小
2022年6月	多数据中心（19个）	约1.5小时	核心代理层中断，多个网站无法访问	网络配置错误	中等规模，恢复较快
2025年3月21日	全球	约1小时7分钟	存储读写严重故障，影响大量依赖Cloudflare存储/缓存的服务	KV/存储层写失败 + 部分读异常	2025年早期较显著的一次
2025年6月12日	全球（部分新功能）	数小时	部分新功能/服务不可用，核心流量基本正常	特定模块部署问题	非核心流量中断，影响有限
2025年7月14日	全球（1.1.1.1 DNS）	约62分钟	公共DNS解析器（1.1.1.1）完全不可用，大量用户无法上网	配置错误导致BGP路由撤回，DNS前缀从全球路由表消失	对依赖1.1.1.1的用户影响极大，堪称“断网级”
2025年10月左右	部分服务	数十到几十分钟	DNS解析短暂中断	DNS相关配置问题	中型故障
2025年11月18日	全球	约4–5小时（高峰期更长）	大规模互联网中断：X（Twitter）、ChatGPT、Shopify、Spotify、Letterboxd、Indeed、Canva、Uber、DoorDash、Truth Social、League of Legends等大量顶级服务瘫痪；约20%网页流量受影响，1/3 Alexa前1万网站受波及	Bot Management特征文件异常膨胀（数据库权限变更导致文件大小翻倍）→ 全网传播 → 代理层崩溃	2025年最严重的一次，也是2019年后Cloudflare最严重的全局流量中断
2025年12月5日	全球	数小时	再次出现大范围5xx错误，Shopify、Zoom、Vinted、Fortnite、Square、Just Eat、Canva、Vimeo、AWS部分服务、Deliveroo等受影响	未见完整官方根因（疑似配置/传播类问题）	距离11月18日仅17天，连续两次重大事故引发强烈质疑

重要观察与趋势（2014–2025）

2014–2018早期：Cloudflare体量快速增长，但公开的全局重大故障记录很少，主要是一些局部、地域性或功能性问题。那时互联网对Cloudflare的依赖度远低于现在。
2019年7月：成为Cloudflare历史上最经典的“黑天鹅”事件，此后6年多时间里再未出现同等规模的核心代理层全局中断。
2025年成为异常年份：
- 出现了至少3–4次影响面较大的全球/近全球事件（尤其是11月18日和12月5日连续两次）。
- 11月18日 被公认为2019年后最严重的一次，影响范围和深度都极高。
- 12月5日再次中断，让很多人质疑Cloudflare的变更控制、回滚机制和“fail small”原则执行情况。
典型特点：
- 大部分严重故障都与配置变更、特征文件/规则传播、控制面组件或DNS/BGP相关。
- 官方复盘非常透明：每次重大事故后都会在blog.cloudflare.com发布详细post-mortem（根因、时间线、改进措施）。
- 恢复速度通常较快（回滚 + 停止传播），但影响传播极广（因为Cloudflare的Anycast网络和安全挑战机制）。
- 不像AWS/Azure/Google那样有明确的SLA信用赔付，但会提供详细解释和改进承诺。

总体而言，Cloudflare在2014–2025这12年间真正达到重大级别（全球核心流量长时间中断）的故障大约5–7次，其中2019年7月和2025年11月18日是公认的两个峰值事件。2025年故障频次明显上升，引发了行业对“互联网基础设施集中化风险”的新一轮讨论。

腾讯云的故障

腾讯云（Tencent Cloud）从2014年到2025年期间，作为中国第二大公有云厂商（仅次于阿里云），整体稳定性在国内云厂商中属于中上水平，真正影响面极广、持续时间长、社会关注度高的全局/多地域重大事故数量相对较少，但一旦出现控制面（管控台/API）或核心存储问题，影响会迅速放大到大量企业和开发者。

腾讯云的status页面（https://status.cloud.tencent.com/history）公开透明度相对较低，历史事件列表通常只展示最近1年，且很多中大型故障不会出现在公开列表中，主要靠官方微信公众号、技术博客、媒体报道和社区讨论拼凑完整图景。

下面按时间顺序列出公认的比较严重的、影响面较广的腾讯云故障事件（基于官方复盘、媒体报道、知乎/微博/开发者社区讨论等公开信息）：

时间	地域/范围	持续时长	主要影响范围与后果	主流原因说明	备注 / 行业评价
2014年11月2日	全国（管控面+部分服务）	约6分钟	腾讯云官网访问慢、图片加载失败、控制台异常，部分用户无法正常使用	未详细公开（疑似网络/负载问题）	早期小体量时期，影响有限，但被当时媒体广泛报道
2018年8月	部分用户/云硬盘	不确定（单用户影响数小时至永久）	多位用户云服务器磁盘数据清零/丢失，涉及千万元级别损失	磁盘静默错误 + 数据迁移过程中校验/副本机制失效	腾讯云历史上最严重的“丢数据”事件，引发云安全信任危机，官方发详细复盘
2023年（零星报道）	部分地域/服务	数十分钟–数小时	零星控制台/API异常、存储访问抖动	未见公开详细复盘	相比阿里云同年11月全球事故，腾讯云这一年相对平稳
2024年4月8日	全球17个地域	约74–87分钟	控制台完全无法登录、云API全面报错（504 Gateway Timeout）、CVM/RDS等实例正常运行但无法管理/续费/扩容等操作；1957个客户报障	云API新版本向前兼容性不足 + 配置数据灰度机制缺失 → 全量发布导致全局传播	腾讯云近年来最严重的一次，被广泛称为“全球大故障”“管控面崩盘”，类似阿里云2023年11月风格
2025年10月15日	多地域	约数十分钟–1小时	弹性伸缩（Auto Scaling）等服务异常	未详细公开	来自status页面，属于中型故障
2025年10月17日	广州地域	约1小时多	智能数智人相关服务异常	未详细公开	区域级，影响特定AI/数字人产品

重要观察与趋势（2014–2025）

早期（2014–2018）：故障多为存储层数据丢失或短时访问异常，典型如2018年“丢数据”事件对企业信任打击最大。
2019–2023：腾讯云故障频次和严重度明显下降，鲜有全国/全球级事件，稳定性优于阿里云同期（尤其是2023年阿里云11·12史诗级故障时腾讯云表现平稳）。
2024–2025：2024年4月8日成为转折点，这次管控面全局故障让很多人重新审视腾讯云的“变更安全”和“灰度发布”能力。2025年出现几次中型事件，但未见类似2024年4月或阿里云/谷歌云那种“全服务瘫痪”级别。
典型特点：
- 控制面/API问题是近年最主要痛点（2024年4月事件典型代表）。
- 存储/数据丢失类事故对企业杀伤力最大（2018年案例）。
- 腾讯云官方复盘相对及时（尤其是重大事件会在公众号、技术社区发详细说明）。
- 没有像AWS/Azure/Google那样严格的SLA信用赔付机制，但会提供代金券/补偿。
- 故障传播效应不如阿里云、Cloudflare那么剧烈（因为腾讯云客户结构更偏企业/游戏/视频，对消费互联网依赖相对低）。

总体而言，腾讯云在2014–2025这12年间真正称得上重大级别（全国/全球管控面长时间不可用或严重数据丢失）的故障大约3–5次，其中2018年丢数据和2024年4月8日全球管控面故障是公认影响力和讨论度最高的两起。

故障透明度

就故障透明度而言，阿里云和腾讯云是比较薄弱的。阿里云的健康看板（https://status.aliyun.com/#/?region=cn-shanghai）和腾讯云的健康看板（https://status.cloud.tencent.com/history）只显示了过去1年发生过的历史事件。

Azure（https://azure.status.microsoft/en-us/status/history/）保留了5年，cloudflare（https://www.cloudflarestatus.com/history?page=17）最详细透明，可以使用page一直翻页到前面几年的事故。

公有云“死因”

在我年轻的时候，我热衷于查阅并重构别人的代码。直到Java Boy给了我上了一课：即便我帮他修复了内存泄露的问题，他感受到的是一种来自内心深处的存在主义危机。他以愤怒作为掩盖自己无能的藉口，把“维持kubernetes平台稳定”的罪责推到我身上。

其实我也不是很乐意帮他擦屁股。我只是觉得频繁出现的OOM kill event 报警让我很烦躁而已。从这个故事中，我领悟了0的哲学：边际收益为0的重构没人愿意做。

因此便能推导得出软件行业的熵增定律：项目代码库会随着时间推移而变成一座屎山。

有人问，这跟公有云的死因有什么关系呢？

实际上是非常有关系的。因为“工业克苏鲁”要求企业贡献随时间递增的利润。因此对于公有云厂商，对于他们的基层员工而言，就必须“讲一种新的增长故事”，比如现在是2026年，就以AI作为新的增长极。

而旧的的代码就一直烂在那里。因为修改他们没有任何边际收益。

于是大家就逐渐形成这种共识：不修改别人的代码，任由它成为一座屎山。代码如此，架构亦如此。即便网络拓扑成为纯粹的相互依赖的网状结构，反正出事的时候大家都用不了，当宕机责任被平等分摊，自己便没有责任。

讽刺的是，一个在职期间0故障发生，天天上班睡觉的运维工程师，会被认为是一个不称职的人。因为他看起来啥事都没做。然而反直觉的是，这种人其实应该当成企业的吉祥物供起来，因为你根本不知道他之前为了公司的业务稳定付出了多少努力。或者说他纯粹是命好，配享大庙。

实际上，最好的运维在于不运维。因为运维收入与职业风险完全不对等。上级不会因为你删除了一个看起来没用的配置，而在这个月多给你发一笔补贴；但你会因为删除了一个有用的数据库配置，而遭到客户的辱骂。

公有云企业忘了，网络效应可以把他们扶起来，也可以把他们重重地摔下去。当他们的客户越多，单次宕机而产生的网络连锁反应就会越大。就好比2025年12月4日晚约21:00–23:37的支付宝故障，这已经是阿里系在2025年的第六次大故障。

当用户规模以亿作为计算单位，每一秒都有人在支付。然而业务又要求往软件上继续加新的功能，最后整个系统不堪重负。

而且公有云服务厂商赔付完全不对等。像支付宝这种最多就是多退少补，少收用户的钱当做福利。但政企的损失则完全无法估算。如果业务寄宿在公有云上，而公有云宕机了，那么作为业务方的你，要怎么向公有云介绍自己的损失呢？

“我的系统每天交易几百个亿，你赔我几个亿？”

客户的损失无法量化，因此阿里云通常都是赔点代金券。但这完全是杯水车薪。损失的时间，谁也无法说清楚实际的业务影响和时间价值。

网络效应带来了公有云指数级别的收入增长。但作为大型政企用户而言，对公有云反依赖应该提上日程。把自己的命运跟单一的云厂商绑定，无法应对突发的风险。

小并发高可用系统

在此基础上，我提出我的“小并发高可用系统”概念。我的初步设想是通过存储的冗余，实现业务的高可用。当流量平稳分摊到设计冗余的信息系统，既规避了集中式流量带来的单集群流量洪峰，又减少了问题扩散的半径。

举个最简单的例子。在DNS解析的时候，把广东的DNS解析设置在一个华南区域的阿里云、腾讯云kubernetes集群。每一个集群互不依赖，运行内部完整的信息业务系统。这样最坏情况，公有云自身出问题，只会出现50%的不可用。

同时不可用，概率极小。

孤帆远影碧山尽，唯见长江天际流

参考链接

【1】 2025 年 11 月 18 日 Cloudflare 服务中断 https://blog.cloudflare.com/zh-cn/18-november-2025-outage/

【2】从 AWS 故障看 DNS 的隐形杀伤力：DeepFlow 如何在混乱中快速锁定根因 https://my.oschina.net/u/3681970/blog/18697034

【3】 2023-11-12阿里云故障复盘与分析 https://github.tiankonguse.com/blog/2023/11/29/aliyun-break.html

Summary

This article starts from formal logic and definitions (network effect, law of entropy increase, anti-dependency, and the “zero” philosophy of zero marginal benefit), systematically reviews major outages of mainstream public clouds and infrastructure—Alibaba Cloud, Google Cloud, Azure, Cloudflare, Tencent Cloud—from 2014 to 2025, and compares their fault transparency. On this basis, it analyzes the “causes of death” of public cloud: software entropy and zero marginal benefit make legacy code and architecture hard to govern; network effects amplify cascading failures; and SLA compensation is severely misaligned with actual losses for enterprises and government. The author recommends that large enterprises and government agencies prioritize “anti-dependency” on any single public cloud and proposes a “small-concurrency high-availability system”—reducing single-point risk and blast radius through storage redundancy and traffic distribution (e.g., multi-region, multi-cluster DNS resolution).

Formal Logic and Definitions

Network effect: The more users (or participants) a product/service/platform has, the more valuable it becomes to each user.

Law of entropy increase: A project’s codebase will, over time, turn into a mess.

Anti-dependency: The reverse of depending on a single programming language, tech stack, or cloud platform. Examples: polyglot programming, multi-stack choices, multi-cloud strategy. Anti-dependency lets the business run smoothly without being tied to one language, open-source project, or public cloud.

Zero: Nobody wants to do refactoring whose marginal benefit is zero.

AWS Outages

Time	Region / Scope	Duration	Main Impact & Consequences	Official / Main Cause	Notes / Industry Evaluation
2014-06-13	us-east-1 (Northern Virginia)	Not specified	Affected key components of Amazon SimpleDB, some users unable to access or operate databases.	Power-related system interruption.	Relatively small-scale; quick recovery; highlighted power redundancy issues.
2014-08-07	EU West (Ireland)	Not specified	Impacted EC2, EBS, and RDS; some European users lost access to instances, storage, and databases.	Internal system event (root cause not detailed).	Regional impact; showed early limitations in regional isolation.
2014-11-26	Global (CloudFront DNS)	~2 hours	DNS servers down, affected CDN; many websites and cloud services failed to resolve requests.	DNS server failure.	Short but broad impact; exposed DNS fragility of the world’s largest cloud.
2015-09-20	us-east-1	Several hours	DynamoDB outage caused internal service communication failure; affected Netflix, Reddit, IMDb, Amazon properties.	Internal service communication chain reaction.	Serious incident; millions impacted; warned about tight internal dependencies.
2017-02-28	us-east-1	4–5 hours	S3 control plane outage; Slack, Trello, GitHub Pages, Quora, many sites lost images/files.	Engineer typo deleted critical configuration.	One of the most famous outages ever; “most expensive typo in history”.
2020-11-25	us-east-1	Several hours	Kinesis and Cognito disruption; affected Roku, Adobe, Flickr; streaming & auth services down.	Capacity update issue.	Happened during pandemic; highlighted capacity planning challenges.
2022-12-05	us-east-2 (Ohio)	~40 minutes	Availability Zone outage; impacted multiple services in the region.	Not publicly detailed (likely network/power).	Short but emphasized importance of multi-AZ architecture.
2023-06-13	us-east-1	Not specified	Lambda service disruption; affected large organizations (Boston Globe, NYC subway, AP, etc.).	Not publicly detailed.	Exposed fragility of serverless computing at scale.
2024-07-30	us-east-1	Not specified	Kinesis Data Streams outage; impacted real-time data processing applications.	Not publicly detailed.	Highlighted risks in stream-processing dependencies.
2025-02	eu-north-1 (Stockholm)	Not specified	Major network issue in one AZ; affected core services in Europe.	Major network failure.	Regional event; reflected challenges in European infrastructure expansion.
2025-10-19/20	us-east-1	>15 hours	DynamoDB API endpoint outage (DNS failure); impacted Slack, Reddit, Roblox, Fortnite, Coinbase, Venmo, Duolingo, Canva, PlayStation, banks, airlines (Delta/United delays), Amazon services; >3,500 companies, 60+ countries, >17 million user reports.	DNS resolution failure leading to cascading effect.	Largest cloud outage of 2025; called “the biggest cloud fragility exposure”; strongly pushed multi-cloud strategies.

Analysis of the most severe incidents
The most severe outages were 2015-09-20 (DynamoDB), 2017-02-28 (S3), and especially 2025-10-19/20 (DynamoDB DNS). All occurred in us-east-1, AWS’s oldest and busiest region.
Severity ranking:

2015: entertainment & social platforms heavily affected, but limited to consumer services.
2017: massive productivity and developer impact; huge economic loss due to human error.
2025: longest duration (>15h), broadest scope (finance, gaming, education, aviation, critical infrastructure), highest user impact — widely regarded as the most serious single cloud outage in recent years.
Common lessons: over-reliance on us-east-1, control-plane fragility, cascading failures. Industry increasingly recommends multi-region, multi-cloud, or hybrid architectures.

Alibaba Cloud Outages

From 2014 to 2025, Alibaba Cloud did not have an unusually high number of major incidents that were widely reported, officially disclosed, truly broad in impact, long in duration, and widely called “major outages” (relative to its scale, its overall SLA remains among the best in the industry). A few of them, however, did cause significant social impact and industry debate. Below is a chronological list of major-level outages (based mainly on public reports, official announcements, media and community post-mortems):

Time	Region/Scope	Duration	Main Impact and Consequences	Official/Main Cause	Notes / Industry View
June 2018	Some regions (details not public)	~30 min	Some cloud products abnormal, limited impact	Not disclosed in detail	Described by some media as “major technical failure”
March 3, 2019	North China 2 (Beijing) AZ-C	Hours	Many ECS disk failures, many sites/Apps down	Disk failure	Significant impact; Alibaba Cloud compensated per SLA
Dec 18, 2022	Hong Kong Region AZ-C	~15.5 hours	Hong Kong region largely down; key sites in Macau (monetary authority, Galaxy, Lotus TV, etc.) unavailable; OKX affected	Cooling equipment failure → cascade → large outage	Widely called “one of the worst incidents in Alibaba Cloud history”
Nov 12, 2023	All regions and services globally	~3h 16m	Console, API, MQ, microservices, monitoring, ML, etc. largely abnormal; Taobao, DingTalk, Xianyu, Ele.me, Alibaba Cloud Drive, etc. down	Core component failure (auth/metadata/control plane)	Widely seen as Alibaba Cloud’s worst, broadest outage; “epic,” “unprecedented in the industry”
Nov 27, 2023	Some servers	~2 hours	Server access abnormal	Not disclosed in detail	Only half a month after 11·12; renewed trust concerns
July 2, 2024	Some regions/services	Hours	Console and some services abnormal	No detailed post-mortem	Mid-sized; impact smaller than earlier incidents
2025 (date unclear)	Global (suspected DNS-related)	~6 hours	DNS hijacking led to global service issues	DNS hijacking	From 2025 public cloud outage summary; details TBD

Important Notes and Trends

2014–2018 early: Very few publicly disclosed major P0-level incidents in this period; more local, limited issues. Scale was much smaller; impact was smaller too.
Two most severe:
- 2022.12 Hong Kong 15.5h → Longest single-region outage; severe impact on critical infrastructure in Hong Kong and Macau.
- 2023.11.12 global 3h+ → Control plane and global services down; widely seen as a rare “all regions × all services” failure, breaking the “multi-active, multi-center, N nines” myth.
2024–2025: From known information, frequency and severity are lower than 2022–2023, but medium-to-large events still occur (e.g. 2025 DNS hijacking had broad impact).
Alibaba Cloud’s handling: Most major incidents get detailed post-mortems (especially 2022 Hong Kong and 2023 global); SLA compensation (usually vouchers); senior/formal apologies.

Overall, in 2014–2025 Alibaba Cloud had roughly 5–7 incidents that qualify as “major,” with Nov 12, 2023 and Dec 2022 Hong Kong generally seen as the two most severe.

Google Cloud Outages

Google Cloud Platform (GCP) had relatively good overall SLA from 2014 to 2025; major incidents that truly affected global scope or multiple core services were not especially frequent (fewer than AWS and Azure in terms of global disasters). When they did occur, they often affected many third-party apps (e.g. Snapchat, Spotify, Discord, services depending on Cloudflare), with high social impact.

Below is a chronological list of serious, broad-impact GCP outages (based on public Status Dashboard, media, Wikipedia, industry post-mortems):

Time	Region/Scope	Duration	Main Impact and Consequences	Main Cause	Notes / Industry View
Aug 2015	Europe (Ghlin, Belgium)	Hours	Compute Engine very high read/write error rate; some data loss	Lightning damaged part of datacenter	Google rarely admitted data loss; limited customer set
July 2018	Global (multiple regions)	Hours	GCP services abnormal; Snapchat, Spotify, etc. largely unusable	Network congestion + internal routing	Widely reported; strong third-party impact
June 2, 2019	US East + global	~4–5 hours	YouTube, Gmail, G Suite largely down; Snapchat, Discord, Vimeo login failures	US East network congestion + cascade	Broad impact; social media buzz
Dec 14, 2020	Global	~1 hour	Gmail, YouTube, Google Home, Nest, Pokémon GO, etc.—almost all auth-dependent services down	Identity/auth system (IAM-like) global failure	Consumer services “down”; one of the worst
Aug 2022	Iowa datacenter	Local	Electrical fire (3 injured); some services affected, not global	Datacenter electrical fire	Physical facility; not purely software/architecture
Apr 2023	Europe (Paris, etc.)	Hours	Multi-region network + service disruption	Flood + datacenter + network issues	Weather-related; medium impact
Oct 23, 2024	Europe (Frankfurt europe-west3)	~12+ hours	Region largely unavailable; many European customers affected	Not disclosed in detail (suspected control plane/network)	One of the longest single-region outages
June 12, 2025	Global (40+ regions)	~2.5–3 hours	70+ GCP services abnormal; IAM down → API requests failing; Spotify, Discord, Twitch, Cloudflare, Fitbit, Gmail, Drive, YouTube, etc. down	Service Control (API auth core) automation update introduced severe bug → crash loop → global overload	Widely seen as GCP’s worst global outage since 2020
July 18, 2025	us-east1	~2 hours	Multiple products higher error rates	Not disclosed in detail	Mid-sized; recovery relatively fast

Azure Outages

Microsoft Azure did not have an unusually high number of major incidents that were broad in impact, long in duration, and highly visible from 2014 to 2025 (compared with earlier, smaller-scale frequent glitches, the trend improved). A few events did cause global or multi-service impact, especially when Microsoft 365, Teams, Xbox, Outlook and other consumer/enterprise products were involved; the propagation effect was very visible.

Below is a chronological list of major-level Azure outages (based on Azure Status History, Post Incident Reviews, media, Wikipedia, industry post-mortems):

Time	Region/Scope	Duration	Main Impact and Consequences	Main Cause	Notes / Industry View
Aug 14–18, 2014	US Central, US East, US East 2, Europe North	Multiple days, hours per event	Cloud Services, SQL Database, VM, Websites, HDInsight, Mobile Services, Service Bus largely unavailable	Multiple network/storage issues	2014’s most concentrated wave; Azure still young
Nov 18–19, 2014	Multiple regions (US, EU, Asia)	~11 hours	Azure Storage at core; VM, Websites, Visual Studio Online, Xbox Live, MSN, Search, 20+ services down	Storage perf config change → Blob front-end infinite loop	Azure’s worst early incident; detailed RCA; customer compensation
Sep 15, 2016	Global	Hours	Widespread DNS resolution failure; many Azure DNS–dependent services affected	Global DNS issue	Exposed DNS single-point risk
June 20, 2018	North America multiple datacenters	Hours–1+ day	Cooling failure (lightning + surge protection) → multi-service disruption	Physical facility (lightning cascade)	Rare hardware/infrastructure incident
Sep 4, 2018	Multiple regions	25+ hours (some services 3 days)	Core services long unavailable	Cooling (lightning + surge)	One of the longest recoveries
Jan 23, 2023	Global (core network)	~3 hours	Microsoft 365 (Teams, Outlook, Exchange), some Azure services down	WAN issue	M365 “down”; huge impact
July 18, 2024	US Central	~Half day	VM and other management operations failing; customers unable to access managed services	Access control error + infrastructure failure	Close in time to next-day CrowdStrike global BSOD but independent
Jan 8–9, 2025	East US 2, etc.	Hours	Azure Databricks, Synapse, Functions, App Service, VM network disruption	Network component issue	Notable early 2025
Oct 29, 2025	Global	~8 hours	Azure Front Door at core; Microsoft 365, Outlook, Teams, Xbox Live, Minecraft, Copilot down; Alaska Airlines, Heathrow, Costco, Starbucks, etc. affected	Azure Front Door config change + protection bug → inconsistent config propagated globally	2025’s worst for Azure; Downdetector 30k+ reports; similar to AWS same month
Nov 5–6, 2025	West Europe (AZ01)	~9–10 hours	VM, PostgreSQL/MySQL Flexible Server, AKS, Storage, Service Bus degraded/out	Datacenter thermal event	Serious regional outage

Observations and Trends (2014–2025)

2014: Azure in rapid expansion; config changes and storage layer issues frequent; most concentrated year (Nov incident is a classic case).
2015–2019: Fewer incidents; still mostly single region or infrastructure (cooling, lightning, DNS); impact relatively contained.
2020–2023: Few major global outages; more network or M365 dependency on Azure (e.g. Jan 2023).
2024–2025: Control plane/edge (e.g. Azure Front Door) became a new pain point; Oct 29, 2025 widely seen as Azure’s worst global outage in recent years, comparable to Alibaba Nov 2023 or GCP June 2025.
Typical traits: Detailed Post Incident Review (PIR) after major incidents; config change, control plane, network often root causes (not just hardware); strong third-party propagation when M365, Xbox, Teams fail; SLA compensation (credit); customers care most about business continuity.

Overall, Azure had roughly 8–10 major-level (global/multi-service, long) outages in 2014–2025; severity and frequency on par with AWS and GCP; cascading failure from config error is a recurring pattern.

Cloudflare Outages

Cloudflare, as one of the world’s largest CDN, security, DNS, and edge providers, did not have an unusually high number of major incidents that caused broad internet disruption from 2014 to 2025. When they did occur, impact often reached millions to hundreds of millions of users (Cloudflare carries ~20–25% of global web traffic).

Typical pattern: recovery is often fast (most ease within 1–4 hours), but propagation is extreme—when core proxy, DNS, or security components fail, many top sites (X, ChatGPT, Shopify, Discord, Spotify, parts of AWS, etc.) see 5xx or unreachable at once.

Below is a chronological list of major-level Cloudflare outages (based on official blog, status.cloudflare.com history, media, Wikipedia; focused on global/core traffic events):

Time	Scope	Duration	Main Impact and Consequences	Main Cause	Notes / Industry View
July 2, 2019	Global	~1–2 hours	Many sites 502/503/504; large parts of internet unreachable	Software deploy introduced severe bug → proxy layer crash	Widely seen as Cloudflare’s worst ever; detailed post-mortem
2020 multiple	Some regions/control plane	Hours	Dashboard, analytics, some APIs down; core proxy largely stable	Control plane issues	More impact on developers; less for general users
June 2022	Multiple datacenters (19)	~1.5 hours	Core proxy down; many sites unreachable	Network config error	Medium scale; fast recovery
Mar 21, 2025	Global	~1h 7m	Storage read/write severely impaired; many storage/cache–dependent services affected	KV/storage layer write failure + partial read issues	Notable early 2025
June 12, 2025	Global (some features)	Hours	Some features/services down; core traffic largely OK	Specific module deploy	Not core traffic; limited impact
July 14, 2025	Global (1.1.1.1 DNS)	~62 minutes	Public DNS resolver (1.1.1.1) fully down; many users unable to reach internet	Config error → BGP route withdrawal → DNS prefix disappeared from global routing table	Severe for 1.1.1.1 users; “internet-breaking” level
~Oct 2025	Some services	Tens of minutes	Brief DNS resolution disruption	DNS-related config	Mid-sized
Nov 18, 2025	Global	~4–5 hours (peak longer)	Large-scale internet outage: X (Twitter), ChatGPT, Shopify, Spotify, Letterboxd, Indeed, Canva, Uber, DoorDash, Truth Social, League of Legends, etc.; ~20% web traffic; 1/3 of Alexa top 10k sites	Bot Management rules file abnormal growth (DB permission change → file size doubled) → global propagation → proxy crash	2025’s worst; also worst global traffic outage since 2019
Dec 5, 2025	Global	Hours	Widespread 5xx again; Shopify, Zoom, Vinted, Fortnite, Square, Just Eat, Canva, Vimeo, parts of AWS, Deliveroo, etc.	No full official root cause (suspected config/propagation)	Only 17 days after Nov 18; two major incidents in a row raised strong criticism

Observations and Trends (2014–2025)

2014–2018: Cloudflare grew fast; few public global major incidents; more local/regional/functional issues; internet depended on Cloudflare less than today.
July 2019: Became Cloudflare’s classic “black swan”; no core proxy global outage of similar scale for over six years.
2025 as anomaly: At least 3–4 broad global/near-global events (especially Nov 18 and Dec 5 back-to-back). Nov 18 widely seen as worst since 2019. Dec 5 again led many to question change control, rollback, and “fail small.”
Typical traits: Most serious incidents tied to config change, rules/propagation, control plane, or DNS/BGP; very transparent post-mortems on blog.cloudflare.com; recovery usually fast (rollback + stop propagation), but impact very broad (Anycast + challenge mechanism); no explicit SLA credit like AWS/Azure/Google, but detailed explanation and improvement commitments.

Overall, Cloudflare had roughly 5–7 major-level (global core traffic, long) outages in 2014–2025; July 2019 and Nov 18, 2025 are the two peak events. 2025 saw a clear rise in frequency and renewed discussion of “internet infrastructure centralization risk.”

Tencent Cloud Outages

Tencent Cloud, as China’s second-largest public cloud (after Alibaba Cloud) from 2014 to 2025, had relatively good stability among domestic providers. Truly broad, long, high-visibility global/multi-region major incidents were relatively few; when control plane (console/API) or core storage failed, impact quickly spread to many enterprises and developers.

Tencent Cloud’s status page (https://status.cloud.tencent.com/history) is relatively opaque; history often shows only the last year, and many medium-to-large incidents are missing; the full picture relies on official WeChat, tech blog, media, and community.

Below is a chronological list of serious, broad-impact Tencent Cloud incidents (based on official post-mortems, media, Zhihu/Weibo/developer community):

Time	Region/Scope	Duration	Main Impact and Consequences	Main Cause	Notes / Industry View
Nov 2, 2014	Nationwide (control plane + some services)	~6 min	Tencent Cloud site slow, images failing, console abnormal; some users unable to use	Not disclosed (suspected network/load)	Early, small scale; limited impact but widely reported
Aug 2018	Some users/cloud disk	Unclear (single-user impact hours to permanent)	Multiple users’ cloud disk data wiped/lost; losses in tens of millions	Silent disk error + migration validation/replica failure	Tencent Cloud’s worst “data loss” incident; trust crisis; detailed post-mortem
2023 (sporadic)	Some regions/services	Tens of min–hours	Sporadic console/API issues, storage jitter	No detailed public post-mortem	Compared with Alibaba Nov 2023 global, Tencent was relatively stable
Apr 8, 2024	17 regions globally	~74–87 min	Console fully unreachable; cloud API 504 Gateway Timeout; CVM/RDS instances running but unmanageable/no renew/scale; 1957 customers reported	New API version backward-incompat + missing config gray release → full rollout → global propagation	Tencent Cloud’s most serious in recent years; “global outage,” “control plane collapse”; similar style to Alibaba Nov 2023
Oct 15, 2025	Multiple regions	~Tens of min–1 hour	Auto Scaling and other services abnormal	Not disclosed	From status page; mid-sized
Oct 17, 2025	Guangzhou	~1+ hour	AI digital-human related services abnormal	Not disclosed	Regional; specific AI/digital-human product

Observations and Trends (2014–2025)

Early (2014–2018): Failures often storage data loss or short access issues; 2018 “data loss” hit enterprise trust hardest.
2019–2023: Tencent Cloud incident frequency and severity dropped; few nationwide/global events; stability better than Alibaba in the same period (e.g. calm during Alibaba 11·12).
2024–2025: Apr 8, 2024 was a turning point; control plane global failure led many to reassess “change safety” and “gray release.” 2025 had several mid-sized events but nothing at “full service down” level like Apr 2024 or Alibaba/Google.
Typical traits: Control plane/API is the main pain point (Apr 2024); storage/data loss is most damaging to enterprises (2018); post-mortems relatively timely (WeChat, tech community); no strict SLA credit like AWS/Azure/Google, but vouchers/compensation; propagation less dramatic than Alibaba/Cloudflare (customer mix more enterprise/gaming/video, less consumer internet).

Overall, Tencent Cloud had roughly 3–5 major-level (nationwide/global control plane long unavailable or serious data loss) incidents in 2014–2025; 2018 data loss and Apr 8, 2024 global control plane are the two most discussed.

Outage Transparency

In terms of outage transparency, Alibaba Cloud and Tencent Cloud are relatively weak.

Alibaba Cloud’s status board (https://status.aliyun.com/#/?region=cn-shanghai) and Tencent Cloud’s (https://status.cloud.tencent.com/history) only show the last year of events.

Azure (https://azure.status.microsoft/en-us/status/history/) keeps five years. Cloudflare (https://www.cloudflarestatus.com/history?page=17) is the most transparent; you can paginate back through earlier years.

“Death” of the Public Cloud

When I was younger, I was keen on reading and refactoring other people’s code. Until “Java Boy” taught me a lesson: even after I fixed his memory leak, what he felt was an existential crisis. He used anger to cover his own inadequacy and blamed “keeping the Kubernetes platform stable” on me.

I wasn’t that eager to clean up his mess either. I just found the frequent OOM kill event alerts annoying. From that story I learned the philosophy of zero: nobody wants to do refactoring whose marginal benefit is zero.

Hence the law of entropy increase in software: a project’s codebase will, over time, turn into a mess.

Someone asked: what does this have to do with the “death” of the public cloud?

It’s very related. Because “industrial Cthulhu” demands that companies deliver ever-increasing profit. So for public cloud vendors and their frontline staff, they must “tell a new growth story”—in 2026, that story is AI.

The old code just rots. Changing it has no marginal benefit.

So everyone converges on the same idea: don’t touch others’ code; let it become a mess. Same for code, same for architecture. Even when the network topology is a pure mesh of mutual dependency, when things break everyone’s down, and when outage responsibility is shared equally, you bear no responsibility.

Ironically, an ops engineer who had zero incidents on their watch and “slept at work” every day would be seen as incompetent—because they look like they did nothing. Counterintuitively, that person should be treated as the company mascot: you have no idea how much they did before to keep things stable. Or they were just lucky and deserve a shrine.

The best ops is no ops. Because ops compensation and career risk are completely misaligned. Your boss won’t give you a bonus for deleting a seemingly useless config; but you will get cursed by customers for deleting a useful database config.

Public cloud vendors forget: network effects can lift them up and can slam them down. The more customers they have, the bigger the network cascade from a single outage. Like the Alipay outage on Dec 4, 2025, ~21:00–23:37—Alibaba’s sixth major incident in 2025.

When user scale is in the hundreds of millions, someone is paying every second. Yet the business keeps asking for more features; eventually the system buckles.

And public cloud compensation is completely misaligned. For something like Alipay it’s at most “refund the difference”; undercharging is treated as a perk. But losses for government and enterprises are incalculable. If your business runs on the public cloud and the cloud goes down, how do you explain your loss to the provider?

“My system does billions in transactions a day; you’re going to compensate me a few hundred million?”

Customer loss is unquantifiable, so Alibaba Cloud usually just hands out vouchers. That’s a drop in the bucket. No one can really account for lost time, actual business impact, or the value of that time.

Network effects brought public cloud exponential revenue growth. For large government and enterprise users, anti-dependency on a single public cloud should be on the agenda. Tying your fate to one cloud vendor cannot handle sudden risk.

Small-Concurrency, High-Availability Systems

On that basis I propose “small-concurrency, high-availability systems”: redundancy in storage to achieve high availability in the business.

When traffic is spread across redundant systems, you avoid the single-cluster traffic spike of centralized flow and shrink the radius of failure.

Simplest example: at DNS resolution, point Guangdong to a South China Alibaba + Tencent Kubernetes cluster. Each cluster is independent and runs a complete internal business system. Worst case, if the public cloud itself fails, you get at most 50% unavailability.

Both being down at once is extremely unlikely.

Farewell, Public Cloud. See you on the Yangtze River.

References

【1】
Cloudflare service outage, November 18, 2025
https://blog.cloudflare.com/zh-cn/18-november-2025-outage/

【2】
The invisible impact of DNS from the AWS outage: how DeepFlow quickly found root cause in chaos
https://my.oschina.net/u/3681970/blog/18697034

【3】
2023-11-12 Alibaba Cloud outage post-mortem and analysis
https://github.tiankonguse.com/blog/2023/11/29/aliyun-break.html

要約

本稿は形式論理と定義（ネットワーク効果、エントロピー増大の法則、反依存性、限界便益ゼロの「ゼロ」の哲学）から出発し、2014年から2025年までのアリババクラウド、Google Cloud、Azure、Cloudflare、テンセントクラウドなど主要パブリッククラウド・インフラの重大障害を体系的に整理し、各社の障害透明性を比較する。その上で、パブリッククラウドの「死因」を分析する：ソフトウェアのエントロピーと限界便益ゼロによりレガシーコード・アーキテクチャの治理が困難になること、障害時にネットワーク効果が連鎖反応を増幅すること、SLA賠償が政企の実際の損失と著しく乖離していること。著者は大型政企が単一パブリッククラウドへの「反依存」を優先すべきだとし、「小並行高可用システム」の構想を提示する——ストレージ冗長とトラフィック分散（例：マルチリージョン・マルチクラスタのDNS解決）により単一点リスクと影響半径を低減する。

形式論理と定義

ネットワーク効果：製品・サービス・プラットフォームの利用者（または参加者）が増えるほど、各利用者にとっての価値が高まる。

エントロピー増大の法則：プロジェクトのコードベースは時間とともにスパゲッティ化する。

反依存性：単一のプログラミング言語・技術スタック・クラウドプラットフォームへの依存の逆。例：多言語混在プログラミング、マルチスタック選定、マルチクラウド戦略。反依存性により、業務は言語・オープンソース・パブリッククラウドに縛られず安定稼働できる。

ゼロ：限界便益がゼロのリファクタリングは誰もやりたがらない。

AWSの障害

時期	地域 / 範囲	継続時間	主な影響と結果	公式 / 主な原因	備考 / 業界評価
2014-06-13	us-east-1 (北バージニア)	未詳	Amazon SimpleDB の重要コンポーネントに影響、一部ユーザーがデータベース操作不可。	電源関連の問題	小規模、迅速回復；電源冗長性の不足が露呈。
2014-08-07	EU West (アイルランド)	未詳	EC2、EBS、RDS に影響；欧州の一部ユーザーがインスタンス・ストレージ・DB にアクセス不可。	内部システムイベント（詳細非公開）	地域限定；初期の地域分離の限界を示した。
2014-11-26	グローバル (CloudFront DNS)	約2時間	DNSサーバーダウン、CDNに影響；多数のウェブサイト・クラウドサービスが名前解決不能。	DNSサーバー障害	短時間だが広範囲；世界最大クラウドのDNS脆弱性が露呈。
2015-09-20	us-east-1	数時間	DynamoDB障害→内部通信途絶；Netflix、Reddit、IMDb、Amazon系サービスに広範な影響。	内部サービスの連鎖反応	深刻なインシデント；数百万ユーザーに影響；内部依存の危険性を警告。
2017-02-28	us-east-1	4〜5時間	S3制御平面停止；Slack、Trello、GitHub Pages、Quoraなど多数のサイトで画像・ファイル消失。	エンジニアの誤操作（重要な設定の誤削除）	史上最も有名な障害の一つ；「史上最も高価なタイポ」。
2020-11-25	us-east-1	数時間	KinesisとCognito障害；Roku、Adobe、Flickrなどに影響；ストリーミング・認証サービス停止。	キャパシティ更新の問題	パンデミック中の発生；キャパシティ計画の難しさを浮き彫りに。
2022-12-05	us-east-2 (オハイオ)	約40分	可用性ゾーン障害；地域内の複数サービスに影響。	詳細非公開（ネットワーク/電源の可能性）	短時間だがマルチAZの重要性を強調。
2023-06-13	us-east-1	未詳	Lambdaサービス障害；Boston Globe、NYC地下鉄、AP通信などに大きな影響。	詳細非公開	サーバーレスコンピューティングの大規模時の脆弱性を露呈。
2024-07-30	us-east-1	未詳	Kinesis Data Streams障害；リアルタイムデータ処理アプリケーションに連鎖影響。	詳細非公開	ストリーム処理依存のリスクを浮き彫りに。
2025-02	eu-north-1 (ストックホルム)	未詳	1つのAZで重大なネットワーク障害；欧州のコアサービスに影響。	大規模ネットワーク障害	地域限定；欧州インフラ拡張の課題を反映。
2025-10-19/20	us-east-1	15時間以上	DynamoDB APIエンドポイント障害（DNS障害）；Slack、Reddit、Roblox、Fortnite、Coinbase、Venmo、Duolingo、Canva、PSN、銀行、航空会社（Delta/United遅延）、Amazon系サービスに影響；3500社以上、60カ国以上、1700万件超の報告。	DNS解決障害による連鎖反応	2025年最大のクラウド障害；「クラウドの脆弱性が最も露呈した事件」；マルチクラウド戦略が強く推奨される。

最も深刻な障害の分析
2014〜2025年で最も深刻だったのは2015年9月（DynamoDB）、2017年2月（S3）、特に2025年10月（DynamoDB DNS）の3件。すべてus-east-1で発生。
深刻度順：

2015年：エンタメ・SNSに大きな打撃だが、主に消費者向け。
2017年：生産性ツール・開発者に甚大な影響；人的ミスによる経済損失が極めて大きい。
2025年：最長時間（15時間超）、最も広範（金融、ゲーム、教育、航空、重要インフラ）、ユーザー影響最大 — 近年最大の単一クラウド障害と評価。
共通教訓：us-east-1への過度な集中、コントロールプレーンの脆弱性、連鎖障害。業界はマルチリージョン、マルチクラウド、ハイブリッドアーキテクチャの採用を強く推奨している。

アリババクラウドの障害

2014年から2025年まで、アリババクラウドが公表・公式開示した影響範囲が広く、継続時間が長く、「重大事故」と広く呼ばれた障害は（体量に比べ）特に多くはなく、全体のSLAは業界トップクラスである。ただしそのうち数件は社会的影響と業界議論を引き起こした。以下は重大級の障害の時系列リスト（主に公開情報・公式発表・メディア・コミュニティの振り返りに基づく）：

時期	地域/範囲	継続時間	主な影響と結果	公式/主流の原因	備考/業界評価
2018年6月	一部地域（詳細非公開）	約30分	一部クラウド製品異常、影響は限定的	詳細非公開	当時メディアにより「重大技術障害」と呼ばれた
2019年3月3日	華北2（北京）AZ-C	数時間	ECSディスク障害多発、多数サイト/アプリ停止	ディスク障害	影響大、アリババクラウドはSLAに基づき賠償
2022年12月18日	香港リージョンAZ-C	約15.5時間	香港域ほぼ全域停止、マカオの重要機関（金融管理局、銀河、蓮花衛視等）サイト不通、OKX影響	冷却設備故障→連鎖反応で大規模ダウン	「アリババクラウド史上最悪の醜聞の一つ」と広く称された
2023年11月12日	全世界域・全サービス	約3時間16分	コンソール・API・MQ・マイクロサービス・監視・ML等ほぼ全線異常；淘宝・釘釘・閑魚・餓了么・阿里雲盤等一斉「クラッシュ」	基盤コアコンポーネント（認証/メタデータ/コントロールプレーン）障害	アリババクラウド史上最悪・影響最広と公認；「エピック」「業界前例なし」
2023年11月27日	一部サーバー	約2時間	サーバーアクセス異常	詳細非公開	11・12事故の半月後、信頼への疑問再燃
2024年7月2日	一部地域/サービス	数時間	コンソール及び一部サービス異常	詳細な振り返りなし	中規模、以前の数件より影響小
2025年（日付不明）	グローバル（DNS関連疑い）	約6時間	DNSハイジャックによりグローバルサービス異常	DNSハイジャック関連	2025年パブリッククラウド障害まとめより、詳細要確認

重要な注記とトレンド

2014–2018年初期：この期間のアリババクラウドの重大P0級障害の公表は極めて少なく、局所・小規模が中心。当時は体量が今よりはるかに小さく、影響も限定的だった。
最悪の二件：
- 2022.12 香港15.5時間 → 単一地域最長障害、港澳の重要インフラに悪影響。
- 2023.11.12 グローバル3時間超 → コントロールプレーン/グローバルサービス全面停止；「全地域×全サービス」同時故障として稀とされ、「マルチアクティブ・マルチセンター・Nナイン」神話を打ち砕いた。
2024–2025：既知の情報では、2022–2023より頻度・深刻度は低下しているが、中〜大規模事象は依然発生（特に2025年DNSハイジャック系は影響範囲が広い）。
アリババクラウドの対応：重大障害の多くで詳細な振り返りを公表（特に2022香港・2023グローバル）；SLA賠償（通常は障害時間に応じた倍率のバウチャー）；幹部/公式の謝罪。

全体として、2014–2025年の12年間でアリババクラウドが「重大事故」と呼べるのはおおよそ5〜7件、その中で2023年11月12日と2022年12月香港が影響力・深刻度で最も高いと公認されている。

グーグルクラウドの障害

Google Cloud Platform（GCP）は2014年から2025年まで、全体のSLAは比較的良好で、グローバルまたは複数コアサービスに真に影響した重大事故は（AWS・Azureに比べグローバル災害級は少ないが）発生時には多くのサードパーティアプリ（Snapchat、Spotify、Discord、Cloudflare依存サービス等）を巻き込み、社会的影響が大きい。

以下は深刻で影響範囲の広いGCP重大障害の時系列リスト（公開Status Dashboard・メディア・Wikipedia・業界振り返り等に基づく）：

時期	地域/範囲	継続時間	主な影響と結果	主流の原因	備考/業界評価
2015年8月	欧州（ベルギーGhlin）	数時間	Compute Engine 読み書きエラー率極高、一部データ損失	落雷でデータセンター一部機器損傷	グーグルがデータ損失を認めた稀有な例、影響は限定的顧客群
2018年7月	グローバル（多地域）	数時間	GCP多サービス異常、Snapchat・Spotify等サードパーティが広範囲でログイン/利用不可	ネットワーク輻輳＋内部ルーティング	当時広く報道、サードパーティ影響が顕著
2019年6月2日	米東部＋グローバル波及	約4–5時間	YouTube・Gmail・G Suite広範囲不可用、Snapchat・Discord・Vimeo等ログイン失敗	米東部ネット輻輳＋カスケード	影響範囲広、SNSで話題
2020年12月14日	グローバル	約1時間	Gmail・YouTube・Google Home・Nest・Pokémon GO等、認証依存サービスがほぼ全滅	認証システム（IAM相当）グローバル障害	コンシューマサービス一斉「クラッシュ」、最大級の一つ
2022年8月	米アイオワ州データセンター	局所	電気火災（負傷3名）、一部サービス波及、グローバルではない	データセンター電気事故による火災	物理施設事故、純粋なソフト/アーキテクチャ問題ではない
2023年4月	欧州（パリ等）	数時間	多地域ネット＋サービス中断	洪水＋データセンター＋ネット問題	気象要因、影響は中程度
2024年10月23日	欧州（フランクフルト europe-west3）	約半日（12時間超）	当該地域ほぼ全サービス不可、欧州顧客多数に影響	詳細非公開（コントロールプレーン/ネット疑い）	単一地域最長障害の一つ
2025年6月12日	グローバル（40超地域）	約2.5–3時間	70超GCPサービス異常、IAM認証崩壊でAPIリクエスト全面失敗；Spotify・Discord・Twitch・Cloudflare・Fitbit・Gmail・Drive・YouTube等広範囲停止	Service Control（API認証コア）の自動更新が深刻バグ導入→クラッシュループ→グローバル過負荷	2020年以降GCP最悪のグローバル障害と公認
2025年7月18日	us-east1	約2時間	複数製品エラー率上昇	詳細非公開	中規模、回復は比較的速い

Azureの障害

Microsoft Azureは2014年から2025年まで、影響範囲が広く、継続時間が長く、社会的注目が高い重大事故の数は（初期の小規模時の頻繁な小障害に比べ）特に多くはないが、数件はグローバルまたは多サービス級の深刻な影響を与え、Microsoft 365・Teams・Xbox・Outlook等のコンシューマ/エンタープライズ製品が絡むと伝播効果が非常に大きい。

以下は重大級Azure障害の時系列リスト（Azure公式Status History・Post Incident Review・メディア・Wikipedia・業界振り返り等の公開情報に基づく）：

時期	地域/範囲	継続時間	主な影響と結果	主流の原因	備考/業界評価
2014年8月14–18日	US Central・US East・US East 2・Europe North	複数日・1回数時間	Cloud Services・SQL Database・VM・Websites・HDInsight・Mobile Services・Service Bus等広範囲不可用	複数ネット/ストレージ問題	2014年最も集中した一波、当時Azureはまだ若い
2014年11月18–19日	多地域（米・欧・アジア一部）	約11時間	Azure Storageを中心にVM・Websites・Visual Studio Online・Xbox Live・MSN・Search等20超サービス中断	ストレージ性能最適化の設定変更→Blobフロント無限ループ	Azure初期最悪の一件、公式詳細RCA、顧客賠償
2016年9月15日	グローバル	数時間	DNS解決広範囲障害、Azure DNS依存サービス多数に影響	グローバルDNS問題	DNS単点リスク露呈
2018年6月20日	北米複数データセンター	数時間–1日超	冷却系故障（落雷＋サージ保護不足）で多サービス中断	物理施設（落雷連鎖）	稀なハードウェア/インフラ級障害
2018年9月4日	多地域	25時間超（一部サービス3日）	複数コアサービス長時間不可用	冷却（落雷＋サージ）	回復最長の一つ
2023年1月23日	グローバル（コアネット影響）	約3時間	Microsoft 365（Teams・Outlook・Exchange）、一部Azureサービス中断	WAN問題	M365一斉「クラッシュ」、影響巨大
2024年7月18日	US Central	約半日	VM等の管理操作失敗、顧客がマネージドサービスにアクセス不可	アクセス制御エラー＋インフラ障害	翌日CrowdStrike全球ブルースクリーンに近接するが独立
2025年1月8–9日	East US 2等	数時間	Azure Databricks・Synapse・Functions・App Service・VM等ネット中断	ネットワークコンポーネント問題	2025年序盤で顕著な一件
2025年10月29日	グローバル	約8時間	Azure Front Doorを中心にMicrosoft 365・Outlook・Teams・Xbox Live・Minecraft・Copilot広範囲停止；Alaska Airlines・Heathrow・Costco・Starbucks等波及	Azure Front Door設定変更＋保護機構のバグで設定不整合がグローバル伝播	2025年Azure最悪、Downdetector3万超報告、同月AWS障害に類似
2025年11月5–6日	West Europe (AZ01)	約9–10時間	VM・PostgreSQL/MySQL Flexible Server・AKS・Storage・Service Bus等多サービス劣化/中断	データセンター熱イベント	リージョン級で深刻な障害

観察とトレンド（2014–2025）

2014年：Azureは急拡大期；設定変更とストレージ層問題が頻発、障害が最も集中した年（特に11月は古典的ケース）。
2015–2019：障害頻度は低下、依然単一地域またはインフラ（冷却・落雷・DNS）が中心、影響は比較的抑制。
2020–2023：重大グローバル障害は少なめ、ネットまたはM365のAzure依存による間接影響（例：2023年1月）が中心。
2024–2025：コントロールプレーン/エッジ（Azure Front Door等）が新たな痛み；2025年10月29日は近年Azure最悪のグローバル中断とされ、アリババ2023年11月やGCP 2025年6月に匹敵。
典型：重大事故のたびに詳細なPost Incident Review (PIR) を公表、透明性が高い；設定変更・コントロールプレーン・ネットが原因となることが多く（単なるハード障害ではない）；M365・Xbox・Teamsが落ちるとサードパーティ伝播が極めて大きい；SLA賠償（クレジット）、顧客は事業継続性を最重視。

全体として、Azureは2014–2025年の12年間で重大級（グローバル/多サービス長時間中断）はおおよそ8–10件、深刻度・頻度はAWS・GCPと同水準で、設定ミスによるカスケードが繰り返し現れるパターン。

Cloudflareの障害

Cloudflareは世界最大級のCDN・セキュリティ・DNS・エッジプロバイダーの一つとして、2014年から2025年まで影響範囲が広くインターネット大規模麻痺を引き起こした重大事故は特に多くはないが、一度起きると数百万〜数億ユーザーに波及し（Cloudflareは全世界の約20–25%のウェブトラフィックを担う）、影響範囲が極めて広い。

特徴は回復が比較的速い（多くは1–4時間で緩和）一方で伝播が極端——コアプロキシ・DNS・セキュリティコンポーネントが落ちると、X・ChatGPT・Shopify・Discord・Spotify・AWS一部等のトップサイトが同時に5xxやアクセス不可になる。

以下は重大級Cloudflare障害の時系列リスト（公式ブログ・status.cloudflare.com履歴・メディア・Wikipedia・業界振り返り、グローバル/コアトラフィック中断に焦点）：

時期	範囲	継続時間	主な影響と結果	主流の原因	備考/業界評価
2019年7月2日	グローバル	約1–2時間	多数サイトで502/503/504、インターネットの広域がアクセス不可	ソフトウェアデプロイが深刻バグを導入→プロキシ層クラッシュ	Cloudflare史上最悪と公認、公式詳細振り返り
2020年複数回	一部地域/コントロールプレーン	数時間	ダッシュボード・分析・一部API不可；コアプロキシはほぼ安定	コントロールプレーン問題	開発者への影響大、一般ユーザーは感知小
2022年6月	複数データセンター（19）	約1.5時間	コアプロキシ中断、多数サイトアクセス不可	ネットワーク設定エラー	中規模、回復は速い
2025年3月21日	グローバル	約1時間7分	ストレージ読み書き深刻障害、ストレージ/キャッシュ依存サービス多数に影響	KV/ストレージ層書き込み失敗＋一部読み異常	2025年序盤で顕著
2025年6月12日	グローバル（一部機能）	数時間	一部機能/サービス不可、コアトラフィックはほぼ正常	特定モジュールデプロイ	コアトラフィック中断ではなく影響は限定的
2025年7月14日	グローバル（1.1.1.1 DNS）	約62分	パブリックDNSリゾルバ（1.1.1.1）完全不可、多数ユーザーがインターネット接続不可	設定エラー→BGPルート撤回→DNSプレフィックスがグローバルルーティングテーブルから消失	1.1.1.1依存ユーザーに極めて深刻、「断網級」
2025年10月頃	一部サービス	数十分	DNS解決の短時間中断	DNS関連設定	中規模
2025年11月18日	グローバル	約4–5時間（ピークはより長い）	大規模インターネット中断：X（Twitter）・ChatGPT・Shopify・Spotify・Letterboxd・Indeed・Canva・Uber・DoorDash・Truth Social・League of Legends等多数トップサービス麻痺；約20%ウェブトラフィック、Alexa上位1万サイトの1/3が影響	Bot Managementルールファイル異常肥大（DB権限変更でファイルサイズ倍増）→全网伝播→プロキシクラッシュ	2025年最悪、2019年以来最悪のグローバルトラフィック中断
2025年12月5日	グローバル	数時間	再び広範囲5xx；Shopify・Zoom・Vinted・Fortnite・Square・Just Eat・Canva・Vimeo・AWS一部・Deliveroo等影響	完全な公式根因なし（設定/伝播類疑い）	11月18日からわずか17日、連続二回の重大事故で強い批判

観察とトレンド（2014–2025）

2014–2018年初期：Cloudflareは急成長；公表されたグローバル重大障害は少なく、局所・地域・機能問題が中心；当時インターネットのCloudflare依存度は今より低い。
2019年7月：Cloudflare史上の古典的「ブラックスワン」；その後6年以上、同規模のコアプロキシ全局中断はなし。
2025年は異常な年：少なくとも3–4回の影響の大きいグローバル/準グローバル事象（特に11月18日と12月5日の連続）。11月18日は2019年以来最悪と公認。12月5日の再発で、変更管理・ロールバック・「fail small」の実行が疑問視された。
典型：深刻な障害の多くが設定変更・ルール/伝播・コントロールプレーンまたはDNS/BGPに関連；blog.cloudflare.comで毎回詳細なpost-mortem（根因・タイムライン・改善策）を公開、透明性が高い；回復は通常速い（ロールバック＋伝播停止）が影響は極めて広い（Anycast＋チャレンジ機構）；AWS/Azure/Googleのような明確なSLAクレジット賠償はないが、詳細説明と改善コミットを提供。

全体として、Cloudflareは2014–2025年の12年間で重大級（グローバルコアトラフィック長時間中断）はおおよそ5–7件、2019年7月と2025年11月18日が二つのピーク。2025年は障害頻度が明らかに上昇し、「インターネットインフラ集中化リスク」の議論が再燃した。

テンセントクラウドの障害

テンセントクラウドは2014年から2025年まで、中国第二のパブリッククラウド（アリババに次ぐ）として、国内クラウドベンダーの中では安定性は中〜上で、影響が極めて広く、継続時間が長く、社会的注目が高いグローバル/多地域重大事故は相対的に少ないが、コントロールプレーン（コンソール/API）やコアストレージに問題が起きると、影響は多数の企業・開発者に急速に拡大する。

テンセントクラウドのステータスページ（https://status.cloud.tencent.com/history）の公開透明性は比較的低く、履歴は通常直近1年のみで、中〜大規模障害の多くは一覧に載らず、公式微信・技術ブログ・メディア・コミュニティで全体像を補う。

以下は深刻で影響範囲の広いテンセントクラウド障害の時系列リスト（公式振り返り・メディア・知乎/微博/開発者コミュニティ等の公開情報に基づく）：

時期	地域/範囲	継続時間	主な影響と結果	主流の原因	備考/業界評価
2014年11月2日	全国（コントロールプレーン＋一部サービス）	約6分	テンセントクラウド公式サイト遅延・画像読込失敗・コンソール異常、一部ユーザーが正常利用不可	詳細非公開（ネット/負荷疑い）	初期小規模期、影響は限定的だが当時メディアで広く報道
2018年8月	一部ユーザー/クラウドディスク	不明（単一ユーザーで数時間〜恒久）	複数ユーザーのクラウドサーバーディスクデータゼロ/消失、千万単位の損失	ディスク静默エラー＋データ移行時の検証/レプリカ機構不全	テンセントクラウド史上最悪の「データ消失」、クラウド信頼危機、公式詳細振り返り
2023年（散発）	一部地域/サービス	数十分–数時間	散発的なコンソール/API異常、ストレージジッター	公開の詳細振り返りなし	アリババ2023年11月グローバルと比べテンセントは比較的安定
2024年4月8日	全球17地域	約74–87分	コンソール完全ログイン不可、クラウドAPI全面504 Gateway Timeout；CVM/RDS等インスタンスは稼働するが管理/更新/スケール不可；1957件の顧客障害報告	クラウドAPI新バージョンの後方互換不足＋設定データのグレーリリース機構欠如→一斉リリースでグローバル伝播	テンセントクラウド近年最悪、「全球大障害」「コントロールプレーン崩壊」と広く呼ばれ、アリババ2023年11月スタイルに類似
2025年10月15日	多地域	約数十分–1時間	弹性伸缩（Auto Scaling）等サービス異常	詳細非公開	ステータスページより、中規模
2025年10月17日	広州地域	約1時間超	智能数智人関連サービス異常	詳細非公開	リージョン級、特定AI/デジタルヒューマン製品

観察とトレンド（2014–2025）

初期（2014–2018）：障害はストレージ層のデータ消失や短時間アクセス異常が典型；2018年「データ消失」が企業信頼を最も痛撃。
2019–2023：テンセントクラウドの障害頻度・深刻度は明らかに低下、全国/グローバル級は稀、安定性は同期のアリババより良好（特に2023年アリババ11・12エピック障害時はテンセントは安定）。
2024–2025：2024年4月8日が転換点；このコントロールプレーン全局障害で多くの人がテンセントクラウドの「変更安全」と「グレーリリース」能力を再検討。2025年は中規模が数回あるが、2024年4月やアリババ/グーグルクラウドのような「全サービス麻痺」級は見られない。
典型：コントロールプレーン/APIが近年の最大の痛み（2024年4月が代表）；ストレージ/データ消失が企業への打撃が最大（2018年事例）；公式振り返りは比較的タイムリー（重大時は微信・技術コミュニティで詳細説明）；AWS/Azure/Googleのような厳格なSLAクレジット賠償はないが、バウチャー/補償を提供；障害の伝播はアリババ・Cloudflareほど劇的ではない（顧客構成が企業/ゲーム/動画寄りで、コンシューマインターネット依存が相対的に低いため）。

全体として、テンセントクラウドは2014–2025年の12年間で重大級（全国/グローバルコントロールプレーン長時間不可または深刻なデータ消失）と呼べるのはおおよそ3–5件、2018年データ消失と2024年4月8日グローバルコントロールプレーン障害が影響力・議論度で最も高い二件とされている。

障害の透明性

障害の透明性という点では、アリババクラウドとテンセントクラウドは比較的弱い。

アリババクラウドのステータスボード（https://status.aliyun.com/#/?region=cn-shanghai）とテンセントクラウドのステータスボード（https://status.cloud.tencent.com/history）は、過去1年間のイベントしか表示しない。

Azure（https://azure.status.microsoft/en-us/status/history/）は5年分を保持。Cloudflare（https://www.cloudflarestatus.com/history?page=17）が最も詳細で透明で、pageで数年分まで遡って閲覧できる。

パブリッククラウドの「死」

若い頃、私は他人のコードを読んでリファクタリングするのが好きだった。Java Boyに教えられるまで：彼のメモリリークを直したのに、彼が感じたのは深い実存的不安だった。彼は怒りで自分の無能を隠し、「Kubernetesプラットフォームの安定維持」の責任を私に押し付けた。

私も彼の尻拭いを喜んでやっていたわけではない。ただ、頻発するOOM killイベントアラートが煩わしかっただけだ。その話から、ゼロの哲学を悟った：限界便益がゼロのリファクタリングは誰もやりたがらない。

ゆえにソフトウェア業界のエントロピー増大の法則が導かれる：プロジェクトのコードベースは時間とともにスパゲッティ化する。

「これがパブリッククラウドの死と何の関係がある？」と聞く人がいた。

実は大いに関係がある。「工業的クトゥルフ」は企業に時間とともに増える利益を要求する。だからパブリッククラウドベンダーとその現場社員は「新しい成長物語」を語らなければならない——2026年なら、その物語はAIだ。

古いコードはそのまま腐る。変更しても限界便益はない。

やがて誰もが同じ合意に至る：他人のコードには触れず、スパゲッティ化に任せる。コードもアーキテクチャも同じ。ネットワークトポロジーが純粋な相互依存の網の目になっても、障害時はみんな使えず、ダウン責任が平等に分散すれば、自分に責任はない。

皮肉なことに、在職中に障害ゼロで毎日「仕事中に寝ている」ように見える運用エンジニアは、無能だと見なされる。何もしていないように見えるから。しかし直感に反して、その人は企業のマスコットとして祀るべきだ。彼が以前どれだけ業務安定のために努力したか、あるいは単に運が良かっただけなのか、誰にもわからない。大廟に配享するに値する。

究極の運用は、運用しないことである。運用の報酬とキャリアリスクは完全に不均衡だからだ。上司は「使っていなさそうな設定」を消しても今月の手当を増やしてくれない。だが「使っているデータベース設定」を消せば、顧客に罵倒される。

パブリッククラウド企業は忘れている。ネットワーク効果は彼らを押し上げることも、叩き落とすこともできる。顧客が増えれば、単一のダウンによるネットワークの連鎖反応は大きくなる。2025年12月4日夜21:00–23:37頃の支付宝障害のように——これは阿里系2025年の第六の重大障害だった。

ユーザー規模が億単位になると、一秒ごとに誰かが支払っている。それでも業務はソフトに新機能を追加し続けを求め、やがてシステムは耐えられなくなる。

しかもパブリッククラウドの賠償は完全に不均衡だ。支付宝のようなケースではせいぜい「多退少補」、少なく徴収した分を福利として返す程度。だが政府・企業の損失は到底算定できない。業務がパブリッククラウドに載っていて、クラウドがダウンしたら、業務側はクラウドにどう自分の損失を説明するのか？

「うちのシステムは一日数百億取引している。数億賠償してくれる？」

顧客の損失は定量化できない。だからアリババクラウドは通常、バウチャーを少し渡すだけだ。それは焼け石に水。失われた時間、実際の業務影響、その時間価値を誰もはっきり言えない。

ネットワーク効果はパブリッククラウドに指数関数的な収益成長をもたらした。しかし大型の政府・企業ユーザーにとっては、パブリッククラウドへの反依存を日程に載せるべきだ。自らの運命を単一のクラウドベンダーに縛れば、突発リスクには対応できない。

小並行・高可用システム

その上で、私は「小並行・高可用システム」を提案する。ストレージの冗長により、業務の高可用性を実現する。

トラフィックが冗長な情報システムに平準に分散されれば、集中型トラフィックによる単一クラスタのトラフィックピークを避け、問題の拡散半径を縮小できる。

最も単純な例。DNS解決の際、広東のDNSを華南地域のアリババ・テンセントKubernetesクラスタに向ける。各クラスタは互いに依存せず、内部で完全な情報業務システムを稼働させる。最悪の場合、パブリッククラウド自体に問題が起きても、不可用は50%までに抑えられる。

両方同時に不可用になる確率は極めて小さい。

Farewell, Public Cloud. See you on the Yangtze River.

参考リンク

【1】
2025年11月18日 Cloudflare サービス中断
https://blog.cloudflare.com/zh-cn/18-november-2025-outage/

【2】
AWS障害から見るDNSの見えざる杀伤力：DeepFlowが混乱の中でいかに素早く根因を特定したか
https://my.oschina.net/u/3681970/blog/18697034

【3】
2023-11-12 アリババクラウド障害の振り返りと分析
https://github.tiankonguse.com/blog/2023/11/29/aliyun-break.html

Резюме

Статья исходит из формальной логики и определений (сетевой эффект, закон возрастания энтропии, антизависимость, философия «нуля» нулевой предельной выгоды), систематически обозревает крупные сбои основных публичных облаков и инфраструктуры — Alibaba Cloud, Google Cloud, Azure, Cloudflare, Tencent Cloud — с 2014 по 2025 год и сравнивает прозрачность их отчётности по сбоям. На этой основе анализируются «причины смерти» публичного облака: энтропия ПО и нулевая предельная выгода затрудняют управление устаревшим кодом и архитектурой; сетевые эффекты усиливают каскадные сбои; компенсации по SLA серьёзно не соответствуют реальным потерям предприятий и госсектора. Автор рекомендует крупным предприятиям и госорганам приоритизировать «антизависимость» от одного публичного облака и предлагает концепцию «высокодоступной системы с малой параллельной нагрузкой» — снижение риска единой точки отказа и радиуса поражения за счёт избыточности хранения и распределения трафика (например, мультирегиональное, мультикластерное DNS-разрешение).

Формальная логика и определения

Сетевой эффект: чем больше пользователей (или участников) у продукта/сервиса/платформы, тем выше его ценность для каждого пользователя.

Закон возрастания энтропии: кодовую базу проекта со временем ожидает превращение в «свалку».

Антизависимость: обратная зависимость от одного языка программирования, стека или облачной платформы. Примеры: полиглот-программирование, мультистек, мультиоблако. Антизависимость позволяет бизнесу стабильно работать без привязки к одному языку, открытому проекту или публичному облаку.

Ноль: рефакторинг с нулевой предельной выгодой никому не нужен.

Сбои AWS

Время	Регион / Область	Длительность	Основное воздействие и последствия	Официальная / основная причина	Примечания / Оценка отрасли
2014-06-13	us-east-1 (Северная Вирджиния)	Не указано	Затронуты ключевые компоненты Amazon SimpleDB, часть пользователей не могла работать с БД.	Проблема с питанием.	Небольшое событие; быстро восстановлено; показало слабость резервирования питания.
2014-08-07	EU West (Ирландия)	Не указано	Затронуты EC2, EBS, RDS; европейские клиенты потеряли доступ к инстансам и хранилищам.	Внутреннее системное событие.	Региональное; выявило слабую изоляцию регионов на раннем этапе.
2014-11-26	Глобально (CloudFront DNS)	~2 часа	Сбой DNS-серверов CloudFront; многие сайты и сервисы не могли разрешать запросы.	Сбой DNS-серверов.	Короткий, но широкий эффект; показал уязвимость DNS крупнейшего облака.
2015-09-20	us-east-1	Несколько часов	Сбой DynamoDB → сбой внутренних коммуникаций; пострадали Netflix, Reddit, IMDb, Amazon.	Цепная реакция внутренних сервисов.	Серьёзный инцидент; миллионы пользователей; предупреждение о сильной связанности сервисов.
2017-02-28	us-east-1	4–5 часов	Поломка контрольной плоскости S3; Slack, Trello, GitHub Pages, Quora и многие сайты без файлов.	Ошибка инженера — удалена критическая конфигурация.	Одна из самых известных аварий; «самая дорогая опечатка в истории».
2020-11-25	us-east-1	Несколько часов	Сбой Kinesis и Cognito; пострадали Roku, Adobe, Flickr; стриминг и аутентификация.	Проблема с обновлением ёмкости.	Произошло во время пандемии; подчеркнуло сложности планирования мощностей.
2022-12-05	us-east-2 (Огайо)	~40 минут	Сбой зоны доступности; нарушена работа ряда сервисов в регионе.	Не раскрыто подробно (вероятно сеть/питание).	Короткий, но показал важность multi-AZ архитектуры.
2023-06-13	us-east-1	Не указано	Сбой Lambda; пострадали Boston Globe, метро Нью-Йорка, Associated Press и др.	Не раскрыто подробно.	Показал уязвимость бессерверных вычислений при масштабе.
2024-07-30	us-east-1	Не указано	Сбой Kinesis Data Streams; нарушена обработка данных в реальном времени.	Не раскрыто подробно.	Подчеркнул риски зависимостей потоковой обработки.
2025-02	eu-north-1 (Стокгольм)	Не указано	Крупный сетевой сбой в одной зоне; нарушены ключевые сервисы в Европе.	Серьёзный сетевой сбой.	Региональное; отразило сложности расширения инфраструктуры в Европе.
2025-10-19/20	us-east-1	>15 часов	Сбой точки входа DynamoDB (DNS); пострадали Slack, Reddit, Roblox, Fortnite, Coinbase, Venmo, Duolingo, Canva, PlayStation, банки, авиакомпании (задержки Delta/United), Amazon; >3500 компаний, 60+ стран, >17 млн жалоб.	Сбой разрешения DNS → каскадный эффект.	Крупнейший сбой облака 2025 года; «самое большое обнажение уязвимости облака»; активно продвигают multi-cloud.

Анализ самых серьёзных инцидентов
Наиболее тяжёлые сбои: 2015 (DynamoDB), 2017 (S3) и особенно 2025-10 (DynamoDB DNS). Все произошли в us-east-1 — самом старом и загруженном регионе AWS.
Рейтинг тяжести:

2015 — сильно пострадали развлекательные и социальные платформы.
2017 — огромный ущерб продуктивности и разработчикам; рекордные убытки из-за человеческого фактора.
2025 — самая длительная (>15 ч), самая широкая (финансы, игры, образование, авиация, критическая инфраструктура) — считается самым серьёзным одиночным облачным сбоем последних лет.
Главные уроки: чрезмерная зависимость от us-east-1, хрупкость контрольной плоскости, каскадные сбои. Отрасль всё активнее рекомендует многорегиональные, мультиоблачные и гибридные архитектуры.

Сбои Alibaba Cloud

С 2014 по 2025 год у Alibaba Cloud не было аномально большого числа крупных инцидентов, широко освещённых и официально раскрытых, действительно широких по охвату, длительных и называемых «крупными авариями» (по масштабу компании общий SLA по-прежнему на уровне лидеров отрасли). Однако несколько из них действительно вызвали заметные общественные последствия и отраслевую дискуссию. Ниже — хронологический список крупных сбоев (по открытым отчётам, официальным заявлениям, СМИ и разборам сообщества):

Время	Регион/охват	Длительность	Основное влияние и последствия	Официальная/основная причина	Заметки/оценка отрасли
Июнь 2018	Часть регионов (детали не раскрыты)	~30 мин	Сбои части облачных продуктов, ограниченное влияние	Подробно не раскрыто	Часть СМИ назвала «крупным техническим сбоем»
3 марта 2019	Северный Китай 2 (Пекин) AZ-C	Часы	Массовые сбои дисков ECS, падение множества сайтов/приложений	Сбой дисков	Существенное влияние; Alibaba Cloud компенсировала по SLA
18 декабря 2022	Регион Гонконг AZ-C	~15,5 ч	Почти полная остановка Гонконга; недоступность ключевых сайтов Макао (денежно-кредитное управление, Galaxy, Lotus TV и др.); затронут OKX	Отказ охлаждения → каскад → массовый простой	Широко названо «одним из худших инцидентов в истории Alibaba Cloud»
12 ноября 2023	Все регионы и сервисы глобально	~3 ч 16 мин	Консоль, API, MQ, микросервисы, мониторинг, ML и др. в сбое; Taobao, DingTalk, Xianyu, Ele.me, Alibaba Cloud Drive и др. упали	Сбой ядра (аутентификация/метаданные/контрольная плоскость)	Широко признано худшим и самым широким сбоем Alibaba Cloud; «эпический», «беспрецедентный в отрасли»
27 ноября 2023	Часть серверов	~2 ч	Сбой доступа к серверам	Подробно не раскрыто	Всего через полмесяца после 11·12; новые вопросы к доверию
2 июля 2024	Часть регионов/сервисов	Часы	Сбои консоли и части сервисов	Детального разбора нет	Средний масштаб; влияние меньше предыдущих
2025 (дата неясна)	Глобально (подозрение на DNS)	~6 ч	Подмена DNS привела к глобальным сбоям сервисов	Подмена DNS	По сводке сбоев публичного облака 2025; детали уточняются

Важные замечания и тренды

2014–2018, ранний период: Публично раскрытых крупных P0-инцидентов в этот период крайне мало; в основном локальные, ограниченные случаи. Масштаб был намного меньше, влияние — тоже.
Два самых тяжёлых:
- 2022.12 Гонконг 15,5 ч → Самый длительный сбой в одном регионе; тяжёлое влияние на критическую инфраструктуру Гонконга и Макао.
- 2023.11.12 глобально 3+ ч → Остановка контрольной плоскости и глобальных сервисов; широко признано редким сбоем «все регионы × все сервисы», развенчавшим миф о «мультиактивности, мультицентре, N девяток».
2024–2025: По известным данным частота и тяжесть ниже, чем в 2022–2023, но средние и крупные события по-прежнему случаются (например, подмена DNS в 2025 году имела широкий охват).
Подход Alibaba Cloud: После большинства крупных сбоев публикуются детальные разборы (особенно по Гонконгу 2022 и глобальному 2023); компенсация по SLA (обычно ваучеры); официальные извинения руководства.

В целом за 2014–2025 у Alibaba Cloud порядка 5–7 инцидентов уровня «крупная авария», при этом 12 ноября 2023 и декабрь 2022 Гонконг общепризнанно считаются двумя самыми тяжёлыми.

Сбои Google Cloud

Google Cloud Platform (GCP) с 2014 по 2025 год имел в целом хороший SLA; крупные инциденты, реально затронувшие глобальный охват или несколько ключевых сервисов, не были особенно частыми (меньше глобальных катастроф, чем у AWS и Azure). Когда они происходили, часто страдали многие сторонние приложения (Snapchat, Spotify, Discord, сервисы, зависящие от Cloudflare и т.д.) с высоким общественным резонансом.

Ниже — хронологический список серьёзных, широких по охвату сбоев GCP (по открытому Status Dashboard, СМИ, Wikipedia, отраслевым разборам):

Время	Регион/охват	Длительность	Основное влияние и последствия	Основная причина	Заметки/оценка отрасли
Август 2015	Европа (Глин, Бельгия)	Часы	Очень высокая доля ошибок чтения/записи Compute Engine; частичная потеря данных	Молния повредила часть ЦОД	Google редко признаёт потерю данных; ограниченный круг заказчиков
Июль 2018	Глобально (несколько регионов)	Часы	Сбои сервисов GCP; Snapchat, Spotify и др. в основном недоступны	Перегрузка сети + внутренняя маршрутизация	Широко освещено; сильное влияние на третьи стороны
2 июня 2019	Восток США + глобально	~4–5 ч	Массовые сбои YouTube, Gmail, G Suite; сбои входа Snapchat, Discord, Vimeo	Перегрузка сети на востоке США + каскад	Широкий охват; активное обсуждение в соцсетях
14 декабря 2020	Глобально	~1 ч	Gmail, YouTube, Google Home, Nest, Pokémon GO и др. — почти все сервисы, зависящие от аутентификации, упали	Глобальный сбой системы идентификации (аналог IAM)	«Падение» потребительских сервисов; один из худших
Август 2022	ЦОД в Айове	Локально	Электрический пожар (3 пострадавших); затронуты часть сервисов, не глобально	Электрический пожар в ЦОД	Физический объект; не чисто софт/архитектура
Апрель 2023	Европа (Париж и др.)	Часы	Сбои сети и сервисов в нескольких регионах	Наводнение + ЦОД + сетевые проблемы	Погодный фактор; среднее влияние
23 октября 2024	Европа (Франкфурт europe-west3)	~12+ ч	Регион в основном недоступен; затронуты многие европейские заказчики	Подробно не раскрыто (подозрение на контрольную плоскость/сеть)	Один из самых длительных сбоев в одном регионе
12 июня 2025	Глобально (40+ регионов)	~2,5–3 ч	Сбои 70+ сервисов GCP; падение IAM → сбои API-запросов; Spotify, Discord, Twitch, Cloudflare, Fitbit, Gmail, Drive, YouTube и др. упали	Service Control (ядро API-аутентификации): автоматическое обновление внесло тяжёлый баг → цикл сбоев → глобальная перегрузка	Широко признано худшим глобальным сбоем GCP с 2020 года
18 июля 2025	us-east1	~2 ч	Повышенная доля ошибок у нескольких продуктов	Подробно не раскрыто	Средний масштаб; восстановление относительно быстрое

Сбои Azure

У Microsoft Azure с 2014 по 2025 год не было аномально большого числа крупных инцидентов, широких по охвату, длительных и привлекающих внимание (по сравнению с ранним периодом частых мелких сбоев при меньшем масштабе ситуация улучшилась). Несколько событий действительно привели к глобальному или мультисервисному влиянию, особенно когда были затронуты Microsoft 365, Teams, Xbox, Outlook и другие потребительские/корпоративные продукты; эффект распространения был очень заметен.

Ниже — хронологический список крупных сбоев Azure (по Azure Status History, Post Incident Reviews, СМИ, Wikipedia, отраслевым разборам):

Время	Регион/охват	Длительность	Основное влияние и последствия	Основная причина	Заметки/оценка отрасли
14–18 августа 2014	US Central, US East, US East 2, Europe North	Несколько дней, часы за событие	Cloud Services, SQL Database, VM, Websites, HDInsight, Mobile Services, Service Bus в основном недоступны	Несколько сетевых/хранилищных проблем	Самая концентрированная волна 2014 года; Azure ещё молодой
18–19 ноября 2014	Несколько регионов (США, ЕС, Азия)	~11 ч	В центре Azure Storage; VM, Websites, Visual Studio Online, Xbox Live, MSN, Search, 20+ сервисов упали	Изменение конфигурации производительности хранилища → бесконечный цикл фронта Blob	Худший ранний инцидент Azure; детальный RCA; компенсация заказчикам
15 сентября 2016	Глобально	Часы	Массовый сбой разрешения DNS; затронуты многие сервисы, зависящие от Azure DNS	Глобальная проблема DNS	Обнажён риск единой точки отказа DNS
20 июня 2018	Несколько ЦОД в Северной Америке	Часы–1+ день	Сбой охлаждения (молния + защита от перенапряжения) → сбои нескольких сервисов	Физический объект (каскад от молнии)	Редкий инцидент уровня железа/инфраструктуры
4 сентября 2018	Несколько регионов	25+ ч (часть сервисов 3 дня)	Ключевые сервисы длительно недоступны	Охлаждение (молния + перенапряжение)	Одно из самых длительных восстановлений
23 января 2023	Глобально (ядро сети)	~3 ч	Microsoft 365 (Teams, Outlook, Exchange), часть сервисов Azure упали	Проблема WAN	«Падение» M365; огромное влияние
18 июля 2024	US Central	~Полдня	Сбои операций управления VM и др.; заказчики не могли получить доступ к управляемым сервисам	Ошибка контроля доступа + сбой инфраструктуры	Близко по времени к глобальному BSOD CrowdStrike на следующий день, но независимо
8–9 января 2025	East US 2 и др.	Часы	Сбои сети Azure Databricks, Synapse, Functions, App Service, VM	Проблема сетевого компонента	Заметный инцидент начала 2025 года
29 октября 2025	Глобально	~8 ч	В центре Azure Front Door; Microsoft 365, Outlook, Teams, Xbox Live, Minecraft, Copilot упали; затронуты Alaska Airlines, Heathrow, Costco, Starbucks и др.	Изменение конфигурации Azure Front Door + баг защиты → несовместимая конфигурация распространилась глобально	Худший инцидент Azure в 2025 году; Downdetector 30k+ отчётов; похоже на сбой AWS в том же месяце
5–6 ноября 2025	West Europe (AZ01)	~9–10 ч	Деградация/остановка VM, PostgreSQL/MySQL Flexible Server, AKS, Storage, Service Bus	Тепловой инцидент в ЦОД	Серьёзный региональный сбой

Наблюдения и тренды (2014–2025)

2014: Azure в фазе быстрого роста; частые проблемы изменений конфигурации и слоя хранилища; самый концентрированный по сбоям год (ноябрьский инцидент — классический кейс).
2015–2019: Частота сбоев снизилась; по-прежнему в основном один регион или инфраструктура (охлаждение, молния, DNS); влияние относительно ограничено.
2020–2023: Крупных глобальных сбоев мало; чаще сеть или зависимость M365 от Azure (напр., январь 2023).
2024–2025: Контрольная плоскость/край (напр. Azure Front Door) стал новой болевой точкой; 29 октября 2025 широко признано худшей глобальной остановкой Azure за последние годы, сопоставимой с Alibaba ноябрь 2023 или GCP июнь 2025.
Типичные черты: Детальный Post Incident Review (PIR) после крупных инцидентов; изменение конфигурации, контрольная плоскость, сеть часто в корне (не только железо); сильное распространение на третьи стороны при сбоях M365, Xbox, Teams; компенсация по SLA (кредит); заказчики больше всего заботятся о непрерывности бизнеса.

В целом у Azure за 2014–2025 порядка 8–10 крупных (глобальных/мультисервисных, длительных) сбоев; тяжесть и частота на одном уровне с AWS и GCP; каскадный сбой из-за ошибки конфигурации — повторяющийся сценарий.

Сбои Cloudflare

Cloudflare как один из крупнейших в мире CDN, безопасности, DNS и edge-провайдеров с 2014 по 2025 год не имел аномально большого числа крупных инцидентов, вызвавших широкий сбой интернета. Когда они происходили, влияние достигало миллионов и сотен миллионов пользователей (Cloudflare обрабатывает ~20–25% мирового веб-трафика).

Типичная картина: восстановление часто быстрое (большинство ослабевает за 1–4 ч), но распространение крайне сильное — при сбое ядра прокси, DNS или компонентов безопасности многие топовые сайты (X, ChatGPT, Shopify, Discord, Spotify, части AWS и т.д.) одновременно получают 5xx или становятся недоступны.

Ниже — хронологический список крупных сбоев Cloudflare (по официальному блогу, истории status.cloudflare.com, СМИ, Wikipedia; фокус на глобальных/ядровых трафиковых событиях):

Время	Охват	Длительность	Основное влияние и последствия	Основная причина	Заметки/оценка отрасли
2 июля 2019	Глобально	~1–2 ч	Массовые 502/503/504 на сайтах; большие части интернета недоступны	Внедрение софта внесло тяжёлый баг → падение слоя прокси	Широко признано худшим за всю историю Cloudflare; детальный разбор
2020, несколько раз	Часть регионов/контрольная плоскость	Часы	Недоступны дашборд, аналитика, часть API; ядро прокси в основном стабильно	Проблемы контрольной плоскости	Больше влияния на разработчиков; обычные пользователи меньше замечают
Июнь 2022	Несколько ЦОД (19)	~1,5 ч	Остановка ядра прокси; множество сайтов недоступны	Ошибка конфигурации сети	Средний масштаб; быстрое восстановление
21 марта 2025	Глобально	~1 ч 7 мин	Сильные сбои чтения/записи хранилища; затронуты многие сервисы, зависящие от хранилища/кэша	Сбой записи слоя KV/хранилища + частичные проблемы чтения	Заметный инцидент начала 2025 года
12 июня 2025	Глобально (часть функций)	Часы	Часть функций/сервисов недоступна; ядро трафика в основном в порядке	Внедрение определённого модуля	Не остановка ядра трафика; ограниченное влияние
14 июля 2025	Глобально (DNS 1.1.1.1)	~62 мин	Публичный DNS-резолвер (1.1.1.1) полностью недоступен; многие пользователи не могли выйти в интернет	Ошибка конфигурации → отзыв BGP-маршрута → префикс DNS исчез из глобальной таблицы маршрутизации	Очень тяжело для пользователей 1.1.1.1; уровень «обрушения интернета»
~Октябрь 2025	Часть сервисов	Десятки минут	Краткий сбой разрешения DNS	Проблема конфигурации DNS	Средний масштаб
18 ноября 2025	Глобально	~4–5 ч (пик дольше)	Крупная остановка интернета: X (Twitter), ChatGPT, Shopify, Spotify, Letterboxd, Indeed, Canva, Uber, DoorDash, Truth Social, League of Legends и др.; ~20% веб-трафика; 1/3 сайтов из топ-10k Alexa	Аномальный рост файла правил Bot Management (изменение прав БД → удвоение размера файла) → глобальное распространение → падение прокси	Худший в 2025 году; также худшая глобальная остановка трафика с 2019 года
5 декабря 2025	Глобально	Часы	Снова массовые 5xx; затронуты Shopify, Zoom, Vinted, Fortnite, Square, Just Eat, Canva, Vimeo, части AWS, Deliveroo и др.	Полной официальной первопричины нет (подозрение на конфигурацию/распространение)	Всего через 17 дней после 18 ноября; два крупных инцидента подряд вызвали сильную критику

Наблюдения и тренды (2014–2025)

2014–2018: Cloudflare быстро рос; публичных крупных глобальных инцидентов мало; в основном локальные/региональные/функциональные проблемы; зависимость интернета от Cloudflare была ниже, чем сейчас.
Июль 2019: Стал классическим «чёрным лебедем» Cloudflare; более шести лет не было глобальной остановки ядра прокси сопоставимого масштаба.
2025 как аномальный год: Не менее 3–4 широких глобальных/почти глобальных событий (особенно 18 ноября и 5 декабря подряд). 18 ноября широко признано худшим с 2019 года. 5 декабря снова заставило многих усомниться в контроле изменений, откате и принципе «fail small».
Типичные черты: Большинство тяжёлых инцидентов связаны с изменением конфигурации, правилами/распространением, контрольной плоскостью или DNS/BGP; очень прозрачные разборы на blog.cloudflare.com; восстановление обычно быстрое (откат + остановка распространения), но влияние очень широкое (Anycast + механизм вызова); нет явной компенсации по SLA как у AWS/Azure/Google, но есть детальные объяснения и обязательства по улучшениям.

В целом у Cloudflare за 2014–2025 порядка 5–7 крупных (глобальная ядровая трафиковая, длительная) сбоев; июль 2019 и 18 ноября 2025 — два пиковых события. В 2025 году частота сбоев заметно выросла, возобновилось обсуждение «риска концентрации интернет-инфраструктуры».

Сбои Tencent Cloud

Tencent Cloud с 2014 по 2025 год как второй по размеру публичный облачный провайдер Китая (после Alibaba Cloud) имел в целом хорошую стабильность среди местных провайдеров. Действительно широких, длительных, привлекающих внимание глобальных/мультирегиональных крупных инцидентов было относительно немного; при сбое контрольной плоскости (консоль/API) или ключевого хранилища влияние быстро распространялось на множество предприятий и разработчиков.

Страница статуса Tencent Cloud (https://status.cloud.tencent.com/history) относительно непрозрачна: история часто показывает только последний год, многие средние и крупные инциденты отсутствуют; полная картина складывается из официального WeChat, техблога, СМИ и сообщества.

Ниже — хронологический список серьёзных, широких по охвату инцидентов Tencent Cloud (по официальным разборам, СМИ, Zhihu/Weibo/сообществу разработчиков):

Время	Регион/охват	Длительность	Основное влияние и последствия	Основная причина	Заметки/оценка отрасли
2 ноября 2014	По стране (контрольная плоскость + часть сервисов)	~6 мин	Медленный сайт Tencent Cloud, сбой загрузки изображений, сбой консоли; часть пользователей не могла нормально пользоваться	Подробно не раскрыто (подозрение на сеть/нагрузку)	Ранний период малого масштаба; влияние ограничено, но тогда широко освещено
Август 2018	Часть пользователей/облачный диск	Неясно (влияние на одного пользователя часы до постоянного)	Обнуление/потеря данных облачного диска у нескольких пользователей; убытки порядка десятков миллионов	Тихий сбой диска + сбой проверки/реплики при миграции	Худший инцидент «потери данных» в истории Tencent Cloud; кризис доверия; детальный разбор
2023 (отдельные сообщения)	Часть регионов/сервисов	Десятки мин–часы	Отдельные сбои консоли/API, джиттер хранилища	Детального публичного разбора нет	По сравнению с глобальным сбоем Alibaba в ноябре 2023 Tencent был относительно стабилен
8 апреля 2024	17 регионов глобально	~74–87 мин	Консоль полностью недоступна; облачный API 504 Gateway Timeout; инстансы CVM/RDS работают, но управление/продление/масштабирование невозможно; 1957 обращений заказчиков	Обратная несовместимость новой версии API + отсутствие механизма поэтапного раскрытия конфигурации → полный выкат → глобальное распространение	Самый тяжёлый за последние годы у Tencent Cloud; широко названо «глобальной аварией», «обрушением контрольной плоскости»; стиль похож на Alibaba ноябрь 2023
15 октября 2025	Несколько регионов	~Десятки мин–1 ч	Сбои Auto Scaling и других сервисов	Подробно не раскрыто	Со страницы статуса; средний масштаб
17 октября 2025	Гуанчжоу	~1+ ч	Сбои сервисов, связанных с AI digital-human	Подробно не раскрыто	Региональный; конкретный продукт AI/цифровой человек

Наблюдения и тренды (2014–2025)

Ранний период (2014–2018): Сбои часто потеря данных хранилища или краткие проблемы доступа; инцидент «потери данных» 2018 года сильнее всего ударил по доверию предприятий.
2019–2023: Частота и тяжесть сбоев Tencent Cloud снизились; общенациональных/глобальных событий мало; стабильность выше, чем у Alibaba в тот же период (напр., спокойно во время 11·12 у Alibaba).
2024–2025: 8 апреля 2024 стало переломным; глобальный сбой контрольной плоскости заставил многих переоценить «безопасность изменений» и «поэтапный выкат». В 2025 было несколько средних инцидентов, но ничего уровня «полная остановка сервисов» как в апреле 2024 или у Alibaba/Google.
Типичные черты: Контрольная плоскость/API — главная болевая точка (апрель 2024); хранилище/потеря данных наиболее разрушительны для предприятий (2018); разборы относительно своевременны (WeChat, техсообщество); нет строгой компенсации по SLA как у AWS/Azure/Google, но есть ваучеры/компенсация; распространение сбоя менее драматично, чем у Alibaba/Cloudflare (клиентская база более корпоративная/игры/видео, меньше зависимость от потребительского интернета).

В целом у Tencent Cloud за 2014–2025 порядка 3–5 крупных (общенациональная/глобальная контрольная плоскость длительно недоступна или серьёзная потеря данных) инцидентов; потеря данных 2018 и глобальный сбой контрольной плоскости 8 апреля 2024 — два самых обсуждаемых.

Прозрачность по сбоям

С точки зрения прозрачности по сбоям Alibaba Cloud и Tencent Cloud относительно слабы.

Доска статуса Alibaba Cloud (https://status.aliyun.com/#/?region=cn-shanghai) и Tencent Cloud (https://status.cloud.tencent.com/history) показывают только события за последний год.

Azure (https://azure.status.microsoft/en-us/status/history/) хранит пять лет. Cloudflare (https://www.cloudflarestatus.com/history?page=17) наиболее прозрачен; можно листать страницы назад на несколько лет.

«Смерть» публичного облака

В молодости я любил читать и рефакторить чужой код. Пока «Java Boy» не преподал урок: даже после того, как я починил утечку памяти, он почувствовал глубокий экзистенциальный кризис. Гневом он прикрывал собственную несостоятельность и возлагал вину за «поддержание стабильности платформы Kubernetes» на меня.

Я и сам не горел желанием за ним убирать. Просто частые алерты OOM kill меня раздражали. Из той истории я вынес философию нуля: рефакторинг с нулевой предельной выгодой никому не нужен.

Отсюда закон возрастания энтропии в софте: кодовую базу проекта со временем ожидает превращение в «свалку».

Кто-то спросил: какое это имеет отношение к «смерти» публичного облака?

Прямое. Потому что «индустриальный Ктулху» требует от компаний растущей прибыли. Поэтому для провайдеров публичного облака и их рядовых сотрудников необходимо «рассказывать новую историю роста» — в 2026 году эта история про AI.

Старый код просто гниёт. Менять его — нулевая предельная выгода.

И все сходятся в одном: не трогать чужой код, дать ему превратиться в свалку. И с кодом так, и с архитектурой. Даже когда сетевая топология — чистая сеть взаимных зависимостей, при сбое все одинаково без сервиса, и когда ответственность за простой распределена поровну, на тебе лично ответственности нет.

Ирония в том, что инженера по эксплуатации с нулём инцидентов за время работы, который «каждый день спит на работе», сочтут некомпетентным — потому что выглядит, будто он ничего не делает. Контринтуитивно: такого человека стоило бы держать как талисман компании — неизвестно, сколько он сделал раньше ради стабильности. Или ему просто повезло, и он заслуживает алтаря.

Лучшая эксплуатация — не эксплуатировать. Потому что доход от эксплуатации и карьерный риск совершенно несоизмеримы. Начальник не доплатит за удаление «вроде бы ненужной» настройки; но за удаление нужной настройки БД тебя обругают заказчики.

Провайдеры публичного облака забывают: сетевой эффект может их поднять и может больно опустить. Чем больше у них заказчиков, тем сильнее сетевая цепная реакция от одного простоя. Как сбой Alipay 4 декабря 2025, ~21:00–23:37 — уже шестой крупный инцидент экосистемы Alibaba в 2025 году.

Когда масштаб пользователей — сотни миллионов, каждую секунду кто-то платит. А бизнес продолжает требовать новые функции; в конце концов система не выдерживает.

И компенсация провайдеров публичного облака совершенно несоизмерима. Для чего-то вроде Alipay это максимум «вернуть разницу»; недобор считают подарком. Но потери госсектора и предприятий не поддаются оценке. Если твой бизнес на публичном облаке и облако легло — как ты объяснишь провайдеру свой ущерб?

«Моя система обрабатывает миллиарды транзакций в день; вы мне компенсируете пару миллиардов?»

Ущерб заказчика не квантифицируем, поэтому Alibaba Cloud обычно просто раздаёт ваучеры. Это капля в море. Никто не может толком учесть потерянное время, реальное влияние на бизнес и ценность этого времени.

Сетевой эффект принёс публичному облаку экспоненциальный рост выручки. Для крупных государственных и корпоративных пользователей антизависимость от одного публичного облака должна быть в повестке. Связать свою судьбу с одним облачным провайдером — нельзя справиться с внезапным риском.

Системы малой параллельности и высокой доступности

На этой основе я предлагаю «системы малой параллельности и высокой доступности»: избыточность хранилища для высокой доступности бизнеса.

Когда трафик распределён по избыточным системам, ты избегаешь пика трафика одного кластера при централизованном потоке и сокращаешь радиус распространения сбоя.

Простейший пример: при разрешении DNS направлять Гуандун на кластер Kubernetes Alibaba + Tencent в Южном Китае. Каждый кластер независим и крутит полную внутреннюю бизнес-систему. В худшем случае при сбое самого публичного облака недоступность не более 50%.

Одновременная недоступность обоих крайне маловероятна.

孤帆远影碧山尽，唯见长江天际流

Прощай, облачный сервис. Увидимся на Янцзы.

Ссылки

【1】
Сбой сервисов Cloudflare 18 ноября 2025
https://blog.cloudflare.com/zh-cn/18-november-2025-outage/

【2】
Невидимое влияние DNS на примере сбоя AWS: как DeepFlow быстро нашёл первопричину в хаосе
https://my.oschina.net/u/3681970/blog/18697034

【3】
Разбор и анализ сбоя Alibaba Cloud 2023-11-12
https://github.tiankonguse.com/blog/2023/11/29/aliyun-break.html

教育行政化体系下的激励函数设计

Fri, 30 Jan 2026 00:00:00 +0000

引言

本文将以教育行政化体系作为论述的大环境背景，提取 1 教师Y，教师F，教师D 2 学生犹大，学生黑曼巴，学生P，学生Y，学生C13 3 心理老师 4 学校领导的家庭背景，性格特征，以及行为模式。把「人类决策」拆成可计算的变量 → 评分 → 概率 / 结果。并分析不同决策产生的政策风险和结果，根据不同的角色定位，研究探讨最佳策略，并尽可能地为学校领导设计一个最佳的时间激励函数。

形式逻辑和定义

教育行政化：学生对老师负责，老师受校长管理，校长对学校负责。学校政绩以学生平均成绩和本科升学率作为量化。

踢貓效應（英語：Kick the cat）：也稱為踢狗效應（kick the dog）[1]，是一種隱喻，描述在組織或是家庭中位階較高的人，可能會藉由責罰位階較低的人來轉移其挫折或不滿，而位階較低的人也會以類似的方式將挫折發泄給位階更低的人，因此產生了連鎖反應。

收益函数：教师以学生平均成绩和本科升学率作为收益函数；学生以个人高考成绩作为收益函数，学生最终的高考成绩，跟过往3年的成绩正相关。

收益函数（Payoff）定义

教师收益 (U_{\text{teacher}})：以学生平均成绩 (\bar{S}) 和本科升学率 (r) 为自变量
[U_{\text{teacher}} = w_{\text{avg}} \cdot \bar{S} + w_{\text{enroll}} \cdot r]
实现中取 (w_{\text{avg}}=0.6)，(w_{\text{enroll}}=0.4)。政绩（领导层激励）与教师收益同构。
学生高考成绩预测 (G)：与过往 3 年年末成绩正相关，近期权重更大
[G = w_1 S_{t-3} + w_2 S_{t-2} + w_3 S_{t-1},\quad w_1+w_2+w_3=1,\; w_1\le w_2\le w_3]
实现中取 (w_1=0.2,\,w_2=0.3,\,w_3=0.5)。
学生收益 (U_{\text{student}})：以个人高考成绩（预测值）为收益；未参考高考则无高考收益
[U_{\text{student}} = \begin{cases} G & \text{若在高考参考池} \ 0 & \text{否则} \end{cases}]

量化公式

公式1：学生平均成绩 = 学生总成绩 / 学生人数

公式2：本科升学率 = 本科录取人数 / 参加高考人数 × 100%

人物建模分析

教师Y：以公式1作为决策量化的依据。公式1中的学生人数可以减少（使用PUA策略，让学生休学退学）；使用罚站、电话家长、班会公开点名批评等方式减少学生人数；使用撒谎和躲避监控策略，应付上级道德和法律审查。

教师F：以公式1和公式2作为决策量化的依据。公式1中的学生人数不变，但是从本科升学率出发，参加高考的人数可以减少。

教师D：以公式1和公式2作为决策量化的依据。以学生平均成绩最大化作为目标，但不采取剔除学生策略。

学生犹大：富裕中产阶级，攀附教师F获得了群管理。通过网络暴力的形式，攻击其他学生，意图在减少学生数量。

学生黑曼巴：家里非常有钱，可以直接使用钞能力购买澳门科技大学本科学位。因此高考只是一种选项，他本人可以不参加高考。

学生P：学习能力比较差，IQ比较低，对于教师Y的PUA策略，采取回避态度，使用休学作为消极对抗策略。

学生Y：高度近视的高IQ运动员。通过运动员加分策略让自己在高考中获得加分，但获取加分需要学校领导同意。

学生C13：家里很穷，但是一个 IQ>160 的天才学生。

心理老师：教育系统中的平衡人士。负责降低学生心理压力，安抚学生负面情绪。

学校领导：负责分配学校资源（比如谁加分，哪位学生休学退学），安排心理老师定向辅导学生的领导。

以时间序列作为元编程模型，将家庭背景、IQ、EQ、PUA、法律法规道德风险等因素量化分析，并根据不同的角色，对不同的社会成员建模，模拟实验不同学生和教师采取的策略和对应后果。编程语言使用 Go，程序位于本目录（function/local/n/china/shantou/）。

时间序列元编程模型（与 function/time.md 对齐）

第一性原理：时间是第一维度。所有时序对象的时间必须为第一成员，时序函数的时间必须为第一参数。
时序对象：Factor（量化因子）、Agent（社会成员）、SimState（仿真状态）均以 Birth 或 Current 为第一成员。
时序函数：Incentive(t, ...)、ChooseStrategy(t, ...)、ApplyStrategy(t, ...) 等均以时间 t 为第一参数。
时序日志：所有事件记录为「时间 + 内容」格式（LogTS），满足时间序列日志规范。
时序可视化：激励函数采样为 (t, 政绩值) 点列，时间作为 x 轴可绘制政绩随时间演化。

量化因子定义

因子	符号/字段	取值范围	含义
家庭背景	FamilyBackground	[0,1]	0=极贫，1=极富；影响资源与升学路径（如钞能力、运动员投入）
智力	IQ	[0,1]	映射智力分数，影响学业表现与策略理解
情绪智力	EQ	[0,1]	影响抗压与踢猫链中的情绪传播
PUA 暴露	PUAExposure	[0,1]	教师 PUA 策略对该个体的暴露强度
PUA 抵抗力	PUAResistance	[0,1]	个体对 PUA 的抵抗力
法律法规道德风险	LegalMoralRisk	[0,1]	个体/行为触发的法规与道德追责风险

净 PUA 压力可定义为：PUAExposure × (1 - PUAResistance)，用于驱动休学/回避等策略。

角色与策略建模

角色	激励依据	可选策略	策略选择逻辑（简述）
教师Y	公式1（平均分）	PUA减员、撒谎躲避、正常教学	平均分低且人数多→PUA；法规风险高→撒谎躲避
教师F	公式1+公式2	减少高考参考人数、撒谎躲避、正常教学	参考人数多且升学率低→减参考人数
教师D	公式1+公式2	撒谎躲避、正常教学（不采取剔除学生策略）	法规风险高→撒谎躲避；否则正常教学，不以PUA/减参考人数提高政绩
学生犹大	攀附教师F	网络暴力、努力学习	人数多且自身法规风险低→网络暴力
学生黑曼巴	钞能力	无（不参与高考）	—
学生P	低IQ、高PUA暴露	休学退学、回避对抗	净PUA高且压力大→休学
学生Y	运动员加分	运动员加分	稳定选择加分策略
学生C13	高IQ贫困	努力学习	稳定选择努力学习
心理老师	系统平衡	减压安抚	平均压力高→减压
学校领导	政绩=激励函数	向下施压、设计激励函数	政绩低→向下施压（踢猫）；政绩高→设计激励

策略与后果量化

策略	后果（增量/布尔）	作用对象
PUA施压减员	ΔStress↑, LegalRisk↑	随机目标学生
减少高考参考人数	LeaveExam, LegalRisk↑	随机目标学生
撒谎躲避监控	LegalRisk↓（短期）	行为者
休学退学	Dropout, LeaveExam	行为者本人
网络暴力	ΔStress↑, LegalRisk↑	随机目标学生
运动员加分/努力学习/回避对抗	ΔScore, ΔStress	行为者本人
减压安抚	ΔStress↓	随机目标学生
向下施压	ΔStress↑	随机目标学生

时间激励函数

政绩（领导层感知的激励值）与教师收益同构，定义为时间 t 的激励函数：

Incentive(t) = TeacherPayoff(平均成绩, 本科升学率) = 0.6 × 平均成绩 + 0.4 × 本科升学率

其中平均成绩与本科升学率由当前在校学生、参考人数、达线人数在 t 时刻的状态计算得到。仿真中每步对 Incentive(t) 采样，得到时间序列点列，可用于绘制「时间–政绩」曲线（时间轴为 x 轴）。学生高考成绩预测在每年末用当前成绩更新 ScoreHistory（过往 3 年），用于 GaokaoScore 与 StudentPayoff。

纳什均衡与各方最佳策略

在以上收益函数与策略空间下，可得到如下均衡与推荐策略（仿真与理论一致）：

角色	收益/目标	纳什均衡下的策略	最佳策略建议
教师	(U_{\text{teacher}}=\bar{S}) 与升学率	平均分低且人数多时倾向 PUA/减参考人数（背叛）；法规风险高或上期已背叛则正常教学（合作）	在重复博弈中：多数时期正常教学以维持声誉；仅在平均分明显偏低且学生数多时考虑减员，并注意法规道德风险
学生	(U_{\text{student}}=G)（与 3 年成绩正相关）	高 IQ、低 PUA 暴露：努力学习；高 PUA 暴露且压力大：休学或回避	以最大化 3 年成绩为主：优先「努力学习」；高压力或高 PUA 暴露时「回避对抗」或必要时休学以保护长期收益
心理老师	系统稳定（降低总压力）	平均压力高于阈值时减压安抚，否则不行动	当 `AvgStress > 阈值` 时采取减压安抚，其余时期不行动
学校领导	政绩 = (U_{\text{teacher}})	政绩低于阈值时向下施压（踢猫），否则设计激励	政绩低时向下施压；政绩高时设计激励、批准加分等资源分配

纳什均衡要点：教师与学生存在重复博弈关系。教师若长期背叛（PUA/减参考人数），会触发学生报复（如网络暴力）或回避/休学，从而损害平均成绩与升学率，最终降低教师自身收益。在均衡下，教师多数时候选择正常教学，学生在无极端压力下选择努力学习，使双方在长期内都更接近各自收益最大化。心理老师与领导的行为由聚合指标（平均压力、政绩）驱动，其最佳策略为上述阈值反应。

仿真实验设计

步长：按日（或可配置）推进。
每步：先根据当前状态更新聚合指标（学生数、参考数、升学率、平均压力等），再对每个在册成员按角色调用 ChooseStrategy(t, agent, ctx)，得到策略后调用 ApplyStrategy(t, strategy, ...) 得到后果，将后果施加于行为者或目标学生，并追加「时间+内容」日志。
输出：① 时间序列日志（每一条为「时间+内容」）；② 激励函数采样序列（时间→政绩）；③ 终态统计（在校人数、参考人数、本科录取数、平均成绩、本科升学率、政绩）。

实现文件

源代码位置：zeusro/system — function/local/n/china/shantou/y

文件	内容
model.go	时间序列对象：Factor、Event、Point、NLine；时间第一成员（Birth/T）
roles.go	角色 Role 与策略 Strategy 枚举；Agent 构造（Birth 第一成员）、NewAgent；Agent 含 Factor、InSchool、InExamPool、Score、ScoreHistory、Stress、LegalRisk、StrategyCount、LastStrategy
incentive.go	IncentiveParams（时间第一成员）；时间激励函数 Incentive(t, …)、IncentiveAt；教师收益 TeacherPayoff(平均成绩，升学率)；高考成绩预测 GaokaoScore(ScoreHistory)；学生收益 StudentPayoff(GaokaoScore, InExamPool)
strategy.go	ChooseStrategy(t, agent, ctx) 按角色分派；各角色策略函数（教师Y/F、犹大、黑曼巴、P、Y、C13、普通学生、心理老师、领导）；Consequence 后果结构；ApplyStrategy(t, strategy, agent, ctx, rng) 及后果量化
sim.go	SimContext（聚合状态含 StepsRemaining、LastRoundTeacherDefection）；SimState（Birth、Current、Agents、Events、Points、Duration）；LogTS、UpdateContext、Run（步进、每年末更新 ScoreHistory、激励采样、重复博弈两阶段选策略与施加后果）；pickStudentTarget
y.go	主仿真入口 Y(base, end, randomCount, seed)；newNamedAgents 构造教师与命名学生；输出时间序列日志、激励采样、终态统计、收益函数采样、学生策略分组统计、C13 建议
y_test.go	TestY 完整仿真（可 -short 跳过）；TestY_shortParams、TestY_shortRun 短仿真与 Run 单元测试

参考

[1] 踢貓效應 — https://zh.wikipedia.org/wiki/踢貓效應

Incentive Function Design under Education Bureaucracy

Introduction

This article takes the education bureaucracy system as the macro context, and extracts family background, personality traits, and behaviour patterns of: (1) Teachers Y, F, D; (2) Students Judas, Black Mamba, P, Y, C13; (3) the school psychologist; (4) school leadership. It breaks “human decisions” into computable variables → scores → probability / outcome, analyses policy risks and consequences of different decisions, studies optimal strategies by role, and designs a time-based incentive function for school leadership as far as possible.

Formal Logic and Definitions

Education bureaucracy: Students answer to teachers, teachers are managed by the principal, the principal answers to the school. School performance is quantified by average student score and undergraduate enrolment rate.

Kick the cat (also “kick the dog”) [1]: A metaphor for higher-ranking people in an organisation or family displacing frustration or dissatisfaction by punishing lower-ranking people, who in turn pass it down the chain, producing a cascade.

Payoff functions: Teachers’ payoff is average student score and undergraduate enrolment rate; students’ payoff is individual college-entrance exam score; final exam score is positively correlated with the past three years’ scores.

Payoff (Payoff) Definitions

Teacher payoff (U_{\text{teacher}}): Arguments are average student score (\bar{S}) and undergraduate enrolment rate (r)
[U_{\text{teacher}} = w_{\text{avg}} \cdot \bar{S} + w_{\text{enroll}} \cdot r]
Implementation uses (w_{\text{avg}}=0.6), (w_{\text{enroll}}=0.4). Performance (leadership incentive) is isomorphic to teacher payoff.
Predicted student exam score (G): Positively correlated with year-end scores of the past 3 years, with higher weight on recent years
[G = w_1 S_{t-3} + w_2 S_{t-2} + w_3 S_{t-1},\quad w_1+w_2+w_3=1,\; w_1\le w_2\le w_3]
Implementation uses (w_1=0.2,\,w_2=0.3,\,w_3=0.5).
Student payoff (U_{\text{student}}): Payoff is predicted individual exam score; no exam payoff if not in the exam pool
[U_{\text{student}} = \begin{cases} G & \text{if in exam pool} \ 0 & \text{otherwise} \end{cases}]

Quantitative Formulas

Formula 1: Average student score = Total student score / Number of students

Formula 2: Undergraduate enrolment rate = Number admitted to undergraduate / Number taking exam × 100%

Character Modelling

Teacher Y: Uses Formula 1 for decisions. Can reduce the denominator (student count) via PUA tactics (pressuring students to leave or drop out); uses standing punishment, calling parents, public criticism in class meetings; uses lying and avoiding oversight to cope with moral and legal scrutiny.

Teacher F: Uses Formula 1 and Formula 2. Keeps student count in Formula 1 fixed but can reduce the number of exam takers to improve enrolment rate.

Teacher D: Uses Formula 1 and Formula 2. Maximises average score without removing students.

Student Judas: Affluent middle class, curries favour with Teacher F and gets a management role. Uses online harassment to attack other students to reduce headcount.

Student Black Mamba: Very wealthy; can buy an undergraduate place (e.g. Macau). The exam is optional; he may not sit it.

Student P: Low academic ability and IQ; responds to Teacher Y’s PUA with avoidance and withdrawal (leave of absence) as passive resistance.

Student Y: Highly myopic, high-IQ athlete. Uses athlete bonus in the exam; bonus requires school leadership approval.

Student C13: Poor family, genius with IQ > 160.

School psychologist: Balancer in the system; reduces student stress and negative emotion.

School leadership: Allocates resources (e.g. who gets bonus, who leaves), assigns the psychologist to targeted counselling.

A time-series meta-programming model quantifies family background, IQ, EQ, PUA exposure, legal/moral risk, etc., and models agents by role to simulate strategies and consequences. Implementation is in Go under function/local/n/china/shantou/.

Time-Series Meta-Programming Model (aligned with function/time.md)

First principle: Time is the first dimension. All time-series objects have time as the first member; time-series functions have time as the first parameter.
Time-series objects: Factor, Agent, SimState have Birth or Current as the first member.
Time-series functions: Incentive(t, ...), ChooseStrategy(t, ...), ApplyStrategy(t, ...) take time t as the first parameter.
Time-series log: All events are logged as “time + content” (LogTS).
Visualisation: Incentive function sampled as (t, performance); time on x-axis.

Factor Definitions

Factor	Symbol/Field	Range	Meaning
Family background	FamilyBackground	[0,1]	0=very poor, 1=very rich; affects resources and paths (e.g. “money power”, athlete investment)
Intelligence	IQ	[0,1]	Maps to score; affects academic performance and strategy understanding
Emotional intelligence	EQ	[0,1]	Affects stress resistance and emotion propagation in the kick-the-cat chain
PUA exposure	PUAExposure	[0,1]	Intensity of teacher PUA on this agent
PUA resistance	PUAResistance	[0,1]	Agent’s resistance to PUA
Legal/moral risk	LegalMoralRisk	[0,1]	Risk of legal/moral accountability for agent/action

Net PUA pressure: PUAExposure × (1 - PUAResistance), driving leave/avoidance strategies.

Roles and Strategy Modelling

Role	Incentive basis	Strategies	Selection logic (brief)
Teacher Y	Formula 1 (avg)	PUA to reduce headcount, lie/evade, normal teaching	Low avg and many students → PUA; high legal risk → lie/evade
Teacher F	Formulas 1+2	Reduce exam takers, lie/evade, normal teaching	Many takers and low rate → reduce takers
Teacher D	Formulas 1+2	Lie/evade, normal teaching (no removal)	High legal risk → lie/evade; else normal teaching
Student Judas	Curries Teacher F	Online harassment, study hard	Many students and low own risk → harassment
Student Black Mamba	Money	None (no exam)	—
Student P	Low IQ, high PUA	Leave/drop out, avoid	High net PUA and stress → leave
Student Y	Athlete bonus	Athlete bonus	Stable: choose bonus
Student C13	High IQ, poor	Study hard	Stable: study hard
Psychologist	System balance	Reduce stress, soothe	High avg stress → soothe
Leadership	Performance = incentive	Pressure down (kick cat), design incentives	Low performance → pressure; high → design incentives

Strategy and Consequence Quantification

Strategy	Consequence (delta/boolean)	Target
PUA to reduce headcount	ΔStress↑, LegalRisk↑	Random target student
Reduce exam takers	LeaveExam, LegalRisk↑	Random target student
Lie/evade oversight	LegalRisk↓ (short term)	Actor
Leave/drop out	Dropout, LeaveExam	Self
Online harassment	ΔStress↑, LegalRisk↑	Random target student
Athlete bonus / study hard / avoid	ΔScore, ΔStress	Self
Soothe / reduce stress	ΔStress↓	Random target student
Pressure down	ΔStress↑	Random target student

Time Incentive Function

Performance (leadership incentive) is isomorphic to teacher payoff, as an incentive function of time (t):

Incentive(t) = TeacherPayoff(avg score, enrolment rate) = 0.6 × avg score + 0.4 × enrolment rate

Avg score and enrolment rate are computed from current in-school students, exam takers, and admittees at time (t). Each step samples Incentive(t) to get a time series for a “time–performance” plot. Predicted exam score is updated at year-end from ScoreHistory (past 3 years) for GaokaoScore and StudentPayoff.

Nash Equilibrium and Best Strategies

Under the above payoff functions and strategy sets, the equilibrium and recommendations (simulation and theory agree):

Role	Payoff/goal	Strategy at Nash	Recommended best strategy
Teachers	(U_{\text{teacher}}=\bar{S}) and rate	When avg low and many students → PUA/reduce takers (defect); when legal risk high or previous defect → normal teaching (cooperate)	In repeated game: mostly normal teaching to keep reputation; consider reduction only when avg clearly low and headcount high, mind legal/moral risk
Students	(U_{\text{student}}=G) (3-year correlation)	High IQ, low PUA: study hard; high PUA and stress: leave or avoid	Maximise 3-year score: prefer “study hard”; under high stress or PUA use “avoid” or leave to protect long-term payoff
Psychologist	System stability (lower total stress)	Soothe when avg stress above threshold, else no action	When `AvgStress > threshold` soothe; else no action
Leadership	Performance = (U_{\text{teacher}})	When performance below threshold pressure down (kick cat); else design incentives	Low → pressure; high → design incentives, approve bonuses, allocate resources

Nash equilibrium summary: Teachers and students are in a repeated game. Persistent defection (PUA/reduce takers) triggers student retaliation (e.g. harassment) or avoidance/leave, hurting average score and rate and thus teacher payoff. At equilibrium, teachers mostly teach normally and students without extreme stress study hard, so both approach maximum payoff over time. Psychologist and leadership act on aggregate indicators (avg stress, performance) with threshold responses as above.

Simulation Design

Step: Advance by day (or configurable).
Per step: Update aggregates (student count, exam takers, rate, avg stress); for each agent call ChooseStrategy(t, agent, ctx), then ApplyStrategy(t, strategy, ...), apply consequences, append “time + content” log.
Output: (1) Time-series log; (2) incentive function sample (time → performance); (3) final stats (in-school, exam takers, admits, avg score, rate, performance).

Implementation Files

Source code location: zeusro/system — function/local/n/china/shantou/y

File	Content
model.go	Time-series types: Factor, Event, Point, NLine; time first member (Birth/T)
roles.go	Role and Strategy enums; Agent (Birth first), NewAgent; Factor, InSchool, InExamPool, Score, ScoreHistory, Stress, LegalRisk, StrategyCount, LastStrategy
incentive.go	IncentiveParams; Incentive(t,…), IncentiveAt; TeacherPayoff; GaokaoScore(ScoreHistory); StudentPayoff
strategy.go	ChooseStrategy(t, agent, ctx) by role; Consequence; ApplyStrategy(t, strategy, …)
sim.go	SimContext, SimState; LogTS, UpdateContext, Run; pickStudentTarget
y.go	Main entry Y(…); newNamedAgents; outputs log, incentive sample, final stats, C13 advice
y_test.go	TestY (full run, -short to skip); TestY_shortParams, TestY_shortRun

Reference

[1] Kick the cat — https://en.wikipedia.org/wiki/Displaced_aggression

教育行政化体系下における激励関数の設計

はじめに

本稿は教育行政化体系をマクロな背景として、(1)教師Y・F・D、(2)生徒ユダ・ブラックマンバ・P・Y・C13、(3)心理教師、(4)学校領導の家庭環境・性格・行動パターンを抽出する。「人間の意思決定」を計算可能な変数→スコア→確率/結果に分解し、異なる決定の政策リスクと結果を分析し、役割ごとの最適戦略を検討し、学校領導のための時間激励関数を可能な限り設計する。

形式論理と定義

教育行政化：生徒は教師に、教師は校長に、校長は学校に責任を負う。学校の業績は生徒の平均成績と本科進学率で定量化される。

蹴り猫効果（Kick the cat、蹴り犬効果）[1]：組織や家庭で上位者が下位者を罰して不満を転嫁し、下位者も同様にさらに下位に伝播させる連鎖の比喩。

利得関数：教師の利得は生徒の平均成績と本科進学率。生徒の利得は個人の大学入試成績。最終成績は過去3年の成績と正の相関。

利得（Payoff）の定義

教師利得 (U_{\text{teacher}})：生徒平均成績 (\bar{S}) と本科進学率 (r) を変数とする
[U_{\text{teacher}} = w_{\text{avg}} \cdot \bar{S} + w_{\text{enroll}} \cdot r]
実装では (w_{\text{avg}}=0.6)、(w_{\text{enroll}}=0.4)。業績（領導層の激励）は教師利得と同型。
生徒の入試成績予測 (G)：過去3年の年末成績と正の相関、近年ほど重み大
[G = w_1 S_{t-3} + w_2 S_{t-2} + w_3 S_{t-1},\quad w_1+w_2+w_3=1,\; w_1\le w_2\le w_3]
実装では (w_1=0.2,\,w_2=0.3,\,w_3=0.5)。
生徒利得 (U_{\text{student}})：個人の入試成績（予測値）が利得。受験プール外なら入試利得なし
[U_{\text{student}} = \begin{cases} G & \text{受験プールに在籍時} \ 0 & \text{それ以外} \end{cases}]

定量公式

公式1：生徒平均成績 = 生徒総得点 / 生徒数

公式2：本科進学率 = 本科合格者数 / 受験者数 × 100%

人物モデリング

教師Y：公式1を意思決定の根拠とする。公式1の生徒数を減らせる（PUA戦略で休学・退学させる）。罰則・保護者連絡・班会での公開名指し批判で生徒数を減らす。嘘と監視回避で上級の道徳・法審査に対応。

教師F：公式1・公式2を根拠とする。公式1の生徒数は変えず、本科進学率のため受験者数を減らせる。

教師D：公式1・公式2を根拠とする。平均成績の最大化を目指すが、生徒の排除は行わない。

生徒ユダ：富裕な中産階級。教師Fに取り入って群管理を獲得。ネットいじめで他生徒を攻撃し、人数削減を図る。

生徒ブラックマンバ：非常に裕福。マカオ科技大学などの本科を「金の力」で購入可能。受験は選択肢の一つで、受験しないこともある。

生徒P：学力・IQが低い。教師YのPUAに対して回避的態度を取り、休学で消極的抵抗。

生徒Y：強度近視の高IQアスリート。入試でスポーツ加分を利用。加分は学校領導の承認が必要。

生徒C13：貧しい家庭だが IQ>160 の天才。

心理教師：システムのバランサー。生徒の心理圧力と負の感情を軽減。

学校領導：資源配分（誰に加分、誰を休学・退学させるか）、心理教師の個別指導割り当てを担当。

時系列メタプログラミングモデルで家庭背景・IQ・EQ・PUA・法規・道徳リスクなどを定量化し、役割ごとにエージェントをモデル化して戦略と結果をシミュレート。実装はGo、function/local/n/china/shantou/ に配置。

時系列メタプログラミングモデル（function/time.md と整合）

第一原理：時間が第一次元。時系列オブジェクトの第一メンバは時間、時系列関数の第一引数は時間。
時系列オブジェクト：Factor、Agent、SimState は Birth または Current を第一メンバに持つ。
時系列関数：Incentive(t, ...)、ChooseStrategy(t, ...)、ApplyStrategy(t, ...) は時間 t を第一引数に取る。
時系列ログ：全イベントは「時間＋内容」形式（LogTS）。
可視化：激励関数を (t, 業績値) でサンプリングし、時間をx軸にプロット。

量化因子の定義

因子	記号/フィールド	範囲	意味
家庭背景	FamilyBackground	[0,1]	0=極貧、1=極富。資源と進路（金の力・アスリート投資）に影響
知能	IQ	[0,1]	スコアに写像。学業と戦略理解に影響
情動知能	EQ	[0,1]	耐圧性と蹴り猫連鎖の感情伝播に影響
PUA暴露	PUAExposure	[0,1]	教師のPUAが当該個体に及ぶ強度
PUA耐性	PUAResistance	[0,1]	PUAへの耐性
法規・道徳リスク	LegalMoralRisk	[0,1]	個体/行為が引き起こす追及リスク

純 PUA 圧力：PUAExposure × (1 - PUAResistance)。休学・回避戦略の駆動に使用。

役割と戦略モデリング

役割	激励の根拠	選択可能な戦略	選択ロジック（概要）
教師Y	公式1（平均）	PUA減員・嘘/回避・通常授業	平均低かつ人数多→PUA；法リスク高→嘘/回避
教師F	公式1+2	受験者削減・嘘/回避・通常授業	受験者多かつ進学率低→受験者削減
教師D	公式1+2	嘘/回避・通常授業（排除なし）	法リスク高→嘘/回避；否則通常授業
生徒ユダ	教師Fに取り入る	ネットいじめ・勉強	人数多かつ自身の法リスク低→いじめ
生徒ブラックマンバ	金の力	なし（受験不参加）	—
生徒P	低IQ・高PUA暴露	休学・退学・回避	純PUA高かつ圧力大→休学
生徒Y	スポーツ加分	スポーツ加分	安定：加分選択
生徒C13	高IQ・貧困	勉強	安定：勉強
心理教師	システム平衡	減圧・安抚	平均圧力高→減压
学校領導	業績=激励	下への圧力・激励設計	業績低→圧力（蹴り猫）；高→激励設計

戦略と結果の定量化

戦略	結果（増分/ブール）	対象
PUA減員	ΔStress↑, LegalRisk↑	ランダム対象生徒
受験者削減	LeaveExam, LegalRisk↑	ランダム対象生徒
嘘/監視回避	LegalRisk↓（短期）	行為者
休学・退学	Dropout, LeaveExam	本人
ネットいじめ	ΔStress↑, LegalRisk↑	ランダム対象生徒
スポーツ加分/勉強/回避	ΔScore, ΔStress	本人
減压・安抚	ΔStress↓	ランダム対象生徒
下への圧力	ΔStress↑	ランダム対象生徒

時間激励関数

業績（領導層が知覚する激励）は教師利得と同型。時間 (t) の激励関数として：

Incentive(t) = TeacherPayoff(平均成績, 本科進学率) = 0.6 × 平均成績 + 0.4 × 本科進学率

平均成績と進学率は、時刻 (t) の在籍者・受験者・合格者から計算。各ステップで Incentive(t) をサンプリングし「時間–業績」曲線を描く。入試成績予測は毎年末に ScoreHistory（過去3年）で更新し、GaokaoScore と StudentPayoff に用いる。

ナッシュ均衡と各主体の最適戦略

上記利得関数と戦略空間のもとで、均衡と推奨（シミュレーションと理論は一致）：

役割	利得/目標	ナッシュ下の戦略	最適戦略の提案
教師	(U_{\text{teacher}}=\bar{S}) と進学率	平均低かつ人数多→PUA/受験者削減（裏切り）；法リスク高または前回裏切り→通常授業（協力）	繰り返し博弈では主に通常授業で評判維持；平均が明らかに低く人数が多いときのみ減員を検討し、法・道徳リスクに注意
生徒	(U_{\text{student}}=G)（3年相関）	高IQ・低PUA→勉強；高PUAかつ圧力大→休学または回避	3年成績の最大化を主に：優先は「勉強」；高圧力・高PUA時は「回避」または必要なら休学で長期利得を守る
心理教師	システム安定（総圧力低減）	平均圧力が閾値超で減压・安抚、否則無行動	`AvgStress > 閾値` のとき減压、それ以外は無行動
学校領導	業績 = (U_{\text{teacher}})	業績が閾値未満で下へ圧力（蹴り猫）；否則激励設計	低→圧力；高→激励設計・加分承認・資源配分

ナッシュ均衡の要点：教師と生徒は繰り返し博弈の関係。教師が長期に裏切り（PUA/受験者削減）すると生徒の報復（いじめ等）や回避・休学を招き、平均成績と進学率を損ない教師自身の利得も下がる。均衡では教師は多く通常授業、生徒は極端な圧力がなければ勉強し、双方が長期で利得最大化に近づく。心理教師と領導は集約指標（平均圧力・業績）に応じた閾値反応が最適。

シミュレーション実験設計

ステップ：日単位（または設定可能）で進行。
各ステップ：現状態で集約指標（生徒数・受験者数・進学率・平均圧力等）を更新し、在籍メンバーごとに役割で ChooseStrategy(t, agent, ctx) を呼び、得た戦略で ApplyStrategy(t, strategy, ...) を呼んで結果を適用し、「時間+内容」ログを追加。
出力：① 時系列ログ；② 激励関数サンプル（時間→業績）；③ 終状態統計（在籍数・受験者数・本科合格数・平均成績・進学率・業績）。

実装ファイル

ソースコードの場所：zeusro/system — function/local/n/china/shantou/y

ファイル	内容
model.go	時系列型：Factor, Event, Point, NLine。時間第一メンバ（Birth/T）
roles.go	Role・Strategy 列挙。Agent（Birth第一）、NewAgent。Factor, InSchool, InExamPool, Score, ScoreHistory, Stress, LegalRisk, StrategyCount, LastStrategy
incentive.go	IncentiveParams。Incentive(t,…), IncentiveAt。TeacherPayoff。GaokaoScore(ScoreHistory)。StudentPayoff
strategy.go	ChooseStrategy(t, agent, ctx) を役割で分派。Consequence。ApplyStrategy(t, strategy, …)
sim.go	SimContext, SimState。LogTS, UpdateContext, Run。pickStudentTarget
y.go	メイン入口 Y(…)。newNamedAgents。ログ・激励サンプル・終状態・C13アドバイスを出力
y_test.go	TestY（本番長、-shortでスキップ可）。TestY_shortParams, TestY_shortRun

参考

[1] 蹴り猫効果（Kick the cat）— https://en.wikipedia.org/wiki/Displaced_aggression

Проектирование функции стимулирования в условиях образовательной бюрократии

Введение

В статье в качестве макроконтекста рассматривается система образовательной бюрократии; выделяются семейный фон, черты характера и модели поведения: (1) учителей Y, F, D; (2) учеников Иуда, Блэк Мамба, P, Y, C13; (3) школьного психолога; (4) руководства школы. «Человеческие решения» разлагаются на вычислимые переменные → оценки → вероятность / исход; анализируются политические риски и последствия разных решений, по ролям исследуются оптимальные стратегии и по возможности проектируется временная функция стимулирования для руководства школы.

Формальная логика и определения

Образовательная бюрократия: ученики подотчётны учителям, учителя управляются директором, директор подотчётен школе. Результативность школы измеряется средней успеваемостью и долей поступления в бакалавриат.

Эффект „пинок кошке“ (Kick the cat, «пинок собаке») [1]: метафора о том, что люди выше по иерархии в организации или семье переносят фрустрацию или недовольство, наказывая нижестоящих, которые в свою очередь передают это дальше по цепочке.

Функции выигрыша: выигрыш учителя — средняя успеваемость и доля поступления в бакалавриат; выигрыш ученика — личный результат вступительного экзамена; итоговый экзаменационный результат положительно коррелирует с результатами за последние три года.

Определения выигрыша (Payoff)

Выигрыш учителя (U_{\text{teacher}}): аргументы — средняя успеваемость (\bar{S}) и доля поступления (r)
[U_{\text{teacher}} = w_{\text{avg}} \cdot \bar{S} + w_{\text{enroll}} \cdot r]
В реализации (w_{\text{avg}}=0.6), (w_{\text{enroll}}=0.4). Результативность (стимул для руководства) изоморфна выигрышу учителя.
Прогноз экзаменационного балла ученика (G): положительная корреляция с годовыми баллами за последние 3 года, больший вес у недавних лет
[G = w_1 S_{t-3} + w_2 S_{t-2} + w_3 S_{t-1},\quad w_1+w_2+w_3=1,\; w_1\le w_2\le w_3]
В реализации (w_1=0.2,\,w_2=0.3,\,w_3=0.5).
Выигрыш ученика (U_{\text{student}}): выигрыш — прогноз личного экзаменационного балла; вне экзаменационного пула выигрыша от экзамена нет
[U_{\text{student}} = \begin{cases} G & \text{если в экзаменационном пуле} \ 0 & \text{иначе} \end{cases}]

Количественные формулы

Формула 1: средняя успеваемость = сумма баллов учеников / число учеников

Формула 2: доля поступления в бакалавриат = число поступивших в бакалавриат / число сдававших экзамен × 100%

Моделирование персонажей

Учитель Y: использует формулу 1 для решений. Может уменьшать знаменатель (число учеников) через PUA-тактики (давление с целью ухода/отчисления); использует стояние в углу, звонки родителям, публичную критику на классных часах; ложь и уход от контроля перед моральной и правовой проверкой.

Учитель F: использует формулу 1 и формулу 2. Число учеников в формуле 1 не меняет, но может уменьшать число сдающих экзамен ради доли поступления.

Учитель D: использует формулу 1 и формулу 2. Максимизирует среднюю успеваемость без исключения учеников.

Ученик Иуда: зажиточный средний класс, подлаживается к учителю F и получает роль «управляющего». Использует сетевую травлю против других учеников, чтобы сократить численность.

Ученик Блэк Мамба: очень богатая семья; может «купить» место в бакалавриате (напр. Макао). Экзамен для него опционален.

Ученик P: низкие способности и IQ; на PUA учителя Y реагирует уходом и отчислением как пассивным сопротивлением.

Ученик Y: сильная близорукость, высокий IQ, спортсмен. Использует спортивную надбавку к экзамену; надбавка требует одобрения руководства школы.

Ученик C13: бедная семья, гений с IQ > 160.

Школьный психолог: балансир в системе; снижает психологическое давление и негативные эмоции учеников.

Руководство школы: распределяет ресурсы (кто получает надбавку, кто отчисляется), назначает психолога на целевое консультирование.

Временная метапрограммная модель квантифицирует семейный фон, IQ, EQ, PUA-воздействие, правовой/моральный риск и т.д., по ролям моделирует агентов и симулирует стратегии и последствия. Реализация на Go в каталоге function/local/n/china/shantou/.

Временная метапрограммная модель (согласована с function/time.md)

Первый принцип: время — первое измерение. У всех временных объектов время — первый член; у временных функций время — первый аргумент.
Временные объекты: у Factor, Agent, SimState первый член — Birth или Current.
Временные функции: Incentive(t, ...), ChooseStrategy(t, ...), ApplyStrategy(t, ...) принимают время t первым аргументом.
Временной лог: все события в формате «время + содержание» (LogTS).
Визуализация: функция стимулирования сэмплируется как (t, результативность); время по оси x.

Определения факторов

Фактор	Символ/поле	Диапазон	Смысл
Семейный фон	FamilyBackground	[0,1]	0=крайняя бедность, 1=крайнее богатство; влияет на ресурсы и пути (деньги, спорт-инвестиции)
Интеллект	IQ	[0,1]	Отображение в балл; влияет на успеваемость и понимание стратегии
Эмоциональный интеллект	EQ	[0,1]	Влияет на устойчивость к стрессу и передачу эмоций в цепочке «пинок кошке»
PUA-воздействие	PUAExposure	[0,1]	Интенсивность учительского PUA на данного агента
Сопротивление PUA	PUAResistance	[0,1]	Устойчивость агента к PUA
Правовой/моральный риск	LegalMoralRisk	[0,1]	Риск правовой/моральной ответственности за агента/действие

Чистое PUA-давление: PUAExposure × (1 - PUAResistance), движет стратегиями ухода/избегания.

Роли и моделирование стратегий

Роль	Основа стимула	Стратегии	Логика выбора (кратко)
Учитель Y	Формула 1 (среднее)	PUA-сокращение, ложь/уклонение, обычное преподавание	Низкое среднее и много учеников → PUA; высокий правовой риск → ложь/уклонение
Учитель F	Формулы 1+2	Сокращение числа сдающих, ложь/уклонение, обычное преподавание	Много сдающих и низкая доля → сократить сдающих
Учитель D	Формулы 1+2	Ложь/уклонение, обычное преподавание (без исключения)	Высокий правовой риск → ложь/уклонение; иначе обычное преподавание
Ученик Иуда	Подлаживается к учителю F	Сетевая травля, учёба	Много учеников и низкий собственный риск → травля
Ученик Блэк Мамба	Деньги	Нет (не сдаёт экзамен)	—
Ученик P	Низкий IQ, высокое PUA	Уход/отчисление, избегание	Высокое чистое PUA и стресс → уход
Ученик Y	Спортивная надбавка	Спортивная надбавка	Стабильно: выбирает надбавку
Ученик C13	Высокий IQ, бедность	Учёба	Стабильно: учёба
Психолог	Баланс системы	Снижение стресса, успокоение	Высокий средний стресс → успокоение
Руководство	Результативность = стимул	Давление вниз (пинок кошке), проектирование стимулов	Низкая результативность → давление; высокая → проектирование стимулов

Квантификация стратегий и последствий

Стратегия	Последствие (приращение/булево)	Объект
PUA-сокращение	ΔStress↑, LegalRisk↑	Случайный ученик-цель
Сокращение сдающих	LeaveExam, LegalRisk↑	Случайный ученик-цель
Ложь/уклонение от контроля	LegalRisk↓ (краткосрочно)	Действующее лицо
Уход/отчисление	Dropout, LeaveExam	Сам агент
Сетевая травля	ΔStress↑, LegalRisk↑	Случайный ученик-цель
Спортивная надбавка / учёба / избегание	ΔScore, ΔStress	Сам агент
Успокоение / снижение стресса	ΔStress↓	Случайный ученик-цель
Давление вниз	ΔStress↑	Случайный ученик-цель

Временная функция стимулирования

Результативность (воспринимаемый руководством стимул) изоморфна выигрышу учителя как функция стимулирования времени (t):

Incentive(t) = TeacherPayoff(средняя успеваемость, доля поступления) = 0.6 × средняя успеваемость + 0.4 × доля поступления

Средняя успеваемость и доля поступления вычисляются по состоянию на момент (t) (ученики в школе, сдающие, поступившие). На каждом шаге сэмплируется Incentive(t) для графика «время–результативность». Прогноз экзаменационного балла обновляется в конце года по ScoreHistory (последние 3 года) для GaokaoScore и StudentPayoff.

Равновесие Нэша и оптимальные стратегии

При заданных функциях выигрыша и пространстве стратегий равновесие и рекомендации (модель и теория совпадают):

Роль	Выигрыш/цель	Стратегия в равновесии Нэша	Рекомендуемая оптимальная стратегия
Учителя	(U_{\text{teacher}}=\bar{S}) и доля	При низком среднем и многих учениках → PUA/сокращение сдающих (предательство); при высоком правовом риске или после предательства → обычное преподавание (кооперация)	В повторяющейся игре в основном обычное преподавание для репутации; сокращение только при явно низком среднем и большом числе учеников, с учётом правового/морального риска
Ученики	(U_{\text{student}}=G) (корреляция за 3 года)	Высокий IQ, низкое PUA → учёба; высокое PUA и стресс → уход или избегание	Максимизация балла за 3 года: приоритет «учёба»; при высоком стрессе или PUA — «избегание» или при необходимости уход для защиты долгосрочного выигрыша
Психолог	Стабильность системы (снижение общего стресса)	Успокоение при среднем стрессе выше порога, иначе бездействие	При `AvgStress > порог` успокоение, иначе бездействие
Руководство	Результативность = (U_{\text{teacher}})	При результативности ниже порога — давление вниз (пинок кошке); иначе проектирование стимулов	Низкая → давление; высокая → проектирование стимулов, утверждение надбавок, распределение ресурсов

Равновесие Нэша: учителя и ученики в повторяющейся игре. Длительное предательство (PUA/сокращение сдающих) провоцирует ответ учеников (травля и т.п.) или избегание/уход, что снижает среднюю успеваемость и долю поступления и тем самым выигрыш учителя. В равновесии учителя в основном преподают нормально, ученики при отсутствии экстремального стресса учатся, и обе стороны в долгосроке приближаются к максимуму выигрыша. Психолог и руководство реагируют на агрегированные показатели (средний стресс, результативность) пороговой реакцией, как выше.

Дизайн имитационного эксперимента

Шаг: продвижение по дням (или настраиваемо).
За шаг: обновление агрегатов (число учеников, сдающих, доля поступления, средний стресс); для каждого агента вызов ChooseStrategy(t, agent, ctx), затем ApplyStrategy(t, strategy, ...), применение последствий, добавление лога «время + содержание».
Выход: (1) временной лог; (2) сэмпл функции стимулирования (время → результативность); (3) итоговая статистика (в школе, сдающие, поступившие, средняя успеваемость, доля, результативность).

Файлы реализации

Расположение исходного кода: zeusro/system — function/local/n/china/shantou/y

Файл	Содержимое
model.go	Временные типы: Factor, Event, Point, NLine; время — первый член (Birth/T)
roles.go	Роли и стратегии (перечисления); Agent (Birth первый), NewAgent; Factor, InSchool, InExamPool, Score, ScoreHistory, Stress, LegalRisk, StrategyCount, LastStrategy
incentive.go	IncentiveParams; Incentive(t,…), IncentiveAt; TeacherPayoff; GaokaoScore(ScoreHistory); StudentPayoff
strategy.go	ChooseStrategy(t, agent, ctx) по ролям; Consequence; ApplyStrategy(t, strategy, …)
sim.go	SimContext, SimState; LogTS, UpdateContext, Run; pickStudentTarget
y.go	Главный вход Y(…); newNamedAgents; вывод лога, сэмпла стимула, итоговой статистики, совета по C13
y_test.go	TestY (полный прогон, -short для пропуска); TestY_shortParams, TestY_shortRun

Ссылка

[1] Эффект «пинок кошке» — https://en.wikipedia.org/wiki/Displaced_aggression

政治正确是如何毁了开源社区

Thu, 22 Jan 2026 00:00:00 +0000

❌master ✅ main

master/slave 是计算机长久以来的一种主从架构。通过主从的分离，实现分布式读和故障转移。然而在Black Lives Matter 运动中，github 在2020年6月中公布了计划，反对使用可能带有奴役联想的术语，并在2020 年 10 月 1 日默认新仓库的分支名改为 “main”。

道德警察

政治正确在开源社区的一大体现，就是各种道德警察。很多中国的开发者，利用他们为数不多的时间开发开源软件，结果还被各种issue霸占，整天围绕着一些”弱智问题”问一些弱智问题。像是怎么安装这个软件，xx出错了怎么修复。

他们甚至没有时间去看一下报错的错误堆栈是从哪个地方开始的，总是理所当然地浪费他人的时间。然后把他人的无私贡献当成”开源精神”。

要么就是把一些八竿子打不着的理念带到开源社区，比如LGBT。

LGBT文化在开源社区的流行，个人认为是一种历史的倒退。就好像我们中国的女拳斗士，她们借助男多女少的性别优势，发表各种逆天言论。

但究其理论根基，是一个黑洞。她们最终的述求，不过是要在结婚前多要点钱，结婚中（防止对方）转移资产，离婚后平方对方资产，要不就是在细枝末节的小事上斤斤计较（比如要求他人环保自己却不断浪费食物），靠一些“情感考验”索取对方情绪价值。在这一点上，中西方竟然取得了完美的统一。

Black Lives Matter & LLM寄生虫

道德警察在Black Lives Matter运动中特别明显。我记得在2020年底的时候，查看kubernetes网页文档突然多了声援BLM的牛皮癣广告。

查阅历史发现是 #25173 https://github.com/kubernetes/website/pull/25173/files 添加的。但后来在Jan 8, 2021，https://github.com/kubernetes/website/pull/25769 的时候就被移除了，而且移除的理由非常隐晦，仿佛一切都没存在过。

BLM运动的联合发起人Patrisse Cullors，于2021年辞去BLMGNF执行董事职务，税务文件显示她在财政年度内未领取薪水，而是作为”无薪志愿者”，但她与基金的关联公司和家人收到大笔资金：她的兄弟Paul Cullors的公司（Cullors Protection 或 Black Ties LLC）收到约84万美元用于”专业安全服务”（2022年税务文件）。自2021年收入总计以来超过420万美元。

Cullors还被指使用基金购买洛杉矶一处约600万美元的豪宅，用于”黑人创意空间”。

而其他发起人董事会成员Shalomyah Bowers的公司收到210万美元咨询费。

前董事会成员Raymond Howard及其姐妹的公司收到约110万美元。

两名前雇员收到结算金：一位前董事会成员40万美元，另一位33.5万美元（2023年）。

而随着时间的推移我们发现，声援这场运动的人才是真正的小丑。在 BLM 运动背后，最终得到实质利益的只是组织者的收入与豪宅，而非运动本身的理想。消费死者能够换回这么大的好处，也就只有这种资本主义国家能办到了。嘴上都是正义，一切都是生意。

他们的收入跟kubernetes这个项目根本毫无关系。它让我又想起了初高中那些寄生虫同学，他们只想着浪费你的资源，去实现自己的目的。

就好像之前的 https://github.com/tailwindlabs/tailwindcss 。现在的LLM辅助编程工具，可以在用户不读懂文档的前提下直接集成到自己的项目中。https://github.com/zeusro/tool 我这个项目就是用Cursor集成tailwindcss 的。

说实话，这让我有点毛骨悚然。一方面，开发者兢兢业业地工作，项目的star越来越多，用户也越来越多；然而真实的一面却是，获得的这些虚拟赞誉，完全无法覆盖团队的日常开支，甚至连基本的生存都成为问题。

我的想法

我在2020年的时候就认识到，kubernetes这个项目其实跟中国人没啥关系。项目主要发起人是Google cloud的人，那么如果你的工作关系不归属于Google cloud，那么基本上他们也不会接受你的pull request。这也完美解释了为什么LGBT的banner会出现在 kubernetes/website 这个项目。

crd是kubernetes的资源，而cr和controller是crd的下游。因此不管第三方（openkruise）实现的deployment、StatefulSet 、 DaemonSet 控制器有多好，这辈子要往上游 kubernetes 合并，估计有生之年都见不到了。

我自己早已被kubernetes 这个组织拉黑，但我无所叼谓。

作为国内的开发者，我觉得大家其实应该思考一个问题：如果我们总是等待救世主的到来，才付诸行动。那么有没有一种可能，其实这个世界从来就没有什么神仙皇帝，也不存在所谓的救世主呢？

我们总是陷入一种模仿者的被动思维，不愿意去吃第一只螃蟹。而是等到项目成熟之后，才想着去分一杯羹，然而人家根本就不带你玩。

开源世界的政治斗争远比我们想象的要残酷。和平与开放之下，其实暗流涌动。

对于个人开发和初创团队开发的开源项目，我不会发表任何意见，看不爽不用便是。毕竟人家能付出点时间开发，就已经实属不易；但对于带上市公司背景的单位，我觉得眼光还是要放长远一点，姿态先放低一点，先立足于国内草台班子和小微企业占多数的情况，想清楚项目立意的客户群体。

整天拿着百万年薪，写出来的代码却狗屁不通，连资源占用的ROI和边际收益，都无法跟喜欢零元购的小老板们说清楚。

Yellow Lives Matter

如果kubernetes不改变，那就由我来改变kubernetes。

我决定以 https://github.com/p-program/kube-killer 和 https://github.com/Z-Nightmare/kuberneteskuberneteskubernetes 作为起点，在全球互联网发起 Yellow Lives Matter 运动，抗议 Kubernetes 组织这种国籍歧视和道德偏见。

“The old is dying and the new cannot be born; in this interregnum a great variety of morbid symptoms appear.”

How Political Correctness Ruined the Open Source Community

❌master ✅ main

master/slave is a long-standing master-slave architecture in computing. Through the separation of master and slave, distributed reading and failover are achieved. However, during the Black Lives Matter movement, GitHub announced plans in June 2020 to oppose the use of terms that might carry associations with slavery, and on October 1, 2020, the default branch name for new repositories was changed to “main”.

Moral Police

A major manifestation of political correctness in the open source community is the various moral police. Many Chinese developers use their limited time to develop open source software, only to have their projects flooded with various issues, constantly dealing with “stupid questions” about stupid problems. Like how to install this software, or how to fix errors when something goes wrong.

They don’t even have time to look at where the error stack trace starts, always taking it for granted to waste others’ time. Then they treat others’ selfless contributions as “open source spirit”.

Or they bring completely unrelated ideologies into the open source community, such as LGBT.

The popularity of LGBT culture in the open source community is, in my opinion, a historical regression. It’s like the female fighters in China, who leverage the gender advantage of there being more men than women to make all kinds of outrageous statements.

But when you examine their theoretical foundation, it’s a black hole. Their ultimate demands are nothing more than asking for more money before marriage, preventing the other party from transferring assets during marriage, splitting the other party’s assets after divorce, or being petty about trivial matters (like demanding others to be environmentally friendly while constantly wasting food themselves), and extracting “emotional value” from the other party through various so‑called “tests of feelings”. In this regard, China and the West have achieved perfect unity.

Black Lives Matter & LLM Parasites

Moral police were particularly evident during the Black Lives Matter movement. I remember that at the end of 2020, when viewing Kubernetes web documentation, there suddenly appeared BLM support advertisements.

Looking at the history, it was added by #25173 https://github.com/kubernetes/website/pull/25173/files. But later on Jan 8, 2021, https://github.com/kubernetes/website/pull/25769, it was removed, and the reason for removal was very vague, as if it never existed.

Patrisse Cullors, co-founder of the BLM movement, resigned from her position as executive director of BLMGNF in 2021. Tax documents showed that she did not receive a salary during the fiscal year, but served as an “unpaid volunteer.” However, her associated companies and family members received large sums of money: her brother Paul Cullors’ company (Cullors Protection or Black Ties LLC) received approximately $840,000 for “professional security services” (2022 tax documents). Total income since 2021 has exceeded $4.2 million.

Cullors was also accused of using the fund to purchase a mansion in Los Angeles worth approximately $6 million for a “black creative space.”

Other co-founder and board member Shalomyah Bowers’ company received $2.1 million in consulting fees.

Former board member Raymond Howard and his sister’s company received approximately $1.1 million.

Two former employees received settlement payments: one former board member $400,000, and another $335,000 (2023).

As time passed, we discovered that those who supported this movement were the real clowns. Behind the BLM movement, the only ones who actually benefited were the organizers’ income and mansions, not the ideals of the movement itself. Being able to exchange the consumption of the dead for such great benefits is something only this kind of capitalist country can achieve. All talk of justice, everything is business.

Their income has nothing to do with the Kubernetes project. It reminds me of those parasitic classmates in middle and high school, who only think about wasting your resources to achieve their own goals.

It’s like the previous https://github.com/tailwindlabs/tailwindcss. Current LLM-assisted programming tools can integrate into users’ projects without them even reading the documentation. https://github.com/zeusro/tool This project of mine integrates tailwindcss using Cursor.

To be honest, this makes me a bit horrified. On one hand, developers work diligently, projects get more and more stars, and users keep increasing; however, the reality is that these virtual accolades cannot cover the team’s daily expenses, and even basic survival becomes a problem.

My Thoughts

I realized back in 2020 that the Kubernetes project actually has nothing to do with Chinese people. The main initiators of the project are people from Google Cloud, so if your work relationship doesn’t belong to Google Cloud, they basically won’t accept your pull requests. This perfectly explains why the LGBT banner appeared in the kubernetes/website project.

CRD is a Kubernetes resource, and CR and controller are downstream of CRD. Therefore, no matter how good the deployment, StatefulSet, and DaemonSet controllers implemented by third parties (openkruise) are, merging them upstream into Kubernetes will probably never happen in our lifetime.

I myself have long been blacklisted by the Kubernetes organization, but I don’t give a damn.

As a Chinese developer, I think everyone should actually think about a question: If we always wait for a savior to arrive before taking action, then is it possible that this world has never had any gods or emperors, and there is no so-called savior?

We always fall into a passive mindset of imitators, unwilling to be the first to eat the crab. Instead, we wait until the project matures before thinking about getting a piece of the pie, but they simply don’t play with us.

The political struggles in the open source world are far more brutal than we imagine. Beneath the peace and openness, there are actually undercurrents.

For open source projects developed by individuals and startup teams, I actually won’t make any comments - if you don’t like it, don’t use it. After all, it’s already quite difficult for them to spend time developing; but for units with listed company backgrounds, I think the vision should be longer-term, the posture should be lower first, and they should first establish themselves based on the situation where domestic makeshift teams and small and micro enterprises are the majority, and think clearly about the target customer group for the project’s purpose.

Instead of holding million-dollar annual salaries all day, writing code that makes no sense, unable to even explain the ROI of resource usage and marginal benefits to small bosses who like zero-cost shopping.

White Lives Matter

If Kubernetes doesn’t change, then I will change Kubernetes.

I have decided to use https://github.com/p-program/kube-killer and https://github.com/Z-Nightmare/kuberneteskuberneteskubernetes as starting points to launch a White Lives Matter movement on the global internet, protesting against the Kubernetes organization’s national discrimination and moral bias.

“The old is dying and the new cannot be born; in this interregnum a great variety of morbid symptoms appear.”

政治的正しさがオープンソースコミュニティをどのように破壊したか

❌master ✅ main

master/slaveは、コンピューティングにおける長年のマスター・スレーブアーキテクチャです。マスターとスレーブの分離により、分散読み取りとフェイルオーバーを実現します。しかし、Black Lives Matter運動の中で、GitHubは2020年6月に、奴隷制を連想させる可能性のある用語の使用に反対する計画を発表し、2020年10月1日に新規リポジトリのデフォルトブランチ名を「main」に変更しました。

道徳警察

オープンソースコミュニティにおける政治的正しさの大きな現れは、さまざまな道徳警察です。多くの中国の開発者は、限られた時間を使ってオープンソースソフトウェアを開発していますが、結果として様々なissueに占領され、愚かな問題についての「愚かな質問」に終日対応することになります。このソフトウェアのインストール方法、エラーが発生したときの修正方法など。

彼らはエラースタックトレースがどこから始まるかを見る時間さえなく、常に当然のように他人の時間を浪費します。そして、他人の無私の貢献を「オープンソース精神」として扱います。

あるいは、LGBTなど、まったく関係のない理念をオープンソースコミュニティに持ち込みます。

オープンソースコミュニティにおけるLGBT文化の流行は、個人的には歴史的な後退だと考えています。それは、中国のフェミニスト戦士たちのように、男性が女性より多いという性別の優位性を利用して、さまざまな逆天的な発言を行うのと同じです。

しかし、その理論的基盤を掘り下げてみると、それはブラックホールです。彼女たちの最終的な要求は、結婚前に少しでも多くのお金をもらうこと、結婚中に（相手が）資産を移転しないようにすること、離婚後に相手の資産を二等分すること、あるいは些細なこと（他人には環境保護を要求しながら自分は食べ物を無駄にし続けるなど）にいちいちこだわること、さらにはさまざまな「感情テスト」を通じて相手から感情的な価値を搾り取ることに過ぎません。この点において、中西双方は見事なまでに一致しています。

Black Lives Matter & LLM寄生虫

道徳警察はBlack Lives Matter運動中に特に顕著でした。2020年末、Kubernetesのウェブドキュメントを閲覧していたとき、突然BLM支援の広告が増えたのを覚えています。

履歴を調べると、#25173 https://github.com/kubernetes/website/pull/25173/files によって追加されたものでした。しかし、その後2021年1月8日、https://github.com/kubernetes/website/pull/25769 で削除され、削除の理由は非常に曖昧で、まるで存在しなかったかのようでした。

BLM運動の共同創設者Patrisse Cullorsは、2021年にBLMGNFの執行取締役を辞任しました。税務書類によると、彼女は会計年度内に給与を受け取らず、「無給のボランティア」として活動していましたが、彼女の関連会社と家族は多額の資金を受け取りました：彼女の兄弟Paul Cullorsの会社（Cullors ProtectionまたはBlack Ties LLC）は「専門セキュリティサービス」のために約84万ドルを受け取りました（2022年税務書類）。2021年以降の総収入は420万ドルを超えています。

Cullorsはまた、基金を使用してロサンゼルスの約600万ドルの豪邸を「黒人クリエイティブスペース」として購入したと指摘されています。

他の共同創設者で取締役会メンバーのShalomyah Bowersの会社は210万ドルのコンサルティング料を受け取りました。

元取締役会メンバーRaymond Howardとその姉妹の会社は約110万ドルを受け取りました。

2人の元従業員が和解金を受け取りました：元取締役会メンバー1人が40万ドル、もう1人が33.5万ドル（2023年）。

時が経つにつれ、この運動を支持した人々こそが本当の道化師であることがわかりました。BLM運動の背後には、運動自体の理想ではなく、組織者の収入と豪邸だけが実質的な利益を得ています。死者を消費してこれほど大きな利益を得られるのは、この種の資本主義国だけです。口では正義を唱え、すべてがビジネスです。

彼らの収入はKubernetesプロジェクトとは全く関係がありません。それは私に中学・高校時代の寄生虫のような同級生を思い出させます。彼らは自分の目的を達成するためにあなたのリソースを浪費することしか考えていません。

以前の https://github.com/tailwindlabs/tailwindcss のように。現在のLLM支援プログラミングツールは、ユーザーがドキュメントを読まなくても、直接自分のプロジェクトに統合できます。https://github.com/zeusro/tool この私のプロジェクトは、Cursorを使用してtailwindcssを統合したものです。

正直に言うと、これは私に少しぞっとする感覚を与えます。一方で、開発者は真面目に働き、プロジェクトのスターはますます増え、ユーザーも増え続けています。しかし、現実の一面は、これらの仮想の称賛は、チームの日常的な支出をカバーできず、基本的な生存さえ問題になるということです。

私の考え

私は2020年に、Kubernetesプロジェクトは実際には中国人とは何の関係もないことを認識しました。プロジェクトの主な発起人はGoogle Cloudの人々なので、あなたの仕事関係がGoogle Cloudに属していない場合、基本的に彼らはあなたのpull requestを受け入れません。これが、LGBTのバナーがkubernetes/websiteプロジェクトに現れた理由を完璧に説明しています。

CRDはKubernetesのリソースであり、CRとcontrollerはCRDの下流です。したがって、サードパーティ（openkruise）が実装したdeployment、StatefulSet、DaemonSetコントローラーがどれほど優れていても、これらを上流のKubernetesにマージすることは、おそらく私たちの生涯では見られないでしょう。

私はすでにKubernetes組織によってブラックリストに登録されていますが、どうでもいいです。

国内の開発者として、私は皆が実際に一つの問題を考えるべきだと思います：もし私たちが常に救世主の到来を待ってから行動を起こすなら、この世界には神や皇帝が存在せず、いわゆる救世主も存在しない可能性はないでしょうか？

私たちは常に模倣者の受動的な思考に陥り、最初のカニを食べることを望みません。代わりに、プロジェクトが成熟するまで待ってから、一杯のスープを分けてもらおうと考えますが、彼らは単に私たちを遊びに連れて行きません。

オープンソース世界の政治的闘争は、私たちが想像するよりもはるかに残酷です。平和と開放の下には、実際に暗流が渦巻いています。

個人開発者やスタートアップチームが開発したオープンソースプロジェクトについては、実際には何も意見を述べません。気に入らなければ使わなければいいです。結局のところ、彼らが開発に時間を費やすことはすでに非常に困難です。しかし、上場企業の背景を持つ組織については、視野を長期的に保ち、まず姿勢を低くし、国内の臨時チームや中小企業が大多数を占める状況に基づいてまず自分自身を確立し、プロジェクトの目的の対象顧客グループを明確に考えるべきだと思います。

百万ドルの年俸を一日中持っていながら、意味のないコードを書き、リソース使用のROIと限界利益を、ゼロコストショッピングが好きな小さなボスに説明することさえできないのではなく。

Yellow Lives Matter

Kubernetesが変わらないなら、私がKubernetesを変えます。

私は https://github.com/p-program/kube-killer と https://github.com/Z-Nightmare/kuberneteskuberneteskubernetes を起点として、グローバルインターネットで Yellow Lives Matter運動を開始し、Kubernetes組織の国籍差別と道徳的偏見に抗議することを決定しました。

“The old is dying and the new cannot be born; in this interregnum a great variety of morbid symptoms appear.”

Как политкорректность разрушила сообщество открытого исходного кода

❌master ✅ main

master/slave — это давно существующая архитектура «мастер-подчиненный» в вычислительной технике. Благодаря разделению мастера и подчиненного достигаются распределенное чтение и отказоустойчивость. Однако во время движения Black Lives Matter GitHub в июне 2020 года объявил о планах против использования терминов, которые могут ассоциироваться с рабством, и 1 октября 2020 года имя ветки по умолчанию для новых репозиториев было изменено на «main».

Моральная полиция

Основным проявлением политкорректности в сообществе открытого исходного кода являются различные моральные полицейские. Многие китайские разработчики используют свое ограниченное время для разработки программного обеспечения с открытым исходным кодом, но в результате их проекты захватываются различными проблемами, постоянно разбираясь с «глупыми вопросами» о глупых проблемах. Например, как установить это программное обеспечение, как исправить ошибки, когда что-то идет не так.

У них даже нет времени посмотреть, откуда начинается трассировка стека ошибок, всегда считая само собой разумеющимся тратить время других. Затем они относятся к бескорыстному вкладу других как к «духу открытого исходного кода».

Или они приносят совершенно не связанные идеологии в сообщество открытого исходного кода, такие как ЛГБТ.

Популярность ЛГБТ‑культуры в сообществе открытого исходного кода, на мой взгляд, является историческим регрессом. Это похоже на китайских феминисток‑боевиков, которые пользуются гендерным преимуществом — мужчин больше, чем женщин — чтобы делать всевозможные запредельные заявления.

Но если разобрать их теоретическую основу, там сплошная черная дыра. Их конечные требования сводятся к тому, чтобы перед браком выжать побольше денег, в браке не дать второй стороне вывести активы, после развода поделить имущество пополам, либо придираться к мелочам (например, требовать от других бережного отношения к экологии, при этом самим постоянно выбрасывая еду) и через разные «проверки чувств» выкачивать из партнера эмоциональную выгоду. В этом отношении Китай и Запад достигли поразительного единства.

Black Lives Matter & LLM-паразиты

Моральная полиция была особенно заметна во время движения Black Lives Matter. Я помню, что в конце 2020 года при просмотре веб-документации Kubernetes внезапно появилась реклама поддержки BLM.

Изучая историю, это было добавлено #25173 https://github.com/kubernetes/website/pull/25173/files. Но позже, 8 января 2021 года, https://github.com/kubernetes/website/pull/25769, это было удалено, и причина удаления была очень расплывчатой, как будто этого никогда не существовало.

Patrisse Cullors, соучредитель движения BLM, ушла с поста исполнительного директора BLMGNF в 2021 году. Налоговые документы показали, что она не получала зарплату в течение финансового года, а работала «неоплачиваемым волонтером». Однако ее связанные компании и члены семьи получили большие суммы денег: компания ее брата Paul Cullors (Cullors Protection или Black Ties LLC) получила примерно 840 000 долларов за «профессиональные охранные услуги» (налоговые документы 2022 года). Общий доход с 2021 года превысил 4,2 миллиона долларов.

Cullors также обвинялась в использовании фонда для покупки особняка в Лос-Анджелесе стоимостью примерно 6 миллионов долларов для «черного творческого пространства».

Компания другого соучредителя и члена правления Shalomyah Bowers получила 2,1 миллиона долларов консультационных сборов.

Компания бывшего члена правления Raymond Howard и его сестры получила примерно 1,1 миллиона долларов.

Два бывших сотрудника получили расчетные выплаты: один бывший член правления 400 000 долларов, другой 335 000 долларов (2023).

Со временем мы обнаружили, что те, кто поддерживал это движение, были настоящими клоунами. За движением BLM единственными, кто действительно получил выгоду, были доходы и особняки организаторов, а не идеалы самого движения. Возможность обменять потребление мертвых на такие большие выгоды — это то, что может достичь только такой капиталистический режим. Все разговоры о справедливости, все — это бизнес.

Их доход не имеет ничего общего с проектом Kubernetes. Это напоминает мне тех паразитических одноклассников в средней и старшей школе, которые думают только о том, чтобы тратить ваши ресурсы для достижения своих целей.

Это как предыдущий https://github.com/tailwindlabs/tailwindcss. Текущие инструменты программирования с поддержкой LLM могут интегрироваться в проекты пользователей, даже не читая документацию. https://github.com/zeusro/tool Этот мой проект интегрирует tailwindcss с помощью Cursor.

Честно говоря, это меня немного пугает. С одной стороны, разработчики усердно работают, проекты получают все больше и больше звезд, и пользователи продолжают расти; однако реальность такова, что эти виртуальные похвалы не могут покрыть ежедневные расходы команды, и даже базовое выживание становится проблемой.

Мои мысли

Я понял еще в 2020 году, что проект Kubernetes на самом деле не имеет ничего общего с китайцами. Основные инициаторы проекта — люди из Google Cloud, поэтому, если ваши рабочие отношения не принадлежат Google Cloud, они в основном не примут ваши pull request. Это прекрасно объясняет, почему баннер ЛГБТ появился в проекте kubernetes/website.

CRD — это ресурс Kubernetes, а CR и controller — это нижестоящие от CRD. Поэтому, независимо от того, насколько хороши контроллеры deployment, StatefulSet и DaemonSet, реализованные третьими сторонами (openkruise), слияние их вверх по течению в Kubernetes, вероятно, никогда не произойдет в нашей жизни.

Я сам давно в черном списке организации Kubernetes, но мне все равно.

Как отечественный разработчик, я думаю, что все должны подумать о вопросе: если мы всегда ждем прихода спасителя, прежде чем действовать, то возможно ли, что в этом мире никогда не было никаких богов или императоров, и нет так называемого спасителя?

Мы всегда впадаем в пассивное мышление подражателей, не желая быть первыми, кто съест краба. Вместо этого мы ждем, пока проект созреет, прежде чем думать о том, чтобы получить кусок пирога, но они просто не играют с нами.

Политическая борьба в мире открытого исходного кода гораздо более жестока, чем мы представляем. Под миром и открытостью на самом деле бурлят подводные течения.

Что касается проектов с открытым исходным кодом, разработанных отдельными лицами и стартап-командами, я на самом деле не буду делать никаких комментариев — если вам не нравится, не используйте. В конце концов, им уже довольно сложно тратить время на разработку; но для подразделений с фоном публичных компаний я думаю, что видение должно быть более долгосрочным, поза должна быть сначала ниже, и они должны сначала утвердиться на основе ситуации, когда отечественные импровизированные команды и малые и микропредприятия составляют большинство, и четко подумать о целевой группе клиентов для цели проекта.

А не держать миллионные годовые зарплаты весь день, писать код, который не имеет смысла, не в состоянии даже объяснить ROI использования ресурсов и предельную выгоду мелким боссам, которые любят бесплатные покупки.

White Lives Matter

Если Kubernetes не изменится, то я изменю Kubernetes.

Я решил использовать https://github.com/p-program/kube-killer и https://github.com/Z-Nightmare/kuberneteskuberneteskubernetes в качестве отправных точек для запуска движения White Lives Matter в глобальном интернете, протестуя против национальной дискриминации и моральной предвзятости организации Kubernetes.

“The old is dying and the new cannot be born; in this interregnum a great variety of morbid symptoms appear.”

GitHub Discussions：开源项目的社区交流新方式

Mon, 19 Jan 2026 00:00:00 +0000

什么是 GitHub Discussions？

GitHub Discussions 是 GitHub 在 2020 年推出的一个功能，它为开源项目提供了一个全新的社区交流平台。与传统的 Issues 和 Pull Requests 不同，Discussions 更像是一个论坛，允许用户进行更自由、更开放的讨论。

为什么需要 Discussions？

在传统的开源项目协作中，我们主要使用：

Issues：用于报告 bug、提出功能请求
Pull Requests：用于代码贡献和审查

但这些工具更适合处理具体的技术问题。对于以下场景，Discussions 更加合适：

项目发展方向讨论
使用经验分享
最佳实践交流
社区问答
项目公告

Discussions 的主要特性

1. 分类管理

Discussions 支持多种分类：

📣 Announcements（公告）：项目重要通知
💬 General（一般讨论）：日常交流
💡 Ideas（想法）：功能建议和创意
🗳️ Polls（投票）：社区决策
🙏 Q&A（问答）：问题解答
🙌 Show and tell（展示）：项目展示

2. 更灵活的交流方式

支持 Markdown 格式
可以 @ 提及用户
支持表情符号
可以标记为已回答/未回答
支持置顶重要讨论

3. 与 Issues 的集成

Discussions 可以与 Issues 无缝集成，可以将讨论转换为 Issue，也可以从 Issue 创建讨论。

我的项目实践

最近我在 Zeusro.github.io 项目中开启了 Discussions 功能。这个项目是我的个人博客，使用 Jekyll 构建并托管在 GitHub Pages 上。

开启 Discussions 后，我发现它非常适合：

分享博客写作经验
讨论技术话题
收集读者反馈
发布项目更新公告

如何开启 Discussions？

进入你的 GitHub 仓库
点击 Settings（设置）
在左侧菜单中找到 General → Features
勾选 Discussions 选项
保存设置

开启后，你可以在仓库主页看到新的 Discussions 标签页。

最佳实践建议

明确分类：为不同类型的讨论设置合适的分类
及时回复：保持活跃的社区氛围
置顶重要信息：将重要公告置顶
引导讨论：鼓励社区成员参与讨论
定期整理：将有价值的讨论整理成文档

总结

GitHub Discussions 为开源项目提供了一个更加开放和友好的交流平台。它补充了 Issues 和 Pull Requests 的不足，让社区交流变得更加轻松自然。如果你正在维护一个开源项目，不妨试试开启 Discussions 功能，它可能会为你的项目带来意想不到的活力。

本文由 AI 生成

What is GitHub Discussions?

GitHub Discussions is a feature launched by GitHub in 2020 that provides a new community communication platform for open source projects. Unlike traditional Issues and Pull Requests, Discussions is more like a forum, allowing users to have more free and open discussions.

Why Do We Need Discussions?

In traditional open source project collaboration, we mainly use:

Issues: For reporting bugs and proposing feature requests
Pull Requests: For code contributions and reviews

However, these tools are more suitable for handling specific technical problems. Discussions is more appropriate for the following scenarios:

Project direction discussions
Experience sharing
Best practices exchange
Community Q&A
Project announcements

Key Features of Discussions

1. Category Management

Discussions supports multiple categories:

📣 Announcements: Important project notifications
💬 General: Daily communication
💡 Ideas: Feature suggestions and creativity
🗳️ Polls: Community decisions
🙏 Q&A: Question and answer
🙌 Show and tell: Project showcases

2. More Flexible Communication

Supports Markdown format
Can @ mention users
Supports emoji
Can be marked as answered/unanswered
Supports pinning important discussions

3. Integration with Issues

Discussions can be seamlessly integrated with Issues. You can convert discussions to Issues, or create discussions from Issues.

My Project Practice

Recently, I enabled the Discussions feature in my Zeusro.github.io project. This project is my personal blog, built with Jekyll and hosted on GitHub Pages.

After enabling Discussions, I found it very suitable for:

Sharing blog writing experiences
Discussing technical topics
Collecting reader feedback
Publishing project update announcements

How to Enable Discussions?

Go to your GitHub repository
Click Settings
Find General → Features in the left menu
Check the Discussions option
Save settings

After enabling, you can see the new Discussions tab on your repository homepage.

Best Practice Recommendations

Clear Categories: Set appropriate categories for different types of discussions
Timely Responses: Maintain an active community atmosphere
Pin Important Information: Pin important announcements
Guide Discussions: Encourage community members to participate
Regular Organization: Organize valuable discussions into documentation

Conclusion

GitHub Discussions provides a more open and friendly communication platform for open source projects. It complements the shortcomings of Issues and Pull Requests, making community communication more relaxed and natural. If you are maintaining an open source project, you might want to try enabling the Discussions feature—it may bring unexpected vitality to your project.

This article was generated by AI

GitHub Discussionsとは？

GitHub Discussionsは、GitHubが2020年にリリースした機能で、オープンソースプロジェクトに新しいコミュニティ交流プラットフォームを提供します。従来のIssuesやPull Requestsとは異なり、Discussionsはよりフォーラムに近く、ユーザーがより自由でオープンな議論を行うことができます。

なぜDiscussionsが必要なのか？

従来のオープンソースプロジェクトの協力では、主に以下を使用します：

Issues：バグの報告や機能リクエストに使用
Pull Requests：コードの貢献とレビューに使用

しかし、これらのツールは具体的な技術的な問題を処理するのに適しています。以下のシナリオでは、Discussionsがより適切です：

プロジェクトの方向性の議論
使用経験の共有
ベストプラクティスの交流
コミュニティのQ&A
プロジェクトの告知

Discussionsの主な機能

1. カテゴリ管理

Discussionsは複数のカテゴリをサポートします：

📣 Announcements（告知）：プロジェクトの重要な通知
💬 General（一般討論）：日常的な交流
💡 Ideas（アイデア）：機能提案と創造性
🗳️ Polls（投票）：コミュニティの意思決定
🙏 Q&A（質問と回答）：質問への回答
🙌 Show and tell（展示）：プロジェクトの展示

2. より柔軟な交流方法

Markdown形式をサポート
ユーザーを@メンション可能
絵文字をサポート
回答済み/未回答としてマーク可能
重要な議論をピン留め可能

3. Issuesとの統合

DiscussionsはIssuesとシームレスに統合でき、議論をIssueに変換したり、Issueから議論を作成したりできます。

私のプロジェクト実践

最近、Zeusro.github.ioプロジェクトでDiscussions機能を有効にしました。このプロジェクトは私の個人ブログで、Jekyllで構築され、GitHub Pagesでホストされています。

Discussionsを有効にした後、以下の用途に非常に適していることがわかりました：

ブログ執筆経験の共有
技術トピックの議論
読者のフィードバックの収集
プロジェクト更新の告知

Discussionsを有効にする方法

GitHubリポジトリに移動
Settings（設定）をクリック
左メニューでGeneral → Featuresを見つける
Discussionsオプションにチェックを入れる
設定を保存

有効にすると、リポジトリのホームページに新しいDiscussionsタブが表示されます。

ベストプラクティスの推奨事項

明確なカテゴリ：異なるタイプの議論に適切なカテゴリを設定
迅速な返信：活発なコミュニティの雰囲気を維持
重要な情報をピン留め：重要な告知をピン留め
議論を導く：コミュニティメンバーの参加を奨励
定期的な整理：価値のある議論をドキュメントに整理

まとめ

GitHub Discussionsは、オープンソースプロジェクトに、よりオープンで友好的な交流プラットフォームを提供します。IssuesやPull Requestsの不足を補完し、コミュニティの交流をよりリラックスして自然なものにします。オープンソースプロジェクトを維持している場合は、Discussions機能を有効にしてみることをお勧めします。プロジェクトに予想外の活力をもたらすかもしれません。

この記事はAIによって生成されました

Что такое GitHub Discussions?

GitHub Discussions — это функция, запущенная GitHub в 2020 году, которая предоставляет новую платформу для общения сообщества в проектах с открытым исходным кодом. В отличие от традиционных Issues и Pull Requests, Discussions больше похож на форум, позволяя пользователям вести более свободные и открытые обсуждения.

Зачем нужны Discussions?

В традиционном сотрудничестве в проектах с открытым исходным кодом мы в основном используем:

Issues: Для сообщения об ошибках и предложения функций
Pull Requests: Для вклада в код и обзоров

Однако эти инструменты больше подходят для решения конкретных технических проблем. Для следующих сценариев Discussions более подходят:

Обсуждение направления развития проекта
Обмен опытом использования
Обмен лучшими практиками
Вопросы и ответы сообщества
Объявления проекта

Основные функции Discussions

1. Управление категориями

Discussions поддерживает несколько категорий:

📣 Announcements (Объявления): Важные уведомления проекта
💬 General (Общие): Ежедневное общение
💡 Ideas (Идеи): Предложения функций и творчество
🗳️ Polls (Опросы): Решения сообщества
🙏 Q&A (Вопросы и ответы): Ответы на вопросы
🙌 Show and tell (Показ): Демонстрация проектов

2. Более гибкое общение

Поддержка формата Markdown
Можно упоминать пользователей через @
Поддержка эмодзи
Можно отмечать как отвеченные/неотвеченные
Поддержка закрепления важных обсуждений

3. Интеграция с Issues

Discussions может быть бесшовно интегрирован с Issues. Можно преобразовать обсуждения в Issues или создать обсуждения из Issues.

Моя практика проекта

Недавно я включил функцию Discussions в моем проекте Zeusro.github.io. Этот проект — мой личный блог, созданный с помощью Jekyll и размещенный на GitHub Pages.

После включения Discussions я обнаружил, что он очень подходит для:

Обмена опытом написания блога
Обсуждения технических тем
Сбора отзывов читателей
Публикации объявлений об обновлениях проекта

Как включить Discussions?

Перейдите в ваш репозиторий GitHub
Нажмите Settings (Настройки)
Найдите General → Features в левом меню
Установите флажок Discussions
Сохраните настройки

После включения вы можете увидеть новую вкладку Discussions на главной странице вашего репозитория.

Заключение

GitHub Discussions предоставляет более открытую и дружелюбную платформу для общения в проектах с открытым исходным кодом. Он дополняет недостатки Issues и Pull Requests, делая общение в сообществе более расслабленным и естественным. Если вы поддерживаете проект с открытым исходным кодом, возможно, стоит попробовать включить функцию Discussions — она может принести неожиданную жизненную силу вашему проекту.

Эта статья была сгенерирована ИИ

Unknown

golang的问题

零值陷阱

弱网问题

兼容性问题

golang的不向前兼容

window不适合golang开发

选择编译缺失

后记

Zero-value traps

Weak networks

Compatibility

When golang is not forward-compatible

window is a bad fit for golang

No selective compilation

Postscript

ゼロ値の罠

弱いネットワーク

互換性

golangが前方互換でない例

windowはgolang開発に向かない

選択的コンパイルの欠如

あとがき

Ловушки нулевых значений

Слабая сеть

Совместимость

Когда golang не совместим вперёд

window плохо подходит под golang

Нет условной компиляции в стиле препроцессора

Постскриптум

不幂等电梯与P=NP中的分家产问题

不幂等电梯

个体自私导致群体延误

P=NP中的分家产问题

近水楼台先得月

Non-idempotent Elevator

Individual selfishness causes collective delay

The estate division problem in P=NP

Nearby advantage

非冪等エレベーター

個人の利己性が集団遅延を生む

P=NPにおける遺産分割問題

近くの楼台は先に月を得る

Неидемпотентный лифт

Индивидуальный эгоизм приводит к задержкам для группы

Проблема раздела наследства в P=NP

Кто ближе, тот и первым

中国Windows系统使用多个版本的go

卡点

One more thing

db_basic.go

db_cloud.go

main.go

参考链接

Sticking points

One more thing

db_basic.go

db_cloud.go

main.go

References

つまずき

One more thing

db_basic.go

db_cloud.go

main.go

参考リンク

Где застреваешь

One more thing

db_basic.go

db_cloud.go

main.go

Ссылки

打通智能家居数据流动的上下游

数据堰塞湖

上下文丢失

意念编程（Spec Coding）与主动陪伴（Active Companionship）

Data Barrier Lake

Context Loss

Spec Coding and Active Companionship

データ堰塞湖（Data Barrier Lake）

When `golang` is not forward-compatible

`window` is a bad fit for `golang`

`golang`が前方互換でない例

`window`は`golang`開発に向かない

Когда `golang` не совместим вперёд

`window` плохо подходит под `golang`