凤凰项目节选内容、记录和重新描述

从中了解一些IT系统的问题，处理方式，工具的使用。
另外是三步工作法的深入了解，让自己能更快速的理解体会开发运维的的思想，成为生产的一部分。

1. 了解IT运维部门的变更工作量

由于变更引起的工资结算问题，促进了变更审批会议的落实，所有变更都必须事先审批后再实施。
具体操作：每个IT运维人员通过便签提交自己的变更，上面需要有制定变更人，需要改动的系统，一句话的概述。
事件中收集了一周内的变更有400个，从中还讨论到以下信息和处理方式：
变更就是对应用程序，数据库，操作系统，网络或硬件进行的物理，逻辑或虚拟操作，并且这样的操作可能对相关服务产生影响。
易损品：容易出问题的老旧系统，要对其作变更必须审批才能实施。需要明确变更的时间（需要告知相关的业务部门风险，并由业务确定变更时间），需要明确操作的人员，需要做安全措施（操作后的待命，包括产品供应商）
标准变更：一直在进行的常规的重复的成功进行的变更，直接安排实施。
中等风险：变更提交者得到受影响人员的认可后，提交审核后安排日程。

2. 工作参观

在原材料从车间的一侧进入，成品从车间的另一侧运出，期间有很多工作中心，即一些工序，其中有一些会被称作约束点，在这里的是烘房和涂料固化两个工作中心。半成品（WIP）会堆积在约束点的前面，因为约束点是所有工序中最慢的。半成品会引起长期性交货期限问题，质量问题，导致督办员每天调整优先级的根源之一。（查看后面内容会有更多了解）

另外车间的第一个工作站应该如何选择工作？这个工作站选择不同的工作就会有不同的后续工作流动到后面的工序。先到先做？还是根据约束点所完成工作的速度来安排工作呢？（不急于理解）
约束点外的改进都是假像，约束点前的改进只会造成更多的半成品堆积，约束点后的改进也是没有作用，因为约束点没有产出到一个工序。

重点信息：（后面的内容会反复提到）
确保形成一条迅速，可预测，持续不断的计划内工作流，从而向业务部门交付工作价值，降低计划外工作的影响和破坏。
确保绝大数受约束的人力资源，都只能投放在为整个系统的目标所服务的工作上，而不是只为一个部门的目标服务。
三步工作法：
建立快速工作流，业务-开发-运维-客房；
缩短及放大反馈环路，从而在源头上解决质量问题，避免返工
鼓励探索，吸取教训，反复的实践是精通工作的先决条件。

3. 1级故障，信用卡系统故障

处理方式：不能单凭猜测处理事故，跟进所有相关的变更和时间线，核查事故原因。后续安排2周一次故障排查实战演练，认为是第三步工作法，不断让系统承受压力，多次练习后对故障就能产生更有效更快速的应对。
规范：不准未经授权的变更，中断期间不准未经公开的变更（引起问题的恶化）

4. 变更调整

变更工作以便签形式安排在一周的排期表里后，即将工作可视化了，这个工具称为看板。
周五会有公司重大项目凤凰的部署，经过提醒后，不少人把变更调整得离周五更远的日期，让每天的工作更均匀，并可以看到相关的变更是否有冲突，便于发现问题和调整工作。

5. IT工作分类

内部IT项目
业务项目
变更
计划外的工作，破坏力极强，打乱计划内的工作，60%的变更没有实施，如果再拖延一周，变更将会达到上千，即半成品大量堆积（原因是：凤凰部署所引发的问题，耗费了大量IT资源，特别指专家）
解决办法：利用下边提到的处理故障的工程师处理部分变更，分批让专家处理变更

6. 初步对约束点的优化

IT系统专家就是IT工作的约束点，很多工作都需要其参与，很多故障也要他来解决，难以找到一样的人，因为新找的人也没办法能对系统有这么熟悉，所以所有问题还是由他解决，有些人还缺乏工作。

处理办法：要把约束点保护起来，让其专注在核心业务。中断外界与其联系，设立一个3级工程师队伍才能与其接触，让他们学习和记录专家解决故障的方法，形成知识库。对专家和工程师们实施奖惩，提高学习效果。

7. 凤凰问题

