<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Reliability on All about Raspberry Pi</title><link>https://hugozhu.site/tags/reliability/</link><description>Recent content in Reliability on All about Raspberry Pi</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 24 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://hugozhu.site/tags/reliability/index.xml" rel="self" type="application/rss+xml"/><item><title>健康检查全绿，数字员工失联了 16 分钟：生产交付的几个关键实践</title><link>https://hugozhu.site/post/2026/365-digital-employee-harness-production-lessons/</link><pubDate>Mon, 24 Aug 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/365-digital-employee-harness-production-lessons/</guid><description>&lt;p&gt;2026 年 8 月 8 日下午，我们的数字员工失联了 16 分钟。监控这边，它一切正常。&lt;/p&gt;
&lt;p&gt;说「失联」其实不准确——从所有监控指标的视角看，它一直活得好好的：进程存活检查正常，HTTP /session 探测返回 200，健康检查每 5 分钟跑一次，次次报「健康」。唯一的异常是：群里任何人 @ 它，它都不回。最早的「告警」是一个人在钉钉里发现不对劲——这比我们任何一条监控都快。&lt;/p&gt;
&lt;p&gt;16 分钟不长，但足够让人意识到一件事：我们精心搭建的监控体系，监控的根本不是「数字员工在工作」，而是「装着数字员工的那个容器还在」。&lt;/p&gt;
&lt;p&gt;这篇文章讲的，就是从这类事故里长出来的几个生产级实践。它们已经沉淀进数字员工的 harness 模板——&lt;a href="https://hugozhu.site/post/2026/299-dingtalk-opencode-tag-scaffold-delivery-paradigm/"&gt;三步上线一个数字员工&lt;/a&gt; 里讲过这个脚手架是什么、怎么三步上线；模板本身也在持续迭代，从内部生产版本一路提炼成开源的 &lt;a href="https://github.com/hugozhu/dingtalk-opencode-tag"&gt;dingtalk-opencode-tag&lt;/a&gt;。这篇是它的续篇：&lt;strong&gt;上线只是开始，生产环境会用它自己的方式告诉你，「能跑」和「生产级」之间还隔着多少坑。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href="https://hugozhu.site/img/2026/digital-employee-harness-production-lessons.png"&gt;&lt;img src="https://hugozhu.site/img/2026/digital-employee-harness-production-lessons-thumb.jpg" alt="When All Health Checks Are Green but the Brain Is Gone"&gt;&lt;/a&gt;&lt;/p&gt;</description></item></channel></rss>