我用 800 块钱买了台办公用的 Mini PC

最近，我花了 800 块钱买了一台 Mini PC，用来办公。刚好这四个月在公司领到的每月 200 块钱电脑补贴，全都花光了。算是“取之于公司，用之于公司”吧，哈哈。

这次的购买经历不仅让我更深刻地体会到“消费降级”的现实，还让我感受到了科技进步所带来的性价比红利。在预算有限的情况下，这台 Mini PC 不仅完美满足了我的日常需求，还让我对它的未来用途充满期待。接下来，我详细聊聊这次购买的选择过程、使用体验以及相关感悟。

配置与硬件概览

这台 Mini PC 的硬件配置如下：

• CPU: Intel 第 12 代 N100
  • 4 核心
  • 缺省运行在 0.8 GHz 的低功耗模式，但睿频最高可达 3.4 GHz
• 内存: DDR4，主频未知
• 存储: M.2 2280 PCIe SSD，容量 512 GB
• 网络: 双频 WiFi（2.4G+5G）+ 蓝牙
• 其他物理接口:
  • USB3.2 × 2
  • USB2.0 × 2
  • 耳机接口 × 1
  • 千兆以太网卡 × 1
  • HDMI × 1
  • DP（DisplayPort） × 1

此外，它的体积和重量也非常小巧：

• 尺寸：124.5 x 112 x 50.8 mm
• 重量：约 400 克

整机可以轻松放在桌面的一角，或者显示器下面的空隙。

系统选择与使用体验

拿到手后，我给这台 Mini PC 装了 Debian testing 系统，当前版本是 Debian 13，字母代号 trixie，桌面环境选择了轻量的 XFCE。安装过程非常顺利，硬件驱动几乎开箱即用，尤其是 WiFi 和蓝牙的兼容性让我非常满意。

但是装完以后进入桌面发现 wifi 用不了。可能是安装时没选相关 non-free 的包的问题吧。但是经过简单的排错、下载了一个 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/iwlwifi-so-a0-jf-b0-77.ucode 放到 /usr/lib/firmware/ 目录下以后就好了。

下面是一张我使用 neofetch 工具查看系统和硬件信息的截图：

从图中可以清晰看到系统的核心信息：

• 系统: Debian GNU/Linux trixie/sid x86_64
• 内核: 6.11.7-amd64
• 运行时间: 已开机 7 天 19 小时
• CPU: Intel N100 (4 核 @ 3.4 GHz)
• GPU: Intel Alder Lake-N UHD Graphics
• 内存使用: 11.88 GB / 15.70 GB

选择 Mini PC 的理由

Mac Mini M2 的诱惑

有趣的是，这次购买正好碰上了 Mac Mini M4 发售。因为各种折扣补贴，当时这台设备的价格非常美好，只要 3000 出头。有同事也推荐我直接买 Mac Mini，毕竟性能和生态都很优秀，而且这好像还是第一次改了模具，整个机型变得比上一版小巧了很多很多。

我确实犹豫了一下，但仔细思考后，还是选择了这台便宜了两千多块的 Mini PC。原因很简单：

1. 预算有限：800 元 vs 3000 元，差价不是一星半点。即使 Mac Mini 性能更好，但对我来说这些性能是溢出的，完全用不到。
2. 实际需求：我的工作主要依赖 SSH 和 浏览器，对性能的要求并不高。而这台 Mini PC 在省钱的同时，已经能很好地满足这些需求。
3. 可玩性更高：用 Debian 和 XFCE 环境，比起 macOS，更符合我的习惯，也更自由可控。

好吧，我摊牌了，其实原因就是第一个，其他两个都是搭头。

所以，尽管 Mac Mini M4 也是性价比很高的设备，但对比我的实际需求，这台 800 元的 Mini PC 显然是更务实的选择。

办公和远程工作的便利性

目前，这台 Mini PC 是我主要的办公设备，而且我设置了它每天不关机，一直保持在线状态。在家时，如果需要处理工作，只要通过远程工具直接登录它，就可以快速进入工作状态，非常方便。

同时，得益于低功耗特性，而且的确负载也轻，它 24 小时开机几乎感觉不到风扇的噪音。这样的小型设备，不仅可以满足日常办公需求，还能成为远程协作的可靠节点。

低功耗与未来的潜力

这台 Mini PC 的另一个显著优势是功耗极低。Intel N100 平台在缺省状态下只跑 0.8 GHz，风扇几乎听不到声音。即使长时间开机运行，耗电和发热都非常可控。偶尔需要睿频到 3.4 GHz 时，性能释放也完全够用。

得益于低功耗、小尺寸的特点，这台电脑即使以后不再用作办公机，也有很多未来用途。我已经有以下几个计划：

• NAS：搭建一个家庭文件存储和同步服务，继续配合 Syncthing 使用。
• Docker 容器：托管一些轻量级的服务，比如媒体服务器、工具脚本等。
• 远程访问节点：利用 ZeroTier 和 Tailscale，随时随地访问家中设备。

