系统与基础设施eranki.tumblr.com
Dropbox 的扩展经验教训（第一部分）
Scaling lessons learned at Dropbox, part 1
2012 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Dropbox 工程师总结的服务规模化经验第一部分，讨论分片、日志、监控、人为制造冗余负载等扩展实践。文章虽写于 2012 年，但其中不少关于工程权衡和基础工具的建议至今仍适用。
为什么经久不衰：它沉淀的是大规模系统扩展中经得起时间检验的原则与权衡，而不是某个具体框架或时髦技术。
HN 评论精选
安全不能只算公司公关成本，用户风险应优先。
好文章，但安全这部分让我有点担心……很多服务（甚至银行）都有严重安全问题，却似乎能扛过一场小公关风暴。所以在锁死一切之前，先弄清楚它是否真的重要（你值得被黑吗？你真的在乎被黑吗？值得投入工程或产品成本吗？）。但能“承受”被黑，并不意味着不应该主动保护数据。归根结底，安全不是关于你，而是关于用户。正是这种态度导致了近年那些大规模泄露。公司当然会因负面公关“受伤”，但真正的受害者是用户。尤其涉及用户文件这种敏感数据时，应该先考虑用户的风险，再考虑公司自身。
jgannonjr查看英文原文
Great post, but this part scares me a bit... I think a lot of services (even banks!) have serious security problems and seem to be able to weather a small PR storm. So figure it out if it really is important to you (are you worth hacking? do you actually care if you’re hacked? is it worth the engineering or product cost?) before you go and lock down everything. Just because you can "afford" to be hacked, doesn't mean you shouldn't take all the steps necessary to proactively protect your data. In the end, security is not about you, it is about your users. This is exactly the type of attitude that leads to all the massive breaches we have been seeing recently. Sure your company is "hurt" with bad PR, but really your users are the ones who are the real victims. You should consider their risk (especially with something as sensitive as people's files!) before you consider your own company's well being. Edit: formatting
人为冗余负载可能让人拖延真正的修复。
运行额外负载这个想法理论上不错，但我忍不住觉得有点像把表拨快以防迟到。最终你知道表快了 5 分钟，就会开始补偿。我怀疑这种策略也会有同样效果：因为知道可以在变严重前拉高负载，就把修复往后推。就像你知道表其实走快了，于是晚几分钟出门赶火车。
brc查看英文原文
The idea of running extra load - it sounds good in theory but I can't help thinking that it's a bit like setting your watch forwards to try and stop being late for things. Eventually you know your watch is 5 minutes fast so start compensating for it. I wonder if this strategy starts to have the same effect - putting fixes off because you know you can pull the extra load before it becomes critical. In the same way you leave for the train a couple of minutes later because you know your watch is actually running fast.
内部人补充并更新了文中实践：日志受限、分片固定、UTC 和 Python 长期不变。
2015 到 2020 年我在 Dropbox，有趣的是很多事变了，很多事又没变。变化：2015 年我加入时已禁止在服务器上直接记文本日志，只有少数 SRE 能访问文本日志；关心的事件必须通过文中“应用特定指标”系统记录，而且相当易用。（不过桌面端仍用 logspam，因为调试客户端异常时，有时唯一线索就是看哪些代码行在打印日志。）分片方面，我加入时大部分 MySQL 已被自研的、基于 MySQL 的 KV/图数据库取代，分片数固定，约 255。没变的（至少到 2020 年我离开时）：一切都用 UTC，包括所有 UI（指标、异常、崩溃等）；Python 仍几乎用于所有东西。
nosefrog查看英文原文
I was at Dropbox from 2015-2020, and it's funny how many things have changed and how many stay the same. Changes: - When I joined in 2015, it was already forbidden to just log text on the server. Only a small number of SREs even had access to the text logs. Any event that you cared about needed to be logged from the system described in "App-specific metrics", which was pretty easy to use. (That said, on desktop we still used logspam because when you're debugging a desktop client doing the wrong thing, sometimes the only lead you have is tracing which lines of code are being run by looking at which logs are being printed.) - Re: shards, by the time I joined most of the mysql was replaced by a homegrown KV/graph database on top of mysql that had a fixed number of shards (something like 255). Things that didn't change (at least by the time I left in 2020): - Everything was in UTC, including in the UIs for everything (e.g. metrics, exceptions, crashes, etc). I ended making a GPS clock that showed UTC to put on my desk as a fun project, and I know at least one SRE who had set basically all their clocks to UTC time (e.g. phone, laptop, calendar, etc). This is in contrast to Google, where almost every system either shows your local time or "Google Standard Time" (which is just Pacific Time). - Python was still used for virtually everything.
Unix 工具比流行框架更值得长期投资。
这篇文章可能来自 2012 年，但令人惊讶的是其中多少具体建议仍然适用。grep、sed、awk、xargs 等仍然是调试用的经典 shell 工具，几十年来一直如此。这让人意识到，学习 Unix 工具很可能比学习最新流行框架是更好的长期时间投资。我希望能够回到过去告诉年轻时的自己……
yaseer查看英文原文
This may be from 2012, but it's surprising just how much of the specific advice still applies. Grep, sed, awk, xargs etc are still the canonical list of shell tools for debugging, and have been for decades. Makes you realise, learning Unix tools will likely be a better long term time investment than the latest trendy framework. I wish I could go back in time and tell that to my younger self...
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选