精华内容
下载资源
问答
  • DevOps

    2021-01-09 23:00:34
    什么是DevOps 前言 字面意思上说 DevOps 是指“开发运维一体化”,即通过工具辅助开发完成运维的部分工作,减少成本。但深入理解了 DevOps 之后,你会发现 DevOps 其实是一种软件研发管理的思想,方法论,他追求...
    
    什么是DevOps
    
    

    前言

    字面意思上说 DevOps 是指“开发运维一体化”,即通过工具辅助开发完成运维的部分工作,减少成本。但深入理解了 DevOps 之后,你会发现 DevOps 其实是一种软件研发管理的思想,方法论,他追求的是一种没有隔阂的理想的研发协作的状态,可能涉及到的角色有开发、测试、产品、项目管理、运维等等。所以我们认为,为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 DevOps 的范畴。

    比如 Google 提出的 5 个 DevOps 原则,这套原则中必须依赖于工具辅助的部分只有后两点,更多的则是对于开发组织形式的内省:

    精简组织架构;
    愿意承担一部分试错带来的损失;
    分阶段地一小步一小步地进行转型;
    最大化地利用工具和自动化流程;
    对所有的过程和结果进行记录和分析。
    所以 DevOps 不是简单的开发软件化,而是企业的学习能力不断提升的结果,将企业改造成敏捷应对的学习型组织,运用新的工具,优化组织架构和流程,不断地进行自我革命和创新的方式。工具是辅助,而非基础。


    一、困难重重的 DevOps 落地?

    在弄清楚了 DevOps 的宏观定义之后,我们再来观察一下 DevOps 目前在国内的实践现状。根据南京大学 «DevOps 中国•2018 年度调研» 的调研报告,目前设有 DevOps 实践团队的公司中,科技和互联网行业占比接近 70%。其他行业的从业者对 DevOps 的认知还存在一定的不足。

    这与我们的调研走访体验一致:大多数企业都愿意尝试运用 DevOps ,但是在实践 DevOps 中,普遍碰到了比较大的困难。主要是以下三个原因:

    1.对 DevOps 有不切实际的预期

    部分团队为了做 DevOps 而做 DevOps,并没有真正的从业务的角度出发来考虑。

    如前文所说,DevOps 不是银弹,高水平的研发团队在 DevOps 实践中将快速找到研发质量与业务增长的平衡点。但对于许多仍然在使用中心化的研发组织形式的团队来说,DevOps 的尝试无法立即获得肉眼可见的增长数据,思索与尝试带来的对团队的训练可能会是第一份收获。

    2.步子迈得太大

    新生代互联网公司诞生于 DevOps 理念已经相对成熟的年代,且互联网公司天生地将迭代速度作为追求目标之一,使得这些公司能够在发展的初期,就将 DevOps 的理念融入到公司的架构设计中。
    在这里插入图片描述
    上图是 Netflix 的整个系统架构。如此复杂的系统架构同时还能每天迭代几十个版本,无法通过传统的研发管理模式来维护,只有通过实践 DevOps 的理念,来优化组织的分工、资源和能效,才能得以实现。在这样的组织里,已经不需要有人了解所有模块是做什么,每个人只需要对自己的模块负责。

    而很多企业,为了巩固和提高自己的市场竞争力,非常急于达成上述高效的状态,并且希望能一步到位。国内其实大部分团队都没到大规模实践 DevOps 的时间点,有些团队甚至连分支开发、并行开发的方式都没有。我给这类的企业建议是:不要想着一口气吃成个胖子,一步一步来,先理解 DevOps 的理念和对业务的实际意义,然后搭建一只小的 DevOps 团队来承接一项新业务,旧的业务仍然使用旧系统,双轨并行,等待小团队适应了 DevOps 的管理节奏之后再向其他团队进行推广。

    在这里插入图片描述
    之前出过一篇关于 DevOps 的专题报告《四周年 · 专题报告:双速 IT》,也可以作为参考。

    3.工具链危机

    实践 DevOps 的原则中很重要的一点就是对工具的运用及依赖工具搭建合适企业的自动化流程。但是目前市面上缺乏成熟的 DevOps 工具链,各个服务商的细分工具层出不穷,企业为了搭建整套 DevOps 流程,需要研究几十种工具,并选取其中的 7-8 种进行落地实践。非常依赖于管理者的项目经验,没有 DevOps 经验的团队起步将会比较困难。

    以 CODING 为例。2018 年之前 CODING 产品仅有任务及代码管理模块。我们是这样进行工作的:产品经理在 CODING 上撰写文档创建任务,研发 Leader 将任务分配给开发,开发完成后提交代码,并创建 MR,我们在本地部署了 Jenkins 进行持续集成进行构建和测试,再由其他工程师进行人工评审,通过后并到发布分支,进行预发布,再通过持续集成进行构建,自建 Docker registry 进行构建物管理。构建出的 Docker 镜像在测试环境和预发布环境上依次进行自动化测试及人工测试,测试通过后,使用我们运维自己搭建的工具进行部署管理。

    目前 CODING 每天都进行产品迭代,可以快速响应用户需求并保证服务质量,但搭建这一整套的流程高度依赖于团队能力,门槛非常高。

    3.DevOps 是未来的趋势

    既然 DevOps 这么难,坑这么多,为什么还要做呢?因为这是企业未来的长期诉求。

    从大趋势上分析,未来所有企业都将是软件企业,制造软件、服务软件、构建于软件。比如全世界最大的出行公司 Uber,其实是一个软件公司,而非出租车公司。从企业自身诉求出发,中国的中大型企业已经逐步进入了创新驱动的阶段。无论是供给侧改革还是智能制造 2025 都要求企业修炼内功,提高效率促进创新。过去几年中在塑造前沿行业的 DevOps 理念将在 2019 年左右成为主流,成为企业能否在行业内脱颖而出的关键性因素。

    在 Statsia 2018 年的报告中,有超过 72% 的企业或多或少地开始践行 DevOps 的理念,其中完整采用 DevOps 的比例高达 17% ,而在 2017 年这个数字仅有 10%。
    在这里插入图片描述
    真正能够实践 DevOps 的团队也会为自身的业务带来巨大的提升。根据 Puppt 的2017 DevOps State Report,DevOps 型团队将部署频率提高46倍,交付速度提高 440 倍。

    可见,在国际上来说,DevOps 已经处于企业爆发性需求的前夜。而在国内公司中,新兴企业的成功实践也在为中国企业的 DevOps 输送方法论与有经验的专家。

    字节跳动可以说是 DevOps 最佳践行者之一。在其创始人张一鸣看来:

    公司的业务越复杂,人越多,组织就越大。这导致信息失效、(下属)向上管理和业务变大。他把类似组织的负规模效应称为“自嗨”,这是他所不能接受的。
    故而字节跳动在组织架构上,总共只有 3 个核心部门:技术、Growth 和商业化,分别负责研发、推广和收入。

    在这里插入图片描述
    今日头条、抖音、西瓜视频……字节跳动的每款 App 都基于这三个部门来发展。在项目开始时,公司会为每个项目设置虚拟项目组,由三个核心部门抽调人员组成,试水成功后直接推广。所有产品共用一条技术线,快速试错。针对 App 类产品的快速迭代的业务特性,字节跳动依据 DevOps 理念对组织架构进行调整和优化,从结构上保证了技术支持业务创新的能力。

    4.Why Now?

    DevOps 的理念和优势被说了很多年,但一直都只在少量公司有能力实践。 软件的工程化历史还比较短暂,业务需求与技术理念都日新月异,前两年大量的团队还在为了研发新的业务疲于奔命,没有精力关注研发效能升级的问题。许多团队的研发管理还停留在靠微信喊话和 Excel 管理的阶段。

    而如今,在市场遇冷和企业数字化转型的契机下,更多的公司开始将目光放在企业内部的效率提升和研发成本的控制上。

    在 Netflix、Google 这样发展比较久的的巨型公司可以耗费大量的内部资源从底层服务开始从零搭建 DevOps 流程。而像字节跳动这样的新型公司可以如此快速实现敏捷,也得益于云服务的逐步成熟。

    尤其是在当前环境下,运维业务逐步多样化和复杂化,很多传统的运维技术和解决方案已经不能满足当前运维所需,越来越多的团队选择使用 Docker kubernetes 等技术提升运维能力。同时,云厂商的 SaaS、IaaS 和 PaaS 服务相对于传统的运维业务帮助企业节省大量硬件维护的成本和时间,让企业能专注于业务的发展与创新。

    总结

    孙子兵法有云,凡兵法韬略,在道不在术。面对日新月异的的市场,企业必须逼迫自己不断的进行革新来应对市场变化。就像马化腾在互联网大会上提到的,现在互联网已经发展到了深水区,甚至是无人区。只有不断的迭代,迅速反应,才能应对未来的变化,而这也正是 DevOps 所强调的。

    展开全文
  • Devops

    2020-04-13 12:00:21
    https://www.jianshu.com/p/c5d002cf25b9 ----Devops软件研发的系统化流程 https://zhuanlan.zhihu.com/p/95309012 ----Devops工具介绍

    https://www.jianshu.com/p/c5d002cf25b9 ----Devops软件研发的系统化流程
    https://zhuanlan.zhihu.com/p/95309012 ----Devops工具介绍

    展开全文
  • devops

    2019-06-01 21:02:00
    DevOps 是一个完整的面向IT运维的工作流,以 IT 自动化以及持续集成(CI)、持续部署(CD)为基础,来优化程式开发、测试、系统运维等所有环节。 DevOps的概念 DevOps一词的来自于Development和Operations的...

     

    DevOps 是一个完整的面向IT运维的工作流,以 IT 自动化以及持续集成(CI)、持续部署(CD)为基础,来优化程式开发、测试、系统运维等所有环节。

     

     

    DevOps的概念

    DevOps一词的来自于Development和Operations的组合,突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

    DevOps是为了填补开发端和运维端之间的信息鸿沟,改善团队之间的协作关系。不过需要澄清的一点是,从开发到运维,中间还有测试环节。DevOps其实包含了三个部分:开发、测试和运维。

     

     换句话说,DevOps希望做到的是软件产品交付过程中IT工具链的打通,使得各个团队减少时间损耗,更加高效地协同工作。专家们总结出了下面这个DevOps能力图,良好的闭环可以大大增加整体的产出。

    历史变革

    由上所述,相信大家对DevOps有了一定的了解。但是除了触及工具链之外,作为文化和技术的方法论,DevOps还需要公司在组织文化上的变革。回顾软件行业的研发模式,可以发现大致有三个阶段:瀑布式开发、敏捷开发、DevOps。

    DevOps早在九年前就有人提出来,但是,为什么这两年才开始受到越来越多的企业重视和实践呢?因为DevOps的发展是独木不成林的,现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易,计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。

    好处是什么?

    DevOps的一个巨大好处就是可以高效交付,这也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告,根据全球4600位各IT公司的技术工作者的提交数据统计,得出高效公司平均每年可以完成1460次部署。

    与低效组织相比,高效组织的部署频繁200倍,产品投入使用速度快2555倍,服务恢复速度快24倍。在工作内容的时间分配上,低效者要多花22%的时间用在为规划好或者重复工作上,而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高,还指员工的工作质量得到提升。

    DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效,也更有满足和成就感;调查显示高效员工的雇员净推荐值(eNPS:employee Net Promoter Score)更高,即对公司更加认同。

    快速部署同时提高IT稳定性。这难道不矛盾吗?

    快速的部署其实可以帮助更快地发现问题,产品被更快地交付到用户手中,团队可以更快地得到用户的反馈,从而进行更快地响应。而且,DevOps小步快跑的形式带来的变化是比较小的,出现问题的偏差每次都不会太大,修复起来也会相对容易一些。

    因此,认为速度就意味着危险是一种偏见。此外,滞后软件服务的发布也并不一定会完全地避免问题,在竞争日益激烈的IT行业,这反而可能错失了软件的发布时机

    为什么DevOps会兴起?

    为什么会继续火下去?

    条件成熟:技术配套发展

    技术的发展使得DevOps有了更多的配合。早期时,大家虽然意识到了这个问题的,但是苦于当时没有完善丰富的技术工具,是一种“理想很丰满,但是现实很骨感”的情况。DevOps的实现可以基于新兴的容器技术;也可以在自动化运维工具Puppet、SaltStack、Ansible之后的延伸;还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。

    来自市场的外部需求:这世界变化太快

    IT行业已经越来越与市场的经济发展紧密挂钩,专家们认为IT将会有支持中心变成利润驱动中心。事实上,这个变化已经开始了,这不仅体现在Google、苹果这些大企业中,而且也发生在传统行业中,比如出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等等。能否让公司的IT配套方案及时跟上市场需求的步伐,在今天显得至关重要。

    DevOps 2016年度报告给出了一个运维成本的计算公式: 
    停机费用成本 = 部署频率 * 版本迭代失败概率 * 平均修复时间 * 断电的金钱损失

    来自团队的内在动力:工程师也需要

    对于工程师而言,他们也是DevOps的受益者。微软资深工程师Scott Hanselman说过“对于开发者而言,最有力的工具就是自动化工具”(The most powerful tool we have as developers is automation)。

    工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行;正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话:“谁开发谁运行”。(You build it, you run it)

    实现DevOps需要什么?

    硬性要求:工具上的准备

    上文提到了工具链的打通,那么工具自然就需要做好准备。现将工具类型及对应的不完全列举整理如下:

    • 代码管理(SCM):GitHub、GitLab、BitBucket、SubVersion

    • 构建工具:Ant、Gradle、maven

    • 自动部署:Capistrano、CodeDeploy

    • 持续集成(CI):Bamboo、Hudson、Jenkins

    • 配置管理:Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail

    • 容器:Docker、LXC、第三方厂商如AWS

    • 编排:Kubernetes、Core、Apache Mesos、DC/OS

    • 服务注册与发现:Zookeeper、etcd、Consul

    • 脚本语言:python、ruby、shell

    • 日志管理:ELK、Logentries

    • 系统监控:Datadog、Graphite、Icinga、Nagios

    • 性能监控:AppDynamics、New Relic、Splunk

    • 压力测试:JMeter、Blaze Meter、loader.io

    • 预警:PagerDuty、pingdom、厂商自带如AWS SNS

    • HTTP加速器:Varnish

    • 消息总线:ActiveMQ、SQS

    • 应用服务器:Tomcat、JBoss

    • Web服务器:Apache、Nginx、IIS

    • 数据库:MySQL、Oracle、PostgreSQL等关系型数据库;cassandra、mongoDB、redis等NoSQL数据库

    • 项目管理(PM):Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

    在工具的选择上,需要结合公司业务需求和技术团队情况而定。(注:更多关于工具的详细介绍可以参见此文:51 Best DevOps Tools for #DevOps Engineers)

    软性需求:文化和人

    DevOps成功与否,公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习,从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。

    出席了2016年伦敦企业级DevOps峰会的ITV公司在2012年就开始落地DevOps,其通用平台主管Clark在接受了InfoQ的采访,在谈及成功时表示,业务人员非常清楚他们希望在最小化可行产品中实现什么,工程师们就按需交付,不做多余工作。

    这样,工程师们使用通用的平台(即打通的工具链)得到更好的一致性和更高的质量。此外,DevOps对工程师个人的要求也提高了,很多专家也认为招募到优秀的人才也是一个挑战。

    DevOps的采用现状

    哪些公司在用?

    DevOps正在增长,尤其是在大企业中:调查发现,DevOps的接受度有了显著提高。74%的受访者已经接受了DevOps,而去年这一比例为66%。目前,在81%的大企业开始接受DevOps,中小企业的接受度仅为70%。

    那么具体而言都有些公司在采用DevOps呢?Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Target(泛欧实时全额自动清算系统)、Walmart、Sony等等。

    他们怎么实施的?

    首先,大企业正在自下而上接受DevOps,其中业务单位或部门(31%)以及项目和团队(29%)已经实施DevOps。不过,只有21%的大企业在整个公司范围内采用了DevOps。 

    其次,在工具层面上,DevOps工具的用量大幅激增。Chef和Puppet依然是最常用的DevOps工具,使用率均为32%。Docker是年增长率最快的工具,用量增长一倍以上。Ansible的用量也有显著增加,使用率从10%翻倍至20%。

     

    参考:https://www.cnblogs.com/liufei1983/p/7152013.html

    转载于:https://www.cnblogs.com/cuiqq/p/10960991.html

    展开全文
  • 【管理】DevOps的思考

    万次阅读 2020-03-04 11:23:53
    DevOps是最近非常火的一个概念,谈IT流程建设不说点DevOps都不好意思和人打招呼。但是DevOps究竟是个什么东西,这个东西能不能用?怎么用?什么样的情况才叫做DevOps落地成功?对于这些问题的答案,虽然网上有...

    DevOps是最近非常火的一个概念,谈IT流程建设不说点DevOps都不好意思和人打招呼。但是DevOps究竟是个什么东西,这个东西能不能用?怎么用?什么样的情况才叫做DevOps落地成功?对于这些问题的答案,虽然网上有铺天盖地的文章和教程,但是一般来说都是从理论或者方法论上去阐述,也有大厂的实施经历。个人就感觉这里的它山之石,很难攻玉了。最终还是得思考下DevOps的由来,综合自己所在企业的现实状况去考虑。

    在这篇文章中,本人无意对DevOps从理论或者方法论上做说明和讲解,只是想综合自己工作过程中的一些现实情况,在解决和优化一些现实情况的过程中,接触到了DevOps这样一个概念,想试着在DevOps这条路上找到一些解决问题的可行性和落地方式。本文是基于这个目的来做的一些总结,提到的概念和方法不一定和网上其他的教程/文章描述的一样,我只是想提出我的理解,希望各位看客轻拍,可以留言或者私信交流。

    一. DevOps作为一种软件开发手段和方法

    先引用下百度百科上对DevOps的描述:“DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。”我对这句话的理解,就是利用各种技术和管理手段来使整个软件工程更加的高效。为了更好的理解这样一个概念。就有必要去了解下在DevOps出现之前,有哪些软件工程流程,为什么在当前的情况下,需要有DevOps的出现,才能更好的理解这些技术或者管理手段的目的和意义。

    软件行业的江湖中一直流传着这样类型的传说,某位大神闭关若干月,凭借自己无上的神功,在车库/地下室等各种不同简陋的地点开发出牛逼的一塌糊涂的产品。行内的各位肯定对这样的传说并不陌生。但是我个人认为其中有夸大的成分,不可否认,某位大神可以凭借自己无上神功搭出产品的核心框架,但是最终成熟的商业产品肯定是需要一个稳定的团队,依靠可靠的流程手段来维持和推进,缺乏有效管理的产品会变成一个焦油坑(人月神话)。

    那么,这样一个可靠的流程手段就是我们通常讲到的软件工程:

    a. 最初的阶段,我们的软件产品只有有限的需求,业务对软件的依赖也不是那么的大,因此有相对较长的交付周期。对于这样的一个应用场景,就有了最初的瀑布模型:

    瀑布模型为了保证整个软件可控,从而保证软件产品质量,对每个阶段进行管控,只有前一个阶段的输出稳定和质量过关后,才能进入下一个阶段。

    这种模型在需求量相对简单和少的情况下,可以做到可控。但是随着社会的发展,各行各业对软件的依赖越来越大,各种复杂的业务都需要有软件的介入,复杂的业务场景,更短的开发周期,更频繁的业务场景变更,导致瀑布模型的开发模式无法保证有效和高质量的产品开发。因此我们需要有更好更适合的开发模型。

    b. 最简单的,我们采用分而治之的方法,将整个软件需求拆分成若干个子集,将整个过程拆分成若干个迭代,每个迭代挑选出若干子集采用瀑布模型的方式进行开发。称之为迭代模型。

    这样,可以保证在每个迭代开发周期中,形成一个可交付的产品子集,逐步增量的进行交付。

    理论上讲,通过控制迭代的需求范围,迭代开发可以适用大多数软件开发场景了。但是随着互联网和移动业务的崛起,对于软件的更新/构建速度提出了前所未有的要求。在迭代开发中,每个迭代还是走的需求设计/概要设计/详细设计/开发/测试/部署的流程。一旦一个迭代的范围和时间确定,为保证质量,原则上是不调整需求的。而一个迭代的流程下来,少说一个月两个月的。但是在移动互联网时代,为了快速响应用户需求来占领市场,需求是不断变化的,根本没有可能等待一个迭代结束之后再重新调整需求。因此,面向用户需求的软件开发理念就迅速在业界流行起来,也就是敏捷开发。

    c. 我们来看一下敏捷开发的定义,引用百度百科上的定义:

    敏捷软件开发(英语:Agile software development),又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法,是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用。

    我个人对这个定义的理解是敏捷开发是一套方法论,为了适应频繁变化的需求而产生的。而在软件开发流程上相对于上述的瀑布和传统迭代模型而言,最关键的变化就是从面向书面的文档转变为面向人员合作。在上述的流程中,强调的是每个阶段的可靠性,只有当每个阶段的输出完成后才进入下一个阶段(包括文档输出,文档也会作为一个重要的输出,成为下一阶段的输入)。而敏捷开发更强调的是人与人之间的合作和沟通,而不是依赖文档(当然,不是不需要文档,必要的文档记录是很重要和必要的工作)。为了保持足够有效的人员沟通,团队的规模就不可能很大。因此就只能是小而精的团队,通过有效的沟通快速将需求实现。从而小步快跑的进行快速迭代。

    上面是一个敏捷开发的一个方法论,不是一个具体的实现方法,一个比较著名的方法就是scrum。

    而在快速迭代的过程中,每个需求和阶段的重点是通过人员之间的合作来推动,而人总是没有机器和工具的可靠(也就是说,人总是会犯错),为了保证质量和流程的稳定,一系列的工具被开发出来,这些工具也成为了敏捷开发的一部分。

    因此,我理解的敏捷开发应该是一套实现了方法论的实践 + 工具集合。

    讲到这里,就想先引入下所在企业的现状,碰到的问题及问题的思考,在这层思考的基础上去考虑DevOps的可行性和落地方法。也就是说,本人是想将DevOps作为解决方案之一来做思考的。

    二. 企业软件开发流程现状

    本人所在企业的业务是ToB的业务,和移动互联网从需求层面来讲是有很大区别的。一般来说,ToB的业务都是面向某一个特定的行业,行业属性极强,比如医疗,工业等领域,作为IT界的专业人士完全无法了解到其中的专业知识,更有甚者连最基本的常识都没有。这点和大多面向ToC的移动互联网不一样,移动互联网的业务一般都是基于常识,比如基于个人消费的电商,音乐软件等,产品经理都可以基于常识+个人体验做到对用户的引导来提出需求。这点在本人看来,对于开发流程是至关重要的,因为不管是什么样的流程,都是源自于需求,而软件本身只是一个人类生活中实现各种业务需求的工具,偏离了需求,软件也就没有存在的价值。

    上面的一大段提到的问题会衍生出下面几个关键问题:

    • 我们团队在产品的需求上话语权太低。在碰到不同客户的不同需求上,对于客户的引导难度非常大。一个简单的例子就是,对于一个需求的优先级和重要性,无法有一个客观的判断,而对于客户而言,他提出的每一个需求对他而言都是重要和关键的,而我们的团队无法对其进行判别,更别说去对客户进行引导。
    • 企业是一个初创团队,没有足够的行业经验积累。产品是基于某几家合作单位客户需求搭建起来的,是否具有业务上的普适性有待考证。
    • 由于上述两个问题,就会造成在多个项目同时推进时,无法判断是否能由一个产品或者说时一套代码来交付
    • ToB的业务往往是需要强可靠性和非常低的错误容忍度。简单的一个说明就是,你在发朋友圈的时候,由于程序bug导致发送失败,而且导致输入没有保存,你除了发点牢骚,心想着换个app,再默默的重新输入一次之外没有别的想法,而tob的业务可能就会导致某条流水线失败,工业事故或者更有甚者就是影响到人的生命。

    因此,在实际的软件开发过程中,企业的开发模式应该是处于半敏捷开发的模式。整体来说还是需求->设计->开发->测试的模式。在产品开发初期及产品成型后的交付初期,需求相对确定,产品规模和业务复杂度较低,团队规模也不大。

    • 每个迭代的时长控制在一周到两周左右。
    • 需求文档往往就是一个截图和excel列表,在团队中通过会议进行同步和说明。
    • 测试往往提前介入,及时将开发输出的需求进行测试,在过程中完善测试用例(测试的用例文档的目的往往是为了留档,进行知识储备)。让每个迭代的构建和发布时间相对缩短。

    在半年到一年的交付之后,需求复杂度和代码耦合性越来越高。这个流程越来月陷入到焦油坑中:

    • 需求往往要经过多次讨论,需要集合越来越多上下游的开发测试人员参与讨论,讨论的时间往往就是半天到一天
    • 开发代码牵一发动全身,if-else堆积如山,圈复杂度急剧上升。
    • 测试很难保证测试质量,任何一个bug的修复都会导致意想不到的bug出现,根本无法提前介入测试,或者说提前介入测试基本没有起到应用的作用,在交付压力的情况下,测试会成为交付进度的牺牲品。
    • 为了保证交付质量,每个环节不得不加入大量的文档和评审,保证上下游对改动的理解和范围一致
    • 到了不重构就无法推进的境地,而进度和人员规模很难保证互不影响

    可以看到,敏捷开发模式逐步退回到迭代模型中。由人员合作为导向变成了由文档为导向,每个阶段的“墙”越来越厚。

    2. 堆积如山的环境

    一般来说,刚开始我们是规划了几套环境来保证日常的开发工作

    • 本地环境:很好理解,每个开发人员的办公环境,不管是物理机还是虚拟机。用于开发人员本地调试,保证需求代码开发完成。
    • 开发环境:开发人员维护,所有的代码提交之后,可以较为频繁和灵活的构建,作为代码的第一次整合。
    • 测试环境:每个迭代规划若干次构建,每次构建后不做改动,由测试团队在此发现问题。
    • 生产环境:测试确认无误后,将相应的改动部署,投入业务生产当中。

    当项目越来越多时,每个项目都需要配置相同的环境。还有一些专用的环境,比如性能测试环境,为了保证稳定和演练上线步骤出现的预发布环境等等。光是环境都有一大把。虽然在现在虚拟化和容器技术的支撑下,不需要机房里堆上一大堆的物理服务器,但是对于每台虚拟机的管理也是一个相当繁琐的工作。也是影响交付效率下降的一个重要原因。

    3. Dev VS Ops,难以调和的矛盾

    我们的团队中没有专门负责部署和运维的团队,一般由开发或者测试的人来兼任这部分工作。但是不阻碍我们可以把这两部分工作区分开来考虑。对于已经商用的项目,规划多少需求到一个迭代中去开发和交付,是对整个团队的选择题。是尽可能多的上新的需求还是降低风险尽量少的控制需求是每次都会纠结的问题。

    • 尽快的响应客户需求,将新开发的功能尽可能多的排入计划。上线失败的风险就会增加。
    • 为了稳定尽可能少的逐步上需求,会导致客户满意度下降。

    虽然没有两个团队之间的部门墙问题,同样还是存在Dev和Ops之间的矛盾。

    4. 解决方案之一 -- DevOps

    上面说了这么一些,总的说来就是研发和交付效率随着业务和代码的复杂度上升而显著下降,就需要有更好的流程和工具来解决这样的问题。自然而然的,团队就将注意力放到了大火的DevOps上。

    是否要用DevOps,不是因为别人用了,我们就要用。首先想了解下DevOps是什么,能解决什么问题,和现在的方式方法有什么区别,然后才能对症下药。

    在敏捷开发中,已经将整个软件开发流程中的 需求->开发->测试三个环节囊括在内,指导这三个阶段的相关团队提升效率。

    从上述的图中看到,在整个软件生命周期中的最后一个环节:部署没有被囊括进去,也就是你前面玩的再High,对于部署团队而言,输出件都是不被信任的(指输出质量,不带我玩,为啥要信你,你说啥就是啥?)。而DevOps就是想把最后这个环节也囊括到这个大循环中。

    最终的目的是想让在这个循环中的各个阶段团队都对整个产品和整个交付过程负责,而不是只对某个阶段负责。

    回到文章的最开头,DevOps的定义里提到用的是一系列的工程方法和工具来提高效率。也就是说,用工具使得这个循环能顺利的转起来,并且要自动化的运转起来,在保证质量的前提下再越转越快。

    三. DevOps的实践方式

    上面提到了当前的几个问题:

    • 业务/代码复杂度高,任何修改无法评估,失败风险大。逐步退化成靠文档去规范每个阶段
    • 环境多,需要大量的人力成本来维护
    • 需求开发速度和稳定性之间的矛盾

    那么就考虑下DevOps提供了哪些方法和工具来解决这些问题,从网上盗了一张图,是每个阶段的工具集合(侵删)

    看完了简直是一脑壳包,所以要梳理下。

    是否引入一个新的工具或者方法的时候,总要有一个判断标准,根据数字化的标准去判断是否由于当前的方法和工具。对于研发效率这个方向而言,有下面几个指标可以参考:

    • 部署频率:指应用和服务向生产环境部署代码的频率。
    • 变更前置时间:指代码从提交到成功运行在生产环境的时长。
    • 服务恢复时间:指线上应用和服务出现故障到恢复运行的时长。
    • 变更失败率:指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。

    或者说,我们就是要从这想办法提高这几个指标。

    或者从软件工程的角度理解,我们可以把往DevOps演进可以逐步分成下面几个阶段:

    1. 持续集成,代码统一管理,持续构建,开发持续输出到测试。
    2. 持续发布,持续测试,完成到产品发布的持续输出
    3. 持续部署/交付,完成产品到生产环境上的持续输出

    也就是说,我认为提高效率的过程中(不管是不是DevOps),都是可以针对性的去提高这几个指标,逐步的演进到下一个阶段。在这个过程中来针对性的选择工具。使用工具就是想让各个流程步骤自动化,避免对人的依赖。

    1. 开发自动化,主要从配置管理,代码托管(Git),代码评审(GitHub),代码静态检查(sonar),单元测试(JUnit),配合Jenkins工具来提高。

    2. 测试自动化,引入自动化测试

    3. 运维自动化,引入环境监控(Portainer),日志收集等工具

    具体的工具介绍就不写了,这个不是本篇文章的重点。策略就是发现瓶颈,解决瓶颈。发现人工部分,考虑工具来替代人工操作,不断循环往复的过程。

    实际上,这里必须摆脱“器”或者“术”的思路,而要采用“道”的思路:

    • 不仅仅限于某种工具,再通过工具去解决某些问题。而应该是反过来的,发现了什么问题,可以用什么样的方法去解决这个瓶颈问题,再去找相关的工具。
    • 解决问题不一定要采用某种流行的工具,不是他用了你就好用的,别人通过这个工具解决的问题,你不一定能通过这个工具解决问题,一定要从实际场景和应用出发。举个简单的例子,我们的一个产品想做日志收集,第一反应就是使用ELK + ES的方案。调研之后发现ELK的资源占用比我们产品本身的资源占用还大,ELK + ES的集群设置比产品本身的设置还困难。如果这样选型的话就是本末倒置了。而仔细分析之后我们仅仅是想将各个组件和服务之间产生的生产日志收集到一起而已,可能一个简单的SHELL脚本就可以收集了。
    • 在这样的一个思路的指导下,不是使用了DevOps这个链条上的工具就表示我们是一个DevOps实践的团队了,而是团队在不停的解决瓶颈,不断提高自动化效率之后,促进了研发效率,提高了人员合作效率,我就可以说团队已经走在DevOps的康庄大道了。

    四. DevOps是一种态度和文化

    绝大多数提到DevOps的文章都会提到,DevOps包含了两个部分,工具和文化。上面已经针对工具做了一个简单的思考总结。现在来谈谈文化。

    企业文化就是一群人的做事风格,或者说是在做选择题,做决策的一种指导思想。而DevOps就是想提供一种有效的选择和指导思想。

    1. 统一目标而不是分割目标,DevOps的目的是想让整个软件开发生命周期中的所有环节都对结果负责,这里的结果是整体、业务或者商业上的结果,而不是割裂成若干个小环节的局部结果。而术业有专攻,每个阶段肯定是由若干个专业团队负责的,在管理流程上很容易的将每个团队分开管理考核,很容易导致团队之间的对立。因此需要在管理流程上对这个目标进行合理的引导(制度上),而不是去阻碍这种态度的形成。
    2. 预防大于治疗,基于上面一点,负责每个阶段的团队都需要多走出一步,向前一步,向后一步。这样才能弥补每个环节之间的间隙。而不是等到上一个环节出了问题之后再去返回去修改,这时追责的意义实际上已经不大。因此必须整个团队达成一致,是要主动迈出一步,而不是事后追责。才能形成一个有效的循环。
    3. 拥抱变化,软件开发是一个变化巨大的行业,需求、技术、甚至是人员本身都在快速的变化中,因此持续改进是应对变化的最有效的办法。快速发现问题,再快速解决问题。在团队统一目标,每个环节伸出左右手拉住上下游,形成一个车轮迅速往前推进。
    4. 另外,我想说下我理解的全栈工程师,不是一个人通吃整个开发的生命周期,当然刚开始可能是需要有几个一专多能的牛人构建出产品的雏形。但是只有融合不同的专才的团队才能让整个开发生命周期更长久,更稳定。而全栈指的是在目标统一的前提下,利用全局的思路去指导每个环节的研发工作。
    5. 很多人讨论是文化先行还是工具先行的问题,本人认为这不是一个串行关系,工具是一个自底向上的过程,在持续改进中积累。而文化需要一个自顶向下的过程,在演进到某个阶段,需要取得企业管理层的一致后,在公司导向,制度制定等方面向下推广。两个方向同时发展,才能取得比较好的效果。

    最后,引用网络上的一句话,文化 = 人 + 流程 来做一个小小的总结。

    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 22,581
精华内容 9,032
关键字:

devops