乐趣区

关于devops:DevOps面面观-IDCF

源于读了《凤凰我的项目: 一个 IT 运维的传奇故事》一书(感激徐磊同学的举荐),这本小说体零打碎敲的书,浏览感触十分好,提笔想做读书笔记却有些犯难,小说貌似只有写读后感的;恰好随后给共事做过两次 DevOps 的介绍,伺机整顿了一下思路,将本人对 DevOps 方方面面的了解,最终出现为这篇文档,作为阶段性的总结。

什么是 DevOps?

  • DevOps 不只是开发与运维的问题
  • 从大处着眼
  • 从小处下手
  • 通过加大部署 / 公布频度来撬动整个交付过程
  • 自动化、标准化、配置化
  • DevOps 实际
  • DevOps 与云
  • DevOps 与精益、麻利
  • 三步工作法

一、以下问题有没有解?

  • “疾速将产品推向市场”与“提供稳固、平安并牢靠的 IT 服务”是否能够兼得?
  • 用更少的资源实现更多的业绩,既要放弃竞争力,又要削减老本;
  • 如何解决工作交接呈现的问题,例如业务与开发,开发与运维之间;
  • 运维人员是否和其他人一样,失常上下班,而不必在夜里或者周末加班?

二、什么是 DevOps?七嘴八舌

WikiPedia 上说:”DevOps 是软件开发、运维和质量保证三个部门之间的沟通、合作和集成所采纳的流程、办法和体系的一个汇合。它是人们为了及时生产软件产品或服务,以满足某个业务指标,对开发与运维之间相互依存关系的一种新的了解。“

百度百科说:“DevOps(英文 Development 和 Operations 的组合)是一组过程、办法与零碎的统称,用于促成开发(应用程序 / 软件工程)、技术经营 和品质保障(QA)部门之间的沟通、合作与整合。它的呈现是因为软件行业日益清晰地意识到:为了按时交付软件产品和服务,开发和经营工作必须严密单干。”

IBM 这样说:DevOps 是企业必备的继续交付能力,通过软件驱动的翻新,保障组织抓住市场机会,同时缩小反馈到客户的工夫。

三、DevOps 不只是开发与运维的问题

一般而言,开发与运维有着不同的文化;开发部门的驱动力通常是“频繁交付新个性”,而运维部门则更关注 IT 服务的可靠性和 IT 老本投入的效率,升高危险。两者指标的不匹配,在开发与运维部门之间造成了鸿沟,从而减慢了 IT 交付业务价值的速度。运维从维稳登程,天然心愿生产零碎部署上线次数越少越好,而上线频度升高,对开发人员是一个负激励:反正我公布的版本也不会上线,反正我再踊跃也不能实时的体现进去,团队积极性和人员士气都会受到打击。

与此同时,业务部门则心愿业务需要尽快的推向市场,而维稳的要求导致价值交付用户的速度被延缓,价值无奈迅速失去反馈验证。

当公布列车变成 3 个月一趟车次时,业务人员习惯于本人的需要无奈疾速失去满足,能想出的的办法就是把所有的业务需要都设置成最高优先级,去抢占公布窗口。所有人都这样想这样做,拥挤就此产生,真正高价值的需要无奈失去疾速交付。(试想,如果每天有十次公布,大家还会拼得头破血流去抢一个公布窗口么?)

上线频度低的另一个副作用是,单次上线中蕴含的变更规模变大,危险也随之减少。事实上,缩小上线次数不仅不会升高危险,反而让每一次上线都变得像一个火药桶,危机四伏。

四、从大处着眼

究其基本,DevOps 目标是晋升业务交付能力:如何疾速的交付想法;如何让客户进行尝试(从而获取反馈);如何疾速响应客户反馈;

DevOps 不应该只是 IT 外部的几个部门玩的游戏。必须跳出 IT 的角度,端到端(业务端到客户端)剖析,能力弄清公司须要依附 IT 的哪些工作来撑持业务指标,撑持企业策略,从而实现更残缺、真正的 DevOps。

须要将 IT 变成一种能力,融入公司的日常运作中,融入业务流动中。在快鱼吃慢鱼的时代,须要疾速试错,一直整合来自市场的反馈。

