登入帳戶　 |　訂單查詢　 |　購物車/收銀台( 0 )　|　在線留言板　 |　付款方式　 |　運費計算　 |　聯絡我們　 |　幫助中心　|　 加入書簽
會員登入 新用戶登記
HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類瀏覽雜誌 臺灣用戶
品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心 服務：香港／台灣／澳門／海外 送貨：速遞／郵局／服務站

新書上架：簡體書 繁體書
暢銷書架：簡體書 繁體書
好書推介：簡體書 繁體書

三月出版：大陸書 台灣書
二月出版：大陸書 台灣書
一月出版：大陸書 台灣書
12月出版：大陸書 台灣書
11月出版：大陸書 台灣書
十月出版：大陸書 台灣書
九月出版：大陸書 台灣書
八月出版：大陸書 台灣書
七月出版：大陸書 台灣書
六月出版：大陸書 台灣書
五月出版：大陸書 台灣書
四月出版：大陸書 台灣書
三月出版：大陸書 台灣書
二月出版：大陸書 台灣書
一月出版：大陸書 台灣書

『簡體書』运维困境与DevOps破解之道

書城自編碼： 3697403
分類：簡體書→大陸圖書→計算機/網絡→计算机理论
作者： [美]杰弗瑞·史密斯[Jeffery D. Smith]著
國際書號(ISBN)： 9787302592716
出版社： 清华大学出版社
出版日期： 2021-11-01

頁數/字數： /
書度/開本： 16开 釘裝： 平装

售價：HK$ 119.6

我要買 件

 

** 我創建的書架 **
未登入.

新書推薦：
这就是心理咨询：全球心理咨询师都在用的45项技术（第3版）
《 这就是心理咨询：全球心理咨询师都在用的45项技术（第3版） 》
售價：HK$ 153.6
正说清朝十二帝（修订珍藏版）
《 正说清朝十二帝（修订珍藏版） 》
售價：HK$ 105.6
黑海史：从历史涟漪到时代巨浪
《 黑海史：从历史涟漪到时代巨浪 》
售價：HK$ 115.2
我，毕加索
《 我，毕加索 》
售價：HK$ 60.0
投资真相
《 投资真相 》
售價：HK$ 81.6
非洲大陆简史（萤火虫书系）
《 非洲大陆简史（萤火虫书系） 》
售價：HK$ 93.6
知宋·宋代之军事
《 知宋·宋代之军事 》
售價：HK$ 94.8
我能帮上什么忙？——一位资深精神科医生的现场医疗记录（万镜·现象）
《 我能帮上什么忙？——一位资深精神科医生的现场医疗记录（万镜·现象） 》
售價：HK$ 81.6

 
建議一齊購買：

+

HK$ 226.8
《 计算机科学中的数学：信息与智能时代的必修课 》		 +

HK$ 91.5
《 区块链技术及应用（第二版） 》		 +

HK$ 108.6
《 区块链概论 》		 +

HK$ 64.0
《 计算机组成原理（第3版） 》		 +

HK$ 104.3
《 CAN总线嵌入式开发--从入门到实践（第3版） 》		 +