开发环境与测试环境难以调整到一致；
QA检查到问题后，要等开发人员提供新版本；
代码都是局部提交，总是有遗漏；
版本编号不严格，解决问题的同时又产生了一些问题。

紧急处理办法：单一人员处理交付的新代码（带性能缺陷编号），交接例行发布，文档记录，标签和版本标记，再由单一人员统一发布信息。

业务部门需要多功能而快 - 开发部门走捷径 - 日益恶化的部署 - 是一个脆弱的应用程序 - 故障而需要版本更新 - 没有开发功能 - 业务部门用不上 （没这么容易解决）

重要信息：
在你建立起一个可信赖的系统用以管理通向约束点的工作流之前，约束点经常是闲置的。（约束点要等必须的材料）

未还清的技术债务（来自于走捷径，如金融债务，利息成本越来越高，部门没付清，公司以计划外工作来偿还），计划外工作量会不断增加。

永远不要让约束点迁就别的资源而干等着。

专注于所需完成工作中优先级最高的那一项。

drum - buffer - rope限制驱导式排程法，要以限制的需求来驱动管理整个系统动作的节奏。换言之，是一切决策要以系统限制的需求为优先考量，而系统其余的非限制则要配合限制的决策。

程序除了功能性，还需要加入稳定性，安全性，扩展性，维护性，可操作性，持续性，甚至有效性，存活性，保障性，防御性等

将无用工作剔出系统

哪些工作与企业目标息息相关？

重要的是结果，指营利。

车间如何确定是否接受一项工作，需要看原材料，工艺清单，车间的负荷量，是否会损害工作承诺。

计划外工作的代价非常昂贵，是以计划内工作为代价。

计划外工作的副作用：救火 - 不能按计划工作 - 被动 - 没时间思考 - 被动接受项目 - 工作周期变短 - 有害的多任务处理 - 使用劣质代码（捷径） 是一个死循环

领导的问题：不知道实际工作能力有多少 - 不合理承诺 - 无视已有的全部工作

需要保护约束点，确保工作顺利的流经约束点

提高整个系统的生产能力，不只是提高作务的完成数量（工作要根据目标而制定，有的放矢）

安全方面：没有可靠的工作系统，何来可靠的安全控制系统（分清主次，不能强调不合理的安全）

半成品数量下降交期性能会提升

8. 由上面过程产生重大的改变，不再接受新项目，除了凤凰，停止所有工作

开发有时间处理技术债务
其他项目的开发人员可以加入到凤凰里

9. 监控的作用和重启哪些工作

服务于约束点（专家），有了监控就可以更快的知道问题，排查处理也更容易

采取一切必要手段，让工作经过理多环节才能到达专家那里（让工作更容易处理）

适当提高预防性工作是全面生产维护等计划的关键，如加强维护，保证机器可用率。

要重新启动各项IT工作，可以把工作分成不同类别以颜色卡来区分，重要的工作可以是紫色，一般变更黄色，绿色IT内部项目，粉色有问题的；要进一步优化工作，应该投入到内部的时间要在20%左右（替换架构，供应商升级，审计和安生，升级，替代易损服务等），紫色和绿色要平衡；

由于专家还是约束点，在重启时，还要把所有工作分成3个部分，需要专家参与的，可以提升专家工作效率的，其他。可提升专家工作效率的工作可以进行（包括监控）。

重要信息：
为了降低专家拿到资源的等待时间，需要将工作需要的资源了解清楚，制作各项工作的物料清单（对应于工作中心的工作物料清单包括：机器，人员，方法，测评），控制台，终端，磁盘，应用程序，许可证密钥等。

改进日常工作比开展日常工作更重要。如果不改进，工作效率会下降，系统偏向于无序化。要形成改进形的文化，分解为计划，执行，审核，落实。习惯才能变得精通，每天5分钟的训练比一周3小时的训练更有效。

工作交接：如果一个资源的繁忙/空闲比例为50/50,假定这样会形成一个单位的等待时间，当比例为90/10时，等待时间就为前者的9倍，每一次交接如都如后者，5个交接将是45个单位时间的等待，所以要维持工作中心有适当的空闲，不要高于80。

为了更少的等待时间，需要有人把材料送到工作中心，等工作完成，把成品拿到下一个工作中心（车间中的水蜘蛛）