所以最终,DevOps 是一个端到端的问题,是产品管理部、开发部、测试部、IT 运维部、信息安全部协同工作,独特反对。

DevOps 尝试建设一个业务价值交付管道,业务布局、需要梳理、打算、开发、构建、测试、部署、运维、监控,在此交付过程中波及到的部门 / 团队、过程、零碎、办法都归属于 DevOps 关怀的内容。

五、从小处下手

了解了 DevOps 是一个端到端的过程,整个交付链条波及太多的畛域,问题也层出不穷,无从下嘴。实际操作中,须要有一个切入点。

DevOps 的思维以精益与麻利为外围,通过裸露问题,解决问题,从而实现继续改良。从精益的角度看,在代码投产之前,实际上未产生任何价值,都只是半成品。要限度半成品,即在制品(WIP)数量,让其尽快流过生产线,让投入产生交付价值。

DevOps 是一个简单问题,咱们却心愿能够把一个简单的问题简单化:正如装修时通过加压查看管道是否泄露,是否有阻塞;咱们也通过加压的形式来裸露软件交付管道的问题。

如何加压?以终为始,咱们抉择业务价值交付的那个点,也就是部署与公布来对整个交付管道进行加压。

能够简略的问本人一个问题:“能不能一天部署 10 次?”如果没有方法?那么起因何在?流程不标准?自动化不够?沟通导致效率低下?过程无奈复用?环境差别导致回归出错?逐个的裸露问题,解决问题,交付能力天然晋升。

须要留神的是,依据《凤凰我的项目》中提到的 TOC 束缚实践(Theory of Constraints),在瓶颈之外的任何中央做出的改良都是假象,在瓶颈之后做的任何改良都是徒劳的,因为只能干等着瓶颈把工作传送过去,而在瓶颈之前做的任何改良则只会导致瓶颈处沉积更多的库存。所以如何辨认真正的瓶颈变得尤为重要,在发现问题之后多问几个为什么,力求找到本源起因。

DevOps 的由来

Flickr 公司的约翰. 阿尔斯帕瓦和保罗. 哈蒙德在 2009 年 Velocity 技术大会对于开发速率的一场演讲,“一天十次部署”,是 2009 年前后衰亡的 DevOps 静止的一部分,提倡开发和 IT 运维通力协作,在实现高频率部署的同时,进步生产环境的可靠性、稳定性、灵敏性和安全性。2009 年一天十次部署就算很快了,但当初只能算平均水平,2012 年亚马逊公司发表,他们均匀每天能发展 23000 个部署。

Wikipedia 上说,有以下几方面因素可能促使一个组织引入 DevOps:

  • 应用麻利或其余软件开发过程与办法
  • 业务负责人要求放慢产品交付的速率(新兴技术趋势,例如云计算、挪动利用、大数据和社交媒体)
  • 虚拟化和云计算基础设施(可能来自外部或内部供应商)日益广泛
  • 数据中心自动化技术和配置管 理工具的遍及
  • 传统的治理形式导致“烟囱式自动化”,从而造成开发与运维之间的鸿沟

六、通过加大部署 / 公布频度来撬动整个交付过程

以利用部署自动化作为切入点,由部署自动化,往前倒逼测试自动化、构建自动化;进一步往前,配置管理、变更治理是根底要求;再往前,业务需要与麻利打算同步关联,通过短周期迭代交付与反馈,增强业务与开发的合作沟通;

同样的,往后端与运维连接,更小、更频繁的变更,须要让开发人员更多地管制生产环境,更多地以应用程序为核心来了解基础设施;须要定义简洁明了的流程,尽可能地自动化;从而在实现高频率部署的同时,进步生产环境的可适应性,与此同时,可靠性、稳定性、弹性和安全性也同时晋升;

由此也促成了开发与运维的合作,通过一直缩减批量规模,实现疾速工作流,确保了部署环境时刻准备就绪,按需投产。频繁的公布、意味着每次公布蕴含的变动更少,每次部署不会对生产零碎造成微小影响,应用程序会以平滑的速率逐步成长。逐渐协调和弥合开发与运维之间的技能鸿沟和沟通鸿沟。

