免责声明:

• 本文内容有一定程度上请教 ChatGPT(4.0)，而 “ChatGPT可能會出錯。請考慮核對重要資訊。”
• OCI 的制定晚于 Docker 早期版本，因此部分历史镜像或历史 Docker 版本的逻辑可能与本文论述的不一致

如上图，描述了主要 Docker 指令对应的产物关系。

关键实体说明

• Internal Docker Image: 指的是 Docker 在本地构建完成后的镜像， 是内部 Docker 镜像，它是基于 Dockerfile 通过 docker build 命令构建的。它存储在 Docker 守护进程的内部存储中，(Linux 下)通常位于 /var/lib/docker/，遵循的是 Docker 内部的镜像存储结构。
• OCI Runtime Bundle: 创建容器所依赖的 config 和 rootfs 文件, 参考 Filesystem Bundle

行为说明

docker build

1. Docker 从 Dockerfile 读取指令，构建镜像层，生成镜像配置
2. Docker 将镜像直接按照 Docker 内部格式进行存储

docker push

docker push 会将镜像以符合 OCI Image Spec 的格式推送到远程仓库

1. Docker 生成符合 OCI Image Spec 的 Docker Image

   1. 准备镜像清单 (manifest)

   2. 生成镜像配置 (config)

2. Docker 推送 Docker Image

   1. 上传 layers
   2. 推送 manifest & config
   3. tag 推送

docker save

docker save 会将镜像以符合 OCI Image Spec 格式的 Docker Image 保存下来为 tarball

docker run

docker run 会 调用 runtime(如 runc) 来创建和操作 OCI Runtime Bundle, 并创建容器并执行

1. Docker 从镜像中提取元数据和配置信息
2. Docker 准备 rootfs
3. Docker 生成配置
4. Docker 调用 Runtime 管理容器生命周期
5. Docker 启动容器

OCI Runtime Specification 的出发点和 Image Spec 基本一致，它通过制定容器执行的标准规范，使容器的行为和状态与具体的上层软件无关，实现容器的便携性和更好地自动化支持。

满足 OCI Runtime 的标准容器有五个基本的原则(runtime-spec/principles.md at main · opencontainers/runtime-spec):

• Standard Operations
• Content-agnostic
• Infra-agnostic
• Designed for automation
• Industrial-grade delivery

术语

为了尽可能准确地明确文章中使用术语的上下文，我们着重介绍一下 Runtime Spec 中涉及到的两个和其上下文较紧密相关的术语, 详细的列表大家可以参考 runtime-spec/glossary.md at main · opencontainers/runtime-spec

• Bundle: OCI Runtime Filesystem Bundle, 是符合 OCI Runtime Spec 定义规范的，用于创建容器的文件夹
• Runtime: OCI Runtime Spec 的具体实现，我们下文举例会用到的 runc 就术语 runtime, 其他例子见 runtime-spec/implementations.md at main · opencontainers/runtime-spec

Filesystem Bundle

如图所示，Runtime Bundle 包含两部分文件内容。

config.json 文件

Config 文件 是和容器运行相关的配置文件，必须放在 Bundle 根目录下。它包含的典型内容如环境变量信息、挂载(Mounts) 信息、容器进程(process) 信息、和容器生命周期相关的 hooks 等。

Config 文件的生成来源主要有两种:

• 通过 Runtime 指令生成默认的 config.json 文件: 如 runc spec , 通常用于开发、测试或是定制化配置的场景，生成默认配置后可以在其上进行修改来适配容器场景。
• 通过 OCI Image config 转化: 转化逻辑可以参考 image-spec/conversion.md at main · opencontainers/image-spec， 我们日常接触的其实主要是这种来源，它具有一致性和可复现，通常与容器生态系统进行了集成（如 Docker 实际上帮我们做了这层转化)。

rootfs 文件夹

rootfs 即容器的 filesystem, 工业使用场景中通过 Image Layers unpack 得到， rootfs 的路径和名称可以在 config.json 文件的 root.path 中进行指定。

Demo

Runtime Bundle 的文件结构相较于 Image Spec 要简单许多，我们不妨尝试按一下步骤动手尝试构建一个 Bundle 。

0. 准备 Linux 环境(runc 只支持 Linux 环境执行)并进行 runc 准备， 见 runc

1. 通过 docker export 指令获得容器的 rootfs 并放置在指定文件夹, 这里以 busybox 镜像为例

   $ mkdir rootfs
   $ docker export $(docker create busybox:latest) | tar -C rootfs -xvf -
   

2. 创建默认的 config.json 文件

   $ runc spec
   

Over, 最终文件结构如下

$ tree -L 2
.
├── config.json
└── rootfs
    ├── bin
    ├── dev
    ├── etc
    ├── home
    ├── lib
    ├── lib64 -> lib
    ├── proc
    ├── root
    ├── sys
    ├── tmp
    ├── usr
    └── var

13 directories, 1 file

Lifecycle

除了文件结构 Bundle， OCI Runtime Spec 还定义了容器状态机及相关的 (Runtime 需要支持的) Operation 操作。

上图展示了容器的生命周期、对应触发指令及容器的响应行为，上图涉及的相关行为说明可以在 runtime-spec/runtime.md at main · opencontainers/runtime-spec 这里找到， 图上涉及的 Env 信息、Hooks 信息、用户制定的容器进程 process 都是在 config.json 文件中指定的。

我们可以在上文初始化好的 bundle 文件夹中创建容器并观察 Lifecycle：

1. 执行 runc create <container-id>, container-id 可以任意指定， 这里我们指定为 testid

2. 执行 runc list 观察状态, 这时我们容器的状态为 created

   $ runc list
   ID          PID         STATUS      BUNDLE                                              CREATED                          OWNER
   testid      7094        created     .../busybox_fs   2024-02-17T13:20:13.231362865Z   root
   

3. 执行 runc start testid 后再执行 runc list, 会发现状态变为了 stopped （我们没有指定 process)

4. 可以通过 runc state testid 获得 runtime-spec/runtime.md at main · opencontainers/runtime-spec 描述的状态元数据信息， 如

   {
     "ociVersion": "1.1.0+dev",
     "id": "testid",
     "pid": 0,
     "status": "stopped",
     "bundle": "...",
     "rootfs": "...",
     "created": "2024-02-17T14:19:51.642906094Z",
     "owner": ""
   }
   

rate: ⭐️⭐️⭐️⭐️

第二十条是今年(2024)年的贺岁档电影，看着上面这张海报喜气洋洋，C 位由雷佳音和马丽两个（先前）主演喜剧的演员担任左右护法，左下角还明目张胆写着“我爱我家❤️️”，谁能想到这是一部内核颇为严肃的法律教育片。作为2024年我第一部在影院观影的电影，虽然从主题上来说它可能不满足贺岁片该有的喜庆和轻松，但是在我看来是一部质量相当在线的电影。

先来说说人物。从海报上就可以看出来，第二十条的主要演员阵容和 23 年颇火的 《狂飙》 重合度很高，以至于我一直期待着张颂文老师的出现。主演们在我这外行看来演技都是在线的，几个老戏骨自不必说，刘耀文和赵丽颖两个年轻演员在电影中也很放得开，不做作，在被各种装逼的小鲜肉恶心的几年里这已经足够让我感到欣慰了。以及，大嫂真漂亮。

节奏上整体也让人感到比较合适，严肃的情节里穿插着还比较合时宜而不尴尬的喜剧桥段调节气氛。不同故事线之间的情节推进和衔接自然，不突兀，也能充分反映在主角的情绪变化上。

稍有点让人感到疲惫的是频繁的情侣式的斗嘴片段，相似的桥段可能出现两次会觉得有趣，多了就有点生厌。不知道是不是错觉，这种斗嘴的片段似乎随着剧情的紧张也有在变得频繁，我斗胆猜测一下，张艺谋导演或许是想借这种争吵之间的频率以及严肃程度来侧面反应剧情紧张，相关人员的心理压力也在逐渐增大，反映昧着本心做着守法但是合乎清理的决定最终只会让自己在乎的人难受？

最后回到剧情上。

第二十条指的是 《刑法》第二十条关于 “正当防卫” 的法条，电影主要也围绕着三个和正当防卫有关的故事展开，电影的整体逻辑和《不止不休》类似，主角（团）面对着种种现实因素的阻挠和惯例的约束，从畏手畏脚到最终觉醒，推动不合理制度/现象的改变。（会不会是因为因为剧情逻辑太一致所以张颂文老师没有出演🤔）。

电影中涵盖了三条不同的正当防卫的故事线，通过主角韩明串在了一起。三条线有着或明或暗的相同和对比，我懒得展开具体描述电影的情节，就结合我个人主观揣测一下这些相同和对比点的意图和个人感受吧。

相同点一: 在三个故事线中，侵害人都是正当防卫事件里的弱势者，生活中的强势者，这大概也是现实中正当防卫相关案件的普遍情况吧。

王勇强案中的高利贷债主和债权人，韩雨辰故事中的教导主任儿子和寄托全家希望的借读生，单亲的张贵生司机和流氓，这些人在生活中都有着自己的软肋，软肋也很可能恰恰被抓在侵害人手中。受到反抗的侵害人地展现和利用自己在正当防卫事件中的弱势形象，同时又靠着自己在生活中的强势地位施加压力，伟光正地为自己争取“合理”的诉求。

他们的诉求合理吗？电影里展现的诉求是合“理”的，无非是杀人偿命，无非是打人的先道个歉，他们有时甚至不为自己申请实际的利益。但是这种合理的诉求是可怕的，他们的诉求释放的信号是对正在受着压迫的当事人和非当事人的警告: 反抗我们是要付出代价的。不管是正当防卫还是见义勇为，大多是心里压抑的强烈情感的爆发，不断地接收这种信号也是在不断地提升反抗的阈值，也就有着更多和更长久的人被持续压迫着。

值得注意的是，在王勇强和韩雨辰的故事中，站出来博取同情的并不是当事人，他们可能并没有参与侵害，他们不会心虚，他们有着无比正当的理由。以韩雨辰和教导主任来说，教导主任想要的是一个为打人事件的道歉，他也愿意为霸凌的事单独处理单独追究，同是站在局外人的视角看，在观影的时候我一度感觉这种分治的处理方法是思路清晰的，一个道歉也只是动动嘴皮的事。

但是这种理中客视角的小代价和处理方法是对防卫人的服从性测试，你接受了道歉，你也就接受了压迫，你也就会在下次被霸凌的时候选择忍耐。

相同点二: 举证的困难，防卫人需要证明自己是受到威胁的，是在被持续侵犯的，是在侵害人作为生活的强势人掌控舆论甚至掌控自己软肋的情况下抱着鱼死网破的决心的情况下去证明自己为什么忍无可忍了。

王勇强案的一大段篇幅都在等着一把刀的出现，一把侵害人口中的放在车上的说要砍死王勇强的刀。故事的结局是好的，刀找到了，但是如果侵害人只是口舌之快，或是今天出门忘了带刀，那是不是只能认罪。

说到底那把刀重要吗，侵害人就是刀，一刀下去可能是家破人亡和三年霸凌，一辈子的心理阴影。

接下来说说不同的地方。

三个故事线的严重程度不同，阐述视角不同。

韩雨辰事件是中学里发生的事，是主角身边的事，也可能是我们身边的事，也可能就是我。

王勇强案是重大事件，侵害程度最大，但即使是这么恶劣的侵害，他仍然需要一把刀去证明自己的正当性。

张贵生是一个几年的历史老案，是一个判决后不断上访但无法翻案的老案。这条线告诉我们，法是全国一样的法，环境和惯例就是如此。

有趣的是在观影的时候坐我身后的小屁孩在不断地顶着我的椅背，而我也担心刺头小孩吵闹影响了其他观众而选择了忍耐，属于是即时情景体验了。

The Open Container Initiative is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes. ── About the Open Container Initiative - Open Container Initiative

