ARTS中的 Review英文技术文章点评 和 Share技术文章分享，先试点按照月为单位，每月发一篇汇总吧。每篇写一小段感想。
关于英文技术文章来源，从v2ex的推荐，找到了DevURLs – A neat developer news aggregator的文章聚合网站。但感觉这些文章大多很短，看得不太过瘾。所以在尝试了两周后，改为根据本周关注的技术点，用英文关键字Google，选择搜索结果中质量比较高的。

Review

eBPF for Cloud Computing - DZone

https://dzone.com/articles/ebpf-for-cloud-computing

eBPF这个术语看到过好几次，找了一篇入门介绍。主要是针对eBPF和K8S结合的场景，包括网络可观测性、安全、性能监控等用途。
eBPF的主要优势在于不用开发Linux内核模块，也能在内核执行。这点使其很适合K8S，用于包含Calico、Cilium在内的开源项目。

Improving language understanding by generative pre-training[J].

https://s3-us-west-2.amazonaws.com/openai-assets/research-covers/language-unsupervised/language_understanding_paper.pdf

在B站李沐视频和内网解读文章的辅助下，读了GPT-1的论文。除了论文本身的知识点外，有2个感受：

大数据的相关性特性

挺巧的是，最近从不同来源听到了这个理论两次。

第一次是ACE题库里的一道题：“美国海军军官莫里通过对前人航海日志的分析，绘制了新的航海日志图，表明了大风与洋流可能发生的地点，这体现了大数据分析理念中的：”
这道题的标准答案是：在分析方法上，更注重相关分析而不是因果分析。

第二次是听播客“纵横四海”，讲瑞幸数字化。瑞幸除了把甜度、浓稠度等饮料的指标做了数字化之外，也将其和销量的反馈结合起来。但在结合的时候，并不会试图推断出甜度与销量的因果关系，而是相信数据给出的指引。
播客里还举了几个典型的案例，比如沃尔玛发现飓风前人们喜欢屯蛋挞。至于为什么是蛋挞，而不是薯片，也不是可乐，从因果性没法给出很好的解释。
还有亚马逊的案例中书籍推荐之间的相关性，医疗保险方面买车与遵医嘱信用分的相关性。
这时候就要反人类的本能，放弃对因果性的追究，去全身心拥抱大数据。

从某个角度，LLM中对Few Shot有效性的解释，也可以从这个角度来理解。Few Shot本身并没有改变模型，但得到的结果就是更好了。即Few Shot与结果的有效性之间存在相关性。但当前的理论模型只能给出一些猜测，还无法完美证明。

个人对因果性与相关性的看法

对于这个现象，我的个人看法分为两点：

• 接受这个事实，从实用性角度先利用起来。
• 关注业界对于其背后原理的研究进展。

背景

在之前参与资产市场产品迭代的时候，就资产市场与研发平台的打通，研发团队就提出过使用IaC，实现“一键下行”。一键下行，指的是在下行复用组件资产的时候，将组件所依赖的资源也同时自动化开通，然后自动将组件部署在新开通的资源上。
举个例子：假设4A组件需要依赖RDS、Redis、OSS，就在后台配置的云资源环境自动申请RDS、Redis、OSS。站在研发的视角，隐藏了资源申请的复杂性，加速了复用流程，提升了研发体验。
在资产市场对外输出时，对接的云资源往往没有那么理想，必定是阿里云公共云资源。如果使用IaC，便于适配不同的云环境。

接下来即将开始的工作，可能也会涉及大量而频繁的云资源开通。最近在做Demo的时候，就深感开通和销毁云资源这个繁琐的事情有多浪费时间。
以程序员的偷懒本性，自然想到了使用IaC来提升效率。

概念和快速入门指引可以直接查阅参考资料，就不copy & paste了。只记录一些个人觉得实践时需要关注的点。
由于自家的关系，以下云资源默认为阿里公共云。

2. 工作中可能用到IaC的业务场景

IaC核心是版本控制和可重复，实现提效、降低误操作、一致性与合规安全。
适合IaC的业务场景是什么？企业上云、环境复制、环境重建、合规管控等。

3. 学习时的几个选型

3.1 Terraform vs. 阿里云ROS

1.保理的概念

保理，从本质上来说，就是应收账款的融资服务。
举个场景:某桂园向某混凝土公司A采购了2000吨水泥，应收账款100万。但由于账期原因，应收账款是按照季度结算。但公司A因为款项没有即时结清，产生了资金周转问题。于是公司A就将应收账款以折扣价转让给了保理商B。保理商B给供应公司A提供了融资，并通知某桂园回款后续不再打给公司A，而是打给保理商自己。季末某桂园将回款打给了保理商B。保理商B在融资和回款的差价里赚到了收益。
整个流程可以参见下图

在这个最基础的流程中，有三方：

• 卖方:某混凝公司A，也可以称为债权方、上游
• 买方:某桂园，也可以称为债务方、下游
• 保理商:分为商业机构进行的商业保理和银行保理

1.1 正向保理和反向保理

