Phoenix Project Reading Notes
读书笔记 —— 《凤凰项目：一个IT运维的传奇故事》
本书从IT运维管理者的第一视角，讲述了IT部门每天都会发生的事情，并通过从工厂管理经验中借鉴到的方法，改善了IT部分的产能的故事。
IT工作者的每日工作项目
IT人员的工作往往分为如下几个项目。所以每一个程序员需要重视这四类工作。
业务项目
这是多数开发项目所包含的业务举措，通常隶属于项目管理办公室。虽然是IT项目，但大多数是跟业务的利润有直接相关联。
IT内部项目
IT内部项目包括可能由业务项目衍生出的基础架构或IT运维项目，亿级内部生成的改进项目（例如创建新环境和部署自动化等）。这类项目业务部门并不是直接集中跟踪管理的，而属于预算所有者（例如数据库经理、存储管理经理和分布式系统经理）。
变更
经常由前两种类型的工作引起，往往在保修系统中被跟踪（例如IT运维补救、JIRA或者用于开发的敏捷计划工具）。事实上，在价值流的两个不同部分中存在两个工作跟踪系统，这会引起问题，尤其在交接工作的时候。
某些情况下，在一些兼具功能开发和服务交付指责的专门团队中，所有工作都会处在同一个系统中。这样做的好处是，操作层面的故障会和功能缺陷以及新的特性功能一起，在存量工作和现行工作中显现。
在生产环境的变更是需要严格关注的，有的公司会专门对生产环境的变更进行记录。尤其会对变更本身的原因，步骤，以及风险评估和处理细节都进行记录。变更记录会交由管理者进行审批从而在计划时间窗口生效。
计划外项目/救火
包括操作事故和操作问题，通常由上述三类型的工作导致，而且往往以牺牲其他计划内工作为代价。
布伦特——约束点问题
文中的工程师布伦特是IT运维部的约束点，原因是：
- IT运维工作中最优秀的救火队员
- IT运维视角唯一的项目系统架构师
- IT变更项目中时常存在的执行者
- 项目半成品堆积：由于救火项目或者忙等待问题造成。
每个工作中心中都存在他的身影，个人能力的有限决定了IT部门的产出有限。
约束点问题解决了，工作产能问题便能解决。所有在非约束点做的改进都是假象。
对应的改善约束点问题的方案：
- 建立L3支持工程师代替执行并学习布伦特的救火技术，建立其他人可以借鉴的trouble shooting检查清单。
- 专一做到资深架构应该做的工作：关键项目的系统架构
- 将需要布伦特参与的项目进行工作和流程标准化管理
- IT工作可视化并控制半成品
等待时间是工作中心中某个资源忙碌成都的函数。下图横轴坐标上是工作重心中给定资源的忙碌百分比，纵坐标轴上是大致的等待时间（更确切的说是队列长度）。等待时间=忙碌时间百分比/空闲时间百分比。曲线的形状表明，当资源使用率超过80%时，等待时间就会直线上升。这会对项目交付产生灾难性后果。
看板对于IT中的半成品问题是最有效、最简单的一种对策。两本书推荐阅读：
- 《个人看板:了解工作/驾驭生活》by吉姆·本森和托尼安妮·德马里亚·巴里
- 《看板方法：科技企业渐进变革成功之道》by戴维·J·安德森
工作流程改进————形
为了将IT的工作项目完善的进行预先评估和量化分析，每一项工作类型都可以进行执行周期的管理与规划，尽量减少工作半成品的积压，并且最大化工作成品的“吞吐量”。本文提出需要进行“改进形”计划：
以两周为周期，进行两个“计划-执行-审核-落实”改进周期，确立项目需要的四大要素：机器、方法、人员与测评。每两周必须做出一些改进，无论任何形式的改进。
积压的项目分为三类：需要布伦特参与的项目，可以提高布伦特生产力的项目，其他项目。优先开展后两类项目；对于需要布伦特参与的项目遵循约束点问题解决方案进行优化。
“改进形”带来的好处：
- 提供一种适用于各种问题或挑战的系统化科学规程；
- 组织成员普遍养成解决问题的习惯；
- 通过让经理开展周期性指导，让其向教练和导师的角色转变；
- 通过让人们每天慢慢进步的方法，形成PDCA（Plan-Do-Check-Action）。
微软IT案例研究《在9个月内实现逆袭：在微软IT部门应用鼓点-缓冲-绳子解决法（译注：即限制驱导式排程法）》，作者是戴维·J．安德森和德拉戈什·杜密特里乌。
当时安德森和杜密特里乌两人都在微软，他们描述了以前那种糟透了的状态。大多数IT从业人员>对那种状态都再熟悉不过了。
❑ 完成业务部门要求的工作耗时过长：平均交付周期是155天。
❑ 对于延误和长交付周期的不满迫使IT管理作出“更多的工作预估”，这让经理们不得不把全部时
间都用来做PPT，而不是干实事（因为业务部门的结论是他们没有作出正确的工作预估）。❑ 不管业务部门提出什么要求，回答永远是“做这件事需要5个月”。
❑ 每项任务都预计在20天内完成，但是没人知道多出的那135天都去哪儿了。
杜密特里乌在报修系统中创建了一个名叫“等待德拉戈什”的新字段（实际上，这个报修系统是微>软缺陷跟踪系统），以及时发现工作阻碍。他很快得出结论，项目团队70%的时间都卡在了别人>那里——也就是说，在70%的时间里，工作都在排队。
杜密特里乌认为，他的团队一个月只能完成3项工作，按照这个速度，需要三年才能完成所有的>工作。以下是他提出的对策及其惊人结果。❑ 他们不再预估工作，而采用根据历史数据得出的实际时间——他们有80个人——报修系统里有多>年的工作记录供他们使用。这样做的结果是开发和测试效率立刻提高了30%。
❑ 他们不再采用成本核算，而采用简单的“基于预算贡献的ROI（Return on Investment，投资>回报率）”。所节省的时间让PM能力立刻提高了20%。
❑ 发现约束点是开发部之后，PM接管了许多开发任务，把开发能力提高了20%。这样做也让开发>人员更加高兴，因为他们可以专心写代码，不用再作任务预估了。
❑ 他们引进了一名可用性专家来调整变更申请表。（他打趣说：“我们得填完4页表格，才能得到>一杯水；我们把4页表格换成2页的，上面还有很多自由格式字段，目的是保证从事这项工作的人>了解其所需的全部信息。”）
❑ 接着他们减少了系统中允许的半成品数量：一开始平均有40到60个未结项目，他们把未结项目>数减少到了5个。
❑ 然后他们创建了工作缓冲区，任何遇到阻碍的开发或测试人员都能在缓冲区里做一些工作。
❑ 交付周期从155天下降到22天。这么短的交付周期让他们创造了一个新的SLA认证（SLA >guarantee）,25天（哇哦！）。
❑ 他们的下一轮生产能力大幅提高来自于增加开发人员数量，因为每两天的开发工作就需要一天>的测试工作。他们提拔了愿意参与开发工作的测试人员，把开发人员和测试人员的比例从1∶1提>高到2∶1。
❑ 上述种种的结果是什么？他们在9个月里完成了整整3年积压下来的工作；对他们服务的需求量>也增加了，然后他们继续在其后的每个月都顺利完成并交付了所有业务部门要求的工作；不仅没>人被解雇，而且很多人还升了职。
杜密特里乌说：“我们始终致力于降低交付周期，而不是开发和测试自身的优化，因此我们成功>了。”这只是详细描述的众多惊人转变之一。难以置信的是，转变主要不是基于自动化，相反，这种不>可思议的改进来自于调整关于工作系统的策略和控制半成品的策略，确保有一个高效的跨职能团>队，让所有事情都为约束点服务，以及管理好工作交接。
IT工作管理核心思想
三步工作法
第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，决不让缺陷刘翔下游工作中心，并且不断为了整体目标(相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。
必要的做法包括持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。
第二工作法是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。
必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；日复一日地持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普遍的产品遥测技术，让每个人都能知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。
第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。
尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。
必要的做法包括营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。
团队领导力的寓言
这是帕特里克·兰西奥尼在《团队领导的五大障碍：关于领导力的寓言》（The Five Dysfunctions of a Team: A Leadership Fable）一书中描述的方法。
他认为，团队无法达成目标的一个核心诱因是信任缺失。在他的模型中，五大障碍被描述为：
- 信任缺失——不愿在团队中显示弱点；
- 惧怕冲突——在充满激情的建设性辩论中寻求和谐的假象；
- 缺乏诚意——假意与团队的决策达成一致，形成模棱两可的公司氛围；
- 回避问责——面对员工的失职行为，逃避追责，降低了工作标准；
- 忽视结果——对个人成就、地位和自我价值的关注超过了对团队成功的关注。
考虑到开发部和IT运维部之间，以及IT和“业务部门”之间存在着长期、剧烈的部门斗争，我想我们非常需要兰西奥尼先生的教诲以实现开发运维的理想。
通常来说，运用兰西奥尼先生方法论的第一步，是领导人要展示自己的弱点（或者起码要从塑造示弱的行为着手）。在《凤凰计划》中，史蒂夫多年来已将这一实践内化于心，并主导了一场关于个人经历的分享活动。
信息安全问题解决思想
以不对IT系统做过多无用功就保护公司不受审计困扰，才是最终的胜利。而不是一昧的强制加入新的安全补丁，限制IT系统的功能与产出更多的维护问题。正如QA不需要测试不再需要的功能和不可能发生的性能压力，不要犯“眼界的错误”。
优先项目永远优先
关乎公司存亡的项目永远放在第一位。必要时可以冻结其他项目进度以提供充足的资源，人力和时间。