OCI(Open Container Initiative) 是在 2015年 由 Linux Foundation 支持，由 Docker, CoreOS 等其他容器行业内的领导者共同发起的 容器镜像实现的格式标准， 旨在推广容器格式(format) 和运行时(runtime) 的开放治理结构(open governance structure), 创建开放的工业标准。OCI 的成立主要是为了解决容器技术在快速发展过程中出现的标准化问题，确保容器的可移植性和互操作性，让容器能够在各种环境中无缝运行。

OCI 规定了关于容器的两部分标准:

• Image Spec: 关于容器镜像如何实现(或者说打包) 的标准
• Runtime Spec: 关于容器如何运行的标准

本文的内容聚焦于 Image Spec 相关介绍，主要来源为 image-spec/config.md at main · opencontainers/image-spec ，尝试结合实际例子以及个人认为更符合逻辑的理解顺序来梳理 Image Spec 的主要概念。

Demo

在有条件的情况下读者可以先按如下步骤进行相关 demo 的准备，结合 Demo 进行 Image Spec 相关实体的理解更能增强体感。

# 拉取 nginx:latest 镜像到本地，nginx:latest 是本文选择的符合 OCI image 的镜像
$ docker pull nginx:latest
# 以 tarball 形式保存 nginx 镜像
$ docker image save -o nginx.tar nginx:latest
# 创建并解压保存下来的 tarball 到指定文件夹
$ mkdir nginx && tar -xvf nginx.tar -C ./nginx

总览

在开始深入介绍前我们先对 OCI Image Spec 有个大概的认识，为了方便理解我们不妨先将 OCI Image Spec 分为两个部分

• Spec Context: 对 Image 的结构、格式、描述方法所做出的约束和规范。又包括
  • Layout: 对 Image 实现的文件夹结构的规范
  • Media Type: 对 Image 设计的文件(或者叫 component) 的类型的约定
  • Descriptor: 定义了 Image 中 component 之间进行关联的结构体
• Spec components: Image 实现中需要包含的具体组成实体, 有各自对应的文件。

接下来本文将结合上文 nginx tarball 例子，先从 Spec Context 开始对 OCI Image 建立规范上的认识，再分别介绍各个 Spec Components， 每一块内容标题下都提供了对应的原始文档链接，有兴趣的读者可以点击进入深入了解。

Spec Context

Layout

image-spec/image-layout.md at main · opencontainers/image-spec

OCI Image Layout 规定了 Image 的文件夹组织方式，通过遵守 Layout， 相关的工具可以对一个镜像按照一致的路径处理成符合 OCI Runtime Spec 的 bundle。

Layout 规定了一个镜像需要包含 blobs 文件夹, oci-layout 文件，index.json 文件， 这三种文件类型在我们的 demo 中也可以看到:

$ ls
blobs         index.json    manifest.json     oci-layout    repositories

blobs 文件夹

blob 是 Binary Large Object 的缩写，通常指的是镜像中的二进制数据块。在 OCI Image Spec 的上下文中，我们可以直接将所有通过内容进行 hash 索引的文件理解成是 blob。

blobs 文件夹存储的就是使用特定 Hash 算法计算过的文件，它的子目录的结构为 <alg>/<encoded>, <alg> 为对应的 Hash 算法 ，<encoded> 为该 Hash 算法对内容进行过 Hash 后的值。

比如在我们的 demo 中， blobs 包含如下文件

$ tree
.
├── blobs
│   └── sha256
│       ├── 02eecd1b8ebb27cc1f576804168486c4c5c3180d22c50048fdaa546b581adec9
│       ├── 047c9d07f2a3abf9e7c546307dc69cb5147b1cb8d2f81b58d36d2be57fea6257
│       ├── 0655e46321e4ed76b200f52007cb59fcc3801faccd391f6795712028d7536c6f
│       ├── 11deb55301007d6bf1db2ce20cb5d12e447541969990af4a03e2af8141ebdbed
│       ├── 1adb92f0b5e98c8db798082a7877732ad1f5e273577b63ac9c1a505f3e8ed61c
│       ├── 31eaf3687d312550bf26d9d649c95283ebc46b03aeda439952d4fba2fd3187e6
│       ├── 37be4081a37453c9e9f11af799eb037c47664a0549ddfa236b3e57bab95ba64b
│       ├── 46dca80a0cef221684a9da329176ad5bc6d6f77c379ad234a9e5931795f975d3
│       ├── 5c23503565e9eb6c31f511199a6f80721b2750d00d174011bcc80248b2b896ff
│       ├── 8790436822597f6bbc1de71c6e9d25636fd687fb8a60dfc2c69e0bf3d330349a
│       ├── 8d80ad266f0138f5eedd03c130279b1059fed471346f1656c5bf0bfa1d3d12ed
│       ├── bb23c2def74f2ccbf902543ca6675687e5f662e3d991fbd9938dbea06c5faefc
│       ├── c356d79b264683ba6151321749af21974030d674d1a607e2c888c4598017620b
│       ├── ced4d951e1bfe83757aa885f51c2b48d081e0c23a87af7d01386a62cec11824c
│       ├── df91f10d317c00ef9f4ce4359c893a96e621ae6ee532649af2e42b774315e528
│       ├── f2b5466eadaed1957e9c445669168b5a90e9e259a2dd5990af5f3ebb7ad50df0
│       └── f63419ada981fd98f7a67208d219167f82c6097de0e747c9f42c6c86924afc47

即一系列由 sha256 对内容进行过 Hash 的文件。

对于这些文件，我们可以通过如下方式验证其内容与 Hash 值是匹配的

$ shasum -a 256 ./blobs/sha256/02eecd1b8ebb27cc1f576804168486c4c5c3180d22c50048fdaa546b581adec9
02eecd1b8ebb27cc1f576804168486c4c5c3180d22c50048fdaa546b581adec9  ./blobs/sha256/02eecd1b8ebb27cc1f576804168486c4c5c3180d22c50048fdaa546b581adec9

因此这些 blobs 是 content-addressable 的，即是由他们的内容决定存储位置的 blob, 这在 OCI Image Spec 中是一个相对比较重要的概念: 除了可以根据 Hash 值进行标识符进行基本的 ref 和 索引， 还可以起到校验的作用。

OCI Image 的 blobs 包含了镜像的大部分内容，在我们总览的 Spec Components 中，除了 Layout 里单独提到的 index 文件，其他 component 都保存在 blobs 文件夹下， 除此之外 blobs 也可能包含一些各个工具自身实现需要的(在 OCI Image Spec 之外的)额外的文件。

oci-layout 文件

oci-layout 文件的包含的内容很简单，通常只包含 imageLayoutVersion 字段信息，表明镜像所适配的 layout 版本号。

如我们 demo 中的 oci-layout 内容如下

{ "imageLayoutVersion": "1.0.0" }

index.json 文件

对应 spec components 中的 index 文件，index.json 文件是 OCI Image 的入口。我们在后文的 components 中会展开介绍，这里不再赘述。

Media Type

image-spec/media-types.md at main · opencontainers/image-spec

Media Type 定义了 OCI Image 各个组件的类型，对应到组件里的 mediaType 字段， 根据这个字段我们便可以知道某个文件对应的 component 及一些基础的元数据信息。

Media Type 基本是用户可读的， 比如如果一个 Image 文件对应的 mediaType 是 application/vnd.oci.image.layer.v1.tar+gzip 从字面上我们就可以看出这个 文件对应的是 OCI v1 版本下的 layer 组件，通过 tar 进行了打包并且通过 gzip 进行了压缩。

除了定义类型，Media Type 还起到识别冲突和判断兼容性的作用。

• 识别冲突: 当工具请求获得 blob 的信息时，返回的元数据信息中的类型与工具实现所期望的 mediaType 可能不匹配，这种情况下工具需要遵守 mediaType 对冲突的响应规范进行处理或报错。
• 兼容性判断: OCI Image Spec 会尽可能地向前及向后兼容。同时对历史(OCI 之前)的 Image 配置类型，Spec 中也给出了明确的兼容性矩阵帮助进行判断。当出现兼容性问题时，就可能发生如镜像拉取/推送失败，或者容器启动失败等问题。

Descriptor

image-spec/descriptor.md at main · opencontainers/image-spec

如上文所说，OCI Image 包含了多个不同的 component, 这些 component 需要进行相互关联，这些 component 的关联关系就以 Content Descriptors(=Descriptor) 表示。

Descriptor 通常包含如下内容:

• mediaType : 即上文介绍的 mediaType 内容
• digest: 记得我们上面提到 blobs 是 content-addressable 的吗？ digest 记代表了引用的组件的标识符，同时我们也能根据这个标识符在 blobs 文件夹中找到对应的资源
• size： blobs 原始内容的大小(bytes)
• …

Spec Components

Index

image-spec/image-index.md at main · opencontainers/image-spec

index 是 OCI Image 的入口(entry point), 也是多架构镜像中指向多个单一平台镜像的更高视角的索引入口。

index 通常对应的文件便是上文 Layout 中提到的 index.json, 我们结合 nginx Demo 看一下 index.json 文件中包含的具体内容

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:f2b5466eadaed1957e9c445669168b5a90e9e259a2dd5990af5f3ebb7ad50df0",
      "size": 1356,
      "annotations": {
        "io.containerd.image.name": "docker.io/library/nginx:latest",
        "org.opencontainers.image.ref.name": "latest"
      },
      "platform": { "architecture": "arm64", "os": "linux" }
    }
  ]
}

如 Demo 所示，典型的 index.json 包含的 properties 有以下内容:

• schemaVersion int: 标识了 image 的 manifest 的 schema version， 对于当前(20240214) 的 OCI Image Spec 版本，这个 property 的值为 2

• mediaType string: 标识 index 的 mediaType 的字段， 值为 application/vnd.oci.image.index.v1+json

• manifests array of objects: 包含特定 platform 对应的 manifest descriptor。结合 descriptor 的字段定义，我们对其中的关键字段可以进一步展开:

  • mediaType : application/vnd.oci.image.manifest.v1+json 表示引用的是 manifest.
  • digest: manifest 的 digest, 可以在 blobs/sha256 中找到对应的文件

• platform: 表示对应的 manifest 需要满足的最小 runtime 要求

Manifest

manifest 组件提供了单一架构/操作系统下的镜像所需要的配置和 layers 信息，允许工具如 registry 和运行时确定需要拉取的配置内容和各 layers 层信息。

根据 index.json 文件的 manifests[*].digest , 我们可以在 blobs 文件夹中找到对应的manifest（可能有些工具为自身实现的需要会在根目录下直接冗余 manifest.jon 文件，OCI image spec 的定义中 manifest 是在 blobs 中保存的）。

# f2b5466eadaed1957e9c445669168b5a90e9e259a2dd5990af5f3ebb7ad50df0 是在 index.json 文件中获得的 manifest 的 digest 值
$  cat blobs/sha256/f2b5466eadaed1957e9c445669168b5a90e9e259a2dd5990af5f3ebb7ad50df0 | jq

文件内容如下

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:11deb55301007d6bf1db2ce20cb5d12e447541969990af4a03e2af8141ebdbed",
    "size": 7016,
    "platform": {
      "architecture": "arm64",
      "os": "linux"
    }
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar",
      "digest": "sha256:02eecd1b8ebb27cc1f576804168486c4c5c3180d22c50048fdaa546b581adec9",
      "size": 100168192
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar",
      "digest": "sha256:ced4d951e1bfe83757aa885f51c2b48d081e0c23a87af7d01386a62cec11824c",
      "size": 95961088
    },
    // ....
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar",
      "digest": "sha256:047c9d07f2a3abf9e7c546307dc69cb5147b1cb8d2f81b58d36d2be57fea6257",
      "size": 5120
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar",
      "digest": "sha256:8d80ad266f0138f5eedd03c130279b1059fed471346f1656c5bf0bfa1d3d12ed",
      "size": 7168
    }
  ]
}

我们来看看其中涉及的具体的 properties:

• schemaVersion 和 mediaType 基本和上文 index 文件中所述一致
• config descriptor: 指向对应镜像的配置文件，后文对 config 本身会有具体介绍。
• layers array of descriptors: 指向构成镜像的 layers 列表，layers 之间存在以下关系
  • index 0 位置的 layer 是 image 的 base layer
  • layers 的顺序符合镜像打包的堆叠顺序
  • image 最终构成的 filesystem 匹配在一个空的文件夹下 apply 所有的 layers

