DevOps:你有问题,乐神有答案

前言:

周三晚上,被小伙伴们热情的称作"乐神"的 DevOps专家张乐 为我们带来了《2017年DevOps现状调查报告》解读的线上语音分享,深入讲解了IT效能与组织效能的数据,分析了取得这些成绩背后的管理、技术、文化等因素,包括变革领导力的建设、架构的解耦、技术实践的应用、精益管理的促进等。

想打造高绩效的组织,就需要整合以上的各个层面,形成相互支撑和促进的正反馈循环,并紧跟业界最佳实践持续学习和改进。

以下内容根据乐神和DevOps时代社区小伙伴们的问答互动整理而成,主要就DevOps理论知识、推广和落地经验、流程与实践技术方面回答了大家的问题。

DevOps理论知识

1. @黄威@新大陆-运维产品 :DevOps是方法论,与敏捷的区别是什么?

乐神:在DevOps的领域里包括有敏捷、持续交付、IT服务管理和精益管理等不同的部分,配合在一起去解决整体效能提升问题,如图所示

DevOps推广与落地

1. @黄威@新大陆-运维产品 :如果要落地,怎么说服老板和客户进行组织变革,流程再造?前期投入产出比是多少?要多久才能产生回报?

乐神:从说服老板进行组织变革的角度来讲,我觉得还是要突出它能够取得的效果是什么,可以从四个结果指标,包括产能方面的,以及稳定性方面的去说明,通过这些指标去让老板感受到实在的效果。 另外,从DevOps的现状报告也可以看到,越来越多的组织通过这种变革已经取得了显而易见的成果,推动DevOps已经是大势所趋,我觉得这些都可以去说服老板去做相关的尝试。

2. @一帆@票易通-架构师 : devops人员有工种区分吗?还是就是开发和运维重叠部分

1. @BillyP:我觉得 术业有专攻 是不是工种的区别不一定 但肯定有倾向性吧 2. @石雪峰:虽然DevOps不针对某一具体工种,更多的是一种思想和行为的改变,但是还是会有这样一群人,没事跟自己死磕,为了追求极致的效率提升,让交付更快更好,以此来深挖其中的思想理论和工具实践的结合,作为DevOps的践行者来存在于各个工种之中,也就是这个群里的成员吧

3. @黔明 : 推进DevOps需要哪些基本条件?

乐神:首先在敏捷管理方向已经初步有一些尝试,至少敏捷的研发模式已经能基本跑起来。在DevOps领域里可以通过一些自动化手段和其他工程维度的实践配合起来,将工程维度和管理维度整合在一起去改进,有助于达到一个比较好的效果。

4. @李强@杭州云铸-运维 :大家觉得10人以内的小公司,推行DevOps的话,性价比高不高?

乐神:推进DevOps不是看公司的规模,更关键是能解决什么样的问题,只要能解决问题的实践都是好的,所有有助于提升效率和稳定性的改进,都是值得推动的。

5. @大雨:有一种推广方法,找项目或产品试点,然后以此为基础扩大,这种做法很大的可能性是上层决心不足,公司体系也不跟着改变,最后不了了之。还有一种,某个团队自发尝试,在技术上有所积累并能提效,但是组织上不支持,最后因为KPI等因素,不了了之。

这两种情况,一般大家是怎么解决的,有哪些最佳实践推荐。整体上可以理解为devops的组织导入

乐神:大雨这个问题,今天我分享了两张图,分别是自上而下推动和自下而上推动的整个演进的路线,可以去参考。

6. @雷蕾 : 现有架构中的角色如何转变 比如项目经理和运维经理 他们负责的范围分别是什么 有木有交集 具体如何分工协助

乐神:我觉得在DevOps的转型过程中,角色的转变强调的是跨界、以及具备T型人才的能力。首先是原有各角色要先把自己职责范围内的事情做得足够专业,然后再考虑向前向后的延伸和跨角色更好的融合。 具体来讲,项目经理不仅要关注需求、设计、开发、测试各个环节的效能是否最优,还要重点考虑如何打通端到端的交付流水线,如何打造从生产到上线后反馈的闭环;运维经理除了保证运维本身的职责之外,还要重点考虑如何能够将运维能力做更好的服务化,变成一种自助式、自动化的方式,并且要参与到项目前期的架构评审中去,把从运维侧获取的架构经验和反馈注入到前面的环节。

7. @刘敬月 如何量化评估DEVOPS的TCO(总体拥有成本)?

