<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>站点可靠性工程 on 办公AI智能小助手</title>
    <link>https://blog.qife122.com/tags/%E7%AB%99%E7%82%B9%E5%8F%AF%E9%9D%A0%E6%80%A7%E5%B7%A5%E7%A8%8B/</link>
    <description>Recent content in 站点可靠性工程 on 办公AI智能小助手</description>
    <generator>Hugo</generator>
    <language>zh-cn</language>
    <copyright>qife</copyright>
    <lastBuildDate>Tue, 30 Dec 2025 08:12:49 +0800</lastBuildDate>
    <atom:link href="https://blog.qife122.com/tags/%E7%AB%99%E7%82%B9%E5%8F%AF%E9%9D%A0%E6%80%A7%E5%B7%A5%E7%A8%8B/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>追寻根本原因是条歧路：与David Blank-Edelman探讨软件架构与可靠性工程</title>
      <link>https://blog.qife122.com/p/%E8%BF%BD%E5%AF%BB%E6%A0%B9%E6%9C%AC%E5%8E%9F%E5%9B%A0%E6%98%AF%E6%9D%A1%E6%AD%A7%E8%B7%AF%E4%B8%8Edavid-blank-edelman%E6%8E%A2%E8%AE%A8%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E4%B8%8E%E5%8F%AF%E9%9D%A0%E6%80%A7%E5%B7%A5%E7%A8%8B/</link>
      <pubDate>Tue, 30 Dec 2025 08:12:49 +0800</pubDate>
      <guid>https://blog.qife122.com/p/%E8%BF%BD%E5%AF%BB%E6%A0%B9%E6%9C%AC%E5%8E%9F%E5%9B%A0%E6%98%AF%E6%9D%A1%E6%AD%A7%E8%B7%AF%E4%B8%8Edavid-blank-edelman%E6%8E%A2%E8%AE%A8%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E4%B8%8E%E5%8F%AF%E9%9D%A0%E6%80%A7%E5%B7%A5%E7%A8%8B/</guid>
      <description>&lt;h4 id=&#34;关键要点&#34;&gt;关键要点&lt;/h4&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;可靠性是架构的一种涌现属性，可以包含对客户重要的任何属性，如可用性、延迟、吞吐量、持久性或信息新鲜度。因此，它超越了单个用例。&lt;/li&gt;&#xA;&lt;li&gt;不存在所谓的事故单一根本原因。失败有多种原因，其中一些是社会技术性的。有时为了理解事故，必须了解事故发生前某物是如何工作的。&lt;/li&gt;&#xA;&lt;li&gt;架构师和软件可靠性工程师应建立基于对系统实际工作方式好奇心的协作关系。有关失败的知识应与架构师和设计师共享，这样他们不仅能了解系统在实践中的运行方式，还能利用这些信息在未来设计出更好的系统。&lt;/li&gt;&#xA;&lt;li&gt;事后审查应首先关注“什么”和“如何”，然后再问“为什么”。过早关注“为什么”通常会遗漏重要信息。&lt;/li&gt;&#xA;&lt;li&gt;复杂系统几乎总是处于失败的边缘。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h4 id=&#34;文稿&#34;&gt;文稿&lt;/h4&gt;&#xA;&lt;p&gt;&lt;strong&gt;Michael Stiefel&lt;/strong&gt;：欢迎来到架构师播客，在这里我们讨论成为架构师意味着什么，以及架构师实际上如何工作。今天，我们将讨论一些对架构师非常重要但通常没有明确讨论的话题。我们已经在这个播客上多次谈到了可靠性和为失败而设计，但我们还没有讨论过如何让我们的系统设计更加健壮，而不仅仅是在失败后进行修复。&lt;/p&gt;</description>
    </item>
    <item>
      <title>负责任AI快速部署实践指南</title>
      <link>https://blog.qife122.com/p/%E8%B4%9F%E8%B4%A3%E4%BB%BBai%E5%BF%AB%E9%80%9F%E9%83%A8%E7%BD%B2%E5%AE%9E%E8%B7%B5%E6%8C%87%E5%8D%97/</link>
      <pubDate>Thu, 09 Oct 2025 06:05:14 +0800</pubDate>
      <guid>https://blog.qife122.com/p/%E8%B4%9F%E8%B4%A3%E4%BB%BBai%E5%BF%AB%E9%80%9F%E9%83%A8%E7%BD%B2%E5%AE%9E%E8%B7%B5%E6%8C%87%E5%8D%97/</guid>
      <description>&lt;h1 id=&#34;负责任ai快速部署实践指南&#34;&gt;负责任AI快速部署实践指南&lt;/h1&gt;&#xA;&lt;p&gt;在软件工程中，发布日很少因为缺少单元测试而失败；但在机器学习领域，情况并非如此。远离训练数据的输入、对抗性提示、偏离人类目标的代理，或者声称与其实际不符的上游工件，都可能导致发布失败。问题不在于&amp;quot;能否预防所有故障&amp;quot;，而在于&amp;quot;能否限制故障范围、快速检测并实现可预测的恢复&amp;quot;。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
