江苏网站备案需要多久,天辰建设网站,怎么申请订阅号,wordpress留言功能在上一篇 DevOps 渊源#xff1a;角色消融 中我们分析了在作坊式团队中的责任重叠#xff0c;也回顾了 DBA 角色的消融。那么#xff0c;如今我们讲的 DevOps 又是什么角色的消融呢#xff1f; 我想你已经猜到了#xff0c;接下来要消融的角色就是运维人员了。那这次又是什… 在上一篇 DevOps 渊源角色消融 中我们分析了在作坊式团队中的责任重叠也回顾了 DBA 角色的消融。那么如今我们讲的 DevOps 又是什么角色的消融呢 我想你已经猜到了接下来要消融的角色就是运维人员了。那这次又是什么生产力决定了怎样的生产关系的变化呢实际上不止是开发人员的生产力的变化而是包括了运维的生产力在内一起发生了变化。DevOps Dev Ops视线再次回到上面的作坊式小团队里。以上面那种手工部署的方式面对少数几台服务器问题还不明显。当业务扩大用户量迅速在两个月里从 20 万增长到 50 万服务器也从 3 台增加到了 10 台针对他们来对应用程序的部署和日常维护的工作量徒增继续手动操作带来的错误和其他不可控风险如偶见的服务器环境问题让人越来越不放心了。这时候运维人员们捡起了多年不写的脚本开始了服务器环境自动化的过程。另一头开发人员开始引入持续集成实践来保障质量单元测试被引入、发布版本也可以自动化了。当他们开始实施端到端自动化测试的时候猛然发现对服务器环境的准备过程竟于生产环境如此类似。在小团队里开发人员和运维人员就坐在隔壁类似于上学时同桌的你。他们很快决定通过结对编程的方式高效地整合他们的工作并继续统一的工具链体系来提供在开发阶段和生产环境的各类需求。包括代码编译、创建新服务器、安装依赖软件、部署迁移数据库、多环境配置、自动化测试以及版本发布流程全部都能够在统一的软件上完成了。那么这俩同桌他们是 Dev还是 Ops 呢他们共同宣布了一个新词DevOps。DevOps 让运维工作展现在 Dev 面前让他们从更广的视角来看待等整个系统代码不光要写完还要能够自动地部署到服务器上。DevOps 不是指运维的消失而是以更高效和可靠的方式在做运维。朴实地说DevOps 包括从代码开发开始到产品部署到产品环境再到产品在生产环境的运行期间的监控与维护为止的整个过程。这也是大多数人所理解的 DevOps。如果让一个开发人员来用一个词形容 DevOps 的话他会说自动化。DevOps 运动至此作坊式团队里的 DevOps 故事也就讲完了。我们看到小团队在组织层面的包袱很小而在实践层面也比较容易跟上往往他们的迫切的问题是开发进度太紧面对技能不足却没有足够的时间和机会来夯实技能。要解决这些问题除了团队客观条件亟待改善之外还有产品思路和发布规划的优化。这对于小的团队说来只要决策人下定决心整个团队成功实践 DevOps 并不困难。那么情况在其他团队是怎样的呢我们来看一下大一些的团队。由于他们并不缺人手上述过程就会是另一番景象。再回头看一眼上面的过程我们不难发现有很多风险很大的地方例如开发人员自己编译一个新的程序包直接放到服务器上而风险则往往是大团队需要尽力去防止的。于是他们有一系列流程管控措施来防止问题出现在生产环境中。他们有独立的需求分析部门有严格的代码审查流程甚至团队专门的版本发布团队或者负责人以及话语权很高的质量和风险管理体系。相比而言大一些的团队掌握 DevOps 技能并不成为大的挑战——他们有足够的资源可以在短时间里快速构建这些能力相反他们更大的挑战却是在团队结构不变的情况大家各个“专门”的角色如何向 DevOps 实践看齐并让这种机制持续下去。这正是 DevOps 运动剑峰所指。《凤凰项目》讲了一个 IT 运维经理临危受命通过三步工作法以及同事间协作帮助的情况下拯救了一家历史悠久的汽车配件制造商的故事。这本书还介绍了开发运维模式的 “三步工作法”。第一工作法是建立从左到右的高效工作流。典型做法是持续自动化构建、集成和版本部署等。第二工作法是在这个工作流的相反方向从右向左建立逐级的快速反馈流及早发现问题谨防问题向更右边流动。典型做法是高效的代码检查坚守持续集成纪律测试前移和自动监控机制等。第三工作法是在组织层面构建快速试错和学习成长的气氛和文化。典型做法是放权和信任、复盘问题规模化创新等。这样看来DevOps 不再只是开发团队的事了独角戏是唱不持久起来的。它一定还还涉及到围绕开发团队的其他角色如与其他开发团队的关系和与非开发部门的协作等它还涉及到企业文化的构建才能让 DevOps 深化和持久地实践下去。回顾与讨论在上一篇我们主要讲了作坊式团队中角色重叠这种重叠天然是由于他们的天然压力所决定的。于是事实中不少小团队长年累月地受困于无尽的需求变更还没来得及思考怎么打造好团队团队里的力量就在一次次更新的过程被不断稀释得只剩下一团乱象。但如果团队幸运地遇到了懂得打造工程师文化的负责人那他们反而更能利用优势在 DevOps 运动中成为最具活力的那一群。各司其职并通力协作是大型项目的常见做法人类的各项大型工程一次次成功地实践着这样的经验。然而在 IT 领域这样的协作模式正在受到挑战。近年来我们发现不少产品是由只有少数人的团队研发的在短时间取得了巨大的成功。芬兰的游戏公司 SuperCell 以 5~7 人小团队的模式在短时间里快速地推出不同的游戏同时收集用户的喜好信息据此决定进一步投放到这个游戏的资源。如果受不到欢迎就快速宣布失败、分析教训并用于新游戏的研发。到他们被腾讯以 86 亿美元被收购时整个公司不超过 200 人。这些不断踊现的案例让不少大型团队也在思考如何更好地调整姿态来尝试接受 DevOps让它成为团队的日常风格从而提升团队效能。不过作为一个探索性命题我们不妨深入再想一层如果说 DevOps 是 IT 开发团队需要考虑的方法论的话那么对于大型企业来说组织层面又该怎么办上面提到DevOps 对企业文化是有所期待的而文化这种一般变起来是相当难的对于那些暂时还是业务驱动的企业来说尤其如此。显然这时候对于改变企业文化来说DevOps 作为一种驱动力来说是远远不足的。答案在数字化转型体系可以找到它正是企业组织整体的敏捷性。在这个体系中它更将学习型组织设定为企业整体的文化。当然要在更广的层面去转型更是谈何容易不过换个思路来想IT 团队的 DevOps 相当于自下而上的转型而企业层面的数字化主动转型则是由上而下的转型。大胆地想象一下假如数字化转型获得成功团队的 DevOps 文化会不会自然踊现呢原文地址 https://blog.jijiechen.com/post/devops-the-future/.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
