《凤凰项目》--读书笔记

最新推荐文章于 2023-11-10 13:58:20 发布

Krashe

最新推荐文章于 2023-11-10 13:58:20 发布

阅读量678

点赞数

文章标签： devops

本文链接：https://blog.csdn.net/qq_22271677/article/details/125631200

版权

译者序
1、有些书适合给你的朋友，为了分享阅读的喜悦；有些书适合给你的同事，为了建立理念的共识；有些书适合给你的老板，为了播下伟大的种子。
2、互联网+，产业和商业格局巨大变化。信息技术与核心业务的“黏性”正成为公司竞争力至关重要的构成因素。
3、IT运维部的重要性。
4、缺乏跨团队写作、过度依赖关键个人、办公室政治斗争严重、部门地位尴尬。科学规划的项目
人物表
无极限零部件公司
企业经管人员
史蒂夫-马斯特斯：CEO、代理CIO 辞去8年董事长职务。
迪克-兰德里：CFO
莎拉-莫尔顿：零售运营部高级副总裁
玛吉-李：零售项目管理部高级总监
比尔-帕尔默：IT运维部副总裁，前中型机技术总监
韦斯-戴维斯：分布式技术运维部总监，负责公司网络
布伦特-盖勒：首席工程师
帕蒂-麦基：IT服务支持部总监
约翰-佩斯凯：首席信息安全官(CISO)
克里斯-阿勒斯：应用程序开发部副总裁
董事会成员
鲍勃-斯特劳斯：首席董事长、前董事长、前CEO 复出 20年担任职务
艾瑞克-里德：候选董事
南希-梅勒：首席审计官
即时公告
公司：PAUD 评级：出售目标价格：8美元(现价13美元)
销售增长、库存周转率、赢利能力等处于劣势。
预测并及时响应客户需求竞争对手
月分析师财报电话会议。投资者施加压力，董事会进行调整。推动战略方案。
改进，限定期限。做不到，变化。
首席行业分析师

第一部分
第 1 章 9月2日，星期二
公司40亿美元的产值。公司月例会。
CIO，首席信息官 Career Is Over(职业生涯结束了)
1、问题：间断性网络中断。密切追踪网络故障。
困难逐年增加。必须用更少的资源完成更多的业绩，既要保持竞争力，又要削减成本。
IT运维管理岗位做的久，一定得有足够的资历。才能把事情干好。但是一定要低调，不能卷入政治斗争，以免惹祸上身。
2、离职，同事主动告诉你，多半是自愿的。其他人告诉你，一定是被迫的。
3、团队有组织、最值得信赖。
4、直爽有条理。兑现承诺的能力。面对困难，始终头脑清醒。可靠、务实，且愿意表达真实想法。
5、可以信任的人做正确的事。
6、资深IT领导人，预算或人员的申请。高管变动太快。
7、“绝地武士控心术”。
8、邮件优先级：最高主题。
9、恢复关键业务运营。

第 2 章 9月2日，星期二
1、白板，流程图。信息流。
2、事情，备用方案。
3、程序员给生产体系添乱。冷静专注。
4、网络运营中心，NOC。
5、保持干净整洁不只是为了美观，更是为了安全。
6、SAN，存储区域网络。提供集中存储，故障通常都是全局的性的。
7、问题，分等级，I级严重程度。
8、快节奏处理麻烦事，脑袋爆掉。
9、做出正确的选择。
10、小东西被农化时听说过添堵的说法，诸如手机升级失败。
11、对虚拟技术投入巨资。虚拟技术改变了游戏规则。再也不用管理鼠疫千计的实体服务器。它现在是一台大型服务器中的逻辑实体，甚至可能是在云存储的某个地方。
12、构建一台新的服务器，只需在一个应用里点击右键。布线？只需设置参数就行了。
13、确立各相关事件的准确时间节点。不要把判断建立在道听途说的基础上。靠道听途说没法破案，解决故障。

第 3 章 9月2日，星期二
1、SAN工程师，大跨度的升级路径。维护窗口。扬声电话。不动声色。
2、救火队员和故障维修人员。
3、紧急变更，紧急项目。开发人员，经常粗心大意地弄坏东西，然后消失不见，让运维收拾烂摊子。
4、开发人员和信息安全部门的人联手更危险。添乱的动机、手段和机会齐全了。
5、信息安全部，不依不饶、歇斯底里、自以为是的要求。
6、SAN处理故障中意外被弄残了。
7、按流程来。把故障的来龙去脉梳理清楚。不要武断地得出不恰当的结论(可能会引起别的故障)。
8、不能干涉那些干实事的人。
9、PII存储的紧急审计问题。PII---个人验证信息的简称，类似SSN，社保卡号的简称，还有出生年月之类信息。欧盟法律禁止存储，美国很多州也有这样的法律。审计发现问题。
10、支付卡行业审计师，PCI。
11、重复一遍自己对谈话对象描述的理解。
12、对产品进行任何变更，有一套规定的程序和流程。变更规范。
13、找到问题的关键。
14、对变更进行测试。测试环境。变更事项安排表。准确时间节点。提交变更事项的系统。报修系统或变更授权系统。
15、IT流程的工具配备以及培训。
16、该怎么做就怎么做吧。变更咨询委员会，CAB，形同虚设。太忙、时间紧迫。会议必须出席，不能出席派代表
17、下班前，紧急事项，向负责人发送一封快速状态报告。
18、备忘录

