feat(sreweekly): 补入 431 篇中文译文与 534 期 html，新增翻译队列脚本并更新 manifest

2026-09-15 21:13:34 +08:00
parent 529b2677e7
commit 836fa3b04d
1205 changed files with 16204 additions and 1 deletions
--- a/.DS_Store
+++ b/.DS_Store
--- a/sreweekly/analyze_translate.py
+++ b/sreweekly/analyze_translate.py
@@ -0,0 +1,56 @@
+import os, re, statistics, sys, io
+sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8', errors='replace')
+root = "/Users/weishen/Workspace/nexus/sreweekly/markdown"
+files = []
+for dp, dn, fn in os.walk(root):
+    for f in fn:
+        if f.endswith(".md"):
+            files.append(os.path.join(dp, f))
+print("TOTAL_FILES", len(files))
+
+has_body = no_body = empty_body = 0
+body_words = body_chars = 0
+existing_zh = 0
+short_bodies = 0
+per_dir = {}
+sizes = []
+for p in files:
+    base = os.path.basename(p)
+    if re.search(r"-zh\.md$|\.zh\.md$|zh-CN\.md$", base):
+        existing_zh += 1
+        continue
+    try:
+        txt = open(p, encoding="utf-8").read()
+    except Exception as e:
+        continue
+    m = re.search(r"##\s*正文\s*\n(.*)", txt, re.S)
+    if not m:
+        no_body += 1
+        continue
+    body = m.group(1).strip()
+    if len(body) < 50:
+        empty_body += 1
+        continue
+    words = len(re.findall(r"\S+", body))
+    has_body += 1
+    body_words += words
+    body_chars += len(body)
+    if words < 100:
+        short_bodies += 1
+    sizes.append(words)
+    d = os.path.basename(os.path.dirname(p))
+    per_dir[d] = per_dir.get(d, 0) + 1
+
+print("HAS_BODY", has_body)
+print("NO_BODY", no_body)
+print("EMPTY_BODY", empty_body)
+print("SHORT_BODY_LT100W", short_bodies)
+print("BODY_WORDS", body_words)
+print("BODY_CHARS", body_chars)
+print("EXISTING_ZH", existing_zh)
+print("ISSUE_DIRS_WITH_BODY", len(per_dir))
+sizes.sort()
+print("MEDIAN_BODY_WORDS", statistics.median(sizes))
+print("P90_BODY_WORDS", sizes[int(len(sizes)*0.9)])
+print("MAX_BODY_WORDS", sizes[-1])
+print("SUM_OVER_5K", sum(1 for s in sizes if s > 5000))
--- a/sreweekly/build_queue.py
+++ b/sreweekly/build_queue.py
@@ -0,0 +1,65 @@
+import os, re, io, sys, json
+sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8', errors='replace')
+root = "/Users/weishen/Workspace/nexus/sreweekly/markdown"
+
+# collect files with 正文 >= 50 chars, excluding those with existing -zh.md counterpart
+pending = []
+existing_zh = set()
+for dp, dn, fn in os.walk(root):
+    for f in fn:
+        if re.search(r"-zh\.md$|\.zh\.md$|zh-CN\.md$", f):
+            existing_zh.add(os.path.join(dp, f))
+
+for dp, dn, fn in os.walk(root):
+    for f in sorted(fn):
+        if not f.endswith(".md"): continue
+        if re.search(r"-zh\.md$|\.zh\.md$|zh-CN\.md$", f): continue
+        p = os.path.join(dp, f)
+        if p + "-zh" in [e.replace(".zh.md","").replace("-zh.md","") for e in [] ]: pass
+        stem = f[:-3]
+        if os.path.exists(os.path.join(dp, stem + "-zh.md")) or os.path.exists(os.path.join(dp, stem + ".zh.md")):
+            continue
+        try:
+            txt = open(p, encoding="utf-8").read()
+        except Exception:
+            continue
+        m = re.search(r"##\s*正文\s*\n(.*)", txt, re.S)
+        if not m: continue
+        body = m.group(1).strip()
+        if len(body) < 50: continue
+        pending.append((len(body), p))
+
+pending.sort()  # smallest first
+print("PENDING", len(pending))
+print("TOTAL_CHARS", sum(c for c, _ in pending))
+
+# pack into tasks of ~50K chars each
+TARGET = 50000
+tasks = []
+cur = []
+cur_chars = 0
+for c, p in pending:
+    if cur and cur_chars + c > TARGET:
+        tasks.append(cur)
+        cur = []
+        cur_chars = 0
+    cur.append(p)
+    cur_chars += c
+if cur: tasks.append(cur)
+print("TASKS", len(tasks))
+
+os.makedirs("/Users/weishen/Workspace/nexus/sreweekly/translation_tasks", exist_ok=True)
+meta = []
+for i, t in enumerate(tasks):
+    # split into smaller chunks of ~15 files each for subagent work units inside a task?
+    with open(f"/Users/weishen/Workspace/nexus/sreweekly/translation_tasks/task_{i:04d}.txt", "w") as fh:
+        fh.write("\n".join(t) + "\n")
+    total = sum(os.path.getsize(p) for p in t)
+    meta.append({"task": i, "files": len(t), "chars": total})
+
+with open("/Users/weishen/Workspace/nexus/sreweekly/translation_tasks/meta.json", "w") as fh:
+    json.dump(meta, fh, indent=1)
+print("meta.json written; chars distribution:")
+import statistics
+cs = [m["chars"] for m in meta]
+print("max task chars", max(cs), "median", statistics.median(cs))
--- a/sreweekly/html/534-2026-09-14.html
+++ b/sreweekly/html/534-2026-09-14.html
@@ -0,0 +1,102 @@
+<p><a class="email_only" href="https://sreweekly.com/sre-weekly-issue-534/">View on sreweekly.com</a></p>
+
+<div class="sreweekly-sponsor-message" style="border: 1px solid #b0b0b0; width: 80%;">
+<h2 style="text-align: center; font-size: 80%; color: #909090;">A message from our sponsor, <a href="https://sreweekly.com/link/534">Planetscale</a>:</h2>
+<p>Neki brings horizontal sharding to Postgres. It handles the hard parts of running Postgres at scale:</p>
+<ul>
+<li>Online schema changes</li>
+<li>Version upgrades with no downtime</li>
+<li>Better connection pooling</li>
+<li>Resharding</li>
+<li>Graceful planned and unplanned failovers</li>
+</ul>
+<p>→ Neki is available today. <a href="https://sreweekly.com/link/534"><u>Learn more.</u></a></p>
+</div>
+
+
+<div class="wp-block-group"><div class="wp-block-group__inner-container is-layout-flow wp-block-group-is-layout-flow">
+<div class="sreweekly-entry">
+<div class="sreweekly-title"><a href="https://www.sylvainkalache.com/blog/ai-handles-incidents-engineers-lose-touch-with-their-systems" target="_blank">AI handles incidents, engineers lose touch with their systems</a></div>
+<div class="sreweekly-description">
+<blockquote>
+<p>The better these tools become at resolving routine incidents, the less practice human responders will get. And when an ambiguous, high-severity incident comes in that automation cannot solve, responding engineers will be in trouble.</p>
+</blockquote>
+<p>I love the concept of <em>comprehension debt</em> described in this article.</p>
+<p>&nbsp;&nbsp;<small>Sylvain Kalache</small></p>
+</div>
+</div>
+
+
+
+<div class="sreweekly-entry">
+<div class="sreweekly-title"><a href="https://surfingcomplexity.blog/2026/08/18/tough-days-at-github-a-continuing-series/" target="_blank">Tough days at GitHub, a continuing series</a></div>
+<div class="sreweekly-description">
+<p>Another excellent write-up by my favorite writer of incident write-up write-ups.  I especially like that last section.</p>
+<p>Lorin also <a href="https://surfingcomplexity.blog/2026/08/19/github-autoscaling-and-the-component-substitution-fallacy/">wrote more the next day</a>.</p>
+<p>&nbsp;&nbsp;<small>Lorin Hochstein</small></p>
+</div>
+</div>
+
+
+
+<div class="sreweekly-entry">
+<div class="sreweekly-title"><a href="https://greatcircle.com/blog/2026/08/18/how-senior-leaders-disrupt-incidents-by-showing-up/" target="_blank">How senior leaders disrupt incidents just by showing up</a></div>
+<div class="sreweekly-description">
+<blockquote>
+<p>A VP’s question [&#8230;] lands with the weight of the org chart behind it, and everyone in the channel feels it.</p>
+</blockquote>
+<p>I especially liked the sections toward the end on how to mitigate a leader&#8217;s impact.</p>
+<p>&nbsp;&nbsp;<small>Brent Chapman</small></p>
+</div>
+</div>
+
+
+
+<div class="sreweekly-entry">
+<div class="sreweekly-title"><a href="https://bluetriangle.com/blog/empowering-retail-excellence-how-lowes-sre-team-is-driving-reliability-through-hyper-automation-and-unified-platforms" target="_blank">How Lowe&#8217;s SRE Team is Driving Reliability Through Hyper Automation and Unified Platforms</a></div>
+<div class="sreweekly-description">
+<p>Lowe&#8217;s has an intensive (and intense) SRE practice that provides client teams with a framework of tools to ensure reliability.</p>
+<p>&nbsp;&nbsp;<small>Raghuprasanth Ravichandran, Joe Praveena A, and Pavan Palagiri</small></p>
+</div>
+</div>
+
+
+
+<div class="sreweekly-entry">
+<div class="sreweekly-title"><a href="https://hackernoon.com/before-you-automate-a-decision-define-its-blast-radius" target="_blank">Before You Automate a Decision, Define Its Blast Radius</a></div>
+<div class="sreweekly-description">
+<p>How far will the impact of an incorrect automated decision spread?  Will it get integrated into the system and influence later decisions?</p>
+<p>&nbsp;&nbsp;<small>Sai Sandeep Koneti &mdash; HackerNoon</small></p>
+</div>
+</div>
+
+
+
+<div class="sreweekly-entry">
+<div class="sreweekly-title"><a href="https://www.gremlin.com/blog/managing-kubernetes-node-drains-with-pod-disruption-budgets" target="_blank">Managing Kubernetes node drains with Pod Disruption Budgets</a></div>
+<div class="sreweekly-description">
+<p>A great primer on how pod disruption budgets work and why they&#8217;re critical for reliability.</p>
+<p>&nbsp;&nbsp;<small>Andre Newman &mdash; Gremlin</small></p>
+</div>
+</div>
+
+
+
+<div class="sreweekly-entry">
+<div class="sreweekly-title"><a href="https://www.checklyhq.com/blog/agentic-rewrite-nodejs-to-go" target="_blank">Rewriting a Node.js Service in Go With AI Agents</a></div>
+<div class="sreweekly-description">
+<p>They took a systematic approach using test-driven development.  I enjoyed not only learning what went well, but where they ran into trouble.</p>
+<p>&nbsp;&nbsp;<small>Edvinas Janusevicius &mdash; Checkly</small></p>
+</div>
+</div>
+
+
+
+<div class="sreweekly-entry">
+<div class="sreweekly-title"><a href="https://www.uptimelabs.io/articles/supporting-new-responders" target="_blank">Supporting Your Team&#8217;s New Responders</a></div>
+<div class="sreweekly-description">
+<p>Great advice if you&#8217;re training early-career engineers on incident response.  This advice reminds me of some of the techniques that folks used with me when I was starting out.</p>
+<p>&nbsp;&nbsp;<small>Karan Nagarajagowda &mdash; Uptime Labs</small></p>
+</div>
+</div>
+</div></div>
--- a/sreweekly/manifest.json
+++ b/sreweekly/manifest.json
@@ -1,6 +1,6 @@
 {
  "feed": "https://sreweekly.com/feed/",
-  "last_scanned": "2026-09-12T18:37:33",
+  "last_scanned": "2026-09-14T19:02:12",
  "issues": {
    "532": {
      "id": "532",
@@ -7988,6 +7988,17 @@
      "extracted": false,
      "article_count": 0,
      "markdown_dir": null
+    },
+    "534": {
+      "id": "534",
+      "title": "SRE Weekly Issue #534",
+      "url": "https://sreweekly.com/sre-weekly-issue-534/",
+      "pub_date": "2026-09-14",
+      "html_file": "html/534-2026-09-14.html",
+      "fetched_at": "2026-09-14T19:02:12",
+      "extracted": false,
+      "article_count": 0,
+      "markdown_dir": null
    }
  }
 }
--- a/sreweekly/markdown/10/02-survey-on-release-processes-zh.md
+++ b/sreweekly/markdown/10/02-survey-on-release-processes-zh.md
@@ -0,0 +1,27 @@
+# 发布流程调查
+
+- **期号**: SRE Weekly Issue #10（2016-02-14）
+- **作者**: —
+- **链接**: https://sealuzh.wordpress.com/2016/02/12/survey-on-modern-release-processes-2/
+
+## 简介
+
+苏黎世大学的软件演化与架构实验室正在进行一项关于现代持续部署实践的研究。我非常期待看到结果，尤其是持续交付（CD）与可靠性交汇的那部分，所以如果你有时间，请过去填一下问卷。感谢 UZH 的 Gerald Schermann 联系我。
+
+## 正文
+
+我们目前正在开展一项关于现代发布流程的研究，诚邀您参与我们的调查问卷。我们的目标是要更好地了解那些通常与持续交付（Continuous Delivery）相关的实践在工业界是如何被使用的。
+
+问卷大约需要 **7-9 分钟**。
+
+问卷链接：<https://sealuzh.typeform.com/to/k6SR2t>
+
+参与问卷，您将有机会参与抽奖，**赢取两张 50 美元 Amazon 礼品卡之一**。
+
+我们将**保密**处理所有作答，并在发布前对收集到的所有数据进行**匿名化**处理。我们**不会**将回答归因于任何特定参与者。问卷结束时，您可以自愿提供邮箱地址，以便参与抽奖，和/或在您希望收到调查结果通知时使用。
+
+我们非常感谢您的参与！谢谢！
+
+如有任何疑问，请随时联系 [Gerald Schermann](mailto:schermann@ifi.uzh.ch)。
+
+![screenshot_survey](https://sealuzh.wordpress.com/wp-content/uploads/2016/02/screenshot_survey.png?w=465&h=344)
--- a/sreweekly/markdown/10/03-what-s-behind-most-data-center-outages-zh.md
+++ b/sreweekly/markdown/10/03-what-s-behind-most-data-center-outages-zh.md
@@ -0,0 +1,17 @@
+# 大多数数据中心故障背后的原因是什么？
+
+- **期号**: SRE Weekly Issue #10（2016-02-14）
+- **作者**: —
+- **链接**: https://gcn.com/articles/2016/02/09/data-center-outages.aspx?m=1
+
+## 简介
+
+我一直纠结要不要把 Emerson Network Power 那份关于数据中心故障成本与原因的调查报告链接过来。报告本身大都是一些没什么意思的数字，而且还要注册才能看。不过，这篇文章是对报告的很好总结，还附带了不少其他有趣的统计数据。
+
+## 正文
+
+![EIA long-term outlook identifies EV and data-center load as dominant structural drivers of US electricity growth to 2050 1 EV charging stations at a commercial depot under cool industrial lighting, eia long](https://gcn.com/wp-content/uploads/2026/09/eia-long-term-outlook-identifies-data-photo-scaled-768x432.jpg)
+
+### [EIA 长期展望：电动汽车与数据中心负荷是 2050 年前美国电力增长的主要结构性驱动因素](https://gcn.com/eia-long-term-outlook-identifies-data/21530/)
+
+根据……，电动汽车充电与数据中心服务器合计将是 2050 年前美国电力需求增长的主要结构性驱动因素……
--- a/sreweekly/markdown/100/05-re-invent-2017-new-products-services-zh.md
+++ b/sreweekly/markdown/100/05-re-invent-2017-new-products-services-zh.md
@@ -0,0 +1,49 @@
+# re:Invent 2017 | 新产品与服务
+
+- **期号**: SRE Weekly Issue #100（2017-12-03）
+- **作者**: —
+- **链接**: https://aws.amazon.com/new/reinvent/
+
+## 简介
+
+re:Invent 2017 结束了（呼），现在我们有一大堆新产品和功能可以玩了。详细的解读我就不做了，留给 Last Week in AWS，这里只想指出几个对 SRE 有特别意义的东西：Spot 实例的休眠（Hibernation）、T2 unlimited（T2 无限型）、EC2 分散放置组（spread placement groups）、Aurora 数据库多主支持（预览版）、DynamoDB 全局表（global tables）。
+
+## 正文
+
+# AWS 有什么新动态（What's New with AWS）
+
+及时了解我们最新的云计算服务、功能和区域扩展
+
+## 最新公告（Latest announcements）
+
+                           加载中（Loading）
+                          
+
+                           加载中（Loading）
+                          
+
+                           加载中（Loading）
+                          
+
+                      加载中（Loading）
+                    
+
+                      加载中（Loading）
+                    
+
+                      加载中（Loading）
+                    
+
+                      加载中（Loading）
+                    
+
+                      加载中（Loading）
+                    
+
+                      加载中（Loading）
+                    
+
+                      加载中（Loading）
+                    
+
+                      加载中（Loading）
--- a/sreweekly/markdown/101/06-black-friday-cyber-monday-performance-report-2017-zh.md
+++ b/sreweekly/markdown/101/06-black-friday-cyber-monday-performance-report-2017-zh.md
@@ -0,0 +1,33 @@
+# 2017 年黑色星期五与网络星期一性能报告
+
+- **期号**: SRE Weekly Issue #101（2017-12-10）
+- **作者**: —
+- **链接**: http://blog.catchpoint.com/2017/11/29/black-friday-cyber-monday-performance-report-2017/
+
+## 简介
+
+这是 Catchpoint 的年度总结，盘点近期美国节假日期间各家网站的表现。
+
+## 正文
+
+### SRE 报告：AI 乐观主义与"努力"的经济学
+
+2026 年 2 月 10 日
+
+2026 年 2 月 10 日
+
+谢谢！您的提交已收到！
+
+哎呀！提交表单时出错了。
+
+显示 0 条帖子，共 0 条
+
+2026 年 1 月 22 日
+
+2025 年 12 月 17 日
+
+2025 年 12 月 2 日
+
+未找到结果
+
+请尝试其他关键词
--- a/sreweekly/markdown/103/05-no-need-to-be-alarmed-crafting-an-effective-alert-strategy-zh.md
+++ b/sreweekly/markdown/103/05-no-need-to-be-alarmed-crafting-an-effective-alert-strategy-zh.md
@@ -0,0 +1,15 @@
+# 不必惊慌：制定一份有效的告警策略
+
+- **期号**: SRE Weekly Issue #103（2017-12-31）
+- **作者**: —
+- **链接**: https://blog.appoptics.com/no-need-alarmed-crafting-effective-alert-strategy/
+
+## 简介
+
+AppOptics 对告警的见解，其中这句格外精彩：
+
+> 更多时候，我们对指标的选择和阈值的设定，是被手里已有的工具牵着走的。因此，如果工具测不了延迟，我们也就不会对延迟设置告警。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/103/07-2018-and-the-dawn-of-network-reliability-engineering-nre-zh.md
+++ b/sreweekly/markdown/103/07-2018-and-the-dawn-of-network-reliability-engineering-nre-zh.md
@@ -0,0 +1,44 @@
+# 2018 年与网络可靠性工程（NRE）的黎明
+
+- **期号**: SRE Weekly Issue #103（2017-12-31）
+- **作者**: —
+- **链接**: https://forums.juniper.net/t5/SDN-and-NFV-Era/2018-and-the-Dawn-of-Network-Reliability-Engineering-NRE/ba-p/316915
+
+## 简介
+
+Juniper 探讨了网络工程师角色向网络可靠性工程师（NRE）的演进。
+
+> 正如系统管理员从技师成长为以 SRE 身份出现的技术专家，NRE 这个头衔同样宣告了一种新文化，它代表了我们作为"网络无敌工程"工程师所做、 所有的一切之巅峰。
+
+## 正文
+
+跳过主导航（按回车）。
+登录
+切换导航
+Elevate
+社区
+所有社区
+我的社区
+答案
+创新圈
+培训与发展
+浏览
+讨论帖
+热门讨论
+活动
+知识库条目
+TechPost
+大使
+MistFits
+博客
+播客
+参与
+帮助/常见问题
+分享你的专长
+成为会员
+登录
+加入 Elevate
+页面未找到
+抱歉！您请求的页面未找到。
+© 2025 Hewlett Packard Enterprise Development LP
+由 Higher Logic 提供技术支持
--- a/sreweekly/markdown/104/01-safety-moment-the-power-of-local-rational-it-is-big-zh.md
+++ b/sreweekly/markdown/104/01-safety-moment-the-power-of-local-rational-it-is-big-zh.md
@@ -0,0 +1,33 @@
+# Safety Moment——本地合理性（Local Rationality）的力量……这力量可大了！
+
+- **期号**: SRE Weekly Issue #104（2018-01-07）
+- **作者**: —
+- **链接**: http://preaccidentpodcast.podbean.com/e/safety-moment-the-power-of-local-rationalit-is-big/
+
+## 简介
+
+本地合理性（local rationale）：操作人员在做出某个决策背后的推理与背景。Todd Conklin 提醒我们，当事后诸葛亮让某个决策看起来很不理性时，要去弄清当时现场真正发生了什么。
+
+## 正文
+
+![Safety Moment - The Power of Local Rational...it is big!](https://pbcdn1.podbean.com/imglogo/ep-logo/pbblog733390/Str8conklin.jpg)
+
+2018 年 1 月 3 日
+
+# Safety Moment——本地合理性的力量……这力量可大了！
+
+操作人员在触发导致故障的条件时，他/她当时在想什么？
+
+每个人做每件事都是有原因的。
+
+这是我们再一次讨论这个话题的机会。
+
+听一听，看看你怎么想。
+
+最佳安全播客、安全项目、安全叙事、事故调查、人的表现（Human Performance）、Safety Differently（另一种安全观）、卓越运营、韧性工程（Resilience Engineering）、安全与韧性激励。
+
+听一听吧。
+
+感谢收听，也请告诉你的朋友们。咱们滑雪缆车上见。
+
+还没有评论。快来抢第一个发言！
--- a/sreweekly/markdown/105/05-twitter-mipsytipsy-on-monitoring-vs-observability-zh.md
+++ b/sreweekly/markdown/105/05-twitter-mipsytipsy-on-monitoring-vs-observability-zh.md
@@ -0,0 +1,20 @@
+# Twitter：mipsytipsy 谈监控与可观测性
+
+- **期号**: SRE Weekly Issue #105（2018-01-14）
+- **作者**: —
+- **链接**: https://mobile.twitter.com/mipsytipsy/status/951343352359763968
+
+## 简介
+
+我很少发推特相关的内容，但 Charity Majors 这条推文串值得一读。这玩意儿应该叫推文"串"吗？
+
+## 正文
+
+![@mipsytipsy](https://pbs.twimg.com/profile_images/1576759705933819904/iDotz1Gw_normal.jpg)
+
+你怎么可能预判"未来的你"需要收集哪些数据，来调试一个无法预判的问题？（而且，如果你*能*预判这个问题，那还要花哨的调试工具干什么？）
+我经常听到这种说法，而答案恰恰触及了监控（monitoring）与可观测性（o11y）之间的本质区别。
+
+[2018 年 1 月 11 日 上午 6:41](https://mobile.twitter.com/mipsytipsy/status/951343352359763968)
+
+[加利福尼亚州旧金山](https://mobile.twitter.com/places/5a110d312052166f)
--- a/sreweekly/markdown/105/08-planning-better-for-failure-how-mainframe-error-messages-impact-cx-zh.md
+++ b/sreweekly/markdown/105/08-planning-better-for-failure-how-mainframe-error-messages-impact-cx-zh.md
@@ -0,0 +1,13 @@
+# 为故障做更好的规划：大型机错误消息如何影响客户体验
+
+- **期号**: SRE Weekly Issue #105（2018-01-14）
+- **作者**: —
+- **链接**: https://compuware.com/mainframe-error-messages-impact-cx/
+
+## 简介
+
+这篇文章讲的是有用的错误消息——它无论对客户体验还是对运维都同样重要。不过，如今到底什么才算得上一台"大型机"，我实在拿不准……
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] ssl/tls alert handshake failure (_ssl.c:1032)
--- a/sreweekly/markdown/106/04-sre-survey-2018-zh.md
+++ b/sreweekly/markdown/106/04-sre-survey-2018-zh.md
@@ -0,0 +1,22 @@
+# 2018 年 SRE 调查
+
+- **期号**: SRE Weekly Issue #106（2018-01-21）
+- **作者**: —
+- **链接**: http://pages.catchpoint.com/SRE-Survey-2018.html
+
+## 简介
+
+Catchpoint 正在对 SRE 及从事类似工作的人做一项调查，非常希望你能抽空填一下。不但结果数据会非常有意思，而且每完成一份调查，Catchpoint 就会向慈善机构捐赠 5 美元。让我们把票箱塞满，帮他们冲到 3000 美元的上限吧！
+
+## 正文
+
+**现在可下载！**[**下载《SRE 报告 2025》**](http://pages.catchpoint.com/asset/2025-sre-report)
+
+2018 年 1 月，Catchpoint 调查了 416 名站点可靠性工程师（SRE），以了解成为 SRE 究竟意味着什么，以及 SRE 所在组织的类型、技能与文化。该报告考察了四项关键的调查发现，包括自动化需求与服务级指标，并描绘了当今 SRE 的全面画像。
+
+该报告试图就以下问题获得洞察：
+
+- **SRE 是谁？**他们的经验水平、背景和技能组合如何？
+- **SRE 在哪里工作？**什么样的组织会雇用 SRE，团队结构和文化是怎样的？
+- **他们在做什么？**他们的时间如何分配，角色如何定义？
+- **他们是怎么做的？**SRE 日常使用哪些工具和流程，用什么指标和方法来定义成功？
--- a/sreweekly/markdown/108/07-stop-wasting-your-beer-money-zh.md
+++ b/sreweekly/markdown/108/07-stop-wasting-your-beer-money-zh.md
@@ -0,0 +1,15 @@
+# 别再浪费你的啤酒钱
+
+- **期号**: SRE Weekly Issue #108（2018-02-04）
+- **作者**: —
+- **链接**: https://blog.realkinetic.com/stop-wasting-your-beer-money-12c3fe5e4d54
+
+## 简介
+
+> "那我宁可省下披萨和啤酒，把钱拿去买 Splunk。"
+
+当某个工具并非交付客户价值的关键时，这位作者呼吁我们克制住自研的冲动，转而寻找现成的外部服务或软件。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/108/10-predicting-resource-exhaustion-with-double-exponential-smoothing-zh.md
+++ b/sreweekly/markdown/108/10-predicting-resource-exhaustion-with-double-exponential-smoothing-zh.md
@@ -0,0 +1,13 @@
+# 用双指数平滑预测资源耗尽
+
+- **期号**: SRE Weekly Issue #108（2018-02-04）
+- **作者**: —
+- **链接**: https://signalfx.com/blog/predicting-resource-exhaustion-double-exponential-smoothing/
+
+## 简介
+
+你有多少次因为服务器磁盘使用率达到 95% 而被叫醒，结果发现它离写满还有好几个月？SignalFX 的这篇文章讲的是他们平台上的一个功能，但其中的思路完全可以套用到其他工具上。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)
--- a/sreweekly/markdown/109/04-charity-majors-on-twitter-zh.md
+++ b/sreweekly/markdown/109/04-charity-majors-on-twitter-zh.md
@@ -0,0 +1,22 @@
+# Charity Majors 的推文
+
+- **期号**: SRE Weekly Issue #109（2018-02-11）
+- **作者**: —
+- **链接**: https://twitter.com/mipsytipsy/status/957761131216449536
+
+## 简介
+
+继上周登上《纽约时报》之后，Charity Majors 发布了这条精彩的推文串，讲的是不论你是什么类型的工程师——我尤其想说是 SRE——重视供应商关系管理、创造商业价值的重要性。
+
+## 正文
+
+![@mipsytipsy](https://pbs.twimg.com/profile_images/1576759705933819904/iDotz1Gw_normal.jpg)
+
+这条推文串让我想起，我脑子里一直转着几个与供应商有关的想法。
+第一个是：我们都在卖点什么。如果你是一名受雇的工程师，你也在卖点什么。
+
+此帖子来自你已屏蔽的账号。
+
+[2018 年 1 月 28 日 晚上 11:43](https://twitter.com/mipsytipsy/status/957761131216449536)
+
+[加利福尼亚州旧金山](https://twitter.com/places/5a110d312052166f)
--- a/sreweekly/markdown/11/04-fatal-german-train-crash-caused-by-human-error-prosecutor-says-zh.md
+++ b/sreweekly/markdown/11/04-fatal-german-train-crash-caused-by-human-error-prosecutor-says-zh.md
@@ -0,0 +1,13 @@
+# 检方称德国致命火车相撞事故系人为失误所致
+
+- **期号**: SRE Weekly Issue #11（2016-02-21）
+- **作者**: —
+- **链接**: http://mobile.reuters.com/article/idUSKCN0VP23L
+
+## 简介
+
+我的心与那些受伤、遇难的乘客及其家人同在，也与那位犯下错误的调度员同在。这里有很多值得调查的地方：为什么一个活生生的人会处在那样的位置，让一个错误就能造成如此惨重的后果？希望系统能有一些补救之道，避免未来再发生这样的灾难。
+
+## 正文
+
+[[致德国致命火车相撞事故——检方称系人为失误所致]]
--- a/sreweekly/markdown/110/08-everything-you-need-to-know-about-dynamodb-global-tables-zh.md
+++ b/sreweekly/markdown/110/08-everything-you-need-to-know-about-dynamodb-global-tables-zh.md
@@ -0,0 +1,13 @@
+# 关于 DynamoDB 全局表，你需要知道的一切
+
+- **期号**: SRE Weekly Issue #110（2018-02-18）
+- **作者**: —
+- **链接**: https://engineering.opsgenie.com/everything-you-need-to-know-about-dynamodb-global-tables-952d020d9834
+
+## 简介
+
+OpsGenie 分析了 AWS 的新品 DynamoDB 全局表——一种跨区域多主 NoSQL 数据存储。他们既讲了优点也讲了坑，还讨论了如何平滑迁移到全局表。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/111/02-twitter-charity-majors-about-making-on-call-suck-less-zh.md
+++ b/sreweekly/markdown/111/02-twitter-charity-majors-about-making-on-call-suck-less-zh.md
@@ -0,0 +1,22 @@
+# Twitter：Charity Majors 谈如何让值班没那么难受
+
+- **期号**: SRE Weekly Issue #111（2018-02-25）
+- **作者**: Charity Majors — Honeycomb
+- **链接**: https://twitter.com/mipsytipsy/status/962151928741285888
+
+## 简介
+
+这条推文串写得精彩绝伦，把"为什么开发者亲自值班很重要"以及"如何让这件事不那么可怕"讲得清清楚楚。附带内容：推文串还延伸聊到了值班薪酬。
+
+> 如果你不亲自支撑自己的服务，你的服务在质量上就是更差的**，**而且你等于把自己捅的娄子的负担甩给了别人——那些人也有自己的生活，也要睡觉。
+
+## 正文
+
+![@mipsytipsy](https://pbs.twimg.com/profile_images/1576759705933819904/iDotz1Gw_normal.jpg)
+
+关于值班的这些激烈讨论，确实暴露了那些工程师所在公司的种种病态。听好了：
+1) 工程既包括*构建*服务，也包括*维护*服务
+2) 值班不应该影响生活
+3) 反馈回路越短，服务就越*好*
+
+[2018 年 2 月 10 日 凌晨 2:31](https://twitter.com/mipsytipsy/status/962151928741285888)
--- a/sreweekly/markdown/112/02-github-s-report-on-the-memcached-based-ddos-zh.md
+++ b/sreweekly/markdown/112/02-github-s-report-on-the-memcached-based-ddos-zh.md
@@ -0,0 +1,16 @@
+# GitHub 关于基于 Memcached 的 DDoS 攻击的报告
+
+- **期号**: SRE Weekly Issue #112（2018-03-04）
+- **作者**: Sam Kottler — GitHub
+- **链接**: https://githubengineering.com/ddos-incident-report/
+
+## 简介
+
+本周的大新闻是 memcached UDP 放大型 DDoS 手法——攻击者正是用它向我们的朋友 GitHub 发起了高达 1.3 Tbps（！）的流量。他们的说明见上方链接。
+
+网上相关的讨论也闹翻了天：[Cloudflare 对这次攻击的描述](https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/)、[Akamai 讲述自己如何帮 GitHub 扛过攻击](https://blogs.akamai.com/2018/03/memcached-fueled-13-tbps-attacks.html)、memcached 开发者[宣布](https://twitter.com/dormando/status/968570723521277953)发布默认禁用 UDP 的版本、还有[评论](https://twitter.com/dormando/status/968540354692636672)，Charity Majors 也写了些[有趣的评论](https://twitter.com/mipsytipsy/status/969443770532900866)、以及 [Wired 对 GitHub 遭攻击的报道](https://www.wired.com/story/github-ddos-memcached/)。
+
+## 正文
+
+正在跳转…
+如果未自动跳转，请点击此处。
--- a/sreweekly/markdown/112/03-runbook-template-zh.md
+++ b/sreweekly/markdown/112/03-runbook-template-zh.md
@@ -0,0 +1,56 @@
+# Runbook 模板
+
+- **期号**: SRE Weekly Issue #112（2018-03-04）
+- **作者**: Catie McCaffrey
+- **链接**: https://github.com/CaitieM20/Talks/blob/master/TacklingAlertFatigue/runbook.md
+
+## 简介
+
+一个非常出色的模板，可以作为编写 runbook（运维手册）的基础。
+
+## 正文
+
+一个带主章节链接的目录
+
+对服务的简短描述，最多 1 到 2 句话。这项服务为什么重要？它的核心功能是什么？它为用户提供了哪些特性？
+
+指向该服务仪表盘（Dashboard）的链接
+
+指向该服务告警（Alert）的链接
+
+每个告警都应有对应的章节，按字母顺序排列
+
+告警描述：为什么会有这个告警？它表示什么？通常是什么原因触发的？
+
+这种情况如何影响我们的客户？如果客户没有受到影响，这就是一个很好的信号：该告警可以考虑删除了。
+
+用清单宣言（Checklist Manifesto）风格的步骤来说明如何解决这个告警。一个从未接触过我们技术栈的人也应该能照着这些步骤来处置事件。如果无法自行处置，请在这里包含升级（escalation）步骤。
+
+1. 做这件事
+2. 查看这个图表
+3. 做这件事
+4. 再做另一件事
+5. 确认服务已恢复
+
+团队联系方式，以及可能的升级联系人信息。我们依赖哪些服务？如何向它们升级？在这里定义这些信息。
+
+我们通过 Jira 进行生产环境变更管理部署，这里放一个包含所有最新变更的链接。最近的提交、CI 日志等，对于了解系统上部署了什么代码、近期做了哪些变更极有帮助。
+
+关于这项服务部署在哪里、以及如何访问这些机器的信息。
+
+如何部署这项服务。这里同样推荐使用清单宣言风格的列表。
+
+1. 做这件事
+2. 再做另一件事
+3. 最后做这件事
+
+如何进行金丝雀部署（Canary Deployment）的说明
+
+1. 做这件金丝雀部署的事
+2. 另一项金丝雀部署任务
+
+如何回滚一次部署（Rollback）的说明。
+
+1. 从这里获取回滚构建
+2. 做这件事
+3. 再做另一件事。
--- a/sreweekly/markdown/112/04-devops-and-sre-contribution-the-lemur-book-zh.md
+++ b/sreweekly/markdown/112/04-devops-and-sre-contribution-the-lemur-book-zh.md
@@ -0,0 +1,15 @@
+# DevOps 与 SRE 投稿征集——《狐猴之书》
+
+- **期号**: SRE Weekly Issue #112（2018-03-04）
+- **作者**: David Blank-Edelman
+- **链接**: https://lemurbook.com/devops-and-sre-contribution/
+
+## 简介
+
+这位即将出版 O'Reilly 新书的作者，正在为一章众包内容征集小稿：
+
+> 用不超过两段话回答：你认为 DevOps 和 SRE 之间是什么关系？它们有何相似之处？又有何不同？两者能在每个组织里都落地吗？两者能同时存在于同一个组织吗？诸如此类……
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/112/08-launching-an-entire-fireworks-display-at-once-zh.md
+++ b/sreweekly/markdown/112/08-launching-an-entire-fireworks-display-at-once-zh.md
@@ -0,0 +1,28 @@
+# 一次点爆整场烟花
+
+- **期号**: SRE Weekly Issue #112（2018-03-04）
+- **作者**: Tom Scott
+- **链接**: https://www.youtube.com/watch?v=dabnx8VSdkE&feature=youtu.be
+
+## 简介
+
+这是一个令人震撼的方式，来阐述"设计系统要能对人为失误有韧性"这一观点。
+
+> 如果一个人可能按错按钮、意外点爆整场烟花，那么问题也许不在人，而在于那个按钮。如果"分钟"和"几分之一秒"确实像我们故意演示的那样容易被搞混，那么也许是系统不够清晰，又或者是发射前的检查清单还不够周全。
+
+## 正文
+
+关于
+新闻动态
+版权
+联系我们
+创作者
+广告
+开发者
+条款
+隐私
+政策与安全
+YouTube 的工作原理
+试用新功能
+NFL Sunday Ticket
+© 2026 Google LLC
--- a/sreweekly/markdown/112/09-managing-feature-flag-debt-with-split-zh.md
+++ b/sreweekly/markdown/112/09-managing-feature-flag-debt-with-split-zh.md
@@ -0,0 +1,22 @@
+# 用 Split 管理特性开关债务
+
+- **期号**: SRE Weekly Issue #112（2018-03-04）
+- **作者**: Adil Aijaz — Split
+- **链接**: https://www.split.io/blog/managing-feature-flag-debt-split/
+
+## 简介
+
+这篇文章在预防和缓解"使用特性开关（feature flag）所固有的技术债"方面，有不少非常好的想法。表面上看这是篇介绍如何使用 Split.io 的文章，但这些想法完全可以广泛应用。
+
+## 正文
+
+![自主工作代理：流水线里的 AI 智能体](https://cdn.prod.website-files.com/69e786e187c925d08ee02b92/6a912f63d9743fc627959049_6a912f62de77187ae21860c8_6a7bbb98a8f91f9e32712ba1_6a7bbb92adaaa88df0f79dc2_autonomous-worker-agents-ai-ag-LW9nLnBuZw.webp)
+
+精选
+
+## 自主工作代理：流水线里的 AI 智能体
+
+Harness 推出自主工作代理：以 AI 作为流水线步骤运行，并具备企业让代理在生产环境中获信所需的治理能力。
+
+
+自主工作代理：流水线里的 AI 智能体
--- a/sreweekly/markdown/114/02-migrating-edge-network-providers-zh.md
+++ b/sreweekly/markdown/114/02-migrating-edge-network-providers-zh.md
@@ -0,0 +1,17 @@
+# 迁移边缘网络提供商
+
+- **期号**: SRE Weekly Issue #114（2018-03-18）
+- **作者**: Jacob Bednarz — Envato
+- **链接**: https://webuild.envato.com/blog/migrating-edge-providers/
+
+## 简介
+
+他们用了一个很棒的方法：用 RSpec 构建一套 HTTP 请求测试，在部署期间持续运行，确保从最终用户视角看没有任何变化。再加上自动生成测试这一点，简直是额外加分。
+
+## 正文
+
+![分享 AI 艺术的平台选择：16 个平台对比（2026）](https://elements.envato.com/learn/wp-content/uploads/2026/09/12_Popular_Platforms_for_Sharing_AI-Generated_Artwork_Hero_Image_01-copy-768x432.jpg) 
+
+### [分享 AI 艺术的平台选择：16 个平台对比（2026）](https://elements.envato.com/learn/where-to-share-ai-art)
+
+对比 2026 年分享 AI 艺术的 16 个平台，包括哪些平台要求标注、哪些限制 AI 作品、哪些能带来付费客户项目。
--- a/sreweekly/markdown/114/07-twitter-charity-majors-on-distributed-systems-complexity-and-microserv-zh.md
+++ b/sreweekly/markdown/114/07-twitter-charity-majors-on-distributed-systems-complexity-and-microserv-zh.md
@@ -0,0 +1,18 @@
+# Twitter：Charity Majors 谈分布式系统、复杂性与微服务
+
+- **期号**: SRE Weekly Issue #114（2018-03-18）
+- **作者**: Charity Majors
+- **链接**: https://twitter.com/mipsytipsy/status/973806469136121856
+
+## 简介
+
+什么是分布式系统，它们为什么难搞？我特别喜欢第二条推文里的定义。
+
+## 正文
+
+![@mipsytipsy](https://pbs.twimg.com/profile_images/1576759705933819904/iDotz1Gw_normal.jpg)
+
+最近好像很多人觉得指出"分布式系统"不过就是两个节点加一张网络，是一件很有趣的事。
+口语里说的分布式系统，意思是"这个系统最难、最有趣的部分恰恰就在于它的分布式特性"——也就是由大量动态小组件构成。
+
+[2018 年 3 月 14 日 上午 6:22](https://twitter.com/mipsytipsy/status/973806469136121856)
--- a/sreweekly/markdown/114/08-troubleshooting-ipv6-badness-to-certain-hosts-in-a-rack-zh.md
+++ b/sreweekly/markdown/114/08-troubleshooting-ipv6-badness-to-certain-hosts-in-a-rack-zh.md
@@ -0,0 +1,13 @@
+# 排查机架内某些主机的 IPv6 异常
+
+- **期号**: SRE Weekly Issue #114（2018-03-18）
+- **作者**: Rachel Kroll
+- **链接**: https://rachelbythebay.com/w/2018/03/16/slowroad/
+
+## 简介
+
+我特别爱看精彩的故障排查故事。这篇的故障模式相当出色，调查手法堪称满分，而且始终强调要一路追查到底、直到找到答案为止。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/115/02-look-for-the-duct-tape-zh.md
+++ b/sreweekly/markdown/115/02-look-for-the-duct-tape-zh.md
@@ -0,0 +1,13 @@
+# 去找找那些"胶带"吧
+
+- **期号**: SRE Weekly Issue #115（2018-03-25）
+- **作者**: Rachel Kroll
+- **链接**: https://rachelbythebay.com/w/2018/03/23/ducttape/
+
+## 简介
+
+所谓"胶带"，你懂的——就是那些躺在你 ~/bin 目录里的小 shell 脚本，因为系统自带的工具碍手碍脚、或者满足不了你的需求，你才亲手写了它们。按照这篇文章的说法，找到这些东西，你就找到了能让系统变得更好的有趣工作点。我想再补充一句：这些毛刺往往也正是引发故障的元凶之一。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/115/09-how-threat-stack-does-devops-part-iv-making-engineers-accountable-zh.md
+++ b/sreweekly/markdown/115/09-how-threat-stack-does-devops-part-iv-making-engineers-accountable-zh.md
@@ -0,0 +1,15 @@
+# Threat Stack 怎么做 DevOps（第四部分）：让工程师担起责任
+
+- **期号**: SRE Weekly Issue #115（2018-03-25）
+- **作者**: Pete Cheslock — Threat Stack
+- **链接**: https://www.threatstack.com/blog/how-threat-stack-does-devops-part-iv-making-engineers-accountable/
+
+## 简介
+
+作为一家安全公司，Threat Stack 在授权开发者直接运维其线上软件时，把安全放在第一位，这再合理不过。
+
+> 我们相信，好的运维成就好的安全。缩小工程师对系统的访问范围，万一我们日后需要调查恶意活动，噪声也会少很多。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/116/04-four-interacting-decisions-break-ssh-access-zh.md
+++ b/sreweekly/markdown/116/04-four-interacting-decisions-break-ssh-access-zh.md
@@ -0,0 +1,15 @@
+# 四个相互作用的决策搞坏了 ssh 访问
+
+- **期号**: SRE Weekly Issue #116（2018-04-01）
+- **作者**: Rachel Kroll
+- **链接**: https://rachelbythebay.com/w/2018/03/20/sshclock/
+
+## 简介
+
+这篇调试故事读起来很过瘾，里面也藏着一些值得你在自己系统里留意的坑。
+
+> 滴答滴答滴答。时间这东西，真难搞。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/117/04-it-s-about-what-broke-not-who-broke-it-zh.md
+++ b/sreweekly/markdown/117/04-it-s-about-what-broke-not-who-broke-it-zh.md
@@ -0,0 +1,13 @@
+# 重要的是什么东西坏了，而不是谁弄坏的
+
+- **期号**: SRE Weekly Issue #117（2018-04-08）
+- **作者**: Rachel Kroll
+- **链接**: https://rachelbythebay.com/w/2018/03/27/whowhat/
+
+## 简介
+
+> 你必须这样设计系统：让"自然而然去做的事"就能带来好结果，并且不会把任何人置于危险之中。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/117/09-preliminary-analysis-of-the-site-reliability-engineer-survey-zh.md
+++ b/sreweekly/markdown/117/09-preliminary-analysis-of-the-site-reliability-engineer-survey-zh.md
@@ -0,0 +1,33 @@
+# 站点可靠性工程师调查初步分析
+
+- **期号**: SRE Weekly Issue #117（2018-04-08）
+- **作者**: Dawn Parzych — Catchpoint
+- **链接**: http://blog.catchpoint.com/2018/03/15/preliminary-analysis-site-reliability-engineer-survey/
+
+## 简介
+
+比起调查报告中那种常见的汇总统计，我更喜欢这种"初步结果"。里面引用了自由回答的问题中实打实的原话，其中颇有一些真知灼见。如果你感兴趣，文末还附了可下载的完整调查报告链接。
+
+## 正文
+
+### SRE 报告：AI 乐观主义与"努力"的经济学
+
+2026 年 2 月 10 日
+
+2026 年 2 月 10 日
+
+谢谢！您的提交已收到！
+
+哎呀！提交表单时出错了。
+
+显示 0 条帖子，共 0 条
+
+2026 年 1 月 22 日
+
+2025 年 12 月 17 日
+
+2025 年 12 月 2 日
+
+未找到结果
+
+请尝试其他关键词
--- a/sreweekly/markdown/118/05-how-did-this-machine-jump-into-the-future-zh.md
+++ b/sreweekly/markdown/118/05-how-did-this-machine-jump-into-the-future-zh.md
@@ -0,0 +1,13 @@
+# 这台机器是怎么"穿越到未来"的？
+
+- **期号**: SRE Weekly Issue #118（2018-04-16）
+- **作者**: Rachel Kroll
+- **链接**: https://rachelbythebay.com/w/2018/04/12/date/
+
+## 简介
+
+一切只源于一个小小的拼写错误。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/119/02-why-i-usually-run-w-first-when-troubleshooting-unknown-machines-zh.md
+++ b/sreweekly/markdown/119/02-why-i-usually-run-w-first-when-troubleshooting-unknown-machines-zh.md
@@ -0,0 +1,13 @@
+# 排查陌生机器时，我为什么总是先运行 "w"
+
+- **期号**: SRE Weekly Issue #119（2018-04-29）
+- **作者**: Rachel Kroll
+- **链接**: https://rachelbythebay.com/w/2018/03/26/w/
+
+## 简介
+
+好主意。这让我想起几份工作之前，我把我们基础设施改造了一番，让所有在 shell 里敲下的命令都自动记入一个 Slack 频道。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/119/08-disaster-recovery-sites-of-exchanges-under-focus-as-ncdex-volumes-fall-zh.md
+++ b/sreweekly/markdown/119/08-disaster-recovery-sites-of-exchanges-under-focus-as-ncdex-volumes-fall-zh.md
@@ -0,0 +1,25 @@
+# NCDEX 成交量下滑，交易所灾备站点受关注
+
+- **期号**: SRE Weekly Issue #119（2018-04-29）
+- **作者**: Rajesh Bhayani — Business Standard
+- **链接**: http://www.business-standard.com/article/markets/disaster-recovery-sites-of-exchanges-under-focus-as-ncdex-volumes-fall-118042800285_1.html
+
+## 简介
+
+NCDEX 是印度孟买的一家证券交易所，它已经在灾难恢复（DR）站点运行了两周。遗憾的是，看起来性能与标准站点并不在一个水平上。
+
+## 正文
+
+这一迁移决定是在 4 月 16 日孟买坎朱尔马尔格（Kanjurmarg）的 NCDEX 办公楼发生意外火灾、部分线缆受损后做出的。交易在交易所迁移站点一天后恢复正常。
+
+此次事件让 DR 运营成为焦点，因为这可能是交易所有史以来第一次需要在 DR 站点运营将近两周的时间。
+
+自 4 月 16 日起，交易一直在 DR 站点进行，但较小的经纪商抱怨专线（leased line）工作不正常。截至 4 月 27 日，日均成交量从火灾前当月上半月的 218.7 亿卢比降至 155 亿卢比。
+
+一位不愿透露姓名的经纪商表示，他的成交量受到了影响，因为专线无法工作，他无法服务客户。他还表示，NCDEX 的成交量占他 MCX 成交量的 10%，因此为在 DR 站点交易而投入互联网线路对他而言并不划算。
+
+在周四晚间发布的一份通知中，NCDEX 表示："交易所正在恢复主站点，预计很快完成。交易所还将从主站点安排模拟交易时段，以测试连接性和站点整体就绪状态。"
+
+在 DR 站点交易两周，是印度所有交易所中最长的。2005 年孟买洪水时，MCX 曾将交易转移到 DR 站点数天。"然而，这一次焦点已经转移到各交易所 DR 站点的运作上，它们正在重新测试可操作性，以便为将来再发生类似事件时的长期使用做好准备，"一位业内官员说。
+
+一位行业资深人士表示："交易所多年来一直在 DR 站点进行测试和试运行交易。然而，NCDEX 事件证明这其实还远远不够。"原因是 DR 站点的专线连接带宽通常要小得多。因此，长期宕机实际上意味着长期的业务损失。
--- a/sreweekly/markdown/119/09-southwest-1380-engine-failure-4-17-2018-entire-event-actual-multi-sect-zh.md
+++ b/sreweekly/markdown/119/09-southwest-1380-engine-failure-4-17-2018-entire-event-actual-multi-sect-zh.md
@@ -0,0 +1,28 @@
+# 西南航空 1380 航班（2018 年 4 月 17 日发动机故障）全程实录：真实的多扇区空管录音
+
+- **期号**: SRE Weekly Issue #119（2018-04-29）
+- **作者**: —
+- **链接**: https://www.youtube.com/watch?v=FkVTdvcghHc
+
+## 简介
+
+你可能听说过，西南航空一架航班发生了灾难性的发动机故障，导致一名乘客罹难。而就在第二天，我的家人正好乘坐西南航空的航班飞往奥兰多。天哪。
+
+空管录音听起来令人震撼。当时在无线电上应答的那位飞行员冷静沉着，一边响应事故，一边安排降落和地面应急力量。
+
+## 正文
+
+关于
+新闻动态
+版权
+联系我们
+创作者
+广告
+开发者
+条款
+隐私
+政策与安全
+YouTube 的工作原理
+试用新功能
+NFL Sunday Ticket
+© 2026 Google LLC
--- a/sreweekly/markdown/12/03-what-is-high-availability-zh.md
+++ b/sreweekly/markdown/12/03-what-is-high-availability-zh.md
@@ -0,0 +1,77 @@
+# 什么是高可用（High Availability）？
+
+- **期号**: SRE Weekly Issue #12（2016-02-28）
+- **作者**: —
+- **链接**: https://www.digitalocean.com/community/tutorials/what-is-high-availability
+
+## 简介
+
+DigitalOcean 分享了这份关于高可用基本概念的概览。
+
+## 正文
+
+精选 AI 产品（Featured AI Products）
+
+计算（Compute）
+
+构建、部署和扩展云计算资源
+
+容器与镜像（Containers and Images）
+
+安全地存储和管理容器及备份
+
+托管数据库（Managed Databases）
+
+运行主流数据库引擎的全托管资源
+
+管理与开发工具（Management and Dev Tools）
+
+控制基础设施并获取洞察
+
+网络（Networking）
+
+保护并控制流向应用的流量
+
+安全（Security）
+
+借助这些安全功能保护你的账户和资源
+
+存储（Storage）
+
+在云端可靠地存储和访问任意规模的数据
+
+AI/ML
+
+CMS
+
+数据与物联网（Data and IoT）
+
+开发工具（Developer Tools）
+
+游戏与媒体（Gaming and Media）
+
+托管（Hosting）
+
+安全与网络（Security and Networking）
+
+初创企业与中小企业（Startups and SMBs）
+
+Web 与应用程序平台（Web and App Platforms）
+
+社区（Community）
+
+文档（Documentation）
+
+开发工具（Developer Tools）
+
+参与进来（Get Involved）
+
+实用工具与帮助（Utilities and Help）
+
+成为合作伙伴（Become a Partner）
+
+市场（Marketplace）
+
+随着你的成长而扩展——无论你运行的是一台虚拟机还是一万台。
+
+从 GPU 驱动的推理和 Kubernetes，到托管数据库与存储，获取构建、扩展和部署智能应用所需的一切。
--- a/sreweekly/markdown/120/01-non-uniform-memory-access-meets-the-oom-killer-zh.md
+++ b/sreweekly/markdown/120/01-non-uniform-memory-access-meets-the-oom-killer-zh.md
@@ -0,0 +1,13 @@
+# 非一致性内存访问（NUMA）遇上 OOM killer
+
+- **期号**: SRE Weekly Issue #120（2018-05-06）
+- **作者**: Rachel Kroll
+- **链接**: https://rachelbythebay.com/w/2018/03/30/oom/
+
+## 简介
+
+> "单个 NUMA 节点也能 OOM"——这句话从此进入我的排查清单：当一台机器明明内存充足，却还是跑去"屠杀"无辜（但个头很大）的进程时，我要考虑的原因又多了一条。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/121/03-the-benefits-of-chaos-engineering-as-a-service-zh.md
+++ b/sreweekly/markdown/121/03-the-benefits-of-chaos-engineering-as-a-service-zh.md
@@ -0,0 +1,45 @@
+# 混沌工程即服务（chaos engineering-as-a-service）的好处
+
+- **期号**: SRE Weekly Issue #121（2018-05-13）
+- **作者**: Matt Fornaciari — Gremlin, Inc.
+- **链接**: https://jaxenter.com/chaos-engineering-service-144113.html
+
+## 简介
+
+注意，本文作者是 Gremlin 的 CTO，不过文章里关于「购买还是自建混沌工程系统」的论述确实有不少可取之处。这些观点也适用于其他混沌工程服务——如果存在的话。
+
+## 正文
+
+{{article.subtitle}}
+
+{{article.abstract | truncate(300) }}
+
+{{article.abstract | truncate(200) }}
+
+{{isSecondAdsSet}}
+
+                    brand id {{brandid}}
+
+apploaded {{apploaded}}
+
+loading {{loading}}
+
+everLoadedData {{everLoadedData}}
+
+page {{page}}
+
+page_size {{page_size}}
+
+loadMorePossible {{loadMorePossible}}
+
+									＼立即抢购！＼用 Fullstack 会员让你的技术生涯
+更上一层楼！
+
+				
+更上一层楼！
+
+									＼使用优惠码 BTS24 立减 $20
+（全年会员）
+
+				
+（全年会员）
--- a/sreweekly/markdown/123/07-building-low-overhead-metrics-collection-for-high-performance-systems-zh.md
+++ b/sreweekly/markdown/123/07-building-low-overhead-metrics-collection-for-high-performance-systems-zh.md
@@ -0,0 +1,13 @@
+# 为高性能系统构建低开销的指标采集
+
+- **期号**: SRE Weekly Issue #123（2018-05-27）
+- **作者**: Jonathan Brown — Wallaroo
+- **链接**: https://blog.wallaroolabs.com/2018/02/building-low-overhead-metrics-collection-for-high-performance-systems/
+
+## 简介
+
+指标很好，对吧？但有时候也没那么好——当指标采集本身带来的负载大到足以拖累系统时，事情就反过来了。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/125/03-a-postmortem-template-zh.md
+++ b/sreweekly/markdown/125/03-a-postmortem-template-zh.md
@@ -0,0 +1,17 @@
+# 一份事后复盘模板
+
+- **期号**: SRE Weekly Issue #125（2018-06-10）
+- **作者**: Michael Kehoe
+- **链接**: http://michael-kehoe.io/post/postmortem-template/
+
+## 简介
+
+我倒是更愿意把它称作"复盘（retrospective）模板"，但不管怎么说，它都相当精妙！
+
+## 正文
+
+我酝酿这个想法已经有一阵子了，真的很想发布自己的事后复盘模板。
+
+空模板可以在这里找到，未来几周我会再补一份填好示例的版本。
+
+有任何反馈，欢迎直接在推特上 @ 我。
--- a/sreweekly/markdown/126/02-10-ways-to-avoid-cdn-issues-at-peak-zh.md
+++ b/sreweekly/markdown/126/02-10-ways-to-avoid-cdn-issues-at-peak-zh.md
@@ -0,0 +1,13 @@
+# 高峰期避免 CDN 问题的 10 个方法
+
+- **期号**: SRE Weekly Issue #126（2018-06-17）
+- **作者**: Hadar Weiss — Peer 5（CDN）
+- **链接**: https://blog.peer5.com/avoid-cdn-issues-at-peak/
+
+## 简介
+
+世界杯季即将到来，这里有些扛住峰值流量的小贴士。我很喜欢第 10 条（压测）里的讨论：想准确地测试你的 CDN，几乎是不可能的事。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/126/03-a-story-of-being-on-call-zh.md
+++ b/sreweekly/markdown/126/03-a-story-of-being-on-call-zh.md
@@ -0,0 +1,28 @@
+# 一个关于值班的故事
+
+- **期号**: SRE Weekly Issue #126（2018-06-17）
+- **作者**: Charity Majors — Honeycomb
+- **链接**: https://www.youtube.com/watch?v=p_paJ2PB4MY
+
+## 简介
+
+这是 Charity Majors 在 Monkigras 2018 上演讲的视频录像。关于如何让值班变得愉快、如何对自己的代码负责，她有很多精彩的观点，包括这句金句：
+
+> 顺便说一句，婴儿是进化工程出来的产物——它们被设计得可爱到让你舍不得下手。你的代码可没有这待遇。
+
+## 正文
+
+关于
+新闻动态
+版权
+联系我们
+创作者
+广告
+开发者
+条款
+隐私
+政策与安全
+YouTube 的工作原理
+试用新功能
+NFL Sunday Ticket
+© 2026 Google LLC
--- a/sreweekly/markdown/126/07-sample-your-traffic-but-keep-the-good-stuff-zh.md
+++ b/sreweekly/markdown/126/07-sample-your-traffic-but-keep-the-good-stuff-zh.md
@@ -0,0 +1,26 @@
+# 给流量采样：但好东西要留住
+
+- **期号**: SRE Weekly Issue #126（2018-06-17）
+- **作者**: Ben Hartshorne — Honeycomb
+- **链接**: https://www.youtube.com/watch?v=oRVy0Y0qcCo
+
+## 简介
+
+套用这场演讲录像里的一句话：让可观测性系统的规模与被观测系统的规模相匹配，极少是正确的做法。要避免这种局面，你就得丢弃一部分事件数据，而不是把所有东西都存下来、建立索引。那么，如何做到这一点，同时还能保持可观测性正常工作呢？
+
+## 正文
+
+关于
+新闻动态
+版权
+联系我们
+创作者
+广告
+开发者
+条款
+隐私
+政策与安全
+YouTube 的工作原理
+试用新功能
+NFL Sunday Ticket
+© 2026 Google LLC
--- a/sreweekly/markdown/126/08-automated-database-deployments-series-kick-off-zh.md
+++ b/sreweekly/markdown/126/08-automated-database-deployments-series-kick-off-zh.md
@@ -0,0 +1,15 @@
+# 自动化数据库部署系列开篇
+
+- **期号**: SRE Weekly Issue #126（2018-06-17）
+- **作者**: Bob Walker — Octopus Deploy
+- **链接**: https://octopus.com/blog/automated-database-deployments-series-kick-off
+
+## 简介
+
+我很期待这个系列会走向何方。数据库变更是巨大的可靠性风险，把它做对至关重要。
+
+## 正文
+
+/blog/automated-database-deployments-series-kick-off/
+
+/blog/why-consider-database-deployment-automation
--- a/sreweekly/markdown/127/06-mysql-high-availability-at-github-zh.md
+++ b/sreweekly/markdown/127/06-mysql-high-availability-at-github-zh.md
@@ -0,0 +1,14 @@
+# GitHub 的 MySQL 高可用方案
+
+- **期号**: SRE Weekly Issue #127（2018-06-24）
+- **作者**: Shlomi Noach — GitHub
+- **链接**: https://githubengineering.com/mysql-high-availability-at-github/
+
+## 简介
+
+文章对他们当前的架构做了出色的介绍，但真正让这篇文章出彩的，是它解释了旧系统哪里出了问题、以及他们为什么要把旧系统整个换掉。
+
+## 正文
+
+正在跳转…
+如果未自动跳转，请点击此处。
--- a/sreweekly/markdown/127/07-automated-database-deployments-iteration-zero-zh.md
+++ b/sreweekly/markdown/127/07-automated-database-deployments-iteration-zero-zh.md
@@ -0,0 +1,16 @@
+# 自动化数据库部署：第零次迭代
+
+- **期号**: SRE Weekly Issue #127（2018-06-24）
+- **作者**: Hen Peretz — BlazeMeter
+- **链接**: https://octopus.com/blog/automated-database-deployments-iteration-zero
+
+## 简介
+
+这篇文章的亮点：对两种自动化数据库迁移技术的优劣做了对比；以及"触手"（tentacle）一词出现的次数多得惊人。
+
+## 正文
+
+正在从
+/blog/automated-database-deployments-iteration-zero/
+跳转到
+/blog/database-deployment-automation-approaches
--- a/sreweekly/markdown/128/06-colm-maccárthaigh-on-twitter-random-number-generation-zh.md
+++ b/sreweekly/markdown/128/06-colm-maccárthaigh-on-twitter-random-number-generation-zh.md
@@ -0,0 +1,19 @@
+# Colm MacCárthaigh 的推文：随机数生成
+
+- **期号**: SRE Weekly Issue #128（2018-07-01）
+- **作者**: Colm MacCárthaigh
+- **链接**: https://twitter.com/colmmacc/status/1012719876706840578
+
+## 简介
+
+> 你写代码时有没有需要生成随机数的场合？不管是掷骰子，还是洗牌，这条推文串就是为你准备的！这事没理由看起来简单或理所当然——连非常有经验的程序员也会重复犯常见的错误。我在学会之前就犯过……
+
+严格来说这和 SRE 关系不大，但话说回来，作者是 Colm MacCárthaigh，他本人和 SRE 大有关系。
+
+## 正文
+
+![@colmmacc](https://pbs.twimg.com/profile_images/696813823584374784/I2mByZE__normal.jpg)
+
+你写代码时有没有需要生成随机数的场合？不管是掷骰子，还是洗牌，这条推文串就是为你准备的！这事没理由看起来简单或理所当然——连非常有经验的程序员也会重复犯常见的错误。我在学会之前就犯过……
+
+[2018 年 6 月 29 日 下午 3:30](https://twitter.com/colmmacc/status/1012719876706840578)
--- a/sreweekly/markdown/128/09-sri-harsha-kalavala-on-twitter-alert-on-support-page-views-zh.md
+++ b/sreweekly/markdown/128/09-sri-harsha-kalavala-on-twitter-alert-on-support-page-views-zh.md
@@ -0,0 +1,20 @@
+# Sri Harsha Kalavala 的推文：给支持页面浏览量设告警
+
+- **期号**: SRE Weekly Issue #128（2018-07-01）
+- **作者**: Sri Harsha Kalavala
+- **链接**: https://twitter.com/harshaunplugged/status/1012765568892485632
+
+## 简介
+
+> 如果你还没有给"支持页面浏览量"设告警，现在就去做吧！！日后你会感谢我的。这是几分钟前我们仪表盘的截图——它直观地展现了用户所受的影响，是对现有监控和告警的补充。……
+
+点击查看图表。监控状态和支持页面浏览量……我们还需要其他监控吗？半开玩笑地说。
+
+## 正文
+
+![@harshaunplugged](https://pbs.twimg.com/profile_images/1043716353352298496/NKxLzKxZ_normal.jpg)
+
+如果你还没有给"支持页面浏览量"设告警，现在就去做吧！！日后你会感谢我的。
+这是几分钟前我们仪表盘的截图——它直观地展现了用户所受的影响，是对现有监控和告警的补充。
+
+[2018 年 6 月 29 日 下午 6:31](https://twitter.com/harshaunplugged/status/1012765568892485632)
--- a/sreweekly/markdown/129/04-a-chaos-engineering-gameday-report-template-zh.md
+++ b/sreweekly/markdown/129/04-a-chaos-engineering-gameday-report-template-zh.md
@@ -0,0 +1,19 @@
+# 一份混沌工程实战演习报告模板
+
+- **期号**: SRE Weekly Issue #129（2018-07-08）
+- **作者**: Michael Kehoe
+- **链接**: http://michael-kehoe.io/post/chaos-gameday-template/
+
+## 简介
+
+几周前，我贴过一份事后复盘模板。这篇是同一个作者写的实战演习（gameday）报告模板。
+
+## 正文
+
+继我的[事后复盘模板文档](https://michael-kehoe.io/post/postmortem-template/)之后，我认为为混沌工程实战演习写一份类似的模板也是明智之举。
+
+空模板可以在这里[找到](https://docs.google.com/document/u/1/d/1hec4i4mp_buLr54Fyu0Kg3GdiUETPDYdzm52k9l03aI/edit#)，未来几周我会再补一份填好示例的版本。
+
+有任何反馈，欢迎直接在推特上 @ [我](https://twitter.com/matrixtek)
+
+最后修改时间：2020 年 4 月 25 日
--- a/sreweekly/markdown/13/02-actionable-alerts-reducing-false-positives-making-on-call-suck-less-vi-zh.md
+++ b/sreweekly/markdown/13/02-actionable-alerts-reducing-false-positives-making-on-call-suck-less-vi-zh.md
@@ -0,0 +1,15 @@
+# 可行动的告警：减少误报，让值班没那么难受——VictorOps
+
+- **期号**: SRE Weekly Issue #13（2016-03-06）
+- **作者**: —
+- **链接**: https://victorops.com/blog/actionable-alerts-cagedata/
+
+## 简介
+
+> 这是来自我们客户 CageData 的支持系统总监 Aaron 的一篇客座文章。他讲的是让告警变得可行动（actionable），以及为什么这很重要。
+
+## 正文
+
+VictorOps 现已更名为 Splunk On-Call——新名字，升级版产品。借助 Splunk On-Call，开发、DevOps 和运维团队可以让值班不那么难受，同时缩短平均确认与恢复宕机的时间。团队能收到上下文丰富的通知，并进行跨职能协作，从而更快、更高效地解决事故、减少停机。利益相关方也能看到关键事故以及为解决问题所采取的步骤。
+
+登录你的 Splunk On-Call 账户、获取用户支持，或探索我们的其他资源以了解更多。
--- a/sreweekly/markdown/130/07-relp-100-cpu-rsyslog-stop-after-start-issue-13-rsyslog-librelp-github-zh.md
+++ b/sreweekly/markdown/130/07-relp-100-cpu-rsyslog-stop-after-start-issue-13-rsyslog-librelp-github-zh.md
@@ -0,0 +1,37 @@
+# relp 100% CPU——rsyslog 启动后停止运行 · Issue #13 · rsyslog/librelp · GitHub
+
+- **期号**: SRE Weekly Issue #130（2018-07-15）
+- **作者**: 坦诚说明：文中提到了我的雇主 Fastly。
+- **链接**: https://github.com/rsyslog/librelp/issues/13
+
+## 简介
+
+这周我乐此不疲地挖出了我们在工作中反复遇到的 Rsyslog 卡死的根源。我找到了原因（socket 写入的过度重试），并整理了一份 bug 报告和一个 pull request。
+
+## 正文
+
+你好，
+
+我遇到的问题：
+
+- 在使用 imrelp 的 rsyslog 服务器上 CPU 达到 100%——而且只是把 imrelp 添加到标准的 Debian Jessie 或 Debian Wheezy 配置里就这样了。
+但问题似乎出在安装了 1.0.0 版 librelp 的客户端上。
+
+这个问题在下面两个链接里有相当详细的描述：
+
+[http://lists.adiscon.net/pipermail/rsyslog/2013-July/033303.html](http://lists.adiscon.net/pipermail/rsyslog/2013-July/033303.html)
+
+[http://bugzilla.adiscon.com/show_bug.cgi?id=208](http://bugzilla.adiscon.com/show_bug.cgi?id=208)
+
+我已经测试了下面的补丁，它不会占用 collector 的 CPU。
+
+[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771218](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771218)
+
+两个问题：
+
+1. 我在别处没有找到针对 librelp 的补丁，如果你认为这个补丁与 bug 208 相关，能否把它附加到该 bug 上？
+2. 是否可以给服务器开发一个补丁，以避免这种行为，或者至少在日志里加上警告？
+
+谢谢，
+
+Daniele
--- a/sreweekly/markdown/131/01-twitter-alicegoldfuss-on-new-ops-zh.md
+++ b/sreweekly/markdown/131/01-twitter-alicegoldfuss-on-new-ops-zh.md
@@ -0,0 +1,21 @@
+# Twitter：@alicegoldfuss 谈新运维
+
+- **期号**: SRE Weekly Issue #131（2018-07-22）
+- **作者**: Alice Goldfuss
+- **链接**: https://mobile.twitter.com/alicegoldfuss/status/1020002647196102656
+
+## 简介
+
+我很喜欢"用兴趣爱好来衡量你在工作中的超载程度"这个点子。另外，Alice 对工作中、尤其是在运维场景下喝酒的坚决反对态度，也必须点个赞。
+
+## 正文
+
+发帖
+登录
+注册
+发帖
+登录
+注册
+发帖
+此帖子来自受保护的账号。
+此帖子来自受保护的账号。
--- a/sreweekly/markdown/132/06-safety-moment-predicting-the-future-zh.md
+++ b/sreweekly/markdown/132/06-safety-moment-predicting-the-future-zh.md
@@ -0,0 +1,27 @@
+# 安全时刻——预测未来！！！！
+
+- **期号**: SRE Weekly Issue #132（2018-07-29）
+- **作者**: Todd Conklin — Pre-Accident Podcast
+- **链接**: https://preaccidentpodcast.podbean.com/e/safety-moment-predicting-the-future/
+
+## 简介
+
+> 我能做些什么，来确保当系统发生故障时，它以尽可能"有效"的方式失败？
+
+## 正文
+
+![安全时刻——预测未来！！！！](https://pbcdn1.podbean.com/imglogo/ep-logo/pbblog733390/Str8conklin.jpg)
+
+2018 年 7 月 25 日
+
+# 安全时刻——预测未来！！！！
+
+收听这期播客。
+
+最佳安全播客、安全计划、安全叙事、调查、人的绩效、安全新思路、卓越运营、韧性工程、安全与韧性激励
+
+去听听吧。
+
+感谢收听，也请告诉你的朋友。我们未来某处再见。
+
+还没有评论。快来抢沙发！
--- a/sreweekly/markdown/133/02-cloud-infrastructure-at-grubhub-zh.md
+++ b/sreweekly/markdown/133/02-cloud-infrastructure-at-grubhub-zh.md
@@ -0,0 +1,13 @@
+# Grubhub 的云基础设施
+
+- **期号**: SRE Weekly Issue #133（2018-08-05）
+- **作者**: William Blackie — Grubhub
+- **链接**: https://bytes.grubhub.com/cloud-infrastructure-at-grubhub-94db998a898a
+
+## 简介
+
+在搭建面向服务的架构的过程中，Grubhub 首先着手开发了"用于构建高可用、分布式服务的基础框架"。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/134/02-how-to-manage-changing-requirements-for-a-high-availability-service-zh.md
+++ b/sreweekly/markdown/134/02-how-to-manage-changing-requirements-for-a-high-availability-service-zh.md
@@ -0,0 +1,13 @@
+# 如何管理高可用服务的需求变更
+
+- **期号**: SRE Weekly Issue #134（2018-08-12）
+- **作者**: Yiwei Liu — Grubhub
+- **链接**: https://bytes.grubhub.com/how-to-manage-changing-requirements-for-a-high-availability-service-4715750576bc
+
+## 简介
+
+我们创造的任何系统，几乎都不可能在整个生命周期里一成不变。那么，如何在不牺牲可靠性的前提下，为系统做改造升级？
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/134/03-glb-github-s-open-source-load-balancer-zh.md
+++ b/sreweekly/markdown/134/03-glb-github-s-open-source-load-balancer-zh.md
@@ -0,0 +1,14 @@
+# GLB：GitHub 的开源负载均衡器
+
+- **期号**: SRE Weekly Issue #134（2018-08-12）
+- **作者**: Theo Julienne — GitHub
+- **链接**: https://githubengineering.com/glb-director-open-source-load-balancer/
+
+## 简介
+
+> 我们之前介绍过 GLB——面向裸机数据中心的可扩展负载均衡方案 […] 今天，我们很高兴分享更多关于负载均衡器设计的细节，并把 GLB Director 作为开源项目发布。
+
+## 正文
+
+正在跳转…
+如果未自动跳转，请点击此处。
--- a/sreweekly/markdown/134/08-john-oliver-viewers-not-hackers-responsible-for-fcc-system-outage-zh.md
+++ b/sreweekly/markdown/134/08-john-oliver-viewers-not-hackers-responsible-for-fcc-system-outage-zh.md
@@ -0,0 +1,27 @@
+# 导致 FCC 系统宕机的是 John Oliver 的观众，不是黑客
+
+- **期号**: SRE Weekly Issue #134（2018-08-12）
+- **作者**: Thomas Barrabi — Fox Business
+- **链接**: https://www.foxbusiness.com/media/john-oliver-viewers-not-hackers-responsible-for-fcc-system-outage
+
+## 简介
+
+FCC 把今年五月的那次宕机归咎于 DDoS。结果发现，那只是海量分布式发来的合法服务请求。
+
+## 正文
+
+# 导致 FCC 系统宕机的是 John Oliver 的观众，不是黑客
+
+根据该机构监察部门（watchdog arm）的说法，导致美国联邦通信委员会（FCC）2017 年 5 月系统宕机的，是 HBO 主持人 John Oliver《上周今夜秀》（Last Week Tonight）节目关心此事的观众，而不是黑客。
+
+作为 FCC 撤销奥巴马时代"网络中立"（net neutrality）法规的直言批评者，Oliver 呼吁观众在 2017 年 5 月 7 日那一期节目播出后，到 FCC 网站发表评论，敦促官员不要执行该计划。Oliver 还搭建了一个网站，将用户重定向到 FCC 的消费者反馈板块。
+
+不久之后，FCC 的评论板块崩溃，FCC 主席 Ajit Pai 将宕机归咎于黑客，声称恶意行为者使用了"分布式拒绝服务"（DDoS）攻击将该功能打下线。然而，FCC 监察长办公室本周公布的调查结果认定，与 Oliver 活动相关的"海量病毒式流量"很可能是原因。
+
+报告称："我们的调查未能证实多次 DDoS 攻击的指控。"报告还指出，在官方"Last Week Tonight"Twitter 账号发布网站链接仅一分钟后，FCC 评论板块的流量就出现了大幅激增。
+
+去年 12 月，FCC 以 3 比 2 的党派投票结果废除了网络中立规则。批评者认为，废除这些规则让互联网服务提供商更容易对竞争对手的内容进行限速或屏蔽，或者向消费者收取更高的高速互联网费用。
+
+Pai 在一份声明中说："对于报告的调查结果，我对 FCC 前首席信息官（CIO）——由前任政府任命、现已离开委员会——就此事向我、我的办公室、国会和美国人民提供不准确的信息深感失望。这完全不可接受。"
+
+John Oliver 和 HBO 的《上周今夜秀》尚未对报告的调查结果作出回应。
--- a/sreweekly/markdown/134/09-you-can-t-debug-systems-with-dashboards-zh.md
+++ b/sreweekly/markdown/134/09-you-can-t-debug-systems-with-dashboards-zh.md
@@ -0,0 +1,13 @@
+# 用仪表盘调试不了系统
+
+- **期号**: SRE Weekly Issue #134（2018-08-12）
+- **作者**: Forrest Brazeal — A Cloud Guru
+- **链接**: https://read.acloud.guru/why-you-can-t-effectively-debug-your-modern-systems-with-dashboards-57fe3ecd26bf
+
+## 简介
+
+这篇对 Charity Majors 的采访里，我最喜欢的部分是（接近结尾处）关于 Serverless 基础设施中如何做运维的讨论。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/136/03-through-a-dashboard-darkly-brain-of-buildchimp-curated-selections-from-zh.md
+++ b/sreweekly/markdown/136/03-through-a-dashboard-darkly-brain-of-buildchimp-curated-selections-from-zh.md
@@ -0,0 +1,17 @@
+# 穿过仪表盘，一片漆黑——Buildchimp 的大脑——来自我脑海深处的声音精选
+
+- **期号**: SRE Weekly Issue #136（2018-08-26）
+- **作者**: John Casey
+- **链接**: https://buildchimp.me/Through-a-Dashboard-Darkly/
+
+## 简介
+
+> 这是一个关于"有缺陷的流程叠加在有缺陷的基础设施之上、却又缺乏支撑决策所需数据"的故事。同时也是一个关于觉醒于这些问题、并谋划出路的故事。
+
+[…]
+
+> 事实证明，单凭推理无法解决复杂应用在生产环境下遇到的那类问题。这类问题几乎总是更难对付——因为它们扛过了你能扔过去的全部测试，依然幸存了下来。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/136/04-simple-hard-metrics-that-help-reduce-mttr-when-looking-for-a-root-caus-zh.md
+++ b/sreweekly/markdown/136/04-simple-hard-metrics-that-help-reduce-mttr-when-looking-for-a-root-caus-zh.md
@@ -0,0 +1,13 @@
+# 有助于定位根因、缩短 MTTR 的简单/硬性指标
+
+- **期号**: SRE Weekly Issue #136（2018-08-26）
+- **作者**: Pavel Trukhanov — okmeter
+- **链接**: https://blog.okmeter.io/simple-hard-metrics-that-help-reduce-mttr-when-looking-for-a-root-cause-637eaf5b3518
+
+## 简介
+
+这是一个关于某种不太常见的故障场景（机房积热事件）的故事，以及如何在不过度增加指标负担的前提下，对这种状况进行监控。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/137/04-we-want-machines-to-be-people-and-people-to-be-machines-what-is-wrong-zh.md
+++ b/sreweekly/markdown/137/04-we-want-machines-to-be-people-and-people-to-be-machines-what-is-wrong-zh.md
@@ -0,0 +1,27 @@
+# 我们想让机器像人，又想让人像机器。我们到底怎么了？
+
+- **期号**: SRE Weekly Issue #137（2018-09-02）
+- **作者**: Todd Conklin — Pre-Accident Podcast
+- **链接**: https://preaccidentpodcast.podbean.com/e/safety-moment-we-want-machines-to-be-people-and-people-to-be-machines-what-is-wrong-with-us/
+
+## 简介
+
+非常值得花两分半钟听一听。
+
+## 正文
+
+![Safety Moment - We want machines to be people and people to be machines.  What is wrong with us?](https://pbcdn1.podbean.com/imglogo/ep-logo/pbblog733390/Str8conklin.jpg)
+
+2018 年 8 月 29 日
+
+# Safety Moment——我们想让机器像人，又想让人像机器。我们到底怎么了？
+
+来听听这期播客吧。
+
+最佳安全播客、安全项目、安全叙事、事故调查、人的表现（Human Performance）、Safety Differently（另一种安全观）、卓越运营、韧性工程（Resilience Engineering）、安全与韧性激励。
+
+听一听吧。
+
+感谢收听，也请告诉你的朋友们。咱们后会有期。
+
+还没有评论。快来抢第一个发言！
--- a/sreweekly/markdown/138/01-096-resilience-engineering-with-john-allspaw-greater-than-code-zh.md
+++ b/sreweekly/markdown/138/01-096-resilience-engineering-with-john-allspaw-greater-than-code-zh.md
@@ -0,0 +1,13 @@
+# 096：与 John Allspaw 谈韧性工程（Resilience Engineering）——Greater Than Code
+
+- **期号**: SRE Weekly Issue #138（2018-09-09）
+- **作者**: Janelle Klein, John Sawers, Rein Henrichs 与 Jessica Kerr，嘉宾 John Allspaw
+- **链接**: https://www.greaterthancode.com/2018/09/05/096-resilience-engineering-with-john-allspaw/
+
+## 简介
+
+这期 Greater Than Code 请来了 John Allspaw，精彩程度和我的预期差不多。几个亮点：与其问事故"是怎么发生的"，不如问"是什么阻止了它变得更糟"；对事故要多问"怎么"、少问"为什么"；人与技术加在一起，才是一个完整的认知系统；怎样才能让自动化成为团队的一员？
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:1032)
--- a/sreweekly/markdown/138/03-colmmacc-on-twitter-shuffle-sharding-zh.md
+++ b/sreweekly/markdown/138/03-colmmacc-on-twitter-shuffle-sharding-zh.md
@@ -0,0 +1,71 @@
+# @colmmacc 在 Twitter 上：shuffle sharding
+
+- **期号**: SRE Weekly Issue #138（2018-09-09）
+- **作者**: Colm MacCárthaigh — AWS（感谢 Thread Reader 提供的串帖汇总）
+- **链接**: https://threadreaderapp.com/thread/1034492056968736768.html?utm_source=last_week_in_AWS&utm_medium=newsletter&utm_campaign=website&utm_source=Last%20Week%20in%20AWS&utm_medium=email
+
+## 简介
+
+Colm MacCárthaigh 解释了 shuffle sharding（洗牌分片）如何像一根由数学构成的魔法杠杆一样提升可靠性。
+
+## 正文
+
+![Profile picture](https://threadreaderapp.com/images/avatars/14340150.jpg)
+
+[@colmmacc](https://twitter.com/colmmacc)
+
+![Profile picture](https://threadreaderapp.com/images/Twitter_Logo_Blue.png)
+
+![](https://pbs.twimg.com/media/DltAuMNUYAEJCIQ.jpg)
+
+![](https://pbs.twimg.com/media/DltBh42U0AAMmPC.jpg)
+
+![](https://pbs.twimg.com/media/DltDnteV4AAbU90.jpg)
+
+![](https://pbs.twimg.com/media/DltD33yUwAEUW0r.jpg)
+
+![](https://pbs.twimg.com/media/DltEIgdUcAAPYNR.jpg)
+
+![](https://pbs.twimg.com/media/DltEYYJVsAA-skb.jpg)
+
+![](https://pbs.twimg.com/media/DltExMVU4AAeuzQ.jpg)
+
+![](https://pbs.twimg.com/media/DltFB1GU0AAOaOr.jpg)
+
+![](https://pbs.twimg.com/media/DltFUTFU8AArQqH.jpg)
+
+![](https://pbs.twimg.com/media/DltFfyOVAAAmLHD.jpg)
+
+![](https://pbs.twimg.com/media/DltGd1YVsAAfiaS.jpg)
+
+![](https://pbs.twimg.com/media/DltGkZNV4AA1B3v.jpg)
+
+![](https://pbs.twimg.com/media/DltGzsTU0AE5ndd.jpg)
+
+![](https://pbs.twimg.com/media/DltHNnpUcAAIA_A.jpg)
+
+![](https://pbs.twimg.com/media/DltHvLsUYAA9qSO.jpg)
+
+![](https://pbs.twimg.com/media/DltIKmiVAAAwN_u.jpg)
+
+![](https://pbs.twimg.com/media/DltItHJUwAAPz86.jpg)
+
+[gist.github.com/colmmacc/4a39a…](https://gist.github.com/colmmacc/4a39a6416d2a58b6c70bc73027bea4dc)。拿 Route 53 的数据试试。Route 53 有 2048 台虚拟名称服务器，每个托管区域（hosted zone）分配 4 台。所以 n = 2048，m = 4。
+
+[github.com/awslabs/route5…](https://github.com/awslabs/route53-infima)
+
+![](https://pbs.twimg.com/media/DltKPTxVsAAQdbp.jpg)
+
+![](https://pbs.twimg.com/media/DltK8nhVAAAVigC.jpg)
+
+[en.wikipedia.org/wiki/Lottery_m…](https://en.wikipedia.org/wiki/Lottery_mathematics)提供了我们如何得出这个等式的良好背景……
+
+![](https://pbs.twimg.com/media/DltL6nmV4AAAdee.jpg)
+
+![](https://pbs.twimg.com/media/DltMSIyUcAA6LqM.jpg)
+
+![](https://pbs.twimg.com/media/DltMc-AU8AAcCWB.jpg)
+
+![](https://pbs.twimg.com/media/DltMur_UwAAeJ0f.jpg)
+
+![](https://pbs.twimg.com/media/DltNCQxUwAAc2xl.jpg)
--- a/sreweekly/markdown/138/08-nova-why-trains-crash-zh.md
+++ b/sreweekly/markdown/138/08-nova-why-trains-crash-zh.md
@@ -0,0 +1,13 @@
+# NOVA——火车为什么相撞
+
+- **期号**: SRE Weekly Issue #138（2018-09-09）
+- **作者**: PBS
+- **链接**: http://www.pbs.org/wgbh/nova/tech/why-trains-crash.html
+
+## 简介
+
+这周我看了这期 Nova（PBS）节目，强烈推荐。它探讨了火车为什么会相撞、以及各国政府正在如何提升安全。上面的链接需要会员才能观看，但你在 Netflix 上也能看到。
+
+## 正文
+
+（该节目已不再提供在线播放。）从脱轨、正面相撞，到公路道口被撞身亡的司机，致命的火车事故每年夺走数十条生命。但铁路到底有多不安全？NOVA 调查了近年来的铁路惨剧，以及有望防止这些事故的火车技术进展，并特别关注了以完美安全纪录著称的日本超高效新干线列车。要迎来一个更安全、更快、更现代、更可靠的铁路旅行的新黄金时代，我们需要付出什么？
--- a/sreweekly/markdown/139/03-checklists-an-operational-gift-zh.md
+++ b/sreweekly/markdown/139/03-checklists-an-operational-gift-zh.md
@@ -0,0 +1,13 @@
+# 清单：一份运维的礼物
+
+- **期号**: SRE Weekly Issue #139（2018-09-16）
+- **作者**: Sri Ray
+- **链接**: https://tech.buzzfeed.com/checklists-an-operational-gift-aaf42cf0be12
+
+## 简介
+
+> 任何生产操作，无论大小，都值得一份清单。同样，任何再紧张的情况，也都能从清单中获益。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/14/05-evolution-of-useful-results-from-anomaly-detection-systems-zh.md
+++ b/sreweekly/markdown/14/05-evolution-of-useful-results-from-anomaly-detection-systems-zh.md
@@ -0,0 +1,27 @@
+# 异常检测系统有用成果的演进
+
+- **期号**: SRE Weekly Issue #14（2016-03-13）
+- **作者**: —
+- **链接**: https://blogs.msdn.microsoft.com/azuresecurity/2016/03/09/evolution-of-useful-results-from-anomaly-detection-systems/
+
+## 简介
+
+说到异常检测，这篇文章指出了现有异常检测系统存在的问题，并描述了成功的系统应该是什么样子。我至今还没见过哪个通用异常检测系统能在可接受的误报率下，比有针对性的专项监控做得更好。
+
+## 正文
+
+注意
+
+访问此页面需要授权。你可以尝试[登录](https://blogs.msdn.microsoft.com)或[更换目录]。
+
+访问此页面需要授权。你可以尝试[更换目录]。
+
+**如果你是在找 MSDN 或 TechNet 博客：请注意 MSDN 和 TechNet 博客站点已经退役，博客内容已迁移并归档至此处**。
+
+## 如何使用本站
+
+归档博客按博客名称首字母的字母顺序分组。从目录（TOC）中选择首字母，即可查看该字母下的完整博客列表。
+
+你也可以在本页右上角的「搜索」框中输入博客名称或博文标题进行搜索。
+
+如有任何问题或疑问，请在[此处](https://github.com/MicrosoftDocs/feedback/issues)分享你的反馈。
--- a/sreweekly/markdown/14/06-2016-cloudendure-dr-survey-zh.md
+++ b/sreweekly/markdown/14/06-2016-cloudendure-dr-survey-zh.md
@@ -0,0 +1,43 @@
+# 2016 年 CloudEndure 灾难恢复调查
+
+- **期号**: SRE Weekly Issue #14（2016-03-13）
+- **作者**: —
+- **链接**: https://www.cloudendure.com/blog/news/disaster-recover-survey-2016/
+
+## 简介
+
+这份上个月发布的调查看上去可能有点意思。不过我不太确定，因为他们的服务器离线了，我取不到内容。哦，真讽刺。
+
+## 正文
+
+![Logo](https://www.cloudendure.com/blog/news/disaster-recover-survey-2016/Skins/Default/Stylesheets/Images/transparent.gif)
+
+            日志控制台（Log Console）
+
+            全部文件（All Files）
+
+                - 全部文件
+
+首页（Home）
+
+                - 目录（Contents）
+
+- 索引（Index）
+
+- 术语表（Glossary）
+
+- 浏览（Browse）
+
+- 社区（Community）
+
+- 搜索筛选（Search Filters）
+
+ of 
+
+            创建档案（Create Profile）
+
+                    邮件通知（Email Notifications）
+
+                    当……时，我想收到一封邮件
+
+            一封用于验证新档案的邮件已发送。请在提交信息之前填妥所有必填字段。
--- a/sreweekly/markdown/140/02-linux-4-19-rc4-released-an-apology-and-a-maintainership-note-zh.md
+++ b/sreweekly/markdown/140/02-linux-4-19-rc4-released-an-apology-and-a-maintainership-note-zh.md
@@ -0,0 +1,25 @@
+# Linux 4.19-rc4 发布，一封道歉信，以及维护者说明
+
+- **期号**: SRE Weekly Issue #140（2018-09-23）
+- **作者**: Linus Torvalds
+- **链接**: https://lore.kernel.org/lkml/CA+55aFy+Hv9O5citAawS+mVZO+ywCKd9NQ2wxUmGsz9ZJzqgJQ@mail.gmail.com/
+
+## 简介
+
+本周，Linus Torvalds 因一封为自己不专业行为道歉并承诺改进的电子邮件而掀起波澜。
+
+## 正文
+
+# 确认你不是机器人！
+
+![](https://lore.kernel.org/.within.website/x/cmd/anubis/static/img/pensive.webp?cacheBuster=v1.26.2)
+
+加载中……
+
+你会看到这个页面，是因为本网站的管理员部署了 Anubis，用来保护服务器免受 AI 公司大肆抓取网站的侵害。这种抓取确实会导致网站宕机，让所有人都无法访问其资源。
+
+Anubis 是一种折中方案。Anubis 采用了一种类似 Hashcash 的工作量证明（Proof-of-Work）机制——Hashcash 最初就是为减少垃圾邮件而提出的工作量证明方案。其思路是：在个体规模下，额外的负载可以忽略不计；但在批量抓取者的规模下，成本就会累积起来，让抓取变得昂贵得多。
+
+归根结底，这是一个过渡性的解决方案，以便把更多时间花在指纹识别和识别无头浏览器（例如通过它们的字体渲染方式）上，从而不必向那些更可能是真实用户的访问者展示工作量证明挑战页面。
+
+请注意，Anubis 需要用到现代 JavaScript 特性，而 JShelter 之类的插件会禁用这些特性。请针对本域名禁用 JShelter 或其他类似插件。
--- a/sreweekly/markdown/141/05-upgrading-github-from-rails-3-2-to-5-2-zh.md
+++ b/sreweekly/markdown/141/05-upgrading-github-from-rails-3-2-to-5-2-zh.md
@@ -0,0 +1,14 @@
+# 把 GitHub 从 Rails 3.2 升级到 5.2
+
+- **期号**: SRE Weekly Issue #141（2018-09-30）
+- **作者**: Eileen Uchitelle — GitHub
+- **链接**: https://githubengineering.com/upgrading-github-from-rails-3-2-to-5-2/
+
+## 简介
+
+GitHub 使用了一种创新的技术，在升级应用以支持 Rails 5.2 的过程中，避免了长期维护一条分叉出来的代码分支。
+
+## 正文
+
+正在跳转…
+如果未自动跳转，请点击此处。
--- a/sreweekly/markdown/143/05-preliminary-report-pipeline-over-pressure-of-a-columbia-gas-of-massach-zh.md
+++ b/sreweekly/markdown/143/05-preliminary-report-pipeline-over-pressure-of-a-columbia-gas-of-massach-zh.md
@@ -0,0 +1,83 @@
+# 初步报告：马萨诸塞州哥伦比亚天然气公司低压天然气配送系统超压
+
+- **期号**: SRE Weekly Issue #143（2018-10-14）
+- **作者**: US National Transportation Safety Board (NTSB)
+- **链接**: https://www.ntsb.gov/investigations/AccidentReports/Pages/PLD18MR003-preliminary-report.aspx
+
+## 简介
+
+即使只是一份初步报告，关于上个月（美国）马萨诸塞州那系列燃气爆炸的成因，也有很多值得细细消化的内容。我觉得自己经历过有着类似诱因的事故。
+
+## 正文
+
+调查
+调查流程
+调查报告
+调查档案
+调查办公室
+安全建议
+安全研究
+事故数据
+统计回顾——航空
+海事安全数据仪表盘
+安全研究报告
+新闻与活动
+活动
+新闻中心
+官方证词
+国会与监管往来
+倡导
+安全警报
+安全问题
+倡导活动
+家属援助
+幸存者、家属与朋友
+响应社区
+关于我们
+历史
+委员会
+组织机构
+FOIA
+法律
+就业
+采购信息
+预算与绩效报告
+调查
+调查流程
+调查报告
+调查档案
+调查办公室
+安全建议
+安全研究
+事故数据
+统计回顾——航空
+海事安全数据仪表盘
+安全研究报告
+新闻与活动
+活动
+新闻中心
+官方证词
+国会与监管往来
+倡导
+安全警报
+安全问题
+倡导活动
+家属援助
+幸存者、家属与朋友
+响应社区
+关于我们
+历史
+委员会
+组织机构
+FOIA
+法律
+就业
+采购信息
+预算与绩效报告
+首页
+页面未找到
+页面未找到
+页面内容
+您要找的页面不存在。
+请检查 URL 中是否有拼写错误，或
+前往网站首页
--- a/sreweekly/markdown/144/02-resilience-weekly-zh.md
+++ b/sreweekly/markdown/144/02-resilience-weekly-zh.md
@@ -0,0 +1,13 @@
+# Resilience Weekly
+
+- **期号**: SRE Weekly Issue #144（2018-10-21）
+- **作者**: Thai Wood
+- **链接**: https://resilienceweekly.com/?utm_source=monitoringweekly
+
+## 简介
+
+哦，新周刊！这份专门聚焦韧性话题。看起来每周只有寥寥几篇文章，但每篇都有深度的摘要。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/144/03-mo-developers-mo-problems-how-serverless-has-trouble-with-teams-zh.md
+++ b/sreweekly/markdown/144/03-mo-developers-mo-problems-how-serverless-has-trouble-with-teams-zh.md
@@ -0,0 +1,45 @@
+# 开发者越多，问题越多：Serverless 在团队协作上的麻烦
+
+- **期号**: SRE Weekly Issue #144（2018-10-21）
+- **作者**: Toby Fee — jaxenter
+- **链接**: https://jaxenter.com/how-serverless-trouble-teams-150705.html
+
+## 简介
+
+这篇文章以一个虚构（？）的案例开场，讲述了在 serverless 环境中团队之间互相踩脚时可能发生的某种故障。随后文章讨论了应对这类问题的技术，包括精细的权限管理。
+
+## 正文
+
+{{article.subtitle}}
+
+{{article.abstract | truncate(300) }}
+
+{{article.abstract | truncate(200) }}
+
+{{isSecondAdsSet}}
+
+                    brand id {{brandid}}
+
+apploaded {{apploaded}}
+
+loading {{loading}}
+
+everLoadedData {{everLoadedData}}
+
+page {{page}}
+
+page_size {{page_size}}
+
+loadMorePossible {{loadMorePossible}}
+
+									＼立即抢购！＼用 Fullstack 会员让你的技术生涯
+更上一层楼！
+
+				
+更上一层楼！
+
+									＼使用优惠码 BTS24 立减 $20
+（全年会员）
+
+				
+（全年会员）
--- a/sreweekly/markdown/145/01-to-err-is-human-zh.md
+++ b/sreweekly/markdown/145/01-to-err-is-human-zh.md
@@ -0,0 +1,16 @@
+# 人非圣贤，孰能无过
+
+- **期号**: SRE Weekly Issue #145（2018-10-28）
+- **作者**: Mara Schmid — Blue Skies Magazine
+- **链接**: https://blueskiesmag.com/2018/09/26/to-err-is-human/
+
+## 简介
+
+一篇探讨"调查飞行运动（为安全起见给出定义）事故时如何看穿人为失误"的文章，借鉴了 Don Norman 的著作。特别强调了"手误（slip）"与"过错（mistake）"的区别：
+
+> "手误在熟练者身上发生的频率，往往高于新手
+[…]
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/146/02-applying-humanops-to-on-call-zh.md
+++ b/sreweekly/markdown/146/02-applying-humanops-to-on-call-zh.md
@@ -0,0 +1,13 @@
+# 把 HumanOps 应用到值班上
+
+- **期号**: SRE Weekly Issue #146（2018-11-04）
+- **作者**: David Mytton — StackPath
+- **链接**: https://blog.stackpath.com/applying-humanops-to-on-call?utm_campaign=Resilience%20Weekly&utm_medium=email&utm_source=Revue%20newsletter
+
+## 简介
+
+一些关于如何设计值班、让身处其中的人得到公平对待的建议，其中不乏"半夜被叫醒后自动放一天假"这样的金点子。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/147/06-how-automatic-root-cause-analysis-works-zh.md
+++ b/sreweekly/markdown/147/06-how-automatic-root-cause-analysis-works-zh.md
@@ -0,0 +1,13 @@
+# 自动根因分析是如何工作的
+
+- **期号**: SRE Weekly Issue #147（2018-11-11）
+- **作者**: Steve Waterworth — Instana
+- **链接**: https://www.instana.com/blog/how-automatic-root-cause-analysis-works/
+
+## 简介
+
+这个思路很巧妙。通过把基础设施各组件之间的关系建模，当所有东西同时开始告警时，你就能推断出最可能是哪个组件的问题。注：这篇文章明显是为 Instana 的产品量身定做的。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)
--- a/sreweekly/markdown/15/04-true-story-on-call-doesn-t-have-to-suck-zh.md
+++ b/sreweekly/markdown/15/04-true-story-on-call-doesn-t-have-to-suck-zh.md
@@ -0,0 +1,15 @@
+# 真实故事：值班不一定要那么难受
+
+- **期号**: SRE Weekly Issue #15（2016-03-20）
+- **作者**: —
+- **链接**: https://victorops.com/blog/on-call-doesnt-suck/
+
+## 简介
+
+一位工程师写给同行的"学会从容对待值班"指南，还有一些达成这一目标的技巧。
+
+## 正文
+
+VictorOps 现已更名为 Splunk On-Call——新名字，升级版产品。借助 Splunk On-Call，开发、DevOps 和运维团队可以让值班不那么难受，同时缩短平均确认与恢复宕机的时间。团队能收到上下文丰富的通知，并进行跨职能协作，从而更快、更高效地解决事故、减少停机。利益相关方也能看到关键事故以及为解决问题所采取的步骤。
+
+登录你的 Splunk On-Call 账户、获取用户支持，或探索我们的其他资源以了解更多。
--- a/sreweekly/markdown/151/02-working-with-aws-limits-zh.md
+++ b/sreweekly/markdown/151/02-working-with-aws-limits-zh.md
@@ -0,0 +1,21 @@
+# 与 AWS 限额打交道
+
+- **期号**: SRE Weekly Issue #151（2018-12-09）
+- **作者**: Bakha Nurzhanov — RealSelf
+- **链接**: https://www.awsadvent.com/2018/12/07/working-with-aws-limits/
+
+## 简介
+
+限额和配额真能毁掉你的一整天。而正如我们从 RealSelf 这起事故中学到的，在变更进入生产环境之前就预判到限额耗尽，往往难上加难。
+
+## 正文
+
+搜索
+2018
+2016
+菜单
+与 AWS 限额打交道
+作者：Bakha Nurzhanov
+2018 年 12 月 7 日
+2018
+0
--- a/sreweekly/markdown/151/06-reasons-to-scale-horizontally-zh.md
+++ b/sreweekly/markdown/151/06-reasons-to-scale-horizontally-zh.md
@@ -0,0 +1,13 @@
+# 横向扩展的理由
+
+- **期号**: SRE Weekly Issue #151（2018-12-09）
+- **作者**: Sean T. Allen — Wallaroo Labs
+- **链接**: https://blog.wallaroolabs.com/2018/11/horizontal-scaling-reasons/
+
+## 简介
+
+看到这个标题，我心想："呃，因为横向扩展更好？"但这篇文章还是值得一读——它把横向扩展与纵向扩展讲得清楚透彻，包括什么时候该选哪一种，以及为什么横向扩展很难。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/153/01-110-human-incident-response-with-courtney-eckhardt-greater-than-code-zh.md
+++ b/sreweekly/markdown/153/01-110-human-incident-response-with-courtney-eckhardt-greater-than-code-zh.md
@@ -0,0 +1,13 @@
+# 110：与 Courtney Eckhardt 谈人性化事故响应（Human Incident Response）——Greater Than Code
+
+- **期号**: SRE Weekly Issue #153（2018-12-23）
+- **作者**: Mandy Moore（摘要）；嘉宾主持 John K. Sawers、Sam Livingston-Gray、Jamey Hampton 与 Coraline Ada Ehmke；嘉宾 Courtney Eckhardt
+- **链接**: https://www.greaterthancode.com/2018/12/19/110-human-incident-response-with-courtney-eckhardt/
+
+## 简介
+
+在这期播客里，Courtney Eckhardt 和嘉宾团队把事故响应、复盘、防御心理、无指责文化、社会正义等一大堆引人入胜的话题聊了个遍。非常值得一听。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:1032)
--- a/sreweekly/markdown/154/03-i-m-john-allspaw-ask-me-anything-about-incident-analysis-and-postmorte-zh.md
+++ b/sreweekly/markdown/154/03-i-m-john-allspaw-ask-me-anything-about-incident-analysis-and-postmorte-zh.md
@@ -0,0 +1,19 @@
+# 我是 John Allspaw，关于事故分析与事后复盘，尽管问我
+
+- **期号**: SRE Weekly Issue #154（2019-01-06）
+- **作者**: John Allspaw（以及众多评论者）
+- **链接**: https://community.atlassian.com/t5/Jira-Ops-questions/I-m-John-Allspaw-Ask-Me-Anything-about-incident-analysis-and/qaq-p/957084
+
+## 简介
+
+光看标题，你就知道它有多精彩了。我原本以为这是视频或音频形式的 AMA，一直在等录像发布。结果他是在评论区里逐条回答那些精彩问题的，而且每一条回答都像一篇精心打磨的文章。
+
+## 正文
+
+您需要启用 JavaScript 才能使用本页面。
+
+我们尝试加载脚本，但出了点问题。
+
+请确认您的网络设置允许您从以下域名加载脚本：
+
+https://id-frontend.prod-east.frontend.public.atl-paas.net
--- a/sreweekly/markdown/154/04-sarah-mei-on-twitter-compensation-for-on-call-zh.md
+++ b/sreweekly/markdown/154/04-sarah-mei-on-twitter-compensation-for-on-call-zh.md
@@ -0,0 +1,21 @@
+# Sarah Mei 的推文：值班的报酬
+
+- **期号**: SRE Weekly Issue #154（2019-01-06）
+- **作者**: Sarah Mei
+- **链接**: https://twitter.com/sarahmei/status/1078475018294616065
+
+## 简介
+
+> 我对值班的根本意见是：比起雇主的网站是否在线，我更在乎自己的个人生活和健康。我想所有人都是这样！那么……我们到底为什么要忍受值班？
+
+凡是正在值班、或者管理值班人员的人，都该读读这条。
+
+## 正文
+
+![@sarahmei](https://pbs.twimg.com/profile_images/900926526182445058/qOi3HTwf_normal.jpg)
+
+我对值班的根本意见是：比起雇主的网站是否在线，我更在乎自己的个人生活和健康。
+我想所有人都是这样！所以……我们到底为什么要忍受值班？🤔
+也许"劳动者团结"这回事确实有点道理
+
+[2018 年 12 月 28 日 凌晨 2:17](https://twitter.com/sarahmei/status/1078475018294616065)
--- a/sreweekly/markdown/155/03-devops-discussions-postmortem-chat-part-1-youtube-zh.md
+++ b/sreweekly/markdown/155/03-devops-discussions-postmortem-chat-part-1-youtube-zh.md
@@ -0,0 +1,26 @@
+# DevOps 讨论：事后复盘闲聊——第 1 部分（YouTube）
+
+- **期号**: SRE Weekly Issue #155（2019-01-13）
+- **作者**: 注：其中一位嘉宾是我的同事，同在 Fastly 工作。Jessica DeVita — Microsoft，与 Duck Lawn（Pushpay）、Tom Griffin（Pushpay）、Sue Allspaw Pomeroy（Fastly）、John Allspaw（Adaptive Capacity Labs）和 Richard Cook 博士（Adaptive Capacity Labs）
+- **链接**: https://www.youtube.com/watch?v=TkA6u8qEugc&feature=youtu.be
+
+## 简介
+
+这是微软主持的一场关于事故复盘分析的扣人心弦的讨论。整场讨论都强调从事故中学习，而不是仅仅列出一串整改行动项。
+
+## 正文
+
+关于
+新闻动态
+版权
+联系我们
+创作者
+广告
+开发者
+条款
+隐私
+政策与安全
+YouTube 的工作原理
+试用新功能
+NFL Sunday Ticket
+© 2026 Google LLC
--- a/sreweekly/markdown/155/04-an-agile-sre-meeting-plan-zh.md
+++ b/sreweekly/markdown/155/04-an-agile-sre-meeting-plan-zh.md
@@ -0,0 +1,13 @@
+# 一份敏捷 SRE 会议计划
+
+- **期号**: SRE Weekly Issue #155（2019-01-13）
+- **作者**: Dave Mangot
+- **链接**: https://tech.mangot.com/blog/2019/01/09/an-agile-sre-meeting-plan/
+
+## 简介
+
+如果你正在寻找一份如何组织你的 SRE 组织会议的蓝图，这是一份很棒的参考资料。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/156/03-sre-survey-2019-zh.md
+++ b/sreweekly/markdown/156/03-sre-survey-2019-zh.md
@@ -0,0 +1,15 @@
+# 2019 年 SRE 调查
+
+- **期号**: SRE Weekly Issue #156（2019-01-20）
+- **作者**: Catchpoint
+- **链接**: http://www.sresurvey2019.com/
+
+## 简介
+
+和去年一样，只要你参加调查，Catchpoint 就会向慈善机构捐出 5 美元！
+
+> 今年我们又回来了，这次的重点是宕机和事故。事故对组织以及参与响应的个人有什么影响？这种影响在不同行业、不同组织之间又有怎样的差异？
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:1032)
--- a/sreweekly/markdown/156/04-the-myth-of-the-server-s-terrible-horrible-no-good-very-bad-day-zh.md
+++ b/sreweekly/markdown/156/04-the-myth-of-the-server-s-terrible-horrible-no-good-very-bad-day-zh.md
@@ -0,0 +1,33 @@
+# “服务器糟糕透顶的一天”之迷思
+
+- **期号**: SRE Weekly Issue #156（2019-01-20）
+- **作者**: Arya Asemanfar — LightStep
+- **链接**: https://lightstep.com/blog/myth-server-bad-day-latency/
+
+## 简介
+
+> 你完全可以做得比“服务器不高兴了”更好。要留意这类说法。它通常是一个很好的学习机会，或者至少是补齐一些可观测性（instrumentation）空白的良机。
+
+## 正文
+
+### 让我们一起互联
+
+加入我们，让我们的百万会员社区更加出色。创建免费账户，让世界对每个人都运转得更好。
+
+[加入社区](https://lightstep.com/community/s/plugins/common/feature/oidcss/sso_login_redirect/providerid/default?referer=https%3A%2F%2Fwww.servicenow.com%2Fcommunity%2Fcloud-observability%2Fct-p%2Fcloud-observability)
+
+获得洞察，快速发现并响应云原生与单体应用的变化
+
+订阅
+
+你在 ServiceNow 之旅中取得成功所需的一切资源
+
+这些资源为你介绍产品，并为实施做好准备。
+
+清单、指南与最佳实践，用于准备和规划配置与上线。
+
+上线之后，通过这些洞察了解如何从你的投资中获得最大价值。
+
+你成功了！现在，学习如何将云可观测性（Cloud Observability）提升到新高度。
+
+在你需要的时候，得到你需要的答案。
--- a/sreweekly/markdown/157/02-survey-on-call-compensation-in-tech-it-zh.md
+++ b/sreweekly/markdown/157/02-survey-on-call-compensation-in-tech-it-zh.md
@@ -0,0 +1,15 @@
+# [调查] 科技/IT 行业的值班薪酬
+
+- **期号**: SRE Weekly Issue #157（2019-01-27）
+- **作者**: Chris Evans 与 Spike Lindsey
+- **链接**: https://docs.google.com/forms/d/e/1FAIpQLSd1bXweEUs2OHpBccKaXrj1hvvInGgbW8JRJEA8Lu-EnGBBpQ/viewform
+
+## 简介
+
+这两位发起了一份调查，收集 IT 行业是否有、以及如何为值班提供报酬的信息。这个话题在过去两年里热度渐涨，我已经等不及想看调查结果了。请花点时间填一下问卷。
+
+## 正文
+
+你的值班薪酬是多少？*
+
+请结合你上面填写的周期和币种来回答——例如，如果你填的是"按天"和"EUR"，那么这里填 100 就意味着每天 100 欧元。如果你的费率有波动（比如周末/节假日费率更高），请给出一个大致的平均值，并在下一节给我们留言。如果值班报酬已包含在基本工资中、或者属于更复杂的安排，请填 0，并在下一节留言说明。
--- a/sreweekly/markdown/157/07-what-does-a-site-reliability-engineer-do-zh.md
+++ b/sreweekly/markdown/157/07-what-does-a-site-reliability-engineer-do-zh.md
@@ -0,0 +1,15 @@
+# 站点可靠性工程师（SRE）是做什么的？
+
+- **期号**: SRE Weekly Issue #157（2019-01-27）
+- **作者**: Sylvia Fronczak — Scalyr
+- **链接**: https://blog.scalyr.com/2019/01/site-reliability-engineer/
+
+## 简介
+
+如果你是刚接触这个领域的新人，这是一篇不错的入门介绍。
+
+## 正文
+
+SentinelOne AI SIEM 是日志分析与威胁检测在 SentinelOne 平台上的下一代演进。它将 DataSet 广为人知的高速摄取与查询能力，与 AI 驱动的检测、关联和响应能力结合在一起。
+
+作为 DataSet 客户，你早已熟悉支撑 AI SIEM 的性能与规模。如果你有兴趣了解扩展后的平台能为你的团队带来什么，请联系你的客户经理，或在此了解更多。[https://www.sentinelone.com/platform/ai-siem/](https://www.sentinelone.com/platform/ai-siem/)
--- a/sreweekly/markdown/158/01-accident-case-study-traffic-pattern-tragedy-zh.md
+++ b/sreweekly/markdown/158/01-accident-case-study-traffic-pattern-tragedy-zh.md
@@ -0,0 +1,28 @@
+# 事故案例分析：空中交通模式悲剧
+
+- **期号**: SRE Weekly Issue #158（2019-02-03）
+- **作者**: US Air Safety Institute
+- **链接**: https://www.youtube.com/watch?v=mf3xhjXl454&feature=youtu.be
+
+## 简介
+
+这起航空事故分析听起来令人脊背发凉，同时也极具教育意义。当你一路听下去，会越来越清楚地意识到：那位飞行员正遭受着信息过载。作为事件指挥官，牢记这里的教训是明智的。
+
+听完上面这段录音后，我彻底上瘾了，又接连听了一个又一个案例分析。这里还有另一个发人深省的：真实飞行员故事：从失误到救援。
+
+## 正文
+
+关于
+新闻动态
+版权
+联系我们
+创作者
+广告
+开发者
+条款
+隐私
+政策与安全
+YouTube 的工作原理
+试用新功能
+NFL Sunday Ticket
+© 2026 Google LLC
--- a/sreweekly/markdown/159/03-the-new-systems-engineer-zh.md
+++ b/sreweekly/markdown/159/03-the-new-systems-engineer-zh.md
@@ -0,0 +1,13 @@
+# 新一代系统工程师
+
+- **期号**: SRE Weekly Issue #159（2019-02-10）
+- **作者**: Matt Ouille
+- **链接**: https://mattouille.com/articles/2019-01/the-new-systems-engineer/
+
+## 简介
+
+无论你是否赞同这篇文章对"系统工程师"（或 SRE，抑或任何相关头衔）的这次定义尝试，它都值得你思考和讨论。我们这个领域发展得太快，头衔本身就是个移动靶。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/16/07-an-update-on-this-week-hipchat-blog-zh.md
+++ b/sreweekly/markdown/16/07-an-update-on-this-week-hipchat-blog-zh.md
@@ -0,0 +1,13 @@
+# 本周情况更新——HipChat 博客
+
+- **期号**: SRE Weekly Issue #16（2016-03-26）
+- **作者**: —
+- **链接**: https://blog.hipchat.com/2016/03/18/update-this-week/#update
+
+## 简介
+
+Atlassian 就上周的不稳定事件发布了一篇详尽、细致的事后复盘。主要原因之一是 VPC 里一个 NAT 服务过载，而他们客户端的激进重试又进一步加重了这个问题。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: _ssl.c:1015: The handshake operation timed out
--- a/sreweekly/markdown/160/05-mipsytipsy-on-twitter-what-to-alert-on-zh.md
+++ b/sreweekly/markdown/160/05-mipsytipsy-on-twitter-what-to-alert-on-zh.md
@@ -0,0 +1,21 @@
+# @mipsytipsy 在 Twitter 上：该告警什么
+
+- **期号**: SRE Weekly Issue #160（2019-02-17）
+- **作者**: Charity Majors（Liz Fong-Jones 在回复中）
+- **链接**: https://twitter.com/mipsytipsy/status/1096278212257054720
+
+## 简介
+
+> 现在有一种新兴共识：只对用户可见的故障进行告警。可另一方面，我们无疑需要提前了解并应对那些用户还没注意到的情况——比如缓存淘汰率过高。这两者该如何调和？
+
+这里面藏着一个真正的瑰宝，绝对值得一读。
+
+## 正文
+
+![@mipsytipsy](https://pbs.twimg.com/profile_images/1576759705933819904/iDotz1Gw_normal.jpg)
+
+这让我想起 [@chimeracoder](https://x.com/chimeracoder) 刚才问过的问题。现在有一种新兴共识：只对用户可见的故障进行告警。可另一方面，我们无疑需要提前了解并应对那些用户还没注意到的情况——比如缓存淘汰率过高。这两者该如何调和？
+
+[2019 年 2 月 15 日凌晨 5:21](https://twitter.com/mipsytipsy/status/1096278212257054720)
+
+[San Francisco, CA](https://twitter.com/places/5a110d312052166f)
--- a/sreweekly/markdown/161/02-accident-case-study-in-too-deep-youtube-zh.md
+++ b/sreweekly/markdown/161/02-accident-case-study-in-too-deep-youtube-zh.md
@@ -0,0 +1,26 @@
+# 事故案例分析：陷得太深（YouTube）
+
+- **期号**: SRE Weekly Issue #161（2019-02-24）
+- **作者**: Air Safety Institute
+- **链接**: https://youtu.be/W0lWsqAwYwY
+
+## 简介
+
+我对飞行事故案例分析依旧上瘾。在这个案例里，任务固着和犹豫不决酿成了灾难。
+
+## 正文
+
+关于
+新闻动态
+版权
+联系我们
+创作者
+广告
+开发者
+条款
+隐私
+政策与安全
+YouTube 的工作原理
+试用新功能
+NFL Sunday Ticket
+© 2026 Google LLC
--- a/sreweekly/markdown/161/04-the-on-call-compensation-survey-2019-oncall-wtf-zh.md
+++ b/sreweekly/markdown/161/04-the-on-call-compensation-survey-2019-oncall-wtf-zh.md
@@ -0,0 +1,13 @@
+# 2019 年值班薪酬调查｜oncall.wtf
+
+- **期号**: SRE Weekly Issue #161（2019-02-24）
+- **作者**: Chris Evans 与 Spike Lindsey
+- **链接**: https://oncall.wtf/articles/2019-02/on-call-survey-2019
+
+## 简介
+
+几周前，我贴过一份关于值班薪酬的调查链接。这是对调查结果的分析，另外附上一些原始数据，供你想自己折腾时使用。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/162/03-how-to-avoid-catastrophe-zh.md
+++ b/sreweekly/markdown/162/03-how-to-avoid-catastrophe-zh.md
@@ -0,0 +1,16 @@
+# 如何避免灾难
+
+- **期号**: SRE Weekly Issue #162（2019-03-03）
+- **作者**: Catherine H. Tinsley、Robin L. Dillon 与 Peter M. Madsen — Harvard Business Review
+- **链接**: https://hbr.org/2011/04/how-to-avoid-catastrophe
+
+## 简介
+
+如何避免灾难：重视险情。这篇文章提出了一个极具说服力的观点——我们必须有意识地努力去关注险情，并且解释了认知偏误是如何让我们恰好做出相反举动的。
+
+## 正文
+
+## 摘要
+
+转载：R1104G 大多数商业失败——比如工程灾难、产品故障和公关危机——都会有险情作为前兆
+大多数人以为"险情"是那种幸免于难的惊险时刻——比如消防员在建筑坍塌前一刻逃出火场，或者龙卷风奇迹般地从沿路小镇绕开。这类事件是罕见的死里逃生，让我们惊魂未定、急于寻找经验教训。
--- a/sreweekly/markdown/162/05-learning-from-organizational-incidents-resilience-engineering-for-high-zh.md
+++ b/sreweekly/markdown/162/05-learning-from-organizational-incidents-resilience-engineering-for-high-zh.md
@@ -0,0 +1,13 @@
+# 从组织事故中学习：高风险流程环境中的韧性工程
+
+- **期号**: SRE Weekly Issue #162（2019-03-03）
+- **作者**: Thai Wood（评述 Stefanie Huber、Ivette van Wijgerden、Arjan de Witt 和 Sidney W.A. Dekker 合著的一篇论文）
+- **链接**: https://www.getrevue.co/profile/resilience/issues/resilience-roundup-learning-from-organizational-incidents-resilience-engineering-for-high-risk-process-environments-issue-22-160719
+
+## 简介
+
+一家有百年历史的化工公司，一直以为自己有着极佳的安全记录。结果发现，大家只是把事故当成了"家常便饭"，干脆就不上报了。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/sreweekly/markdown/163/01-three-analytical-traps-in-accident-investigation-youtube-7-36-zh.md
+++ b/sreweekly/markdown/163/01-three-analytical-traps-in-accident-investigation-youtube-7-36-zh.md
@@ -0,0 +1,30 @@
+# 事故调查中的三个分析陷阱（YouTube，7:36）
+
+- **期号**: SRE Weekly Issue #163（2019-03-10）
+- **作者**: Johan Bergström 博士 — 隆德大学
+- **链接**: https://www.youtube.com/watch?v=TqaFT-0cY7U
+
+## 简介
+
+这个视频以 NTSB 一份飞机坠毁报告为案例，讲了我们做事故复盘时最容易掉进的三个陷阱：
+
+> 反事实推理（Counterfactual reasoning）；规范性语言（Normative language）；机械论推理（Mechanistic reasoning）
+
+我想把这条视频列为所有复盘参与者的必看材料。
+
+## 正文
+
+关于
+新闻动态
+版权
+联系我们
+创作者
+广告
+开发者
+条款
+隐私
+政策与安全
+YouTube 的工作原理
+试用新功能
+NFL Sunday Ticket
+© 2026 Google LLC
--- a/sreweekly/markdown/164/05-shift-changes-updates-and-the-on-call-architecture-in-space-shuttle-mi-zh.md
+++ b/sreweekly/markdown/164/05-shift-changes-updates-and-the-on-call-architecture-in-space-shuttle-mi-zh.md
@@ -0,0 +1,14 @@
+# 航天飞机任务控制中心的换班、交接与值班架构
+
+- **期号**: SRE Weekly Issue #164（2019-03-17）
+- **作者**: Thai Wood — Resilience Roundup（摘要）
+Emily S Patterson 与 David D Woods — 俄亥俄州立大学（原文）
+- **链接**: https://www.getrevue.co/profile/resilience/issues/resilience-roundup-shift-changes-updates-and-the-on-call-architecture-in-space-shuttle-mission-control-issue-24-163997?utm_campaign=Issue&utm_content=view_in_browser&utm_medium=email&utm_source=Resilience+Roundup
+
+## 简介
+
+> 本周我带来一篇关于值班、以及 NASA 如何做值班的文章。文中许多结论，对任何有值班经验的人来说或许都不意外，但我认为，NASA 让这套系统运转起来的方法，有很多值得我们学习的地方。
+
+## 正文
+
+> ⚠️ 抓取失败：URLError: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1032)
--- a/Show More
+++ b/Show More