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 ：灰度发布如何做到用户无感知？感觉现在好多假灰度

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