第 4 章 9月3日，星期三
1、日程表管理。权限。
2、语音邮件，检查一遍，将需要处理的留言记录下来。
3、写字板。紧急项目管理会议。邮件标记为高优先级。所有相关人员，拿出一份书面技术参数。
4、个性化的市场营销需要高科技对的支撑。
5、有条不紊、客观冷静、富有责任感。专业化水准。
6、项目第1阶段的关键路径上有12项任务，完成进度。
7、面对误解，深吸一口气，保持沉默。我期待你提出的任何建议。政治参与。领导
8、确定投产日期。技术参数，基础架构，服务器和网络设备，供应商，交货时间。
9、产品和测试系统配置的具体技术参数。
10、紧急的日期驱动项目，结果从来不理想。业务决策。
11、软件产品实在太不稳定、太不可用。最后，IT运维部在通宵达旦地为糟糕的代码买单，每隔一个小时重启一次服务器。尽可能向世人隐瞒糟糕的真相。
12、尽可能平静地对话。
13、组织架构和计划会议。
14、疏于计划，而不得不奋力拼搏。
15、最后一刻邀请参加会议，当天街道一个新通知后重新调整好日程安排呢？
16、实际情况下工作是如何开展的。
17、协同工作，从源头解决问题。否则疲于奔命。
18、变更管理会议，协调和安排所有工作的场合，能确保不会手忙脚乱。
19、员工参加ITIL培训，学习最佳的工作实践。引进顾问。
20、ITIL，代表IT基础架构库。记录着许多最好的IT实践和流程。
21、这里有一系列的命令：只可对上抱怨，不可对下牢骚。
22、提出解决方案。不要繁文缛节。
23、要付出什么样的努力才能和平共处呢？

第 5 章 9月4日，星期四
1、IT审计发现评估。文档要求，收集数据并准备答复。发现问题，很快改正。
2、审计师代表着一种客观公正的力量。
3、IT常规控制。
4、关键在于，我们在有限的时间里能够做些什么，以及哪些系统是真正可以修复的。
5、弄清楚究竟需要哪些资源。做事必要反反复复。
6、工作清单。业务项目，基础架构项目。
7、对工作需求、优先等级、工作君度、可用资源都一无所知，怎么可能管理好生产工作呢？开始从管理人员的角度来思考问题。
8、弄清工作职责，估算出工作量。列出所有的工作任务。
9、人员，向他们交办特定领域的工作职责。
10、一行简单的文字说明，描述他们的工作是什么，以及他们认为完成这些工作需要多少时间。为了争取更多的资源。对员工进行简短的15分钟访谈。
11、预算编制工具。

第 6 章 9月5日，星期五
1、质量保证部，QA
2、访谈、收集数据、然后做了分析。
3、知道真相好过一无所知。
4、预防性维护是有道理的。小破事。无法把精力集中到对公司最为重要的事情上。
5、一定在完成各项工作的同时，研究如何建立一套可持续的流程来解决问题。避免乌龙事故。想可行方案。
6、障碍是什么？
7、近期计划变更进行授权并安排好时间。
8、索引卡片，三条信息：变更计划的制定者、将要实施变更的系统以及一条一句话的概述。白板日程表
9、打开一台重复的DHCP服务器(duplicate 9、打开一台重复的DHCP服务器 Server)导致全公司网络瘫痪。
10、变更：对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作，且这样的操作可能对相关服务产生影响。讨论变更的事。
11、在建立一个有效系统之前，会不断尝试，且让大家务必帮我们达成目标。
12、需要一些方法来稳妥地计划、沟通、实施变更。改进工作方法。
13、新操作的指南详细写下来。
14、再也没有比阻止人们去做他们理应做的事情更能毁掉大家的热情和支持了。

