网络讨论中，开发的定义还算清晰，一般默认是写业务的，运维的定义可就太模糊了，进机房搬服务器的、维护网络的、基础架构研发调优的都能叫运维，这差距太大。没有基准定义的争论直接忽略掉就好了。

Infra 相关岗位一般定义为和运维相关的基础设施研发或维护，似乎比较符合 OP 的兴趣。个人觉得找 Infra 相关的比较合适，Infra 偏研发更好一些，偏维护的也能接受。

cert-manager/caddy/traefik 可以用起来了，公网可以访问 80 和 443 的话，使用 HTTP-01 challenge 还是挺简单的。访问端口受限可以使用 DNS-01 challenge ，DNS API 操作受限还可以使用 acme-dns ，通过 CNAME 绕一下。
另外，业务证书监控还是要加一下。

写博客。
当然，在本站“博客”基本和“写”没关系，不是搞主题就是搞生成器。同样，这里推荐的也是打着写博客的名头，把玩一下 CI/CD 持续集成流水线那一套。像写代码一样写博客，实现持续集成持续部署。
选一个合适的生成器（ hexo 、hugo 一类），在本地 VSC 写 markdown ，提交推送到 Gitea 代码仓库，触发 Action 流水线，在生成器环境编译构建，封装为容器镜像，调用 docker ，更新部署，发布成功。
一个简单的流水线基本就是这些逻辑，可以理解为 CI/CD 的 hello world 。

顺其自然吧，生活不用如此严肃。不管怎么选，脑臀分离和屁股决定脑袋的标签你总要选一个的。

@dcoder 10 分钟还是太慢了。以我使用腾讯云 TKE 和阿里云 ACK 的经验，绝大部分时候，添加一个节点，5 分钟以内就可以完成了，包含实例创建启动加入集群。

homelab 场景的存储设计，个人倾向于优先考虑池化，其次是备份，最后是高可用。个人用户需要保障“硬盘故障不会导致数据丢失”的数据量一般不大，通过备份实现比通过类似 RAID 的高可用实现更合适，复杂度也更低。当然，需要研究各种软硬 RAID 方案的除外。

OP 对丈母娘家有一种俯视视角，江西、妹妹、彩礼、北京半套房、打工、国企，潜意识里的傲慢在日常沟通中很难隐藏，并能轻易的被别人感知。这会加剧日常沟通的对抗性。
小孩子打架，父母教育自己孩子的逻辑是没有核心利益冲突时，以教育孩子成长为主。成年人打架很多都是有核心利益冲突的，批评自己人没有意义。OP 不应该拿小孩子的逻辑套在成年人冲突上。
人活一辈子，会有大量的人生痕迹和生活习惯，无法更改或消除，摸索出和老年人共存的方式，被迫产生的关联也只能视为婚姻代价的一部分，做好预期管理，做好代价预算。

如果是为了控制台能查看日志并保存到文件持久化，可以简单使用 tee 命令。node server.js 2>&1 | tee app.log

家务事难断，从楼上各种各样的评论可以看出。
OP 描述中提到“老婆觉得老人明显不公平，还要装作很公平”，这个细节不应该忽略，OP 可以深挖一下。如果 OP 老婆是一个明事理的人，可能有以下的思考逻辑：
- 父母的钱给谁不给谁，公平不公平，跟我没有关系
- 但把分配方案拿出来说，拿出来讨论，那就是有明显的动机、预期、目的。大家心知肚明的赡养问题，明显和我有关系
- 我觉得分配方案不公平，但我明事理无所谓，毕竟不是我的钱，我管不着。但你不能按着我的头，让我认为它公平，并接受以它公平为基础的赡养逻辑
- 我赡养老人是因为我有道德，有亲情，有感情。这种逻辑下的赡养无所谓公平不公平，从自己本心出发。
- 父母把家产分配问题拿出来讨论，那就意味把赡养和家产分配挂钩。你要按这个逻辑出发，那我就要好好拉扯一下公平分配问题。

如果 OP 老婆是个明事理的人，很可能有以上思考逻辑。这个时候一定要明晰这是一个逻辑问题不是钱的问题，提钱无异于火上浇油。或者 OP 老婆本身就是在乎钱，但当她提出是逻辑问题时，就要按照逻辑问题分析。
问题本质是老人的认知和认识不足，不太能较好的处理家族内钱和感情互相纠缠的问题，对自己，对自己的儿子儿媳没有正确的认识。

家务事难断，大部分人都是路过，过过嘴瘾，吃吃瓜。OP 还是结合自己的情况，对自己真诚对家人真诚，认真处理问题为好。

从架构上讲，1 和 3 （如果是 hyper-v 的话）是一样的，都是 hypervisor+os+container 的方案，区别只是 hypervisor 选型问题。2 里面没有 hypervisor ，但折腾起来难免会有使用不同内核操作系统的需求，container 解决不了这个问题，还是需要一个 Type-2 的 hypervisor 。
所以自己折腾玩的话基本就 2 种架构：
1. baremetal+hypervisor+os+container
2. baremetal+os ，os 上并行跑 Type-2 的 hypervisor 和 container

