Unknown

信息技术的熵减定律

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 — она может принести неожиданную жизненную силу вашему проекту.

Эта статья была сгенерирована ИИ

把2014年B站的返回顶点锚点扒了下来

Tue, 13 Jan 2026 00:00:00 +0000

2014-05-03 去把bilibili的返回顶点锚点扒了下来

今天闲来无事看着刷着bilibili对那锚点标记觊觎已久，下决心将其收为己用，遂动手。

个人主推Firefox+firebug查看网页代码。我用的是夜壶(nightly)，就火狐的每日更新版(建议不用，有时一日三更重启非常蛋疼).

网页代码，css和图片容易弄，哪里想要点哪里，左边是代码，右边是css和其他，背景图的话，右键路径在新页面打开保存就行。

主要是绑定的javascript事件麻烦。楼主一开始傻BB就对着那个锚点的divid找啊找，找到了一些但死活找不到事件。后来firebug会用了就简单多了。点击标签绑定的是goTop函数，在firebug的控制栏里输入”goTop”，然后点”RUN”，那个函数就会出现了，找到之后还可以右键美化源代码，方便复制过去。输”goTop()”的话是执行。不一样的。

bilibili的锚点是挺有趣的，首先其位置设置的不错，会根据元素在当前视口的相对偏移设置，其次是它让人流氓滚，在点了页面开始调用函数之后一旦你往下滚轮它还是会用生命滚到页首，直到完全触顶为止。

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title></title>
    <script src="../Scripts/jquery-1.10.2.min.js"></script>
    <script>
        $(function () {
            $('body').append('<div id="gotop" onclick="goTop();"></div>');
            $(window).scroll(function () {
                300 < $(this).scrollTop() ?
                ($('#gotop').show(),
                $('#gotop').css('left', $('.z').offset().left + $('.z').width() + 20),
                $('#gotop').css('top', $(window).height() - 300))
                : $('#gotop').hide()
            });
            $(window).resize(function () {
                $('#gotop').css('left', $('.z').offset().left + $('.z').width() + 20)
            })
        });
        function goTop(u, t, r) {
            var scrollActivate = !0;
            if (scrollActivate) {
                u = u || 0.1;
                t = t || 16;
                var s = 0,
                q = 0,
                o = 0,
                p = 0,
                n = 0,
                j = 0;
                document.documentElement && (s = document.documentElement.scrollLeft || 0, q = document.documentElement.scrollTop || 0);
                document.body && (o = document.body.scrollLeft || 0, p = document.body.scrollTop || 0);
                n = window.scrollX || 0;
                j = window.scrollY || 0;
                s = Math.max(s, Math.max(o, n));
                q = Math.max(q, Math.max(p, j));
                p = 1 + u;
                window.scrollTo(Math.floor(s / p), Math.floor(q / p));
                0 < s || 0 < q ? window.setTimeout('goTop(' + u + ', ' + t + ')', t) : 'undefined' != typeof r && r()
            } else {
                scrollActivate = !0
            }
        }
    </script>
    <style>
        #gotop:hover {
            background-position: 0px -116px;
        }
        #gotop {
            width: 29px;
            height: 106px;
            position: fixed;
            display: none;
            cursor: pointer;
            background: url('go_to_top.png') no-repeat scroll 0px 0px transparent;
        }
    </style>
</head>
<body>
    <div class="z" style="border: 1px dashed; height: 2999px; width: 977px; margin: 0 auto;">
    </div>
</body>
</html>

2015-04-26 博客园，你们家的js好神奇

2015-04-26 为你的博客园添加平滑移动到页面顶端的锚点和tag云

首先我的目录是在marvin的基础上二次开发的。然后我发现锚点图和目录都在同一个图上面，所以就一起用了。

返回顶部锚点:

我用以前旧版bilibili的那个函数。可以做到平滑滚动到页面，并且在触顶前不能向下滚屏。具体的看我参考链接。当然因为涉及到js要申请权限，简单的话a标签href用#top当然可以，体验有点差罢了。

然后因为我懒，锚点的出现条件直接和目录的出现条件弄在一起。也就是匹配元素相对滚动条顶部的偏移超过200时显示。

tag云:

我用Google随便找的。用的矢量绘图。

但是这玩意有个局限性，就是其实例化函数限制要用元素ID.于是我用一个div包裹了标签区的ul.然后实例化。实例化成功的时候隐藏掉标签区和标题，设置canvas的蠕动和显示

window.onload=function(){                      
    $("ul:first","#sidebar_categories").wrap("<div id='caonimagebi' style='display:block'></div>")  
    if(!$('#myCanvas').tagcanvas({
          textColour: '#519cea',
          outlineColour: '#404040',
          reverse: true,
          depth: 0.8,
          maxSpeed: 0.10
        },'caonimagebi')) {
          console.log("日了狗了")
          $('#myCanvasContainer').hide(); 
        }
        else{
            $('#myCanvasContainer').css('display', 'block');    
            $('#myCanvas').tagcanvas("setspeed", [0.015, -0.05]);        
             $('#caonimagebi').css('display', 'none');                    
              $('.catListTitle:first-child','#sidebar_categories').empty();//去掉随笔分类  
        }   
               }

但是这样有个局限性，就是因为写在onload里面，有点生硬，你们可以看到，这玩意像是隐搞出来的，不和谐。这就是让我抓狂的地方了。

抓狂:

我就是很好奇，为毛这个包裹方法写在onready里面就不行了，而且是线上的时候不行。我是有在本地测试的，本地写在onready的时候页面很正常，传到博客园就变成这样。

博客园，你们家的js好神奇

备注:

1博客园的文件系统是软删除，慢更新。就是你删了文件还在，你删了那个文件上传同名文件的话，服务器上的文件还是旧版的，所以需要自己手动修改文件名和相应的引用文件名。

2这个目录有一定的局限性，也就是h2,h3,h4.方法写的不是很健壮，而且目录的高度应该尽可能的根据标题数来计算，然后弄个上限，但是我也懒得改了。还有就是z-index的问题。这个要格外注意下。我是把旁边的锚点和返回顶部设置为999了。

3博客园自带jQuery.所以无需另外引用

2026-01-13 备注

原文是我在博客园的2篇文章和1个问答，我用爬虫扒了下来，并稍微修改了一下。

2015-04-26 19:41 为你的博客园添加平滑移动到页面顶端的锚点和tag云 https://www.cnblogs.com/zeusro/p/4458222.html

2014-05-03 18:58 去把bilibili的返回顶点锚点扒了下来 https://www.cnblogs.com/zeusro/p/3705426.html

现在B站的返回顶点锚点还不如10年前。我已经把它移植到我这个项目中。

提交链接是 247c0101d65b9c580fadc40db32165d2ef84fe07。AI还顺便修复了jQuery的问题，也是神奇了。

Chrome 截图脚本

使用 Chrome 的 --headless=new 模式进行全页面截图：

$url = "https://q.cnblogs.com/q/71564"
$outputPath = "D:\Zeusro.github.io\img\in-post\bilibili\cnblogs-71564.png"
$chromePath = "C:\Program Files\Google\Chrome\Application\chrome.exe"

& $chromePath --headless=new --disable-gpu --window-size=1280,2000 --virtual-time-budget=10000 --screenshot=$outputPath $url

参数说明：

--headless=new: 使用新的无头模式
--disable-gpu: 禁用 GPU 加速
--window-size=1280,2000: 设置窗口大小为 1280x2000 像素，足够大的高度可以捕获完整页面
--virtual-time-budget=10000: 给页面 10 秒的虚拟时间预算，确保所有内容都加载完成
--screenshot=$outputPath: 指定截图保存路径

参考链接:

去把bilibili的返回顶点锚点扒了下来

如何给你的为知笔记添加一个漂亮的导航目录

http://www.goat1000.com/tagcanvas-functions.php

2014-05-03 Scraping Bilibili’s Back-to-Top Anchor

Today I was idly browsing Bilibili and had been eyeing that anchor mark for a long time. I decided to make it my own, so I got to work.

I mainly use Firefox + Firebug to inspect webpage code. I’m using Nightly, Firefox’s daily update version (not recommended, sometimes it updates three times a day and restarts are very annoying).

Webpage code, CSS, and images are easy to get. Just click where you want, left side shows code, right side shows CSS and other stuff. For background images, right-click the path and open it in a new page to save.

The main trouble was the bound JavaScript events. I was initially stupidly searching for the anchor’s div id, found some things but couldn’t find the event. Later, when I learned to use Firebug properly, it became much easier. The click tag is bound to the goTop function. In Firebug’s console, type “goTop”, then click “RUN”, and the function will appear. After finding it, you can right-click to beautify the source code for easy copying. Typing “goTop()” executes it. It’s different.

Bilibili’s anchor is quite interesting. First, its position is set well, adjusting based on the element’s relative offset in the current viewport. Second, it forces scrolling - after clicking and the function starts, even if you scroll down, it will still scroll to the top with all its might until it fully reaches the top.

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title></title>
    <script src="../Scripts/jquery-1.10.2.min.js"></script>
    <script>
        $(function () {
            $('body').append('<div id="gotop" onclick="goTop();"></div>');
            $(window).scroll(function () {
                300 < $(this).scrollTop() ?
                ($('#gotop').show(),
                $('#gotop').css('left', $('.z').offset().left + $('.z').width() + 20),
                $('#gotop').css('top', $(window).height() - 300))
                : $('#gotop').hide()
            });
            $(window).resize(function () {
                $('#gotop').css('left', $('.z').offset().left + $('.z').width() + 20)
            })
        });
        function goTop(u, t, r) {
            var scrollActivate = !0;
            if (scrollActivate) {
                u = u || 0.1;
                t = t || 16;
                var s = 0,
                q = 0,
                o = 0,
                p = 0,
                n = 0,
                j = 0;
                document.documentElement && (s = document.documentElement.scrollLeft || 0, q = document.documentElement.scrollTop || 0);
                document.body && (o = document.body.scrollLeft || 0, p = document.body.scrollTop || 0);
                n = window.scrollX || 0;
                j = window.scrollY || 0;
                s = Math.max(s, Math.max(o, n));
                q = Math.max(q, Math.max(p, j));
                p = 1 + u;
                window.scrollTo(Math.floor(s / p), Math.floor(q / p));
                0 < s || 0 < q ? window.setTimeout('goTop(' + u + ', ' + t + ')', t) : 'undefined' != typeof r && r()
            } else {
                scrollActivate = !0
            }
        }
    </script>
    <style>
        #gotop:hover {
            background-position: 0px -116px;
        }
        #gotop {
            width: 29px;
            height: 106px;
            position: fixed;
            display: none;
            cursor: pointer;
            background: url('go_to_top.png') no-repeat scroll 0px 0px transparent;
        }
    </style>
</head>
<body>
    <div class="z" style="border: 1px dashed; height: 2999px; width: 977px; margin: 0 auto;">
    </div>
</body>
</html>

2015-04-26 CNBlogs, Your JavaScript is Amazing

First, my table of contents is based on marvin’s work, which I further developed. Then I found that the anchor image and table of contents are on the same image, so I used them together.

Back-to-Top Anchor:

I used the function from the old Bilibili version. It can smoothly scroll to the page top, and prevents scrolling down before reaching the top. See my reference link for details. Of course, since it involves JavaScript that requires permissions, you can simply use an anchor tag with href=”#top”, but the experience is a bit poor.

Then because I’m lazy, I made the anchor’s appearance condition the same as the table of contents. That is, it shows when the matched element’s offset relative to the scrollbar top exceeds 200.

I found it randomly on Google. Uses vector graphics.

But this thing has a limitation - its instantiation function requires an element ID. So I wrapped the tag area’s ul with a div, then instantiated it. When instantiation succeeds, hide the tag area and title, set the canvas animation and display.

window.onload=function(){                      
    $("ul:first","#sidebar_categories").wrap("<div id='caonimagebi' style='display:block'></div>")  
    if(!$('#myCanvas').tagcanvas({
          textColour: '#519cea',
          outlineColour: '#404040',
          reverse: true,
          depth: 0.8,
          maxSpeed: 0.10
        },'caonimagebi')) {
          console.log("Damn it")
          $('#myCanvasContainer').hide(); 
        }
        else{
            $('#myCanvasContainer').css('display', 'block');    
            $('#myCanvas').tagcanvas("setspeed", [0.015, -0.05]);        
             $('#caonimagebi').css('display', 'none');                    
              $('.catListTitle:first-child','#sidebar_categories').empty();//Remove essay categories  
        }   
               }

But this has a limitation - because it’s written in onload, it’s a bit abrupt. You can see this thing appears like it was hidden, not harmonious. This is what drives me crazy.

Going Crazy:

I’m just very curious why this wrapping method doesn’t work when written in onready, and it only fails online. I did test locally, and when written in onready locally, the page works normally, but when uploaded to CNBlogs it becomes like this.

CNBlogs, Your JavaScript is Amazing

Notes:

CNBlogs’ file system is soft delete, slow update. That is, when you delete a file it’s still there. If you delete a file and upload a file with the same name, the server file is still the old version, so you need to manually change the filename and the corresponding reference filename.
This table of contents has certain limitations, namely h2, h3, h4. The method isn’t written very robustly, and the table of contents height should be calculated based on the number of headings as much as possible, then set an upper limit, but I’m too lazy to change it. Also, there’s the z-index issue. This needs special attention. I set the anchor and back-to-top next to it to 999.
CNBlogs comes with jQuery built-in, so no need to reference it separately.

2026-01-13 Notes

The original text consists of 2 articles and 1 Q&A from my CNBlogs, which I scraped and slightly modified.

2015-04-26 19:41 Adding Smooth Scroll-to-Top Anchor and Tag Cloud to Your CNBlogs https://www.cnblogs.com/zeusro/p/4458222.html

2014-05-03 18:58 Scraping Bilibili’s Back-to-Top Anchor https://www.cnblogs.com/zeusro/p/3705426.html

Now Bilibili’s back-to-top anchor is worse than 10 years ago. I’ve already ported it to this project.

The commit link is 247c0101d65b9c580fadc40db32165d2ef84fe07. AI also fixed the jQuery issue, which is also amazing.

Chrome Screenshot Script

Using Chrome’s --headless=new mode for full-page screenshots:

$url = "https://q.cnblogs.com/q/71564"
$outputPath = "D:\Zeusro.github.io\img\in-post\bilibili\cnblogs-71564.png"
$chromePath = "C:\Program Files\Google\Chrome\Application\chrome.exe"

& $chromePath --headless=new --disable-gpu --window-size=1280,2000 --virtual-time-budget=10000 --screenshot=$outputPath $url

Parameter explanation:

--headless=new: Use the new headless mode
--disable-gpu: Disable GPU acceleration
--window-size=1280,2000: Set window size to 1280x2000 pixels, large enough height to capture the full page
--virtual-time-budget=10000: Give the page 10 seconds of virtual time budget to ensure all content is loaded
--screenshot=$outputPath: Specify the screenshot save path

References:

Scraping Bilibili’s Back-to-Top Anchor

How to Add a Beautiful Navigation Table of Contents to Your WizNote

http://www.goat1000.com/tagcanvas-functions.php

2014-05-03 Bilibiliのトップへ戻るアンカーを取得

今日は何もすることがなく、Bilibiliをブラウジングしていて、そのアンカーマークをずっと狙っていました。決心して自分のものにしようと、作業を始めました。

個人的にはFirefox + Firebugでウェブページのコードを確認することを推奨しています。私は夜間版（nightly）を使用しています。これはFirefoxの毎日更新版です（推奨しません。時々1日に3回更新して再起動が必要で非常に面倒です）。

ウェブページのコード、CSS、画像は簡単に取得できます。欲しい場所をクリックするだけで、左側にコード、右側にCSSやその他の情報が表示されます。背景画像の場合は、パスを右クリックして新しいページで開いて保存すればOKです。

主な問題は、バインドされたJavaScriptイベントでした。最初はアンカーのdiv idを探していましたが、いくつか見つかったものの、イベントが見つかりませんでした。後でFirebugの使い方がわかると、ずっと簡単になりました。クリックタグはgoTop関数にバインドされています。Firebugのコンソールで「goTop」と入力し、「RUN」をクリックすると、その関数が表示されます。見つけた後、右クリックしてソースコードを整形し、コピーしやすくできます。「goTop()」と入力すると実行されます。違います。

Bilibiliのアンカーは非常に興味深いです。まず、その位置設定が優れており、現在のビューポート内の要素の相対オフセットに基づいて設定されます。次に、強制的にスクロールさせます。ページをクリックして関数が開始された後、下にスクロールしても、完全にトップに到達するまで全力でトップまでスクロールし続けます。

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title></title>
    <script src="../Scripts/jquery-1.10.2.min.js"></script>
    <script>
        $(function () {
            $('body').append('<div id="gotop" onclick="goTop();"></div>');
            $(window).scroll(function () {
                300 < $(this).scrollTop() ?
                ($('#gotop').show(),
                $('#gotop').css('left', $('.z').offset().left + $('.z').width() + 20),
                $('#gotop').css('top', $(window).height() - 300))
                : $('#gotop').hide()
            });
            $(window).resize(function () {
                $('#gotop').css('left', $('.z').offset().left + $('.z').width() + 20)
            })
        });
        function goTop(u, t, r) {
            var scrollActivate = !0;
            if (scrollActivate) {
                u = u || 0.1;
                t = t || 16;
                var s = 0,
                q = 0,
                o = 0,
                p = 0,
                n = 0,
                j = 0;
                document.documentElement && (s = document.documentElement.scrollLeft || 0, q = document.documentElement.scrollTop || 0);
                document.body && (o = document.body.scrollLeft || 0, p = document.body.scrollTop || 0);
                n = window.scrollX || 0;
                j = window.scrollY || 0;
                s = Math.max(s, Math.max(o, n));
                q = Math.max(q, Math.max(p, j));
                p = 1 + u;
                window.scrollTo(Math.floor(s / p), Math.floor(q / p));
                0 < s || 0 < q ? window.setTimeout('goTop(' + u + ', ' + t + ')', t) : 'undefined' != typeof r && r()
            } else {
                scrollActivate = !0
            }
        }
    </script>
    <style>
        #gotop:hover {
            background-position: 0px -116px;
        }
        #gotop {
            width: 29px;
            height: 106px;
            position: fixed;
            display: none;
            cursor: pointer;
            background: url('go_to_top.png') no-repeat scroll 0px 0px transparent;
        }
    </style>
</head>
<body>
    <div class="z" style="border: 1px dashed; height: 2999px; width: 977px; margin: 0 auto;">
    </div>
</body>
</html>

2015-04-26 ブログ園、あなたのJavaScriptは素晴らしい

2015-04-26 ブログ園にスムーズにページトップへ移動するアンカーとタグクラウドを追加

まず、私の目次はmarvinの作品を基に二次開発したものです。そして、アンカー画像と目次が同じ画像上にあることに気づき、一緒に使用しました。

トップへ戻るアンカー：

以前のBilibiliバージョンの関数を使用しました。ページをスムーズにスクロールでき、トップに到達する前に下にスクロールできません。詳細は参考リンクを参照してください。もちろん、JavaScriptには権限が必要なため、シンプルにaタグのhrefに#topを使用することもできますが、体験は少し劣ります。

そして、私は怠け者なので、アンカーの表示条件を目次の表示条件と同じにしました。つまり、マッチした要素のスクロールバートップからの相対オフセットが200を超えたときに表示されます。

タグクラウド：

Googleで適当に見つけました。ベクターグラフィックを使用しています。

しかし、これには制限があります。インスタンス化関数は要素IDを使用する必要があります。そこで、タグエリアのulをdivでラップし、インスタンス化しました。インスタンス化が成功したとき、タグエリアとタイトルを非表示にし、canvasのアニメーションと表示を設定します。

window.onload=function(){                      
    $("ul:first","#sidebar_categories").wrap("<div id='caonimagebi' style='display:block'></div>")  
    if(!$('#myCanvas').tagcanvas({
          textColour: '#519cea',
          outlineColour: '#404040',
          reverse: true,
          depth: 0.8,
          maxSpeed: 0.10
        },'caonimagebi')) {
          console.log("クソだ")
          $('#myCanvasContainer').hide(); 
        }
        else{
            $('#myCanvasContainer').css('display', 'block');    
            $('#myCanvas').tagcanvas("setspeed", [0.015, -0.05]);        
             $('#caonimagebi').css('display', 'none');                    
              $('.catListTitle:first-child','#sidebar_categories').empty();//エッセイカテゴリを削除  
        }   
               }

しかし、これには制限があります。onloadに書かれているため、少し不自然です。この機能が隠されたように表示され、調和していないことがわかります。これが私を狂わせる点です。

狂気：

なぜこのラッピング方法をonreadyに書くと機能しないのか、そしてオンラインでのみ機能しないのか、非常に興味深いです。ローカルでテストしましたが、ローカルでonreadyに書いたときはページが正常に動作しましたが、ブログ園にアップロードするとこのようになります。

ブログ園、あなたのJavaScriptは素晴らしい

備考：

ブログ園のファイルシステムはソフト削除、遅延更新です。つまり、ファイルを削除してもまだ存在します。ファイルを削除して同じ名前のファイルをアップロードすると、サーバー上のファイルはまだ古いバージョンのままなので、ファイル名と対応する参照ファイル名を手動で変更する必要があります。
この目次には一定の制限があります。つまり、h2、h3、h4です。メソッドはあまり堅牢に書かれておらず、目次の高さは可能な限り見出し数に基づいて計算し、上限を設定する必要がありますが、変更するのが面倒です。また、z-indexの問題もあります。これは特に注意が必要です。隣のアンカーとトップへ戻るを999に設定しました。
ブログ園にはjQueryが組み込まれているため、別途参照する必要はありません。

2026-01-13 備考

原文は私のブログ園の2つの記事と1つのQ&Aで、クローラーで取得し、少し修正しました。

2015-04-26 19:41 ブログ園にスムーズにページトップへ移動するアンカーとタグクラウドを追加 https://www.cnblogs.com/zeusro/p/4458222.html

2014-05-03 18:58 Bilibiliのトップへ戻るアンカーを取得 https://www.cnblogs.com/zeusro/p/3705426.html

現在のBilibiliのトップへ戻るアンカーは10年前よりも劣っています。すでにこのプロジェクトに移植しました。

コミットリンクは 247c0101d65b9c580fadc40db32165d2ef84fe07です。AIはjQueryの問題も修正しました。これも素晴らしいです。

Chromeスクリーンショットスクリプト

Chromeの--headless=newモードを使用して全ページスクリーンショットを取得：

$url = "https://q.cnblogs.com/q/71564"
$outputPath = "D:\Zeusro.github.io\img\in-post\bilibili\cnblogs-71564.png"
$chromePath = "C:\Program Files\Google\Chrome\Application\chrome.exe"

& $chromePath --headless=new --disable-gpu --window-size=1280,2000 --virtual-time-budget=10000 --screenshot=$outputPath $url

パラメータ説明：

--headless=new: 新しいヘッドレスモードを使用
--disable-gpu: GPUアクセラレーションを無効化
--window-size=1280,2000: ウィンドウサイズを1280x2000ピクセルに設定。全ページをキャプチャするのに十分な高さ
--virtual-time-budget=10000: ページに10秒の仮想時間予算を与え、すべてのコンテンツが読み込まれることを確保
--screenshot=$outputPath: スクリーンショットの保存パスを指定

参考リンク：

Bilibiliのトップへ戻るアンカーを取得

WizNoteに美しいナビゲーション目次を追加する方法

http://www.goat1000.com/tagcanvas-functions.php

2014-05-03 Извлечение якоря возврата наверх Bilibili

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

Лично я рекомендую Firefox + Firebug для просмотра кода веб-страниц. Я использую Nightly, ежедневную обновляемую версию Firefox (не рекомендуется, иногда обновляется три раза в день, перезапуски очень раздражают).

Код веб-страницы, CSS и изображения легко получить. Просто кликайте где хотите, слева код, справа CSS и прочее. Для фоновых изображений просто правой кнопкой мыши по пути, откройте в новой странице и сохраните.

Основная проблема была в привязанных событиях JavaScript. Сначала я тупо искал div id якоря, нашёл кое-что, но никак не мог найти событие. Позже, когда научился использовать Firebug, стало намного проще. Тег клика привязан к функции goTop. В консоли Firebug введите “goTop”, затем нажмите “RUN”, и функция появится. После нахождения можно правой кнопкой мыши форматировать исходный код для удобного копирования. Ввод “goTop()” выполняет её. Это другое.

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

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title></title>
    <script src="../Scripts/jquery-1.10.2.min.js"></script>
    <script>
        $(function () {
            $('body').append('<div id="gotop" onclick="goTop();"></div>');
            $(window).scroll(function () {
                300 < $(this).scrollTop() ?
                ($('#gotop').show(),
                $('#gotop').css('left', $('.z').offset().left + $('.z').width() + 20),
                $('#gotop').css('top', $(window).height() - 300))
                : $('#gotop').hide()
            });
            $(window).resize(function () {
                $('#gotop').css('left', $('.z').offset().left + $('.z').width() + 20)
            })
        });
        function goTop(u, t, r) {
            var scrollActivate = !0;
            if (scrollActivate) {
                u = u || 0.1;
                t = t || 16;
                var s = 0,
                q = 0,
                o = 0,
                p = 0,
                n = 0,
                j = 0;
                document.documentElement && (s = document.documentElement.scrollLeft || 0, q = document.documentElement.scrollTop || 0);
                document.body && (o = document.body.scrollLeft || 0, p = document.body.scrollTop || 0);
                n = window.scrollX || 0;
                j = window.scrollY || 0;
                s = Math.max(s, Math.max(o, n));
                q = Math.max(q, Math.max(p, j));
                p = 1 + u;
                window.scrollTo(Math.floor(s / p), Math.floor(q / p));
                0 < s || 0 < q ? window.setTimeout('goTop(' + u + ', ' + t + ')', t) : 'undefined' != typeof r && r()
            } else {
                scrollActivate = !0
            }
        }
    </script>
    <style>
        #gotop:hover {
            background-position: 0px -116px;
        }
        #gotop {
            width: 29px;
            height: 106px;
            position: fixed;
            display: none;
            cursor: pointer;
            background: url('go_to_top.png') no-repeat scroll 0px 0px transparent;
        }
    </style>