第 7 章 9月5日，星期五
1、难以根除的IT有效性问题，导致公司上新闻头条。
2、监督并评估。行动计划，改变。整改措施，在工作中进一步严明纪律。改进流程，不再手忙脚乱。
3、从救火模式中解脱出来。
4、只有掌握了战术，才能实现战略目标。
5、显然并不真正理解“工作”是什么？工作是怎样完成并提交给公司的。管理、组织，排序以确保足额配备完成工作所需的资源。
6、项目交付成果、故障处理、审计合规等问题。
7、WIP，半成品，库存。半成品是个隐形杀手。管理任何一家红肠的机制之一：就是工作任务和原材料的发布。
8、根据瓶颈资源所能完成工作的速度来安排工作。在瓶颈之外的任何地方做出的改进都是假象。
9、工作，确保形成一条迅速的、可预测、持续不断地计划内工作流，从而向业务部交付工作价值，同时尽可能降低计划外工作的影响和破坏，才能提供稳定的、可预期的、安全的IT服务。
10、对工作的内涵有更好的理解之前，任何关于控制工作的讨论都会让你茫然无措。夏虫不可语冰。
11、如何控制IT运维部的工作导入量，更重要的是，确保大多数受约束的人力资源都只能投放在为整个系统的目标所服务的工作上，而不只是为一个部门的目标服务。
12、三步工作法。第一，帮助我们理解在工作从开发部移向IT运维部时该如何建立快速工作流，那就是业务部门与客户之间的衔接。第二，如何缩短及放大反馈环路，从而从源头上解决质量问题，避免返工。第三，如何建立一种文化，既能鼓励探索、从失败中吸取教训，又能理解反复实践是精通工作的先决条件。
13、有四种类型的工作：业务项目工作、内部项目、变更、计划外工作(救火)。
14、寻找平行宇宙。
15、提出问题，思考，形成答案。

第 8 章 9月8日，星期一
1、工作的传递途径变得更加可视化。
2、缜密理性、条例分明的论点。花时间排练。
3、生活很艰难。两件事都得做。
4、心里默数三下才开口。
5、项目需求和生产能力。
6、该多联系更加悲观的场景。
7、变更审核委派给代理人。
8、预先定义好高风险变更目录。标准变更(低风险)。
9、职责是保证细节。更关心流程的完整性，而不是过多考虑实际的变更。
10、手工工作不可持续。敲定确切的规则。

第 9 章 9月9日，星期二
1、预算会议。
2、I级严重级别的事故。负责任必须弄清楚相关事件，尤其是相关变更的时间线。
3、观察，不说出鲁莽的话。
4、每两周组织一次排查故障的实战演练。
5、让每个人都养成运用合理的方式来解决问题的习惯。召开应急处置会议之前，就必须把时间线搞清楚。
6、变更冲突以及可用资源矛盾。
7、单人辩论俱乐部。

第 10 章 9月11日，星期四
1、进度报告和更新后的完成时间节点。
2、目标：观察并寻求理解。
3、改变工作流转到布伦特那里的方式。
4、建立一个3级工程师的人力资源库，由他们处理流转过来的工作。负责记录学到的东西，永远不要让布伦特反复解决同一个问题。惩罚措施。
5、记录解决方案。解决一个问题，知识库多一片关于如何解决某个疑难杂症的文章，且能够实施修复的人越来越多。
6、服务器建立标准。
7、每天提交时间表。记录在案，以便今后分析。

第 11 章 9月11日，星期四
1、变更时间表能够及时反映实际发生的情况。
2、如何传播知识？
3、保持思维活跃。

第 12 章 9月12日，星期五
1、乱成一团，FUBAR
2、团队，全面管理检查。
3、更好地统筹协调。管理源头，确保每件东西都贴好标签，注明版本。维持秩序，确保大家按流程办事。
4、单一入口。
5、缺乏竞争力才是成事的大敌。

第 13 章 9月15日，星期一

第 14 章 9月16日，星期二
1、实际解决方案
2、COBOL维护。另一个过气的中层经理。

第 15 章 9月17日，星期三
1、对自己的定位：养家者、家长，伴侣，然后是突发事件的应变者。
2、预防措施
3、问题故障，无视它们的存在是没法蒙混过关的。
4、脆弱的认知一闪而过，又无影无踪。片刻的情形认知。
5、反工作，强调了它的额破坏性以及可避免的本质
6、计划外工作是恢复性工作，几乎总是让你远离目标。知道计划外工作从何而来显得尤为重要。
7、可视化工作管理工具，并在整个系统中运行起来了。
8、稳定工作环境。
9、约束点，提高流量。
10、工商学院学习工厂运营管理。《目标》---高德拉特博士。写下快速提示。
11、五个聚焦步骤：一、确认约束点，继续加压，直到确定那的确是整个部门层面的约束点；二、利用约束点；三、把约束点置于次要地位；四、
12、计划外工作会让你丧失开展计划内工作的能力，必须不惜一切代价去消灭计划外工作。墨菲法则，总会有计划外工作，但必须高效地处理它们。
13、《目标》出版整二十年后，大卫-J-安德森创建在软件开发和IT运维中使用看板来发布工作并控制半成品技术。
14、使用变更板的方式来解决管理流程问题。
15、对你无法控制的事情怨天尤人。
16、相比于向系统中投入更多的工作，将无用的工作剔出系统更为重要。
17、与实现企业目标息息相关的是什么？
18、重要的是结果，而非过程、管理，或者你完成了哪些工作。

