SRE-谷歌运维揭秘
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2020-07-12
软件方法
建模带来竞争优势。 前言 “唱曲的名家，唱到极快处，吐字依然干净利落”。 不能站在别人的肩膀上看得更远，只是摘抄别人的观点，无意义。要有足够的积累，和深度的思考。 涉众（stakeholder）往往会做而不会定义，把不同类型的涉众放在一起访谈时，只会剩下在场军衔最高那个人的意见。 需求变更的时候，要注意涉众利益角度分析。 项目的流程步骤： 寻找老大 揣摩愿景 业务建模 系统用例 需求规约 分析模型 设计开发 只有一个领域（核心域）的知识是系统能在市场上生存的理由。 拿来主义要摒除门户之见，不关注流派和风格，着力于细节和应用。 建模与 uml 利润 = 需求 - 设计 需求：提升销售 设计：降低开发维护成本 几种弊习： 从需求直接映射设计，会得到大量的重复代码。 从设计出发来定义需求，会得到一堆假的“需求”。 从涉众视角对系统功能分包会得到需求包。 子系统是基于内部视角根据系统部件的耦合和内聚情况进行切割。 需求 设计 卖的视角 做的视角 具体 抽象 产品当项目做 项目当产品做 设计源于需求，高于需求 建模工作流 业务建模：描述组织...
2026-06-21
NRW 仲裁参数——分布式副本读写的数值问题
问题 分布式系统把数据复制到 N 个节点上。写入时让 W 个节点确认，读取时查询 R 个节点。W 和 R 取多少，才能保证读到最新写入的数据？ "取多数派"是工程师最常见的直觉回答，但"多数"到底是多少——N 的一半多一个？还是 N 的三分之二？这两个数字分别在什么条件下出现，背后的推导和权衡，远比"取多数派"三个字复杂。 起源：Gifford 加权投票（1979） NRW 模型的源头是 David K. Gifford 在 1979 年 SOSP 会议上发表的论文 Weighted Voting for Replicated Data。Gifford 的模型比今天常见的等权版本更一般化：每个副本节点被分配一个投票权重 wᵢ，所有节点的总票数 V = Σwᵢ。读仲裁所需票数 Vr 和写仲裁所需票数 Vw 必须满足两个约束： 12约束 1：Vr + Vw > V约束 2：Vw > V / 2 约束 1 保证任何一次读操作至少触碰到一个持有最新版本的节点——读集合和写集合必然有交集。约束 2 保证任何两次写操作至...
2026-06-20
生产运维：集群扩缩、监控指标与故障排查
上一篇解决了安全体系的认证、授权与加密。这一篇进入生产运维。 生产运维容易被理解为"改配置 + 重启"。更准确的说法是：Kafka 集群的运维本质上是对分布式日志的分区所有权、副本状态和元数据的受控迁移，每一步操作都在改变哪些 broker 持有哪些 partition 的哪个角色。 本文只抓三个问题：如何安全地扩缩 broker，应该盯哪些 JMX 指标，以及遇到常见故障时从哪里开始排查。 集群扩缩容模型 Kafka 集群的 broker 状态可以用一个简化模型描述： 123456789101112当前集群: [broker-0, broker-1, broker-2]partition 分布: topic-A-0 -> leader=0, follower=[1,2] topic-A-1 -> leader=1, follower=[0,2]加 broker-3 后: broker-3 加入集群，无 partition -> 手动触发 partition reassignment topic-A-0 -> leader=0...
2025-07-28
Redis 经典用例全解：从数据结构到系统设计
Redis 最容易被误解成“更快的数据库”。这个理解只对了一小半。Redis 更适合放在系统的热路径上，处理短生命周期状态、派生索引、原子协调、近实时统计和少量高频列表；完整事实仍然应该由数据库、日志或对象存储承载。 系统设计面试里，Redis 的价值也不在命令背诵。更重要的是把业务需求翻译成几个稳定的问题模型： 这份数据是否可以过期 这份数据丢了能否重建 读路径是否远热于写路径 是否需要排序、范围查询、集合运算或原子判断 Redis 故障时，系统还能不能保持核心正确性 答案如果把 Redis 当成事实库，通常会在持久性、审核追溯、深页查询或跨 key 一致性上掉坑。更可靠的边界是：数据库保存事实，Redis 保存热路径和派生状态。 Redis 的系统设计位置 flowchart TD Req["业务需求"] --> Sem["抽象操作语义"] Sem --> DS["选择 Redis 数据结构"] DS --> Key["设计 Key 和分片边界"] ...
2026-04-14
Anthropic Managed Agents 深度研究：解耦大脑与双手的架构哲学
原文链接：Scaling Managed Agents: Decoupling the brain from the hands 研究时间：2026-04-14 研究方法：多轮迭代搜索 + 交叉验证 + 结构化综合 前言：从"程序即未设想之物"说起 Anthropic 在 2026 年 4 月发布的 Managed Agents 服务，解决了一个经典的计算机科学问题：如何为"尚未设想的程序"设计系统。 这个问题的答案，早在几十年前操作系统设计时就已经给出——通过虚拟化硬件为通用抽象（进程、文件），使得 read() 系统调用既能访问 1970 年代的磁盘组，也能访问现代 SSD。抽象层保持稳定，底层实现自由演进。 Managed Agents 做了同样的事情：将 Agent 组件虚拟化为三个核心组件——Session（追加式事件日志）、Harness（调用 Claude 并将工具调用路由到相关基础设施的循环）、Sandbox（Claude 可以运行代码和编辑文件的执行环境），并在此基础上通过**两个扩展维度——Many Brains（多...
2026-06-26
深入 Elasticsearch（16）：集群扩缩、监控指标与故障排查
上一篇解决了安全体系——认证、授权、加密的洋葱模型。这一篇进入生产环境中 ES 集群怎样运维。 生产运维的核心工作是监控和排障。ES 提供了丰富的内置 API 来观察集群各层的状态。关键是建立分层监控的思路：从集群健康到节点资源到索引性能到查询诊断，逐层下钻。 本文抓两个问题：生产集群应该监控哪些指标，以及常见故障怎样排查。 分层监控 监控从宏观到微观分四层，每层对应不同粒度的 API 和指标。排查问题时从 L1 开始逐层下钻，定位到具体层再展开： graph TD L1[L1 集群健康<br/>_cluster/health] -->|status != green| L2[L2 节点资源<br/>_nodes/stats] L2 -->|JVM/disk 异常| L3[L3 索引性能<br/>_cat/indices] L3 -->|rejected/慢操作| L4[L4 查询诊断<br/>slow log / profile] L1 -->|green| OK[正常运...
