作者:张岩峰,转载请注明出处     笔名:云烟旧梦

51CTO课程地址:https://edu.51cto.com/lecturer/12750547.html    Linux技术交流群:1127825548


DevOps是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

DevOps(Development 和 Operations 的组合词)是一种重视“软件开发人员(Dev)”和“IT 运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运维工作必须紧密合作。


混乱之墙:

在传统开发周期中,开发团队将新发布的软件“隔墙扔给”运维人员,意味着自己的工作已经顺利完成。

运维人员接手开发者的成果,准备开始进行部署。运维人员手工修改由开发者提供的部署脚本,当然更多时候这些脚本都是运维人员自己维护的。

运维人员还需要手工修改配置文件,以反映生产环境的需求,而生产环境往往与开发或QA环境有很大差异。

就算最理想的情况,运维人员可能只是做了一些在上一个环境中已经做过的重复工作,而最糟糕的情况,可能会引入或发现新的Bug。

随后IT运维团队开始讨论他们所认为的,目前最正确的部署流程,然而由于开发和运维在脚本、配置、流程,甚至环境等方面的差异,基本上等同于要从零开始将所有工作重新执行一遍。

当然这一过程中不可避免会遇到问题,他们联系开发者希望进行排错。运维称开发者提供的代码本身有问题,开发者则回应称代码在自己的环境中一切正常,因此错误肯定源自运维端。

由于配置、文件位置,以及面临这种状态所执行的操作与自己的预期等因素存在较大差异,开发者甚至很难对这样的问题进行诊断。变更窗口留下的时间所剩无几,当然也没什么足够靠谱的方法将环境回滚至上一个正常状态。

那么原本应该一帆风顺的部署过程,为什么最后却变成了“众志成城”的应急演习?必须经历大量指责和错误才能最终让生产环境恢复可用状态?

这种情况经常发生,经常!

DevOps来救场了

通过在共同的业务目的情境中让开发和运维角色与流程变的一致,DevOps有助于促进IT的统一。开发和运维都需要明确,自己是统一业务流程的一份子。DevOps思维确保了无论组织结构是怎样的,个体决策与行为需要尽力为统一的业务流程提供支持和促进作用。

亚马逊CTOWerner Vogel甚至在2014年说过:

“谁开发,谁运行。”

©著作权归作者所有:来自51CTO博客作者云烟旧梦的原创作品,如需转载,请注明出处,否则将追究法律责任

如果文章对你有帮助,请赞赏

赞赏

0人进行了赞赏支持

更多相关文章

  1. Linux系统集群架构线上项目配置实战(一)
  2. 第六集:人机融合—人、物、环境的复杂系统
  3. 生产环境常见HTTP状态码
  4. JAVA环境的CPU高负载问题排查小计
  5. AWS 大数据实战 - 环境准备(一)
  6. 为Dynamics 365写一个简单程序实现解决方案一键迁移
  7. Puppet自动化集群管理进阶篇
  8. CentOS 7 安装以及配置桌面环境
  9. 开发者要了解的图形数据库知识

随机推荐

  1. 安卓相关学习
  2. Android:简单的开场界面
  3. android布局控件的用法
  4. 解决:修改安卓system系统文件导致手机一直
  5. android属性动画爬坑之路
  6. Activity的android:launchMode
  7. [Android(安卓)编译(一)] Ubuntu 16.04 L
  8. android测试器
  9. 疯狂Android第二章:Adapter以及部分控件
  10. 浅析android中Bitmap的使用