第 16 章 9月16日，星期四
1、发票系统故障。未经批准，什么都不准碰。
2、不要猜测，要基于事实的推理。
3、把时间线和数据汇总起来，关于前因后果的最好的见解。
4、陪孩子，晚间阅读时间。好奇心。
5、不间断的事后调查，搞清楚故障的来龙去脉，并拿出防止类似情况的办法。开展了一系列全员参与的模拟事故呼叫，排演的处理步骤。
6、故障处理团队的有效沟通。
7、每小时都发出一份状态汇报。
8、训练方法应对气急败坏的人。冷静地重申之前所说的话。
9、扮演的角色。
10、了解全局。
11、冷静理智的话语。
12、公开透明。

第二部分
第 17 章 9月22日，星期一
1、辞职四天，睡觉安稳多了。

第 18 章 9月23日，星期二
1、IT很重要。IT不只是一个部门，IT是整个公司需要发展的一种能力。
2、面对巨大的挑战，需要一个杰出的团队发挥出最佳的水平。完全信赖彼此。
3、使团队变得伟大的因素，是每个人都互相信任。
4、《团队发展的五大障碍》，展现出自己脆弱的一面。
5、生活方式，

第 19 章 9月23日，星期二
1、更深入地了解彼此。才能建立起信任的基础。
2、为了找到人生定位而不断尝试。
3、是否接受一个新项目的依据是什么？对工作能力和工作要求作分析。
4、未偿还的技术债务。走捷径。计划外工作的代价是牺牲。
5、观点有数据支撑。
6、不只是更好地区分轻重缓急。
7、目标是提高整个系统的生产能力，不只是提高任务的完成数量。
8、就让补课避免的事情发生吧，看看我们能从中学到些什么？
9、草稿，大家修改。
10、确认最主要的技术债务。

第 20 章 9月25日，星期四
1、需要做哪些工作、如何确定工作的优先级并发布工作。
2、监控项目以及如何保护系统内的工作时偶然发现的那些问题。
3、不懂工作是如何运行的。
4、理解工作流式成功实现“第一工作法”的关键。
5、约束点---工作中心。工作中心：机器、人员、方法，以及测评。
6、把工作标准化，让其他人能够执行。最终把那些步骤记录下来，所以在一定程度上保证稳定性和质量。
7、直觉提供一种理论支撑。
8、问题是一直把两件事混淆了。能在脑子里把它们区分开来。
9、自己一团乱麻，搞不清楚状况，还指望别人把答案告诉你？
10、构建一份资源清单。也就是材料清单以及所需工作中心和工艺的清单。
11、适当提高预防性工作是去那面生产维护等计划的关键。
12、改进日常工作比开展入场工作更重要。
13、弹性工程学，系统里经常出些故障。长此以往，再与困难就没有原来那么痛苦了。
14、改进的内容是无关紧要的，关键是要不断改进。----迈克-罗瑟
15、改进形，不断重复可以形成习惯，而有了习惯才能变得精通。只有通过实践和操练才能达到精通的地步。
16、每天训练5分钟比每周开展一次为期3小时的训练更有效。
17、营造一种真正的改进文化，必须把那些习惯建立起来。
18、管理好工作交接。
19、第二工作法，关键部分让等待时间可视化。
20、目标：使流量最大化。

第 21 章 9月26日，星期五
1、眼界的错误。

第 22 章 9月29日，星期一
1、项目管理软件，甘特图。
2、实际操作，否则只是在黑暗中摸索。
3、点带你滴滴的经验和智慧，每一天都在谱写着传奇。
4、车间管理有很多地方值得我们学习。
5、如何管理工作流。
6、看板，可视化。引入关键资源之中。在看板上，迅速完成。不在看板上，不能开展。
7、持续不断地两周改进周期。每个周期实验一个小型的“计划---执行---审核---落实”项目，让他们不断想着目标迈进。
8、应该怎样管理工作。建立起工作中心和工作路径。
9、提高把工作标准化的能力。
10、项目队列。

第 23 章 10月7日星期二
1、等待时间是忙碌时间百分比除以空闲时间百分比。
2、每个人都需要空闲时间，松弛时间。
3、修正任务分解结构。WBS。
4、任务，看板追踪路径。
5、经常性任务，标准化。
6、新角色，兼有项目经理和稽查员的职能。

第 24 章 10月11日星期六

第 25 章 10月14日，星期二
1、让所有人员都保有责任感，确保掌握成功的必备技能。
2、远期目标、近期目标以及评估指标
3、系统思维，始终确保整个企业达成其目标，而不只是其中的一部分。
4、必须跳出IT领域，才能弄清公司需要依靠IT的哪些工作来达成目标。
5、最英明的审计师，只有三种内部控制目标：确保财务报告的可靠性，符合法律法规，以及运营的效率和效果。
6、COSO立方，内部控制整合框架。
7、建立一个服务等级协议(SLA).
8、制定更好的业务决策。
9、建立起价值链，目标任务与IT对这些目标人物的影响关联起来。收集以前IT问题如何影响那些目标的具体案例。

