新書推薦：
《
无尽的海洋：美国海事探险与大众文化（1815—1860）
》
售價：NT$
454.0
《
治盗之道：清代盗律的古今之辨
》
售價：NT$
556.0
《
甲骨文丛书·剑桥世界暴力史（第一卷）：史前和古代世界（套装全2册）
》
售價：NT$
959.0
《
甲骨文丛书·中华早期帝国：秦汉史的重估
》
售價：NT$
1367.0
《
欲望与家庭小说
》
售價：NT$
449.0
《
惜华年（全两册）
》
售價：NT$
320.0
《
甲骨文丛书·古代中国的军事文化
》
售價：NT$
454.0
《
中国王朝内争实录（套装全4册）：从未见过的王朝内争编著史
》
售價：NT$
1112.0
|
| 編輯推薦： |
谷歌首创的“站点可靠性工程”(SRE)用于创建伸缩性更强和稳定性更高的大型交付系统，是当前更有价值的软件创新机会。《SRE实践手册:软件组织如何规模化实施站点可靠性工程》作为一本简明、实用和全面的SRE指导手册，展示了如何才能顺利实施SRE。作者提出一个循序渐进的方法，基于文化、组织和技术流程这三个支点来建构SRE基础，帮助软件交付组织快速实现“最小可行SRE”并在此基础上进行持续的迭代和精进。
乌基斯博士在书中分享了西门子医疗的SRE转型过程。贯穿全书，他全面解答了落地SRE所涉及的问题，指出可能存在的种种陷阱，并说明了如何避免和克服这些容易被忽视的坑。从事软件开发、工程或运维的读者，可借助于本书巧妙地应用SRE来持续提升服务体验。
|
| 內容簡介： |
|
《SRE实践手册:软件组织如何规模化实施站点可靠性工程》基于作者在西门子医疗的SRE转型经历，为读者提供了SRE落地实践过程，主题涉及如何从基础设施、组织文化和流程等层面，从全景的角度实际导入和实施SRE工程过程。《SRE实践手册:软件组织如何规模化实施站点可靠性工程》共15章，实用性强，可操作性强，指导性强，适合想要启动SRE实践的组织和团队阅读与参考。
|
| 關於作者： |
弗拉迪斯拉夫·乌基斯博士是西门子医疗Teamplay云平台的研发主管及SRE负责人。作为软件开发负责人，他先后推动了组织内部的持续交付、SRE和DevOps转型，参与了架构、部署、测试、运维和文化相关工作以及规模化实施新的工作流程。
乌基斯博士在德国埃尔朗根-纽伦堡大学获得计算机科学学士学位，后来在英国曼彻斯特大学获得硕士学位。在他的职业生涯中，先后从事软件架构、企业架构、创新管理、私有云和公有云计算、团队管理、工程管理、投资组合管理、合作伙伴管理以及数字化转型过程等工作。
|
| 目錄：
|
简明目录
Ⅰ 基础知识
第1章 SRE概述 3
第2章 面临的挑战 18
第3章 SRE基本概念 36
第4章 评估现状 54
Ⅱ 启动转型
第5章 取得组织的认同 75
第6章 奠定基础 114
第7章 响应SLO违反警报 151
第8章 警报分派 183
第9章 实现事故响应 198
第10章 设置错误预算策略 265
第11章 实现基于错误预算的决策 284
第12章 实现组织结构 340
Ⅲ 度量和维持转型
第13章 度量SRE转型 405
第14章 持续推进SRE运动 411
第15章 未来之路 424
附录 主题快速参考 430
详细目录
第Ⅰ部分 基础知识
第1章 SRE概述 3
1.1 为什么要选择SRE 3
1.1.1 ITIL 3
1.1.2 COBIT 4
1.1.3 建模 5
1.1.4 DevOps 5
1.1.5 关于SRE 6
1.1.6 比较不同的方法 7
1.2 使用SRE进行协同 12
1.3 SRE为什么有用 15
1.4 小结 17
第2章 面临的挑战 18
2.1 种种不协同 18
2.2 集体所有权 20
2.3 SRE应用场景下的所有权 21
2.3.1 产品开发 21
2.3.2 产品运营 23
2.3.3 产品管理 27
2.3.4 效益和成本 30
2.4 挑战声明 32
2.5 教练 33
2.6 小结 35
第3章 SRE基本概念 36
3.1 服务水平指标 36
3.2 服务水平目标 37
3.3 错误预算 39
3.3.1 可用性错误预算的例子 40
3.3.2 错误预算为零 41
3.3.3 延迟错误预算的例子 43
3.4 错误预算策略 44
3.5 SRE概念金字塔 46
3.6 使用SRE概念金字塔进行协同 49
3.7 小结 53
第4章 评估现状 54
4.1 组织现状 54
4.1.1 组织结构 54
4.1.2 组织协同 56
4.1.3 正式和非正式领导 57
4.2 人员现状 58
4.3 技术现状 59
4.4 文化现状 63
4.4.1 是否高度合作 64
4.4.2 培训 64
4.4.3 是否共担风险 65
4.4.4 是否鼓励交流 65
4.4.5 失败后是否可以追根溯源 65
4.4.6 是否接纳新的想法 66
4.5 过程现状 66
4.6 SRE成熟度模型 68
4.7 提出假设 70
4.8 小结 72
第Ⅱ部分 启动转型
第5章 取得组织的认同 75
5.1 取得组织内部对SRE的认同 75
5.2 SRE营销漏斗 77
5.2.1 认识SRE 78
5.2.2 兴趣 79
5.2.3 理解 80
5.2.4 共识 80
5.2.5 参与 81
5.3 SRE教练 82
5.3.1 特质 82
5.3.2 责任 83
5.4 自上而下认同 84
5.4.1 利益相关者图表 85
5.4.2 与开发主管接触 87
5.4.3 与运营主管接触 92
5.4.4 和产品管理主管接触 93
5.4.5 实现联合认同 95
5.4.6 让SRE进入项目组合 97
5.5 自下而上认同 99
5.5.1 与运营团队接触 99
5.5.2 与开发团队接触 100
5.6 横向认同 103
5.7 交错认同 104
5.8 团队辅导 104
5.9 跨组织 106
5.9.1 组织的分组 106
5.9.2 组织穿越与SRE基础设施需求 108
5.9.3 接触各个团队的时机 108
5.10 组织辅导 111
5.11 小结 112
第6章 奠定基础 114
6.1 团队导入对话 114
6.2 传达基础知识 115
6.2.1 SLO作为契约 115
6.2.2 SLO作为客户满意度的代理度量 116
6.2.3 用户画像 117
6.2.4 用户故事地图 119
6.2.5 对SLO被违反情况进行修复的积极性 121
6.2.6 SLO和技术问题无关 123
6.2.7 SLO违反的原因 123
6.2.8 值班应对违反SLO的情况 125
6.3 SLI标准化 125
6.3.1 应用程序性能管理设施 127
6.3.2 可用性 128
6.3.3 延迟 129
6.3.4 优先级排序 130
6.4 启用日志记录 132
6.5 日志查询语言的培训 133
6.6 定义初始SLO 134
6.6.1 什么是好的SLO 135
6.6.2 SLO迭代过程 136
6.6.3 修订SLO 139
6.7 默认SLO 140
6.8 提供基本的基础设施 141
6.8.1 仪表盘 142
6.8.2 警报内容 143
6.9 与拥护者接触 144
6.10 和反对者打交道 144
6.10.1 人们为什么会反对 145
6.10.2 警报的问题 145
6.10.3 工具的问题 146
6.10.4 产品负责人的问题 147
6.10.5 团队激励的问题 147
6.11 创建文档 148
6.12 宣传成功 148
6.13 小结 150
第7章 响应SLO违反警报 151
7.1 环境选择 151
7.2 责任 153
7.2.1 开发责任与运营责任 153
7.2.2 运营责任 154
7.2.3 划分运营责任 154
7.3 工作模式 156
7.3.1 基于中断的工作模式 156
7.3.2 基于专注的工作模式 160
7.4 设置轮流值班 160
7.4.1 初始轮换周期 161
7.4.2 单人值班 161
7.4.3 双人值班 162
7.4.4 三人值班 162
7.5 值班管理工具 163
7.5.1 发布SLO违反 163
7.5.2 排班 165
7.5.3 专业值班管理工具 165
7.6 非工作时间进行值班 167
7.6.1 使用可用性目标和产品需求 168
7.6.2 取舍 168
7.7 系统化的知识共享 170
7.7.1 知识共享需求 172
7.7.2 知识共享金字塔 173
7.7.3 值班培训 175
7.7.4 运行手册 176
7.7.5 内部Stack Overflow工具 178
7.7.6 SRE实践社区 179
7.8 宣传成功 180
7.9 小结 182
第8章 警报分派 183
8.1 警报升级 184
8.2 定义警报升级策略 186
8.3 定义利益相关者分组 187
8.4 触发利益相关者通知 189
8.5 定义利益相关者环 190
8.6 定义有效的利益相关者通知 193
8.7 允许利益相关者订阅 195
8.7.1 使用值班管理工具订阅 196
8.7.2 使用其他方式订阅的可行性 196
8.8 宣传成功 196
8.9 小结 197
第9章 实现事故响应 198
9.1 事故响应基础 198
9.2 事故优先级 199
9.2.1 SLO违反与事故 200
9.2.2 在事故期间更改事故优先级 202
9.2.3 定义通用事故优先级 203
9.2.4 将SLO映射到事故优先级 205
9.2.5 将错误预算映射到事故优先级 207
9.2.6 将基于资源的警报映射到事故优先级 208
9.2.7 发现事故优先级的新用例 209
9.2.8 根据利益相关者的反馈来调整事故优先级 210
9.2.9 扩展SLO定义过程 211
9.2.10 基础设施 212
9.2.11 消除重复 213
9.3 协调复杂事故 215
9.3.1 什么是复杂事故 215
9.3.2 现有的事故协调系统 216
9.3.3 事故分类 217
9.3.4 定义通用事故严重性 217
9.3.5 事故分类的社会维度 219
9.3.6 事故优先级与事故严重性 220
9.3.7 定义角色 221
9.3.8 事故严重性分别对应哪些角色 223
9.3.9 值班角色 223
9.3.10 事故响应过程评估 224
9.3.11 事故响应过程动态 225
9.3.12 事故响应团队的幸福感 228
9.4 事后回顾 232
9.5 有效事后回顾的标准 233
9.5.1 发起事后回顾 234
9.5.2 事后回顾的生命周期 235
9.5.3 事后回顾之前 236
9.5.4 事后回顾会议 238
9.5.5 事后回顾之后 244
9.5.6 分析事后回顾过程 245
9.5.7 事后回顾模板 250
9.5.8 促进从事后回顾中学习 252
9.5.9 成功的事后回顾实践 252
9.5.10 事后回顾实例 253
9.6 工具整合 254
9.6.1 与值班管理工具连接 254
9.6.2 其他工具之间的连接 256
9.6.3 移动集成 257
9.6.4 示例工具搭配 258
9.7 服务状态广播 259
9.8 撰写事故响应过程文档 261
9.9 宣传成功 262
9.10 小结 263
第10章 设置错误预算策略 265
10.1 动机 265
10.2 术语 267
10.3 错误预算策略的结构 267
10.4 错误预算策略的条件 269
10.5 错误预算策略的后果 270
10.6 错误预算策略治理体系 271
10.7 扩展错误预算策略 273
10.8 签署错误预算策略 277
10.9 存储错误预算策略 278
10.10 实行错误预算策略 279
10.11 审查错误预算策略 280
10.12 相关概念 281
10.13 小结 282
第11章 实现基于错误预算的决策 284
11.1 可靠性决策的分类法 284
11.2 实现SRE指标 287
11.2.1 SRE指标的维度 287
11.2.2 “按服务划分的SLO”指标 288
11.2.3 “SLO遵守情况”指标 289
11.2.4 “SLO错误预算消耗”指标 290
11.2.5 “SLO错误预算过早耗尽”指标 295
11.2.6 “按服务划分的SLA”指标 299
11.2.7 “SLA错误预算消耗”指标 300
11.2.8 “SLA遵守情况”指标 303
11.2.9 “客户支持工单趋势”指标 304
11.2.10 “团队轮流值班”指标 308
11.2.11 “事故恢复时间趋势”指标 309
11.2.12 “最不可用服务端点”指标 311
11.2.13 “最慢服务端点”指标 312
11.3 过程指标（而非人员的KPI） 313
11.4 决策与指标 314
11.5 决策工作流 316
11.5.1 “使用API”决策工作流 316
11.5.2 “收紧依赖项的SLO”决策工作流 319
11.5.3 “功能与可靠性优先级排序”工作流 321
11.5.4 “设置SLO”决策工作流 325
11.5.5 “设置SLA”决策工作流 329
11.5.6 “为团队分配SRE能力”决策工作流 331
11.5.7 “选择混沌工程假设”工作流 334
11.6 小结 338
第12章 实现组织结构 340
12.1 SRE原则与组织结构 341
12.2 谁构建，谁运行 342
12.2.1 “谁构建，谁运行？”谱系 343
12.2.2 混合模式 344
12.2.3 改善可靠性的动力 344
12.2.4 模式比较标准 347
12.2.5 模式比较 349
12.3 “你构建，你运行” 350
12.4 “你构建，你和SRE运行” 352
12.4.1 开发组织内的SRE团队 352
12.4.2 运营组织内的SRE团队 354
12.4.3 专门的SRE组织内部的SRE团队 355
12.4.4 对比 357
12.4.5 SRE团队的激励、身份和自豪感 358
12.4.6 SRE团队的人数和预算 359
12.4.7 SRE团队成本核算 362
12.4.8 SRE团队KPI 363
12.5 你构建，SRE运行 365
12.5.1 开发组织内的SRE团队 366
12.5.2 运营组织内的SRE团队 367
12.5.3 专门的SRE组织内部的SRE团队 367
12.6 成本优化 368
12.7 团队拓扑结构 370
12.7.1 报告线 371
12.7.2 SRE身份三角 372
12.7.3 合弄制：无报告线 374
12.8 选择一个模式 375
12.8.1 模式转换选项 375
12.8.2 决策维度 376
12.8.3 报告选项 378
12.8.4 SRE组织的定位 379
12.8.5 将价值传达给管理层 381
12.9 一个新的角色：SRE 382
12.9.1 为什么需要一个新角色 382
12.9.2 角色定义 384
12.9.3 角色命名 387
12.9.4 角色分配 388
12.9.5 角色履行 390
12.10 SRE职业道路 391
12.10.1 SRE角色发展 392
12.10.2 SRE角色转换 394
12.10.3 文化的重要性 395
12.11 就所选模式进行沟通 396
12.12 导入所选的模式 397
12.12.1 组织变化 398
12.12.2 报告结构的变化 400
12.12.3 角色变化 401
12.13 小结 401
第Ⅲ部分 度量和维持转型
第13章 度量SRE转型 405
13.1 测试转型假设 405
13.2 内部未检测到的故障 406
13.3 过早耗尽错误预算的服务 407
13.4 管理层的看法 408
13.5 用户和合作伙伴对可靠性的看法 409
13.6 小结 410
第14章 持续推进SRE运动 411
14.1 建立成熟的SRE CoP 411
14.2 SRE时间 411
14.3 可用性新闻简报 412
14.4 工程博客中的SRE专栏 413
14.5 推广SRE维基页面长文 413
14.6 SRE的宣发 414
14.7 结合SRE和CD指标 415
14.7.1 对比CD与SRE指标 416
14.7.2 瓶颈分析 417
14.8 SRE反馈回路 418
14.9 新的假设 419
14.10 提供学习机会 420
14.11 为SRE教练提供支持 421
14.12 小结 423
第15章 未来之路 424
15.1 服务目录 425
15.2 SLA 426
15.3 监管合规 426
15.4 SRE基础设施 427
15.5 游戏日 428
附录 主题快速参考 430
|
| 內容試閱：
|
前言
本书基于真实的案例，回顾了西门子医疗作为软件交付组织所进行的SRE（Site Reliability Engineering，站点可靠性工程）转型之旅。该组织运行的云平台主要服务于医疗应用和服务。云平台部署在多个数据中心，平台上的应用全球各地的医院都在用，其中一些应用涉及危重病患，因而平台的可靠性尤为重要。
但什么是可靠性？如何度量呢？如何营造一个环境，使开发团队有动力投入可靠性工程？我多年来一直在努力解决这些问题。为了向应用和用户提供一个高可靠性的平台，我们组织可谓操碎了心。一方面，我们需要开发新的功能。另一方面，我们又要保障平台的可靠性。至于哪项工作优先级更高，人们的看法不一样。一方面，运营团队煞费苦心，要确保产品/服务能够正常运行。另一方面，开发团队又兴致勃勃，想要实现新的功能，很少关注现有功能在生产环境中的实际运行情况。项目管理计划因为部署大量非预期的热补丁而受到严重的影响。大量涉及客诉升级的工单纷至沓来，要求恢复服务或交付缺失的功能。大家都在发表高见，指出应该如何改善现状。然而，一旦再次出现故障，他们可能又有新的想法。
我曾经连续几年参加QCon伦敦大会。通过这个会议，我了解了软件开发和运行的新趋势。SRE是大会的主题之一。我虽然知道SRE，但并没有真正理解。在一次QCon大会上，有个分论坛的主题是SRE。我花了相当多的时间参加了相关的会议。在会议结束时，我清楚地认识到了SRE的行业发展势头。
大会结束后，我在回公司的路上翻看自己做的笔记，意识到是时候尝试在组织内应用SRE来改善服务运行了。我没有见过其他结构化的运行方式。在没有采用SRE的情况下，我们自己的尝试并没有带来明显的改善。在大会上，许多人在做报告的时候，都说自己公司成功应用了SRE服务运营方式——无论这些成功具体是指什么。开始的时候似乎都很容易，只需要设定几个基本的指标（比如可用性和延迟），为每个服务定义可接受的目标，并在违反目标时发出警报。
回到工作岗位后，我开始思考如何在组织内推动SRE。通过深入思考，我发现这需要整个组织的参与。我首先想到下面几个问题。
如何争取组织内部对SRE的支持？
如何让领导团队参与进来？
如何让运营团队参与进来？
如何让开发团队参与进来？这些团队的数量越来越多，很快就会达到20个甚至更多。如果是这样，如何在一个不断增长的组织中推动SRE并以一种能够随着团队数量增加而扩展的方式？
SRE发展到更高层次会怎样？
为什么它能发挥作用？
我怎样才能学到更多关于SRE的知识？
我怎样才能学到足够多的SRE知识，以便快速、轻松地向别人解释它？
是否有可以替代SRE的方法？
怎样才能与那些已经在其组织中引入SRE的人接触？
在组织中引入SRE的常见陷阱是什么，如何避免？
带着这些问题，我进行了深入的思考，最终成功地将SRE融入组织的开发团队和运营团队，并使其成为两个部门的核心学科，以可度量的方式极大地提高了我们运营全球化云平台的能力。
此外，组织与许多云端应用开发的团队保持联系。如何有效运行这些应用是这些团队共同面对的问题。我们现在将SRE选作首选运行方法。团队了解了之后，就导入SRE并使用我们提供的SRE基础设施。
在SRE转型期间，我们有机会拜访了柏林的Delivery Hero公司。他们的运营算得上是世界级水平。通过向他们学习，我们获得很大的启发。后来，看到我们自己的团队也逐渐接近世界级水平时，我们备受鼓舞。
回顾往事，我们学到很多经验。为了将SRE规模化导入从未做过运营的开发组织和一个从未让别人做过运营的运营组织，我们需要做许多事情。它要求开发团队长期深度参与并辅导团队，使其在运营能力方面越来越成熟。同时，它要求与运营团队长期接触并辅导他们成为SRE基础设施框架供应商，使开发团队也能参与运营。为了完成转型，需要在开发和运营两个方面，以独特的方式对技术、人员、文化和流程等领域发生的变革进行融合。
我们开始在InfoQ上发布系列文章（主题为数据驱动决策），分享我们在SRE方面的经验，后来又以电子杂志的形式发布。该系列文章中的SRE文章受到广泛的关注，有人找到我，邀请我写一本介绍SRE转型的书。至于剩下的事情，大家都知道了。
对我来说，与Addison-Wesley合作是一种莫大的荣幸。在大学学习计算机科学时，我读了他们出版的很多专业书，以至于我在图书馆里老远就能认出来哪些书是他们出版的。因此，一旦有机会成为他们的作者，我肯定是毫不犹豫地接受邀约。
在一个节奏非常快、经验并不总是特别宝贵的行业中，拥有一些可能值得通过书籍来分享的知识，也是一种荣幸。当然，由于这个行业的节奏和对新事物的偏爱，我有些担心自己的知识不够完整，没准儿很快会过时。另外，我似乎是为数不多的且从未与谷歌合作却敢于写书来谈SRE的人。
不过，我的写作动机在广泛的阅读和丰富的专业实践中愈发强烈。我激励自己，这不仅是对软件工程社区的回馈，更是致敬过去十几年那些通过无数好书和讲座来影响我的作者和讲师。在这个数字干扰无处不在的世界，能够全心投入一个需要高度专注的项目，无疑是一种难得的特权。写书正是这样的过程。它教会我如何抵御数字干扰，让我迅速集中注意力，使我的专注力仿佛回到了互联网诞生之前。
我写这本书的目的是支持那些准备导入SRE（Site Reliability Engineering）理念的组织。这个旅程虽然有极大的价值，但同样充满挑战，需要长期坚持，才能填平过程中遇到的很多坑。导入SRE意味着产品/服务运行在文化、组织结构、责任分配、实践方法和技术应用上需要进行变革。对于用户和客户，产品运行至关重要，因为他们接触到的只有实际运行的产品。因此，优化生产流程直接关系到用户体验和客户满意度的提升。本书将探讨如何以可度量的方式改善用户体验和客户满意度、如何建立SRE基础设施来实现目标以及如何推动组织的SRE转型之旅。
本书分为三个核心部分。第Ⅰ部分中，大致介绍SRE的概念、作用及其在软件运行领域中的地位。同时，我还要概述组织刚接触SRE时所面临的挑战，解释如何从运行和SRE转型准备的角度评估组织的现状。
第Ⅱ部分中，介绍如何着手启动并推进转型。要想确保SRE转型成功，一开始就需要获得组织上下广泛的认同。在这部分中，将解释如何实现这种认同、如何在团队中启动转型活动并确保组织能够建立警报系统、轮班制度和有效的事故响应流程。完成这些步骤，意味着组织已经为导入SRE做好了准备。
随后，继续探讨如何实施更高级的SRE实践，包括错误预算策略和基于错误预算的决策。完成这些实践后，便建成了一个成熟的SRE组织结构。在这部分的结尾，组织不仅建立了基础和高级的SRE实践，还建立了长期可持续的组织结构。
第Ⅲ部分中，将讨论如何度量SRE转型的成功以及如何保持SRE实践。在本书的最后一章，我将展望SRE转型的未来之路。
本书的结构如下表所示。
元素 说明
要点 由书中的讨论所划出的重点，和别人闲聊SRE时要记住这些要点
SRE误区 书中揭穿了行业中一些普遍存在的关于SRE的误区
SRE参考 对一些SRE主题的简短解释，方便快速参考
实战经验 一些故事或见解，基于在SRE转型和实践过程中得到的经验和教训。描述了一个组织在特定情况下真正发生的事情
如果在阅读本书的过程中遇到任何问题，欢迎随时通过领英（LinkedIn）与我联系，我期待收到您的反馈和宝贵意见！
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
