大数据智能时代下DevOps工程和质量安全
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。
需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。 从2009年起，相关的工作组、专业组织和博客快速涌现。
DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。
以下几方面因素可能促使一个组织引入DevOps：
1、使用敏捷或其他软件开发过程与方法
2、业务负责人要求加快产品交付的速率
3、虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
4、数据中心自动化技术和配置管理工具的普及
5、有一种观点认为，占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。
DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。
DevOps对应用程序发布的影响
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下 [2] ：
（1）减少变更范围
与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。
（2）加强发布协调
靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。
（3）自动化
强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。
与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）
DevOps原则和实践
一些有助于奠定DevOps强大文化基础的实践是：
对视角的思考：必须从驾驶员和参与者的角度考虑文化变革。
灵活性：在特殊情况下，组织必须足够灵活，甚至可以暂时放弃DevOps值。
集成过程：必须建立一个流程来集成所做的更改。
敏捷决策：团队必须具备敏捷性，能够根据自己的技能和专业知识决定他们需要使用的工具。
透明度：Dev和Ops团队之间应该没有隐藏的议程。
DevOps文化最好被定义为开放式沟通，责任分担，相互尊重和信任的一种方式。如果两个团队之间的合作得不到最佳处理，将对生产力，软件质量和服务质量产生负面影响。
以协作方式工作以实现在当今环境中的集成，例如，测试移动应用程序不仅需要测试来自不同制造商的多个设备，还需要测试多个操作系统，这显然非常具有挑战性，并且需要不同的方法。
成熟的DevOps环境使开发和运营团队成为彼此的客户和供应商。虽然开发团队需要Ops团队来帮助管理大规模信息系统的系统，但Ops团队需要开发团队协助开发操作系统的工具和应用程序，并实现功能以提高安全性，性能和稳定性。从本质上讲，这种依赖性构成了构建DevOps桥梁的基础。
虽然有些人认为DevOps是一份工作描述，但其他人认为它是一种技能。DevOps实践可以分类，包括质量保证，服务，结构和标准的概念。
DevOps的不同视图要求我们从多个角度来看待DevOps。这使我们能够在不同的名称下统一DevOps的冲突定义，例如DevOps作为SDLC过程中的角色，DevOps作为技能集，DevOps作为支持信息系统开发和操作的概念框架。
一旦建立了适当的DevOps环境，它就会对组织的发展做出重大贡献。
对质量保证（QA）的贡献
DevOps 可以在信息系统的质量保证领域做出重大贡献，将开发，运营和客户支持团队与客户联系起来。QA通常很难预测，DevOps通过合作和工具使上述各方更加紧密，从而改善了质量保证流程。与过去相比，DevOps今天也提供了更多收集更多数据的机会。为了产生更大的影响，可以为执行开发和运营任务的员工分配提供QA的职责。通过使用行为驱动的操作（BDOps），QA的不同角色可以指定系统必须如何提供所需的UX。
对服务的贡献
DevOps原则在服务管理框架（SMF）中也证明是有益的，因为服务越来越依赖于Dev和Ops人员之间的合作。开发和运营活动的整合迫使组织重新评估其业务模式。组织有时需要评估其业务模型以使用基于服务的模型作为软件即服务（SaaS），并且由于DevOps具有一定的竞争优势，因此它作为新模型的组成部分增加了很多价值。
此外，过去由公司拥有的资源现在作为服务提供，例如平台即服务（PaaS），基础设施即服务（IaaS）。由于服务严重依赖Dev和Ops团队之间的无缝合作，因此在SMF中支持DevOps原则是有益的。
对信息系统开发的贡献
DevOps是信息系统开发的一个重大变化。DevOps缩小了开发人员，操作和最终用户之间的差距，允许更早的问题检测。在过去，每个Scrum sprint软件都会按照规范工作，但实际最终用户不会对这些软件进行验证。通过DevOps，我们可以经常为最终用户实施持续开发和发布软件。DevOps还允许开发人员和操作更高效，更有效地协同工作。
因此，DevOps实践有助于节省时间和金钱，同时提高质量和上市时间。是的，您可能需要花时间和资源来设置自动化。