</head>
<body>
    <div class="z" style="border: 1px dashed; height: 2999px; width: 977px; margin: 0 auto;">
    </div>
</body>
</html>

2015-04-26 CNBlogs, ваш JavaScript потрясающий

2015-04-26 Добавление плавного якоря возврата наверх и облака тегов в ваш CNBlogs

Сначала мое оглавление основано на работе marvin, которую я доработал. Затем я обнаружил, что изображение якоря и оглавление находятся на одном изображении, поэтому использовал их вместе.

Якорь возврата наверх:

Я использовал функцию из старой версии Bilibili. Она может плавно прокручивать страницу наверх и предотвращает прокрутку вниз до достижения верха. Подробности смотрите в моей ссылке. Конечно, поскольку это связано с JavaScript, требующим разрешений, можно просто использовать тег якоря с href=”#top”, но опыт будет немного хуже.

Затем, поскольку я ленив, я сделал условие появления якоря таким же, как у оглавления. То есть, оно показывается, когда смещение совпадающего элемента относительно верха полосы прокрутки превышает 200.

Облако тегов:

Я нашёл это случайно в Google. Использует векторную графику.

Но у этой штуки есть ограничение - её функция инициализации требует ID элемента. Поэтому я обернул ul области тегов в div, затем инициализировал. При успешной инициализации скрываю область тегов и заголовок, устанавливаю анимацию и отображение canvas.

window.onload=function(){                      
    $("ul:first","#sidebar_categories").wrap("<div id='caonimagebi' style='display:block'></div>")  
    if(!$('#myCanvas').tagcanvas({
          textColour: '#519cea',
          outlineColour: '#404040',
          reverse: true,
          depth: 0.8,
          maxSpeed: 0.10
        },'caonimagebi')) {
          console.log("Чёрт возьми")
          $('#myCanvasContainer').hide(); 
        }
        else{
            $('#myCanvasContainer').css('display', 'block');    
            $('#myCanvas').tagcanvas("setspeed", [0.015, -0.05]);        
             $('#caonimagebi').css('display', 'none');                    
              $('.catListTitle:first-child','#sidebar_categories').empty();//Удалить категории эссе  
        }   
               }

Но это имеет ограничение - поскольку написано в onload, это немного резко. Вы можете видеть, что эта штука появляется как будто была скрыта, не гармонично. Это то, что сводит меня с ума.

Схожу с ума:

Мне просто очень любопытно, почему этот метод обёртки не работает, когда написан в onready, и это не работает только онлайн. Я тестировал локально, и когда написал в onready локально, страница работала нормально, но при загрузке на CNBlogs становится так.

CNBlogs, ваш JavaScript потрясающий

Примечания:

Файловая система CNBlogs - это мягкое удаление, медленное обновление. То есть, когда вы удаляете файл, он всё ещё там. Если вы удалите файл и загрузите файл с тем же именем, файл на сервере всё ещё старая версия, поэтому нужно вручную изменить имя файла и соответствующее имя файла ссылки.
Это оглавление имеет определённые ограничения, а именно h2, h3, h4. Метод написан не очень надёжно, и высота оглавления должна быть рассчитана на основе количества заголовков, насколько это возможно, затем установить верхний предел, но мне лень это менять. Также есть проблема z-index. Это требует особого внимания. Я установил якорь и возврат наверх рядом с ним на 999.
CNBlogs поставляется со встроенным jQuery, поэтому не нужно ссылаться на него отдельно.

2026-01-13 Примечания

Оригинальный текст состоит из 2 статей и 1 Q&A из моего CNBlogs, которые я извлёк с помощью краулера и слегка изменил.

2015-04-26 19:41 Добавление плавного якоря возврата наверх и облака тегов в ваш CNBlogs https://www.cnblogs.com/zeusro/p/4458222.html

2014-05-03 18:58 Извлечение якоря возврата наверх Bilibili https://www.cnblogs.com/zeusro/p/3705426.html

Теперь якорь возврата наверх Bilibili хуже, чем 10 лет назад. Я уже перенёс его в этот проект.

Ссылка на коммит: 247c0101d65b9c580fadc40db32165d2ef84fe07. AI также исправил проблему jQuery, что тоже удивительно.

Скрипт скриншота Chrome

Использование режима --headless=new Chrome для полностраничных скриншотов:

$url = "https://q.cnblogs.com/q/71564"
$outputPath = "D:\Zeusro.github.io\img\in-post\bilibili\cnblogs-71564.png"
$chromePath = "C:\Program Files\Google\Chrome\Application\chrome.exe"

& $chromePath --headless=new --disable-gpu --window-size=1280,2000 --virtual-time-budget=10000 --screenshot=$outputPath $url

Объяснение параметров:

--headless=new: Использовать новый режим без интерфейса
--disable-gpu: Отключить ускорение GPU
--window-size=1280,2000: Установить размер окна 1280x2000 пикселей, достаточно большая высота для захвата полной страницы
--virtual-time-budget=10000: Дать странице 10 секунд виртуального времени, чтобы убедиться, что весь контент загружен
--screenshot=$outputPath: Указать путь сохранения скриншота

Ссылки:

Извлечение якоря возврата наверх Bilibili

Как добавить красивую навигационную таблицу содержания в ваш WizNote

http://www.goat1000.com/tagcanvas-functions.php

为什么中国没有互联网企业

Tue, 30 Dec 2025 00:00:00 +0000

在垃圾回收站学计算机是一件非常蛋疼的事情，基本上我只学习了HTML和数据库这门课，而其他人学的是HTML那门课——我还记得有一天，我在图书馆里面找书，然后从夹缝里面冒出来一张便利店的纸条，上面写满了爱~

在国内从事计算机其实非常累，网络问题不说，教材又厚又脱离实际。而等到从业，又是漫长的工作/学习曲线，等到刚入门（10年经验），又会被经济周期，家庭琐事，年龄歧视等困扰。这导致大部分人在30岁左右，都以转行告终。

在我个人看来，过于急功近利，是国内没有两家互联网企业的根本原因。

业务开发&框架设计

在我看来，国内所谓的“互联网企业”，只是把业务的场景从线下搬到线上。以银行来说，早期的国内银行是以人工记账为主，银行可以说是最早吃到计算机红利的企业，但它的业务模式本身并没有太多变化，除了招商银行做得比较好之外，其余银行的移动端APP做得非常臃肿，响应缓慢，这二十年的变化无非是去IOE（IBM、Oracle（甲骨文）、EMC）比较成功而已。

但熟悉计算机架构的我知道，假设真让我去接手这些历史遗留项目，我也是不敢去IOE的，因为天知道里面有什么硬件限定坑（比如用特定的选择编译/编程技巧绕过特定硬件架构缺陷，但当你移植程序到Linux时，发现反而成为了bug）。

就业务开发而言，我们的互联网改造无疑是非常成功的。早上可以直接扫码支付买个早餐，出门直接滴滴打车，上班用AI辅助编造废话，中午点个外卖，下午可以刷脸支付要点零食，晚上直接到预约的娱乐场所接着happy。

只要有钱，一部手机可以通行全国。但编程用的框架基本跟我们没啥关系。虽然现在很多顶级的项目开始由中国人牵头，但编程框架本身就是一个不挣钱的买卖。很多人从事这个行业纯粹为了脱贫，更何况大部分人（包括我在内）对知识产权缺乏敬畏，毫无付费习惯。大家只是一味地享受别人的免费劳动，不把别人的时间当一回事儿。

开源开发&语言设计

技术框架，本质是一种提供便利的工具集。因为编程语言本身只做基本的标准实现，所以需要开源的技术框架去构建语言本身的生态。

编程语言就像是一支“毛笔”，而开源的技术框架，则是这支毛笔画出来的“书法作品”。两者是一种相辅相成的关系。以Python这种低性能的弱类型语言来说，语言设计本身其实没有太多让我喜欢的地方，但架不住人工学习框架TensorFlow，PyTorch都是Python写的。

而Python的性能优化方向，竟然是绕过GIL限制和使用C语言。这让我觉得有点顾此失彼的感觉。

就好像我拿着一张美女宣传单去按摩，结果迎接我的是一个七尺壮汉，他告诉我美女休息了，他更有力量，更适合按摩这种工作。对此，我的身心都是拒绝的。因为这跟我的初衷完全相反。

AI得道，Python升天。

语言设计&操作系统开发

编程语言是一种很深的学问。那些控制流和机器码的翻译，抽象语法树，GC，线程，编译原理啥的，关是算1+1我都整不出来。

计算机又是一种很让人挫败的行业。天赋型选手在四五年级就会HTML，开始机器人编程造火箭了；而四五年级的我，当时还只会在亲戚的电脑上注册个QQ，然后被同学们虐爆泡泡堂。

更别提国内这B环境，大学叫兽们努力上岸了，只记得拿着十年前的教程在课堂上吹水，然后告诉你，“其实学C#2005就够了，即便现在有.net core了，都一个样~”

我真是服了，一个是平台限定语言，一个是跨平台甚至跨语言编译的次时代语言，这能一样吗？学习编程，最重要的第一步是参与开源项目设计。理解工业设计的流程，而不是待在泰坦尼克号上求援。

编程语言依托于操作系统，操作系统相当于编程语言的载体。操作系统，是连接硬件和软件的纽带。也是软件开发最高的山。

软件开发&集成电路

其实业务开发，开源框架设计，编程语言设计，操作系统开发，这些都能归集为“软件开发”。如果从这个角度上看，实际上我们的互联网行业还有很大的一部分空白。

把人当成耗材，就要接受工作交接期间网站的流量波动与不稳定。更别提平台用户是可以发起“重定向攻击”的——抛弃那些苛刻对待员工的“互联网平台企业”。

国内所谓的敏捷开发不过是人力推车（而且还是让3个人推一辆四轮新能源车）。在《人月神话》中提到这种“孕妇生孩子”把戏——1个孕妇怀胎生娃要40周，但不可能安排10个孕妇在4周内完成生产。我见过那些所谓通宵赶工的项目，后面无一不是烂尾，要么就是重做。

急功近利浪费的时间精力跟“节约的时间”完全不值一提，如果造成技术漏洞，反而更得不偿失。

软件开发的上游是集成电路。其实我们有一个很好的基金在支持这些高新技术的集成电路产业。只不过资源一再错配，钱没有流入真正为国为民的企业和人手中。

软件开发和集成电路，本该是厚积薄发，重积累和理论联系实际的行业。结果大学科研几乎以骗经费为荣（比如把导师称为老板）；而私营企业以年轻化为由，各种割中年人韭菜，让工程经验丰富的高级开发工程师失业，还美其名曰“为社会输送人才”。

剑气之争

这就好像是华山派的剑宗与气宗之争。剑宗（年轻一派）掌权之后把学气宗的人（资深开发人员）踢出公司。因为学剑宗见效快，都是确定能盈利的项目，而且人力便宜。

剑宗重剑的招式，而气宗（开源项目，语言设计，操作系统）注重内功修炼。两者本无对错，在年幼时，假借剑谱（go，C#,Java语言）练剑没有任何问题，但大部分人不过是一种语言用上4/5年，就以资深开发自居，其实不过是50行代码复制了4/5年而已。

要么就是Java boy 那种，为了下一份工作方便，在不需要微服务的前提下强行微服务。

这不过是东施效颦，真正的内功（互联协议，编程规范，抽象建模能力）没有及时沉淀。最终当“剑”生锈（比如PHP不再流行，项目被竞争对手打压），就只能被迫转行，武学净废。

气宗的“气”并不是傲气，而是一种生存的底气。这种底气是一种十年如一日，久久为功，持之以恒的坚持。是这个世界上所有人都不看好你，你即便手中无剑，依旧偏向虎山行的勇气。

我们需要理想，因为在漫长的黑夜中，唯有希望能带我们远航。

Studying computer science at a garbage dump is a truly painful experience. I basically only learned the HTML and database courses, while others were learning just the HTML course—I still remember one day in the library when I found a convenience store receipt stuck in the cracks, filled with love~

Working in computer science in China is really exhausting. Aside from network issues, the textbooks are thick and detached from reality. When you finally enter the industry, there’s a long curve of work and learning. By the time you’re just getting started (with 10 years of experience), you’re already troubled by economic cycles, family issues, and age discrimination. This causes most people to switch careers around the age of 30.

In my personal view, the fundamental reason why China doesn’t have two internet giants is due to the excessive impatience for quick success.

Business Development & Framework Design

In my opinion, so-called “internet companies” in China merely move offline business scenarios online. Take banks, for example: early domestic banks primarily used manual accounting. Banks were among the first to benefit from computing, but their business models themselves didn’t change much. Except for China Merchants Bank doing relatively well, other banks’ mobile apps are bloated and slow to respond. The change over the past twenty years mostly boils down to successfully ditching IOE (IBM, Oracle, EMC).

