作者:
基恩·金 (Gene Kim)
/
凯文·贝尔 (Kevin Behr)
/
乔治·斯帕福德 (George Spafford)
出版社: 人民邮电出版社
出品方: 图灵教育
副标题: 一个IT运维的传奇故事
译者: 成小留
出版年: 2015-9-1
页数: 362
定价: CNY 49.00
装帧: 平装
ISBN: 9787115403650
出版社: 人民邮电出版社
出品方: 图灵教育
副标题: 一个IT运维的传奇故事
译者: 成小留
出版年: 2015-9-1
页数: 362
定价: CNY 49.00
装帧: 平装
ISBN: 9787115403650
内容简介 · · · · · ·
本书讲述了一位IT经理临危受命,在未来董事的帮助和自己“三步工作法”理念的支撑下,最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代IT组织与管理传统工厂的共通之处,让读者不仅能对如何管理IT组织心领神会,更重要的是将以完全不同于以往的视角来看待自己的工作环境。
作者简介 · · · · · ·
基恩•金
Tripwire有限公司的创始人,他担任公司CTO长达13年之久。在Tripwire公司,他一直热衷于研究如何提高IT组织的效能。
凯文•贝尔
他创建了信息技术流程研究所,他拥有25年的IT管理经验,为CEO和CIO们提供指导和建议。
乔治•斯帕福德
行业分析师,帮助IT组织更好地找到目标,明确必要条件,发现实现目标的方法。
目录 · · · · · ·
第一部分
第1章 9月2日,星期二 2
第2章 9月2日,星期二 12
第3章 9月2日,星期二 23
第4章 9月3日,星期三 34
第5章 9月4日,星期四 49
· · · · · · (更多)
第1章 9月2日,星期二 2
第2章 9月2日,星期二 12
第3章 9月2日,星期二 23
第4章 9月3日,星期三 34
第5章 9月4日,星期四 49
· · · · · · (更多)
第一部分
第1章 9月2日,星期二 2
第2章 9月2日,星期二 12
第3章 9月2日,星期二 23
第4章 9月3日,星期三 34
第5章 9月4日,星期四 49
第6章 9月5日,星期五 61
第7章 9月5日,星期五 72
第8章 9月8日,星期一 82
第9章 9月9日,星期二 92
第10章 9月11日,星期四 100
第11章 9月11日,星期四 108
第12章 9月12日,星期五 114
第13章 9月15日,星期一 127
第14章 9月16日,星期二 135
第15章 9月17日,星期三 143
第16章 9月18日,星期四 155
第二部分
第17章 9月22日,星期一 164
第18章 9月23日,星期二 169
第19章 9月23日,星期二 175
第20章 9月26日,星期五 190
第21章 9月26日,星期五 203
第22章 9月29日,星期一 211
第23章 10月7日,星期二 221
第24章 10月11日,星期六 226
第25章 10月14日,星期二 234
第26章 10月17日,星期五 243
第27章 10月21日,星期二 252
第28章 10月27日,星期一 261
第29章 11月3日,星期一 270
第三部分
第30章 11月3日,星期一 278
第31章 11月3日,星期一 284
第32章 11月10日,星期一 292
第33章 11月11日,星期二 299
第34章 11月28日,星期五 306
第35章 1月9日,星期五 313
致谢 324
简介 327
为什么需要开发运维 328
开发运维从何而来 333
对三步工作法的解释 335
对开发运维的主要误解 337
四种工作类型 341
延伸阅读 346
注释 359
· · · · · · (收起)
第1章 9月2日,星期二 2
第2章 9月2日,星期二 12
第3章 9月2日,星期二 23
第4章 9月3日,星期三 34
第5章 9月4日,星期四 49
第6章 9月5日,星期五 61
第7章 9月5日,星期五 72
第8章 9月8日,星期一 82
第9章 9月9日,星期二 92
第10章 9月11日,星期四 100
第11章 9月11日,星期四 108
第12章 9月12日,星期五 114
第13章 9月15日,星期一 127
第14章 9月16日,星期二 135
第15章 9月17日,星期三 143
第16章 9月18日,星期四 155
第二部分
第17章 9月22日,星期一 164
第18章 9月23日,星期二 169
第19章 9月23日,星期二 175
第20章 9月26日,星期五 190
第21章 9月26日,星期五 203
第22章 9月29日,星期一 211
第23章 10月7日,星期二 221
第24章 10月11日,星期六 226
第25章 10月14日,星期二 234
第26章 10月17日,星期五 243
第27章 10月21日,星期二 252
第28章 10月27日,星期一 261
第29章 11月3日,星期一 270
第三部分
第30章 11月3日,星期一 278
第31章 11月3日,星期一 284
第32章 11月10日,星期一 292
第33章 11月11日,星期二 299
第34章 11月28日,星期五 306
第35章 1月9日,星期五 313
致谢 324
简介 327
为什么需要开发运维 328
开发运维从何而来 333
对三步工作法的解释 335
对开发运维的主要误解 337
四种工作类型 341
延伸阅读 346
注释 359
· · · · · · (收起)
喜欢读"凤凰项目"的人也喜欢的电子书 · · · · · ·
支持 Web、iPhone、iPad、Android 阅读器
喜欢读"凤凰项目"的人也喜欢 · · · · · ·
凤凰项目的书评 · · · · · · ( 全部 40 条 )

