DevOps 面面观(续篇)

02-07 11:43


为什么要说“又”?

两年前的这个时候,读了“凤凰项目”一书,写了一篇“DevOps面面观”,没有做推广,阅读量出乎意料的好。

两年前,读到的是DevOps,是持续交付流水线,是运维自动化。

两年后,读到的是精益/TOC,是云,是价值交付流水线。

过两年如果再读,读到的也许会是教练,如何成为艾瑞克那样的尤达大师。

两年间,业界发生了可以说是翻天覆地的变化,云计算在当时看起来还是个趋势,至少在国内的落地还没有能看的那么清晰,那么成为绝对的趋势,还在讲公有云的安全,还在讲混合云的必要性。

两年前,对广罗大众而言,Docker刚刚兴起,K8s还未见踪影,微服务还在谈概念的阶段。

两年后,Docker、K8s、微服务已经成了DevOps三剑客,国内各家已经基于Docker搭建起CI/CD流水线,DevOps已经是热词,DevOps相关的形形色色的大会不下20场,连架构师峰会也要安排DevOps专场。

两年后,“凤凰项目”已经变成了沙盘游戏,而DevOps Master的认证也如火如荼。

两年前,我谈的是Dev2Ops,End2End。

两年后,我想说的是精益以及三步工作法。

DevOps起源于“一天十次部署”,以提高部署频度为抓手,(如果能成功生存下来)最终达到提升生产环境的可靠性、稳定性、灵敏性和安全性。

书中提到的“三步工作法”,与高德拉特的“目标”一书提到的约束理论TOC五个步骤,异曲同工,“凤凰项目”一书原本就是对“目标”的致敬,而我也才知道“目标”居然是MBA的课程之一,不懂精益的CEO不是好的CIO。

DevOps最终还是要服务与业务的,以最少的资源提供更多的业务价值交付,既保持竞争力,又控制成本,多快好省不是梦想。

DevOps根本上是一条价值流交付管道,一切脱离业务去谈IT效率都是耍流氓。IT的工作是“确保形成一条迅速、可预测、持续不断的计划内工作流,从而向业务部门交付工作价值,同时尽可能降低计划外工作的影响和破坏,提供稳定的、可预测的、安全的IT服务。”

”凤凰项目“,包括Gene Kim、Jez Humble等人的新书“DevOps Handbook”,重点是三步工作法。你关注什么就看到什么,再次阅读时看到的就是三步工作法中的精益思想。

第一步

建立从开发到IT运维再到客户的整个自左向右的工作流。 帮助理解在工作从开发移向IT运维时该如何建立 快速工作流。 为了使流量最大化,需要小的批量规模和工作间隔,绝不让缺陷流向下游工作重心,并且不断为了整体目标(相对于开发功能完成度、测试发现/修复比率或运维有效性等局部目标)进行优化。

必要的做法:看板可视化、持续构建、持续集成、持续测试、持续部署,代码分支整合,按需创建环境,严控半成品,以及构建起能够顺利变更的安全系统和组织。不断降低周期时间,持续不断的降低批量规模,目标是单品流。

可视化价值流图,关键是描述现状,把日常做的事原原本本的写下来,暴露发现问题从而解决问题,而不是相互指责。

可视化一切: 可视化工作流,可视化任务,可视化等待时间,可视化依赖,可视化运维监控。

瓶颈,约束点

保护约束点, 根据瓶颈资源所能完成工作的速度来安排工作,在瓶颈之外的任何地方做出的改进都是假象,在瓶颈之前做出的任何改进都是徒劳的,因为只能干等着瓶颈把工作传送过来;在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。

想想道路交通,堵点后面的道路通常是一马平川,而堵点前面都是要截流的,有交警敢敞开了放行么?

约束理论TOC

第一是确认约束点,这是大前提,如果约束点认错了,你懂得,”在瓶颈之外的任何地方做出的改进都是假象“;

第二是利用约束点,高效的利用约束点;利用约束点,并不意味着单纯的提高约束点的资源利用率,资源利用率是局部的优化,局部的思维方式,而精益/TOC,需要的是全局思维,更看重的是系统整体的吞吐率,即流动效率。“ 在产品开发中,我们的问题几乎从来不是停滞的资源(或不动的工程师),而是停滞的产品需求(用户价值)”,让价值流动起来。

第三是把约束点置于次要位置,Drum-Buffer-Rope,鼓点-缓冲-绳子,从高德拉特的TOC到大卫安德森的看板,同样一脉相传。

构建为运营而设计的系统,把非功能性需求考虑在内,包括要考虑易部署、安全性,并且可测试、可验证、会反馈。