七、DevOps 要实现:自动化、标准化、配置化

  • 自动化:全面自动化,构建、部署、测试、降级、扩大、保护、数据卫生、监测、平安和策略管理。通过自动化,倒逼团队高效沟通,倒逼流程标准;自动化伎俩确保部署工作的可重复性、缩小部署出错的可能性。
  • 标准化:(流程,环境,配置)根底环境标准化,运行环境标准化,应用环境标准化 / 多样化;
  • 配置化:通过配置,尽量避免代码,通过性能开关或者参数设置,来反对 A /B testing、灰度公布;

八、DevOps 实际

  • 不做什么比做什么更重要:相比起向零碎中投入更多的工作,将无用的工作剔出零碎更为重要;无用的工作,无用的我的项目,无用的产品;排优先级,哪些是重要的工作;
  • 运维参加研发评审:常见的景象是,运维人员很少被邀请参加架构决策或代码评审,开发代码是否会影响运维环境后期无人知晓,须要让运维人员参加架构评审,从运维角度提出对系统的要求;
  • 非功能性需要同样重要:偿还技术上的债权。每个人都像器重功能性要求一样器重非功能性要求 QoS(品质,稳定性,可维护性,持续性,可扩展性,可管理性,安全性,可操作性),非功能性需要对于实现业务指标等同重要。要把非功能性需要设计到产品当中。
  • 整体合作:产品所有者,开发部,QA,IT 运维部以及信息安全部通力协作,帮忙彼此乃至整个企业取得胜利。
  • 品质为先:上游团队不再给上游团队造成麻烦,开发部将 20% 的工夫用于帮忙确保工作顺利的通过整个价值流,放慢自动化测试,改良部署基础架构,并确保所有应用程序建设有用的产品遥测;
  • 基础架构即代码(Infrastructure as a Code):把创立和部署流程自动化,把基础架构当成代码一样看待;各套环境之间,代码版本、运行时、环境配置须要匹配;须要将根底环境配置化、版本化治理;
  • 运维服务化:DevOps 会让开发部门承当更多的代码部署和维持服务水平的责任。要求把许多 IT 运维工作转变为自助服务。
  • 版本化所有(Versionlize Everything):应该把所有货色都进行版本控制,不只是代码,而是创立环境所需的每一样货色。
  • ITIL:为了适应 DevOps 更短的交付周期和更高的部署频率,ITIL 流程的很多方面都须要自动化,特地是变更、配置和公布流程等。
  • 云计算:无效的利用云技术,能够为开发和测试人员动静设置基础架构资源,疾速取得测试环境;
  • 针对类生产零碎进行开发和测试(环境的标准化),利用可反复的牢靠流程进行部署,监控并验证运维品质;
  • 放大反馈回路:疾速反馈回路,避免问题代码进入生产环节,并且让代码可能迅速部署投产,从而迅速发现并修复任何产品问题。(编写代码时,单元测试、集成测试、验收测试始终在类生产环境运行,一直确认,代码和环境奖会依照事后设定的运行,并且总是处于可部署状态)

九、DevOps 与云

DevOps 要反对云,虚拟化与云技术能够带来 DevOps 要求的标准化以及自动化;

环境标准化,无论是基础设施还是运行时环境,并把这些环境投入开发、QA 和 IT 运维的日常应用,就能打消大部分在部署流程中因为差别而导致的问题。不仅应该拿出可部署的代码,还应该领有部署这些代码的确切环境,并在版本控制中一并管制与查看。

混合云下的 DevOps 诉求:在云的场景下,如何利用虚拟化、容器等减速环境的创立以及标准化,如何通过自动化的形式放慢环境搭建;如何在 On-Prem、公有云、私有云,不同厂商不同类型的云的混合模式下,对立流程,对立 DevOps 的用户感触;

同时,由应用层的自动化部署,同样能够发现 Infrastructure 层, Runtime 层的问题,虚拟化与云的技术也与 DevOps 相辅相成,井水不犯河水。

十、DevOps 与精益、麻利