HK$ 159.3
《 知识图谱：方法、实践与应用 》
編輯推薦：
从某种程度上讲，所有组织都遭受着糟糕的开发实践、混乱的信息沟通以及陈旧的遗留系统带来的困扰，你所在的组织也不例外。DevOps可以帮助你改进流程，但首先需要识别出阻碍你的核心问题。本书使你能够利用有限的资源进行DevOps交付，同时驾驭实际工作中司空见惯的办公室政治和根深蒂固的思维模式。
　　《运维困境与DevOps破解之道》为开发和沟通的转型提供了清晰的步骤，书中使用通俗的语言描述了能够即刻见效的渐进式技术，帮助你简化工作流程、管理计划外时间和建立运营指标。无论你遇到什么问题，本书观点对于组织的成功都具有积极的意义。
內容簡介：
主要内容
●　化失败为机遇
●　通过文化推动变革
●　打破知识孤岛
●　解决中层管理人员的地盘之争
關於作者：
Jeffery D. Smith 已经在技术领域工作了超过20 年，他一直在管理层岗位和个人贡献者身份之间切换，目前在总部位于伊利诺伊州芝加哥的广告软件公司Centro 担任生产运维总监。
Jeffery 对各类组织中的DevOps 转型充满热情，对公司中心理学层面的问题尤为感兴趣。他和妻子Stephanie 以及他们的两个孩子居住在芝加哥。
目錄：
目 录
第1 章 DevOps 要素 1
1.1 DevOps 的概念 2
1.1.1 有关DevOps的历史 2
1.1.2 DevOps 不是什么 3
1.2 DevOps 的支柱CAMS 5
1.3 关于本书 6
1.4 小结 6
第2 章 家长制综合征 9
2.1 创建壁垒而非安全防护措施 10
2.2 引入把关者 13
2.3 审视把关者 14
2.4 通过自动化治疗家长式作风 17
2.5 捕捉审批的动因 19
2.6 为自动化构建代码 19
2.6.1 审批流程 20
2.6.2 自动化审批 22
2.6.3 日志流程 25
2.6.4 通知流程 26
2.6.5 错误处理 27
2.7 确保持续改进 28
2.8 小结 28
第3 章 运维盲区 29
3.1 作战故事 29
3.2 改变开发和运维职责范围 30
3.3 了解产品 31
3.4 打造运维可视化 32
3.4.1 创建自定义指标 33
3.4.2 决定度量内容 34
3.4.3 定义健康指标 37
3.4.4 失效模式和影响分析 38
3.5 让日志发挥作用 41
3.5.1 日志聚合 41
3.5.2 应该记录的内容 43
3.5.3 日志聚合的缺点 45
3.6 小结 48
第4 章 数据代替信息 49
4.1 从用户而不是数据开始 49
4.2 小部件(仪表盘构建块) 51
4.2.1 折线图 51
4.2.2 柱状图 53
4.2.3 仪表 54
4.3 为小部件提供上下文 54
4.3.1 通过颜色提供上下文 55
4.3.2 通过阈值线提供上下文 55
4.3.3 通过时间比较提供上下文 56
4.4 组织仪表盘 57
4.4.1 处理仪表盘行 57
4.4.2 引导用户 58
4.5 命名仪表盘 59
4.6 小结 60
第5 章 把质量当成调味品 61
5.1 测试金字塔 62
5.2 测试结构 64
5.2.1 单元测试 64
5.2.2 集成测试 67
5.2.3 端到端测试 68
5.3 对测试套件的信心 71
5.3.1 恢复对测试套件的信心 71
5.3.2 避免虚荣指标 74
5.4 持续部署与持续交付 75
5.5 特性标志 77
5.6 执行流水线 78
5.7 管理测试基础设施 81
5.8 DevSecOps 82
5.9 小结 84
第6 章 警报疲劳 85
6.1 作战故事 86
6.2 值班人员轮换的目的 87
6.3 值班人员轮换的定义 88
6.3.1 确认时间 89
6.3.2 开始时间 89
6.3.3 解决时间 90
6.4 定义警报的标准 90
6.4.1 阈值 91
6.4.2 嘈杂的警报 92
6.5 配置值班轮换 95
6.6 值班报酬 97
6.6.1 货币报酬 97
6.6.2 休假 98
6.6.3 增加在家工作的灵活性 99
6.7 值班的体验 100
6.7.1 向谁发出警报 100
6.7.2 警报的紧急程度是怎样的 100
6.7.3 如何发送警报 101
6.7.4 何时通知团队成员 101
6.8 提供其他值班的任务 102
6.8.1 值班支持项目 102
6.8.2 性能报告 103
6.9 小结 104
第7 章 一无所有的工具箱 105
7.1 内部工具和自动化的重要性 107
7.1.1 自动化带来的改进 107
7.1.2 自动化对业务的影响 108
7.2 组织没有实现更多自动化的原因 111
7.2.1 将自动化设为文化上的优先事项 111
7.2.2 自动化和工具化的人员配置 113
7.3 修复文化层面的自动化问题 115
7.3.1 不允许手动任务 115
7.3.2 支持“不”作为答案 115
7.3.3 手动作业的成本 117
7.4 优先考虑自动化 120
7.5 定义自动化目标 121
7.5.1 将自动化作为所有工具的要求 121
7.5.2 在工作中优先考虑自动化 122
7.5.3 把自动化作为员工的优先事项 123
7.5.4 为培训和学习提供时间 124
7.6 填补技能体系缺口 125
7.6.1 加强团队之间的技术协作 127
7.6.2 构建新的技能体系 128
7.7 达到自动化 129
7.7.1 任务中的安全性 130
7.7.2 安全性设计 131
7.7.3 任务的复杂性 133
7.7.4 任务评级的方法 134
7.7.5 自动化简单任务 135
7.7.6 自动化繁杂任务 137
7.7.7 自动化复杂任务 139
7.8 小结 139
第8 章 非工作时间部署 141
8.1 作战故事 141
8.2 分层部署 143
8.3 使部署成为日常事务 145
8.3.1 精确的准生产环境 145
8.3.2 准生产环境永远不会和生产环境完全一样 148
8.4 频率可减少恐惧 149
8.5 通过降低风险减少恐惧 152
8.6 处理部署流程中的各层失败 153
8.6.1 特性标志 153
8.6.2 何时关闭特性标志 154
8.6.3 队列回滚 156
8.6.4 部署制品回滚 158
8.6.5 数据库级回滚 159
8.7 创建部署制品 162
8.7.1 利用包管理 163
8.7.2 包中的配置文件 167
8.8 自动化部署流水线 170
8.9 小结 172
第9 章 浪费一次完美的事故 173
9.1 好的事后剖析的组成部分 174
9.1.1 创建心智模型 175
9.1.2 遵循24 小时规则 176
9.1.3 制定事后剖析规则 177
9.2 事故 178
9.3 开展事后剖析 178
9.3.1 选择参与事后剖析的人员 178
9.3.2 整理时间线 179
9.3.3 定义和跟进行动事项 185
9.3.4 记录事后剖析 187
9.3.5 分享事后剖析 190
9.4 小结 190
第10 章 信息囤积 191
10.1 理解信息囤积的发生机制 192
10.2 识别无意囤积者 193
10.2.1 文档不受重视 193
10.2.2 抽象与混乱 195
10.2.3 访问限制 197
10.2.4 评估把关者行为 198
10.3 有效进行沟通 198
10.3.1 明确主题 199
10.3.2 明确受众 199
10.3.3 勾勒要点 199
10.3.4 提出行动号召 200
10.4 让你的知识可以被发现 200
10.4.1 组织你的知识库 200
10.4.2 建立学习仪式 205
10.5 有效使用聊天工具 210
10.5.1 建立公司制度 210
10.5.2 超越聊天 212
10.6 小结 213
第11 章 法令文化 215
11.1 文化的本质 216
11.1.1 文化价值观 216
11.1.2 文化仪式 217
11.1.3 潜在假设 218
11.2 文化如何影响行为 219
11.3 如何改变文化 220
11.3.1 分享文化 220
11.3.2 一个人可以改变一种文化 223
11.3.3 检查公司的价值观 224
11.3.4 创造仪式 226
11.3.5 用仪式和语言改变文化规范 228
11.4 符合文化的人才 229
11.4.1 旧角色，新思维 230
11.4.2 对高级工程师的痴迷 231
11.4.3 面试候选人 234
11.4.4 评估候选人 238
11.4.5 面试的候选人数量 239
11.5 小结 240
第12 章 过多标尺 241
12.1 目标层级 242
12.1.1 组织目标 243
12.1.2 部门目标 243
12.1.3 团队目标 244
12.1.4 获取目标 245
12.2 对自己工作的觉察 245
12.2.1 优先级、紧迫性和重要性 246
12.2.2 艾森豪威尔决策矩阵 247
12.2.3 如何拒绝允诺 248
12.3 组织团队工作 251
12.3.1 对工作进行时间分割 251
12.3.2 填充迭代 252
12.4 计划外工作 253
12.4.1 控制计划外工作 254
12.4.2 处理计划外工作 257
12.5 小结 259
结语 261
內容試閱：
《运维困境与DevOps 破解之道》旨在帮助个人贡献者和团队领导开始一系列行动，以实现DevOps 转型。本书从建立DevOps 转型的主要支柱开始讲解，并且试图在这些内容中定位组织问题。
本书读者对象
本书是为技术团队的运维或开发工程师准备的，目标读者是团队领导和个人贡献者。更高层的管理者和高级领导会在本书中找到许多有用的启示，但本书所概述的解决方案和方法侧重于有限的读者角色。组织中更高层级的领导者可选择的工具更为广泛，而本书并未涵盖这些工具。
如果你是一位希望实现DevOps 的高管，本书会很有帮助，但还不够全面。
高管人员所能触及的文化变革超出了本书的讨论范围。虽然我仍然建议你阅读本书，但考虑到你作为变革推动者的权力范围，我想向你推荐另外两本不错的书。
一本是Gene Kim、Kevin Behr 和George Spafford 合著的The Phoenix Projects(IT Revolution Press，2018)；另一本是Gene Kim、John Willis、Patrick Debois 和Jez Humble 合著的The DevOps Handbook(IT Revolution Press，2016)。
本书的组织方式
本书围绕组织中常见的一系列反模式进行组织。每一章都从反模式的定义开始，然后解释反转所述模式的方法和解决方案。
● 第1 章讨论一个DevOps 组织的组成要素并引出DevOps 社区中通用的术语。
● 第2 章提出个反模式“家长制综合征”并深入探讨低信任组织的影响；考察把关者在工作过程中的作用及其对变更速度的影响。本章讨论了如何通过自动化处理这些把关者关注的问题以赋能员工，并且安全地提高变更率。
● 第3 章描述“运维盲区”反模式，并且讨论系统运维可视化的需求。通过对系统的理解以及数据和度量来验证系统是否按预期工作。
● 第4 章介绍“数据代替信息”反模式，讨论如何以一种使数据对其受众更有用的方式来构建和呈现它。有时数据是有用的，但其他时候它需要以一种传递特定故事的方式呈现。
● 第5 章介绍“把质量当成调味品”反模式并讨论确保系统质量是所有独立要素之一的必要性。企图在整个过程的后确保质量会导致质量上的某种戏剧性效果。
● 第6 章定义“警报疲劳”反模式。当团队支持生产系统时，他们通常会建立各种各样的警报。但是，当这些警报发出噪声却不需要治理时，则会是有害的。本章讨论通过更仔细地创建警报并了解警报的真正目标来解决这种情况的方法。
● 第7 章诠释“一无所有的工具箱”反模式。随着角色或职责的扩展，团队将时间和精力投入到他们用于履行职责的工具中是很重要的。在没有相应工具化的情况下增加责任范围会导致团队在执行重复性任务时速度普遍变慢。
● 第8 章介绍“非工作时间部署”反模式，并且讨论对部署流程的恐惧。本章讨论的不是管理恐惧，而是如何打造安全的部署过程。通过自动化并借助明确的回滚检查点，可以创建可重复的部署过程。
● 第9 章讲述“浪费一次完美的事故”反模式。许多事件得到了解决，但从未被讨论过。当我们对系统的理解与实际有冲突时，事故就会发生。本章给出一个结构化的方法来处理这种状况，从而在你的组织中创造持续学习。
● 第10 章讨论“信息囤积”反模式。有时信息囤积是偶然的，源于工具中的权限许可、缺乏分享的机会以及其他非恶意的原因。本章介绍减少信息囤积和增加团队间共享的实践。
● 第11 章讲述组织文化及其形成方式。文化不是通过口号和价值陈述创造的，而是通过行动、仪式以及受到奖励和/或惩罚的行为创造的。
● 第12 章讲述组织如何衡量并设定团队目标。有时这些度量会造成团队间的冲突，例如你用稳定性衡量一个团队，用变化率衡量另一个团队，就会造成团队间的冲突。本章介绍共享目标和优先级排序，以更好地协调团队。
总体而言，这些章节可以按照任何顺序分别阅读，尽管有些概念偶尔会建立在其他概念的基础上。你也许会觉得本书将更多责任归在运维团队或开发团队身上，但我鼓励你找时间阅读所有的章节，以便理解这些概念是如何在团队之间相互联系的。
关于代码
本书只包含了少量的代码示例，所有的代码都只是为了说明的目的，代码的显示遵循了标准的格式。

 

 

書城介紹　 |　合作申請　|　索要書目　 |　新手入門　|　聯絡方式　 |　幫助中心　|　找書說明　 |　送貨方式　|　付款方式 香港用户　 |　台灣用户　|　大陸用户　|　海外用户
megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.