第 26 章 10月17日，星期五
1、评估指标负责人
2、必须通过监控来强制实行这些策略。
3、执行力糟透了。
4、了解客户需求和期望，数据是怎样产生的。项目渠道流程及其困难的问题。
5、CRM，MRP。
6、更改了控制策略，通过监控来强制实行这些策略。
7、工作职责，了解客户的需求和期望的衡量标准：客户是否会向朋友推荐我们。
8、盲目行动。数据质量太差。无法进行各种预测。每天销售和缺货报告。准确及时的信息。易获取。
9、管理供求曲线。
10、报告的重要性。
11、推出产品的合理时间？6个月，最多9个月。
12、竞争时代，快速上市，快速淘汰。

第 27 章 10月21日，星期二
1、业务流程负责人，公司评估指标。
2、期望的业务成果：增加收入，提升市场份额，提高平均订单金额，恢复赢利，提高资产回报率。
3、绩效指标依赖IT的方面 IT导致的业务风险所依赖的IT控制
4、每一个评估指标，列出四个层级的管理。
5、对公司系统具备根本性的认识。

第 28 章 10月28日，星期一
1、提高对基础架构和应用程序的产品监控。
2、工作流，
3、回顾小结，自身工作开展情况及需要改进的方面进行自我评估。
4、训练让伟大的团队达成最优表现。训练成习惯，习惯成精通。不断重复可以建立起信任感和透明度，对需要团队合作的事情尤其如此。

第 29 章 11月3日，星期一
1、理论上的理想状态是单一工作流，让生产能力最大化，同时让变化幅度最小化。通过持续不断地降低批量规模，就能达到这种状态。
2、技术，工作方式。
3、创建一个向前的工作系统。目标是单一工作流。

第三部分
第 30 章 11月3日，星期一
1、一家制造工厂就是一个系统。
2、工作中心。思考问题更宏观一些。工厂经理。最好像设计全套流程的人去思考。着眼真个工作流，确认约束点位置，且尽其所能地运用各种技术和流程知识来确保工作得到有效执行。
3、制造业，一个指标叫节拍时间，跟上客户需求所需的周期时间。
4、建立一套反馈环路，一直往回通向产品定义、设计及开发的最初环节。
5、丰田公司，德企。大野、斯皮尔、罗瑟所有著作。
6、还需降低批量规模，几个星期的头脑风暴、调查研究、并与工程部共同开展实验。自动化，形成单一工作流。
7、降低转换时间，让部署周期时间加快。
8、Velocity大会，O'Reilly公司组织的Web性能与运营年度大会。满脑子危险的、不切实际的想法。
9、Flickr网站，如何协同工作，每天10个部署。
10、IT价值流中应用三步工作法的必然结果。颠覆管理IT的方式。
11、缩减批量规模，实现快速工作流。确保部署环境时刻准备就绪，按需投产。创建和部署流程自动化。
12、《持续交付》，做法和原则、《精益创业》，如何帮助公司成长并取得成功
13、精力充沛，
14、创建部署管道，从代码签入到投产的整个价值流。那不是一种技术，而是生产。所有东西进行版本控制。
15、导入创还能流程；把人从部署业务中解脱出来。
16、业务敏捷度并不是单看生产的净速度，而是看你捕捉和适应市场变化并为此承担更大风险的能力。
17、关乎持续不断地尝试。
18、越快把那些功能推向市场接受考验，就越好。更快地为公司回收成本。
19、工作环境。工作更有创意，也更有胆量。

第 31 章 11月3日，星期一
1、需要聚焦的问题是部署的流程以及构建环境的方法。
2、更快速的实验和A/B对比实验。
3、IT工作不仅是无形的，因此更难追踪，且出错的地方也要更多。
4、更严格、更守纪律、更有规划性。
5、把做的事确切地写下来，对每个步骤有一些客观的考量。
6、价值流图。精益生产的工具和技巧。制造业的从业人员用其记录并改进流程。
7、环境和部署
8、突破性建议
9、开发、QA、生产。构建过程
10、非价值附加活动或废料。

第 32 章 11月10日，星期一
1、用老眼光去看待整个行业是不公平的。
2、挑战：是如何让所有人同心协力，向着共同的目标迈进。

第 33 章 11月11日，星期二
1、建立一个快速原型，看看它收否可行。
2、云计算，运行计算实例。
3、保持开放的心态。
4、演示时间。最后冲刺。开发组长展示团队取得的成果。产品经理，一组PPT。
5、熬夜加班，因为每件事都进展顺利。
6、定期检查，确保产品拥有日常访问权限的开发人员仅仅具备只读权限。

第 34 章 11月28日，星期五
1、循环使用更多的服务器，以及关闭计算密集型功能。
2、IT运维友好型的研发设计。在生产中管理代码变得越来越容易。
3、不断优化数据查询功能。
4、集思广益。
5、做不到，作出解释。
6、技术分析师，6个月收集需求，9个月进行开发和测试。可行性研究。

