Q：是否可以有五级或更多层级域名？
A：
DNS 协议本身不限制域名层级数量。理论上可以无限添加子域名层级。但有限制：
Q：多级域名如何配置
A：
配置多级域名：为每一层级的域名单独配置 DNS 记录（如 A、CNAME）。如：
1 | level1.com. IN A 192.0.2.1 |
近10年，开发过一个很简陋的舆情监控平台。大致的架构就是用爬虫从新浪新闻、微博、微信公众号等平台爬取新闻，存储到ElasticSearch中。对于每一条新闻的内容，基于一个负面词库（比如“爆雷”、“下跌”等词），一个公司名+公司高管名字的词库，根据一个自创的算法计算在新闻中的出现次数和关联性，由此判断这篇新闻是否是公司相关的负面舆情新闻。
现在想来，其实就是用稀疏向量检索的方式，企图模拟稠密向量检索的语义识别效果。当时实测下来整体效果还不错。但对于包含了否定词，以及讽刺、反话的内容，识别效果不佳。
本文先比较稀疏向量和稠密向量的差别，然后介绍稠密向量的生成、相似度比较，以及检索方式。然后介绍了阿里云上的向量数据库。
在信息检索领域，“传统”方式是通过关键词进行信息检索，其大致过程为：
老黄的演讲中的确不乏画饼的成分，以部分抵消DeepSeek对于Scaling Law的挑战。不过对于我们有价值的，还是他是如何从逻辑上说圆自洽。
ARTS中的 Review英文技术文章点评 和 Share技术文章分享，先试点按照月为单位，每月发一篇汇总吧。每篇写一小段感想。
关于英文技术文章来源，从v2ex的推荐，找到了DevURLs – A neat developer news aggregator的文章聚合网站。但感觉这些文章大多很短，看得不太过瘾。所以在尝试了两周后，改为根据本周关注的技术点，用英文关键字Google，选择搜索结果中质量比较高的。
https://dzone.com/articles/ebpf-for-cloud-computing
eBPF这个术语看到过好几次，找了一篇入门介绍。主要是针对eBPF和K8S结合的场景，包括网络可观测性、安全、性能监控等用途。
eBPF的主要优势在于不用开发Linux内核模块，也能在内核执行。这点使其很适合K8S，用于包含Calico、Cilium在内的开源项目。
在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了。只记录一些个人觉得实践时需要关注的点。
由于自家的关系，以下云资源默认为阿里公共云。
IaC核心是版本控制和可重复，实现提效、降低误操作、一致性与合规安全。
适合IaC的业务场景是什么？企业上云、环境复制、环境重建、合规管控等。
保理，从本质上来说，就是应收账款的融资服务。
举个场景:某桂园向某混凝土公司A采购了2000吨水泥，应收账款100万。但由于账期原因，应收账款是按照季度结算。但公司A因为款项没有即时结清，产生了资金周转问题。于是公司A就将应收账款以折扣价转让给了保理商B。保理商B给供应公司A提供了融资，并通知某桂园回款后续不再打给公司A，而是打给保理商自己。季末某桂园将回款打给了保理商B。保理商B在融资和回款的差价里赚到了收益。
整个流程可以参见下图
在这个最基础的流程中，有三方：
保理这个概念产生的时候，都是由拥有融资需要的卖方主动发起的。但卖方拿到融资却不供货转身跑路的情况，也不是不会发生。这种情况下，买方当然也不会为没有收到的货而白白付钱。保理为了尽量避坏账，会对卖方的资质和规模进行要求。
但现实中很常见的情况是：上游的卖方是中小企业，无法达成资质规模要求，尽调难度也很大；而下游买方是龙头企业，拥有较高的资信程度。为了在这种场景下也能让保理商放心融资，会由卖方（混凝土公司A）找买方（某桂园）做担保，由买方主动发起保理申请。买方为了保证上游供应链的稳定，出面找保理商做担保：公司A确实是我的上游供应商，我们有商务合作。如果你能信得过我的话（大企业的授信担保），就给公司A融资，然后在一定时间段后到我这里兑回款。保理商相信了A的资信，给公司A提供了融资。
在这里出现了一个核心企业的概念。核心企业是供应链中的概念,是供应链中的关键节点，资信程度较高（AA＋是基本门槛）。
在保理流程中，核心企业是保理的发起方。核心企业的类型也是区分正向保理和反向保理的关键判断因素。核心企业是卖家，就是正向保理；核心企业是买家，就是反向保理。这里的“正”和“反”指的是相关交易链的方向。
本文是极客时间《赵成的运维体系管理课》的读后体会之二 。
ITIL的10个重要的IT管理关键模块之一就是故障管理。
故障永远只是表面现象，其背后技术和管理上的问题才是根因
即当技术和管理上的问题积累到一定程度后，就会以故障的形式爆发出来。所以不能仅将眼光限于故障本身和直接责任人。
故障需要有标准化的流程来指导我们的处理过程。
这里有个关键组织:故障应急小组。这个组织有4个职责：
本文是极客时间《赵成的运维体系管理课》的读后体会之一。
在公司的运维配置管理实践中，存在一些混乱的现象：
这些情况很可能短期甚至长期内不会直接导致什么问题。可能就是让信息安全整理材料多费一点时间，开发排查多绕一点弯路，或多花一些硬件维持或扩容费用。但有些时候这些问题就是给未来出现的生产问题埋下隐患。
硬件的归属，服务器的使用情况，应用域名管理，软件版本，应用与中间件的关联等等，都属于广义上的配置管理。所以归根到底，是配置管理的混乱。
在ITIL（Information Technology Infrastrueture Library）中，有10个重要的IT管理关键模块。其中配置管理（CMDB）通常被认为是其他IT流程的基础。
CMDB（Configuration Managoment DataBase），配置管理数据库，是与IT系统所有组件相关的信息库。它包含IT基础架构配置项的详细信息。
在传统运维时代，CMDB的核心对象是资源，即网络和硬件设备。但在云计算和互联网运维时代，CMB的核心已经转变为了“应用”。随着微服务架构的推广，以应用为核心的注册中心、缓存、消息队列、数据库等都需要纳入配置管理的管理范畴。
以应用为核心的配置管理标准化可以包括：
疫情期间积累了一些远程办公条件下的项目管理经验，稍微整理一下。我司从企业文化到网络硬件，不太具备远程办公的基因，要补课的地方就额外多。
亚马逊CEO贝索斯提到过一个原则：如果两个披萨饼都喂不饱一个团队，那么这个团队可能就太大了。按照这个逻辑，我的团队可能只能容纳两个人。。。
玩笑开完了。但事实就是，对于一般人来说，能较好管理5~6个就已经是不错了。当团队人数超过这个规模，需要将团队拆分为6-10人的小团队规模，增加汇报层级，才能管得过来。
每个小团队可以包含前端、后端和测试，而数据库、UI等共享资源单独一个团队。
对每个小团队需要指定一个第一责任人（以下简称“责任人”）。这个责任人需要有以下的素质：
远程办公期间的通知事项会比较多。邮件通知方式不能确保所有人都会在第一时间查看邮件。
通过即时通信的群通知，可以确保绝大部分人都能第一时间看到并响应。
即时通信大群的注意点：