https://www.ietf.org/id/draft-dekater-panrg-scion-overview-02.html
SCION (Scalability, Control, and Isolation On Next-generation networks)，次世代 BGP。略读了一下：
- AS 带证书，可以给子 AS 签子证书，每个 AS 都可以配置自己独立的 root of trust CA。
- 每个 AS 给的不再是下一跳，而是 path-segment construction beacons (PCBs)，可以认为是一段路径。路径（PCB）上的每个 AS 都会对这个 PCB 签名，每个 AS 可以独立的配置允许的转发路径规则。
- 发送端可以组合最多 3 个 PCB 来决定发送路径，类似于 source routing，但是同时又能验证 PCB 符合 root of trust 以及各个 AS 都接受这个 PCB。
实现：https://github.com/scionproto/scion
但是建议看 https://www.scionlab.org/
SCION (Scalability, Control, and Isolation On Next-generation networks)，次世代 BGP。略读了一下：
- AS 带证书，可以给子 AS 签子证书，每个 AS 都可以配置自己独立的 root of trust CA。
- 每个 AS 给的不再是下一跳，而是 path-segment construction beacons (PCBs)，可以认为是一段路径。路径（PCB）上的每个 AS 都会对这个 PCB 签名，每个 AS 可以独立的配置允许的转发路径规则。
- 发送端可以组合最多 3 个 PCB 来决定发送路径，类似于 source routing，但是同时又能验证 PCB 符合 root of trust 以及各个 AS 都接受这个 PCB。
实现：https://github.com/scionproto/scion
但是建议看 https://www.scionlab.org/
Read It Never
https://www.ietf.org/id/draft-dekater-panrg-scion-overview-02.html SCION (Scalability, Control, and Isolation On Next-generation networks)，次世代 BGP。略读了一下： - AS 带证书，可以给子 AS 签子证书，每个 AS 都可以配置自己独立的 root of trust CA。 - 每个 AS 给的不再是下一跳，而是 path-segment construction…
在生产环境使用 SCION 的是 Swiss National Bank, 今年新的 The Complete Guide to SCION (https://doi.org/10.1007/978-3-031-05288-0) 相对 2017 年的 SCION: A Secure Internet Architecture 有一些设计更新和更详细的细节。
Read It Never
https://doi.org/10.1145/2901318.2901326 Linux 内核调度的 casestudy，比较全面的介绍了现代 Linux 内核调度的方法，同时几个调度的 bug 也对于在现代硬件下调度系统的复杂度有比较好的展现。
https://lwn.net/SubscriberLink/909611/447c4722188eb46b/
一个简略的关于 Intel 大小核调度是怎么实现的介绍，其他关于现代操作系统调度的复杂程度可以参见上面这篇 "The Linux scheduler: a decade of wasted cores"。
“And you have to realize that there are not very many things that have aged as well as the scheduler. Which is just another proof that scheduling is easy.” - Linus Torvalds, 2001
一个简略的关于 Intel 大小核调度是怎么实现的介绍，其他关于现代操作系统调度的复杂程度可以参见上面这篇 "The Linux scheduler: a decade of wasted cores"。
“And you have to realize that there are not very many things that have aged as well as the scheduler. Which is just another proof that scheduling is easy.” - Linus Torvalds, 2001
https://gvisor.dev/blog/2022/10/24/buffer-pooling/
How we Eliminated 99% of gVisor Networking Memory Allocations with Enhanced Buffer Pooling。在 GC 语言里手动管理内存提高了 gVisor 网络协议栈 30+% 的吞吐（笑）。当然不止简单的手动管理内存（引用计数），还对 buffer 分页，实现了 copy on write，新 buffer 的实现可以看：https://github.com/google/gvisor/tree/master/pkg/bufferv2 。并且 GC 语言本身依然保证了内存安全性。
How we Eliminated 99% of gVisor Networking Memory Allocations with Enhanced Buffer Pooling。在 GC 语言里手动管理内存提高了 gVisor 网络协议栈 30+% 的吞吐（笑）。当然不止简单的手动管理内存（引用计数），还对 buffer 分页，实现了 copy on write，新 buffer 的实现可以看：https://github.com/google/gvisor/tree/master/pkg/bufferv2 。并且 GC 语言本身依然保证了内存安全性。
http://www.melconway.com/Home/Committees_Paper.html
How Do Committees Invent? 相对于论证更多的是对现实系统架构的观察得出的假说："Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."
或者使用原文的另一个说法，一个组织设计的系统与组织本身是同构的。
How Do Committees Invent? 相对于论证更多的是对现实系统架构的观察得出的假说："Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."
或者使用原文的另一个说法，一个组织设计的系统与组织本身是同构的。
https://netflixtechblog.com/2721924a2822
Seeing through hardware counters: a journey to threefold performance increase。这是我第一次看到在生产上（Netflix）因为字段没有 padding 导致的巨大性能差异的分析，是标准的不同核心互相不停的 invalidate L1 cache 的场景。
Seeing through hardware counters: a journey to threefold performance increase。这是我第一次看到在生产上（Netflix）因为字段没有 padding 导致的巨大性能差异的分析，是标准的不同核心互相不停的 invalidate L1 cache 的场景。
https://doi.org/10.1145/3292500.3330651
MOBIUS: Towards the Next Generation of Query-Ad Matching in Baidu’s Sponsored Search。百度新的广告推荐系统，主要由两部分变化：
- 在排序层加入了一个额外的相关性模型保证相关性超过阈值
- 可能由于排序层大幅增加了计算量，在匹配层额外考虑了点击率来达到候选集减小的情况下保证召回率
其实我本来看图把三层揉在一起了以为是他们做了一套 e2e 的方案，结果那个图的意思是打破了原来各层的单目标优化，而且相关性还是得靠卡阈值。论文的很大一部分重点在于如何训练出一个有效的相关性模型。
题外话，这个三层架构（或者两层，召回和排序，百度内部架构把排序额外拆成了粗排和精排两层）是很多推荐系统通病的来源。这个架构有一个隐含假设：用户只会点击相关的东西，所以点击率 / 播放时长预估本身保证了相关性，但是这个假设对于高于全局平均优化目标的条目会失效（比如 YouTube 有一段时间给所有人都推荐某钢琴视频）。这个推荐结果在排序系统逻辑上是成立的：如果给所有人都推荐这个视频，所有人对这个视频的平均播放时长是高于用户的平均播放时长的（因为 YouTube 的单目标优化是优化播放时长），那么给所有人都推荐这个视频符合全局的优化目标。这个现象的出现是因为 1、排序层缺少相关性的目标 2、这类单目标优化很难学到负权重。百度这个模型解决了怎么学到负相关性和怎么以相关性作为优化目标，就是最后卡个阈值就发论文了还是有点太 it works 了（
MOBIUS: Towards the Next Generation of Query-Ad Matching in Baidu’s Sponsored Search。百度新的广告推荐系统，主要由两部分变化：
- 在排序层加入了一个额外的相关性模型保证相关性超过阈值
- 可能由于排序层大幅增加了计算量，在匹配层额外考虑了点击率来达到候选集减小的情况下保证召回率
其实我本来看图把三层揉在一起了以为是他们做了一套 e2e 的方案，结果那个图的意思是打破了原来各层的单目标优化，而且相关性还是得靠卡阈值。论文的很大一部分重点在于如何训练出一个有效的相关性模型。
题外话，这个三层架构（或者两层，召回和排序，百度内部架构把排序额外拆成了粗排和精排两层）是很多推荐系统通病的来源。这个架构有一个隐含假设：用户只会点击相关的东西，所以点击率 / 播放时长预估本身保证了相关性，但是这个假设对于高于全局平均优化目标的条目会失效（比如 YouTube 有一段时间给所有人都推荐某钢琴视频）。这个推荐结果在排序系统逻辑上是成立的：如果给所有人都推荐这个视频，所有人对这个视频的平均播放时长是高于用户的平均播放时长的（因为 YouTube 的单目标优化是优化播放时长），那么给所有人都推荐这个视频符合全局的优化目标。这个现象的出现是因为 1、排序层缺少相关性的目标 2、这类单目标优化很难学到负权重。百度这个模型解决了怎么学到负相关性和怎么以相关性作为优化目标，就是最后卡个阈值就发论文了还是有点太 it works 了（
https://engineering.fb.com/2022/06/08/core-data/cache-invalidation/
Cache made consistent: Meta’s cache invalidation solution。有点标题党，meta 并不是解决了 cache invalidation 的问题，而是把解决这个这个问题的角度从正确性问题转换成了可用性问题。要解决可用性问题，首先要做的是定义出问题的可观察指标。meta 建立了一套对于缓存一致性的监控系统，把问题从 “保证系统逻辑是正确的” 转变成了 “尽可能提高 cache 一致性指标”，对这个问题来说是个挺新颖的角度。
For any anomaly in a stateful service, it is an anomaly only if clients can observe it one way or the other. Otherwise, we argue that it doesn’t matter at all.
Cache made consistent: Meta’s cache invalidation solution。有点标题党，meta 并不是解决了 cache invalidation 的问题，而是把解决这个这个问题的角度从正确性问题转换成了可用性问题。要解决可用性问题，首先要做的是定义出问题的可观察指标。meta 建立了一套对于缓存一致性的监控系统，把问题从 “保证系统逻辑是正确的” 转变成了 “尽可能提高 cache 一致性指标”，对这个问题来说是个挺新颖的角度。
For any anomaly in a stateful service, it is an anomaly only if clients can observe it one way or the other. Otherwise, we argue that it doesn’t matter at all.
https://www.sigarch.org/fast-memcpy-a-system-design/
Fast memcpy, A System Design。优化目标是 CPU 的每个 cycle 移动 16 bytes，从 CPU 的角度来考虑达到这个目标 CPU 需要提供什么样的能力。也可以看 ClickHouse 的 memcpy 实现（的注释）：https://github.com/ClickHouse/ClickHouse/blob/master/base/glibc-compatibility/memcpy/memcpy.h
大体上分成三个阶段：
- Small Size: 复制的长度小于一次 load 的宽度（16 bytes）
- Medium Size: 复制的长度小于完整的一轮循环展开（如果循环展开 8 次，就是 128 bytes）
- Large Size: 在对齐的内存上循环展开复制
Fast memcpy, A System Design。优化目标是 CPU 的每个 cycle 移动 16 bytes，从 CPU 的角度来考虑达到这个目标 CPU 需要提供什么样的能力。也可以看 ClickHouse 的 memcpy 实现（的注释）：https://github.com/ClickHouse/ClickHouse/blob/master/base/glibc-compatibility/memcpy/memcpy.h
大体上分成三个阶段：
- Small Size: 复制的长度小于一次 load 的宽度（16 bytes）
- Medium Size: 复制的长度小于完整的一轮循环展开（如果循环展开 8 次，就是 128 bytes）
- Large Size: 在对齐的内存上循环展开复制
https://dl.acm.org/doi/10.1145/3510003.3510111
"Did you miss my comment or what?": understanding toxicity in open source discussions。对 GitHub 上的 toxic 行为做了一些采样归类和总结，只能说就算同为开源项目维护者有时候也未必能对其他维护者共情。
"Did you miss my comment or what?": understanding toxicity in open source discussions。对 GitHub 上的 toxic 行为做了一些采样归类和总结，只能说就算同为开源项目维护者有时候也未必能对其他维护者共情。
https://www.unison-lang.org/learn/the-big-idea/
Unison。基于 content-addressed code 来设计的语言，这样让对任何函数的 reference 天然的具有了不可变的特性，无论其被分发到什么环境中。其文档列举了一些这么做的应用实例。
Unison。基于 content-addressed code 来设计的语言，这样让对任何函数的 reference 天然的具有了不可变的特性，无论其被分发到什么环境中。其文档列举了一些这么做的应用实例。
https://slsa.dev/spec/v0.1/threats
Supply chain Levels for Software Artifacts: Threats and mitigations。总结了从开发者到终端用户所有可能的攻击区间和一些对应的攻击实例，以及提供了对应的减缓其影响的方式。SLSA 在接下来几年有可能会成为缓解供应链攻击的行业方案。
Supply chain Levels for Software Artifacts: Threats and mitigations。总结了从开发者到终端用户所有可能的攻击区间和一些对应的攻击实例，以及提供了对应的减缓其影响的方式。SLSA 在接下来几年有可能会成为缓解供应链攻击的行业方案。
https://thenewstack.io/internode-cache-thrashing-hunting-a-numa-performance-bug/
Internode Cache Thrashing: Hunting a NUMA Performance Bug。无意中跨 NUMA 节点写入内存导致的性能问题。很少看到完整的定位这类 NUMA 性能问题的调试过程，关于 NUMA 为什么会产生这类性能问题可以参考：https://queue.acm.org/detail.cfm?id=2513149 经验数字来说 NUMA 相对 L1 cache 来说一次 load 的成本可能是 300 倍。
Internode Cache Thrashing: Hunting a NUMA Performance Bug。无意中跨 NUMA 节点写入内存导致的性能问题。很少看到完整的定位这类 NUMA 性能问题的调试过程，关于 NUMA 为什么会产生这类性能问题可以参考：https://queue.acm.org/detail.cfm?id=2513149 经验数字来说 NUMA 相对 L1 cache 来说一次 load 的成本可能是 300 倍。
https://www.usenix.org/publications/loginonline/prodspec-and-annealing-intent-based-actuation-google-production
Prodspec and Annealing: Intent-based actuation for Google Production。 对 Google 的生产管理系统的概述，可以认为是 Kubernetes 的内部版本。这篇文章对阐述 Kubernetes 的抽象模型的设计原则比大多数 Kubernetes 的介绍文章都更清晰。
一个典型的传统部署流程是 "canary in cluster X, then deploy N at a time in clusters Y and Z, run a test, and so on."，最早可能是手动，然后可能会有一些脚本来自动化。这么做最大的问题是每个服务往往都有特有的部署流程，一个尽可能去泛化不同的可能步骤的部署系统最后总会变成一个足够执行任何行为的脚本语言。另一个让这个方式难以扩展的原因是每一个步骤都是一个将系统从状态 A 转化到状态 B 的带有副作用的操作，但是要精确的确定系统处在状态 A 和系统达到了状态 B 都是非常困难的，往往最后都依赖于没有写明的隐含状态。
要解决这个问题最显然（2023 年，这个系统设计于 2015 年）的方式就是把最终想要达到的状态（intention）声明到 spec 里，然后再设计一个闭环控制系统来不断生成改变系统状态的操作，直到系统达到了声明的状态。Kubernetes 和 Prodspec/Annealing 都设计了一个非常类似于 Entity-Component-System（ECS）的系统：Prodspec/Annealing 中 Partitions = Entity，Assets = Component，System = Annealing。比如相对于 “把服务 X 部署到 A 和 B”，用户只需要定义一个 “Replicas: 2” 的 Assets 到自己的 Partition 上，而 Annealing 会找到达到这个最终状态的方法。
我个人感觉 Kubernetes 与 ECS 的映射对理解 Kubernetes 的设计逻辑会更有帮助，但是这条已经很长了。
Prodspec and Annealing: Intent-based actuation for Google Production。 对 Google 的生产管理系统的概述，可以认为是 Kubernetes 的内部版本。这篇文章对阐述 Kubernetes 的抽象模型的设计原则比大多数 Kubernetes 的介绍文章都更清晰。
一个典型的传统部署流程是 "canary in cluster X, then deploy N at a time in clusters Y and Z, run a test, and so on."，最早可能是手动，然后可能会有一些脚本来自动化。这么做最大的问题是每个服务往往都有特有的部署流程，一个尽可能去泛化不同的可能步骤的部署系统最后总会变成一个足够执行任何行为的脚本语言。另一个让这个方式难以扩展的原因是每一个步骤都是一个将系统从状态 A 转化到状态 B 的带有副作用的操作，但是要精确的确定系统处在状态 A 和系统达到了状态 B 都是非常困难的，往往最后都依赖于没有写明的隐含状态。
要解决这个问题最显然（2023 年，这个系统设计于 2015 年）的方式就是把最终想要达到的状态（intention）声明到 spec 里，然后再设计一个闭环控制系统来不断生成改变系统状态的操作，直到系统达到了声明的状态。Kubernetes 和 Prodspec/Annealing 都设计了一个非常类似于 Entity-Component-System（ECS）的系统：Prodspec/Annealing 中 Partitions = Entity，Assets = Component，System = Annealing。比如相对于 “把服务 X 部署到 A 和 B”，用户只需要定义一个 “Replicas: 2” 的 Assets 到自己的 Partition 上，而 Annealing 会找到达到这个最终状态的方法。
我个人感觉 Kubernetes 与 ECS 的映射对理解 Kubernetes 的设计逻辑会更有帮助，但是这条已经很长了。
把非计算机相关的内容移到别的频道了：https://t.me/+MU8ImsmmitNiNzVl
Telegram
Never Read It
分享非计算机相关读物
https://doi.org/10.1145/3593856.3595887
FIFO can be Better than LRU: the Power of Lazy Promotion and Quick Demotion。使用真实生产环境的数据来测试各个不同的缓存淘汰算法，LRU 相对于一些优化的 FIFO 算法并没有命中率并没有显著的优势甚至更低。本文主要考虑了两种优化策略：
- Lazy Promotion：当一个值被淘汰时才判断是否需要晋升（比如放到队首）。
- Quick Demotion：让低命中率的值尽可能快的被淘汰。
LRU 除了实现复杂且对并发不友好，另一个问题是任何一个值被淘汰都需要走遍整个队列（在此期间有且仅有一次访问）。对于一个长度为
FIFO can be Better than LRU: the Power of Lazy Promotion and Quick Demotion。使用真实生产环境的数据来测试各个不同的缓存淘汰算法，LRU 相对于一些优化的 FIFO 算法并没有命中率并没有显著的优势甚至更低。本文主要考虑了两种优化策略：
- Lazy Promotion：当一个值被淘汰时才判断是否需要晋升（比如放到队首）。
- Quick Demotion：让低命中率的值尽可能快的被淘汰。
LRU 除了实现复杂且对并发不友好，另一个问题是任何一个值被淘汰都需要走遍整个队列（在此期间有且仅有一次访问）。对于一个长度为
L，平均命中率为 H 的 LRU，每一个被 LRU 淘汰的值在被淘汰前的命中率都是 (1-H)/L。所以加快低命中率的值被淘汰的门槛（减小 L）预期上可以提高缓存利用率。https://doi.org/10.1145/3593856.3595909
Towards Modern Development of Cloud Applications。本文提出了一种新的部署微服务但是向开发者隐藏微服务复杂度的方式，描述的方式粗看很难和 Actor 模式区分开来（特别是代码组织的结构几乎一样）。本文没有很好的来抽象总结新的方式在架构上的变化，我试着重新描述一下
- Actor Model 的 Runtime 功能上可以认为等价于 Kubernetes，而每个进程相当于一个 Pod，但是和 Kubernetes 一样，只解决了 Actor 在这个 Runtime 内的部署问题，而不解决 Runtime 本身的部署问题，而 Runtime 的抽象（一个巨大的虚拟机器）与物理部署的不完全对应，最后导致物理部署的状态泄漏抽象到 Actor 实现。
- 本文描述的方式更接近于集成了 Kubernetes Operator，也就是说每个单体具有控制自身部署的能力，在架构上更接近应用对于部署的控制反转而没有引入额外的抽象层。也就是说 Runtime 并不包括 Kubernetes 而是控制 Kubernetes 来满足自身的需求，尽可能的贴近了物理部署的状态来避免抽象泄漏带来的复杂度。
别的一些设计目标比如因为部署和所有模块现在在同一个 self-contained 单体内，本身提供了一个类似全局锁的效果，保证了这个版本的部署逻辑满足这个版本的业务需求，同时模块只和单体内的模块通讯，避免了异步部署微服务带来的复杂度。
Towards Modern Development of Cloud Applications。本文提出了一种新的部署微服务但是向开发者隐藏微服务复杂度的方式，描述的方式粗看很难和 Actor 模式区分开来（特别是代码组织的结构几乎一样）。本文没有很好的来抽象总结新的方式在架构上的变化，我试着重新描述一下
- Actor Model 的 Runtime 功能上可以认为等价于 Kubernetes，而每个进程相当于一个 Pod，但是和 Kubernetes 一样，只解决了 Actor 在这个 Runtime 内的部署问题，而不解决 Runtime 本身的部署问题，而 Runtime 的抽象（一个巨大的虚拟机器）与物理部署的不完全对应，最后导致物理部署的状态泄漏抽象到 Actor 实现。
- 本文描述的方式更接近于集成了 Kubernetes Operator，也就是说每个单体具有控制自身部署的能力，在架构上更接近应用对于部署的控制反转而没有引入额外的抽象层。也就是说 Runtime 并不包括 Kubernetes 而是控制 Kubernetes 来满足自身的需求，尽可能的贴近了物理部署的状态来避免抽象泄漏带来的复杂度。
别的一些设计目标比如因为部署和所有模块现在在同一个 self-contained 单体内，本身提供了一个类似全局锁的效果，保证了这个版本的部署逻辑满足这个版本的业务需求，同时模块只和单体内的模块通讯，避免了异步部署微服务带来的复杂度。
https://dl.acm.org/doi/10.1145/121132.121151
Scheduler activations: effective kernel support for the user-level management of parallelism。提出一种用户态线程调度的设计，主要引入的几个新的抽象：
Processor：进程空间的虚拟处理器，类似于系统线程但是不会被阻塞，也可以直接对应物理的处理器。由内核来分配每个进程的处理器的数量。
Activation：相当于一个激活（运行）的状态，Activation 总是和 Processor 的数量相等，也就是说对于每个进程来说正在运行的用户态线程总是应该等于虚拟处理器的数量。
一些典型的场景：
- 当持有 Activation 的线程被阻塞在内核时（如 IO 系统调用），内核会 upcall 进程创建新的 Activation，而进程的调度器负责废弃被阻塞的 Activation 并用新创建的 Activation选择下一个执行用户态线程。
- 当内核要增加分配给进程的 Processor 数量时，内核会upcall 进程创建一个新的 Activation；当内核要减少分配给进程的 Processor 数量时，内核会暂停两个 Activation 并upcall 进程创建一个新的 Activation。
Activation 严格的对应于线程的实际运行状态，把系统调度的抽象映射到了用户态，这样进程的调度器可以根据 Activation 来决定调度策略，也可以和现有的同步 syscall 兼容。
Scheduler activations: effective kernel support for the user-level management of parallelism。提出一种用户态线程调度的设计，主要引入的几个新的抽象：
Processor：进程空间的虚拟处理器，类似于系统线程但是不会被阻塞，也可以直接对应物理的处理器。由内核来分配每个进程的处理器的数量。
Activation：相当于一个激活（运行）的状态，Activation 总是和 Processor 的数量相等，也就是说对于每个进程来说正在运行的用户态线程总是应该等于虚拟处理器的数量。
一些典型的场景：
- 当持有 Activation 的线程被阻塞在内核时（如 IO 系统调用），内核会 upcall 进程创建新的 Activation，而进程的调度器负责废弃被阻塞的 Activation 并用新创建的 Activation选择下一个执行用户态线程。
- 当内核要增加分配给进程的 Processor 数量时，内核会upcall 进程创建一个新的 Activation；当内核要减少分配给进程的 Processor 数量时，内核会暂停两个 Activation 并upcall 进程创建一个新的 Activation。
Activation 严格的对应于线程的实际运行状态，把系统调度的抽象映射到了用户态，这样进程的调度器可以根据 Activation 来决定调度策略，也可以和现有的同步 syscall 兼容。
https://doi.org/10.1145/564585.564601
CAP 定理的原始证明。找这篇看起因是因为 The CAP Theorem. The Bad, the Bad, & the Ugly 对 CAP 定理的抨击，看了下原始的证明这个定理确实没有太多现实意义。感觉最大的问题是对于 Availability 的定义过于狭隘，节点对所有请求都必须给出结果，但现实中在检测到网络隔离之后节点完全可以拒绝回复让客户端去重试。
权衡一致性和可用性确实是一个很好的考虑系统设计取舍的框架，但是 CAP 定理并没有否定一个同时满足高可用和强一致性的系统在实践上可以存在。毕竟对于理论来说 “可用” 是个正确性问题，而对实践来说是只是个请求成功率的指标。
CAP 定理的原始证明。找这篇看起因是因为 The CAP Theorem. The Bad, the Bad, & the Ugly 对 CAP 定理的抨击，看了下原始的证明这个定理确实没有太多现实意义。感觉最大的问题是对于 Availability 的定义过于狭隘，节点对所有请求都必须给出结果，但现实中在检测到网络隔离之后节点完全可以拒绝回复让客户端去重试。
权衡一致性和可用性确实是一个很好的考虑系统设计取舍的框架，但是 CAP 定理并没有否定一个同时满足高可用和强一致性的系统在实践上可以存在。毕竟对于理论来说 “可用” 是个正确性问题，而对实践来说是只是个请求成功率的指标。
https://doi.org/10.1145/2509578.2509584
What's wrong with git? a conceptual design analysis。从 git 设计中引入的概念来分析 git 为什么对新用户来说这么不友好，主要讨论的是从修改文件到 commit 以及 branch 的部分。本文基于 Brooks 提出的概念完整性的框架来分析，认为一个好的概念设计应该：
- 正交：功能之间的行为应该互相独立
- 适当：单个功能应该只包含其用途所必需的行为
- 泛化：单个功能应该适用于所有类似场景
- 一致：单个功能应该在不同的参数或者状态下表现出同类的行为
在这个框架下 git 的分析 git 的设计，如 working versions 和 staged versions 不正交，git commit 不同情况下有不同的行为，branch 不能泛化到 working/staged versions （只适用于 commited versions) 等等，并且提出了一个改进设计实现。
题外话，就我目前的观察来看就算招的人再聪明或者做了很多年开源项目，大家还是都不太会用 git。
What's wrong with git? a conceptual design analysis。从 git 设计中引入的概念来分析 git 为什么对新用户来说这么不友好，主要讨论的是从修改文件到 commit 以及 branch 的部分。本文基于 Brooks 提出的概念完整性的框架来分析，认为一个好的概念设计应该：
- 正交：功能之间的行为应该互相独立
- 适当：单个功能应该只包含其用途所必需的行为
- 泛化：单个功能应该适用于所有类似场景
- 一致：单个功能应该在不同的参数或者状态下表现出同类的行为
在这个框架下 git 的分析 git 的设计，如 working versions 和 staged versions 不正交，git commit 不同情况下有不同的行为，branch 不能泛化到 working/staged versions （只适用于 commited versions) 等等，并且提出了一个改进设计实现。
题外话，就我目前的观察来看就算招的人再聪明或者做了很多年开源项目，大家还是都不太会用 git。
https://www.usenix.org/publications/loginonline/evolution-sre-google
The Evolution of SRE at Google。用 System Theory 来分析灾难。传统的思路是事故是一连串的事件的结果，所以解决方法往往是如何打破这一串事件的因果链条（如加冗余，避免单点故障）。从系统的角度来看系统在正常工作时处在一个稳态，也就是说必然存在一套控制系统来维持系统，而一个事故是系统从稳态到亚稳态再最后到灾难的过程，其中亚稳态可能维持了很长的时间。识别出为什么控制系统无法从亚稳态回到稳态可以从一开始避免进入可能会发生事故的状态。System Theory 也能更好的把非技术的因素考虑进来（如组织架构，流程，外部环境）。
Instead of asking "What software service failed?" we ask “What interactions between parts of the system were inadequately controlled?” In complex systems, most accidents result from interactions between components that are all functioning as designed, but collectively produce an unsafe state.
The Evolution of SRE at Google。用 System Theory 来分析灾难。传统的思路是事故是一连串的事件的结果，所以解决方法往往是如何打破这一串事件的因果链条（如加冗余，避免单点故障）。从系统的角度来看系统在正常工作时处在一个稳态，也就是说必然存在一套控制系统来维持系统，而一个事故是系统从稳态到亚稳态再最后到灾难的过程，其中亚稳态可能维持了很长的时间。识别出为什么控制系统无法从亚稳态回到稳态可以从一开始避免进入可能会发生事故的状态。System Theory 也能更好的把非技术的因素考虑进来（如组织架构，流程，外部环境）。
Instead of asking "What software service failed?" we ask “What interactions between parts of the system were inadequately controlled?” In complex systems, most accidents result from interactions between components that are all functioning as designed, but collectively produce an unsafe state.