关于”已完成工作“的定义Define of Done,同样的,需要考虑端到端,不只是编码完成、各类测试通过,同样要包括部署、运维完成,正常运行。此外,产生预期的业务价值或是业务反馈,也应该在DOD内。事实上,从一个DOD入手,就能深挖出DevOps的思想精髓。

第二步

建立价值流各阶段自右向左的快速持续反馈流,放大其效益以确保防治问题再次发生,或者更快的发现和修复问题。 缩短以及放大 反馈环路 ,从而在源头解决质量问题。 这样我们就能在所需支出获取或潜入知识,从源头上保证质量。

必要的做法:在部署管道中的构建和测试失败时“停止生产线”;日复一日的持续改进日常工作;创建快速的自动化测试套装软件,以确保代码总是处于可部署的状态;在开发和IT运维之间建立共同的目标和共同解决问题的机制;建立普遍的产品遥测技术,让每个人都知道,代码和环境是否在按照设定运行,以及是否达到了客户的目标;A/B Testing,蓝绿部署,滚动升级。

不做什么比做什么更重要,Say No,无论是对人或事。系统中最大的浪费恰恰是开发了没人使用的功能。 越快把功能推向市场接受考验,就越能获取反馈,消除不必要的浪费。

精益要求对用户的响应速度要快,用户的需求从进去到出来的时间要短,绝对速度要高,要有明确的衡量指标。同时,更要拼相对速度,相对于市场,相对于竞争对手。

精益的核心在于消除浪费,交付价值。如何消除浪费,很关键的就是需要从反馈中汲取经验,锻炼浪费以后能够快速识别出浪费的能力,同“反脆弱”一样的“反浪费”,不是不浪费,而是能从浪费中获益的能力。

关于“停止生产线”,借鉴精益生产中的Andon Cord 按灯拉绳系统,一旦发现质量问题,每个人都可以拉绳,也应该拉绳。按灯拉绳,不只是一个系统而已,背后是员工的责任感,主人翁精神,客户至尚的理念,以及安全感(知道任何拉绳造成的损失都不会被追究,反而被鼓励拉绳)。按灯拉绳不只是对外部客户,也同样适用于合作伙伴,以及内部团队之间,我们在亚马逊的领导力准则中也可以看到同样的思想。

第三步

创造公司文化,带动两种风气的形成:不断创世,这需要承担风险并从成功和失败中吸取经验教训;理解重复和练习是熟练掌握的前提。

建立 文化 ,技能鼓励探索,从失败中吸取教训,又能理解反复的时间是精通工作的先决条件。

必要的做法:营造一种勇于创新、敢于保险以及高信任度的文化,把至少20%的开发和IT运维周期规划给非功能性需求,并不断鼓励进行改进。

改进日常工作比开展日常工作更重要。不断给系统施加压力,从而不断强化习惯并加以改进。系统里要经常出些故障,长此以往,再遇到困难就没有原来那么痛苦了。

“计划外工作”

第一,知道计划外工作从哪里来,从而在下一次做好计划;第二,如何看待计划外工作,排斥、恐惧还是坦然或者欣然接受。

计划外工作来临时,可以有两种表现:一种是在计划外工作的冲击下崩溃,就像小说中前2/3部分描述的;一种是经常的演练,从失败中吸取教训,优化改进,从而把计划外工作变成日常的训练过程,痛苦的事情一定要多做。

无论是加压测试也好,Chaos Monkey混世猴子也好,都与”反脆弱“理论不谋而合,从失败中获益。

把反脆弱融入到IT的日常中,把原本最让人头痛的部署日常化、平常话,每天10次部署,是2009年最先进的理念,到两年前亚马逊已经可以做到一天23000次。把每次出现问题当成学习改进的机会,像圣斗士一样,做不死的小强,不被同一个招式打倒两次。

把IT融入公司的日常运行中,融入到公司的业务内容中,最终做到大家意识不到IT的存在,IT无所不在又没有一个具体的IT部门,也许才是真正的境界。就像亚马逊贝佐斯一直强调的,真正好的客户服务,是没有(不需要)客户服务。

思考:

你的工作是什么?你所提供的价值是什么?对你而言,什么是美好的一天,什么是糟糕的一天?你的远期目标、近期目标以及评估指标是什么?这些指标与谁以及哪些部门有关,风险有哪些?

同样的,拿着这些问题去问问你身边的人,问问和你工作相关相互协作的部门接口人,问问你做什么能帮到他/她。

参考资料

《凤凰项目:一个IT运维的传奇故事》 by Gene Kim

《目标》 by 高德拉特

《精益产品开发》 by 何勉

DevOps面面观   by 姚冬

原文链接:https://mp.weixin.qq.com/s/BRwzYRvka_u0vijS5j3asA?utm_source=tuicool&utm_medium=referral
标签: DevOps 运维技术
© 2014 TuiCode, Inc.