2020-10-20 读书笔记--DEVOPS实践指南

DEVOPS宗旨

Netflix 工程工具总监 Dianne Marsh 称，她的团队宗旨是：“以支持工程团队的创新和速度为先。我们不为这些团队构建、打包或部署任何产品，也不为他们管理配置。相反，我们构建自助工具。他们可以依赖我们的工具，但不能依赖我们的劳动力 

截图

开发人员数量与部署次数的关系

信封游戏

信封游戏疑问：考虑一种情况，一个人重复做相同的事情可以获得效率提升，而不断切换工作将无法获得“熟练”加成。那么实际上同一工作的耗时是不断减少的，意即F5

一些心得：其次信封1-5必须是相互之间完全独立的产品，不能有相互依赖关系，否则无法使用单件流模式。所以应用到DEVOPS领域，就需要对最小不可分的需求单元做严谨划分。目前大量DEVOPS实践遇到困难，很大程度是因为开发经理在需求分析阶段投入较少，需求不明确、依赖错综复杂，需求过于庞大又限于产品底层设计无法拆分等原因导致无法应用单件流模式，或者强行使用单件流模式，导致更为严重的风险。

不同导向的组织形式和效率对比

质疑：任何一个变革只谈好处不谈坏处，只谈解不谈前提都是耍流氓。回头来看当年集中运维的理由，技术分工使技能专业化，所以需要技术分组，再通过流程进行合作。而且集中运维可以节约人力，共享经济成本优于私人服务这是显然的。改为市场导向，整合不同技能形成团队，能保证专业性吗？人员的冗余如何解决？这些问题在现在已经不存在了吗？市场导向之所以成功是否是因为技术的发展使得条件成熟，从我的角度来说，与其说明市场导向好在哪，不如说明市场导向以前为什么不好。

正如网上常常有言论说中国古代重农抑商是近代落后于世界之源头，诚令人发笑。马克思指出生产力决定生产关系。重农抑商，农商并重，商在农先，先工后商这些理念不是无根之水，经济制度总是要因应时代的。姜齐以商立国，尊王攘夷，齐桓首霸，中国人并不是不懂商之重，但仍选择农本是有其理由的。

所以DEVOPS提出要以市场导向取代职能导向，必要以说明前向为何要选择职能导向，有何制约，而如今该制约已为何种技术进步所解缚，然后才可以向听众说明白这种改革的可行性。

成果展示

平均修复时间

监控系统

技术债务

“技术债务”这个术语是 Ward Cunningham 首次提出的.类似于金融债务，技术债务是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。即使我们审慎地承担技术债务，也依然会产生利息。

“暂时不能标准化，开发不想动，审计日志很重要“等等，我们总有各种理由，为了过去的包袱，只能背上更重的包袱。

恶性循环三部曲

大多数的 IT 从业者可能都对恶性循环三部曲很熟悉。

第一部曲开始于 IT 运维，我们的目标是让应用程序和基础设施持续运行，以便公司向客户交付价值。我们日常工作中的很多问题源于应用程序和基础设施过于复杂、异常脆弱、文档不完备。这就是我们背负的技术债务，这就是我们每天所处的工作环境 我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远都不会到来。更令人担忧的是，我们最脆弱的组件正支撑着最重要的业务系统或者最关键的项目。换句话说，那个最容易发生故障的系统就是我们最重要的系统，也是所有紧急变更的中心。当这些变更失败的时候，那些最重要的公司承诺，例如客户服务可用性、营收目标、客户数据的安全性和财务报告的精确性等，就会直接受到危害。

第二部曲始于有人必须去弥补最近未兑现的承诺一一这可能是某个产品经理承诺了一个更大规模、更大胆的吸引客户的功能，或者是业务主管设置了一个更高的收益目标 然而，他们无视技术能实现什么不能实现什么，以及到底为何没能兑现之前的承诺，而是让技术组织按照新的承诺交付成果。结果，开发团队被指派去做另一个紧急项目，这个项目必然需要解决新的技术难题，需要利用各种捷径以赶上承诺的发布日期，而这又导致了技术债务的增加一一此时我们又承诺一有时间就处理这次产生的所有问题。

在这样的背景下，我们进入了第三部曲，也就是最后一部曲 在这里，所有事情都变得更加困难一一所有人都越来越忙，工作所消耗的时间越来越多，沟通变得更加缓慢，工作积压得越来越多。我们的工作搞合得更加紧密，即使是很小的行动也会导致较大的事故，我们更加害怕和拒绝做出变更 工作需要更多的沟通，协调和审批；团队必须等待更长的时间，等待相关的工作完成；我们的工作质量持续恶化。车轮开始嘎嘎作响地缓慢移动，要想、使之继续转动，就需要付出更多的努力（见附录）。