对比起高功耗的传统台式机，这样的小型设备更适合用作家庭服务器，长期运行也不用担心电费问题。

关于消费降级的感慨

老实说，我选择这台 Mini PC，主要还是因为个人经济状况的限制。最近手头确实有点紧，所以只能选择性价比最高的方案。以前可能会考虑更高端的设备，比如 Mac Mini，但现在不得不降低预算，选择更务实的解决方案。

不过，虽然是消费降级，但我并没有感到体验上的妥协。反而在科技发展的红利下，我用 800 块就买到了一台能够胜任办公、还能支持未来扩展的 Mini PC。放在几年前，这样的设备简直是想都不敢想。

总的来说，这次的购买让我非常满意。当然，为了避免“带货”嫌疑，就不提具体品牌和型号以及购买的平台了。不过，如果你也在寻找一台高性价比的办公电脑，这种 Mini PC 确实值得考虑。

在现代网络架构中，VPN（虚拟专用网络）技术的应用越来越广泛。本文将探讨在我司 IDC 中，使用 WireGuard 实现的 VPN 连接中遇到的一个有趣现象。

场景描述

我司在 IDC 中有一台运行 Debian 的服务器 L1，有两个上联口：E-a 和 E-b，分别连接到运营商 I-a 和 I-b。IP 地址为 ip-a 和 ip-b。L1 上的策略路由很简单：

• 源地址为 ip-a 的数据包通过 E-a 口走 I-a
• 其他数据包则通过默认出口 E-b 走 I-b（源地址自然是 ip-b）

此外，L1 还通过网口 E-c 连接内网，IP 地址为 ip-c。L1 上运行 WirGuard，绑定 0.0.0.0 的 udp 端口 12345。

在办公室，我司还有一台运行 Debian 的机器 L2。由于 L2 位于内网中，没有公网 IP。L2 上也运行着 WireGuard，绑定在 0.0.0.0 的（udp）端口 12345。同时，我在办公室的路由器上做了端口映射，将 udp 12345 端口映射到 L2（虽然这完全没什么用）。

L2 的 WireGuard 配置中，peer 的 endpoint 指定为 L1 的 IP 地址 ip-a。由于 L2 没有公网地址且出口地址不固定，因此在 L1 的 WireGuard 配置中并没有指定 L2 的 IP 地址。就这样，L1 和 L2 上的 WireGuard 的连接顺利建立，一切都如预期般正常运行。

异常现象

其实，L2 上还运行着一个 SmokePing，监测着 ip-a、ip-b 和 ip-c，当然也还有其他，不过那些跟这里没啥关系，也就不提了。

某天我在 Smokeping 监控中发现，ping ip-c 的（时间）值明显高于 ping ip-a 的值，且与 ping ip-b 的相近。这一现象让我感到困惑，因为到 ip-c 的数据包走的逻辑链路（通过 WireGuard 隧道）实际上应该与到 ip-a 的物理链路完全相同，所以 ping ip-c 的数据应该跟 ping ip-a 的几乎一样才对。

我的第一反应是，可能是办公室的网络接入商或 I-a 对 UDP 包进行了 QoS 限速，因为 WireGuard 使用的是 UDP 协议。经过与客服的沟通，确认并没有针对 UDP 包的限速策略。

接着，我使用 iperf3 在 L1 和 L2 之间进行了测速，发现走 UDP 和走 TCP 的测试结果数据引并没有显著差别，这表明问题并不在于 UDP 包有被干扰。随后，我在 L2 上使用 tcpdump 监听 WireGuard 的数据包，结果让我大吃一惊：所有的数据包都是与 ip-b 的端口 12345 进行交互，而不是预期中的 ip-a！这也解释了为什么 ping ip-c 的延迟与 ping ip-b 的延迟相近，因为数据实际上是通过到 ip-b 的物理链路进行的。

深入分析

面对这一现象，我感到百思不得其解。于是，我记录下当前的状况，并重启了 L2 上的 WireGuard，结果一切又都恢复正常：WireGuard 的数据交互对端 IP 变回了 ip-a，ping ip-c 的延迟也降到了与 ping ip-a 相同的水平。

进一步查阅资料后，我发现 WireGuard 具有 endpoint 自动更新的机制。虽然 L1 上没有 L2 端的 endpoint 数据，但 L2 上有 L1 的数据。当 L2 第一次连接 L1 时，L1 会记录下 L2 的 endpoint 数据。如果 L2 使用了不同的 IP 地址连接 L1，L1 会更新 L2 的 endpoint IP 地址。反之亦然。这意味着，当 L1 从 E-b 口以 ip-b 作为源地址连接 L2 时，L2 也会更新 L1 的 endpoint IP 地址。