Config

image-spec/config.md at main · opencontainers/image-spec

对于一个 OCI Image, 我们可以认为它是在特定容器运行时环境下的 layers/changesets 和 运行时参数的组合。

config 文件描述了 OCI Image 运行时所需要的信息，包括环境变量、入口(Entrypoint) 等，主要作用就是告诉工具如何运行指定镜像。 除此之外 config 文件也包含了一些镜像自身的元数据信息，如 author、构建历史等。

我们从上文的 manifest 文件中可以获得对应的 config blobs 的 sha值， 在 blobs 文件夹中查找对应的文件

# 11deb55301007d6bf1db2ce20cb5d12e447541969990af4a03e2af8141ebdbed 是在 manifest blob 中获得的 config 的 digest 值
$  cat blobs/sha256/11deb55301007d6bf1db2ce20cb5d12e447541969990af4a03e2af8141ebdbed | jq

文件内容如下

{
  "architecture": "arm64",
  "config": {
    "ExposedPorts": {
      "80/tcp": {}
    },
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
      "NGINX_VERSION=1.25.3",
      "NJS_VERSION=0.8.2",
      "PKG_RELEASE=1~bookworm"
    ],
    "Entrypoint": ["/docker-entrypoint.sh"],
    "Cmd": ["nginx", "-g", "daemon off;"],
    "Labels": {
      "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>"
    },
    "StopSignal": "SIGQUIT",
    "ArgsEscaped": true,
    "OnBuild": null
  },
  "created": "2023-10-24T22:44:45Z",
  "history": [
    {
      "created": "2023-10-24T22:44:45Z",
      "created_by": "/bin/sh -c #(nop) ADD file:ef6f078c1e72fcfafb9bfeeff0c1c771219dc2efe34650963106f63d32183b49 in / "
    },
    {
      "created": "2023-10-24T22:44:45Z",
      "created_by": "/bin/sh -c #(nop)  CMD [\"bash\"]",
      "empty_layer": true
    },
    // ....
    {
      "created": "2023-10-24T22:44:45Z",
      "created_by": "STOPSIGNAL SIGQUIT",
      "comment": "buildkit.dockerfile.v0",
      "empty_layer": true
    },
    {
      "created": "2023-10-24T22:44:45Z",
      "created_by": "CMD [\"nginx\" \"-g\" \"daemon off;\"]",
      "comment": "buildkit.dockerfile.v0",
      "empty_layer": true
    }
  ],
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:02eecd1b8ebb27cc1f576804168486c4c5c3180d22c50048fdaa546b581adec9",
      "sha256:ced4d951e1bfe83757aa885f51c2b48d081e0c23a87af7d01386a62cec11824c",
      "sha256:5c23503565e9eb6c31f511199a6f80721b2750d00d174011bcc80248b2b896ff",
      "sha256:df91f10d317c00ef9f4ce4359c893a96e621ae6ee532649af2e42b774315e528",
      "sha256:1adb92f0b5e98c8db798082a7877732ad1f5e273577b63ac9c1a505f3e8ed61c",
      "sha256:047c9d07f2a3abf9e7c546307dc69cb5147b1cb8d2f81b58d36d2be57fea6257",
      "sha256:8d80ad266f0138f5eedd03c130279b1059fed471346f1656c5bf0bfa1d3d12ed"
    ]
  }
}

这里不再逐个对 config 文件的每个 property 展开描述，对于大部分 properties 大家可以直接根据 key 值推测出准确的含义。只单独说明一下 rootfs 字段。

rootfs 字段中的 diff_ids描述了 image 各层次的 layer hash 值，并且也是从 base layer 往上层 layer 的顺序排列。大家可能会发现这个列表中的内容和上文 manifest 中的 layers digest 是一致的，实际上这两者在内容上存在区别: manifest layer digest 可以是根据 layer blob 的 压缩或原始内容进行hash 计算，而 diff_ids 只能是根据未压缩的 tarball 内容进行的计算。通过在 rootfs 中也保存 diff_ids ，除了基本的校验能力，也能使 config blob 本身依赖于 layers, 增强镜像整体数据的一致性。

Layers

Layers 是构成镜像具体文件系统的 tarball 集合，也是镜像打包的主体内容。通过按 manifest 中 layers 所展示的顺序解压各个 layer blob, 我们需要能够获得与镜像容器大致匹配的目录结构。

我们仍然以 Demo 所示的 layers 进行操作演示，对比按顺序解压各个 layer blob 所获得的最终的文件结构和进入容器的文件结构情况。

解压各个 layer blob 到特定文件夹:

$ mkdir stack_layers
$ tar -xvf blobs/sha256/02eecd1b8ebb27cc1f576804168486c4c5c3180d22c50048fdaa546b581adec9 -C stack_layers
$ tar -xvf blobs/sha256/ced4d951e1bfe83757aa885f51c2b48d081e0c23a87af7d01386a62cec11824c -C stack_layers
$ tar -xvf blobs/sha256/5c23503565e9eb6c31f511199a6f80721b2750d00d174011bcc80248b2b896ff -C stack_layers
$ tar -xvf blobs/sha256/df91f10d317c00ef9f4ce4359c893a96e621ae6ee532649af2e42b774315e528 -C stack_layers
$ tar -xvf blobs/sha256/1adb92f0b5e98c8db798082a7877732ad1f5e273577b63ac9c1a505f3e8ed61c -C stack_layers
$ tar -xvf blobs/sha256/047c9d07f2a3abf9e7c546307dc69cb5147b1cb8d2f81b58d36d2be57fea6257 -C stack_layers
$ tar -xvf blobs/sha256/8d80ad266f0138f5eedd03c130279b1059fed471346f1656c5bf0bfa1d3d12ed -C stack_layers

export container tar & extract

$ docker export $(docker create nginx:latest) -o container_fs.tar
$ mkdir container_fs && tar -xvf container_fs.tar -C container_fs

简单对比两者的文件树差异

$ tree ./stack_layers > stack_tree
$ tree ./container_fs > container_tree
$ diff stack_tree container_tree

输出如下
1c1
< ./stack_layers
---
> ./container_fs
4a5,7
> │   ├── console
> │   ├── pts
> │   └── shm
144a148
> │   ├── hosts
167a172
> │   ├── mtab -> /proc/mounts
5774c5779
< 658 directories, 5113 files

可以看到就 nginx 镜像来说，完全基于 layers tar 包解压缩获得的文件树与 container export tar 解压的文件树存在少量文件差异。这些差异主要是由于容器运行时动态创建或挂载机制生成的，如 hosts 文件是用于容器内部的 DNS 解析使用的， 而 mtab 是一个符号链接，指向挂载的文件系统信息。

当然除此之外还有其他因为容器打包逻辑或是容器运行时造成的内容差异，在这里我们不(从 diff 分析角度) 展开，这里的主要目的是证明layers tar 包与容器 fs 之间的一致性。

接下来我们(以官方文档中的例子)介绍一下如何 from scratch 基于 fs 构造 OCI Image 各层的 tar 包，这有助于帮助我们理解镜像的运行机制。

Layer Tarballs Creation

1. Initial Root Filesystem & Populate Initial Filesystem

先定义好一个基本的 base layer，并且构建好基本的文件结构， 如下

# base layer 包含的文件信息
rootfs-c9d-v1/
  etc/
    my-app-config
  bin/
    my-app-binary
    my-app-tools

将 rootfs-c9d-v1 打成 tar 包，便是我们的 base layer tarball, 即 layers 中 index 0 位置的 layer。

2. Populate a Comparison Filesystem

准备好 base layer tarball 之后，便是重复往上堆叠 changeset， 每个 changeset 在 OCI Image 中对应一层 layer，在我们使用 Docker 进行镜像打包的过程中即对应 Dockerfile 里的文件变更。

基于上一层进行文件变更的方式如下:

1. 创建一个新的文件夹， copy/snapshot 上一步构建好的 filesystem 到这个文件夹中。这一步有两个要求:

   1. 使用的 copy/snapshot 工具需要能保留上一层文件的 attributes
   2. 对于 copy/snapshot 后的文件的修改不能影响上一层的文件内容

   这一操作镜像打包工具通常使用如 CoW(copy-on-write)技术或 UnionFS 来更高效地实现。

3. Determining Changes

进行完成变更后，镜像构建工具需要进行修改的文件集合及修改内容的确定。最终确定的信息大概如下

Added:      /etc/my-app.d/
Added:      /etc/my-app.d/default.cfg
Modified:   /bin/my-app-tools
Deleted:    /etc/my-app-config

4. Representing Changes

以上步骤对应的变更即 changeset 文件, 会被单独打成该 layer 对应的 tarball， 打包的逻辑如下

• Add/Modify 操作: 对对应的文件及文件夹进行打包
• Delete: 对对应的文件/文件夹 标记为 whiteout , whiteout 存在两种标记方法
  • 单文件的 whiteout 形式，以 .wh. 作为文件前缀的空文件
  • 标识同文件夹下所有文件都被一处的 opaque whiteout 形式: 被删除文件内容的文件夹下存在 .wh..wh..opq 文件

在 apply layer 的时候，whiteout 文件会先被进行处理，即被标记 whiteout 的文件会先进行删除，再应用 layer 的其他变更， 通过顺序保证了镜像打包的时候不会将修改的内容删除。

从这里也可以推导出，如果镜像 layer 中存在删除操作，那么直接根据 tarball 解压获得的文件夹内容会比从容器中 export 的文件内容多出 whiteout 文件

Summary

以上差不多就是 OCI Image Spec 的大致内容，总的来说就是 OCI 对镜像打包在描述格式、文件结构、内容规范定义了标准，通过遵循这些标准使各个工具的镜像打包得以保持一致。

除了 Image Spec， OCI 还对 Runtime Spec 做出了规范，这部分内容后续在单独的文章中介绍。

不管是对于我还是对于这个世界，2024 都算不上开了一个好头，那就先骗骗自己是在踩着农历新年的日子对过去的 2023 做一个总结吧。

第一次

2023 年是我虚岁 29 岁的尾巴，在这个我的人生大约已经走过 1/3 的年纪里，还是体验了不少第一次。

第一次做了一整年的笔记

大约是在2021 年中的时候，我开始沉迷于各种笔记软件，从 Notion 到 Roam Research 到 RemNote , Obsidian, LogSeq…FoMO 情绪让我在各种笔记软件里反复横跳，今年才大概算是把更多地精力放到记录本身，记录下自己一年的轨迹。

说是更多精力投入到记录，但是回头看看，记的多是些零碎的流水帐，除了让自己在写这篇文章的时候能诧异原来今年自己还做了这么些事，似乎也没有沉淀下来什么有价值的东西。

第一次上外教课

由于在 X 上看到某推友晒自己在 Cambly 获得的课时认证书，我也恰好有心改进一下我的哑巴口语，在 2023 年 5 月 18 日那天，一个彻彻底底的 e 人终于鼓起勇气约了第一节外教课， 并且也以每周两次的频率持续到了写下这篇文章的时候。

我很高兴自己在那天踏出了这一小步，尽管和外教老师们就是单纯的尬聊，没有任何系统性的教学或规划，我仍然感觉自己在这半年多的时间里有了不小的进步，值得我写下一篇 《Why you should learn speaking English by talking [to native speakers]》。

第一次听演唱会

2023 年 9 月 10 日，和畅畅到了北京鸟巢听华晨宇的演唱会。

演唱会的氛围很棒，但是我显得有点呆滞。

一是我不是很能欣赏华晨宇的歌，我可以说几乎没有任何音乐素养，单纯是觉得他的歌声不讨我耳朵的喜欢。二是因为华的粉丝们让我有种他们形成了某种奇怪宗教的感觉，我无法理解他们的狂热，也感觉自己的冷静在那个氛围下略显尴尬。

对了，为了赶着第二天回上海上班，我们也第一次体验了在机场的小旅舍过夜。