乐神:可以单独加我微信,我给你分享一些相关的资料。

8. @政企~运维经理~李博文 : Ci CD怎么与产品开发实现DevOps,目前正在组建devops团队,产品如何做好质量把控,怎么控制灰度发布发布给小部分用户

乐神:CI/CD是工程实践,需要敏捷和精益的管理实践结合,从整体上打造DevOps。产品做质量把控主要是测试分级体系的建设,灰度发布有很多技术的支撑。

9. @秦小芬 内建质量从哪里开始?

乐神:内建质量可以从分级自动化测试,培养开发团队的质量意识开始。

DevOps流程、工程实践、技术

1. @Here 魏 Go :请教大神们一个问题,使用k8s部署应用,启动的服务需要注册到zookeeper上,通常是将zookeeper也作为一个服务启动一个pod还是,独立于k8s之外

1. @赵班长: 1. 可以独立啊。独立有独立的好处。这个没有绝对。 2. 我个人觉得zookeeper独立比较好。5个节点的集群。不放在k8s上管理。 3. zookeeper跑在k8s里面,你还需要考虑id的问题。每个节点。要保证id不能相同。 2. @老郭:每一个应用在容器化的时候都要考虑的几个问题,问什么容器化,好处,坏处,成本,收益。

2. @燕儿燕儿:在运维,研发不在同个部门的情况下,是谁来做gatekeeper呢?就是谁来确认本次发布是不是执行?

1. @许峻川:需要流程,研发负责人、测试负责人认可此次上线,再进行发布。 2. @老郭: 1. gatekeeper是一个角色,可能不是一个独立的工种,研发发起,测试通过,PO走流程CTO拍板,这是普通公司。研发leader直接上线这是初创公司。 2. 很多时候要分大版本,小版本,hotfix等不同的上线,有不同的机制和策略 3. @燕儿燕儿:所以这种情况下审批流还是省不了的?是得审批流通过之后才能发布?那中间审批流的时间可能会很长。就无法满足或者说阻碍快递迭代了? 4. @大雨:我的理解审批是为了分责,如果组织不调整,谁能担责谁来 5. @张晨:建立上线流程和质量标准,让每次上线和发布作为例行工作,让审批作为变更管理的特例方式。如果每次发布都是需要CTO签字审批才能完成,不是一个好的模式 6. @Holy文少@ElectricCloud-架构设计 : 开始的时候或者大版本这么做无可厚非,可以逐步放权 7. @方昌@农行-运维 : 建立类似于变更评审,投产上线的规范和制度,这个应该和devops不冲突 8. @文 :按照发布业务的影响大小、大版本还是版本吧,如果每个都要CTO签字,效率会受影响

3. @文:大家发布版本上线前会进行多次灰度发布,会详细测试到什么水平才正式上线?还有业务的自动扩容和缩容,大家是用什么方法来精确判断什么时候应该扩容什么时候应该缩容?用哪些指标来判断

乐神:灰度发布主要是控制风险,通过一个梯度控量,逐步发布特定范围的应用给特定的用户去看,我觉得定义什么样的测试标准,关键看你企业里面的实际情况,比如对错误的容忍度、对风险的分级,以及之前内建质量的完善度和信心等。

4. @燕儿燕儿:脚本如何做好版本管理呢?重点应该抓哪些内容呢?也同步嵌入自动化测试?

乐神: 1. 脚本应该放到版本控制库里,最终达到的效果是,在软件生命周期中任何需要的时间点,都可以将对应的脚本从版本控制库取出,用于进行构建或部署的工作。 2. 自动化测试应该是嵌入到整个持续交付流水线里的每个环节的。

5. @方昌@农行-运维 : 请教各位,发布后大家如何在生产上做系统和应用级自动化验证的?

1. @红风JunTao 在生产环境为测试数据打标签,每次自动化验证就用打完标签的数据验证,银行的系统监管严格,要有特殊的审批估计才行吧 2. @方昌@农行-运维 : 所以每次上线很谨慎,还要组织多方验证 3. @许峻川:可以借助开源工具:Jenkins或者其他商业工具,进行版本发布,这些工具都有严格的权限控制。可以根据流程具体到人。

6. @雷蕾 : 请问在衡量系统稳定性的时候 为什么不考虑故障的数量 只有平均故障解决时间呢?

乐神:不是不考虑故障的数量,而是把一个故障的数量转化成故障解决的时间,因为故障解决时间越长,实际上对企业的消耗是越大的。

