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团队还有很长的路要走。
“精灵学院”第二次分享交流会如约而至，9月6日晚我们继续聊聊《针对企业的DevOps改进和实践（下）》，欢迎各位朋友前来交流分享。
网友评论