分享为什么你的DevOps会失败?

发布于26天前 作者shen100 95次浏览

DevOps的目标非常明确:使应用软件高效迭代,可靠,质量更好。这个目标非常理想,几乎所有人都不会对此产生异议。

许多人都说,他们已经开始了DevOps的实践,正遵循一些常见的框架,比如“CALMS”。然而,能得到非常满意结果的并不多,我们在与200多名DevOps专业人士交谈后,做了以下的数据统计,希望你能从中得出一些结论:

  • 68%的人表示,DevOps中所需的多种工具之间缺乏连接性;
  • 52%的人表示,他们的大部分测试仍然是手动的,速度缓慢;
  • 38%的人表示,他们混合了传统和现代应用,使得环境变得非常混乱,这给应用部署策略和工具链等方面制造了很多麻烦;
  • 27%的人仍然在努力消除孤立的团队,追求所预期的协作;
  • 23%的人对自助服务基础设施的访问仍然受限;
  • 以及一些其他的问题:找不到正确的DevOps思路,难以管理多种服务和环境的复杂性,缺乏预算和紧迫性,以及执行领导层的支持有限……

通过这些数据统计,我们能得出一些更深入的结论来:

挑战1:DevOps工具链中缺少连接

许多DevOps工具会用于自动执行不同的任务,如CI,基础设施配置,测试,部署,配置管理,发布管理等,虽然这些组织开始采用DevOps,但他们往往不能一起工作。

举一个典型的例子,某团队使用Capistrano进行部署,当需要部署新版本的应用程序时,或者当应用配置需更改时,研发人员仍然会通过JIRA tickets 与Test and Ops团队进行通信。

运行Capistrano脚本所需的所有信息都可以在JIRA tickets 中使用,在运行之前,研发人员手动将其复制到脚本中,这个过程通常需要几个小时,需要仔细管理。而所需的配置其实被手动传输两次:先输入到JIRA,再将其复制到Capistrano。 这是一个简单的例子,但这个问题存在于整个工具链中。当DevOps工具链中的工具无法协作并且依赖于手动的时候,持续交付将变得非常困难。

挑战2:缺乏测试自动化

尽管所有的焦点都集中在TDD上,但大多数组织仍然在与自动化测试进行斗争。如果测试是手动的,那么几乎不可能执行整个测试套件,这将成为持续交付的障碍。团队试图通过运行一组核心的测试来处理这一问题,并定期运行完整的测试套件。但这意味着在你的软件交付工作流程中可能忽视很多bug,而且查找和修复的成本要高得多。

测试自动化是DevOps采用过程的重要组成部分,因此需要成为首要任务。

挑战3:布朗菲尔德环境

典型的IT组合在本质上是跨越了数十年的技术、云平台供应商、实验室、数据中心的私有云和公共云。创建跨越这些方面的工作流程是非常有挑战性的,因为相当一部分工具只能使用在特定的架构和技术上。这导致了工具链的蔓延,因为每个团队都希望使用最符合自己需求的工具链。

Docker的兴起鼓励许多组织开发基于微服务架构进行。这也增加了DevOps自动化的复杂性,因为应用程序现在需要数百个异构微服务的部署管道。

挑战4:文化问题

开发人员开发了稳定优质的软件,然后由运维部门部署和运维。尽管所有这些团队都希望能够携手共同合作,但他们往往会有利益冲突。

开发人员可以快速迭代,QA团队确保没有软件错误,两个团队通常由SecOps和基础设施运维部门协调,他们被激励以确保生产不会中断。但成本中心的压力越来越大,这导致了一种反对变革的文化,因为变革引发了风险,破坏了事物的稳定,这意味着需要更多的资金和资源来控制影响。

开发人员也受到开发问题的困扰,大部分时间都花在之前的内容维护上,而不是创新新事物。大多数组织试图让所有团队参与SDLC的所有阶段,但这种方法仍然依赖于手动协作。 自动化是开发和运维合作的最佳方式。但是正如我们刚刚分析的那样,这种不太健康的自动化本身会降低你的速度并引入风险和错误。

我们需要更多关于DevOps理解和思考

一套完整的DevOps框架会包括文化、自动化、测试和共享。DevOps运动的雏形其实是一种文化运动,即使在今天,大多数的实现仍集中在文化上。

虽然文化是任何DevOps架构的重要组成部分,但想改变一个组织的文化是最困难的事情,因为文化会在时间的沉淀中形成。Ops团队不讨厌改变,他们试图快速改变生产过程,但他们更需要运维的稳定性。 把它们和开发人员一起放在一起,可能有助于使工作环境变得更加友好,但它并没有解决根本原因,Dev团队和Ops团队还有很长的路要走。

转载于: http://blog.csdn.net/ghostcloud2016/article/details/77684001
收藏
分享
暂无回复