7. @雷蕾 : 刚才说到敏捷转型范围很广 包含工程实践和管理实践。我想多了解下管理实践包含哪些关键点

乐神:管理实践有很多,包括Scrum方法、用户故事地图、精益看板,大规模敏捷的SAFe、LeSS等等。

8. @挪着路过 :当多个版本并行开发时,即测试在测一个版本,开发在开发另外一个版本,同时线上又来一个需要紧急修复,需要再开一个版本,这种情况下如何来更好的执行主干分支策略

乐神:同一时间不建议有这么多的版本,如果是按Scrum的方式,按不同的迭代来实施。紧急的修复可以在发布分支上进行修改,或拉出一个hot fix分支。提供一张主干开发、分支发布模型的图供参考:

9. @李倩-七牛 : 容器技术在devops发展中的影响以及有无好的案例分享?

乐神:已经有大量公司在使用容器进行应用包和运行时依赖的封装,线下和线上环境的部署,具体案例挺多的,可以关注高效运维公众号。

10. @weldon :灰度发布如何做到用户无感知?感觉现在好多假灰度

乐神:灰度发布有很多方式,比如可以使用功能开关的技术,这里面列举了一些。

原文发布于微信公众号 - DevOps时代(DevOpsTimes)

原文发表时间:2017-06-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏DevOps时代的专栏

什么样的团队结构才能适应 DevOps 的蓬勃发展?

引言 组织中发起任何 DevOps 相关活动的首要目的是改善对客户和业务的价值交付,而不是降低成本,提升自动化程度,或者从配置管理中驱动任何事情;这意味着不同的...

280100
来自专栏Forrest随想录

谈谈技术和成本(三)

接上篇文章,我们讲了技术不是唯一的解决成本问题的手段,但这不代表技术就没有意义,没有价值,相反,到了一定阶段之后,技术将成为最终的决定因素。

8940
来自专栏顾宇的研习笔记

云原生 DevOps

技术雷达是ThoughtWorks每年出品两期的技术趋势报告,新一期即将在5月15日正式发布。本人有幸第三次参与技术雷达的汉化发布工作,并借此机会一览技术前沿的...

22410
来自专栏Keegan小钢

小钢的架构思考:架构规划

上一篇简单聊了下什么是架构,还将架构划分为三个阶段:规划阶段、设计阶段和构建阶段,构建阶段其实也是架构实现的阶段。其实,三个阶段的界限并不明显,而占比最多的是设...

12460
来自专栏IT大咖说

优云新一代智能化运维管理解决方案

摘要 优云软件解决方案中心总监童华权为我们带来优云作为国内在运维领域做得比较深刻的厂商,在运维管理方面的一些见解。 ? 运维面临的挑战 数据中心进入“两化转变”...

1.1K130
来自专栏罗超频道

QQ订阅号来了,有什么值得关注的?

几个星期前,我收到了QQ订阅号的内测邀请,现已入驻QQ订阅号平台(不叫公众平台)。从周边朋友的反馈来看,大家对QQ订阅号平台还是很重视的,很简单,手Q活跃用户大...

38990
来自专栏罗超频道

找社交要答案,搜狗能重构搜索吗?

移动互联网还在不断瓜分着互联网的流量,入口的碎片化使得搜索引擎受到很大冲击,搜索引擎都在尝试重构自己,寻找新的出路,执掌搜狗11年的王小川的思路是:接入独家内容...

45240
来自专栏WeTest质量开放平台团队的专栏

Hi,腾讯 WeTest 联合 Unity官方打造了新的性能分析工具 UPA

早在2016年ChinaJoy开始,WeTest曾受邀出席过Unity中国的线下性能场的活动,介绍我们的自动化框架和王者荣耀的故事。当时的活动很成功,期间我们收...

24210
来自专栏BestSDK

10款最好用的,开源大数据分析工具

考虑到现有技术解决方案的复杂性与多样化,企业往往很难找到适合自己的大数据收集与分析工具。然而,混乱的时局之下已经有多种方案脱颖而出,证明其能够帮助大家切实完成大...

75360
来自专栏云计算

如何利用云优化加快网站访问

云计算最近成为几乎所有行业的基本业务工具。大多数公司领导人已经注意到云计算及其作用,同时也注意到那些可以优化云计算的方法。总而言之,云计算,曾经的奢侈品如今已经...

253110

扫码关注云+社区

领取腾讯云代金券