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

This commit is contained in:
2026-09-15 21:13:34 +08:00
parent 529b2677e7
commit 836fa3b04d
1205 changed files with 16204 additions and 1 deletions

View File

@@ -0,0 +1,21 @@
# 新的高可用性检查清单现已可用 | Azure
- **期号**: SRE Weekly Issue #29(2016-07-03)
- **作者**: —
- **链接**: https://blogs.msdn.microsoft.com/azuregov/2016/06/30/new-high-availability-checklist-now-available/
## 简介
这份检查清单面向 Azure 上的部署,但其中许多条目可以推广应用到部署在其他环境的基础设施。
## 正文
我们很高兴地宣布,我们发布了一份新的[高可用性检查清单](https://azure.microsoft.com/en-us/documentation/articles/resiliency-high-availability-checklist/),帮助你提高应用程序在 Azure 中的弹性和可用性。
我们知道正常运行时间对你很重要,Azure 也提供了很好的工具和服务来帮助你提高可用性。然而,我们注意到许多人还没有充分利用 Azure 的这些优势。Azure 的弹性是一种共担责任(shared responsibility)模式。因此,我们创建了这份检查清单,以提供在 Azure 中提高应用程序可用性的通用方法,涵盖最佳实践、工具和技术。这些建议既来自良好的设计模式,也来自我们与在 Azure 上构建应用的客户打交道的架构师们的经验。
这份清单的一个新增内容是:对每条列出的建议,都附上一段简短说明——不遵循会怎样。在与使用 Azure 的客户讨论最佳实践时,我们经常听到的问题是:"如果我不遵循这条建议会怎样?"我们意识到,你们不仅想知道最佳实践是什么,还想知道它们为什么重要。针对这一反馈,我们在指南中回答了"不使用每条建议会发生什么"的问题。我们希望这能帮助你做出更好的 Azure 应用设计决策,也帮助你理解自己可能做出的各种权衡。
我们希望这份检查清单能帮助你当前和未来的 Azure 应用程序。我们欢迎你对这份清单的任何反馈:请随时在下方评论区、文章页面直接留言,或发送邮件至 [ResiliencyFeedback@microsoft.com](mailto:ResiliencyFeedback@microsoft.com)。
## 0 条评论

View File

@@ -0,0 +1,23 @@
# 谷歌基础设施的两面性——写给谷歌之外的我们
- **期号**: SRE Weekly Issue #29(2016-07-03)
- **作者**: —
- **链接**: https://speakerdeck.com/garethr/the-two-sides-to-google-infrastructure-for-everyone-else
## 简介
一场两方面的辩论,而辩论双方都是 Gareth Rushgrove(出色的 Devops Weekly 维护者)。我们是否应该在自己的基础设施中采纳谷歌的做法?比如错误预算(error budget):
> 如果你运营的是空中交通管制系统或核电站呢?你的目标恐怕更接近零故障。
## 正文
谷歌基础设施的两面性——写给谷歌之外的我们
这是我在 Velocity Santa Clara 大会上的演讲,形式是一场辩论——具体来说,是和我自己辩论。以「GIFEE」梗(**解释**:GIFEE 即「Google 的基础设施,人人可及」的缩写,指全盘照搬谷歌式基础设施与做法的思路)为例,探讨全盘照搬其他组织的软件与实践的利弊。
产品开发者被激励机制与「花掉错误预算以换取最大功能速度」的目标绑在一起——Gareth Rushgrove(Dan Luu,谷歌前员工)http://danluu.com/google-sre-book/
所有人类系统都同时包含一个技术系统和一个社会系统——Gareth Rushgrove https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution
一个联合优化的互惠过程,技术系统与社会系统在此过程中共同演变——Gareth Rushgrove https://en.wikipedia.org/wiki/Coevolution#Technological_coevolution