新書推薦：
《
二十四节气生活美学
》
售價：NT$
340.0
《
西班牙内战：秩序崩溃与激荡的世界格局：1936-1939
》
售價：NT$
990.0
《
基于鲲鹏的分布式图分析算法实战
》
售價：NT$
495.0
《
夺回大脑 如何靠自己走出强迫
》
售價：NT$
299.0
《
图解机械工程入门
》
售價：NT$
440.0
《
中文版SOLIDWORKS 2024机械设计从入门到精通（实战案例版）
》
售價：NT$
450.0
《
旷野人生：吉姆·罗杰斯的全球投资探险
》
售價：NT$
345.0
《
希腊人（伊恩·莫里斯文明史系列）
》
售價：NT$
845.0
|
| 編輯推薦： |
一线运维大咖十多年的运维经验总结，带你避开运维路上的那些坑；
从大公司的案例看运维，直击运维本质，换个角度看运维；
从应用运维体系建设到效率和稳定性实践，理论结合实践，全面解读运维体系建设；
云计算和人工智能时代，该如何做好运维的转型和提升，运维人员该何去何从。
|
| 內容簡介： |
|
本书整体包含四大部分内容：应用运维体系建设、效率和稳定性*实践、云计算时代的运维实践以及运维人员的个人成长。应用运维体系建设部分从运维的本质开始讲起，到运维体系的基本建立和运维组织架构和模式的解读，介绍如何一步步建立运维技术体系和组织架构，如何树立正确的运维建设思路，系统讲解了运维工作的基础。效率和稳定性*实践部分是运维价值的体现，将围绕持续交付、稳定性保障和故障管理，分享如何打造不需要任何运维参与的端到端交付过程，以及如何在实践中锤炼出稳定性保障体系、有效进行故障管理等内容。云计算时代的运维实践部分是新时代运维升级转型的必备要求，将分享在混合云、云存储、静态化以及 CDN 上的实践经验，以及这些实践所带来的巨大收益。运维人员的个人成长作为和运维人员软实力息息相关的一部分，将会分享作者的一些深度思考，包括运维技术发展趋势、个人成长等。
|
| 關於作者： |
|
赵成，是公众号“Forrest 随想录”的作者，多届 ArchSummit 运维专题明星讲师和优秀出品人，TGO 杭州分会会员。目前专注于云计算和人工智能时代的运维转型和提升。加入蘑菇街之前，赵成在华为工作了七年，经历过开发、测试、运维以及一线客户服务等诸多岗位。他在不断的历练中迅速成长，培养了全面思考的意识和能力，积累了丰富的电信级和互联网业务研发及运维经验。赵成说他踏上运维之路有很大的偶然性，第一，不忍心看着自己跟团队开发出来的系统到了线上总是出问题，所以每当有问题时，他总是第一个冲在前面解决问题，久而久之，便积累了丰富的经验，也成为团队中比较重要的角色；第二，也是更重要的一个因素，他说自己非常享受那种攻克难题之后的成就感。
|
| 目錄：
|
第1章 运维的本质
1.1 顶级公司的运维定义 2
1.1.1 没有运维的Netflix 2
1.1.2 Netflix是如何成为行业典范的 3
1.1.3 总结 7
1.2 运维体系建设的核心概念：应用 7
1.2.1 应用的起源 8
1.2.2 应用模型及关系模型的建立 9
1.2.3 微服务架构时代下为什么要以应用为核心 12
第2章 运维体系建设
2.1 标准化体系建设基础 16
2.1.1 标准化的原因和步骤 16
2.1.2 基础设施层面的标准化 17
2.1.3 应用层面的标准化 19
2.1.4 总结 21
2.2 标准化体系建设实践：基础架构标准化 22
2.2.1 常见的分布式基础架构组件 23
2.2.2 基础架构组件的选型问题 24
2.2.3 基础架构的服务化 26
2.2.4 运维的职责 27
第3章 配置管理数据库（CMDB）
3.1 CMDB的前世今生 36
3.1.1 CMDB源起 36
3.1.2 传统运维思路下的CMDB 37
3.1.3 互联网运维体系下的CMDB 39
3.1.4 CMDB进行时 40
3.2 有了CMDB，为什么还需要应用配置管理 41
3.2.1 CMDB是面向资源的管理，是运维的基石 42
3.2.2 应用配置管理是面向应用的管理，是运维的核心 43
3.2.3 总结 45
3.3 在CMDB中落地应用的概念 46
3.3.1 如何有效组织和管理应用 46
3.3.2 应用的集群服务分组建设 49
3.3.3 CMDB在基础服务体系中的核心位置 51
3.3.4 总结 54
第4章 运维组织架构及模式
4.1 运维组织架构和转型 56
4.1.1 自助化运维能力的建设 56
4.1.2 从价值呈现的角度看运维 57
4.1.3 运维协作模式的改变 59
4.1.4 运维的组织架构 61
4.1.5 总结 62
4.2 Google SRE的运维模式 63
4.2.1 SRE岗位的定位 63
4.2.2 SRE岗位的职责 64
4.2.3 如何借鉴和落地 67
4.3 从Google CRE谈运维的服务意识 67
4.3.1 CRE产生的背景 68
4.3.2 CRE岗位的职责 69
4.3.3 从CRE谈谈做运维为什么要有服务心态 70
4.4 云计算和AI时代下的运维转型 73
4.4.1 应用运维的转型 75
4.4.2 云计算和AI带给我们的挑战 78
4.4.3 总结 80
第5章 持续交付
5.1 提升效率，为什么要先做持续交付 84
5.1.1 什么是持续交付 85
5.1.2 持续交付的关键点 86
5.2 持续交付的第一关键点：配置管理 88
5.2.1 版本控制 89
5.2.2 依赖管理 90
5.2.3 软件配置 91
5.3 多环境配置管理 94
5.3.1 多环境问题 94
5.3.2 不同环境下的应用配置管理 95
5.3.3 环境配置管理解决方案 96
5.3.4 总结 100
5.4 多环境建设 101
5.4.1 环境分类 101
5.4.2 线下环境分类建设 102
5.4.3 环境建设上的关键技术点 106
5.4.4 总结 109
5.5 线上环境建设 110
5.5.1 生产环境 110
5.5.2 Beta环境 112
5.5.3 预发环境 113
5.5.4 办公网生产环境 116
5.5.5 总结 117
5.6 流水线模式 118
5.6.1 持续交付流水线简要说明 119
5.6.2 项目需求分解 119
5.6.3 提交阶段之开发模式选择 121
5.6.4 开发模式的选型原则 123
5.7 流水线软件构建 125
5.7.1 构建环节 126
5.7.2 几个关键问题 127
5.8 流水线构建完成后的质量保障 131
5.8.1 依赖规则限制 131
5.8.2 功能测试 132
5.8.3 非功能测试 133
5.8.4 总结 135
5.9 持续交付实践：根据业务场景找方案 136
5.9.1 软件的持续部署发布 137
5.9.2 发布策略 139
5.9.3 持续交付体系的收益 141
5.9.4 总结 141
第6章 稳定性保障
6.1 极端业务场景下的稳定性保障 144
6.1.1 我们所面对的极端业务场景 144
6.1.2 技术上的挑战 146
6.1.3 极端业务场景下的不确定因素 148
6.2 稳定性实践 150
6.2.1 容量规划 150
6.2.2 限流降级 160
6.2.3 开关和预案 167
6.2.4 全链路跟踪系统 172
第7章 故障管理
7.1 我对故障的理解 182
7.2 故障定级和定责 186
7.2.1 故障的定级标准 187
7.2.2 故障的定责标准 189
7.3 故障定责的目的 192
7.3.1 关于定责和处罚 192
7.3.2 目的是鼓励做事，而不是处罚错误 194
7.3.3 处罚的负作用远超我们的想象 196
7.4 故障应急和故障复盘 197
7.4.1 故障应急 198
7.4.2 故障复盘 201
7.4.3 定期总结故障案例 203
7.4.4 总结 204
第8章 云运维的技术选型
8.1 为什么蘑菇街会选择上云 206
8.1.1 我们所面临的问题 206
8.1.2 纵观技术发展趋势 211
8.1.3 没有银弹 212
8.2 为什么混合云是未来云计算的主流形态 213
8.2.1 关于混合云 213
8.2.2 我们所经历的几个基础设施建设阶段 215
8.2.3 总结 219
8.3 面向应用层的云架构解决方案：Spring Cloud 219
8.3.1 Spring Cloud框架中云的影子 220
8.3.2 CNCF 223
8.3.3 可以预见的技术发展趋势 224
8.4 云计算时代的弹性伸缩 225
8.4.1 弹性伸缩的主体是谁 225
8.4.2 总结 228
第9章 CDN
9.1 从CDN和云存储来聊聊云生态的崛起 230
9.1.1 CDN和云存储 230
9.1.2 云生态的优势 231
9.1.3 总结 234
9.2 页面静态化架构和二级CDN建设 235
9.2.1 静态化架构建设的业务场景 235
9.2.2 页面静态化架构 237
9.2.3 静态化架构在大促场景中的应用 239
9.2.4 二级CDN建设 240
9.2.5 总结 241
第10章 运维人员的成长之路
10.1 我是如何走上运维岗位的 244
10.1.1 我是怎么开始做运维工作的 244
10.1.2 我为什么会把运维当作职业发展的方向 247
10.1.3 给我们的一点启发 251
10.2 运维需要懂产品和运营吗 252
10.2.1 运维的角色转变和价值体现 253
10.2.2 技术产品 254
10.2.3 技术运营 254
10.2.4 总结 256
10.3 从技术到管理，如何转身 257
10.3.1 从员工离职说起 257
10.3.2 关于员工离职的两个观点 258
10.3.3 谈谈如何做好技术管理 259
10.3.4 技术管理中引以为戒的一些反模式 261
10.3.5 总结 262
10.4 树立个人品牌意识 263
10.4.1 对求职者的背景调查 263
10.4.2 如何树立个人口碑 265
10.4.3 要引以为戒的反例 266
10.4.4 共勉 268
拓展阅读：运维与安全
|
| 內容試閱：
|
自序
你好，我是赵成，来自美丽联合集团，集团旗下两大主力产品是蘑菇街 和美丽说，我目前负责管理集团的技术服务团队。
本书的内容主要来自我在极客时间的专栏《赵成的运维体系管理课》。
当我写完专栏时，我的专栏编辑李佳告诉我文章可以集结成书出版，这 时我才意识到，原来我在写作专栏文章的过程中，已经不知不觉地将一个相 对比较完整的运维体系输出了，当时的感觉：一切都是水到渠成的。
所以，这里首先要感谢极客时间这样一个优秀的、为技术人服务的知识 内容平台，我不但从极客时间中学到了很多知识，而且对于我个人而言，它 也是一个舞台，能够让我将个人的实践、经验和总结通过最有价值、最有效 的传播方式呈现出来。如果没有这样一个舞台，本书中的内容可能还要延期 很长时间才能面世。
与极客时间结缘，是在 2017 年的 QCon 上海大会前夕，我接到了极客 时间团队的邀请，问我是否可以做一个运维专栏，我当时的第一反应是有些 兴奋，这还真是一个意外的邀请。但是接来下我的反应就是诚惶诚恐，因为 我自己写公众号也有一段时间了，深知持续高质量输出这件事情的挑战之大， 特别是在输出专业文章上更是如此，所以当时一直拿不定主意。
我写公众号文章，在很大程度上是因为之前有过很多次公开演讲和分享的经历，后来发现演讲所面向的受众和时间有限，分享的内容无论是在传播的广度还是内容的深度上，都会受到很大的限制。总之，讲得不过瘾，索性就把一些我觉得还值得更深入探讨的话题和内容完完整整地写出来。
后来，在上海跟极客时间团队见面之后，他们给了我一些建议，因为之前的文章更多是针对一个个观点延伸出去写作，而专栏文章可以尝试更系统地输出，能够把一个运维体系讲透彻。这个建议从一定程度上打开了我写专栏的思路，后来我把内容规划了一下，感觉还是可以输出一些更有价值的内容的，因此就启动了这个专栏的策划。
再后来，就有了本书的全部内容。
这里要特别感谢在我写作专栏和出版图书的过程中帮助和支持过我的人。
感谢我专栏中的读者，你们的信任和反馈是对我最大的支持，也是对我最大的督促，没有你们，就不会有本书高质量的内容输出。
感谢我的专栏编辑李佳，从专栏策划之初就协助我做了大量的内容策划、制作、校订以及各种协调的工作，直至图书出版；感谢极客时间团队，正是因为有了你们，才有了如此优秀的产品。
感谢我的图书编辑侠少和恩惠，帮我进行图书内容的策划和制作，我们相识已久，这次终于有机会合作。
感谢蘑菇街，正是基于这样一个非常优秀的平台，我才得以有机会不断地实践和尝试，也感谢我团队所有的小伙伴，本书所呈现的成果是我们共同努力和实践的结果。
最后，感谢我的妻子朱悦和我的家人，无论在工作还是生活中，你们给予了我最无私的支持。我把本来应该陪伴你们的时间用来写作，感谢你们的理解和奉献。
一路走来，有你们相伴，就是最幸福和开心的事情。
赵成
2018年4月13日于杭州
前言
谈谈运维的价值
我们在大学的软件工程课程中学过，从软件生命周期的角度看，软件开 发阶段只占整个生命周期的 20%~30%，软件运行维护阶段是最长尾的，这 条规律放在当前这个时代同样适用。
Bob 大叔，Robert C.Martin，在其最新图书 Clean Architecture（中文版 由电子工业出版社出版）中对软件架构的目的给出了他的理解：
软件架构的目的，是将构建和维护所需的人力资源降到最低。
一语中的，直击本质。本书的全部内容基本都是围绕着这句话展开的， 我想正对应了万变不离其宗这条规律。
在软件生命周期中，我们可以很清晰地划分出开发阶段和运维阶 段，这个分界点就从开发人员完成代码开发，测试人员验收通过后，交付 到运维人员手上的软件包开始，自此之后的阶段就是软件的运行维护阶段了。
一家公司对于开发的诉求应该是全力实现业务需求，并将需求尽快发布 上线以实现商业上的收益。但是，在一家公司里，除了专注于业务需求的开 发和测试角色，还会有另外一大类开发，比如我们常见的中间件开发、稳定 性开发、工具开发、监控开发、IaaS或PaaS平台开发，甚至专注于底层基础架构的内核开发、网络开发、协议开发等。
如果仔细思考，我们会发现除了业务开发和测试，前面所提到的那些技术岗位都是为软件生命周期中的运行维护阶段服务的，这些角色的作用就是提升研发效率和稳定性，进而降低成本。虽然它们并没有全部被定义为运维岗位，但是本质上它们是跟业务软件的运行维护阶段直接相关的。
所以，从运维的范畴来讲，我认为，在一个研发团队内，除去业务需求实现层面的事情，其他都是运维的范畴，实质是软件架构的范畴，它们都在为软件生命周期中的运行维护阶段服务。
我之前在外部分享中一直表达的一个观点就是，运维能力是整体技术架构能力的体现，运维层面爆发的问题或故障一定是因为整体技术架构中存在问题，割裂两者，单纯地看技术架构或运维都是毫无意义的。
但是，我们在绝大多数情况下都忽略了这个隐藏在软件生命周期中真正的运维范畴，而是简单直接地从软件生命周期分段的角度，生硬地给开发和运维划定了一条界线。
我认为，跳出运维看运维，从架构角度看运维，这种运维思路上的转变，远比单纯提升运维技术更有价值。
而这也正是我们很多公司和团队当前存在的最大的痛点和问题。所以，在本书中，我会针对这些痛点和问题分享一些我的思考。
图书内容结构
本书的内容会聚焦在分布式软件架构下的应用运维这个领域，更多的是我对运维的一些架构思考，主要可以分为以下四个部分。
（1）应用运维体系建设，包括第1章~第4章的内容。这是我们做运维的基础，我会首先分享运维的本质是什么，明确运维的核心概念，并从标准化和应用生命周期开始，讲述如何一步步建立运维技术体系和组织架构，整个过程中的沟通协作以及我们应该如何树立正确的运维建设思路等方面的内容。
（2）效率和稳定性等方面的最佳实践，包括第5章~第7章的内容。这些是运维价值的体现，我会围绕持续交付、稳定性建设以及故障管理三个方面，分享如何打造不需要任何运维参与的端到端交付过程，如何在实践中锤炼出稳定性保障体系，以及如何看待故障并做好故障管理。
（3）云计算方面的思考和实践，包括第8章和第9章的内容。云计算技术的蓬勃发展为我们的业务和技术提供了更多的可能性，利用好云这个平台将会是运维升级转型的必备要求。我会分享在混合云、云存储、静态化以及CDN上的实践经验，以及这些实践给成本和体验带来的巨大收益。
（4）个人成长与趋势热点分析，在第10章进行分享。这一部分更多的会是我个人的一些思考，包括运维技术发展趋势、团队管理、个人成长、热门事件解析、观点碰撞等。
另外，由于运维和安全之间有着密不可分、唇亡齿寒的关系，在工作中也有较多的交集，因此，我将运维与安全作为拓展阅读放于本书的最后，希望能引发大家更多的思考。
最后，开卷有益，期望本书能够带给你不一样的运维思考，共同进步。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