尽管当我们身处其中时很难察觉到，但是当你退后一步，就会发现这个恶性循环是显而易见的。你会注意到产品代码部署消耗的时间更长了，从几分钟到几个小时，再到几天或者几周。更糟的是，部署的效果越来越差，这导致客户服务中断的次数越来越多，需要运维部门来救急，而他们也因此无法偿还技术债务。

结果，我们的产品交付周期越来越长，做的项目越来越少，项目目标也越来越小。而且，对所有人工作（尤其是对来自客户的反馈信号）的反馈越来越慢，且越来越弱。不管我们做出怎样的尝试，事情似乎总是变得越来越糟糕一一面对日新月异的市场竞争，我们不再能够快速响应，也无法为客户提供稳定、可靠的服务。我们最终因此失去了市场。

我们反复地看到，一个 IT 做得失败的公司，整个公司也都是失败的。正如 Steven J. Spear在The High locity Edge 一书中指出的，无论破坏“像消耗性疾病一样慢慢地发展”还是迅速得“像大火焚毁般……其毁灭性都是一样彻底”。

IT做得失败的公司，整个公司也都是失败的。或者说整个公司是失败的，IT肯定也会做得失败。管理的问题是相通的。IT的失败本质上是管理的失败，而不是技术的失败。IT并不能改变一个公司，IT只是公司整个生产链条上的一个环节，管理才是统筹这一切的中枢。中枢坏了，链条上任何一个环节都无能为力。

正如软件开发高管和早期的 DevOps 记录者之一 Christopher Little 所说 “每个公司都是科技公司，无论他们认为自己处在哪个行业。银行也只是拥有银行执照的 IT 公司而已。"

要说服自己这是事实，考虑一下，绝大多数投资项目都在某种程度上依赖于信息技术。俗话说：“想要做出一个不会带来任何 IT 变更的商业决策几乎不可能”。

说什么银行只是拥有银行执照的IT公司，理由是：“ 2003 年，欧洲的汇丰银行雇用的软件开发人员甚至比谷歌公司还多”。这个没有查到实际数据，如果想要证明这一点，也应该是说汇丰银行的IT人员比例比谷歌高才对吧。人员比谷歌多有什么好奇怪的，汇丰员工总数是谷歌的好几倍吧。绝对数量上多证明不了什么。

DEVOPS度量

代码和变更部署次数

代码和变更部署前置时间

可靠性，版本发布失败的比例

生产环境部署成功率

平均服务恢复时间

组织效能指标，需求处理效率

平均每个开发人员的部署次数

浪费

制造业里7种主要的浪费类型：库存、过量生产、过度加工 、运输 、等待、移动和缺陷。

浪费和困境是软件开发过程中导致交付延迟的主要因素，主要的浪费类型如下：

半成品：

它指的是价值流里任何还没有彻底完成的工作（例如，需求文档或尚未审核的变更单）、处于队列中的工作（如等待 QA 审核或服务器管理员审核的工单） 。部分完成的工作会逐渐地过期，随着时间的推移最终失去了价值。

等待领导审批是最常见的半成品，领导是职场中的稀缺资源。无数工单在等待领导审批的时间中发霉。期待“勤勉”的领导是不现实的。一个负责审核的领导意味着他要承担审核的责任，那自然需要了解他所要审核的内容，而这需要花费他巨大的精力和时间，还需要相关人员去解释，反复确认。当然，领导也可以完全不看，直接审核通过，那作为一个橡皮图章，背锅侠存在的领导真得需要存在于流程之中吗？

解放领导，把领导从繁重的审核工作中解放出来，这意味着领导需要把部分权力下放给专家或者专家委员会。同样的也把责任下放。对于控制欲很强或者下属都是垃圾的组织来说，这一点比较困难。所以知人善任，大胆放权，是解决这种半成品的前提条件。在人治的企业中，管理水平十分依赖于领导的管理风格。

额外工序： 

在交付过程中执行的，并未给客户增值的额外工作，可能包括那些在下游工作中心从没使用过的文挡，或是对输出结果做出的并不增值的评审或审批。额外工序不仅增加了处理的工作量， 还增加了前置时间。

额外功能： 

在交付过程中构建的那些组织或客户完全不需要的功能（如“镀金”）。额外功能增加了功能测试和管理的复杂度和工作量。

