从你第一句开始，我大概能猜到，你大概率是用错了。
比如你有一个复杂的表单查询 API ，你通常并不需要去写单元测试去测这个 API ，去模拟各种参数传入调用 API ，这没有必要，这种场景通常用 postman 、jmeter 这类工具去做就可以了。
单元测试通常是测 API 内部的业务逻辑，也就是针对模块化出来的代码单元去进行测试，当然并不是每个业务逻辑都需要测，涉及非常复杂的业务，你也可以先写单元测试，再写具体的代码逻辑。

@kyonn #12 负载均衡，不过通常很少直接在 compose 里用 scale ，会集成 swarm 或者用 k8s 来实现

因为 docker compose 本来就更适合于单机场景，通常一个 compose 文件一个网段，此时 service_name 是唯一的，不存在冲突。

```bash
networks:
net:
driver: bridge
external: false
ipam:
config:
- subnet: 172.19.0.0/24
...
...
```

如果你不指定 container_name ，通常会加上 project_name 前缀，和 index 后缀，swarm 也类似，用户完全不需要关心 container_name ，swarm 随机生成。

至于为什么不建议指定 container_name ，主要是不利于 scale ，非常不灵活。话说回来，有 scale 需求的，一般都上 K8s 了。

事实上，富人的小孩也学习，学的还比穷人好

开 22 端口，无密码登录，没事就 ssh 回家，用了一两年也没见有什么问题

AI 不太适合你不懂的领域，问的不好，很容易被坑然后绕进去。更适合你懂一点但是不是特别懂的领域，多反问就不会太容易被误导。找到一个适合自己使用边界很重要。

nas 小主机性能不行，直接 pc 机 windows 挂盘组存储池，也不影响正常用

这种场景常会依赖海量数据，比如去分析某个大型社交网络上用户实体之间的关系，生成用户画像，就可以基于图数据库构建知识图谱。

ceph 其实没你想得那么复杂，而且可以统一存储底层，cephadm 现在部署很简单，默认引导完添加一下 osd 集群就部署好了，而且自带 orch 编排，配合 systemd + podman 管理也没那么复杂，只需要用 rgw 对象存储的话，rbd 块存储 和 cephfs 文件存储你不配置保持默认都行，另外 ceph 是前期规划复杂点，后面稳定了基本不怎么要维护，只要挂盘扩容就行了。

简单的自定义快捷键，复杂的场景我一般都用这个，然后打字，实在记不住。

https://i.imgur.com/bpUr6HO.png

自建，kubespray ，灵活且强大

root@ns1:~# kdig +tls @1.1.1.1 global.market.xiaomi.com

;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 45832
;; Flags: qr rd ra; QUERY: 1; ANSWER: 5; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; PADDING: 318 B

;; QUESTION SECTION:
;; global.market.xiaomi.com. IN A

;; ANSWER SECTION:
global.market.xiaomi.com. 21229 IN CNAME sgp-l7-apm.slb.xiaomi.com.
sgp-l7-apm.slb.xiaomi.com. 229 IN A 8.219.182.98
sgp-l7-apm.slb.xiaomi.com. 229 IN A 47.236.195.174
sgp-l7-apm.slb.xiaomi.com. 229 IN A 47.236.201.189
sgp-l7-apm.slb.xiaomi.com. 229 IN A 8.219.154.11

;; Received 468 B
;; Time 2025-06-11 14:07:43 CST
;; From 1.1.1.1@853(TLS) in 2227.9 ms

@sentinelK 有的场景下，上下文信息是需要计算的，我试了很多种办法，感觉最好的情况就只能是分阶段，一步一步去引导，直接想一步到位挺难的

企业里有 Jenkins 的话，直接配合参数化构建就能做了，没什么开发成本

相比赔偿，云厂商可能更在乎信誉，你这明显是没看清楚规则。公有云 SLA 基本都是按月计的，不是你这么算的，你这个超长期可用性保证，哪家能保证啊？云厂商有免责声明，比如什么用户自身配置错误、API 使用错误、不可抗力、不可预知的因素啥的，另外你还要证明确实是云厂商服务的问题，另外，就算能赔偿吧，也是按可用性分等级的，所以也别想着能赔多少。

@fuzzsh 现在不知道了，收购前接触过，算是国内最早一批搞容器云服务的公司。很有意思的是，公司在国内，团队日常交流的用的是 slack https://i.imgur.com/NIvxivj.png

火山引擎被收购之前公司的 Boss 是谷歌出来的，整个团队都有点过于专注技术了，产品体验是有点差的。

@hackroad 调查一下呗，我有个强烈预感，过几年下云会成为大趋势。

说实话，国内现在做运维比开发难多了，没个几年实战经验搞不定的，要是只搞个 cicd 和 docker ，建议还是继续开发好了。现在的运维，要会 shell 、python 、golang 三种语言，要会 AWS 、阿里云，要懂架构、懂网络，里面坑多的是，搞得不专业不如不搞。要是让一个新人运维或者高级开发来搞都是一样的，不是胆子太大，就是胆子太小，就别说 prod 环境了，staging 环境估计都不敢让他动，。