安全工作的有效标准：是否提高工作流量（少了问题处理算其只一种方式）？是否提高稳定性，缩短中断和修复时间？是否产生半成品？安全工作应该在产品制作过程就添加防控措施，不是等产品做出来再考虑安全问题。

常规工作用看板安排：改换办公室，添加、修改，删除帐户，配置新电脑，重置密码，每一项都分成待办，在办和已办，可以让工作人员信息和工作状态，工作预判和跟踪都提供到支持，可视化工作是很重要的工作方式。尽量让更多的工作以这种方式进行，提高效率。

部署工作就好像生产线的总装配，把所有零部件集中安装成为成品。

9. 由于还是有众多的项目和变更项目，必须要跳出IT的范围，站在公司的角度，才知道哪些IT项目跟公司的目标相关。探访完成公司关键指标的经理。

销售部门需要物料需求计划系统，电话系统和CRM，前者可以让销售知道库存，哪些缺货; 电话系统是跟跟客户沟通的方式；CRM可以纵观客户的跟进情况，有哪些需要改进。

门店需要订单输入系统，录入客户的系统；需要库存管理系统，知道有哪些库存，如何调整促销策略；另外需要根据订单和销售数据生成报告的功能，更快的对市场作出反应。

由此可知道IT部门需要向哪些模块作力，加强模块的功能，稳定模块为业务部门提供支撑。

10. 后门项目

由于业务部门需要马上使用某些功能，向外部购买了服务，这个服务需要接入到数据库，会引起安全风险。

凤凰最新部署还是出现了很多问题，也是由于上门的后门引起要修改大量数据。另外凤凰的代码即使修复了，还是有大量的问题，体量也很大，部署慢，功能升级慢，而业务需要更快更新的功能，促进了下一个解决方案。

单一工作流可以让生产能力最大化，可以理解为不断生产同一个产品效率最高；在时间允许的情况下，要调整生产，应该是生产跟目前产品差不多的产品，调整少，不影响生产速度。如果小范围优化，应该是小批量生产，适当调整而可以优化产品。

生产不能倒档，生产到一部分再返回去加工，返回去代表浪费（不合格，缺少规范，返工）。

解决方案是新建一个团队，专门开发业务必须要使用的功能，开发速度（跟上客户所需的周期时间），目标可以一天部署十次，在生产中定期变更。

建立反馈环路快速的从业务反应到产品定义，设计及开发的最初环节（还可以加上安全措施）。

业务、开发、QA、运维一起工作，时刻准备环境，按需投产，部署流程自动化；生产环境的基础架构全部形成代码；需要的一切都形成代码；

需要高的敏捷度，这样可以开发出更多功能，只要有10%的功能产生收益，就可以收回成本，赚钱。

代码不再部分提交，直接生成代码包，直接部署。

新项目使用了新的数据库类型，数据库跟原数据库同步，这样可以使用新功能而不影响旧功能，但是防止无序扩张，定下了后续将数据库类型标准化的任务，这样人员不用掌握多种技能，更能精通。

利用云支持短时高峰值的计算需求。

安全和QA一起测试，实现测试自动化。

由于业务成功，业务流量太大，需要停止开发的推荐功能，降低服务器压力，仅使用了几分钟即可禁用了一个功能，这是友好型的研发设计。

后续工作优化，使用15%的时间用于预防性基础架构项目（即改进）；压力测试，主动攻击IT系统，反复实践，让其更能牢固。

IT技能如电力是公司的关键能力是公司的核心竞争力。

IT是公司的一环，IT不要高估，如有些合规问题不需要IT系统来完成，也不能被低估，要明白IT渗透在公司所有工作中，必须要重视。对IT也要像对汽车的定期保养一样，如果不保养，汽车在某一个时候就不能工作，这是要避免的，在IT来说就是打补丁，升级。

审计只有3种内部控制目标，财务报告的可靠性，符合法律法规，运营的效率和效果。

凤凰项目投入3年还不能正常工作，基本上是不能营利了，产品需要快速上市，快速淘汰。产品开发周期长，资本锁定这时没有回报的，一般项目需要在一年内上市，最低收益率为10%，低于10%代表没有利润。

安全优化：变更的同时标记审计范围，做好记录，避免后续重复工作；清除风险数据，可以降低保存成本；外包可分离的风险项目。