专业书籍精读

Ch 1可靠·可扩展·可维护 — 先立三把尺子，用负载参数和响应时间百分位把「系统好不好」量化成可谈的东西Kleppmann · 2017 Ch 2数据模型与查询语言 — 关系 / 文档 / 图各擅长什么，声明式查询为何胜过命令式Kleppmann · 2017 Ch 3存储与检索 — 数据库底层怎么存怎么找：LSM-tree vs B-tree，行存 OLTP vs 列存分析Kleppmann · 2017 Ch 4编码与演化 — 数据怎么序列化、schema 怎么在不停机下前后兼容地演化Kleppmann · 2017 Ch 5复制 — 同一份数据放多台机器：单主 / 多主 / 无主，与复制滞后的一致性坑Kleppmann · 2017 Ch 6分区 — 一份数据太大切成片：按范围还是按哈希，热点与再平衡Kleppmann · 2017 Ch 7事务 — ACID 到底保证了什么，弱隔离放行哪些并发异常，写偏斜为何是最该记的坑Kleppmann · 2017 Ch 8分布式系统的麻烦 — 部分失效、不可靠时钟、网络停顿，为什么分布式这么难Kleppmann · 2017 Ch 9一致性与共识 — 线性一致、全序广播与共识，CAP 之后真正该知道的Kleppmann · 2017 Ch 10批处理 — MapReduce 的「分头数再汇总」，靠一次分布式排序把海量数据算成派生结果，输入不可变所以算错就重来Kleppmann · 2017 Ch 11流处理 — 把数据当永不结束的事件流来一条算一条，靠可回放的日志（Kafka）与流表二象性把数据库里外翻转，难点在事件时间与水位Kleppmann · 2017 Ch 12数据系统的未来 — 把数据库拆开、用一条有序事件流重新组装，正确性靠端到端而非底层事务Kleppmann · 2017 Ch 1软件交付的难题 — 手工部署与发布日地狱，把发布做成一条可重复的流水线Humble & Farley · 2010 Ch 2配置管理 — 一切纳入版本控制，同一份制品部署到所有环境，机器一律不许手工改Humble & Farley · 2010 Ch 3持续集成 — 每天并回主干、红了全队停线，CI 是一种实践不是一个工具Humble & Farley · 2010 Ch 4实施测试策略 — 用四象限把测试摊开：能重复的交给机器，靠好奇心的留给人Humble & Farley · 2010 Ch 5部署流水线剖析 — 从提交到生产的一条自动化关卡：只构建一次，红了就停线Humble & Farley · 2010 Ch 7提交阶段 — 十分钟内给出一个可信的红或绿：这条预算管的是人，不是机器Humble & Farley · 2010 Ch 8自动化验收测试 — 把「验什么」和「怎么点」分层拆开，端到端测试才养得起Humble & Farley · 2010 Ch 10部署与发布 — 蓝绿与金丝雀把上线拆成可撤回的小步；真正的墙不是代码，是数据Humble & Farley · 2010 Ch 11管理基础设施与环境 — 机器只能由自动化按版本库里的定义来建和改，手工改过一次就再也复制不出来Humble & Farley · 2010 Ch 12管理数据 — 代码能换回上一版，数据不能；靠非破坏性迁移和新旧并存的兼容窗口把发布变回可撤销Humble & Farley · 2010 Ch 13组件与依赖 — 拆组件是为了把构建拉回十分钟，代价是丢掉「一次提交、一次全量验证」，得靠钉死版本和集成流水线买回来Humble & Farley · 2010 Ch 1引论 — 请软件工程师来设计运维团队，再用 50% 工程时间下限和错误预算把它钉住Google · 2016 Ch 3拥抱风险 — 100% 是错的目标；把 1 减去 SLO 的那截当成能花的预算，有余额就发、烧光就冻结Google · 2016 Ch 4服务质量目标 — 先挑对该量的东西再谈几个 9；一条 SLO 要写清在哪测、算哪段窗口，还得少到你敢用它拍板Google · 2016 Ch 5消除琐务 — 判据不是烦不烦，而是它会不会随规模线性长大；50% 是上限，超了要退回开发团队Google · 2016 Ch 6监控分布式系统 — 四个黄金信号是最小充分集；告警只报症状，处置机械的那种根本不该叫人Google · 2016 Ch 8发布工程 — 发得快只是结果，能原样重来才是地基；配置也得有自己的版本号和回滚Google · 2016 Ch 9简单性 — 可靠性的上限是你还读得懂多少；代码是负债，最理想的改动是负行数Google · 2016 Ch 12有效排障 — 排障是手艺不是天赋；先止血再破案，从中间折半，然后问「力气花在哪」Google · 2016 Ch 15事后复盘文化 — 不追人只追条件，因为你要的信息只在当事人嘴里；产出不是文档，是一串被跟到关掉的改动Google · 2016 Ch 21处理过载 — 容量别用 QPS 量；扛不住时主动少接一点，产出反而稳在上限上Google · 2016 Ch 22应对级联失效 — 失败会自己繁殖；修好起因也回不来，得亲手把回路掐停Google · 2016 Ch 23管理关键状态 — 心跳加超时不是绕开了共识，而是写错了的共识；这种东西请用现成的Google · 2016 Ch 25数据处理管线 — 管线的敌人不是数据量，是「按点开工」本身：空转的谷、挤爆的峰、看不出死活的中间态Google · 2016 Ch 26数据完整性 — 你以为副本在保护数据，其实副本只是把误删同步得更快；保命的是三道防线Google · 2016 Ch 1加速 — 快与稳不是取舍，是同一批团队的同一件事；改进别爬等级，先找自己最弱的那一环Forsgren et al. · 2018 Ch 2测量效能 — 别数「干了多少」，改数四个互相牵制的结果，让谁都没法牺牲一侧去刷另一侧Forsgren et al. · 2018 Ch 3测量并改变文化 — 别问文化怎么样，看一条坏消息能不能走到该看见它的人手里Forsgren et al. · 2018 Ch 4技术实践 — 持续交付不是买流水线，是让主干随时可发；而自动化测试谁写，比写没写更能拉开差距Forsgren et al. · 2018 Ch 5架构 — 别争单体还是微服务，只问两句：能不能独立测、能不能独立发Forsgren et al. · 2018 Ch 6把安全融入交付 — 安全不是发布前那道门，而是把路铺好：让做对的事比绕开更省事Forsgren et al. · 2018 Ch 9让工作可持续 — 别问团队累不累，问上次上线是周几几点；倦怠是环境的输出，不是人不够强Forsgren et al. · 2018