高端网站建设 司法,wordpress 菜单 标题属性,做企业网站还有钱挣吗,网站开发存在的风险引言 随着业务的发展#xff0c;软件发布迭代的频率越来越高#xff0c;传统的瀑布型模式已经不能满足快速交付的需求#xff0c;DevOps 也因此受到持续关注。越来越多的公司开始接受并尝试使用 DevOps#xff0c;期望能使得软件开发中的构建、测试与发布工作变得更加快捷…引言 随着业务的发展软件发布迭代的频率越来越高传统的瀑布型模式已经不能满足快速交付的需求DevOps 也因此受到持续关注。越来越多的公司开始接受并尝试使用 DevOps期望能使得软件开发中的构建、测试与发布工作变得更加快捷、频繁和可靠。
DevOps 究竟是什么它想要解决的是什么问题为什么 DevOps 很好但却很难落地其中的阻力是什么DevOps 的采用现状如何那些成功的公司都做对了什么本期「TVP 技术夜未眠」邀请了前易宝技术中心负责人、腾讯云 TVP 刘斌老师与腾讯云 CODING DevOps 高级解决方案架构师——陈钧桐老师一起畅聊 DevOps分享在行业内的落地实践经验帮助大家更好理解、规划和实施 DevOps。
如何定义DevOps 其究竟是要解决什么问题
陈钧桐DevOps 客观来说没有一个官方定义我们现在市面上大概有三种讲法 维基百科对 DevOps 的定义是 Development 和 Operations 组合词它通过自动化的软件交付、架构变更的流程使得更加快捷和可靠。这也说明了 DevOps 是强调开发和运维密切做协作并且强调通过自动化的方式让整个流程进行改善。 亚马逊云对 DevOps 的定义是它是一种集文化、理念、实践和工具于一身。出发点就认为它们是密不可分的目的是提高交付能力它更突出的是传统的开发和运维的出发点是有帮助组织更好改进或者服务。 Atlassian 提出 DevOps 是一套实践用于自动化集成软件与 IT 团队之间的流程以便做到更快的软件发布。它对 DevOps 的定义也是包括了运营这个词弥补了之前的鸿沟它强调的是实践并且强调的是弥补以前开发和运维两个团队之间的鸿沟。
综上我们可以看到如果做一个大概的定义DevOps 包含了文化、流程、工具和实践并且这几者之间的关系是密不可分的。
DevOps 初衷是通过工具平台、流程或者人的文化结合建立一种可以持续快速安全交付高质量的流程改进。前面来讲它的初衷是让整个组织的用户价值交付更加快速高效它里面又包含了文化、流程和工具以及很多的实践它们之间是密不可分的所以我们不用太纠结于它的定义如何只要它能达到我们的目的那我们可以采用这样一种原则的集合。
为什么DevOps很好但却很难落地 曾遇到什么难题或阻力
刘斌我在易宝做 DevOps 转型的时候确实遇到一些困难后来也去过蚂蚁大家对基建确实有很多呼声都很渴望能改造好但是我发现达到一种理想的状态各有各的难题。业务快速增长的时候大家会比较排斥基础设施上的折腾如果工作人员对 DevOps 的理解不是很深刻会很难做到围绕业务的推进和实施这些问题导致 DevOps 会变得很难推动。
再有就是传统运维的思路难以转变传统运维关注的是设备是否稳定更希望专注自己的领域各司其职并不服务于开发者或业务。所以这个思维如果不转变就遇到很大困难当时我负责的运维团队里就有人觉得我好像一直让大家服务于开发从而引起不满。开发和运维互相不理解也是一大难处。
我自己遇到的难题和阻力就是从「运维硬刚开发」转变成「运维服务开发」这个转变是有比较大的困难。再一个是从「互相甩锅推责」变成「主动揽责」的转变因为我当时的逻辑就是你配合我的改造责任我来承担。当然会有人觉得特别不理解觉得特别傻但是挺过之后就好很多了。
再就是我们要注意寻找业务上的抓手少说一些比较空洞的话尽量从业务价值上找价值点和业务开发的团队找到一个大家共同受力的点推动这个事情甚至 KPI 或者 OKR 上都可以写成类似一个产出。
还有一个问题就是要坚守我们的核心架构。我非常反对「好的实践就是 DevOps不好的实践就是 DevOps 反模式」。我们不能根据问题的难易程度来做取舍。还有就是坚持不可变基础设施否则的话有可能会转变成一个非常凌乱的、针对大家抱怨提的需求来做一些零碎的工具我感觉主要是这三个阻力和难题。
实施DevOps有哪些常见的坑
刘斌我说一下除了推动别的团队所受的阻力外我们自己内部的一些坑。其中一个很大的坑就是运维容易把运维自动化等同于 DevOps可能有些人会这么想。但我认为 DevOps 应该先做贴近于业务开发的事情而不是只把运维的自动化做得特别好。如果把自动化等同于 DevOps可能会导致沟通模式还是开发在找运维解决问题然后运维再基于自己挺满意的自动化运维工具操作服务于开发这样就是没有做到 DevOps。本质上应该让开发自己去自主运维大家都对自己的事情负责而不是委托给别人做完操作再让他去看结果。
另外一点就是我发现我当时团队里在做 DevOps 平台和工具的时候过早关注界面可能觉得要先把先进的理念展示出来但其实这种做法是本末倒置的。
我觉得 DevOps 应该从交付物出发交付物指的什么呢就是源代码、配置信息打出的包镜像或者测试脚本甚至包括日志。例如这个交付涉及的环境或者你希望它的运行是不是 DevOps 的你的自动化测试是不是真的可以自动执行而不是只是一个触发工具更多还是依赖人工。再有是日志的管理还有包括监控的事件能否对应起来。这个就是整个围绕运维这块的几个对象你的建模、标签是否能串起来需要先把这些事情做好哪怕先找一个简单的开源软件甚至你用商业软件也要先把这个问题先考虑清楚之后再考虑界面上该怎么用。因为我遇到过很多做得非常漂亮但是大家用起来很难受的界面。实际上也增加了使用的复杂性。所以我觉得对制度、交付的约定是一个最优先的事情非常难以反过来我认为这也是一个坑。
DevOps需要打通部门之间的“墙” 您觉得最困难的地方是什么
刘斌从我自己的经验当时 DevOps 的八字循环左边是 Dev右边是 Ops。那个循环我当时感觉右侧的环是相对好推进一些大家做 DevOps 也可以考虑先做右边的环很容易出效果。左边的环我觉得非常困难因为对开发人员的工作方式侵入比较多毕竟需要自动化测试。他们的工作离业务更近业务压力也更大所以非常难推动这是一点。
如果单从部门之间的“墙”而言我认为最重要的是改变运维的服务意识这个说起来有点虚但是也是最核心的而且是我当时一直在团队里反复关注的事情大家很清楚技术都是为业务服务的我们整体的阵型应该更贴近业务而不是下沉夯实自己的基础。例如我当时遇到运维团队非要做自动化运维工具这样会花费更多的精力人肯定离业务越来越远这思路是错的只会导致自己思维守旧。如果我们关注于服务业务会看到更丰富的场景看到更高的挑战这个是最困难的因为必须得有对业务的服务意识。所以我会反复盯这个团队里大家是否把这个思维转变过来了。
陈钧桐本质上还是团队之间思维的转变是很重要的事情。大家要对齐认知和目标要持续地和大家讲事情是如何推进目标是什么。我们从认知到真正的落地实践中间还有很大的隔阂需要不断磨合。
其实我自己对这个话题也有点感慨以前我也是开发会更关注代码但是我们怕大家沉溺于写工具代码去了实际上你做的事情可能是在你团队的第一个但是放大到市面上或者业界有很成熟的工具或案例不管是开源的还是商业的直接去用就好了我们的目的并不是生产基础设施它的目的是有一个使命、价值观和愿景要把这个东西转换成金钱的收入的一个商业链条中间我们做的种种事情只是手段之一而已。我们更加关注的还是业务价值的交付这个业务价值以前开发会觉得产品很难沟通但实际上我们在 DevOps 的文化里更加强调于沟通和协作大家交付的目的是一致的更有利于打破部门墙。
DevOps实践情况如何 那些成功的企业有何共同点
陈钧桐其实现在 DevOps 这种实践很多企业都会运用因为这些东西是为了交付业务价值绕开这个话题其实它只是一系列原则的打包只要我们做的任何动作有益于我们想追逐的东西那么我们可以说它实践了 DevOps。
成功案例大家可能会比较关注国外的先进公司以谷歌为例我们梳理一下谷歌研发模式的变革过程当时他们第一个变革点就是对测试下手开始招聘具有测试思维的开发人员整个测试开始向测试开发转型。然后就是运维开始招有开发经验的运维加上 SRE 角色的转型当然这是第一时代。到了 2008 年他们就做了第二次变革他把测试开始的横向延伸至整体研发效能的领域。从 2013 年到 2014 年进行了第三次变革针对工程效率通过开发的工具、基础架构、指标分析做了一个精细化的运营针对运维 SRE 的工程实践也可以对外输出一些能力整体的方向是向自动化和智能化发展。
我们分析谷歌的这三个变革可以发现关键岗位和人员它的要求有以下几点变化。第一点是开发需要对整个软件生命周期的质量负责包括最基本的执行单元测试要做自动化部署。第二点测试研发效能提升转型现在把整个招聘标准按照开发能力做严格升级这样也是一个重要的变革点。第三点是向运维开发 SRE 转型关注的是整个运维系统工具化和智能化并且有一个隐性的要求50% 的时间 SRE 用于开发并且它在变革的过程中会有意识地培养大家的质量意识、安全意识等这是一个整体持续渐进的过程。我们可以借鉴其中的某些点应用到自己的环境中比如说规律性的定期培训统一大家的意识制定统一的规范然后在招聘人员的标准上有意识做一些区分。
它的变更模式是自上而下、有高层的支持这个对国内来说非常重要。
如何平稳落地DevOps
刘斌第一点还是要贴合业务和业务开发那边做 DevOps 的建设不需要追求工具的完备性不要等工具都完善了才去做另外的事情。我们当时是结合诉求最强烈的点来推动 DevOps 的实践这是一方面。当时我们做的时候就是从现象可观测让开发能快速查出问题所以要从业务价值上找抓手。另外就是从一个横向面去推动会有很多东西会配合做这个事情。
另外一个我们说要服务于开发但实际上也不能太顺着开发的需求走不然可能陷入到一种杂事的鏖战里有种思路就是你在做这个事情的时候得找个锚点这个锚点得影响他去往你期望的方向思考这个问题。我觉得这个还是需要引导的这个锚点实际上就锚定了他的关注点关注点如果关注错了就陷入到一种需求实现的汪洋大海里去了。
有哪些比较推荐的DevOps工具分享
陈钧桐我简单分类列举一下整个软件开发最开始有代码有代码就要做代码托管代码托管的工具有大家耳熟能详的 GitHub有 Bitbucket、GitLab包括 CODING 也是在 2014 年的时候在做国内的代码托管工具。
源代码打完包之后我们叫制品制品的管理工具这里也有一些选择比如常见的 JFrog 的 Artifactory然后是 Harbor它更专注于 Docker还有 Nexus 等。
接下来就是持续集成工具就是 CI这里有 Jenkins、CI包括 GitHub本来它是没有这个功能的后来它也上了还有 Travis。
有了制品就要运转到生产环境上去我们需要持续部署持续部署也有很多的工具有 Spinnaker。还有很多一站式的工具GitLab、GitHub包括国内 CODING 也是做一站式的解决方案也是覆盖了需求的诞生甚至前面 OKR 目标的拆解到最后的交付上线CODING 都有一整套的产品方案感兴趣的同学可以在腾讯云的官网搜索 CODING可以更加具体地了解我们的产品。
对企业而言比较推荐根据现状去选择更合适自己的工具比如说如果这个企业自身的研发能力很强它的业务复杂度不高只是对某个研发阶段有一些痛点就可以用单点的工具做组装。如果企业本身的研发资源有限或者说它的目标专注度更在业务场景这个时候可以选择一些一站式工具比如 CODING当然我们在这个环节里还有其他的角度比如说重视质量重视安全这些里面都有一些插件我们在一站式的平台里也可以针对企业关注的点对插件做集成和嵌入。
DevOps是否会成为一种趋势
刘斌我说这个问题的时候先从运维发展的眼界来讲是我自己的总结。我认为分三个阶段运维发展第一阶段就是按需获取机器第二阶段是按需获取资源第三阶段是按需获取服务。
这个演进过程的趋势本身是为了更好支撑业务响应市场我们的技术整体的振兴是在往业务靠近而且这个阵型越来越紧凑向下沟通层级越来越少了而且是变得越来越薄了。这个趋势会一直有随着技术能力的发展包括对设计能力的演进包括对业务的理解我们会越来越贴近业务这个基础设施团队包括运维团队也会往前端跟进所以 DevOps 会是一个进化的过程而不只是一个工具。所以 DevOps 本身也会是一个趋势如果没有实践 DevOps也会向 DevOps 转变因为这个团队阵型更紧凑就像现代足球它是一个敏捷的团队业务发展肯定会比你快这个公司如果不想被淘汰肯定会往这个方向转型。
结语
DevOps 能否成功关键之一在于各部门之间要有共同的业务目标并不断磨合以达到良好的沟通和互相学习相互协作从而提高生产效率。这也应该是我们在实施 DevOps 时需要认真考虑的核心内容。