保理这个概念产生的时候，都是由拥有融资需要的卖方主动发起的。但卖方拿到融资却不供货转身跑路的情况，也不是不会发生。这种情况下，买方当然也不会为没有收到的货而白白付钱。保理为了尽量避坏账，会对卖方的资质和规模进行要求。
但现实中很常见的情况是：上游的卖方是中小企业，无法达成资质规模要求，尽调难度也很大；而下游买方是龙头企业，拥有较高的资信程度。为了在这种场景下也能让保理商放心融资，会由卖方（混凝土公司A）找买方（某桂园）做担保，由买方主动发起保理申请。买方为了保证上游供应链的稳定，出面找保理商做担保：公司A确实是我的上游供应商，我们有商务合作。如果你能信得过我的话（大企业的授信担保），就给公司A融资，然后在一定时间段后到我这里兑回款。保理商相信了A的资信，给公司A提供了融资。
在这里出现了一个核心企业的概念。核心企业是供应链中的概念,是供应链中的关键节点，资信程度较高（AA＋是基本门槛）。

在保理流程中，核心企业是保理的发起方。核心企业的类型也是区分正向保理和反向保理的关键判断因素。核心企业是卖家，就是正向保理；核心企业是买家，就是反向保理。这里的“正”和“反”指的是相关交易链的方向。

本文是极客时间《赵成的运维体系管理课》的读后体会之二 。

1.对故障的认识

ITIL的10个重要的IT管理关键模块之一就是故障管理。
故障永远只是表面现象，其背后技术和管理上的问题才是根因

即当技术和管理上的问题积累到一定程度后，就会以故障的形式爆发出来。所以不能仅将眼光限于故障本身和直接责任人。

• 管理者要先自我反省:员工只是执行者，管理者的责任永远大于执行者
• 强调用技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题
  • 短期可以辅以一些管理措施，比如靠宣传学习必要的Double Check/制定复杂操作的Checklist等。但是这些只能作为辅助手段，一定不能是常态
  • 随着系统复杂度越来越高，迟早有一天会超出单纯人力的认知范围和掌控能力，各种人力的管理成本也会随之上升，所以最终必须将这些人为动作转化到技术平台中去

2.故障的定级

故障需要有标准化的流程来指导我们的处理过程。

这里有个关键组织:故障应急小组。这个组织有4个职责：

本文是极客时间《赵成的运维体系管理课》的读后体会之一。

运维配置管理实践中一些混乱现象

在公司的运维配置管理实践中，存在一些混乱的现象：

• 信息安全收到fastjson的安全问题报告，但报告中的服务器对应的系统却有错位
• 信息安全收到了报告，发现tomcat的某个版本出现了漏洞需要升级，但不知道到底影响到哪些系统，只能逐个请每个系统的负责人判断
• 部分服务器（特别是开发坏境服务器）已经基本可以确认不再被使用，但服务器资源没有回收，每月持续占用硬件预算
• 某系统上线后发现中漏配置了一个域名，导致部分用户打开首页报错
• redis缺少规划，多个系统公用一个redis集群的情况下，无法根据键（key）来区分每个系统占用了多少缓存。遇到内存不足的情况很难深入排查是哪个系统导致
• 生产消息队列中不少queue堆积着大量消息，但不知道是否还在用，不敢随意删除

这些情况很可能短期甚至长期内不会直接导致什么问题。可能就是让信息安全整理材料多费一点时间，开发排查多绕一点弯路，或多花一些硬件维持或扩容费用。但有些时候这些问题就是给未来出现的生产问题埋下隐患。
硬件的归属，服务器的使用情况，应用域名管理，软件版本，应用与中间件的关联等等，都属于广义上的配置管理。所以归根到底，是配置管理的混乱。

ITIL和配置管理CMDB

在ITIL（Information Technology Infrastrueture Library）中，有10个重要的IT管理关键模块。其中配置管理（CMDB）通常被认为是其他IT流程的基础。
CMDB（Configuration Managoment DataBase），配置管理数据库，是与IT系统所有组件相关的信息库。它包含IT基础架构配置项的详细信息。
在传统运维时代，CMDB的核心对象是资源，即网络和硬件设备。但在云计算和互联网运维时代，CMB的核心已经转变为了“应用”。随着微服务架构的推广，以应用为核心的注册中心、缓存、消息队列、数据库等都需要纳入配置管理的管理范畴。

以应用为核心的配置管理标准化可以包括：

疫情期间积累了一些远程办公条件下的项目管理经验，稍微整理一下。我司从企业文化到网络硬件，不太具备远程办公的基因，要补课的地方就额外多。

1. 按小团队划分并设定第一责任人

亚马逊CEO贝索斯提到过一个原则：如果两个披萨饼都喂不饱一个团队，那么这个团队可能就太大了。按照这个逻辑，我的团队可能只能容纳两个人。。。
玩笑开完了。但事实就是，对于一般人来说，能较好管理5~6个就已经是不错了。当团队人数超过这个规模，需要将团队拆分为6-10人的小团队规模，增加汇报层级，才能管得过来。
每个小团队可以包含前端、后端和测试，而数据库、UI等共享资源单独一个团队。

