49 lines
2.0 KiB
Markdown
49 lines
2.0 KiB
Markdown
# 补遗
|
||
|
||
- **期号**: SRE Weekly Issue #241（2020-10-25）
|
||
- **作者**: —
|
||
- **链接**: http://sreweekly.com/
|
||
|
||
## 简介
|
||
|
||
关于上周那期的一点补充说明：Google 发布了其 Google Chat 事件总结的更新版本，移除了"机密"字样的内容。他们还更新了原链接下的内容。
|
||
|
||
## 正文
|
||
|
||
怎样才能缩短事件检测时间？这里有一些很棒的想法，尤其是监控公司主页流量是否突然飙升这一点。
|
||
|
||
Brent Chapman
|
||
|
||
多么有意思的事件！我建议先读 Azure 的官方复盘，再读 Lorin 那篇出色的分析。
|
||
|
||
Lorin Hochstein
|
||
|
||
分布式数据库很少像组件图所描绘的那样、以干净利落的隔离方式失败。它们往往因时序缺口、过期元数据、所有权不清、重试风暴、相互冲突的健康决策，以及重叠的维护活动而失败。
|
||
|
||
Varsha Ganesh — DZone
|
||
|
||
我很喜欢"政治性事件"（political incident）这个概念：
|
||
|
||
所谓政治性事件，我指的是那些严重程度（severity）先于影响评估（impact assessment）到达的事件。
|
||
|
||
哎，这一段我深有感触：
|
||
|
||
你已经在事件的严重程度字段上花了四十分钟。
|
||
|
||
Tim Irving
|
||
|
||
LLM 代理在哪些场景可以放心使用，哪些场景应该保持由人主导？这篇文章给出了一些不错的判断标准。
|
||
|
||
Sai Joshitha Kathari — HackerNoon
|
||
|
||
读这篇文章时我学到了很多关于 Git 的知识。在 CI 中加快 Git 克隆速度看起来可能并不重要，但当你需要在事件进行中快速部署修复时，它就至关重要了。
|
||
|
||
Mike Thompson and Daniel Esponda — Datadog
|
||
|
||
从自研的自动扩缩器迁移到现成的替代方案是合理的，但它并不是简单的即插即用替换。
|
||
|
||
Samuel Yeboah、Francesco Di Chiara 和 Mingliang Liu — Netflix
|
||
|
||
我们能用基于 LLM 的评审取代人工代码评审吗？这篇文章阐述了 LLM 无法复制的部分，而我认为这些恰恰是对可靠性最重要的部分。
|
||
|
||
John Allspaw — Adaptive Capacity Labs |