第 35 章 1月9日，星期五
1、丧失了所有的激情，确实无事可干。
2、15%的时间用于预防性基础架构项目的目标。
3、适应力的、坚固的、敬酒耐用的IT服务。
4、建立起一种文化，强调用于冒险以及从失败中汲取教训的价值观，并强调通过反复实践以致炉火纯青的必要性。
5、应用到日常工作中。
6、IT是一种技能，每一个雇员都多少掌握这些技能。
7、理解技术能够做什么，不能做什么，已经称为每个部门必须诀别的一种核心竞争力。
8、成长、学习，并掌握新的技能。做到，培养。轮岗，管理一家工厂，积累国际经验，维护关键供应商的客户关系，以及管理供应链。
9、做出特别绩效目标，COO。精通IT系统，管理公司运行。勇气，机会。
10、重视IT。
11、记住，身边有很多经验丰富的人。
12、提升企业管理技术的实践水平。
13、人们意识到自己对改变结果无能为力，沮丧懊恼，尊严尽失；是时候做出改变了。
14、改善百万IT从业者的生活。
15、一时的救世主固然好，但普世的圣经则更有用。
16、分享经验，推动改变。伟大的事。
17、写书，去学。
18、产品管理部门、开发部门、IT运维部门，甚至信息安全部门协同工作，并且相互支持。
19、迎接挑战。

后记
1、过去---对目标的期待
2、DevOps，很多做法反直觉，与常规认知相悖，甚至有争议。万能大法。
3、问题普遍存在，导致整个技术价值流，包括开发、运营和信息安全在内，长期表现欠佳。
4、能以足够的可信性来描述如此复杂的问题的方式只能是小说。《目标》，1984
5、“制约法”理论体系。高德拉特博士。有声书《目标之外》
6、《DevOps实践指南》《凤凰项目之外》
7、组织大家讨论。读书会。
8、惊喜之旅，
9、没有人不可替代。分享者
10、DevOps原则和模式就是整合企业文化、企业架构和技术实践，让下降式螺旋编程上升式螺旋。
11、展望未来
12、科技对一个组织的重要性。
13、不把软件当作核心业务的行业和公司都将以失败告终。
14、2013年，互联网企业，才会使用DevOps。每个垂直领域的结构复杂的大公司都在践行DevOps原则。
15、如何提高生产能力
16、没人会强迫你学习......学习也并非生存必需。
17、进入技术领域永远都不晚，成为终身学习者也永远都不晚。
18、Visible Ops，When It Fails

第四部分三步工作法
节选自《DevOps实践指南》
序
1、工程领域，长足的发展。不断提高对本学科的认知和理解。
2、现代社会需要的是各种形态的工程学科相互交叉影响并从中受益。
3、要想在现代技术上取得成功，必然需要多方向和多专业领域的协作。
4、任何一个领域或学科取得进步和成熟，就需要认真反思它的起源，在反思中寻求不同的观点，并把这些不同的观点来龙去脉思考清楚，对预见未来发展是非常有帮助的。
5、思维方式。

啊哈
1、研究高绩效技术组织。部门之间的良好合作是成功的关键。
2、绝望和无助的感受。
3、《持续交付：发布可靠软件的系统方法》
4、动力：无论是什么限制，总能做的更好。
5、高生产力；试验看板方法，团队显著变化；
6、基础设施即代码的理念
7、ITIL，1989年，IT基础架构库；ITSM，IT服务管理
8、需要文化规范和架构，以便在IT价值流中实现共同的目标。
9、LAMP，Linux、Apache、MySQL、PHP；与使用的技术无关。

传播“啊哈”时刻
1、DevOps是创建动态、学习型且强化高度信任的文化规范的公司的一种表现形式。持续地在市场上创新并在竞争中脱颖而出。
2、计划和指南。
3、改变技术组织管理方式的道德使命。提高效率，创造更快乐和更人性化的工作环境，并帮助每个人成为终身学习者。实现个人的最高目标，且能帮助公司取得更大的成功。

导言：展望DevOps新世界
1、团队文化建设。创造工作环境。
2、需要改变工作方式，DevOps能够给我们指引方向。
3、20世纪80年代的制造业革命。采用精益原则和实践。
4、运用DevOps，能够通过测试商业理念发现对客户和整个公司而言最有价值的想法，然后实施开发，并快速且安全地将其部署到生产环境中。
5、IT员工没有成就感，感觉无力改变流程及其结果。
6、竞争优势需要被快速验证和持续实验地时代。
7、获取客户并向客户交付价值的方式都要依赖于技术价值流。
8、没有讲软件作为核心业务的每一个行业或公司都会受到影响。
9、在过去的经济时代，企业通过移动原子创造价值。而现在，必须通过数字创造价值。
10、技术工作的管理和有效执行，预示着企业能否在市场上取得优势，甚至能否生存下去。
11、尝试和采取一些新的原则和方法势在必行。
12、明确重要性和紧迫性。探索问题的本质。这些问题为什么会发生？

