标签：天都 命令 监控 系统 基础 基础设施 包括 工具 情况
提高DevOps工程师软技能，可以了解一下笔者前一篇文章《DevOps工程师必备软技能》《凤凰项目》是DevOps界神书，虽然内容表现形式是小说，但是依然是敏捷开发及DevOps领域的必读书籍。很多知名的咨询师都是通过此书开启了DevOps及敏捷之旅，书中故事均来源于运维的日常工作，正是体现了艺术源于生活、高于生活的本质。笔者间隔两年时间，阅读此书两次，希望可以讲书中了解到的一些经验分享给大家。
小说主人公比尔，临时接任了IT运维经理的职位，然而此时，公司已经经历了多轮裁员，生产线上故障不断。董事会指望凤凰项目重启拯救公司，然而面对的着层层困难，比尔开始不停的应付突发的线上故障，身心俱疲。为了生存及公司的正常运转，尝试出一套适合该公司的IT转型方案，整个转型过程就像我们从传统开发模式转型DevOps的开发模式一样，踩过很多坑，总结出很多道理，小说的内容我不过多叙述，了解精彩的故事可以直接去购买图书，下面会给大家总结一下书中的一些重要的经验。
在故事中，主人公比尔在接替IT部经理后，通过一系列的故障处理与人际交流的过程中，得出了这个结论。IT的工作无非就是如下四种类型：
从IT的四种工作形态中，我们引申出一个问题，如何减少救火行为呢，我们先看运维圈里的两个定律
著名的二八定律：线上80%的故障来自于20%的变更。
GoogleSRE理论：大概 70% 的生产事故由某种部署的变更而触发
我们不去纠结80%与70%的差异是怎么产生的，但是结论是统一的，大量的线上的故障都是由于变更导致的，变更包括对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作。可以看到，这些内容覆盖了大量的运维工作了，为什么运维容易背锅呢，就是因为平时要处理这些高风险的变更操作，才容易引起线上的故障。而外人看来，运维就是在制造麻烦，之后开始救火工作、解决故障。为了避免种情况，该怎么处理呢？文章中给了我们很重要的方法，就是用看板的方法，规范化所有变更的管理，有计划的进行每一次变更，评估每次变更带来的风险点，就算出现故障，也可以快速修复。
在解决所有变更导致的故障的时候，小说中出现了一个重要的人，杜伦特，这是运维团队中的一个英雄角色，没有他解决不了的问题。但是就是这么厉害的一个人，所有开发人员都喜欢找他进行变更，所有的系统故障都需要他去处理，所以这么厉害的人，每天都从事的是救火工作。这个角色就变成了我们运维规范化过程中的一个瓶颈点。只要他的工作无法被其他人员替代，就无法让他去做运维团队更重要的事，比如自动化的建设，比如重要的监控建设。小说里为了解决这个问题，比尔设置了故障处理分级机制，把杜伦特保护起来，不允许开发人员直接与杜伦特沟通，同时安排其他工程师接触杜伦特原来的工作，让杜伦特的工作重心在自动化建设与监控建设上。这样在关键位置上增加了技术储备的同时，也将核心技术人员用在了最重要的位置上。
小说的名称叫《凤凰项目》，所以故事核心是围绕着凤凰项目来的，凤凰项目是一个计划了三年，经过了三年的憋大招勉强上线的一个项目，当然，准备了这么久的项目最后以失败告终，这个问题告诉我们什么呢。主人公在工厂车间意识到，如果工厂的人力是固定的，如果半成品积累的过多，就会导致最终成品交付给用户会变慢，这也就是我们在软件开发领域常说的在制品数量影响着交付的速度，如果开发团队同时迭代着过多的需求，那么必然需求交付到用户的手中的时间要延长。所以限制在制品数量是DevOps建设的一个核心内容，我们应该多做从0-1的事，而减少0.5的数量。书中总结的很好，一旦研发资本以半成品的形式锁定超过一年而未向公司返还现金，他就几乎不可能再为公司产生回报。
小说的最后作者总结了三步工作法，包含：
1)流动原则
流动原则是DevOps建设的基础，缩短满足客户需求的潜质时间，建立自动化工具链，减少人工干预过程，减小在制品数量，快速迭代，便可以有效地提高工作质量和产量。
2)反馈原则
在源头发现问题，尽早发现问题，测试及安全左移，在生产的源头就要保证质量。
3)持续学习与实验原则
把生产效率、工作流程上升到领导层，推进DevOps文化的落地。
总结：还等什么，买书去看吧，《凤凰项目》。
?更多精彩内容可以专注我们的在线课堂
微信搜索公众号：jfrogchina 获取课程通知
标签：天都 命令 监控 系统 基础 基础设施 包括 工具 情况
原文地址：https://blog.51cto.com/jfrogchina/2480154
