06 | 转型之路：企业实施DevOps的常见路径和问题
该思维导图由 AI 生成，仅供参考
两种轨迹
自底向上
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
企业实施DevOps的常见路径和问题 本文深入探讨了企业实施DevOps的常见路径和问题，为读者提供了对DevOps转型过程的深入了解和思考。作者指出，企业在实施DevOps转型时常遇到缺乏时间和精力投入、企业内部系统庞大难以改变等问题。然而，他认为DevOps转型之路是有迹可循的，企业可以选择自底向上或自顶向下两种可行的轨迹。 在自底向上的模式下，小部门或团队成为DevOps的早期倡导者和实践者，逐步建立DevOps共同体，并通过局部改进逐步铺开至整个企业。而自顶向下的模式则是由公司高层下达任务目标，推动各个团队实施DevOps转型。 寻求管理层的认可和支持是必不可少的，而客观有效的度量指标和持续的资源投入需要借助高层管理层的推动。文章还提到了企业DevOps转型的通用路径，包括寻找合适的试点项目、寻找团队痛点、快速建立初期成功和快速展示和持续改进。 然而，转型过程中也存在一些问题，如J型曲线现象和技术债务的问题。在这种情况下，建立一个专职的转型工作小组是很有必要的，由DevOps转型关联团队的主要负责人、DevOps专家和外部咨询顾问等牵头组成，负责制定DevOps转型项目计划、改进目标识别、技术方案设计和流程改造等。 总的来说，本文通过讨论企业实施DevOps的常见路径和问题，为读者提供了对DevOps转型过程的深入了解和思考。
《DevOps 实战笔记》，新⼈⾸单¥59
全部留言(19)
- 最新
- 精选
iiiqueena老师，在J型曲线里为什么会有”自动化导致人工处理的测试增加"，自动化的进程中不是也增加了自动化测试么？测试的压力从手工转到编写自动化测试脚本，人工处理的测试增加时怎么回事呢？作者回复: 是这样子，由于开发辅助工具以及需求拆分导致开发完成的需求加速，流转到测试团队就对测试团队带来的更大的压力，如果测试团队的自动化能力没有跟上，那么就会产生瓶颈，比如给你举个例子，对于一个移动App来说，开发一个功能可能一天就完成了，但是全量回归测试就要两天，那么开发再怎么快，测试也快不了，这就要求测试能力的提升了，你可能会说，开发只改了一个功能，那么只测一个地方不就行了吗？事实上，并非这么简单，一来害怕出错，二来依赖关系变更影响分析没有做到位，你怎么敢就事论事呢？
2019-10-28218
书剑我们去年7月成立devops小组，先通过jenkins实现了. net应用测试环境构建，paas实现了java应用的平台化构建，目前已通过二开paas平台实现了开发，测试，预发布环境的java应用部署，正在将正式java应用的部署从早期jenkins迁往paas。 途中有两个问题想请教下老师 1.虽然将应用迁移至部署平台，但感觉称不上cicd，请问老师cicd成功实践的判断标准是什么？ 2.就是实践devops时，小组成员手上有很多遗留下来的本职工作，以及随着公司发展穿插进来的新工作，导致先前计划的devops相关工作无法按计划进行，这种矛盾该如何处理？作者回复: 你好，关于第一个问题，我给你提供一个最简单的指标，那就是如果只修改一行代码，从研发提交到上线发布给用户需要多长时间？你可以尝试基于现有的CICD流程来看看，我可以告诉你的是，从业界调查报告来看，这个时间不超过一天，精英公司不超过一个小时。 关于第二个问题，我是觉得从来没有准备就绪的时候，并行工作难以避免，如果想保障DevOps的工作推进，就要在流程上约定，比如每个迭代周期，有百分之多少的工作预留给DevOps，如果没有这个底线，那只能说明DevOps的工作优先级不够高。
2019-10-25411
陈斯佳向上沟通真是很重要的能力，上级是我们能利用到的最好的资源作者回复: 没错，但是很多人都不会利用这个资源，我想这跟组织的文化关系很大，我在最早上班的时候是一家日企，第一天就给我们培训的菠菜文化，也就是报告，联络和相谈这三个词的缩写，有进展及时报告，有问题风险及时联络，有创意和想法及时相谈，这三点对我受益匪浅，推荐给你。
2019-10-3010
Oliver我是负责移动端的devops建设，目前devops团队就我一人，现在的自动化就部署了jenkins去自动化编译，打包，测试 ，发布到应用市场这样一套流程。 后续的工作就不知道怎么去开展和推进了，有点迷茫。作者回复: 你好，我现在也是在负责移动端的项目，我觉得根据项目规模不一样，痛点也不一样，比如我们之前的发版动作比较复杂，还必须专人负责，这就可以优化为一键发版，任何人都能操作，减少人与人之间的依赖。再比如，安全扫描的环节手动执行，这就可以把这个环节串联在流水线中也让他自动化，减少部门与部门之间的依赖。还有，测试安装调试包很复杂，需要自行下载连接手机安装，那么就可以通过二维码，发送链接，手机访问网页等方式一键推送和下载，减少人和机器之间的依赖。所以你看，在主流程跑通之后，其实有大量的可操作空间，这就要站在全局视角观察整个流程的瓶颈点，看看有哪些是自己能做的，也就是持续改进的过程。
2019-11-1336
柯基道格目前公司在做的就是DEVOPS转型异常艰难，整个公司层面不敏捷，部门间壁垒高，部门内不想着自己部门的效率提高为最优先，其自己部门以外整体流程也没权管，公司层面也无关键领导重视整体研发效能，似乎更为关注研发功能的正确性，生产线上少出错。接下来说下具体是怎么回事。 我们公司是传统瀑布工作模式公司，部门壁垒很高，各阶段协作性很差，在我所在部门为测试部门，在收到开发交付的内容参差不齐，导致开展工作会很受阻碍，因此部门领导是支持引入DEVOPS的工具链先，将CI持续集成引入其中，让开发交付内容为整齐划一，可以工具链的方式快速进入到测试开始阶段，让测试附阶段的入口有一道基本检查，拦掉一些低级又浪费时间的错误，因此我们做的是持续集成-测试环境部署+冒烟测试，这和测试相关的一小段DEVOPS链。虽然说整体前置时间对于我们来说还是不能有所提高，但至少是先通过工具手段提升部门一小段吧。从DEVOPS的成熟度来说，目前还是在第一阶段吧。作者回复: 其实，我最近的思考是，无论是工程效率，还是DevOps，关键要做到”有感知“，因为效率提升，质量提升，只有真真切切让人感受到了，而不是只停留在PPT上，汇报邮件上，这个事情才算步入了正轨。看你的留言，至少已经超正确的方向迈出了第一步，那么还担心什么呢，当然为了更加体系化的做事，也建议你参考一些成熟度模型，或者专栏中的体系，可能会让你事半功倍哈！
2020-02-184- sugar老师提出的“羽化原则”比较适合我们当前的现状，从底层开始做起，需要一个可以统领的“大脑”，前端时间申请新服务器，整个流程走了一个多月，本来是准备11.11之前切换的，结果服务器下来之后由于网络配置，走流程开通权限啥的浪费了不少时间（主要就在审批），然后管理啊系统封版，只能等到11.11后，反正目前问题还是比较多
作者回复: 你好，像你说的这种申请资源慢，在很多公司我看都是通病，而且靠一个部门也很难解决，人家不听你的啊，所以这种时候就需要DevOps这类专项来改进，甚至需要借助外部力量，明确指出这个地方有问题，其实很多时候聘用外部专家，核心就是透过他的嘴来说出内部不方面说出的问题哈😄
2019-10-253 
雷霹雳的爸爸要说问题，可能在于整个组织把这个工作当成负责devOps工具平台搭建实施的那些人事情了，而这些人自己甚至也认为devOps的相关工作比业务相关的优先级要低，往后排，长此以往，也就没有以后了的感觉 要说解决，估计还得各种吹风儿，尤其给领导的吹边风儿，争取更多的授权，然后再借一些业务开发问题引入一些具体实践措施，也算瞒天过海，用心良苦了吧作者回复: 精辟！我就在做给最大的领导吹风的事情，但是要把这个事情提升到战略高度，让老板理解的前提下认为这件事情跟业务同等重要，我只想说，不容易，这就要用到一些整理信息的技巧了，比如“推拉镜头”，从小点着手，不断变焦到全局，最终达到目标，我下周试验一把，回头给你反馈😝
2019-11-0832
小谢同学当devops转型工作与本职工作并行时，可否采用kanban方法对工作进行优先级和阈值设定，并通过沟通协商来制定针对触发阈值的决策作者回复: 你好，其实DevOps转型工作和本质工作，都是需求，只不过我们人为的区分了业务需求，技术需求，持续改进需求等多种类型而已，实际上对于优秀的DevOps来说，持续改进类需求和技术需求会占据固定的比例，而不是业务需求的牺牲品。比如像谷歌的工程师，每周有20%的时间是自由的，就是公司鼓励创新的一种途径。 关于看板的使用方法，欢迎继续往后听，我会通过两讲来进行详细的介绍。
2019-10-281
Jxin
1.move fast and break things 2.我感觉我在看的不是devops，而是实施敏捷开发，精益开发，增长理念落地，和分工协作，群策群力。总之，好泛。作者回复: 呵呵，好经典的一句话，只不过我总觉得break既可以翻译成打破常规，也可以翻译成把系统搞挂，要选哪个就看DevOps的了😄
2019-11-08
陈文涛军工企业一年两个版本 就不需要、无法应用 devops么？表示存疑作者回复: 你好，我忘记有没有说了，今年再碰到这个朋友，他们对DevOps的模型框架非常感兴趣，只能说不是不适合，只是时候未到吧，不知道你有什么观点呢？
2019-11-06