第一次滑雪

今年滑了两次雪，都是在浙江的室内滑雪场。

一次是参加了稻草人的周末团，到杭州的冰雪大世界体验了双板；另一次是到了乔波的滑雪场，这次尝试了单板。

滑雪很好玩，希望在 2024 年能学会基本的技术，到室外滑雪场过过瘾吧。

第一次听交响音乐会

2023 年的最后一天，我和畅选择了到一个小教堂听交响音乐会来迎接新的一年。

因为是小教堂，交响乐队和听众有不少有趣的互动，也一起在倒数声和返场中迎来了 2024。但是如果让我再做一次选择，我大概会选择在家里颓过最后一个晚上吧，因为…

第一次在现场看羽毛球赛

而且是世界羽联总决赛 🥳

现场看球的感觉确实和电视不同，有热烈到尖叫的观众，有石宇奇的迷妹粉丝在发应援物品，有更真实的球速感受，当然也有失望提前离场的观众。

让我们恭喜小戴拿下 2023 年总决赛女单冠军吧 🏆。

旅游

2023 年的旅游次数比起往年似乎少了一些，江浙沪的各种必要穿梭抛开不算，中长途的旅行只有两趟吧。

一趟是为了华晨宇的演唱会到了北京，在北京的时候恰好赶上绵绵的秋雨，只在北海公园浅浅地溜达了一圈，吃了四季民福，就也不剩下什么时间了。

第二趟是跟稻草人去了珠峰。畅国庆还要加班，因此这也是我第一次自己跟稻草人的团。

我挺骄傲自己在海拔 5400+ 的地方还能活蹦乱跳，过几年我大概还是回想念并且忘掉头几天高反地难受劲冲向西藏吧。

输入

书

说来惭愧，2023 年初的时候雄心壮志要养成看书的习惯，一年下来看书的时间和数量都不尽如我意。

正在在 2023 年里看完的书大概只有 Kubernetes in Action 这本大部头，尽管是英文版，但是作者用的词汇算是亲民了。

电影

2023 恰好看了 10 部电影，质量都还算不错。

• 流浪地球2: 值回票价的商业片，特效精彩，剧情也算过硬。
• 进击的巨人/最终季/完结篇/前篇 + 后篇： 哪个天才想的命名方法。算是给这步经典动漫收了个还可以的尾巴，和鲁鲁修或者文豪野犬类似的救世主逻辑吧。
• 中国乒乓之绝地反击: 剧情没啥硬伤，也没带太多广告（我现在对电影的要求已经这么低了吗hhh）
• 不止不休: 很不错的社会电影，张颂文老师演技在线，白客也成功证明自己的可能性。
• 蜘蛛侠/纵横宇宙: 没想到在 3202 年了还有电影能有这么出彩的画面特效！漫画风、水墨风以及抽帧等手法着实是让我眼前一亮。
• 子弹列车: 所谓的巧合和误会，看起来是命运，实际上都是必然的因果交织。把多个主角的故事线很自然地衔接在一起。
• 极限职业: 来自韩国的喜剧片，（按我的偏见）我记得韩国以前常以灾难片和社会电影闻名，这部喜剧片倒是也值得推荐。
• 封神/朝歌风云: 乌尔善导演真聪明啊，妲己吸引男观众，一众质子男模们的胸肌吸引女观众，真有你的。
• 辛德勒的名单: 是外教 Tony 推荐的电影，是斯皮尔伯格拍摄的一部老电影了。讲述了二战期间德国商人如何帮助犹太人的故事，和钢琴家从两个视角讲述了那个时代的故事。

动漫

今年看的动漫有 22 部，感觉比起以前我追的番已经不少了，没想到还能达到这个数。

数量太多，也没耐心一一介绍，硬要从里头选一部推荐的话，那么:

拾荒者统治 🥳 出自网飞的作品，扎实的画面和剧情，新颖的想象，如果看腻了日式动漫，那么它会是你很好地调节口味的选择。

其他

今年的上下班路上一直有在坚持听博客和看一些文章。但是像前面说的，总结过少，也没有什么系统性的整理，只能说希望自己在某天遇到问题的时候还能想起来自己看过某个相关的内容吧。

工作

在贵司又度过了一年。

事儿上，我比较欣慰自己在这年里还是做了一些实际的产出吧。经手了大约四五个模块的事情，也还在持续迭代着两个开发项目。

人嘛。

算了，就这样吧。

生活

和畅畅走过了第五个年头。

尽管不想自己度过传统老中人的一生，戴上老中人的枷锁，但是我们也确实到了该考虑下一步的时候了。

或许早就应该考虑了，只是我还是会因为无法调节到满意的结果恐惧吧。

希望 2024 年我们都能得到自己想要的答案，希望答案里都还有我们两个人。

2024

所以到了该展望一下 2024 的时候了。

2023 年年初我曾经想过给自己的生活也按 Q 定几个 OKR，现在一看 Q1 的 OKR 都还留着白。

2024 大概也还是会在相同的白日梦中假装努力吧：

• 早睡
• 学好英语（或许还有日语）
• 看书
• 开源
• 多整理，多输出

祝大家新年快乐。

芳草街

玉林

九眼桥

西藏

拉萨

大昭寺

八廓街

布达拉宫

羊卓雍措

卡洛拉冰川

扎什伦布寺

珠穆朗玛峰

路上

大本营

萨迦寺

这两篇文章会介绍如下内容：

• AWS Savings Plans 相关的概念
• AWS 平台上如何更好地观察 Savings Plans 使用情况
• AWS Savings Plans 相关的数据结构及字段说明
• 包含 AWS Savings Plans 的简单数据分析场景指导

作为第一篇，本文主要会进行 AWS Savings Plans 基本概念的介绍，以及进行相关的成本管理时可能接触到的小知识。

基本介绍

AWS Savings Plans 是本文介绍的主要对象，因此我相对详细地介绍在实际成本管理中需要了解的部分。

