专栏首页DevOps时代的专栏DevOps:你有问题,乐神有答案

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),作者:张乐

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 你所不了解的 DevOps

    DevOps时代
  • 关于 DevOps,你还应该知道这些

    在《关于 DevOps ,咱们聊的可能不是一回事》中我所听到的 DevOps 四类概念(文章链接:关于 DevOps ,咱们聊的可能不是一回事) 分别是: De...

    DevOps时代
  • 解读技术雷达中的 DevOps 发展趋势

    ? 今年4月份,我第一次以主编的身份参加技术雷达的翻译工作。有幸第一时间参加到技术雷达的翻译过程中。通过我在翻译其间对条目的了解和观察,我写下了《DevOps...

    DevOps时代
  • Windows10美化

    利用Hide Taskbar软件可以彻底隐藏Windows任务栏. Hide Taskbar 是一款仅有 200kb 大小的免安装软件 下载链接:https:/...

    Inkedus
  • DevOps如何塑造网络的未来

    自从2009年它的到来,DevOps理念已经成为一场战役迫切地需要技术团队彻底地重新思考传统的开发人员(那些写代码的)和运维团队(那些管理代码运行的操作系统)如...

    SDNLAB
  • 无法购买DevOps[DevOps]

    转到DevOps可能是一项艰巨的任务,许多组织都不知道合适的起点。 最近,我参加了一些“ DevOps评估”,以了解他们提供了什么解决方案,从而使我很开心。 有...

    yyx
  • DevOps和持续交付

    小编说:DevOps 领域在近年来变得流行而普遍。由开发(developers)和运维(operations)组成的“共同协作”,归根结底,就是为了提高产品质量...

    博文视点Broadview
  • Kaggle :第二届 YouTube-8M 视频理解挑战赛

    朱晓霞
  • 未雨绸缪,社交新零售泛滥成灾的解药

    流量获取的成本和难度不断增大已经成为一个不争的事实。对于以流量为生存之本的电商行业来讲,身处其中的玩家们对这一事实更加感同身受,他们投身新零售的义无反顾比较真实...

    孟永辉
  • DevOps转型陷阱与核心实践指南

    2010年,我曾在IBM供职,开始参与DevOps相关的产品研发与实施工作。今天看来,我也许是国内较早的DevOps践行者。这两年DevOps在国内开花结果的时...

    yuanyi928

扫码关注云+社区

领取腾讯云代金券