DevOps 是基于麻利与精益准则的办法。DevOps 是软件开发生命周期(SDLC)从瀑布式到麻利再到精益的倒退。

DevOps 超过了麻利,它的关注点是从 SDLC 中移除节约。通常状况下,发现节约或者瓶颈的模式包含:不统一的环境,人工的构建和部署流程,差的品质,IT 部门之间短少沟通和了解,频繁的中断和期待,局部实现的工作,额定的性能,工作切换等。

DevOps 强调流水线,交付管道,与传统生产与制造业有着千头万绪的分割;而《凤凰我的项目》一书中间接用生产工厂来点化故事的主人公,与 IT 开发运维间接类比;

DevOps 施行中,能够借鉴精益实践中的很多思维,例如:升高批量规模、缩小半成品、缩短并加强反馈回路、价值流图剖析、工夫线剖析、打消节约,以及麻利中继续集成、继续测试、继续交付、继续监控、A/ B 测试、灰度公布、滚动更新等。

十一、三步工作法

《凤凰我的项目: 一个 IT 运维的传奇故事》中倡议的三步工作法以实现 DevOps:

  • 第一工作法:(帮忙了解在工作从开发移向 IT 运维时该如何建设疾速工作流)从开发到 IT 运维再到客户的整个自左向右的工作流。为了使流量最大化,须要小的批量规模和工作距离,绝不让缺点流向上游工作重心,并且一直为了整体指标(绝对于开发性能完成度、测试发现 / 修复比率或运维有效性等部分指标)进行优化。必要的做法:看板、继续构建、集成以及部署,按需创立环境,严控半成品,以及构建起可能顺利变更的平安零碎和组织。
  • 第二工作法:(如何缩短以及放大反馈环路,从而在源头解决品质问题)价值流各阶段自右向左的疾速继续反馈流,放大其效益以确保防治问题再次发生,或者更快的发现和修复问题。这样咱们就能在所需收入获取或潜入常识,从源头上保证质量。必要的做法:在部署管道中的构建和测试失败时“进行生产线”;日复一日的继续改良日常工作;创立疾速的自动化测试套装软件,以确保代码总是处于可部署的状态;在开发和 IT 运维之间建设独特的指标和独特解决问题的机制;建设广泛的产品遥测技术,让每个人都晓得,代码和环境是否在依照设定运行,以及是否达到了客户的指标。
  • 第三工作法:(如何建设文化,技能激励碳酸,从失败中吸取教训,又能了解重复的工夫是精通工作的先决条件)发明公司文化,带动两种风尚的造成:一直创世,这须要承担风险并从胜利和失败中吸取经验教训;了解反复和练习是熟练掌握的前提。一直加压,从而强化习惯并加以改进。(零碎里要常常出些故障,长此以往,再遇到困难就没原来那么苦楚了)必要的做法:营造一种勇于创新、敢于保险以及高信任度的文化,把至多 20% 的开发和 IT 运维周期布局给非功能性需要,并一直激励进行改良。

十二、KPI 与度量

为了促成 DevOps 策略,调整绩效考核和激励机制是必要的,本来按各自为政的 KPI 考核只会造成部门之间的隔膜,仍然只依据敲出代码的生产力来处分开发人员,或者依据基础设施的可靠性来处分运维人员,什么都无奈扭转;围绕业务零碎而不是职责来组织工作,这就是 DevOps 突破 IT 分组壁垒的寓意。团队一起合作,独特为他们的利用和零碎负责。

局部度量参考:

  • 开发利用所破费的最高工夫(开发速率)
  • 失败部署的百分比(部署成功率)
  • 客户产生了多少问题(客户接受度)
  • 故障复原的均匀工夫(团队解决故障的能力)
  • 用户数(用户欢送度)

作者:IDCF 社区冬哥

IDCF 社区共创读书会 首期汇报,每周四晚 8 点, 冬哥有话说 收费直播,关注公众号回复“共读”获取直播地址

  • 8 月 19 日,共读《思考,快与慢》
  • 8 月 26 日,共读《DevOps 实际指南》
  • 9 月 2 日,共读《麻利无敌之 DevOps 时代》
退出移动版