[AWS Savings Plans ](https://docs.aws.amazon.com/cur/latest/userguide/cur-sp.html)是一种预付费定价模型。 用户通过预先承诺一定的计算用量（按小时计算），在一定期限（通常是 1 或 3 年）内获得折扣。

对于以上定义，我们拆散解释:
“预付费定价模型” 指的是作为用户需要在使用服务之前预先支付费用，后续按照周期和用量从该预付款项中直接扣除。
通常这种收费模式会给用户带来一定的折扣，但也要求用户承诺一定的用量或期限。对于 AWS Savings Plans 来说，所作出的承诺就是

1. 期限: “一定期限（通常是 1 或 3 年）”内使用相关服务
2. 使用量: 在使用期限内承诺了按小时计算的使用量

在以上承诺范围内，对应 Savings Plans 的服务可以获得相应的折扣。
Savings Plans 提供了 All Upfront(全预付)、Partial Upfront(部分预付）、No Upfront(无预付)三种选项，预付款金额由高到底，折扣力度也由大到小，基本的内涵是一样的，本文为了帮助理解仅以 All Upfront 付款选项为例进行介绍。

从实际交易的角度来说，实际上就是用户在指定 “期限” 内的相关资源 “用量” 按折扣后的价格计算金额后预先支付给 AWS ，AWS 按小时从该预付款中拿走该“小时费”。小时费是固定的，这意味着：

1. 如果用户实际用量不足承诺小时用量，AWS 仍会拿走固定的金额
2. 如果用户实际用量超过了承诺用量，AWS 对于除了固定金额，对超出用量部分会按需收费

那么这种收费模式对于用户来说分别有什么好处和坏处呢？
对于用户来说最明显的好处是获得了折扣，降低了自身的计算成本，Savings Plans折扣有多种收费模式（参考 Cloud Cost Savings – Savings Plans – Amazon Web Services 本文不展开描述）用户可以根据自身场景和架构选择合适的模式，有一定灵活性。同时 AWS 相关的技术支持人员会帮助用户制定 Savings Plans 购买方案（包括在哪个帐号上购买、购买期限，用量协商…），这也能帮助用户调整架构，提升 SavingsPlans 的利用率。
但相对的，由于我们承诺了用量和期限，我们的使用也就受到了相应的限制，这个限制包括对供应商（AWS）的依赖，对实际用量调整的阻碍。以及因为预付款带来的现金流影响。

收费优先级

需要注意的是 ，Savings Plans 的所有者是 AWS 帐号(Account) 而不是组织(org)粒度的，同时 Savings Plans 是有扣款优先级的，扣款优先级主要与资源类型和帐号有关，关系如下

1. 优先使用当前帐号的 SavingsPlans, 覆盖完当前帐号的 SavingsPlans 后可以使用其他帐号的共享的 SavingsPlans
2. 在满足 1 的情况下，折扣力度最大的资源类型（不同类型的资源的 SavingsPlans 折扣力度不同）优先使用 SavingsPlans 进行覆盖

根据以上收费优先级和折扣力度差异，我们可以得到一个提高 Savings Plans 折扣力度的 tips:

使用部分不实际运行（或运行较少）Savings Plans 相关实例的帐号来购买 Savings Plans，使 Savings Plans 能优先按照折扣力度进行覆盖。

当然以上 tips 还需要结合公司实际业务情况来决策，比如是否需要优先保证某帐号的 Savings Plans 覆盖。

AWS 上的相关分析工具

AWS Cost Management 是专门用于提供 AWS 成本洞察的服务，其中的 Savings Plans 子目录下提供了 Savings Plans 相关服务，辅助我们进行分析的主要是 Inventory、Utilization report、Coverage report 几项

• Inventory: 展示了当前帐号下的 Savings Plans 情况，包括状态(Status)、Type、承诺用量(Commitment), 起止时间
• Utilization report: 主要用于展示 Savings Plans 的使用情况(用户对 Savings Plans 的承诺成本的使用情况)和获得收益。可以结合筛选条件查看 Savings Plans 的 花费、覆盖资源对应的原始花费、节省金额（前两者相减）。使用率越高意味着 Savings Plans 得到了越有效的使用，使用率不足 100% 说明没有完全利用 Savings Plans 。

• Coverage report: 主要展示 Savings Plans 对用户使用的符合条件的资源成本的覆盖情况。提供了按 服务(Service) 和资源类型 拆解进行分析的能力。计算方式是
  Coverage = (按需价格计算下被 Savings Plans 覆盖的资源的价格)/(按需价格计算下被 Savings Plans 覆盖的资源的价格 + 按需价格计算下未被 Savings Plans 覆盖的价格)
  因此 Coverage 越高，即 Savings Plans 覆盖的资源越多，即节省了越多钱。

一句话总结是，在日常分析的时候可以主要结合 Utilization report 和 Coverage report 使用，目标是使 Utilization 和 Coverage 都尽可能高，前者代表我们对 Savings Plans 使用的充分程度，后者代表 Savings Plans 为当前帐号资源的节省情况。

总结一下，本文主要介绍 AWS Savings Plans 的基本模型和常用的知识。下篇会介绍 Savings Plans 数据分析中涉及的概念、字段说明，并举几个典型场景说明用法。

Refs

• Cloud Cost Savings – Savings Plans – Amazon Web Services
• What are Savings Plans? - Savings Plans
• Understanding how Savings Plans apply to your AWS usage - Savings Plans

工作

除了所负责的领域(DevOps)不变，不管是公司还是工作内容都完全不同了。

今年 4 月份从蚂蚁集团离职了。
离职的时候所负责的是“研发洞察”相关的工作，这是一个新兴领域，还没有成熟的发展路径指导演进；这也是一个门槛“不高”的领域，大多数技术同学都能对如何做研发相关的度量发表自己的见解（虽然这个见解应该大概率是对某种度量的批判 hhh）。我也一样，我对研发洞察的发展路径没有足够的领域知识来支撑清晰的规划，能确定的是我对前司方向的不认可，再加上自己处在局中对技术的摄入选择也感到迷茫，因此犹犹豫豫的提出了离职。

新的公司是 PingCAP, 简称贵司。入职的时间是 4.28，本来想的是 gap 两周多少学点东西，但当时在南京需要 14 天 7 检（大概是这个数？），再加上家附近的省外核酸点效率极差，每天下午被核酸的两个多小时撕成碎片，实际上也没学多少。
入职贵司前对贵司实际上是抱有极大的期待的。创业公司 + 开源 + 基础设施，可以说贵司当时就是我心中的白月光，因此虽然当时本身想换个领域但还是在纠结后选择了贵司。
入职之后老实说有点失望，从个人的感觉来看贵司已经带点大公司病，比如会议多（是真的多啊，一天三四个会家常便饭），比如难以对齐但不得不看起的 OKR…

好在内容上有不少自己需要学习的东西，倒也不算踩了大坑。目前我在做的仍是工程效率相关的东西，负责的是某（代码跟屎一样！）的 BMS 系统和 TiDB 云上效率相关的内容。以用户视角来和云厂商打交道，K8S， github action 对于被大厂养坏的我来说都是很新奇的东西。

生活

今年是和畅畅在一起的第四年，一起做了很多事，去了很多地方。
拍了海马体，养了小靛（一只斗鱼，夏天时死了 😭），做了很多次菜，一起去看了只此青绿，参加了稻草人的城市活动。
去了无锡、苏州的几个园林，虽然记不住 ；
去了青岛冲浪，住了这辈子住过的最贵的酒店，虽然畅急性肠胃炎了；
去了湖南吃了好多次茶颜悦色和黑色经典，虽然刚到张家界就因为疫情不得不跑毒（还好跑成功了）；
还有常住的杭州、上海和南京，也想着法子去了几个没去的地方。

今年也是我从杭州到上海的第一年，找了两天房子，以为找到了梦中情房，实际住进来了发现也只是干净一些的老破小，该有的问题还是会有。

今年还是被疫情影响的第三年，也是体感被限制得最严的一年。因为上海被封的 3 个月先在杭州入了职，在上海也得 2 天 1 检。
到了年底风向又大转弯，完全放开了，我也终于在年底成了小 🐑 人。

其他

“我最热衷的浪费时间的方式，就是研究各种效率软件。”

今年花了好多时间研究效率工具，包括 RoamResearch、Obsidian、LogSeq、Readwise Reader…最终在 Obsidian 和 LogSeq 中摇摆了几个月，强迫自己在 Obsidian 定了下来。趁着这几个软件还没把我想吐槽的点完善好，或许最近我该抓紧撸几篇博客出来。

参加了贵司的 Hackathon，其实是个不太有趣的项目，火急火燎的代码写的也和设计完全不同，但是拿了二等奖，奖金给畅买了 NuPhy 键盘（其实是我自己手痒想试试哈哈）。

同时开始用 NeoVim 作为主力 IDE，还是很爽的。

4 个关键字

写着写着回头一看，发现自己 2022 年依然没有什么值得说道的成长，我真的太菜了。
所以决定今年给自己整个新活：定下几个关键字，每天不管多少，总得做些和这些关键字（之一）搭边的内容。定的关键字是下面几个

开源

尽管班还是一直在加，游戏也还是一直在玩，但是今年必须克服恐惧（被嫌菜）参与开源项目，能持续性地给开源社区做贡献。

读书

2022 看了不少文章，但是书似乎只有一两本（甚至都记不准）。2023 年每天睡前看那么几分钟吧，也不限于专业书籍。

输出

不能白交钱了！（不是

英语

2022 我的英语口语依然垃圾，好在上下班路上坚持听 Podcast,听力还是体感上有些进步的。2023 年一定要克服社恐，想办法在口语上有自己满意的进步（至少不会因为口语再被外企拒掉或压 offer 吧…

最后，虽然我并不想主动把这篇文章分享出去，还是祝大家 2023 年万事顺意。

其实早在年初的时候，我就给自己立下了一个 flag ── 只要我拿到offer，就奖励自己一把HHKB。现在入职P社已经过去了1个多月，我也终于咬咬牙（趁着618和公司福利）买了HHKB Hybrid Type-S。

我先简单说明一下我的购买价格，或许可以为同样犹豫很久的同学提供一点参考。我是在天猫618的时候蹭着优惠和满1500减120，以2444的价格买入的，附赠蓝牙接收器和数据线（除了该款其他版本似乎不附赠这两样，但部分版本价格上优惠更多）。

发货地点就在杭州，但由于端午三天及中间恰好有点事，我的HHKB在蜂巢躺了5天才被我抱回家。我本身也不是啥键盘专家，对手感也不太挑剔，这里只是趁着高兴，做一个简单的开箱和首日使用的测评。

正面展示，入手之前觉得这个电池仓设计很丑，本来是想买Pro2 Type-S的，奈何各家店铺都断货。实际上到手以后的感觉就是键盘整体很小巧，电池仓也没有丑的那么扎眼。除了电池仓和字体略微有点大以外，整体的感觉很"复古"，是我个人比较喜欢的素雅的风格。

背面展示，四角有防滑贴很好地固定键盘（但是支撑脚打开后还是有点滑hhhh）。电池仓下方的四方形小盖子下藏着DPI开关。

外观上没有太多值得评价的点，今天使用了一天，手感上有些许体会。

在HHKB之前我主要使用两款机械键盘，一款是Filco的87键的双模忍者圣手二代红轴；另一款是WASD的青轴，同样是87键；平时直接使用MAC的蝴蝶键盘的频率也不低。我以下的测评主要是和以上几款键盘对比得到的感受。

首先是键位上，在购买之前就有小伙伴劝退我，因为我有频繁切换工作键盘的需求，可能会比较不适应。实际上搭配Karabiner-Elements{.ek-link}进行简单(左ctl+hjkl改方向键，Esc键和~键的兼容，以及自己一直有Cap-locks和ctrl键交换的习惯)的魔改后，上手还是相对比较容易的。比较嗝应的点，一个是原本一些修饰键+方向键的用法（比如Magnet – Window manager for Mac的快捷键）还没法形成熟练的肌肉记忆，一个是切换回87键后Delete键容易按成 “|” 键。但就第一天的适应情况来说我还是比较满意的，基本有信心在短时间内能完全上手。

其次是手感上，老实说我并没有觉得有多惊艳，比较大的感觉就是“扎实”。这款HHKB按压下去的感觉，就是“按键的磨砂表面严丝合缝地紧贴着笔直地向下滑动”，但这个“紧贴”感并不会带来手感上的厚重，相反很是轻松。敲了一天HHKB再回头敲Filco和WASD，就感觉这两款机械键盘的按键很“不安分”，对比下轻微地晃动感变得明显，按下的感觉更活泼，反馈也更强烈。这点上应该也是萝卜青菜各有所爱吧。

最后是声音上，这款HHKB的声音也手感的描述的表现比较一致，每次按键按下的声音就像“塑料磨砂表面相互摩擦”带来的轻微的“沙沙”声，与机械键盘撞击及回弹产生的“哒哒”声有比较明显的区别，（比起我的红轴和轻轴）静音效果也确实是很好。

总的来说，作为奖励自己的正反馈，HHKB确实让我产生了一种“想更多地敲击键盘”的兴奋感，希望自己适应之后能明显地提升生产力吧~

“遗憾”但是又“幸运”的是在 P 厂我负责的领域和在 A 厂一样，都是研发效能/工程效率领域，尽管入职还不到两周，距离离职也已快过去一个月，但如我所愿在对比中我也有一些对 A 厂研发效能的想法，趁着感觉还没完全消散，忙里偷闲地进行一些暴论。

免责声明: 以下内容带有强烈的主观推断，有极大可能结论是错误的，都是出于个人的经验和感受进行的总结。我很欢迎大家直接地指出我的错误(如果有人看的话)，也期望能有人和我进行深入地探讨，但对于没有价值的贬低我会直接删除。

也不知道是从谁口中开始传的，大家都说研发效能的三要素是“人”、“流程”、“工具”，仔细一琢磨，想说的几个点大概也可以归到这三个方面上，因此我也就不打算免俗，从工具开始说起吧。

工具大概是明面上最容易感受到差距的地方。到了 P 厂简单了解后就不得不感慨，A 厂的效能工具确实很齐全。从需求/缺陷管理、设计、文档、IDE（及插件）、到代码托管、持续交付、发布管控、数据洞察、工单支持…这个领域内所有我能想到不能想到的边边角角都已经被插上了 A 厂自研的大旗。

得益于完备且相对统一的工具体系，A 厂在质量效率上确实有着很高的起点。速度上来说，（在不出错、不需要审批、且已经被工具调教熟练的前提下）A 厂的发版能享受到完整的一条龙服务。质量上来说，IDE 插件保证编码期间的错误提示，持续交付中的各种规则和组件换着花样伺候开发，线上变更三板斧配合各种应急措施（当然还有故障复盘和追则），保证了蚂蚁极低的线上故障率和极短的修复时间。上万名研发、数千个仓库、每周小几千个 MR、每分钟上百条流水线…以统一的工具体系支撑起这个量级的多种服务需求，不能算是小的成就。

不仅如此，“统一”一定程度上也意味着“标准”。A 厂定义了自己工具体系下的“标准”，这个“标准”即代表使用标准、流程标准，也代表评价标准、管理标准，只要适应了这个标准的语境，员工们就能很快享受到这个“标准”所带来的红利：除了上文所说的显著的质量效率提升，还有沟通术语的一致、团队切换在工作方式适应上的低成本、宏观度量数据的采集和清洗低成本…

这一套体系能够形成如今这么一个宏大的布局，我想最主要大概有这么几个原因：

• 首先最直白的原因便是人多。效能部的人多，A 厂的研发效能部在巅峰时期有 180 多个人（还是 130 多个，记不清了），抛开巅峰时期不谈也从两年前的 50 余人发展到现在的 80 余人，涵盖了开发、产品、解决方案、技术支持、运营等角色，这还不谈体量更大的中间件团队和技术风险团队（作为对比 P 厂的工程效率部在本文撰写期间 2022 年 5 月中旬为 7 个人）。人多是因也是果，人多是工具体系得以全面覆盖的基础，工具体系全面带来的业务也需求并带来了更多的人。

• 其次就是公司大，公司大了业务也就广了。某个 P8 指点过我，公司也是市场黑暗森林里的一个孤立群体，保持静止最终只会带来死亡。A 厂发展到这个阶段，锁涵盖的业务范围不是我这种小 P 可以简单数清的，而 A 厂的组织方式又以中台为主，这么复杂的业务体系收束在一个部门下，确实也不是一些简单的工具可以支持的。

• 再有就是 A 厂对校招生的偏爱，这是我校招进公司时 HR 就提过的。校招生的一个特点就是好调教，一张白纸，A 厂说啥是规范流程啥就是规范流程，再加上 A 厂的校招生水平不低（我算是其中极差的了），这么些各大院校里的尖子生能快速地体会和掌握 A 厂的标准，快速地成为 A 厂的生产力。校招生的高比例和不知是否存在的青睐，也导致他们占据了 A 厂中高层的大多数。“人无法知道自己没看过的东西”，统一语境下成长起来的校招生们，大概对于标准不会有太多的敌意。

• （KPI 导向，但实际上我入职后的 KPI 对我并没有太多约束，因此我也没有太多想法）

但是，质量和效率就是研发效能的全部吗？

很惭愧，在 A 厂两年多的时间里我基本没有吃过我们自己的狗食，我没办法从用户的角度来评判 A 厂的研发效能并给出答案。因此我也只能从一个研发效能部研发人员的视角谈谈我的看法。

如上面所说，其实我代表的就是（我认为）比较典型的，A 厂效能部研发值得诟病的一方面: 我们即不是自己的用户，也离业务太过遥远。

我起先负责的是代码分析能力的建设，代码分析作为持续交付 CI 建设的一环，以“任务”的粒度进行分析，而在当时的我眼里，对这些“任务”进行优化和扩展就是我的工作，我最高频地接触用户的场景，就是在自研的对内的工单咨询系统上进行答疑。在这个阶段，也偶尔有用户跟我提出了需求，而我和 mentor 讨论的时候，往往要关注的是这些需求的“性价比”── 大部分需求是较定制化的，便找理由搪塞了过去，最终我所实现的大部分较“大”的需求，实际上都是我们自己 YY 出来的，看起来牛逼轰轰的需求。

我想这其中就有“统一”的原因，研发效能听起来像是服务于研发的团队或工程，但当我们开始抽象业务的复杂度，实现这个领域的统一时，我们有了很充分的拒绝服务的理由。当我们有了充足的人手，我们的分工也可以足够细，细到我这种螺丝钉始终对业务懵懵懂懂。

我并不知道 A 厂有多少校招生和当时的我一样对自己创造的价值感到困惑，我也不清楚当公司壮大、业务复杂后，这种大一统的中台部门是否是一个必然的选择，如果是的话这个选择带来的业务疏远感应该如何处理（异或是根本不必处理？）。就在上周我和我在 P 社的老板简单地聊到了这个话题，他提到了在他的老东家（另一个大厂）同样要面对需求的性价比问题，他会要求团队里的同学紧贴业务创造价值。这可能是一个很直接且有效的方式吧，我也希望在 P 社成长的过程中自己能有更清晰的答案。

我颇感不适的第二点，就是这全套自研的基础设施。

如上面所说，不能否认自研工具的复杂度和它们对 A 厂复杂业务的支撑价值，但自研又封闭地开发环境在我看来损失了不少成长的可能。

一是足够活跃的社区反馈和讨论（尽管 A 厂内部也建立起了技术论坛，但在用户与产品负责人论坛上的讨论方式让我觉得更接近于“吐槽与公关”的关系），我们服务的主体是技术人员，技术人员本身对生产力工具应该是有天然的热情和兴趣的，缺少健康的沟通渠道以及足够的社区用户让自研仿佛闭门造车。

二是公司内的语境限制了与业界先进实践的接轨，“公司内的语境”指的是当基础设施建设得足够齐全，就相当于在公司内营造了自己的上下文，后续的很多上层建筑的建设工作都是基于这个上下文提出的。这些上层建筑累积得越厚，可能离业界的先进经验就越远，吸取地成本也就越高。

三是当自研工具体系覆盖了大部分领域，但又没有足够的灵活性时，A 厂的研发人员在工具选择上面临着尴尬的局面：自研的产品并不能完美地匹配团队的特性，但“又不是不能用”，这种情况下大部分团队会选择将就使用自研的产品（上面的“社区反馈产品”也是这个例子，A 厂的代码托管平台的 issue 功能鲜有人用。）。

这又带来了另一个问题，即流程上的不规范。是的，上文我们说到了 A 厂的流程是“统一的、标准的”，但统一和标准不同于规范。

**当工具不能很好地满足个人、团队的特性，而流程标准又要求使用这个工具时，工具的使用在一定程度上就变成了负担，负担的累加导致了不规范。**在我参与的第二个项目（某内部洞察项目）中，我和另一个同事曾就内部工具数据对多个（内部）团队进行数据分析工作，所得到的分析结论大部分都因“团队流程不规范”导致的脏数据不可用。

如果你问我，质量和效率就是研发效能的全部吗？我无法回答，我也愿意相信 A 厂仍然能够又好又快地交付产品，但作为曾经 A 厂的效能研发人员，我无法认可自己在那种工作模式下产生的价值。

工作

我在蚂蚁的工作，是一段“恶始恶终”的工作: 从起错花名开始(我的花名是“黎荍(qiáo)”，荍这个字在此之前我也不认识)，在不尽人意的成果中结束。这里也就只对一些微小的工作做一些总结。往事不可谏，来者犹可追，希望我痛定思痛，痛改前非，非常成功，功在千秋，秋天还能回来看看蚂蚁的老伙计们。

LinkA

LinkA是我从实习时开始接手并独立维护的代码分析系统，直到2020年交接给其他团队。在这期间进行了包括但不限于以下功能点在内的设计和实现: 多语言分析模块、远端执行任务能力、增量代码分析的能力、自动CR机器人、代码认知复杂度…

从结果上来看，这些功能里能实际上线的都取得了还不错的成果:

• 多语言分析模块对系统整体进行了还算合理的重构，也对各种分析工具的执行流程进行了恰当的抽象，后续各种静态代码分析工具的接入基本能保持在3人日内完成，多语言用户对相关能力也颇有赞词。
• 远端执行能力很好地保证了系统整体的稳定性和资源池的动态扩缩容，搭配上执行模式热切换的能力，在此能力上线后系统便没出现过不可用故障。
• …

比较遗憾的是，我个人认为实现后略有成就感，也是对系统业务长期发展较重要的的几个功能因为组织架构的调整没能最终上线:

• 自动CR机器人: 通过Git hook进行任务的触发，结合系统提供的增量分析能力在用户提交的变更代码行上标注对应的分析结果，并给出整体的总结报告。这个功能点将质量检测左移到了代码提交阶段，能提供更精确和心智负担更小的修复指导。好在后续接管代码分析功能的团队也提供了类似的能力。
• 认知复杂度: 不同于圈复杂度实际度量的复杂度可以认为是“测试用例构造的复杂度”，认知复杂度是基于Sonar提出的CognitiveComplexity.pdf论文实现的，用于度量代码理解难度的指标。这个指标实际上是LinkA向整体性、系统化的代码分析平台演进的一个探索。

总的来说，负责LinkA系统的开发实际上是一段蛮开心的体验，我可以完全自主地决定系统发展方向的设计和探索，相关的需求也有一定的难度; 每天都有不少的工单需要支持，不少人厌恶工单对工作节奏的影响，但工单常常能让我体会到我产出的价值，也偶尔让我对系统方向有新的感悟。

从反面来说，也是因为是个人维护的系统，在进行需求分析和系统设计的时候，很多情况都是由我拍脑袋决定的，这也是我期间一直觉得自己所缺失的较要紧的一个能力。

研发数据建模

2020年5月，公司收购了原来的源伞，代码分析相关的能力也都要归属到他们团队下。

当时老板给我提出了几个选择: 一个是跟着LinkA系统到新团队下面，另一个是跟着他做研发洞察项目，而研发洞察项目下面又有三个主要的方向: 研发洞察平台开发、效能领域的数据挖掘和研发数据建模。

对这几个我的考虑大概如下: 在代码分析方面实际上我并没有积累足够的底层知识，源伞团队有深厚的技术积累，也有其自带的工程平台，若跟着LinkA变更团队，我可能会有较长时间需要进行系统的交替和下线工作（况且我老板对我还不错）。而研发洞察的几个方向，就我当时的理解来看，平台开发并不是研发洞察的核心能力，底层的数据及模型才是。因此我给老板的答复是我希望能留在当前团队，进行数据相关的工作。老板表示数据建模是当前团队较缺少的能力，也愿意给我时间进行学习和落地。就这样我开始接受我负责的第二个项目: 研发数据建模，实际工作职责也从Java开发变成了数据开发。

研发洞察是一个相当年轻的学科，尽管相关话题热度不低，但业界并没有成熟的工程实践，已有的一些度量指标建议和方法论指导很多也缺少可靠的事实支持。尽管到我离职为止，我在这个领域也有了两年的探索和沉淀，但我仍不觉得自己能较清晰地把握住它未来的发展发向和潜在价值，我仍需要更多的思考和沉淀，而这方面的经历也值得我另外写一篇文章进行总结，在本文我也是简单陈列主要工作。

经我设计和实现的模型，支撑过业务进行决策的有人员产出分、人员交付质量分、人员技术影响力模型、应用质量分、效能健康度模型等。其中人员产出分相关的业务背景复杂(研发产出随岗位、时间、流程的变化)，为了适应业务情况而进行的模型开发工作量也较大(多段的分箱打分机制、线性规划计分、后分层事后分析校验分数合理性…)。

负责研发洞察项目期间我始终处于自我怀疑的状态，一个是怀疑自己是否有持续在学习，一个是怀疑自己的作品是否有生产出价值。我也在不断地与我负责的第一个项目进行对比，我也始终感觉，相比较于数据分析与数据开发，我还是更希望能进行开发工作。

蚂蚁之后

在2021年年初，其实心底就萌生了跳槽的打算了，但由于当时刚提名晋升，同时也想再给自己一点时间在研发洞察这个领域上探索，因此当时并不急着准备。到了8月份左右，心里越来越意识到自己在当前的工作上并不开心，也越来越有对技术沉淀的焦虑感，便下定了要离职的决心，而实际开始准备就到了2022年春节前不久。

开始面试前我问了自己思考了很多次自己想要的是什么，最终我也没能给自己一个准确的答案，我不清楚自己期待的领域，不清楚自己热情的技术栈，也不知道自己最终想成为什么样的人，这让我有点沮丧。但我知道自己不想继续在国内的互联网大厂卷了，最近两年的工作让我对工作内容之外的许多学科都产生了浓厚的兴趣，我希望有时间能进行更多维度的能力提升。

同时我开始思考我的人生观，我开始觉得，既然最终都是要死亡，人生是无绝对意义的。所谓的意义，其实是每个人自己甘愿“被欺骗”的理由，而我自己拿来欺骗自己的人生意义就是：我想体验更多的东西。这也成为我下家选择的一个判断条件，我期望去能带给我更多体验的公司。

最终，我拿到了字节数据安全团队、PingCAP工程效率团队、微软Azure App Service团队的offer。在后两者中纠结了许久，基于上述的判断条件，我决定接受PingCAP的offer。尽管微软的WLB和业务对我来说很有吸引力，可能涉及的技术栈也是我很欠缺的，但我相信PingCAP能带给我更多的技术热情和“更多不同的体验”。

生活

2019年的9月13日，也是当年的中秋节，我和畅畅在一起了。

这两年多里我们一起走过了国内的很多地方:(内蒙(海拉尔、满洲里、阿尔山、额尔古纳…)、黑龙江(哈尔滨)、天津、山西(太原、大同、朔州、繁峙县)、江苏(南京)、浙江(杭州、湖州、舟山、宁波…)、福建(泉州)、广东(深圳)、湖北(武汉)、上海…)，吃了很多美食，认识了很多人，也有不少的遗憾：对于一起经历的很多，一直没有很好地进行记录，由于疫情，我们也一直没机会一起出国旅游…

我也认识了很多朋友，我要前往上海最不舍得的也是他们，好在最亲密的朋友基本都是打球认识的，尽管不在蚂蚁，我们也还能保持联系(希望)。

简介

作者真正意义上从电子以及最基础的二进制原理出发，介绍了一台真正的计算机是如何一步一步诞生的，以及之后又是如何优化成现代我们所使用的计算机及使用的自然语言。

你能学到什么

• 现代计算机软硬件的发展历史
• 计算机软硬件发展过程中涉及的设计原理及推导过程
• 部分现代计算机设计(如编码方式、文件系统等)的入门介绍
• …

优点

• 浅显易懂，适合纯外行了解计算机运行原理，对于更专业的内容点到即止但足够对相关概念有一定了解
• 有趣，尽管读的是译本，但也感受到了作者思路清晰，行文流畅
• 基于问题分析，全书隐隐约约在重复着：向读者抛出问题-解决问题的过程，如果在阅读过程中带着思考分析问题，对于计算机运行原理大概会有更深入了解

缺点

• 约20章之前的内容较连贯，缺乏计算机基础的人不建议跳着看
• (对于我来说)现代计算机在硬件上的优化较没有吸引力

相关资料

1. 知乎:《编码》讲了什么
2. 随便在github上找的资源🙈
3. 豆瓣

• 滴滴下架对司机有没有影响？目前还基本没什么影响，公司也没有发针对司机们的公告。
• 司机能否签约多个打车平台？不能，或者说没必要。
  • 签约了其他平台被发现了是会有惩罚的，比如减少派单，旺季还好，淡季就基本接不到客了。
  • 大多数司机不是专职的，可能也相对没那么多精力接多个平台的单(因为平台不给交社保等等或者说交的很少。通常都有自己的主业，且不是在智力密集型公司上班，工资也不高(几千水平)，通过下班时间兼职司机每月能多几千收入，对于他们来说是很可观的。)
• 为什么出了这个事后不选择签约其他平台？因为滴滴虽然烂(司机原话是: 我们也经常骂滴滴坑)，但是其他平台更差。这表现在几个方面:
  • 平台活跃度，滴滴在这块属于独角兽，其他平台保不齐什么时候就没了。
  • 定价，平台定价高了用户不满意，定价低了司机不满意，合理的定价能保证用户和司机的活跃度，滴滴在这块的拿捏相对比其他平台要好。
  • 福利，这是对于司机来说滴滴远好于其他平台的地方，主要体现在提现上。大多数平台要求司机到30天后才能提现当前收入，这就导致他们要垫付很多油钱，房租及日常开销也会带来压力等等；而滴滴2至3天就可以(不知道理解是否有误，但总体意思是滴滴提现周期远小于其他平台)，出于信任及怕麻烦他们通常也就是一周提一次，不会过于频繁。
• 是否比兼职外卖好？从司机的角度来看，各有优劣：
  • 成本上，滴滴司机成本较高，兼职外卖成本低，但外卖风险相对高些。
  • 收入上两者其实差不多(这个司机也有同事在兼职送外卖。
  • 辛苦程度上，不好比较。外卖小哥虽然风吹日晒爬楼梯，但是时间相对自由，用餐上厕所等都比较方便，乐观点想走路爬楼梯也顺带着锻炼了身体。司机虽然坐在车内也有空调，但是因为车位问题，上厕所和吃饭都很麻烦，让停车的地方没有厕所或小餐馆，有厕所或小餐馆的地方往往不让停车。通常得随缘在合适的时间遇到合适的地方才能解决（因为打司机没法决定调度的方向，因此在固定的地方用餐和如厕也往往不可行）。

在这之前我也和其他司机聊过些零碎的话题，这里整理一两个还有印象的

• 疫情的影响。这个话题是一个健谈的北方出租车司机和我提起的，按他的说法，在疫情前他是不屑于在平台上接单的。杭州算是一个旅游还算可以的城市，疫情前他靠着接送路边的游客，介绍一下熟悉的饭馆商店(在他看来他认为这些店确实有口皆碑，至于是不是收了商家回扣大家各自判断)，就足够他一天的生计。随着疫情的到来，游客渐渐少了，他也不得不接起了平台的生意。当然在我看来不完全是疫情的影响，手机打车确实也就在这几年发展迅速，至少对我来说优先级高于沿路拦车。(这个健谈的大哥说high了错过了转完路口，直接把表按掉了表示是他的锅，不好计价了直接按现在显示的钱算吧hhhh)
• 乘客的素质。前不久被司机吐槽了我司某员工 😥，以下简称A吧，好巧不巧他们还挺有缘老撞到一起。司机说A喜欢在车上吹牛逼，听语气多少是个小领导(司机：应该高不到哪去，是个组长吧好像)，不过这倒也不是他讨厌的点，主要是有过那么一两件事的过节。
  • 一件事是某次送A去机场，A非要司机按他指他指定的路走（背景: 杭州近两年赶工修地铁，司机提醒过A该路可能无法通行），最后真吃了瘪只能回头跟导航走。
  • 一件事是在雨天的时候接到了A的单，A一上车就将湿漉漉的伞丢在了座位上，司机又心疼车，又觉得影响了其他乘客，更觉得A素质不行了。
  • 因此在之后某次司机送A到某打车不便的景区，A要求他晚上回来接他并愿意付调度费时，他直接搪塞了过去hhhhh。

相关资料:

1. 关于下架滴滴出行的通报

做的事情多了，越来越感觉到细节之中蕴藏着宇宙。工作中偶尔需要使用一些看似浅显的手段，在调研时都能发现系统的方法论（向伟大的前人致敬）。这当然是个好事，如果能掌握实现中的每个细节和原理，在交流现有方案时就是无懈可击的；这也是很大的挑战，我现在做事还有太多想当然，每个想当然可能都意味着失败，我需要训练自己去掌握对细节的敏感/直觉，我以为这需要大量的实践才能掌握。

巧的是前不久部门里的9做了一次分享，分享的内容叫做“结构化思维”，分享只有15分钟，没有很深入，但足够介绍这个概念。那之后我也没有对这个概念进行进一步的研究(近期实在有点忙，等晋升完和手头这本书看完，是有打算系统训练一下的），只是我的瞎想又有了一些新的素材。大佬的结构化思维展现为树状且可能是深度遍历的思考方式和输出方式，以我的理解来举个例子，3W1H(Why，What，Where，How，也有5W1H分析法)是结构化很强的分析方式，在处理需求和输出方案时能给自己和别人清晰地指导。我瞎想的结构化思维最终应该是网状的结构，效果应该是除了上述的思考方式外思维中万物有联系，为了区分，我就管我胡诌的这个思维方式叫网状思考，再举个例子，如计算机语言为什么由01组成？从能力上看01能够描述足够多的信息（参考摩斯电码和布莱叶盲文），从实现上看计算机按组成可拆解到加法器，而加法器的实现又可以关系到电路，电路的开闭正可以对应01，电路的设计离不开逻辑运算和电流（实际上逻辑运算中有先贤对哲学的探索故事），电流又涉及电解和原子结构…。这中间可能有没考虑到或者偏颇的内容，但重点是这个过程将计算机的实现和物理、数学、化学乃至政治、历史关联在了一起，这是将多个不同领域的结构化的树进行了关联。

话接前文我觉得对于掌握事物的所有细节困难且需要大量实践的积累，而网状思考的思维应该是能有效减少这个实践需求量的。这里的“有效”我觉得有两个内涵，一是针对“直觉”的训练有了系统的方法论指导，这个方法论就是结构化思维，使对细节的掌握不是胡乱的枚举，而是成体系的梳理；二是对事物知识的掌握更加牢靠，思维的每个点都可能和其他点之间有着联系，记忆和逻辑推理合理且自然。

说到这我产生了一个臆测，部分基础学科中似乎常有泰斗无法接受新兴观点的事情，比如玻尔的原子模型就不被爱因斯坦接受，甚至有这么一句玩笑话“不是新的观点被接受，而是反对的人逐渐都去世了”，可能这些“老学究”也并不是不能接受新的理论，而是其思维体系/网络过于强健且“合理”，以至于新理论可能让其一辈子构建的体系崩塌，因此但凡新理论有一点瑕疵，那么都是难以接受的。而学院的年轻人，可能知识尚未构成自洽的网络，新的理论看起来有希望拨开传统中尚不能解释的雾霾，这便是值得尝试的。

以上目前也还只是我的又一次瞎想，从这乱七八糟的行文也可以看出来我也并没有什么体系的思维，但据切实学习过结构化思维方式的师兄介绍，至少这部分内容是较有价值的思维工具，等真的进行部分了解了，我再回头看看这篇博客是不是又在放屁吧hhh。

我其实是个挺愚钝的人，也并不太擅长“感悟”东西，工作近两年其实并没有觉得自己在这种软实力方面有很大的提升。幸运的是我老板是个资历深厚且愿意和我简单聊聊这种事的人(在沟通绩效时)，因此我的为数不多的感悟大多是老板直接或间接启发得到的，也希望自己在之后的工作中能时常想起，时常遵循吧。

owner意识

owner意识是在我司时常能听到，但FY20财年末我老板着重跟我提起的。虽然现在内外一致认为我司的互联网词汇只是pua或者没有营养的堆砌，但是这个词所代表的能力确实是当时的我所缺少的。

直白的解释，owner意识就是把自己所负责的应用(或者是产品、模型、服务…)当成自己的“财产”，而不仅仅是工作的内容。可能这对于不同的人来说有不同的理解，不同的含义，就我来说，这个词代表的是“懂得接受，懂得拒绝(需求)”。

懂得接受需求，指的是懂得挖掘需求背后的逻辑(可能也叫产品意识？)，如果一个需求是合理的、有价值的，还需要尽量找到它最好的实现方式，而不是做一个需求处理机器人。这里的最好的方式说的不是架构上的，当然这也重要，但只考虑架构合理也只是炫技，说的是以用户的视角+应用本身的“干净”来审视需求。我暂时没有想到特别好的例子来说明(尽量不要在应用里维护过多上下游系统的逻辑大概算一个)。

相对于懂得接受需求，懂得拒绝需求对于我来说更难掌握，其实两者的内涵基本一致，就是需求是否该由这个应用来承担，是否有更合适的人/应用来实现，需求开发出来有多大意义，能有多少人用它，就算是合理的需求，应该怎么评估重要性进行呢排期…都是很现实的问题，但是对于一个刚毕业不太久的人来说仍然是需要学习的技能。

掌握手上的资源

想法来源于前不久我和老板及PD对新财年某个项目的规划时感受到的。事实上从去年六月开始，我在工作时能写代码的机会很少了，应老板要求搬起了数据分析的砖，而上面提到的项目就是进行模型建设的数据分析方案。我在方案制定的过程潜意识里给自己设了个限制——我只能利用现有的数据来构建需要的模型，当我阐述完我的方案后，PD给出的第一个反馈就是不要设限，我可以做问卷调研、可以发动运营同事、可以让老板给我背书…我这才感觉到了自己其实是有资源的，并且也应该积极合理利用资源。

但谨慎使用

这条应该是上一条的前提，之所以放在后面，一个是察觉到的晚，另一个是个人感觉意识到自己手上的资源更为“高级”。

“谨慎使用”是说先穷尽现阶段自己能进行分析/尝试/poc的手段，“走投无路”之后再拿着充足的证据，向自己以及对你即将push的人证明你方案的必要性以及能拿到的成果。我这里用词可能有些极端，我要说明的是这其实是对工作的一种态度，也是我自己没有拿捏好的态度。“穷尽手段”代表的是你对正在负责的项目已经探索了你能力内的所有可能，在这些可能之中你选择了最好的一个，有必要的话你还应该再找能力高于你的人进行论证。   大公司内部常常会有让人诟病的一点是，很多人喜欢重复造轮子，不管是造内部的轮子还是造开源社区的轮子。我自己也见过不少这种例子，也看过心直口快地大佬在内部分享上“怼”同学“造轮子”的理由，我不清楚多少轮子是开发人员迫不得已想出来的最优解，多少轮子只是为了晋升述职的筹码，但是在看到、遇到类似的情况时多分析分析其中的可能性，大概是会对我自己颇有裨益的。

有点好笑的事，实际上这点是我在上文提到的方案汇报后时隔一周的第二次汇报上被老板反问时理解的，而我当时提出的新方案也正是围绕量表调研的一系列置信度、信度效度巴拉巴拉措施展开的(捂脸)。老板提出的问题是我是否调研过公司内部相关的历史问卷调研情况，以及相关平台的数据，有足够的证据能让他向上证明一次新的问卷调研是必要的。

定义问题的能力

又是一个在绩效沟通时老板提到的能力hhhh。老板说的很直白，就是遇到问题时能很快地定位到问题本质的能力。我理解这，在写代码上就是debug的思维清晰，在接需求上就是搞清楚做不做、谁来做、怎么做的能力，在业务上就是看清楚发展方向的能力…老板说他至今(工作十余年了)也没有很好的掌握，可能是谦虚，也可能是这个能力层次过于丰富，不管怎么说，这是一个万金油能力(公司内大佬们的晋升指导也反复提到)，学而时习之吧。

招聘遇到的两种人

当然我的水平还没到足以担任面试官，是老板谈起他招聘时会有两种人让他想给出offer。

第一种人是研究的方向、之前的工作和目前我们正在做的业务十分match的。这种人不一定能力很强，但是你知道他一进来就能干活，就能推进事情进展，中规中矩，无功无过，只是可能缺少从零到一推动一件事落成的本事。

第二种人有点相反，他做的事在能力面前显得就不那么重要了，面试的时候你能感觉到他对自己做的事把控清楚，能条理清楚地和你讲清楚项目从设计到落地的细节和考虑。

老板说第二种人很难得，也更倾向于招第二种人。简单想想就知道这是很显然的道理，做成某件事很简单，但是老道的猎人总能嗅出来应聘的人是跟着需求按部就班地走，还是带着思考地创造。

Data Sense

Data Sense, 大概对于统计学或数仓出身的同学来说很熟悉，对于我这种半路出家的半吊子来说是个新词(笑。我也不清楚它代表的更多的是一种敏感，还是一种能力，或是一种直觉，简单地说它指的是记住，并清楚地了解自己相关的数字的含义，比方说你负责的业务的流量情况，流量波动幅度可能的原因等等等。

组里的数据同事说这是无价之宝，数字是很难记住的，只有门清数字的逻辑才能做到，向老板汇报最要紧的就是这种能力(这个也基本是原话hhh)。在我的直观感觉上，总觉得对于天天和数据打交道的人来说这大概不算难，但是仔细想想，虽然不完全在做数据，但也干了近一年和数据有关的活了，就我自己来说确实是做不到，实在惭愧。

抛开数据科学相关的领域不说，对于研发来说这也应该是要紧的能力。业务上PV、UV的水位，任务执行的效率和成功率，程序运行时FGCT该是多少，多少算异常，可能大体上还是基于经验，但是能有对数字敏感且能快速把握多少也需要天赋和能力吧。

大体来说，近一两年还记得的想法大概就这么些，实际上大多数都是最近才记起来的，乱七八糟地记个流水账，权当为了加深印象吧~

import java.util.Arrays;
import java.util.Collections;
import java.util.List;

public class A {

    private List<String> unsortedList;

    @Override
    public String toString() {
        // 为了输出时方便查看List内容，将其排序后返回
        Collections.sort(unsortedList);

        return unsortedList.toString();
    }

    public List<String> getUnsortedList() {
        return unsortedList;
    }

    public void setUnsortedList(List<String> unsortedList) {
        this.unsortedList = unsortedList;
    }
}

在之后执行/调试的过程中他发现，这个类的表现很不稳定，unsortedList的结果在乱序和有序之间反复横跳，且自己在一步步调试过程中并没有涉及到给该数组排序的指令，这让他十分疑惑。
   经过观察他发现以下几个现象：

• 在正常执行的过程中unsortedList与初始化时的顺序保持一致
• 在调试过程中，如果不对A类进行断点观察，则unsortedList在使用时的顺序也与初始化时的一致
• 但凡设了断点_观察_A，便会发现unsortedList被排序了

对此现象我们称之为薛定谔的排序(误。
   聪明的读者可能很快发现了，问题出在重写的toString方法上，但是当POJO类中充满大量业务相关的字段，或者toString中的操作并没有这么明显的时候，这个陷阱就很可能被忽略掉。
   实际上，在我们debug的时候，IDEA提供的展示值给我们带来了很多便利，而这个展示值就是通过调用toString方法实现的。
   通过查阅官方的使用文档我们也可以知道，通过设置Build, Execution, Deployment/Debugger/Data Views/Java，我们按需对不同类设置启用toString展示。同时在这一个设置窗口中，我们还能设置其他debug过程中的数据展示情况，如

Enable alternative view for Collection classes

这栏窗口允许设置更“人性化”的Collection classes展示方式(比如对于List的实现类，勾选该栏会展示List的大小，取消勾选会适应其他数据展示勾选项——如toString)。
   但事情到这还没结束，当我们在toString中打上断点，尝试进行“多余的”验证来解释debug的机制时，我们会发现始终无法进入toString方法，并且在IDEA下方会提示 Skipped breakpoint at debuggertrap.A:13 because it happened inside debugger evaluation。这行提示的意思是说，该断点发生在debugger的evaluation线程中，因此我们将其进行跳过，有趣的是在查找资料的过程中，我找到了这么一页讨论是关于eclipse是否该跳过evaluation阶段的toString断点的，对于是否跳过，参与讨论的人员都有认为confusing的点，显然IDEA的作者们替我们做了决定，将debugger进行evaluation时的toString进行了跳过(我没找到相关的设置，如果有大佬清楚其中的逻辑的话希望不吝赐教)，这也确实造成了部分用户在使用时对逻辑产生了误判。
   关于IDEA中进行debug的toString隐式调用陷阱讲到这就算结束了。关于debug的原理部分我没有深入地进行研究，而关于其中的JDPA体系在网上有大量资料，我也就不献丑了，仅将官方资料放在👇，有兴趣的读者可以自行前往阅读。如果有时间进行探索将另开文章记录。

相关资料:

1. IDEA关于debugger中的用户视图设置
2. JPDA体系官方介绍
3. 一篇JDPA体系的介绍
4. 另一篇更深入的JDPA体系的介绍，含部分实现代码
5. eclipse论坛中关于是否开启evaluation线程中的toString断点跳过的有意思的讨论

主要概念

VPS

虚拟专用服务器（英语：Virtual private server，缩写为VPS），是将一台服务器分割成多个虚拟专用服务器的服务。实现VPS的技术分为容器技术和虚拟机技术。在容器或虚拟机中，每个VPS都可分配独立公网IP地址、独立操作系统、实现不同VPS间磁盘空间、内存、CPU资源、进程和系统配置的隔离，为用户和应用程序模拟出“独占”使用计算资源的体验。VPS可以像独立服务器一样，重装操作系统，安装程序，单独重启服务器。VPS为用户提供了管理配置的自由，可用于企业虚拟化，也可以用于IDC资源租用。 —— Wiki

关于服务器的选择及购买我在其他文章中有提到，有需要的可以前往或查找相关资料。

Shadowsocks

Shadowsocks（简称SS）是一种基于Socks5 代理方式的加密传输协议，也可以指实现这个协议的各种开发包。目前包使用Python、C、C++、C#、Go语言、Rust等编程语言开发，大部分主要实现（iOS平台的除外）采用Apache许可证、GPL、MIT许可证等多种自由软件许可协议开放源代码。Shadowsocks分为服务器端和客户端，在使用之前，需要先将服务器端程序部署到服务器上面，然后通过客户端连接并创建本地代理。——Wiki

关于SS(及SSR)Wiki上有进一步的介绍，有兴趣的同学可以点击查看。其原理简单来说，就是你在境外拥有一台未被GFW拉入黑名单的服务器，你就可以通过与这台服务器建立起一个加密通道躲过GFW的过滤规则，从而访问墙外资源。更深入的解释可以参考 这篇博客 和 这篇博客

搭建流程

作为搭建的前提，我们已经在合适的平台上购买并了VPS并进行了简单的配置，接下来便开始着手进行“见不得人的勾当”。

ip检测

我们首先要确定的是，我们VPS的ip地址没有在过滤名单中，通过 这个网站 进行检测，若国内国外都可以正常与VPS进行ICMP/TCP连接，便可以进行之后的步骤。

SS/SSR安装

SSR对SS在混淆和协议方面进行了改进，两者在安装方式上没有明显的不同，我们这里以SS为例。

SS 安装及启动

# 安装 pip，若以安装可直接跳过
sudo apt install python-pip
# 使用pip安装shadowsocks
sudo pip install shadowsocks

如此shadowsocks便安装完成了，接下来以指定配置文件的方式启动ss，

# 编辑配置文件, 不同安装方式对应的默认配置文件不同，请读者自行匹配或创建
vim /etc/shadowsocks.json

{
  "server": "0.0.0.0", // 服务器过滤规则，0.0.0.0表示允许所有来源ip请求
  "server_port": 8399, // 指定服务器对外开放端口
  "local_address": "127.0.0.1", // 本地代理监听地址
  "local_port": 1080, // 本地代理监听端口
  "password": "${your_pass_word}", //指定连接方式
  "timeout": 600, //超时设置
  "method": "aes-256-cfb" //加密方式，后续客户端设置需要与这里保持一致
}

# 启动ss服务器
/bin/python /usr/local/bin/ssserver -c /etc/shadowsocks.json -d start
# 关闭
/bin/python /usr/local/bin/ssserver -c /etc/shadowsocks.json -d stop
# 重启
/bin/python /usr/local/bin/ssserver -c /etc/shadowsocks.json -d restart

关于 undefined symbol: EVP_CIPHER_CTX_cleanup

可能有同学在执行时会碰到如上报错，是由于在openssl1.1.0版本中，废弃了EVP_CIPHER_CTX_cleanup函数，只需要将 ${your_python_lib}/dist-packages/shadowsocks/crypto/openssl.py 中的EVP_CIPHER_CTX_cleanup替换成EVP_CIPHER_CTX_reset即可。

关于保姆安装方法

参考 这篇文章，将多种版本的ss进行打包及手把手教学安装

本地客户端安装及配置

pc端

1. 在github仓库下载匹配版本的shadowsocks客户端并进行安装。
2. 点击 服务器 -> 服务器设置…进入服务器设置页面
3. 根据VPS的配置文件(如上文的/etc/shadowsocks.json)进行配置
4. 完成设置，进行连接

手机端

这里以iphone为例

1. 登录非国区appstore账户，下载Spectre
2. 通过pc端的客户端分享配置，扫描二维码或粘贴url添加服务器信息
3. 由于某些原因不方便安装pc端ss客户端的，可以自己生成url在手机端进行粘贴配置，如下

// 拼接待加密路径
String uri = "${method}:${password}@${your_ip_address}:${server_port}";
	// base64编码
String base64 = Base64.getEncoder().encodeToString(uri.getBytes());
      // 输出url
System.out.println("ss://" + base64);

查看服务器端访问日志

tail -f /var/log/shadowsocks.log

关于端口检测及开放

可能有同学会碰到这种情况: ip监测正常, 客户端与服务器端配置也一致，但是访问日志中显示一直接收不到请求。遇到这种情况就需要对服务器端口进行监测。监测网址

情况一: 国外服务器成功连接，国内服务器失败

这种情况是这个端口被ban了，在配置文件中修改server_port并重启ss服务尝试。

情况二: 所有服务器都显示连接失败(Connection to xxxx:xxxx failed)

   这种情况比较大的可能是防火墙未将配置的端口打开，执行

sudo ufw allow ${server_port}/tcp

后再次进行端口检测

参考资料:

1. Shadowsocks四合一安装
2. 关于Ubuntu下防火墙的配置
3. 一篇比较详细的关于ss/ssr配置的博客
4. ss原理简单介绍
5. 胡子哥的ss原理介绍及安装说明 …

准备工作

由于其他的考虑，这个博客使用 独立域名 + VPS + 个人电脑 进行搭建及部署。以下是个人对于相关平台的选择：

cd /home/admin
mkdir blog_receiver.git
 // 建立git裸仓库并设置文件夹权限，将$USER替换为你自己的用户
git init --bare blog_receiver.git && chown -R $USER:$USER blog_receiver.git  // 设置文件夹权限
cd /home/admin/blog_receiver.git/hooks //假设/home/admin/blog_receiver.git为建立的裸仓库
touch post-receiver

打开post-receiver并输入如下内容

```sh
#!/bin/sh
git --work-tree=/home/admin/blog_www --git-dir=/home/admin/blog_receiver.git checkout -f

location / {
    root /home/yocha/blog_www;  index index.html index.htm;
}

deploy:
  type: git
  repo: $USER@$host:/home/admin/blog_receiver.git //$USER替换为上文提到的用户，$host替换为你的服务器host或ip
  branch: master

if theme.disqus.enable == true
  link(rel='stylesheet', type='text/css', href='https://cdn.jsdelivr.net/gh/sukkaw/disqusjs/dist/disqusjs.css?v=' + theme.version)
  script(type='text/javascript' src='https://cdn.jsdelivr.net/gh/sukkaw/disqusjs/dist/disqus.js?v=' + theme.version)
  script(type='text/javascript' id='disqus-count-script').
      $(function() {
           ...
           xhr.ontimeout = function () { xhr.abort(); };
           xhr.send(null);
    // 插入如下函数
    // begin
           setInterval(() => {
            $.each($('iframe'), (arr,x) => {
                let src = $(x).attr('src');
                if (src && src.match(/(ads-iframe)|(disqusads)/gi)) {
                    $(x).remove();
                }
            });
         }, 300);
    // end
         });
        ...

---
title: { { title } }
date: { { date } }
tags:
  -
categories:
  - []
comments: true //允许评论
layout: post //布局类型
toc: true // 显示目录
---