在 Prometheus 中统计接口延迟的 P99 分位数时，为什么 Histogram 类型可以跨实例聚合成全局分位数，而 Summary 类型不行？
When measuring endpoint-latency P99 in Prometheus, why can Histogram metrics be aggregated across instances into a global quantile while Summary metrics cannot?
Summary 在应用进程内部就把分位数算好再暴露，多个实例各自的 P99 无法合并成真实的全局 P99；Histogram 只暴露各桶的累计计数，桶计数在不同实例间可以直接相加，服务端再用聚合后的分布沿桶边界插值估算全局分位数。代价是结果只是桶内插值的近似值，桶边界设计不当会引入明显误差。
A Summary computes quantiles inside the client process, so per-instance P99 values cannot be merged into a true global P99. A Histogram exposes only cumulative bucket counts, which are additive across instances; the server sums the buckets and interpolates along bucket boundaries to estimate the global quantile. The tradeoff is approximation error from interpolation, so bucket boundaries must be designed with care.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录含书名，但缺版次 / 出版社 / 年份中的一部分，需编辑补全后才能做独立比对。
Julien Pivotto & Brian Brazil,《Prometheus: Up & Running》第2版,O'Reilly Media,2020年
Julien Pivotto & Brian Brazil, Prometheus: Up & Running, 2nd ed., O'Reilly Media, 2020
#监控指标 #直方图 #分位数
什么是 API 和契约测试（Contract Testing）？
What are APIs and contract testing?
API 是不同软件之间约定的调用接口；契约测试检查提供方和消费方是否都遵守同一份接口契约，避免一方改动悄悄弄坏另一方。
An API is an agreed interface between software; contract testing checks that provider and consumer both honor the same interface contract, preventing silent breakage.
难度 专业 · 适合 大众
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：本题原挂出处与答案内容不符，已撤回；具体书目待补，暂不展示来源。
本题原挂出处与答案内容不符，已撤回；具体书目待补。
Previous citation withdrawn as unsupported for this answer; a specific source is pending.
#API #测试
什么是持续集成（CI）和持续部署（CD）？
What are continuous integration (CI) and continuous deployment (CD)?
CI 是开发者一提交代码就自动构建和测试，尽早发现问题；CD 则把通过测试的代码自动部署上线，缩短发布周期。
CI automatically builds and tests on every commit to catch issues early; CD automatically deploys passing code, shortening release cycles.
难度 进阶 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-10-04
来源 · Source
Fowler《Continuous Integration》（martinfowler.com，2006 修订版）；Beck《解析极限编程》1999；Humble & Farley《持续交付》2010
Fowler, 'Continuous Integration' (martinfowler.com, 2006 revision); Beck, Extreme Programming Explained (1999); Humble & Farley, Continuous Delivery (2010)
独立核验依据 · Independent verification: 核验依据 1 ISBN 9780321670229 (2010)
#CI #CD
什么是技术债务（Technical Debt）？
What is technical debt?
为了赶进度而写的凑合代码，以后要花更多精力改，就像借债要还利息。适度可控可以，积累太多会拖慢开发。
Rushed, good-enough code costs more to fix later, like debt with interest. Some is fine if managed, but too much slows development.
难度 进阶 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Robert C. Martin,《Clean Code》Prentice Hall,2008;中译《代码整洁之道》人民邮电出版社
R. C. Martin, Clean Code, Prentice Hall, 2008; Chinese ed.
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL17618370W：Clean Code（按标题+作者/年份比对
#技术债务 #工程
什么是微服务架构？
What is microservices architecture?
微服务把一个大系统拆成多个小服务，各自独立开发、部署和扩容，用接口互相调用，灵活但运维更复杂。
Microservices split a system into small services that develop, deploy, and scale independently and talk via interfaces, flexible but more operational work.
难度 进阶 · 适合 大众
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：本题原挂出处与答案内容不符，已撤回；具体书目待补，暂不展示来源。
本题原挂出处与答案内容不符，已撤回；具体书目待补。
Previous citation withdrawn as unsupported for this answer; a specific source is pending.
#微服务 #架构
什么是容器（如 Docker）？它和虚拟机有什么不同？
What is a container (like Docker), and how is it different from a VM?
容器把应用和依赖打包在一起，共享操作系统内核，启动快、更轻量；虚拟机则虚拟整套系统，隔离更强但更重。
A container bundles an app with its dependencies and shares the OS kernel, fast and light; a VM virtualizes a whole OS, stronger isolation but heavier.
难度 进阶 · 适合 大众
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：著录含书名，但缺版次 / 出版社 / 年份中的一部分，需编辑补全后才能做独立比对。
Sean Doyle & Matt Hite,《Docker: Up & Running》第2版,O'Reilly Media,2018
Sean Doyle & Matt Hite, Docker: Up & Running, 2nd ed., O'Reilly Media, 2018
#容器 #Docker
什么是单元测试和集成测试？
What are unit tests and integration tests?
单元测试只测一个最小函数是否正确；集成测试检查多个模块拼起来能否协同工作，二者互补保证质量。
A unit test checks one small function; an integration test checks that combined modules work together. They complement each other for quality.
难度 进阶 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Robert C. Martin,《Clean Code》Prentice Hall,2008;中译《代码整洁之道》人民邮电出版社
R. C. Martin, Clean Code, Prentice Hall, 2008; Chinese ed.
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL17618370W：Clean Code（按标题+作者/年份比对
#测试 #质量
蓝绿部署是如何降低新版本上线风险的?它与滚动更新在资源成本和回滚方式上有何不同?
How does blue-green deployment lower the risk of shipping a new version, and how does it differ from rolling updates in resource cost and rollback mechanics?
蓝绿部署同时维护两套等价环境:新版本先在空闲的绿色环境中完成验证,再由负载均衡把线上流量一次性切换过去,切换只是改路由规则,秒级生效且几乎没有停机窗口。滚动更新按批次逐台替换实例,资源占用只有一份,但新旧版本会共存较长时间,要求接口严格向后兼容。回滚时蓝绿只需把流量切回蓝色环境即可瞬间恢复,滚动更新的回滚却要反向再执行一整轮替换,耗时更久且二次出错的面更大。
Blue-green deployment keeps two equivalent environments alive: the new version is verified in the idle green environment first, then a load balancer flips all production traffic over at once—a routing-rule change that takes effect in seconds with virtually no downtime window. Rolling updates replace instances batch by batch using only one copy of the resources, but old and new versions coexist for extended periods, forcing strict backward-compatible interfaces. On rollback, blue-green simply routes traffic back to the blue environment for instant recovery, while a rolling update's rollback must run a whole replacement pass in reverse, taking longer and widening the surface for a second failure.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
Forsgren, Humble & Kim,Accelerate: The Science of Lean Software and DevOps,IT Revolution Press,2018
Forsgren, Humble & Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution Press, 2018
独立核验依据 · Independent verification: 核验依据 1 OPENLIBRARY 标识 /works/OL27114211W：Accelerate : The Scien
#DevOps #发布与回滚
蓝绿发布、金丝雀发布与滚动发布各自的适用场景是什么?如何结合监控指标自动决定回滚?
What are the appropriate scenarios for blue-green, canary, and rolling deployments, and how can metric monitoring drive automatic rollback decisions?
蓝绿适合需要瞬时切换和秒级回滚的核心服务,代价是双倍资源占用;金丝雀适合大流量在线服务,先放一小部分真实流量验证再逐步扩大;滚动发布资源效率高但版本共存时间长,依赖接口向后兼容。自动化决策通常把错误率、P99 延迟、饱和度三类指标接入 SLO 阈值判断,金丝雀组指标越界即触发流量切回旧版本,并结合部署标记定位引入回归的具体版本。
Blue-green suits core services needing instant cutover and second-level rollback at the cost of doubled capacity; canary fits high-traffic online services where a small real-traffic slice validates the release before gradual expansion; rolling is resource-efficient but keeps versions coexisting longer and demands backward-compatible interfaces. Automated decisions typically feed error rate, P99 latency, and saturation metrics into SLO threshold checks — when the canary group breaches bounds, traffic flips back to the old version and deployment markers pinpoint which revision caused the regression.
难度 进阶 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-10-04
来源 · Source
Jez Humble & David Farley,《Continuous Delivery》第8章,Addison-Wesley,2010
Jez Humble & David Farley, "Continuous Delivery", ch. 8, Addison-Wesley, 2010
独立核验依据 · Independent verification: 核验依据 1 ISBN 9780321670229 (2010)
#持续交付 #发布策略
SRE 中的错误预算如何定义？它怎样用来平衡发布速度与服务可靠性？
How is an error budget defined in SRE, and how does it balance release velocity against service reliability?
错误预算由服务等级目标推导而来：若 SLO 规定 30 天窗口内请求成功率达 99.9%，预算就是剩余 0.1% 所允许的失败请求量。团队据此约定：预算充裕时正常甚至加快发布；一旦消耗过快触发燃烧率告警，就冻结非紧急变更并优先修复可靠性。可靠性与迭代速度由此变成一份可度量的共享资源，工程取舍有了客观依据。
An error budget is derived from the service level objective: if the SLO requires 99.9% successful requests over a 30-day window, the budget is the remaining 0.1%, a finite allowance of failures. Teams agree in advance that a healthy budget permits normal or even faster releases, while rapid depletion firing burn-rate alerts freezes non-urgent changes in favor of reliability work. Reliability and velocity thus become one measurable shared resource, giving engineering trade-offs an objective basis.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
B. Beyer 等（编），《SRE：Google 运维解密》，O'Reilly Media，2016
B. Beyer et al. (eds.), Site Reliability Engineering: How Google Runs Production Systems, O'Reilly Media, 2016
独立核验依据 · Independent verification: 核验依据 1 ARCHIVE 标识 sitereliabilitye0000unse：Site reliability eng
#服务等级目标 #错误预算 #燃烧率告警
代码评审（Code Review）有什么用？
What is the use of code review?
评审让同事在合并前读你的代码，能发现 bug、统一风格、传播知识，也促使作者写得更认真，提升整体质量。
Review has peers read your code before merge to catch bugs, unify style, and share knowledge, and it makes authors more careful, raising overall quality.
难度 进阶 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Robert C. Martin,《Clean Code》Prentice Hall,2008;中译《代码整洁之道》人民邮电出版社
R. C. Martin, Clean Code, Prentice Hall, 2008; Chinese ed.
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL17618370W：Clean Code（按标题+作者/年份比对
#代码评审 #协作
什么是版本控制（如 Git）？为什么需要它？
What is version control (like Git), and why do we need it?
版本控制记录文件每次改动的历史，可随时回到旧版本、看清谁改了什么，多人还能并行修改同一项目而不乱。
Version control records every change history, lets you revert, shows who changed what, and lets many people edit one project without chaos.
难度 入门 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-11-06
来源 · Source
Scott Chacon & Ben Straub,《Pro Git》,Apress,2014
Scott Chacon & Ben Straub, Pro Git, Apress, 2014
独立核验依据 · Independent verification: 核验依据 1 Pro Git 2nd ed. 官方全文（Apress / CC BY-NC-SA 3.0）
#版本控制 #Git