任务切换：

将人员分配到 个项目和价值流里后，他们需要进行上下文切换， 并管理工作之间的依赖关系，这会在价值流中耗费额外的工作量和时间。

等待：

由于资源的竞争而在 作之间产生了等待， 这将增加周期时间，延迟了向客户交付价值

移动： 

信息或数据在工作中心之间移动的工作量。例如，在一个需要频繁沟通的项目里，团队成员实际上不在一起办公，无法坐在一起紧密协作，这时人员移动的浪费就产生了。另外，工作交接也会产生移动的浪费，需要额外的沟通来澄清所有歧义的部分。

缺陷： 

由于信息、材料或产品的错误、残缺或模糊，而需要一定的工作量来确认。缺陷的产生和被检测出来的时间间隔越长 ，解决问题就越困难。

非标准或手动操作：

 需要依赖其他人的非标准的或手动的工作，例如使用不能自动化反复重建的服务器、测试环境和配置。理想情况下，任何依赖运维团队于动完成的操作，都应该配置成自动化的 、按需提供的 ，或者是自助服务。

填坑侠：

为了实现组织的目标， 不得不把有些人和团队置于不太合理的处境，这甚至成为他们的家常便饭（如半夜两点生产环境出现事故，连夜给软件版本提交了上百个工单）。

在复杂系统中安全地工作

Steven Spear 博士在他的哈佛商学院博士论文中揭示了丰田生产系统背后的因果机制。他认为，我们可能无法设计出绝对安全的系统，但是可以通过采取以下4项措施让复杂系统更安全地工作：

管理复杂的工作，从中识别出设计和操作的问题；

群策群力解决问题，从而快速地构建新知识；

在整个组织中，将区域性的新知识应用到全局范围；

领导者要持续培养有以上才能的人

群策群力

群策群力的原因如下：

防止把问题带入下游的处理环节， 则不但修复的成本和工作量会呈指数级增加，而且会欠下技术债；

防止工作中心启动新的工作，那样可能会在系统中引入新的错误；

如果问题还没有得到解决， 那么工作中心在下一次操作中，可能还会遇到相同的问题，需要更高的修复成本。

现实中，大部分企业的工作模式是群策群力的反面。每个部门都着眼于自身的权责，不愿意跨部门沟通和协调。因畏惧协调成本而增加技术债务。究其原因，如果当下就协调，则成本在我，留下技术债务，还债的却不一定是我。那如何选择就显而易见了。管理者要着眼于根本问题，避免下属画地为牢，才能以最低的成本解决问题。

安灯绳制度其实是一种反直觉的管理模式，是先难而后易。着眼于长远的管理模式往往难以推动，这取决于领导者的魄力和毅力。

质量控制无效

需要其他团队帮忙完成一系列乏味、易出错和手动执行的任务，这些任务本应该由需求方自己采用自动化方式完成

需要那些远离实际工作场所且公务繁忙的人批准，迫使他们在不了解工作情况和潜在影响的情况下做出决策，或者仅仅是例行公事式地盖章批准

编写大量含有可疑细节，且在写后不久就过时了的文档。

将大量工作推给运维团队和专家委员去审批和处理，然后等待回复

简直就像是在监视我的工作

我们总是被迫做错误的事情 ，明知道错误却仍然去做。曾经在做甲方的时候，感觉一切都顺利，也许是在一个优秀的领导的庇护下，你总是能做正确的事情，而转为乙方的时候，却不得不为甲方的懒惰和历史债务埋单。即使明知道错误，却仍然要因循，不思改变。

最近就有一例，某公司的基础设备管理十分混乱。服务器没有标准的命名规范，vcenter中虚拟机的命名与操作系统中的hostname不一致，甚至hostname都不加改变，大部分都是默认的localhost。我公司为其部署自动化资源采集，无法将vcenter中的虚拟机与实际的操作系统关联。此事其实易解，只要制定相应的主机命名规范，并且将主机名分批调整即可。然而托辞以人力不足，修改主机名有未知风险为由，无法推行。反而要求自动化信息采集平台适应此形势，无谓增加成本。究其理，主机名规范化，成本在甲方运维团队。修改自动化信息平台的采集方法，成本在乙方，如何选择不问可知。然后哪一种方案是“正确”的也是不问可知。

工程师的思维往往是“直线”式的，古人亦有云，宁向直中取，莫向曲中求。作为一个工程师，心中实在郁结。人生不如意事，莫过于行事违心。

do right things 知易行难