对每个小团队需要指定一个第一责任人（以下简称“责任人”）。这个责任人需要有以下的素质：

• 对小团队成员知根知底
• 快速响应的执行力和跟进能力
• 对任务目标有充分的理解

2. 通知走大群，信息收集走小群

2.1 通知

远程办公期间的通知事项会比较多。邮件通知方式不能确保所有人都会在第一时间查看邮件。
通过即时通信的群通知，可以确保绝大部分人都能第一时间看到并响应。
即时通信大群的注意点：

春节期间看完了极客时间的《说透中台》的课程，顺便也读了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》一书。这篇从实际项目的角度来想象一下，如果让我来负责公司的中台，应该怎么做。
首先说下评价：这个课程符合我对ThoughtWorks的刻板印象：有点滥用理论术语，干货不多；问题题了不少，解决方案不落地。可能是都是给其他公司做的项目，有保密协议的缘故。能理解，但还是不推荐。阿里的那本中台书更加实在。

1. 中台概念整理

1.1 中台的目的

中台的目的就是企业能力复用。

1.2 中台的分类

中台主流分为两大类：业务中台/数据中台。业务中台产生数据，数据中台做数据的二次加工，并将结果再服务于业务中台。
也有“技术中台”的概念，可以理解为一些技术中间件的整合和封装，但我倾向于不将其认定为中台。
中台强调一个复用。如果根本没有系统从零开始建设，一上来就搞中台很容易会过度设计。

2. 中台的抓手

中台会面对所有业务线的需求。虽然中台有企业级的属性，但不代表建设中台的时候必须梳理企业的全业务线。中台的愿景是能力复用，那么最好有具体的新业务作为抓手。

上家公司虽然有这样那样的问题，但在能让我掌控的服务器资源自由度上，也不是随便在哪家公司就能有的。能随便申请个半打一打的4核8G的虚机来搞事情什么的。。。跳槽后就只有自己的Windows工作机了。Docker Desktop搞了半天也没法启用Kubernetes，这也是为什么之前的“Kubernetes实战”系列到7月就戛然而止的原因。
只靠Docker Desktop，平时开发的时候起个数据库或redis是足够用了，但像service mesh之类的就玩不了了。趁年前有空，搭了一套Minikube，把步骤顺便记录一下。原本想合并到之前kubeadm安装的那篇里，但可能会翻起来不方便，还是单独另开一篇吧。
后续“Kubernetes实战”系列都会基于minikube环境来搭建。

1. 软硬件条件

现在内存也不值钱了，插个16G足够玩了。
操作系统上，虽然Windows 10家庭版+VirtualBox/VMWare也可以，但从硬件利用率角度，还是用Windows 10企业版/专业版/教育版+Hyper-V比较好。
在控制面板->程序->启动或关闭Windows 功能 里面打开所有Hyper-V选项然后重启。
重启后运行systeminfo，看到如下内容，说明操作系统层面已经ok了：

1

Hyper-V 要求:     已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。

Docker Desktop是否安装不影响，但在安装Minikube的过程中最好不要启动。在安装过程中报过一个create: precreate: no External vswitch nor Default Switch found的报错，不确定是不是相关。
顺带提一句，如果装了Docker Desktop，可以在Settings->Daemon->Registry mirrors里填写：https://dockerhub.azk8s.cn、http://hub-mirror.c.163.com和https://docker.mirrors.ustc.edu.cn
另外感谢这篇docker/kubernetes国内源/镜像源解决方式 - xinkun的博客 | Xinkun Blog的整理，我也复制一下备忘：

2. 网络条件

以防万一请先关闭Windows防火墙。
因为你懂的那个原因，需要本地搞个SS的梯子。如果哪个步骤因为网络原因卡住了，可以切成代理再试一次。

1. 微服务的公共API模块

微服务之间调用进程会出现DTO实体类的重复定义。比如服务A的接口返回User实体，服务B接收的时候，也需要定义一个同样的User实体。
在引入了Feign后，就有了一个避免项目间重复定义实体类的简单方案：我们可以在服务A开发的时候专门抽出来一个API模块。

这个API模块可以包含接口方法定义，URI以及和对外实体类定义（DTO），可以认为是A和B之间互通的约定。
一个最简单的API模块代码如下：

1
2
3
4
5
6
7
8
9
10
11
12

@Data
@AllArgsConstructor
@NoArgsConstructor
public class DemoDto implements Serializable {
    private String text;
}

@RequestMapping("/demo")
public interface DemoApiService {
    @GetMapping("/hello")
    DemoDto hello();
}

服务A的Controller负责对接口定义进行实现：

1
2
3
4
5
6
7

@RestController
public class DemoProducerController implements DemoApiService {
    @Override
    public DemoDto hello() {
        return new DemoDto("hello");
    }
}

服务A项目将API模块发布到Maven私服上。服务B项目只需要对API模块添加依赖：