码厩开发者笔记

#1038 DNS HINFO 记录

天涯社区将回归！创始人：明天，全面恢复业务！此前被申请破产审查，官网仍“无法访问”
说是 5/1 前回归，我刚查了一下，天涯现在还打不开。搜索一下域名解析的时候，发现了一个 HINFO 记录，这我还是第一次看到。

#1037 腾讯云事故学习

1. 对客户要讲诚信，除了问题要坦诚，要实事求是
2. 故障报告编写流程与规范
3. 服务的状态页
4. 每一件事都需要有 Owner

#1036 关于工作的反思

最近这几个月的工作越来越忙了。感觉怎么忙，工作也做不完，一堆的事情，等着连放假在家都被工作压得不能安心休息一下。

举个简单的小例子：我以前几乎每天都要起来走七八次，上厕所、喝水、或者就在公司走动一下。然后现在每天喝水的次数估计也就一到两次，几乎没有在公司上过厕所了。
这不是一个很好的工作状态，甚至可以说很差劲。

经过反思，我总结了以下几点：

一、事情的优先级没有分清楚。自己很累，做了很多事情，但是有些重要的事情最后没有完成。
重要的工作排在前面做，安排的工作应该是努努力能够完成的。

二、不会拒绝。我应该将一部分临时插入的工作，拒绝掉，或者往后推，让位给更高优先级的工作。
这个其实跟优先级没有排清楚也有很大的关系。

三、工作没有往下分派，把压力传导出去。
我感觉我们组就我最忙。因为我总希望安排下去的工作一定能保证完成，但是这不是能够能够让大家发挥出最大潜力的方式。
作为中层管理人员，应该留有一点时间思考，思考业务，思考团队发展，思考如何改进工作，思考如何提升效率。不能一直盯着脚下，要抽空抬头看看路。

四、这个沟通做的不到位。之前无法完成，之前一定要和相关的同事有深入的沟通。
我现在每次都是答应下来，然后一直等工作完成再去报告。
有些时候无法完成排在手上也没有及时反馈出去。

1. 工作在传到我这里的时候，应该先和需求方确认清楚，需要完成的程度。
2. 我需要自己判断一个优先级，将我自己这边的安排告诉需求方。如果他认为这件事情真的很重要，那我也应该和他或者其他相关人员去沟通，至少应该做到有所取舍。
3. 工作在执行的过程中，也需要有适当的反馈和沟通。凡事有交代，件件有着落，事事有回音。

#1035 政策关注

#1034 西游记重大事件与孙悟空年龄

原著中最明确的年龄锚点是孙悟空大闹地府时，生死簿记载“天产石猴，该寿三百四十二岁”，因此此时为342岁。此后被如来镇压五行山，原著称“已五百馀年”，故获救时约842岁。取经完成时，唐僧向唐太宗说明“一十四遍寒暑”，因此孙悟空取经完成约856岁。出生、成为美猴王、出海求仙及拜师等早期年龄，原著没有明确记载，表中数值属于结合情节和已知年龄节点的推算，并非原著明示。

#1033 牛魔王、铁扇公主、玉面狐狸的关系

如果值看过电视剧版本西游记，可能会认为牛魔王是一妻一妾，然后宠妾灭妻，抛妻弃子，长年和玉面狐狸生活在一起。
可是看了原著之后就会发现事情没有这么简单。

牛魔王是七大圣之首，也是孙悟空结拜的大哥。西游记中牛魔王每次出场都是大哥大作派。
铁扇公主，又名罗刹女。她也不是什么普通妖怪，而是修成地仙的人物，住在翠云山芭蕉洞，手里有先天灵宝芭蕉扇。火焰山方圆八百里，每逢十年，当地百姓都会准备四猪四羊、花红表里，前来求她灭火，因此她根本不缺供奉。
两人育有一子红孩儿，号圣婴大王，在火焰山修行三百年炼成三昧真火，后来占据号山枯松涧火云洞，自成一方势力，山神土地都被当成仆役。