最终，我意识到问题的根源在于 L1 突然使用源 IP 为 ip-b 从 E-b 口发送 WireGuard 数据包给 L2。期间，我发现办公网的网络曾经闪断过几分钟。真相逐渐浮出水面：当 L2 的上联公网链路断开时，L1 由于长时间未收到来自 L2 的 WireGuard 数据包，可能出于某种原因主动向 L2 发送 WireGuard 包，查找 L2 的 endpoint IP 和端口数据。此时，由于源地址未定，数据包直接通过 E-b 口发送，源地址被设为 ip-b。这些数据包持续发送到 L2，直到 L2 的上联网络恢复。L2 收到来自 ip-b 的 L1 的 WireGuard 数据包后，触发了更新 L1 的 endpoint 数据，从而开始与 L1 的 ip-b 进行 WireGuard 数据交互。

结论

通过这一系列的分析，整个逻辑变得自洽了。这一现象不仅揭示了 WireGuard 的灵活性和自动化特性，也提醒我们在设计网络架构时，需考虑到各种可能的网络状态变化。希望这篇文章能为您在使用 WireGuard 或其他 VPN 技术时提供一些启示。

背景介绍

最近要做个 log server，把所有服务器的系统日志都收上来。我现在的服务器，操作系统有两种：Amazon Linux 2023 和 Ubuntu，但其实 Ubuntu 又有 22.04 和 24.04 两种，所以，其实是一共有三种操作系统。

好在这三种系统，其缺省跑的日志应用，Amazon Linux 2023 是 systemd-journald，而 Ubuntu(22.04 和 24.04) 都是既跑有 systemd-journald，又跑的有 rsyslogd。这两种日志应用，都是支持集中的日志服务器的，或者很容易支持。但是为什么不就用一套 rsyslogd 的日志服务器呢？毕竟大家都支持 rsyslogd 的。主要是因为 systemd-journald 相对于 rsyslogd 是很新的东西，所以这里也拿出来练练手。

简介

要把 Python 项目部署到 AWS 的 Lambda function，AWS 官方提供了两种方法：Chalice 和 SAM(AWS Serverless Application Model)，当然，其实比较常用的还有第三方的 serverless。

简介

这是之前有一家公司招 SRE，我投了简历，然后被给了份题让先做一下，于是便有了这篇“水”文。

当然，最终我并没有拿到这个 offer，最早是说一周内安排面试的，后来又说是这个岗位暂停了。

简介

这是之前有一家海外公司招 DevOps 工程师，我投了简历，期望薪资写了薪资范围的最下限，然后被给了份题让先做一下，于是便有了这篇“水”文。

当然，最终我并没有拿到这个 offer，甚至连下一轮见 CTO 的机会都没有。（关于这个，我其实心里还是有一点小小的不服气的。）

起因

在搭建新环境时，我们选择了 OpenTofu——这是在 Terraform 更改了 license 之后从 Terraform 代码库分支并且开放源码的工具——用于构建VPC、RDS、Redis等基础设施。

但当基础设施就位、开始部署应用程序时，问题出现了。每次部署都不成功，查看日志说是 JDBC 相关错误，DB Proxy 的日志中充斥着诸多 “internal error”，却若隐若现关于具体错误原因的描述。尝试直接通过 MySQL 客户端连接 DB Proxy 时，大多数命令执行都引发错误（help 命令除外）提示：

ERROR 1105 (HY000): Unknown error

错误截图参见：

背景

项目有一些非常重要的后台应用是跑在 AWS 的 lambda 上的，老板和产品非常关注这些应用的执行情况，一旦出错，都会是很严重的故障。

方案变迁

前面做过一些基础设施级别的监控报警，如：监控 AWS 的 RDS 并通过企业微信来报警，那个完全是利用基础设施自动打到 CloudWatch 的基础的 metrics 来做的。

于是，我这里下意识的就想利用现有的 CloudWatch 里现成的 Metrics 来做这个事情，于是我就弄了三个（种）监控：

缘起

本来这台 HP Chromebook 11A G6 EE( 加了一张 128G 的 TF 卡 )，我安装好了 Arch Linux(Xfce)，都弄好了的，但最近在知乎上老被安利说装 Debian 的 testing 版，于是我又开始折腾，把 Debian 13 testing(trixie) 安装到这台 Chromebook 上。

安装时，使用 lvm 分区不成功，系统报错：

partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1: cannot open shared object file: no such file or directory

现在想想可能还有其他办法，比如想办法把这个需要的包注入进去，但当时选择了先用 ext4 分区安装系统自带的 16G 的卡里，装完以后再想办法转成 lvm 并把 TF 卡的空间加进来。

引言

监控在云资源管理中占据了核心地位，它可以帮助我们实时追踪资源状态，从而快速发现并处理潜在的问题。本文将介绍如何利用 AWS CloudWatch 监控云数据库服务RDS，并通过企业微信发送报警通知，以达到高效运维的目的。