But as someone familiar with computer architecture, I know that if I were to take over these legacy projects, I wouldn’t dare to ditch IOE either, because who knows what hardware-specific traps lie inside? (For example, using certain compilation or programming tricks to circumvent hardware architecture flaws, but when porting the program to Linux, these become bugs.)

From the standpoint of business development, our internet transformation has undoubtedly been very successful. In the morning, you can scan a QR code to buy breakfast; step outside and hail a Didi ride; at work, use AI to help fabricate nonsense; order takeout at noon; pay for snacks with face recognition in the afternoon; and in the evening, head straight to a booked entertainment venue to keep the party going.

As long as you have money, one smartphone lets you travel nationwide. But the programming frameworks used have basically nothing to do with us. Although many top projects are now led by Chinese people, programming frameworks themselves are a money-losing business.
Many people work in this field purely to escape poverty, and most people (myself included) have no respect for intellectual property and no habit of paying for it.
Everyone just enjoys others’ free labor without valuing their time.

Open Source Development & Language Design

Technical frameworks are essentially convenience toolkits. Because programming languages only implement basic standards, open source technical frameworks are needed to build the language’s ecosystem.

A programming language is like a “brush,” and open source technical frameworks are the “calligraphy works” painted by this brush. They complement each other.
Take Python, a low-performance, dynamically typed language. I don’t particularly like its language design, but I can’t deny that frameworks like TensorFlow and PyTorch are written in Python.

Python’s performance optimization direction surprisingly involves bypassing the GIL and using C. This feels somewhat like a case of missing the forest for the trees.

It’s like I brought a flyer advertising a beautiful masseuse, but was greeted by a burly man who told me the beauty was resting and that he was stronger and better suited for massage work. My mind and body rejected this because it completely contradicted my original intention.

AI has found its way, Python ascends.

Language Design & Operating System

Programming languages are a deep field of study. Control flow, machine code translation, abstract syntax trees, GC, threads, compiler theory—all these are so complex that I can barely solve 1+1.

Computing is also a frustrating industry. Gifted kids learn HTML in fourth or fifth grade and start programming robots and building rockets; meanwhile, I was just registering a QQ account on a relative’s computer and getting crushed in Bubble Trouble by classmates.

Not to mention the terrible environment in domestic universities: professors try hard to get tenure, only to be found teaching with decade-old tutorials and saying, “Actually, learning C# 2005 is enough. Even with .NET Core now, it’s basically the same~”

I’m truly amazed. One is a platform-specific language; the other is a next-generation language supporting cross-platform and even cross-language compilation. How can these be the same? The most important first step in learning programming is participating in open source project design. Understanding industrial design processes, rather than waiting for rescue on the Titanic.

Programming languages rely on operating systems, which serve as their carriers. Operating systems are the bridge between hardware and software. They are the highest mountain in software development.

Software Development & Integrated Circuits

In fact, business development, open source framework design, programming language design, and operating system development can all be categorized as “software development.” From this perspective, our internet industry still has a large blank space.

Treating people as consumables means accepting traffic fluctuations and instability during work handovers. Not to mention platform users can launch “redirect attacks”—abandoning those harsh “internet platform companies” that mistreat employees.

So-called agile development in China is just manpower pushing carts (and three people pushing a four-wheeled new energy vehicle at that). The Mythical Man-Month describes this “pregnant woman giving birth” trick—one woman takes 40 weeks to give birth, but you can’t schedule 10 women to deliver in 4 weeks. I have seen so many “all-nighter” projects, all ending in abandonment or rework.

The time and energy wasted chasing quick wins are negligible compared to the “time saved,” and if technical vulnerabilities result, the losses are even greater.

The upstream of software development is integrated circuits. We do have a good fund supporting high-tech integrated circuit industries. But resources are repeatedly misallocated, and money doesn’t flow to truly national and people-serving enterprises and individuals.

Software development and integrated circuits should be industries of steady accumulation and theory-practice integration. Instead, university research almost prides itself on scamming funds (e.g., calling advisors “bosses”);
private enterprises, under the guise of youthfulness, harvest middle-aged workers like crops, causing experienced senior developers to lose jobs, all while praising this as “delivering talent to society.”

Two styles of swords

This is like the dispute between the Sword Sect and Qi Sect of Mount Hua. After the Sword Sect (the younger faction) took power, they kicked out Qi Sect practitioners (senior developers). Because Sword Sect practices yield fast results, are sure to profit, and have cheap labor.