小说体讲述IT的浴火重生
对于中层管理者来说,的确是不错的小读本。因为书中描述的事情的确是现实生活中中层管理者遇到的具体问题(比如multi-taskng,unplaned work and Changes)。 早知道这本书的主导思想,所以刚开始,我并没有想认真的读下去,只是为了打发碎片时间(比如微博之类的时候)。 然...
(展开)

思维导图|《凤凰项目》
这篇书评可能有关键情节透露
这本书的妙处在于,你能在它身上看到工作的影子。虽然说有爽文的嫌疑,devops也不是银弹,但其中提到的约束理论、控制半成品的要求,还是很有启发意义的。跳开具体的管理理论,本书传达的向成熟行业学习的思路,也值得借鉴学习。 对于一位工程师,或者说工程师团队负责人来说,... (展开)> 更多书评 40篇
论坛 · · · · · ·
凤凰项目:一个IT运维的传奇故事 | 来自mark | 2015-11-04 16:41:44 |
这本书的其他版本 · · · · · · ( 全部3 )
-
IT Revolution Press (2013)8.3分 149人读过
-
人民邮电出版社 (2019)9.0分 386人读过
以下书单推荐 · · · · · · ( 全部 )
- 37°暖书单(二) (37°暖)
- 程序员阅读手册(不断更新中) (mixj93)
- 凤凰项目书单 (络绎很无聊地)
- 豆瓣管理学领域高分书单初筛 (Eisen)
- 运维同学必备系列 (sggggy)
谁读这本书? · · · · · ·
二手市场
· · · · · ·
订阅关于凤凰项目的评论:
feed: rss 2.0
1 有用 liuwill 2016-10-06 23:32:42
凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务,其实本质的思想,是回归常识的约束理论,虽然康威定律指出了现象,但是要怎么做,还需要高德拉特博士在目标中介绍的思考方式
2 有用 全都是风 2016-05-08 23:44:33
一直以来我就有一个问题,为什么战胜拖延症的小组里面堆满了文科老博士,是他们的智力心理的问题,还是他们工作的性质问题。后来灵思风关于真正的魔法是不可分解的理论让我获得了很多自信心。而这本书更告诉我,原来那么大,涉及到那么多用户的产业同样如此困难地(有些人甚至不感到困难)的面对着这个问题;一些些自我厌恶和怀疑我还是能应付的!
6 有用 丁丁虫 2017-08-24 18:23:07
前半部分看的冷汗淋漓,但是后半部分也太理想了
1 有用 alswl 2017-07-28 09:59:12
刚开始觉得小说化还不错,看到 60% 就觉得冗长。 技术观并没有学到什么知识,倒是书中的政治斗争很有趣。
1 有用 棱雷 2020-05-30 12:03:44
竟然能把一个无聊的故事写这么长…
0 有用 无耻之徒 2023-05-04 09:26:43 北京
关于一个烂项目怎么恢复生机的”科幻小说”。一个好项目是怎么变坏的:奇思妙想的需求,无限量增加的P0,连轴转的研发运维,毫无弹性和空闲的时间线;从小问题开始,埋坑时间开始占用正常研发时间,研发延期,短期临时方案频频上线,我们迷信般偏爱技术债,忽视其带来的更多问题,更多修复时间,系统不可用时间;到最后,系统变得复杂无比,极其脆弱,任何变更都有危险性,一枚定时炸弹;更可怕的情况是,管理者不明情况,更加p... 关于一个烂项目怎么恢复生机的”科幻小说”。一个好项目是怎么变坏的:奇思妙想的需求,无限量增加的P0,连轴转的研发运维,毫无弹性和空闲的时间线;从小问题开始,埋坑时间开始占用正常研发时间,研发延期,短期临时方案频频上线,我们迷信般偏爱技术债,忽视其带来的更多问题,更多修复时间,系统不可用时间;到最后,系统变得复杂无比,极其脆弱,任何变更都有危险性,一枚定时炸弹;更可怕的情况是,管理者不明情况,更加push,以为是管理的问题,系统更快的崩溃,项目落后,项目失败。 那么该如何避免此类情况发生? 明确对业务全局有价值的需求,精简敏捷流程,快速试错快速恢复,研发运维足够的弹性,文化上一致性透明性,认清技术债和技术的局限性,稳步的提速前进,适时保养维护,在一个又一个节点中穿梭旅行 (展开)
0 有用 从前以后的 2023-04-11 11:54:28 广东
正向工作流,反馈,改进提升 - 系统论的视角
0 有用 muxueqz 2023-03-31 15:01:53 广东
真正的DevOps是一套可以优化工作方法的理念
0 有用 麦伦 2023-02-19 12:30:33 北京
换皮《目标》
0 有用 小平 2023-02-07 15:57:57 浙江
IT里的devops起源