问题：在你的公司中有些事情必须改进(否则你不会翻这本书)
1、快速地切入市场、提供优质的服务以及持续的创新是一种竞争实力，
2、技术团队无法解决根本的、长期的冲突。技术债务。恶性循环，阻碍了业务目标的实现；每天都要采用临时解决方案、应对紧急情况。
3、两个必须实现的目标：对变化莫测的市场做出反应；为客户提供稳定、可靠和安全的服务；
4、公司对不同部门的考核和激励不同，阻碍了公司全局目标的实现。
5、产品管理、产品开发、QA、IT运维和信息安全管理；
6、恶性循环三部曲：IT运维；有人必须去弥补最近未兑现的承诺；所有事情变得更加困难，所有人越来越忙，工作积压的越来越多。工作耦合的更加紧密
7、无论破坏慢慢发展，还是像大火焚毁般...，其毁灭性都是一样彻底。
8、为什么恶性循环无处不在。
9、公司，项目。资本投入。
10、企业领导者想要实现业务目标，对有效IT管理的依赖程度远远超出了他们的预想。
11、成本：人和经济。
12、创造了"习得性无助"的环境。损害员工
13、重新部署员工，去做能产生5倍价值的事。

DevOps的准则：总有更好的方法
1、用DevOps打破恶性循环
2、通过在流程中的每一步骤创建快速反馈回路，每个人都可以立即看到工作效果。
3、自动化测试可以帮助开发人员快速发现错误(通常在几分钟内)，实现更快速的修复及真正的学习。
4、总体目标高于局部目标。
5、黑启动(dark launch)技术
6、出现问题，进行不指责的事后分析。强化学习文化。
7、举办内部技术研讨会来提高技能，保证所有人不是在教就是在学。
8、每个人都是自己工作的主人。低压力的工作环境以及公司在市场上的成功足以证明这一切。

DevOps的业务价值
1、高绩效者要更加敏捷和可靠。员工满意度高，倦怠程度低。
2、员工参与度较高。拥有高度信任的工作环境的上市公司。
DevOps有助于提高开发人员的生产力
1、《人月神话》
解决方案的通用性
1、精益运动，《目标：简单而有效的常识管理》
阅读指南
1、基于几十年优秀的管理理论、对高绩效科技组织的研究、帮助企业实现DevOps转型所做的工作、验证本书中DevOps实践的有效性的研究、对相关领域专家的访谈。
2、三步工作法，是看待基础理论的一种视角。
3、技术计划

第一部分 DevOps介绍
1、DevOps是把精益原则应用到技术价值流中的结果；
2、DevOps的三步工作法：流动、反馈以及持续学习与实践。
3、简史，体现了哲学和管理学原则的融合。
4、基于制造业实践了数十年的管理经验，将可靠性组织、信任度管理与DevOps实践相结合的产物。
5、DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文海、服务型领导、组织变动管理等方法论。综合第应用到IT价值流。
6、始于2001年的敏捷运动的延续。
7、精益运动，价值流映射、看板和全面生产维护这些实践起源于20世纪80年代的丰田生产系统。
两个主要原则：坚信前置时间是提升质量、客户满意度和员工幸福感的最佳度量指标之一；小批量任务的交付是缩短前置时间的一个关键因素。
如何通过系统性思考为客户创造价值。系统性思考的发哪位涉及建立持久目标、拥抱科学思维，创造流和拉动的协作模式，提倡从源头保证质量，以谦逊为导向，尊重流程中的个体。
8、敏捷宣言，2001年，软件领域17位顶尖大师共同提出。
9、敏捷基础设施和Velocity大会，
10、持续交付
11、丰田套路，《丰田套路：改变我们对领导力与管理的认知》。精益的核心：改善套路(Kata)

第 1 章敏捷、持续交付和三步法
1、制造业价值流
2、技术价值流，把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程。
3、聚焦于部署前置时间，价值流始于工程师向版本控制系统提交了一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。
4、采用测试和运维与设计和开发同步的模式，产生更快的价值流和更高的质量。
5、处理时间与前置时间的比率是十分重要的效率指标。必须缩短工作在队列中的等待时间。
6、目标：分钟级的部署前置时间。通过模块化、高内聚、低耦合的方式优化架构设计，帮助小型团队自治地工作。
7、提交小批量的代码变更，并对代码做自动化测试和探索测试，生产部署。
8、完成时间和精确的总花费时间的百分比(%C/A)；每个步骤的输出质量。
9、三步工作法：DevOps的基本原则；
10、所有经验都可以持续地积累，组织里的人都可以相互借鉴彼此的经验和智慧。