第一种更稳定一些，折腾上层时不太会影响下层。另外还有一些 HCI 超融合基础架构的方案也可以折腾玩玩。

毕业后就进入一家公司，缺少对社会的基本认知，这个倒是实情。
且不说你一直强调狗屎运拆迁 300W 现金流，仅杭州有房无贷这一点，你怎么敢把自己定位在普通人偏下？让其他站友如何自处？只能吐槽你炫耀了。
人要不断完善自我认知，你一边强调自己不求上进，一边又厌烦当前安逸的环境，这种认知失调，对于人这种不安分的动物来说太常见了。人生旅途有太多这样吃着碗里看着锅里的场景了，35 岁的人应该能理解这更多是一种皮痒了的表现。
严肃的认识自己，到底希望安逸过一生还是希望更刺激充沛的人生体验。35 岁的人应该对眼皮浅、脑子一热的场景有一定的免疫力，应该尝试更长远和更有深度的思考问题。

@xinchao 我的烘干机放在通铺的阳台，使用时有些噪音，另外比较喜欢开窗通风，所以烘干机用了几次就吃灰了。迷瞪团购我主要买的实木家具，优惠力度和渠道信任度整体上比较合适。

2 年前买过几个大件家电的经验：
- 大家电一般都可以约定半年到一年的发货时间。建议尽早关注各个渠道价格，建立心理价位。没有建立心理价位的话，容易错过合适的下单时机。同时，关注各个渠道是否方便退单，适时锁单。因为都是半年到一年的发货时间，锁单退单都算正常操作。
- 大家电建议线下，或者 PDD 、咸鱼、团购群。JD 的售后服务在大家电品类优势不明显，但价格会高很多。首推线下渠道，信息源一般来自小区业主群，特别是新小区，采购量比较大，会有很多卖场销售特别渠道，优势是可以现场看再预定，正规渠道，有时叠加政府消费券会拿到很低的价格。其它线上渠道价格有优势，但信任度可能需要自行斟酌，一般都不会翻车，但也有被骗的案例。有的团购比如迷瞪，本身就是天猫京东，如果符合预期价位，可以提前锁单，后续有更合适的再退单也比较方便。
- 坐标杭州。烘干机吃灰中，如果没有新风系统，不建议购买。个人觉得烘干机主要有 2 个应用场景，一是应对梅雨天气，二是应对衣物绒毛带来的屋内浮尘。杭州的梅雨天气个人觉得不严重，持续时间也不长。全屋没有安装新风的话就要经常开窗通风，这样屋内浮尘的主要来源就不是衣物绒毛了，烘干机过滤绒毛也就可有可无了。另外，烘干机非常吵，使用时最好有一个可以隔音的环境。

@A01514035 感谢分享。
- 终端使用公共 dns 但仍命中了透明网关的 dns 分流，应该是透明网关劫持了 udp 53 流量，透明网关一般会默认配置。
- macvlan 这个解决方法有点印象，应该就是这样的。使用 docker 本意是尽量降低对宿主机的操作和依赖，有点抗拒这个解决方法。

内网 dns 仍是一个问题，主要有内部 dns 解析重写、终端 dns 请求管控分析、基于域名的分流这 3 个需求，需要探索一个合理的网络拓扑。

最近也在折腾家庭网络，更倾向透明网关的叫法。也用过 macvlan 网络跑 clash 容器，目前暂时用虚拟机跑 dae 做透明网关。折腾起来还是有不少细节：
- 透明网关多了一跳，导致去程和回程路由不一致。有些应用可能会有奇怪问题。
- 内网有自建 dns 服务，希望管控和分析所有终端的 dns 请求。终端的 dns 指向透明网关就无法识别分析了，不指向透明网关就失去了 dns 分流作用，只能基于 IP 分流。另外，为了对抗 dns 污染和泄露，dns 服务器的上游也需要借助透明网关。拓扑上似乎很难梳理通顺。
- 透明网关容器使用 macvlan ，所在宿主机却无法联通透明网关。似乎是 docker iptables 相关的一些配置问题。即如果仅用一台 docker 主机跑所有服务，包括透明网关，宿主机上的其他容器无法简单的使用该透明网关。所以使用独立虚拟机跑透明网关服务也是一个选择，有可能的话，还是希望能把 dns 管控分析和透明网关打包成一个镜像，一键部署。
- PT 下载问题，透明网关场景需要对 PT 下载有一些调整和适配。
- 其他拓扑尝试，有看到把透明网关放到主路由上游的拓扑，即主路由多 wan 上联的逻辑。似乎也可以试试看。

2 年前选型的时候主要关注的是无桶、净水即热分离结构。这种产品迭代挺快的，如果现在选净水即热一体结构，除了常规参数、耗材成本之外，最好留意一下首杯直饮、零陈水相关说明。

个人觉得家用场景很少会有组 RAID 的需求。RAID 的核心价值在于不间断服务，类似 UPS 停电了还能撑一会，RAID 保障硬盘坏了还能撑一会。这种撑一会非要说是一种备份就太勉强了。商用场景一分钟几百万上下，撑一会很有价值。家用场景一般不存在这样的价值，核心需求一般是备份。服务可以断可以毁，但数据最好不要丢。