The Sword Sect focuses on heavy sword techniques, while the Qi Sect (open source projects, language design, operating systems) emphasizes internal cultivation.
Neither is right or wrong. In youth, practicing sword techniques with borrowed manuals (Go, C#, Java) is fine. But most people just use one language for 4-5 years and then call themselves senior developers, which is basically copying 50 lines of code for 4-5 years.

Or they become Java boys who forcibly implement microservices without need, just to ease the next job hunt.

This is just a poor imitation. True internal skill (internet protocols, coding standards, abstract modeling ability) has not been properly accumulated. When the “sword” rusts (e.g., PHP falls out of favor, projects get crushed by competitors), they’re forced to switch careers, wasting their martial arts.

The “Qi” in Qi Sect is not arrogance but a kind of survival confidence. This confidence is a ten-year daily effort, persistent, and enduring. It is the courage to move toward the tiger’s den even when the whole world doubts you and you have no sword in hand.

We need ideals because, in the long dark night, only hope can carry us far.

ゴミ捨て場でコンピュータを学ぶのは非常に骨の折れることでした。基本的に私はHTMLとデータベースの授業しか受けませんでしたが、他の人はHTMLの授業を受けていました——ある日、図書館で本を探していると、隙間からコンビニのレシートが出てきて、その上には愛の言葉がびっしり書かれていました。

国内でコンピュータ関連の仕事をするのは本当に大変で、ネットワークの問題はさておき、教材は分厚くて実践からかけ離れています。業界に入ってからも、長い仕事や学習の曲線が続き、ようやく入門（10年の経験）した頃には、経済の波、家庭の問題、年齢差別などに悩まされます。これが多くの人が30歳前後で転職を余儀なくされる原因です。

私個人の見解では、あまりにも短期的な利益を追求することが、国内に二つの大手インターネット企業が存在しない根本的な理由だと思います。

业务开发&框架设计

私の考えでは、国内のいわゆる「インターネット企業」は、単に業務のシーンをオフラインからオンラインに移しただけです。銀行を例に取ると、国内の銀行は初期は手作業の帳簿管理が主で、銀行はコンピュータの恩恵を最も早く受けた企業の一つですが、そのビジネスモデル自体はあまり変わっていません。招商銀行が比較的うまくやっている以外は、他の銀行のモバイルアプリは非常に肥大化し、反応も遅いです。この20年の変化は、IOE（IBM、Oracle（甲骨文）、EMC）からの脱却が比較的成功したことに過ぎません。

しかし、コンピュータアーキテクチャに詳しい私としては、もしこれらのレガシープロジェクトを引き継ぐことになったら、IOEからの脱却は怖くてできません。なぜなら、特定のハードウェア制限の罠があるかもしれないからです（例えば特定のコンパイルやプログラミング技術で特定のハードウェアアーキテクチャの欠陥を回避しているが、Linuxに移植したら逆にバグになるなど）。

業務開発に関して言えば、我々のインターネット改造は間違いなく非常に成功しています。朝はQRコードで朝食を買い、出かけるときは滴滴でタクシーを呼び、仕事中はAIで無駄話を補助してもらい、昼はデリバリーを注文し、午後は顔認証でスナックを買い、夜は予約した娯楽施設で楽しむ。

お金さえあれば、スマホ一つで全国を移動できます。しかし、プログラミングに使うフレームワークは基本的に我々には関係ありません。今では多くのトッププロジェクトが中国人によって主導されていますが、プログラミングフレームワーク自体は儲からない商売です。多くの人がこの業界に従事するのは純粋に貧困から脱するためであり、ましてや大多数の人（私も含めて）は知的財産権に対する敬意がなく、支払いの習慣もありません。皆、ただひたすら他人の無料労働を享受し、他人の時間を尊重していません。

开源开发&语言设计

技術フレームワークは本質的に便利なツールセットです。プログラミング言語自体は基本的な標準実装のみを行うため、言語自体のエコシステムを構築するためにオープンソースの技術フレームワークが必要です。

プログラミング言語は「毛筆」のようなものであり、オープンソースの技術フレームワークはその毛筆で描かれた「書道作品」です。両者は相補的な関係にあります。 Pythonのような低性能で弱い型付けの言語に関して言えば、言語設計自体には特に好きなところはありませんが、TensorFlowやPyTorchのようなフレームワークがPythonで書かれているため、学ぶ価値があります。

Pythonの性能最適化の方向性は、GIL制限を回避しC言語を使うことですが、これはどこか本末転倒な感じがします。

まるで美人のチラシを持ってマッサージに行ったら、迎えてくれたのは七尺の大男で、「美女は休みだが、俺の方が力があってマッサージに向いている」と言われたような気分です。これは私の本意とは全く違います。

AIが発展し、Pythonが飛躍する。

语言设计&操作系统开发

プログラミング言語は非常に奥深い学問です。制御フローや機械語への翻訳、抽象構文木、GC、スレッド、コンパイラ理論など、1+1も計算できない私には到底理解できません。

コンピュータはまた挫折感を味わいやすい業界でもあります。天才型の子供は小学校4、5年生でHTMLを学び、ロボットプログラミングやロケット製造を始めますが、私の小学校4、5年生の頃は親戚のパソコンでQQに登録することしかできず、同級生にバブルシュートでボコボコにされていました。

ましてや国内のこの酷い環境では、大学の教授たちは努力しているように見えて、10年前の教材を持ち出して授業で自慢し、「実はC#2005を学べば十分で、.net coreがあっても大差ない」と言うだけです。

本当に呆れます。片方はプラットフォーム限定言語で、もう片方はクロスプラットフォームでクロス言語コンパイル可能な次世代言語です。同じなわけがありません。プログラミング学習で最も重要なのは、オープンソースプロジェクトの設計に参加し、産業設計のプロセスを理解することであり、タイタニック号で助けを求めることではありません。

プログラミング言語はOSに依存し、OSはプログラミング言語の土台です。OSはハードウェアとソフトウェアをつなぐ架け橋であり、ソフトウェア開発の最高峰です。

软件开发&集成电路

実は業務開発、オープンソースフレームワーク設計、プログラミング言語設計、OS開発はすべて「ソフトウェア開発」に帰着します。この視点で見ると、我々のインターネット業界にはまだ大きな空白があります。

人を消耗品と見なすなら、業務引継ぎ期間中のサイトのトラフィック変動や不安定さを受け入れなければなりません。プラットフォームのユーザーが「リダイレクト攻撃」を仕掛けることもあります——厳しく社員を扱う「インターネットプラットフォーム企業」は捨てましょう。

国内のいわゆるアジャイル開発は、人力で車を押しているに過ぎません（しかも3人で四輪の新エネルギーカーを押しているようなものです）。『人月の神話』にはこの「妊婦が出産する手法」が出てきます——1人の妊婦が40週かけて出産するが、10人の妊婦に4週間で出産させることは不可能です。私は徹夜で急ぐプロジェクトを見てきましたが、どれも後に破綻し、再構築を余儀なくされました。

短期的な利益を急ぐことで浪費される時間と労力は「節約された時間」とは比べものにならず、技術的な欠陥を生むと逆に損失が大きくなります。

ソフトウェア開発の上流は集積回路です。実は我々にはこれらの先端技術の集積回路産業を支援する良い基金があります。しかし資源は何度も誤配され、お金は真に国や民のためになる企業や人の手に渡っていません。

ソフトウェア開発と集積回路は、本来は厚い蓄積と理論と実践の結びつきの業界であるべきです。ところが大学の研究はほぼ資金詐取を誇り（例えば指導教官を「ボス」と呼ぶなど）、民間企業は若返りを理由に中年のエンジニアを搾取し、高度な経験を持つ開発者を失業させ、それを「社会に人材を送り出している」と美化しています。

剑气之争

これはまるで華山派の剣宗と気宗の争いのようです。剣宗（若い世代）が権力を握ると、気宗（ベテラン開発者）を会社から追い出します。なぜなら剣宗は効果が早く、確実に利益を生むプロジェクトを担当し、人件費も安いからです。

剣宗は剣の技を重視し、気宗（オープンソースプロジェクト、言語設計、OS）は内功の修練を重視します。両者に正誤はありません。若い時には剣譜（Go、C#、Java言語）を使って剣を練習するのは全く問題ありませんが、多くの人は1つの言語を4、5年使っただけでベテランを自称し、実際には50行のコードを4、5年コピーしているだけです。

あるいはJavaボーイのように、次の仕事のためにマイクロサービスが不要な状況で無理にマイクロサービスを導入する人もいます。

これは東施が西施の真似をするようなもので、本当の内功（インターネットプロトコル、コーディング規範、抽象モデリング能力）は適切に蓄積されていません。最終的に「剣」が錆びる（例えばPHPの流行が終わり、プロジェクトが競合に負ける）と、転職を余儀なくされ、武学は無駄になります。

気宗の「気」は傲慢さではなく、生きるための底力です。この底力は十年一日の如く、長く続けること、粘り強い努力のことです。世界中の誰もがあなたを認めなくても、手に剣がなくても、虎の山に向かう勇気です。

私たちは理想を必要としています。なぜなら長い暗闇の中で、希望だけが私たちを遠くへ導いてくれるからです。

Учиться компьютерным наукам на свалке — это очень неприятное занятие, по сути я изучал только HTML и базу данных, в то время как другие учились только HTML — я до сих пор помню, как однажды в библиотеке, когда я искал книгу, из щели выскользнула записка из магазина с надписью, полной любви~

Работать в сфере IT в Китае на самом деле очень тяжело: проблемы с сетью — это не говоря уже о толстых и оторванных от реальности учебниках. А когда начинаешь работать, тебя ждет долгий путь обучения и работы, и когда ты только входишь в профессию (после 10 лет опыта), тебя начинают беспокоить экономические циклы, семейные проблемы, возрастная дискриминация. В итоге большинство людей к 30 годам заканчивают сменой профессии.

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

Бизнес-разработка & проектирование фреймворков

С моей точки зрения, так называемые «интернет-компании» в Китае просто перенесли бизнес-сценарии из оффлайна в онлайн. Возьмем, например, банки: в ранние годы в Китае банки вели учет вручную, они были одними из первых, кто получил выгоду от компьютеров, но их бизнес-модель практически не изменилась. За исключением招商银行 (China Merchants Bank), остальные банки сделали свои мобильные приложения очень громоздкими и медленными. Изменения за последние двадцать лет свелись в основном к успешному отказу от IOE (IBM, Oracle, EMC).

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

Что касается бизнес-разработки, наша интернет-трансформация, безусловно, очень успешна. Утром можно просто отсканировать QR-код и купить завтрак, выйти из дома и вызвать такси через Didi, на работе использовать AI для составления бессмысленных текстов, заказать еду на обед, после обеда оплатить покупку с помощью распознавания лица, а вечером отправиться в забронированное развлекательное заведение и продолжать веселиться.

Если у тебя есть деньги, один телефон может обеспечить доступ по всей стране. Но фреймворки для программирования в этом почти не участвуют. Хотя сейчас многие топовые проекты возглавляют китайцы, сами фреймворки — это не прибыльный бизнес. Многие работают в этой сфере просто чтобы выбраться из бедности, тем более что большинство (включая меня) не испытывают уважения к интеллектуальной собственности и не привыкли платить за знания. Все просто наслаждаются чужим бесплатным трудом, не считая время других людей.

Открытая разработка & проектирование языков

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

Язык программирования — это как «кисть для каллиграфии», а открытые фреймворки — это «каллиграфические произведения», созданные этой кистью. Они взаимодополняют друг друга. В случае с Python, языком с низкой производительностью и слабой типизацией, сам язык не особо меня привлекает, но невозможно игнорировать тот факт, что такие фреймворки, как TensorFlow и PyTorch, написаны на Python.

Оптимизация производительности Python, как ни странно, заключается в обходе ограничения GIL и использовании C. Это вызывает у меня ощущение, что решается одна проблема за счет другой.

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

AI достиг вершины, Python взлетел.

Проектирование языков & разработка операционных систем

Языки программирования — это глубокая наука. Управляющие конструкции, перевод в машинный код, абстрактные синтаксические деревья, GC, потоки, принципы компиляции — даже простейшие вещи, вроде 1+1, для меня сложны.

Компьютерная индустрия — это очень разочаровывающая сфера. Талантливые дети уже в четвертом-пятом классе знают HTML и начинают заниматься робототехникой и создавать ракеты; а я в том же возрасте только регистрировался в QQ на компьютере родственников и меня безжалостно обыгрывали в Bubble Trouble одноклассники.

Не говоря уже о нашем ужасном окружении: профессора в университете стараются, чтобы сдать экзамены, но используют учебники десятилетней давности и говорят: «На самом деле, изучать C# 2005 достаточно, даже если сейчас есть .net core — они одинаковы~»

Я в шоке: один язык ограничен платформой, другой — это следующий уровень с кросс-платформенной и даже кросс-языковой компиляцией, как они могут быть одинаковыми? Первый шаг в изучении программирования — участие в разработке open source проектов. Понимание процесса промышленного дизайна, а не сидение на Титанике и просьба о помощи.

Языки программирования зависят от операционных систем, которые являются их платформой. Операционная система — связующее звено между аппаратным обеспечением и программным обеспечением. Это вершина программной разработки.

Разработка ПО & интегральные схемы

На самом деле, бизнес-разработка, проектирование open source фреймворков, разработка языков и операционных систем — все это можно объединить в «разработку программного обеспечения». Если смотреть с этой точки зрения, в нашей интернет-индустрии еще много пустого пространства.

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

Так называемая «гибкая разработка» в Китае — это просто люди, толкающие тележку (причем трое толкают одну четырехколесную электромашину). В книге «Миф о человеко-месяце» описывается трюк «беременной женщины» — одна беременная вынашивает ребенка 40 недель, но невозможно заставить 10 беременных родить за 4 недели. Я видел проекты, которые делались в режиме «ночных смен», и все они были провалами или переделками.

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

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

Разработка ПО и интегральных схем должна быть фундаментальной, требующей накопления и тесной связи теории с практикой. Но университетские исследования почти гордятся тем, что обманывают финансирование (например, называют научного руководителя «боссом»); а частные компании под предлогом молодости режут «лук» с опытных разработчиков, увольняя старших инженеров и при этом красиво называя это «подготовкой кадров для общества».

Борьба меча и ци

Это похоже на борьбу между двумя школами на горе Хуашань — мечников (молодое поколение) и ци (ветераны-разработчики). Когда мечники приходят к власти, они выгоняют тех, кто учился у ци. Потому что мечники делают быстрые проекты, которые приносят прибыль, и работают дешевле.

Мечники делают акцент на мощных приемах меча, а ци (open source проекты, проектирование языков, операционные системы) сосредоточены на внутренней силе.

Оба подхода не являются ошибочными. В молодости, тренируясь по учебникам меча (go, C#, Java), это нормально. Но большинство людей просто используют один язык 4-5 лет и считают себя опытными, на самом деле они просто копировали 50 строк кода 4-5 лет подряд.

Или, как Java boy, который ради удобства следующей работы внедряет микросервисы там, где они не нужны.

Это всего лишь подражание, настоящая внутренняя сила (интернет-протоколы, стандарты программирования, способность к абстрактному моделированию) не успевает сформироваться. Когда «меч» ржавеет (например, PHP выходит из моды, проекты проигрывают конкурентам), остается только сменить профессию, и все усилия оказываются напрасными.

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

Нам нужны идеалы, потому что в долгие темные ночи только надежда может привести нас к дальнему плаванию.

时间序列信用卡消费策略

Thu, 11 Dec 2025 00:00:00 +0000

微信支付的策略是基于最后一笔，而支付宝的支付顺序总是瞎搞，无论是自动顺序支付和系统自动匹配，带着明显的平台倾向性。这些都不是我想要的结果。

我决定自己设计一个时间序列信用卡消费策略，完成每一笔信用卡支付。

形式逻辑和定义

時間序列：是一組按照時間發生先後順序進行排列的數據點序列。

时间序列对象：基于时间序列的程序语言对象。时间必须是第一成员。

例如：

type Deal struct {
	t       time.Time
	Money   float32
	policy  string
	Payment Card
}

时间序列函数：基于时间序列的程序语言函数。时间（或者时间序列对象）必须是第一参数成员。

例如：

func (p *DiscountPolicys) MVP(d Deal) DiscountPolicy {
	var best DiscountPolicy
	var maxDiscount float32 = 0
	for _, policy := range p.Resource {
		if !policy.Match(d) {
			continue
		}
		if policy.Discount >= maxDiscount {
			continue
		}
		best = policy
		if best.N > 0 {
			maxDiscount = best.Discount
			//资源池减一
			best.N--
		}
	}
	if len(best.Bank) > 0 {
		p.Resource[best.Bank] = best
	}
	return best
}

// Cards 从本地文件加载信用卡信息，格式是每行 "银行 账单日/最后还款日"。如“农业银行 1/26”
func (z Zeusro) Cards(t time.Time) []Card {
    //省略
}

时间序列不动点：信用卡账单日的第二天。

账单日第二天消费策略：在信用卡账单日的第二天信用卡消费策略。

最大交易折扣交易策略：每一笔信用卡支付选取折扣金额最大的交易途径的消费策略。

基本类型建模

信用卡、交易、交易策略。

type Card struct {
	Bank        string    //金融机构
	BillingDate time.Time //账单日
	LastDate    time.Time //最后还款日
}

type Deal struct {
	t       time.Time
	Money   float32
	policy  string
	Payment Card
}

type Policy interface {
	Match(d Deal) bool
	Name() string
	MVP(d Deal) Policy
}

基于交易金额的二分算法

信用卡消费是一种延长应付账款的消费。单次交易的交易费用（1%左右）由商家承担。而从消费者角度考虑，申请多张信用卡，并设置不同的账单日，就相当于循环账期，形成个人的“永续债”。

小额消费主要以薅银行羊毛为主。比如农业银行的18-0.3，浦发银行的16-0.01，广发银行的n-0.01。个人感受是1000元以上的消费，以账单日第二天消费为宜——即尽量在信用卡账单日的第二天消费，为最佳时序不动点。

因此总的入口算法，以消费金额，使用二分法消费：

func (z Zeusro) Pay(deals []Deal) []Deal {
	//follow the rule and find the best policy
	discount := NewDiscountPolicys(DefaultDiscountPolicys)
	for i, deal := range deals {
		if deal.Money > SmallMoney {
			//账单日第二天消费策略 BillingDatePolicy
			policy1 := NewBillingDatePolicy(z.Cards(deal.t))
			mvp := policy1.MVP(deal)
			best := mvp.BestCard
			deals[i].Payment = best
			deals[i].policy = policy1.Name()
		} else {
			//最大交易折扣交易策略 DiscountPolicys
			mvp := discount.MVP(deal)
			card := Card{Bank: mvp.Bank}
			deals[i].Payment = card
			deals[i].policy = mvp.Name()
		}
	}
	return deals
}

账单日第二天消费策略

基本交易倾向是遍历所有信用卡，尽量接近账单第二日交易。

func (p BillingDatePolicy) MVP(d Deal) BillingDatePolicy {
	if len(p.cards) == 0 {
		return p
	}

	now := d.t
	var bestCard *Card
	var bestDelta time.Duration = time.Hour * 24 * 31 // 极大值

	for i := range p.cards {
		c := &p.cards[i]
		delta := now.Sub(c.BillingDate.AddDate(0, 0, 1))
		if delta > 0 && delta < bestDelta {
			bestDelta = delta
			bestCard = c
		}
	}
	if bestCard != nil {
		p.BestCard = *bestCard
	}
	return p
}

最大交易折扣策略

也叫薅羊毛算法。这个算法很简单，就是哪里有钱去哪里。以农业银行来说，参加每月活动报名之后，日消费第一笔18元减0.3元，浦发银行需要16元，以此类推。

func (p *DiscountPolicys) MVP(d Deal) DiscountPolicy {
	var best DiscountPolicy
	var maxDiscount float32 = 0
	for _, policy := range p.Resource {
		if !policy.Match(d) {
			continue
		}
		if policy.Discount >= maxDiscount {
			continue
		}
		best = policy
		if best.N > 0 {
			maxDiscount = best.Discount
			//资源池减一
			best.N--
		}
	}
	if len(best.Bank) > 0 {
		p.Resource[best.Bank] = best
	}
	return best
}

完整算法在我的自己实现的 OOOS 里面。

每天0.3元，我要薅到农行倒闭

WeChat Pay’s strategy is based on the last transaction, while Alipay’s payment order is always chaotic. Whether it is automatic payment order or system auto‑matching, the platform bias is obvious. None of these behaviors are what I want.

I decided to design my own time‑series credit‑card consumption strategy to control every single credit‑card payment.

Formal Logic and Definitions

Time series: a sequence of data points arranged according to the order in which they occur over time.

Time‑series object: a programming‑language object based on a time series. Time must be the first member.

Example:

type Deal struct {
    t       time.Time
    Money   float32
    policy  string
    Payment Card
}

Time‑series function: a programming‑language function based on a time series. Time (or a time‑series object) must be the first parameter.

Example:

func (p *DiscountPolicys) MVP(d Deal) DiscountPolicy {
    var best DiscountPolicy
    var maxDiscount float32 = 0
    for _, policy := range p.Resource {
        if !policy.Match(d) {
            continue
        }
        if policy.Discount >= maxDiscount {
            continue
        }
        best = policy
        if best.N > 0 {
            maxDiscount = best.Discount
            // reduce resource pool
            best.N--
        }
    }
    if len(best.Bank) > 0 {
        p.Resource[best.Bank] = best
    }
    return best
}

// Cards loads credit‑card information from a local file.
// Format: each line is "Bank BillingDate/LastDate".
// Example: "AgriculturalBank 1/26"
func (z Zeusro) Cards(t time.Time) []Card {
    // omitted
}

Time‑series fixed point: the second day after a credit card’s billing date.

Billing‑date‑plus‑one strategy: a credit‑card spending strategy that executes on the day after the billing date.

Maximum‑discount transaction strategy: for each transaction, choose the payment method that yields the highest discount.

Basic Type Modeling

Credit cards, transactions, and transaction strategies.

type Card struct {
    Bank        string    // financial institution
    BillingDate time.Time // billing date
    LastDate    time.Time // last repayment date
}

type Deal struct {
    t       time.Time
    Money   float32
    policy  string
    Payment Card
}

type Policy interface {
    Match(d Deal) bool
    Name() string
    MVP(d Deal) Policy
}

Binary‑Search Algorithm Based on Transaction Amount

Credit‑card spending is a way to extend accounts payable. The transaction fee (around 1%) is paid by the merchant.

From the consumer’s perspective, applying for multiple credit cards with different billing dates effectively forms a rotating credit cycle — a kind of personal “perpetual bond.”

Small transactions are mainly used to farm bank rewards. For example, Agricultural Bank offers 18 yuan − 0.3 yuan for the day’s first payment after activation; SPD Bank has 16 yuan − 0.01 yuan; GF Bank has n − 0.01 yuan, etc.

Based on personal experience, for payments over 1000 yuan, the best timing is the second day after the billing date — the optimal time‑series fixed point.

Therefore, the top‑level algorithm uses a binary decision on the transaction amount:

func (z Zeusro) Pay(deals []Deal) []Deal {
    // follow the rule and find the best policy
    discount := NewDiscountPolicys(DefaultDiscountPolicys)
    for i, deal := range deals {
        if deal.Money > SmallMoney {
            // BillingDatePolicy: spend on the day after billing date
            policy1 := NewBillingDatePolicy(z.Cards(deal.t))
            mvp := policy1.MVP(deal)
            best := mvp.BestCard
            deals[i].Payment = best
            deals[i].policy = policy1.Name()
        } else {
            // Maximum discount strategy: go wherever the discount is highest
            mvp := discount.MVP(deal)
            card := Card{Bank: mvp.Bank}
            deals[i].Payment = card
            deals[i].policy = mvp.Name()
        }
    }
    return deals
}

Billing‑Date‑Plus‑One Strategy

The fundamental tendency is to iterate over all credit cards and choose the one whose billing‑date‑plus‑one is closest.

func (p BillingDatePolicy) MVP(d Deal) BillingDatePolicy {
    if len(p.cards) == 0 {
        return p
    }

    now := d.t
    var bestCard *Card
    var bestDelta time.Duration = time.Hour * 24 * 31 // large initial value

    for i := range p.cards {
        c := &p.cards[i]
        delta := now.Sub(c.BillingDate.AddDate(0, 0, 1))
        if delta > 0 && delta < bestDelta {
            bestDelta = delta
            bestCard = c
        }
    }
    if bestCard != nil {
        p.BestCard = *bestCard
    }
    return p
}

Maximum‑Discount Transaction Strategy

Also called the “reward‑farming algorithm.” It is simple: follow the discount.

For example, with Agricultural Bank, after registering for the monthly activity, the first daily consumption of 18 yuan gives a 0.3 yuan discount; SPD Bank requires 16 yuan; GF Bank uses n − 0.01, and so on.

func (p *DiscountPolicys) MVP(d Deal) DiscountPolicy {
    var best DiscountPolicy
    var maxDiscount float32 = 0
    for _, policy := range p.Resource {
        if !policy.Match(d) {
            continue
        }
        if policy.Discount >= maxDiscount {
            continue
        }
        best = policy
        if best.N > 0 {
            maxDiscount = best.Discount
            // reduce resource pool
            best.N--
        }
    }
    if len(best.Bank) > 0 {
        p.Resource[best.Bank] = best
    }
    return best
}

The complete algorithm is in my self‑implemented OOOS.

0.3 Yuan per Day — I Will Farm Until Agricultural Bank Collapses

WeChat Pay の戦略は「最後の一筆」に基づいていますが、Alipay の支払順序は常に混乱しており、自動順序決済やシステム自動マッチングにおいても明らかなプラットフォーム側のバイアスが存在します。これらは私が望む結果ではありません。

そこで私は、自分自身で時間系列に基づくクレジットカード消費戦略を設計し、すべてのクレジットカード決済をコントロールすることにしました。

形式論理と定義

時間序列（Time Series）：時間の発生順に並べられたデータ点の集合。

時間序列オブジェクト：時間系列に基づくプログラミング言語のオブジェクト。時間は必ず最初のメンバーであること。

例：

type Deal struct {
	t       time.Time
	Money   float32
	policy  string
	Payment Card
}

時間系列関数（Time-series function）：時間系列に基づく関数。時間（または時間系列オブジェクト）が必ず最初の引数である。

例：

func (p *DiscountPolicys) MVP(d Deal) DiscountPolicy {
	var best DiscountPolicy
	var maxDiscount float32 = 0
	for _, policy := range p.Resource {
		if !policy.Match(d) {
			continue
		}
		if policy.Discount >= maxDiscount {
			continue
		}
		best = policy
		if best.N > 0 {
			maxDiscount = best.Discount
			//資源プールを1減らす
			best.N--
		}
	}
	if len(best.Bank) > 0 {
		p.Resource[best.Bank] = best
	}
	return best
}

// Cards はローカルファイルからクレジットカード情報を読み込む。
// フォーマット：1行につき「銀行名 账单日/最後還款日」。例：「农业银行 1/26」
func (z Zeusro) Cards(t time.Time) []Card {
    //省略
}

時間系列の不動点：クレジットカードの「账单日（締め日）の翌日」。

账单日翌日消費戦略：クレジットカードの締め日の翌日に消費する戦略。

最大割引消費戦略：各取引に対して最も割引額が大きい支払方法を選択する戦略。

基本タイプモデリング

クレジットカード、取引、取引戦略の定義。

type Card struct {
	Bank        string    //金融機関
	BillingDate time.Time //账单日（締め日）
	LastDate    time.Time //最後還款日（返済期限）
}

type Deal struct {
	t       time.Time
	Money   float32
	policy  string
	Payment Card
}

type Policy interface {
	Match(d Deal) bool
	Name() string
	MVP(d Deal) Policy
}

取引金額に基づく二分アルゴリズム

クレジットカードの消費は「应付账款（未払金）」を延長する行為と言えます。1% 前後の手数料は店舗側が負担します。

消費者の視点では、複数のクレジットカードを申し込み、異なる账单日を設定することで、回転する支払サイクルを作り出し、個人の「永続債（Perpetual bond）」のような仕組みを形成できます。

小額消費は主に「銀行のキャンペーンを最大限利用する」目的で行います。例えば：

农业银行：18 元 − 0.3 元
浦发银行：16 元 − 0.01 元
广发银行：n − 0.01 元

そして、私の実感では、1000 元を超える支払いについては、账单日翌日の消費が最適です。すなわち「時間系列の最適不動点」。

したがって上位アルゴリズムは、金額によって二分する方式を採用します：

func (z Zeusro) Pay(deals []Deal) []Deal {
	//follow the rule and find the best policy
	discount := NewDiscountPolicys(DefaultDiscountPolicys)
	for i, deal := range deals {
		if deal.Money > SmallMoney {
			//账单日翌日消費戦略 BillingDatePolicy
			policy1 := NewBillingDatePolicy(z.Cards(deal.t))
			mvp := policy1.MVP(deal)
			best := mvp.BestCard
			deals[i].Payment = best
			deals[i].policy = policy1.Name()
		} else {
			//最大取引割引戦略 DiscountPolicys
			mvp := discount.MVP(deal)
			card := Card{Bank: mvp.Bank}
			deals[i].Payment = card
			deals[i].policy = mvp.Name()
		}
	}
	return deals
}

账单日翌日消費戦略

基本方針は「全カードを走査し、账单日翌日に最も近いタイミングで決済する」ことです。

func (p BillingDatePolicy) MVP(d Deal) BillingDatePolicy {
	if len(p.cards) == 0 {
		return p
	}

	now := d.t
	var bestCard *Card
	var bestDelta time.Duration = time.Hour * 24 * 31 // 極大値

	for i := range p.cards {
		c := &p.cards[i]
		delta := now.Sub(c.BillingDate.AddDate(0, 0, 1))
		if delta > 0 && delta < bestDelta {
			bestDelta = delta
			bestCard = c
		}
	}
	if bestCard != nil {
		p.BestCard = *bestCard
	}
	return p
}

最大割引取引戦略

別名「羊毛狩り（ポイント稼ぎ）アルゴリズム」。
やることは単純で、「割引があるところに行く」だけです。

农业银行の例：

月次キャンペーン登録後、1日の最初の 18 元消費：0.3 元割引
浦发銀行：16 元
以此类推（などなど）

func (p *DiscountPolicys) MVP(d Deal) DiscountPolicy {
	var best DiscountPolicy
	var maxDiscount float32 = 0
	for _, policy := range p.Resource {
		if !policy.Match(d) {
			continue
		}
		if policy.Discount >= maxDiscount {
			continue
		}
		best = policy
		if best.N > 0 {
			maxDiscount = best.Discount
			//資源プールを1減らす
			best.N--
		}
	}
	if len(best.Bank) > 0 {
		p.Resource[best.Bank] = best
	}
	return best
}

See OOOS

1日 0.3 元、私は農業銀行が倒れるまで取り続ける

Стратегия WeChat Pay основана на «последней транзакции», тогда как порядок платежей Alipay всегда хаотичен. Автоматическое списание и системное сопоставление демонстрируют явный платформенный перекос. Всё это не соответствует тому, что мне нужно.

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

Формальная логика и определения

Временной ряд — последовательность точек данных, упорядоченных по времени.

Объект временного ряда — объект языка программирования, основанный на временном ряде. Время обязательно является первым полем.

Пример:

type Deal struct {
	t       time.Time
	Money   float32
	policy  string
	Payment Card
}

Функция временного ряда — это функция, основанная на временных данных. Параметр времени (или объект временного ряда) должен быть первым параметром.

Например:

func (p *DiscountPolicys) MVP(d Deal) DiscountPolicy {
	var best DiscountPolicy
	var maxDiscount float32 = 0
	for _, policy := range p.Resource {
		if !policy.Match(d) {
			continue
		}
		if policy.Discount >= maxDiscount {
			continue
		}
		best = policy
		if best.N > 0 {
			maxDiscount = best.Discount
			// уменьшение ресурсного пула
			best.N--
		}
	}
	if len(best.Bank) > 0 {
		p.Resource[best.Bank] = best
	}
	return best
}

// Cards загружает информацию о кредитных картах из локального файла.
// Формат: каждая строка — «банк дата_биллинга/дата_погашения».
// Например: «ABC 1/26»
func (z Zeusro) Cards(t time.Time) []Card {
    // опущено
}

Неподвижная точка временного ряда — второй день после даты выписки кредитной карты.

Стратегия расходования на второй день после даты выписки — стратегия использования кредитных карт на следующий день после даты выписки.

Стратегия максимальной скидки — для каждой операции выбирается способ оплаты с наибольшей скидкой.

Моделирование базовых типов

Кредитные карты, транзакции, стратегии транзакций.

type Card struct {
	Bank        string    // финансовая организация
	BillingDate time.Time // дата выписки
	LastDate    time.Time // крайний срок погашения
}

type Deal struct {
	t       time.Time
	Money   float32
	policy  string
	Payment Card
}

type Policy interface {
	Match(d Deal) bool
	Name() string
	MVP(d Deal) Policy
}

Бинарный алгоритм на основе суммы транзакции

Расходование по кредитной карте — это форма продления кредиторской задолженности. Комиссия за транзакцию (около 1%) оплачивается продавцом.

С точки зрения потребителя, оформление нескольких кредитных карт с разными датами выписки создаёт цикл вращающихся долгов — персональный «вечный долг» (perpetual bond).

Мелкие покупки в основном используются для получения бонусов банков. Например:

ABC: 18 – 0.3
SPDB: 16 – 0.01
CGB: n – 0.01

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

Поэтому общий алгоритм определяет стратегию на основе бинарного разбиения суммы:

func (z Zeusro) Pay(deals []Deal) []Deal {
	// follow the rule and find the best policy
	discount := NewDiscountPolicys(DefaultDiscountPolicys)
	for i, deal := range deals {
		if deal.Money > SmallMoney {
			// стратегия расходования на второй день после биллинга
			policy1 := NewBillingDatePolicy(z.Cards(deal.t))
			mvp := policy1.MVP(deal)
			best := mvp.BestCard
			deals[i].Payment = best
			deals[i].policy = policy1.Name()
		} else {
			// стратегия максимальной скидки
			mvp := discount.MVP(deal)
			card := Card{Bank: mvp.Bank}
			deals[i].Payment = card
			deals[i].policy = mvp.Name()
		}
	}
	return deals
}

Стратегия расходования на второй день после даты выписки

Основной принцип — перебрать все кредитные карты и выбрать ту, чья дата «выписка + 1 день» наиболее близка к текущему времени.

func (p BillingDatePolicy) MVP(d Deal) BillingDatePolicy {
	if len(p.cards) == 0 {
		return p
	}

	now := d.t
	var bestCard *Card
	var bestDelta time.Duration = time.Hour * 24 * 31 // большое значение

	for i := range p.cards {
		c := &p.cards[i]
		delta := now.Sub(c.BillingDate.AddDate(0, 0, 1))
		if delta > 0 && delta < bestDelta {
			bestDelta = delta
			bestCard = c
		}
	}
	if bestCard != nil {
		p.BestCard = *bestCard
	}
	return p
}

Стратегия максимальной скидки

Называется также алгоритмом «снятия сливок» — идти туда, где дают выгоду.

Например, в ABC после регистрации в ежемесячной акции первая ежедневная операция на 18 юаней даёт скидку 0.3 юаня.
SPDB — 16 юаней.
И так далее.

func (p *DiscountPolicys) MVP(d Deal) DiscountPolicy {
	var best DiscountPolicy
	var maxDiscount float32 = 0
	for _, policy := range p.Resource {
		if !policy.Match(d) {
			continue
		}
		if policy.Discount >= maxDiscount {
			continue
		}
		best = policy
		if best.N > 0 {
			maxDiscount = best.Discount
			// уменьшение ресурсного пула
			best.N--
		}
	}
	if len(best.Bank) > 0 {
		p.Resource[best.Bank] = best
	}
	return best
}

Полный алгоритм находится в моём собственном проекте OOOS。

Каждый день 0.3 юаня — буду получать, пока ABC не развалится

Go学长围观Java boy嘲讽C#

Thu, 27 Nov 2025 00:00:00 +0000

2013年的时候我就注册了博客园，第一从业编程语言是C#。

那会儿还有点流量。张善友是微软C#的中国步道师，当他还在腾讯垂死挣扎的时候我还差点信了，最后还是直接转go语言了。

2015年那会儿经常在网上跟java boy（JB）们互喷，现在想想还有点搞笑。

2020年在科兴科学园的电梯见过他一面，我当面说了一句“C#现在不是不行了吗？”他非常尴尬，但由于我们在同一个下行的电梯，于是出于礼貌敷衍了我一下。

形式逻辑和定义

皮裤原理：在回答别人问题的时候。不一定要告诉他真实的答案。很多时候，告诉他一个符合他想象的答案，可能效果更好。因为不是每一个人，都有勇气去接受他不懂的东西，愿意去理解他未知的领域。对绝大多数人来说，更倾向用已有的想法，去解释看到的一切。

AOT 动态库（Ahead-of-Time Dynamic Library）是 .NET 在 AOT 编译模式下生成的一类可被其它语言、引擎或平台调用的原生动态链接库（如 .dll、.so、.dylib）。它让 C# 代码能够像 C/C++ 编译的库一样被引用，不需要 .NET 运行时参与执行。

背景

　　.NET(以下简称N)心里想:现在企业级应用.NET用的少，但起码.net的语法特性优美，IDE宇宙最强吧，啧啧。

　　JAVA(以下简称J)心里想:我大JAVA遍地开花，什么Android,kotlin,scale，总之就是一个字:叼。

撕逼大战

事情的发生是从落魄N想学安卓开始。他接触了一段时候后，吐槽Android studio开始的。大家知道这玩意很多坑的，随后N就随带的埋怨其老东家Google起来最后连java也一起喷了起来。为了公正我们把喷点罗列出来。

项目无故卡死
模拟器横竖屏bug
呆逼虚拟机简直逗比，性能杀手
java不支持隐式变量声明

J: .net 都不知道是用来干嘛的。。大型集群不行。。开发人员不多。。。还要授权费。。

N: 存储方案也可以用MySQL啊 , 只是一些系统的集成方案都被java的占了

J: 因为当时.net还没开源啊 , 不可否认这就是开源的力量 , 最后还不是被逼到要开源

N心里想:尼玛这关开源什么关系。然后说:25台服务器撑起了stackoverflow.com，说集群不行是偏见吧。应用的瓶颈不能怪语言，是人的技术问题。

J: 集群可以的话，京东就不会忍痛改为Java了

N:那是语言设计问题好吗？关应用性能什么事？

J:那是语言设计的问题，不喜欢可以不用啊。而且你说的语法糖Java8已经支持了 . scale 也是支持语法糖

N: 你确定java8有隐式变量类型推断？

J:我说的是语法糖，你知道什么是语法糖吗？

N: var就不叫语法糖吗

J: 喜欢这种编程方式的可以使用这种语言(kotlin)，编译后一样是Java的字节码，各种新特性，这就是开源带来的好处，就算让.net抄，也可以带来压倒性的东西

N想:尼玛你自己打不过了竟然召唤你的基友，不同种语言好吗？我.NET还能编译成MSIL呢我是不是该把他给叫出来.MSbuild都开源了真他妈跨平台编译了我是不是也得把他召唤出来，但是出于逼格，N说: 说的好像java比.NET之前就有拉姆达表达式似得 .

J: 说的好像整个运行机制不像Java一样

路人甲及时补刀:你那么喜欢.net还学安卓干什么

N知道事态不对了，自己进了狼群了，赶紧身退: 好坏都是比较产生的，拿自己好处和对方短处比。没有可比性，反过来也是一样。不理智，只能说各有千秋。不让人有批评意见的社会是不会有进步空间的，好吗？你活在天朝不满意政府难道你就非得投河自尽吗，还不是得苟延残喘下去。散了吧，不合你们扯了

J看起来很不服气，继续鞭尸一把: 切，你在一个都是用Java的群数落Java，不打你打谁，语言无分好坏，但你在人家的地盘数落人家的吃饭工具，连做人的基本礼貌都不会，还要谈理智？重点是自己又不是很懂Java，还在自己说Java怎样，不懂Android的虚拟机，还在说Android的虚拟机？？

没错，被鞭尸的人就是我。针对最后一句话，我想说，呆逼虚拟机低能，大家自己看新闻，很好的话Google后来搞ART干嘛？自己的东西不好就不让别人喷，这是思想狭隘的表现。我想说的是，.NET不好的地方多了去了，但我不会和你们说，但你们说中那就说中了憋，这是事实，我为什么有能力去反驳？哈哈。当然，最后这段话我只是在这里讲，因为我想起了皮裤原理.

这些人极度自负。

来自2025-11-27的思考

以上内容整理自2015-04-27 23:48在博客园发表的文章，从今天看来，博客园已经快倒闭了，而张善友先生创办了深圳友浩达，不变的是依旧当着微软MVP。从TIOBE 上看，C# 目前正在逐步蚕食 Java 的市场份额，而且现在 .net core 可以通过AOT 动态库编译成纯原生机器码，供以下语言使用：

C/C++
Go
Rust
Python（通过FFI）
Unity Native Plugin
iOS / Android Native 以C++来说，相当于我可以用 .NET core 写 C++代码，这波操作属于是直接偷家了。微软不亏是编程语言界第一邪恶组织。

而且最近又有了新的命名空间，真是可喜可贺：

IAsyncEnumerable 异步数据流处理
System.Threading.Channels “借鉴”golang 的channel
EFCore.BulkExtensions ORM 批量写入

参考链接

[1] 月经贴:当落魄的.NET基佬遇上不可一世的JAVA派 developer https://www.cnblogs.com/zeusro/p/4461808.html

[2] 月薪集中8k-17k，跳槽率不足四成，Java稳居榜首… https://zhuanlan.zhihu.com/p/711520388

[3] Get up to speed with .NET: What new for .NET Conf 2022 https://developer.microsoft.com/en-us/reactor/events/17372/

Back then the platform still had some traffic. Zhang Shanyou was Microsoft’s C# evangelist in China. When he was still struggling at Tencent, I nearly believed him. In the end, I switched directly to the Go language.

In 2015, I often fought online with “java boy” (~~junky boy~~). Thinking back now, it’s a bit funny.

In 2020, I met him once in the elevator at Kexing Science Park. I said to him: “Isn’t C# not doing so well now?” He looked very embarrassed, but since we were in the same downward elevator, he responded politely.

Formal Logic and Definitions

*Leather Pants Principle **:
When answering someone’s question, you don’t always need to tell them the real answer. Very often, giving them an answer that *matches their imagination works better. Because not everyone has the courage to accept that they don’t understand something or is willing to explore an unknown field. Most people prefer to use their existing beliefs to explain everything they see.

AOT Dynamic Library (Ahead-of-Time Dynamic Library) is a type of native dynamic library (such as .dll, .so, .dylib) generated by .NET under AOT compilation mode. It allows C# code to be referenced like C/C++ libraries, without requiring the .NET runtime to execute.

Background

.NET (hereinafter referred to as N) thinks: enterprises may not use .NET much nowadays, but at least the syntax is elegant, and its IDE is the strongest in the universe.

JAVA (hereinafter referred to as J) thinks: Java is everywhere — Android, Kotlin, Scala — in short: awesome.

The Flame War

The story began when the declining N wanted to learn Android. After some experience, he started complaining about Android Studio. Everyone knows how buggy it can be. Naturally, N also blamed Google and eventually complained about Java as well. For fairness, here are the complaints:

Projects freeze without reason
Emulator rotation bugs
Dalvik VM is ridiculous, a performance killer
Java doesn’t support implicit variable declaration

J: “.NET is practically useless… can’t handle large clusters… few developers… needs licensing…”

N: “Storage solutions can use MySQL too. It’s just that many enterprise integrations were taken by Java.”

J: “Because .NET wasn’t open-source at that time. This is the power of open source. In the end .NET was forced to open source anyway.”

N thinks: “What does open-source have to do with this?”
Then says: “25 servers support stackoverflow.com. Saying .NET can’t scale is prejudice. Performance bottlenecks are about people, not languages.”

J: “If .NET scaled well, JD.com wouldn’t have painfully switched to Java.”

N: “That’s a language design issue! Not application performance!”

J: “If you don’t like the design, don’t use it. And the syntax sugar you mentioned already exists in Java 8. Scala also supports syntax sugar.”

N: “Are you sure Java 8 supports implicit type inference?”

J: “I said syntax sugar. Do you even know what that means?”

N: “Isn’t var syntax sugar?”

J: “If you like that style, you can use Kotlin. It compiles to Java bytecode with all the new features. This is the power of open source. Even if .NET copies, it still can’t compete.”

N thinks: “Damn, you can’t win so you summon your allied language? Different languages, okay? .NET can compile to MSIL too. Should I summon MSBuild next? MSBuild is open-source and cross-platform now. Should I bring that up?”
But to maintain some dignity, N says: “You make it sound like Java had lambda expressions earlier than .NET.”

J: “You make it sound like your runtime mechanism is not similar to Java’s.”

Bystander: “If you love .NET so much, why are you learning Android?”

N realizes the situation is bad — he walked into a den of Java fans. He quickly retreats:
“Good and bad are relative. Comparing your strengths with others’ weaknesses is meaningless. Each language has its merits. A society without criticism cannot progress. If you’re unhappy with the government, will you jump into a river? No — you still struggle on. Let’s stop here, this is pointless.”

J is not satisfied and strikes again:
“Cut it out. You insult Java in a Java group — who wouldn’t hit you? Languages have no inherent good or bad, but you insult people’s livelihood tools on their turf. That’s not basic manners. And you’re not even good at Java, yet you judge Java? You don’t understand Android’s VM yet you criticize it?”

Yes, the one being beaten was me. Regarding the last sentence: Dalvik VM really was awful. Just look at the news — why else did Google create ART later? If something is bad, others can point it out. Pretending criticism is forbidden is narrow-minded. .NET has many flaws too. I just didn’t mention them. But if someone points them out, that’s fair — it’s the truth. Why can’t I refute? Haha. Of course, I only say this here, because I remembered the Leather Pants Principle.

These people were extremely arrogant.

Thoughts from 2025-11-27

The above content is compiled from an article published on cnblogs on April 27, 2015 at 23:48. Judging from today’s situation, cnblogs is almost defunct, while Mr. Zhang Shanyou founded Shenzhen Youhaoda, and remains a Microsoft MVP. According to TIOBE, C# is gradually eroding Java’s market share, and now .NET Core can be compiled into pure native machine code via AOT dynamic libraries for use by the following languages:

    •  C/C++
    •  Go
    •  Rust
    •  Python (via FFI)
    •  Unity Native Plugin
    •  iOS / Android Native

For C++ developers, this means I can write C++-callable libraries using .NET Core — essentially infiltrating their home turf. Microsoft truly is the most “evil” organization in the programming language world.

References

[1] 月经贴:当落魄的.NET基佬遇上不可一世的JAVA派 developer https://www.cnblogs.com/zeusro/p/4461808.html

[2] 月薪集中8k-17k，跳槽率不足四成，Java稳居榜首… https://zhuanlan.zhihu.com/p/711520388

[3] Get up to speed with .NET: What new for .NET Conf 2022 https://developer.microsoft.com/en-us/reactor/events/17372/ In 2013, I registered my Blog Garden (博客园) account. My first professional programming language was C#.

2013年、私はすでにブログ园（cnblogs）に登録しており、最初に使用した職業プログラミング言語は C# でした。

当時はまだ多少のアクセスがありました。张善友氏は Microsoft C# の中国エバンジェリストとして知られており、彼がまだ Tencent 内で苦戦していた頃、私は少しだけ信じかけたこともありました。しかし、最終的には Go 言語へと乗り換えました。

2015年の頃、私はインターネット上で java boy（JB）たちとよく口論していました。今思えば少し滑稽でもあります。

2020年、科兴科学園のエレベーターで偶然彼を見かけました。私は彼に向かって「今の C# ってもうダメなんじゃないの？」と直接言いました。彼は非常に気まずそうな顔をしていましたが、同じ下りエレベーターに乗っていたため、礼儀として軽く返事してくれました。

形式論理と定義

皮パン原理（Leather Pants Principle）：
他人の質問に答えるとき、必ずしも真実だけを語る必要はない。多くの場合、相手が思い込みたい答えを与えたほうが効果的なことがある。なぜなら、多くの人は自分が理解できないものを受け入れる勇気がなく、未知を理解しようともしないからである。人は大抵、既に持っている概念で世界を解釈しようとする。

AOT Dynamic Library（Ahead-of-Time Dynamic Library）とは、.NET の AOT コンパイルモードによって生成されるネイティブ動的リンクライブラリ（.dll / .so / .dylibなど）の一種であり、C/C++製ライブラリと同じように他の言語・プラットフォームから呼び出せ、.NET ランタイムを必要としない。

背景

　　.NET（以下 N）の心の声：「今どき企業システムで .NET を使うところは減っている。でも少なくとも文法の美しさと IDE の強さは宇宙最強でしょ？」

　　JAVA（以下 J）の心の声：「我らが JAVA は天下無双、Android、Kotlin、Scala、とにかく ―― 最強。」

炎上の始まり

N が Android を学び始めたことが発端でした。少し触ってみたものの Android Studio の不具合に文句を言い始めました。あの IDE に問題が多いのは周知の事実です。そして N は Google にも文句を言いはじめ、最終的には Java をも巻き添えにしてしまいました。公平を期すために N の不満を挙げます。

プロジェクトが無理由でフリーズ
エミュレーターの縦横回転バグ
Dalvik VM が低性能で笑いもの
Java に暗黙的型推論がない

J: 「.NETって何に使うの？大規模クラスタは無理だし… 開発者も少ない… しかもライセンス料？」

N: 「MySQL も使えるし、Java が流行ったのは統合ソリューションが早かっただけ」

J: 「当時 .NET はオープンソースじゃなかったからね。それがオープンソースの力。最後は .NET も開かざるを得なかった」

N（心）：「それ関係ないだろ…」
口では：「stackoverflow.com は25台のサーバーで動いてる。クラスタ弱いって偏見だろ。技術力の問題だ。」

J: 「本当に強いなら JD（京东）は Java に移行してないよ」

N: 「それは言語設計の問題で性能とは無関係！」

J: 「それも含めて言語設計。嫌なら使うな。Java8 には syntax sugar があるし、Scala にもある」

N: 「Java8 に暗黙的型推論あるの？」

J: 「syntax sugar の意味わかってる？」

N: 「var も syntax sugar だろ」

J: 「そういう書き方が好きなら Kotlin 使えば？Bytecode は Java と同じ。オープンソースの利点。たとえ .NET が真似しても Java の優位は揺るがない」

N（心）：「お前1人で勝てないから Kotlin 呼ぶなよ… .NET だって MSIL あるぞ… MSBuild だってクロスプラットフォームだぞ…」
でもプライドのために言ったのは：「まるで Java がラムダを先に発明したかのように言うなよ」

J: 「まるで Java の VM が .NET と違うとでも？」

通りすがり: 「.NET が好きなら Android なんて学ぶなよ」

N は危機を悟り撤退：
「良い悪いは比較の中にしかない。どちらも長所短所がある。批判のない社会に進歩はない。政府が気に入らないなら、川に飛び込むのか？生きるしかないだろ。以上、解散」

J、止まらず追撃：
「Java コミュニティで Java をけなすとか礼儀ゼロ。しかも Java の理解浅いのに文句？Android VM も知らないくせに？」

はい。ボコられていたのは私です。
最後のセリフに答えると：Dalvik VM が微妙なのはニュース見れば分かる。だから Google は ART を作った。欠点に触れられたくないのは心が狭い。もちろん .NET にだって欠点はたくさんある。でも指摘されたら認める。それだけ。
この言葉はここにだけ書く。なぜなら皮パン原理を思い出したから。

彼らは極端に自信過剰だった。

2025-11-27 からの考察

以上は 2015-04-27 23:48 にブログ园へ投稿した記事をまとめたものです。
今見ると、博客园はほぼ崩壊状態、張善友氏は深圳友浩达を創業し、今も Microsoft MVP。
TIOBE の指標によれば、C# は Java のシェアを徐々に奪いつつある。
今や .NET Core は AOT Dynamic Library として完全なネイティブコードへコンパイルでき、以下の言語から利用可能：

C/C++
Go
Rust
Python（FFI）
Unity Native Plugin
iOS / Android Native

C++ 視点で言えば、.NET Core で C++ コードを書けるようなもの。これは完全に「裏取り」です。
Microsoft はプログラミング界で最も邪悪な組織 No.1 に相応しい。

そして最近、新しい namespace も追加されている。素晴らしい：

IAsyncEnumerable ― 非同期データストリーム
System.Threading.Channels ― Go の channel を「参考に」
EFCore.BulkExtensions ― ORM バルク書き込み

参考リンク

[1] 月经贴:当落魄的.NET基佬遇上不可一世的JAVA派 developer https://www.cnblogs.com/zeusro/p/4461808.html

[2] 月薪集中8k-17k，跳槽率不足四成，Java稳居榜首… https://zhuanlan.zhihu.com/p/711520388

[3] Get up to speed with .NET: What new for .NET Conf 2022 https://developer.microsoft.com/en-us/reactor/events/17372/

В 2013 году я уже зарегистрировался в Blog Garden, первый профессиональный язык программирования был C#.

Тогда ещё был некоторый трафик. 张善友 был евангелистом Microsoft C# в Китае. Когда он ещё боролся в Tencent, я почти поверил ему, но в итоге напрямую перешёл на язык go.

В 2015 году я часто спорил в интернете с java boy (JB), теперь думаю, это немного смешно.

В 2020 году я встретил его один раз в лифте в Kexing Science Park. Я сказал ему в лицо: «Разве C# сейчас не в порядке?» Он выглядел очень неловко, но поскольку мы были в одном нисходящем лифте, он из вежливости ответил мне.

Формальная логика и определения

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

AOT динамическая библиотека (Ahead-of-Time Dynamic Library) — это тип нативной динамической библиотеки (такой как .dll, .so, .dylib), генерируемой .NET в режиме компиляции AOT. Она позволяет коду C# быть вызванным, как библиотеки C/C++, без участия среды выполнения .NET.

Фон

.NET (далее N) думает: теперь в корпоративных приложениях .NET используется мало, но по крайней мере синтаксические особенности .NET элегантны, IDE сильнейшая во вселенной, верно?

JAVA (далее J) думает: мой великий JAVA везде, Android, kotlin, scale, одним словом: круто.

Война пламени

Происшествие началось с того, что упавший N хотел изучать Android. После некоторого контакта он начал жаловаться на Android Studio. Все знают, что эта штука имеет много проблем, затем N также начал жаловаться на своего старого работодателя Google, и в итоге также обрушился на java. Для справедливости перечислим жалобы.

Проект без причины зависает
Баг поворота эмулятора
Глупый виртуальный компьютер просто смешной, убийца производительности
java не поддерживает неявное объявление переменных

J: .net вообще не знаю, для чего используется… Большие кластеры не работают… Разработчиков мало… Ещё нужна плата за лицензию…

N: Решения хранения также могут использовать MySQL, просто некоторые системные интеграционные решения были заняты java.

J: Потому что .net тогда ещё не был открыт, нельзя отрицать, это сила открытого исходного кода, в итоге всё равно был вынужден открыться.

N думает: чёрт, какое это имеет отношение к открытому исходному коду. Затем говорит: 25 серверов поддерживают stackoverflow.com, говорить, что кластеры не работают, — это предрассудок. Узкое место приложения не может винить язык, это проблема человеческих технологий.

J: Если кластеры могут работать, JD.com не стал бы болезненно переходить на Java.

N: Это проблема дизайна языка, хорошо? Какое отношение это имеет к производительности приложения?

J: Это проблема дизайна языка, не нравится — не используй. И синтаксический сахар, о котором ты говорил, Java8 уже поддерживает. scale также поддерживает синтаксический сахар.

N: Ты уверен, что Java8 имеет неявный вывод типа переменных?

J: Я сказал синтаксический сахар, ты знаешь, что такое синтаксический сахар?

N: var не называется синтаксическим сахаром?

J: Если нравится такой стиль программирования, можно использовать этот язык (kotlin), после компиляции это тот же байт-код Java, все новые функции, это преимущество открытого исходного кода, даже если .net скопирует, также может принести подавляющие вещи.

N думает: чёрт, ты сам не можешь победить, так вызываешь своего друга, разные языки, хорошо? Я .NET также могу скомпилировать в MSIL, должен ли я его вызвать? MSbuild уже открыт, действительно кроссплатформенная компиляция, должен ли я также вызвать его, но из-за стиля N говорит: звучит так, будто java раньше .NET имел лямбда-выражения.

J: Звучит так, будто весь механизм выполнения не похож на Java.

Прохожий своевременно нанёс удар: если ты так любишь .net, зачем изучать Android?

N знает, что ситуация неправильная, сам попал в волчью стаю, быстро отступает: хорошее и плохое — это результат сравнения, брать свои преимущества и сравнивать с недостатками другого. Нет сравнимости, наоборот тоже. Нерационально, можно только сказать, что у каждого есть свои достоинства. Общество, не позволяющее иметь критические мнения, не будет иметь пространства для прогресса, хорошо? Ты живёшь в Поднебесной, недоволен правительством, разве ты должен обязательно броситься в реку и покончить с собой? Всё равно нужно влачить жалкое существование. Расходимся, не буду с вами спорить.

J выглядит очень недовольным, продолжает добивать: чёрт, ты в группе, где все используют Java, ругаешь Java, кого ещё бить, если не тебя? Языки не делятся на хорошие и плохие, но ты на чужой территории ругаешь инструменты для заработка, даже базовой вежливости не знаешь, ещё говорить о рациональности? Главное, что сам не очень понимаешь Java, ещё говоришь, что Java такой-то, не понимаешь виртуальную машину Android, ещё говоришь о виртуальной машине Android??

Да, тот, кого избивали, — это я. Относительно последнего предложения, я хочу сказать, глупая виртуальная машина низкоэффективна, все сами смотрят новости, если бы было хорошо, зачем Google потом делал ART? Своё плохое не позволяет другим ругать, это проявление узости мышления. Я хочу сказать, у .NET плохих мест много, но я не буду вам говорить, но если вы сказали, значит сказали, это факт, почему я должен иметь способность опровергать? Хаха. Конечно, последний абзац я говорю только здесь, потому что вспомнил принцип кожаных штанов.

Эти люди крайне самоуверенны.

Размышления от 2025-11-27

Вышеизложенное содержание составлено из статьи, опубликованной в Blog Garden 2015-04-27 23:48, с сегодняшней точки зрения Blog Garden уже почти закрылся, а г-н 张善友 основал Shenzhen Youhaoda, неизменным остаётся то, что всё ещё является Microsoft MVP. Согласно TIOBE, C# постепенно захватывает долю рынка Java, и теперь .net core может быть скомпилирован в чистый нативный машинный код через AOT динамическую библиотеку для использования следующими языками:

C/C++
Go
Rust
Python (через FFI)
Unity Native Plugin
iOS / Android Native

Для C++ это эквивалентно тому, что я могу писать код C++ с помощью .NET core, эта операция напрямую крадёт дом. Microsoft действительно является первой злой организацией в мире языков программирования.

И недавно появились новые пространства имён, действительно радостно:

IAsyncEnumerable обработка асинхронных потоков данных
System.Threading.Channels «заимствование» channel из golang
EFCore.BulkExtensions пакетная запись ORM

Ссылки

[1] Месячный пост: когда упавший .NET гей встречает непобедимую JAVA фракцию developer https://www.cnblogs.com/zeusro/p/4461808.html

[2] Зарплата сосредоточена на 8k-17k, частота смены работы менее 40%, Java стабильно на первом месте… https://zhuanlan.zhihu.com/p/711520388

[3] Get up to speed with .NET: What new for .NET Conf 2022 https://developer.microsoft.com/en-us/reactor/events/17372/