第 2 章第一步：流动原则
1、是工作可见，可视化工作板，如在看板或Sprint计划板上，使用纸质或电子卡片将各项工作展示出来。有效管理工作，加速其从左至右的流动。度量出工作的前置时间。
2、工单系统，信息不完整，将工作踢来踢去。
3、每个工作中心都采用单任务的处理方式。
4、限制在制品数
5、技术工作通常的动态的。临时安排控制了日常工作。
6、多任务、认知规则和目标之间来回切换，付出重新进入角色的成本。效率显著降低。
7、多任务会导致更长的处理时间。
8、《看板方法：科技企业渐进式变革成功之道》，停止开始，开始结束。
9、减小批量大小，单件流。
10、减少交接次数，或自动化执行大部分操作。
11、持续识别和改善约束点
12、DevOps转型过程，环境搭建、代码部署、测试的准备和执行、紧密耦合的架构；
13、消除价值流中的困境和浪费，
14、浪费是业务兴盛的最大威胁。浪费和困境是软件开发过程中导致交付延迟的主要因素。
15、通过持续的学习来破解日常工作中的困境。

第 3 章第二步：反馈原则
1、快速、频繁、高质量的信息流
2、复杂系统的本质，无法将系统视为一个整体，去理解各个部分是如何组合在一起的。
3、在复杂系统中安全地工作
4、故障存在且不可避免。设计一个安全的工作系统，让员工能无所畏惧地开展工作。快速检测出错误。
5、措施：管理复杂的工作，从中识别出设计和操作的问题；群策群力解决问题，从而快速地构建新知识；在整个组织中，将区域性的新知识应用到全局范围；领导者要持续培养有以上才能的人。
6、及时发现问题，不断地对设计和假设进行验证。
7、《第五项修炼：学习型组织的艺术与实践》，反馈回路是学习型组织和系统思维的重要组成部分。
8、《探索吧！深入理解探索式软件测试》，反馈至关重要，它是我们工作的向导。
9、测试仅仅是一种反馈。
10、群策群力，战胜问题获取新知，遏制住问题，防止蔓延，然后定位和处理问题，避免复发。丰田的安灯绳。
11、事故的发生具有一次性和难追溯性；
12、PDCA环，计划、实施、检查、改进。
13、在源头保障质量，
14、决策质量、决策周期。
15、因为清晰度和及时性不足。
16、为下游工作中心而优化

第四章第三步：持续学习与实验原则
1、严格定义并完成工作内容。错误；工作系统是动态的。工作流程是严格标准化的，工作结果都会写入文档。
2、建议和指出问题。
3、要求并积极地促进学习。
4、技术价值流的核心：建立高度信任的文化。
5、为日常工作的改进预留时间。
6、建立学习型组织和安全文化，
7、点名、责备和羞辱模式，坏苹果理论。《The Field Guide to Understanding Human Error》
导致信息封闭、责任逃避和滋生自我保全意识。
8、安全文化，正义文化。保持专注而不是感到恐惧。组织不官僚，而更细致。
9、病态型，恐惧和威胁，故障和事故经常被隐瞒；官僚型，规则和流程僵化；生机型，积极探索和分享信息，所有员工共同承担责任，对事故进行积极反思，并进行真正的根因调查。
10、进行不指责的回顾，客观解释，优化系统的最佳措施；
11、事故回顾记录工具Morgue；不指责，没有恐惧，坦诚，有效预防事故；
12、组织自我诊断和自我优化。
13、将日常工作的改进制度化，能力和意愿，持续饱受眼前问题的困扰和折磨，且痛苦指数还会与日俱增；持续恶化。
14、《丰田套路》，《Learn It》
15、比日常工作更重要的，是对日常工作的持续改进。
16、通过明确预留时间来改善日常工作，包括偿还债务、修复缺陷、重构、优化代码和环境。
17、每个开发周期的间隙中预留一段时间。自组织团队的方式来解决感兴趣的问题。
18、识别自身的处境、困难和障碍，逐渐用动态的持续改进模式替代了传统的应急和救火模式。
19、发现和解决潜在风险。
20、把局部发现转化为全局优化，分享，让更多的人获益。
21、隐性知识，很难通过文档或沟通的方式传递的知识；转换位显性知识，实践应用。
22、集体的经验和智慧。智慧库，建立全局知识库。可搜索的知识库；共享源代码库，个人专业知识转化为服务更多成员的集体智慧。
23、故障报告，积累经验。
24、在日常工作中注入弹性模式，改善日常运营，持续地引入张力提高生产效率。通过加压来增加弹性的做法称为抗脆弱性。
25、预演大规模故障。生产环境注入大规模故障。
26、领导层强化学习文化，
27、制定目标，分配资源，建立正确的激励机制，为组织建立情感基调。
28、领导力的优秀并非体现在做出的所有决定都是对的。为团队创造条件，让团队能在日常工作中感受到这种卓越。设计和执行流程，洞察力和权力。
29、《走动管理》，必须互相尊重；谁都无法独立解决问题。
30、必须强调解决问题的能力和学习的价值。
31、教练套路，明确地描述我们的《真北》目标。
32、战略目标的指导，建立相互嵌套的迭代的短期目标，在价值流或工作中心级别设立目标条件，实现目标。
33、清晰地描述要解决的问题，对解决方案所做的假设，验证假设的方法，对结果的解释，以及如何利用经验进行下一个迭代。