Neohope的网络笔记

公司是脚，业务是穿鞋的场景，技术是鞋子。

先考虑技术，再考虑业务，往往会导致削足适履，让你怎么穿都别扭；
不考虑技术，只考虑业务，会导致打赤脚或穿草鞋，让你天天肉痛。
两者一起考虑，才能找到合适你的跑鞋、登山靴或轮滑。

不懂业务的技术人员，很难设计出一双适合用户的好鞋子；
不懂技术的业务人员，至少知道用户要一双什么样的鞋子。
所以，你不懂业务，技术再牛，也要听懂业务的。

一句话，除非你是搞理论研究或专业分工的，否则，脱离了业务说技术都在是耍流氓，脱离了业务谈架构同样是在耍流氓，脱离了业务天天扯一堆前沿名词就是大流氓。

Hansen的工作笔记001

最近，根据工作安排的调整，参与了部分售前支持工作，发现了工作上的一些不足之处：
1、个人对公司产品的理解不够深入，对用户的最关心的痛点理解过于肤浅，对行业态势了解滞后，对竞争对手了解太少。
2、公司产品的相关文档太少，苦了售前、实施各位大哥大姐。
3、沟通时，技术性仍然太强。回想起来，用户、售前和销售人员居然表示可以理解，也太难为他们了。后面要做到，对方不懂技术，也可以讲明白。
4、有时候，过于急躁，看到自己写的“戒骄 戒躁 戒懒”的便利贴，还是脸红了一下。

改进措施：
1、多学习。就像前面和杨荣聊的，人懒了，放弃学习了，也就掉队了。你做软件，做不到35，除了自己谁也别怪，只能怪自己。
2、多沟通，多讨论。沟通和讨论，是一个很好的可以帮自己系统梳理思路的好方式，关键是不累心。
3、知识组成要多元化。团队成长到一定阶段，即需要专精人才，也需要综合性人才。要及时找到适合自己的路子。但即使你走专精的道路，也要让自己的知识构成多元化一些，才不至于闭门造车。
4、搭建了OpenKM，替代了没人用的Wiki。希望可以发挥一些作用。感谢陈燕婷的大力支持。
5、要逼着各位产品经理、技术经理补充缺失的文档。相信对他们也有很多好处。
6、加强个人非技术的沟通技巧，文档写的要让非开发人员可以读懂。

归纳一下，调动员工积极性的关键：
首先要把员工当作经营伙伴迎入公司；
要让员工从内心爱戴你、迷恋你；
要阐述工作的意义；
要树立高目标；
要确立具备大义名分的企业使命；
要不断讲述哲学；
以及经营者要提升自己的心性。

书中的另一种表述：
把员工当作经营伙伴，要去依靠他们
让员工爱戴你、迷恋你，要有领导气质
阐述工作的意义，让大家认可自己的工作
揭示高目标，让工作有挑战性
明确企业的使命，所有岗位都要揭示大义名分，让大家理解工作的意义
不断讲述哲学，让大家有凝聚力
提升自己的心性，企业才能进步

模拟京瓷的使命，我们公司的使命是：追求全体员工物质与精神两方面的幸福，为世界卫生事业进步发展做出贡献。

本书中我最喜欢的（也是唯一的）一张图表显示，等待时间是工作中心中某个资源忙碌程度的函数。埃瑞克用这张图表来说明为什么布伦特的30分钟的简单变更要耗费几个星期才能完成。原因显然是，作为所有工作的瓶颈，布伦特的使用率一直是100%甚至超过100%，因此，我们每次交给他的工作都只能在队列里枯等，如果不进行加速或升级处置，就永远不会完成。

图表显示：横坐标轴上是工作中心中给定资源的忙碌百分比，纵坐标轴上是大致的等待时间（更确切地说是队列长度）。曲线的形状表明，当资源使用率超过80%时，等待时间就会直线上升。

本书中，比尔及其团队意识到，他们对项目管理办公室承诺的交付期会带来怎样的灾难性后果。

我告诉他们，埃瑞克在MRP-8对我说过，等待时间取决于资源使用率。“等待时间是‘忙碌时间百分比’除以‘空闲时间百分比’。也就是说，如果一个资源的忙碌时间是50%，那么它的空闲时间也是50%。等待时间就是50%除以50%，也就是一个时间单位。就说是一个小时吧。所以平均来说，一个任务在处理前的排队等待时间为一个小时。”

帕蒂似笑非笑地说：“哦，当然了。因为输入字符只需要30秒，对不对？”

比尔及其团队意识到，他们那个30分钟的简单任务实际上需要7个交接步骤（也就是服务器团队、网络维护团队、数据库团队、虚拟化团队，当然还有布伦特、布伦特、布伦特）。假设所有工作中心都有90%的时间是忙碌的，那么这张图表告诉我们，在每一个工作中心的平均等待时间是9个小时。由于工作必须经过7个工作中心，总共等待时间就是7倍：63个小时。

也就是说，总的“有效时间”（有时候也称为“加工时间”）只有总交付周期的0.16%（30分钟除以63小时）。那就意味着，在总交付周期99.8%的时间里，工作只不过在排着队等待被执行（例如，在报修系统里等和在电子邮件里等）。