牛魔王有这么一个温馨的小家庭，为什么勾搭上玉面狐狸呢？其实不是牛魔王见色起意，而是玉面狐狸主动招赘牛魔王。
中国古代就有一种说法，叫做吃绝户，玉面狐狸就面临这种情况。玉面狐狸是万岁狐王的独女。狐王死后，留下百万家私，却没有儿子继承，也没人能够保护这份家产。
玉面狐狸需要靠山，牛魔王则看中了百万家私（图他家私，招我为夫），两人一拍即合、各取所需。
我倒是好奇，牛魔王也不缺钱，为什么要图玉面狐狸的家产，再结合他导出结交各路妖王的 “不安分” 作派，他到底是要干什么？

这事铁扇公主完全知情，甚至默许，坦然接受玉面狐狸定期送来的金银珠翠、柴米绸缎。这在原著玉面狐狸台词中说的很清楚。
铁扇公主拿钱就相当于承认玉面狐狸的外室身份。玉面狐狸也就是买个心安，不用担心主母闹事，安安稳稳地过日子。
问题是，铁扇公主又是为什么要这样做？可能是反正牛魔王的决定无法改变，自己没想离婚，也不像大吵大闹失了体面，那这个送上来的孝敬不拿白不拿。现实主义。
三个人维持了一种平衡：正妻守名分，外室得陪伴，牛魔王两头安稳，三方各得其所。
后来牛魔王长期住在积雷山摩云洞。入赘嘛，这个规矩牛魔王还是讲的。

只是出了唐僧师徒路过火焰山这事，拉拉扯扯，最后搞得：

1. 牛魔王被佛道两家联合围剿，最后走投无路的牛魔王最终被众神牵去交给佛门发落。
2. 铁扇公主交出芭蕉扇，后面不知道怎样了，书里没有写。
3. 玉面狐狸被猪八戒一耙打死。

在此之前红孩儿已经跟着观音走了，后面占领落胎泉的牛魔王弟弟如意真仙被打跑。从妖精的角度看，算是团灭。一个原本势力庞大的妖怪家族，也就此分崩离析。

#1032 Golang sync/atomic

在 Go 的并发程序中，多个 goroutine 同时读写共享变量是非常常见的场景。例如统计请求数量、维护连接数、实现限流器、更新状态标志等。如果只是简单地执行 counter++，即使变量本身是一个 int64，也不能保证并发安全。

Go 标准库提供了 sync/atomic，用于执行原子读、写、加减、交换和 CAS（Compare-And-Swap）操作。与 sync.Mutex 相比，atomic 更适合保护单个简单变量，在高并发、低临界区的场景下可以减少锁竞争。

#1031 中韩关于苏岩礁的争议

中韩之间并不存在类似中日钓鱼岛那样明确的岛屿主权争端，双方真正的核心矛盾，是黄海、东海部分海域的专属经济区（EEZ）和大陆架划界问题。由于两国海岸距离较近，200海里专属经济区存在重叠，因此双方长期没有确定最终海上边界。

苏岩礁就是这一矛盾最具代表性的焦点。它是一处常年位于水下的暗礁，最浅处仍在海面以下4.6米。按照《联合国海洋法公约》，它本身不能产生领海或专属经济区。因此，所谓“苏岩礁归谁”，实际上并不是传统意义上的领土主权问题，而是它周边海域究竟应该划归哪一方管辖。

围绕这一海域，中韩双方都在采取行动。韩国2003年建成离於岛海洋科学研究基地，长期开展海洋、气象和渔业监测，并维持相关海域的持续存在。中国则一直反对韩国单方面强化管辖性设施，近年来明显增加海警巡航、海洋调查和设施建设。2024年以来，中国在黄海/东海重叠海域建设大型海上设施，引发韩国抗议；2025年韩国调查船试图接近其中一处设施时，还曾被中国海警阻拦。双方的海上存在竞争明显升温。

苏岩礁也不存在实控问题，韩国依然拥有长期运行的海洋科学基地，中国则正在加强周边海域的执法和存在。目前更准确的描述，是双方都在通过设施、巡航、调查和外交谈判扩大自身存在，为未来海洋划界争取筹码。

因此，苏岩礁并不是一个孤立的“岛屿争端”，而是中韩整个海洋划界博弈的一个缩影。未来真正决定双方利益格局的，不是谁“占住了一块礁石”，而是黄海、东海重叠海域最终如何划界，以及由此产生的渔业、资源、航行和执法权益如何分配。

预测：最终形成长期搁置争议、有限合作与持续博弈并存的状态。

#1030 一封邮件的“500 英里魔咒”：一个 Bug 如何暴露网络底层规律

