《凤凰项目 一个IT运维的传奇故事》总结
“ The more you know the more you know you don't know”
1. 古老的IT方法有哪些问题？
2. DevOps是如何解决的？
3. 书中核心的DevOps三步法指的是什么？
技术价值流：把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程
—
古老的IT模式
我们总是承诺一有时间就改进那些系统，但这一天永远也不会到来
—
DevOps如何解决的？
DevOps目标：（小步试错，快速迭代）拥有一个快速交付的流水线，可以快速的交付需求，并同时保证系统的稳定性以及安全性
开发在开发环境独立的实现功能
并在测试环境（与生产环境一致）中自动化测试
新的代码可靠的发布到线上，并且对于客户是无感知的
黑启动，先将新功能发布到线上，但启动开关只给内部用户或者部分外部客户开放，回滚只需要改动一个配置
每次发布规模小，发布成本低
保证团队完整性，每个人都要对自己的代码负责，并编写可靠的单元测试
强化学习文化，从失败中吸取教训，进行充分的事后分析，并不是针对出错的人
通过故障演练来验证服务可用性以及预案可操作性
一、增加的发布频率
增加发布的频率可以使得我们比竞争对手更快的对市场做出反应，新功能的上线时间远远低于对手，从效率和成本上大幅度领先对手
二、增加服务可靠性
通过自动化的测试，生产环境、测试环境一致性保证将变更导致的故障尽可能的在投入生产环境之前被发现，使得我们的服务稳定性增加
在故障发生后能快速的回滚我们的代码降低损失，平均恢复时间同步降低
三、生产力、市值提高
通过上述两个优势我们获得了更多的客户，卖出了更多的产品，直接影响到了我们的营业额和公司市值
—
DevOps三步法
技术价值流：把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程
第一步：流动原则
建立从开发到运维之间快速的、平滑的、能向客户交付价值的工作流
目标：在缩短代码从变更到生产环境上线所需时间的同时，提高服务的质量和可靠性
一、工作流程可视化
示例看板
对于研发来说开发完某个功能，并不算是完成了某个需求，只有应用程序通过测试，并且稳定的发布到了线上环境实际的为客户和公司产生价值时才算是【已完成】
通过将每个工作中心放到队列中，并且可视化的展示出来更容易从全局的角度确定各个工作的优先级，调度所有工作中心的生产力
二、限制半成品（工作队列）
对于技术人员来说，每一次被打断看似无足轻重，但工程师一般需要极长的时间才能整理思路并且恢复到之前的工作状态，在脑力劳动中多任务并发处理会大幅度降低工作效率
通过限制工作队列的长度可能会导致某些人由于等待他人而无事可做，此时更好的方法应该是查明空闲的原因，而不是启动一项新工作
三、减少每次变更的内容
大批量发布的缺点
1. 功能上线时间被拉长，流动性变差
2. 发布时出现故障难以定位，增加故障时间
3. 某个功能产生的故障需要回滚全部变更
四、减少交接
缺点：
1. 每次交接消耗大量的沟通时间
2. 依赖性较强，工作进度依赖于被交接部门的优先级排序
3. 交接过程中由于信息不对称可能导致知识丢失
解决方法
1. 减少交接次数
2. 通过自动化来完成工作
3. 调整组织架构，减少依赖
五、不断改进瓶颈点
在任何价值流中，总是有一个流动方向、一个约束点，任何不针对此约束点而做的优化都是假象。
❏ 识别系统的约束点
❏ 决定如何利用这个系统约束点
❏ 基于上述决定，考虑全局工作
❏ 改善系统的约束点
❏ 如果约束点已经突破了，请回到第一步，但要杜绝惯性导致的系统约束。
六、消除价值流传递中的资源浪费
❏ 半成品：还没有彻底完成的工作、处于队列中的工作。随着时间的推移部分工作会失去价值
❏ 额外流程：没有任何价值的流程，例如从没有使用过的文档，或者额外的审批流程
❏ 额外功能：客户完全不需要的功能
❏ 任务切换：将技术人员分配到多个项目组中同时处理多个项目
❏ 等待：依赖其他的团队完成某些工作而导致自己无事可做
❏ 沟通效率：频繁的工作交接会导致沟通效率低下，而本应该做在一起办公的人却在不同的办公楼也会导致沟通效率低效
❏ Bug延期修复：bug的产生周期越长，需要付出修复的精力就越多
❏ 非标准或手动操作：Dont repeat you self
❏ 填坑侠：将某些人一直处于不合理的环境中
总结：
提升技术价值流的流动性对实施DevOps来说至关重要。为此，我们需要是将这些浪费和困境（任何需要填坑侠的场合）都可视化，并系统地进行改进，减轻或消除这些负担，从而实现快速流动的目标
第二步：反馈原则
在整个价值流和组织中建立快速、频繁、高质量的信息流，包括反馈和前馈回路，可以让系统更安全。并在不断从失败和事故中学习，增加系统的反脆弱性
一、及时发现问题
在技术价值流的每个阶段，所有的任务执行过程中建立快速的反馈机制，以便尽可能早的检测出来那些可能导致危险的变更
二、及时战胜问题，而不是拖延
遏制住问题，防止蔓延，然后定位和处理问题，避免复发，让所有的的参与者都能得到更深入的知识，理解并改进整个系统，使得员工与企业共同成长
这样做的好处：
❏ 防止把问题传递给下游
❏ 防止启动新的任务，这样可能带来更多新的错误
❏ 修复问题最高效的方法就是立刻修复他，而不是拖延
全民总动员的方式来解决小问题，才能把灾难性事故消灭在萌芽状态。
三、在源头保证质量
通过同行评审、自动化测试的方式提升开发代码的质量，让开发人员也对系统的稳定性和质量负责不仅可以提升可用性，而且还能使得开发人员快速学习
四、保证输出产品的质量
对于开发来说，需要对两类客户负责
1. 外部客户，功能的使用者，并且为我们付费的人
2. 内部客户，紧随着我们来接手并处理我们产出的人
根据精益原则，最重要的客户是紧接着要处理我们产出的那些人。我们需要为他们优化我们的工作
在技术价值流中运维的稳定性需求（如架构、性能、可测试性、可配置性和安全性）与用户功能同样重要。
总结：
及时的发现问题，并快速解决从长远的视角来看会节省我们大量的时间，而从输入和输出上控制质量，做到标准化操作，可以大幅度提升我们的工作效率
第三步：持续学习与实验原则
一、建立学习性的组织与文化
如果不指责，员工就没有了恐惧，没有了恐惧，就能够做到坦诚，而坦诚能够有效预防事故
在每次事故后，不进行职责性的回顾，而是应该对事故发生的原因和过程做出客观的解释，尽可能的避免本次问题再次发生，并且即使该问题再次发生，也能快速的故障定位和恢复系统
二、通过制度来改进日常工作
在时间的推移中，流程和制度会过时，需要不断的更新制度和流程，以满足团队效率最大化的目的，如果团队没有意愿来改进现有的流程，那么就会被各种问题所困扰
三、知识共享
当某个局部的实验取得成功后，需要快速的推广给其他人，例如建立内部知识库，让所有的人都能阅读他，方便的去解决日常工作中的各种问题，让知识服务更多的员工
四、领导层强化学习
领导者通过正确的决定来领导团队，但实际上优秀的领导力并非体现在所有的决定都是正确的这一个指标上，而是为团队创造条件，让每个成员发挥其最大价值
领导层通过持续学习不断的帮助一线员工解决日常工作中遇到的各种问题
—
全书总结
当然本书并不是十全十美，本书的几个问题：
1. 每个文章的目录都是以日期命名，并没有实际的框架，导致阅读有些困难
2. 英文转义的读物我们阅读起来难题就是各个英文人名，如果在翻译时转换成【张三、李四、王五】或许能增加更多的可读性