我的合著者乔治·斯帕福德和我同在华盛顿州立大学参加詹姆斯·霍尔特博士（在延伸阅读部分有更详细的介绍）的EM526约束管理课程时，我们首次见到了这张图，它如此出色地显示出，高资源使用率所导致的长时间排队的破坏性本质。

遗憾的是，我不知道这幅图的确切来历。有人和我一样相信，这幅图是立特尔法则的简化版本。根据这个法则，我们假定的是只有一个工作中心、均匀的工作队列（例如，所有任务需要的完成时间都相同）、工作之间没有延迟等。

在这幅图中，我相信“等待时间”其实代表着“队列长度”。也就是说，由于它不是所用时间，因此没有时间单位（也就是说，既不是分钟，也不是小时、天）。关于此书派生出来的最棒的讨论（及其合理性/不合理性）都可以在Linkedin网站上本书的页面看到。这些讨论尽管有时略显尖刻，但确实充满智慧。

我的看法是，科学的目标是用最少的原理来解释最多的现象，并揭示惊人的内涵。我认为这张图很能说明问题。它有效阐释了过度压榨IT工作者的灾难性后果，以及在IT运维部门使用传统项目管理方式的错误。

由于布置工作的途径比以往更多（例如电子邮件、电话、关于业务应用程序的中途会谈、短信、报修系统、会议等），我们希望直观地看到现有任务。

埃瑞克告诉比尔，IT从事着四种类型的工作。

业务项目

这是多数开发项目所包含的业务举措，通常隶属于项目管理办公室。项目管理办公室跟踪管理公司内的所有正式项目。

IT内部项目

包括可能由业务项目衍生出的基础架构或IT运维项目，以及内部生成的改进项目（例如创建新环境和部署自动化）。这些项目经常并非集中跟踪，而是属于预算所有者（例如数据库经理、存储管理经理和分布式系统经理）。

当IT运维成为瓶颈时，这会导致问题，因为不能轻易查明已经在内部项目中投放了多少生产能力。

变更

经常由上述两种类型的工作引起，往往在报修系统中被跟踪（例如IT运维补救、JIRA或者用于开发的敏捷计划工具）。事实上，在价值流的两个不同部分中存在两个工作跟踪系统，这会引起问题，尤其是在交接工作的时候。

偶然情况下，在一些兼具功能开发和服务交付职责的专门团队中，所有工作都处在同一个系统之中。这样做有一些好处，因为操作层面的故障会和功能缺陷以及新的特性功能一起，在存量工作和现行工作过程中显现。

计划外工作或救火工作

包括操作事故和操作问题，通常由上述三种类型的工作导致，而且往往以牺牲其他计划内工作为代价。

在本书中，我们阐述了这一基础原理，即所有开发运维模式都来自“三步工作法”，它旨在阐明指导开发运维的流程与实践的价值观与理念。

第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。必要的做法包括持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。

第二工作法是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；日复一日地持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普遍的产品遥测技术，让每个人都能知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。

第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。必要的做法包括营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。

《凤凰项目》是一本介绍DevOps的书，书中有一个叫做布伦特的人，他个人能力很强，工作超级努力，对公司的各种IT环境了如指掌，做事情超级靠谱，大家都喜欢找他合作，有了问题也会第一时间想到他，就是一个公司的英雄人物。

但问题是，长期的工作模式，导致了IT部门几乎所有重要事情都需要布伦特参与才能成功，于是可怜的布伦特天天加班，而且无论如何都完不成堆积如山的任务，最终造成了大量的任务积压，IT部门被各种投诉。

同时，由于工作压力，布伦特更加没有时间写文档，做事情只好走捷径，甚至会直接变更一些数据流程，最后很多环境只有他清楚，很多事情只有他可以做，就是一个恶性循环。

新上任的比尔将布伦特识别为IT生产环境中的约束点，并对此采取了对策：

1、告知布伦特，拒绝除凤凰项目以外的任何项目，如有疑问直接找布伦特的领导沟通，并与CEO取得了共识。让请求需要通过层层过滤才能达到布伦特，从而保证了布伦特可以将精力放到最重要的项目中，让布伦特去做该做的事情“偿还技术债务，保证系统的稳定性、安全性、可扩展性、可维护性、可操作性、持续性”，而不是“修理打印机，升级电脑，连接网络”；

2、对所有积压的任务，进行区分，所有不需要布伦特参与的变更都可以根据优先级执行，所有需要布伦特的项目都需要等待凤凰项目，从侧面引导大家使用其他资源，并在此确保好钢用在刀刃上；

3、在其他部门领导绕过流程，直接为布伦特安排其他工作时，直接抽丫的；

4、围绕布伦特，组建了一个资深小组，学习布伦特的工作经验，并形成文档，将布伦特的经验传授过所有人，将布伦特从各种复杂繁琐的事情中解放出来；

5、最后，将布伦特整理的各种脚本，做成自动化发布软件，最终解放了生产力；

最终结果是，一开始大家承受了很大的压力，但经过一段时间后，大大提升了工作效率。并发起了独角兽和独角鲸项目，取得了成功。

我们周围的布伦特是谁？我们有好好保护他吗？我们有找人帮他把经验变成团队的经验吗？我们如何帮他提升到一个新的水平？