2002 年，美国北卡罗来纳州一所大学发生了一件看似荒诞的网络故障：统计系的邮件服务器，只能向 500 英里以内的服务器正常发邮件。

统计系主任最初发现，邮件发送似乎存在一道神秘的“距离边界”：里士满、亚特兰大、华盛顿等地可以正常发送，但孟菲斯、波士顿、底特律等更远地区却几乎全部失败。统计系甚至请地理学家绘制地图，发现故障范围竟然真的接近一个以办公室为圆心、半径约 500 英里的圆。

管理员 Trey Harris 随后发现，真正决定邮件能否发送的并不是收件人住在哪里，而是对方邮件服务器在哪里。一位朋友虽然住在北卡，但邮件服务器部署在西雅图，邮件同样无法送达。

最终，发现问题出在一次系统升级：
顾问升级 SunOS 时，意外将新版 Sendmail 降级成了旧版本，却继续使用新版配置文件。
旧版程序无法识别部分新配置项，便悄悄忽略了它们，导致 SMTP 连接超时时间异常变成了接近 3 毫秒。

3 毫秒究竟有多短？TCP 建立连接需要经过网络传输，而数据传输速度受光速和网络设备延迟限制。距离较近的服务器，TCP 握手还能勉强在超时前完成；距离更远时，程序已经主动放弃连接。于是，一个普通的配置兼容性问题，最终表现成了仿佛系统“认识地理距离”的 500 英里边界。

这个故事也成为网络排障的经典案例：系统表面的异常现象，背后往往不是玄学，而是软件配置、网络协议和物理规律共同作用的结果。
给开发者的另一个教训是：程序异常之后，系统保持静默，按照错误的规则运行，比报错糟糕得多。

#1029 机器重启之后没有 supervisor 服务了

一台运行了好久的 RockyLinux 服务器做了一下重启，重启之后用 supervisorctl 启动服务的时候发现 supervisor 服务没有启动。
然后 systemctl 启动 supervisor 的时候有发现没有这个服务。

$ which supervisord supervisorctl
/usr/local/bin/supervisord
/usr/local/bin/supervisorctl
# 如果是 yum/apt 安装的，二进制程序路径应该是 /usr/bin/supervisord。

$ rpm -qf /usr/local/bin/supervisord
file /usr/local/bin/supervisord is not owned by any package
# Debian/Ubuntu 上对应的命令是 dpkg -S /usr/local/bin/supervisord

$ ls -l /etc/supervisor/supervisord.conf
-rw-r--r-- 1 root root 10648 Mar 12 18:59 /etc/supervisor/supervisord.conf
$ ls -l /etc/supervisord.conf
ls: cannot access '/etc/supervisord.conf': No such file or directory

$ locate -r "/supervisor$"
/etc/supervisor
/opt/woodycoder/deploy/supervisor
/usr/local/lib/python3.12/site-packages/supervisor

$ pip show supervisor
Name: supervisor
Version: 4.3.0
Summary: A system for controlling process state under UNIX
Home-page: http://supervisord.org/
Author: Chris McDonough
Author-email: chrism@plope.com
License: BSD-derived (http://www.repoze.org/LICENSE.txt)
Location: /usr/local/lib/python3.12/site-packages
Requires: 
Required-by: 

原来之前使用 pip install supervisor 安装的。pip 安装的 Supervisor 不会自动注册 systemd 服务，所以机器重启后 supervisord 不会自动启动。
可能之前安装的时候是手动启动了 supervisor：supervisord -c /etc/supervisor/supervisord.conf。

只是没有 Unit 文件就好办了，创建一个 Unit 文件就行：

sudo tee /etc/systemd/system/supervisord.service >/dev/null <<'EOF'
[Unit]
Description=Supervisor process control system
Documentation=http://supervisord.org
After=network.target

[Service]
Type=forking
PIDFile=/var/run/supervisord.pid

ExecStart=/usr/local/bin/supervisord -c /etc/supervisor/supervisord.conf
ExecStop=/usr/local/bin/supervisorctl -c /etc/supervisor/supervisord.conf shutdown
ExecReload=/usr/local/bin/supervisorctl -c /etc/supervisor/supervisord.conf reload

Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now supervisord

sudo systemctl status supervisord

# 查看 Supervisor 管理的进程
sudo supervisorctl -c /etc/supervisor/supervisord.conf status