翻译-DevOps究竟是什么？
原文地址:http://www.drdobbs.com/architecture-and-design/what-exactly-is-devops/240009147
作者:Neil Garnichaud
软件开发目前的最新趋势是DevOps文化，即开发人员和运营人员一起确保软件以最低的故障率运行。
很多组织发现他们面临这样的挑战，即随着云的Web应用程序的发展，要求快速发布以便及时响应来自用户社区的问题或请求。及时响应用户需求是每个软件开发团队的目标，但是会给组织内的功能团队造成压力。压力往往导致更多的缺陷和对团队持续性的打断。DevOps通过构建一种开发和运营（这就是DevOps名字的由来）之间的关系来试图解决该问题。在该结构中，开发团队支持运营需求，比如部署脚本，异常诊断，以及从周期最开始就进行的负载和性能测试；而运营团队在软件部署前，部署时及部署后向开发团队提供知识支持和及时的反馈。
DevOps是很多软件开发团队正在前进的方向。他们之前忍受着组织给予的压力，即在QA缺少时间测试的情况下还要生产高质量的代码。而DevOps是一个新的环境，如果开发人员想要成功，就不得不有所调整。在截止期限的压缩，分为开发，QA，产品的故事墙成为了敏捷的阻碍。DevOps试图打破这个墙。现在，团队协作能力变得与技术能力一样重要。因此，单一关注最终用户的体验，来看其是如何影响业务的。DevOps并不是新的工具或组织，而是新的文化和流程。它是开发，QA以及运营相互工作来加快开发和解决问题。
为什么开发人员需要DevOps
DevOps对于开发人员来说是好事。开发人员想工作于DevOps为导向的组织中，有三个主要的原因：
更好的生活质量。DevOps模式的开发人员很少会在半夜接到电话要求解决产品问题。这是因为问题在产生灾难性之前已经被发现，主动监控比被动警告要好的多。
引以为豪的所有权。传统的软件流程中，一旦软件被部署，就被“甩手扔给了”QA，然后甩手扔到了产品环境。所以最终用户看到的可能与开发人员编写的完全不同。但在DevOps模式下，编写的即是发布的，因为开发人员在代码被交给QA甚至到产品环境后，仍可以继续查看和访问代码。换句话说，开发人员拥有从创建到实现的整个交付过程的代码所有权。
更多相关的工作。开发人员和大多数人类一样，在真实世界中相关的工作中更容易得到满足感。因为在传统组织中的开发人员是孤立的，他们经常虚构用户场景来模拟问题。当出问题的时候他们只能尽量模拟接近这个问题。在DevOps模式中，场景是真实的。环境是经过负载测试的，比如，在软件被放入产品环境之前会测试是否能正确工作。另一个例子是测试脚本本身可以测试产品你环境，而不仅仅是模拟环境。将测试结果分享给开发人员，给予了开发人员查看在真实条件下他们编写的代码的性能的机会。
已经实现DevOps意味着什么
可能你的组织已经采用了DevOps模型。有三个问题可以让你清楚的了解DevOps的实行情况：
你作为一个开发人员，能够实时获取故障信息吗？
产品环境中是否使用了开发团队的测试及其它工具来验证产品环境是否能正常工作？
作为开发人员，你是否视网络团队为你的合作伙伴？
如果这些回答都是“否”，那么你并未真正实现DevOps。有一些建议可以改进该情况。先从工具说起。DevOps是文化和流程高于组织，工具可以帮助执行最佳实践。特别是跨团队共享故障信息。这要求在软件中添加更多的检测信息以便查看软件在QA及产品环境中的执行情况，而不仅仅是开发环境中。这些代码会捕获错误，检查系统参数，报告功能超时，以及返回程序执行期间的其它值，并将其写入到日志文件中。
在孤立的环境中，一旦代码被发布到产品环境中，开发人员往往不能再查看这些日志文件。在DevOps世界中，开发人员可以查看任意环境中的日志文件，不管是开发环境，QA环境还是产品环境。这样不仅可以快速修复缺陷，也可以避免同样的缺陷出现在将来的发布中。这使得开发自身对业务能更快速，更具响应性，把敏捷质量引入到敏捷开发中。
打破旧习惯
DevOps也要求打破旧习惯。比如自然倾向是软件bug数量作为衡量质量的方式。但修复单个bug并不意味着能更快的创建无bug的软件。更好的衡量方式是处理bug的流程。换句话说，整个流程中是那个环节引入这个bug的？例如，是因为开发人员本地的构建环境与QA环境或产品环境不一致？或者是代码行为之所以在不同环境中表现不一致是因为某些环境中无法显示某些东西？
除非代码版本是跨环境紧密同步的，而且这些环境也是紧密同步的，否则很难搞清楚一个问题到底是个逻辑问题还是数据问题，抑或环境问题，或者其它问题。而工具能够保证其一致性。即工具能自动的将同样的代码一次性部署到多个环境中。
合作伙伴或谴责者？
开发人员需要做的最大改变可能就是与其他团队成员要有日常互动。开发人员是是主动解决软件问题（比如通过日常监控操作日志），还是等待问题报告给他们？当有问题时，又是如何被解决的？团队成员是合作伙伴还是谴责者？
很多都取决于领导力。不管管理团队如何说教DevOps愿景，请以身作则，提供必要的培训和支持，奖励开发人员的团队贡献，而不仅仅是技术能力。DevOps需要一个乐队指挥。即使当前工作并不是你的工作领域，你也应当接受它。实现DevOps环境需要理解什么对于管理是重要的；是不是发布更快了？是不是质量更高了？是不是开发人员对他们的代码更负责了？这些都与DevOps环境的方式有关。
Neil Garnichaud是SmartBear公司的Host Solutions Business经理，负责产品开发及软件研发。
