贯穿软件生命周期共享相同的容器是容器化DevOps带来的优点之一，它简化了开发与运维团队之间的关系。这个共享能力与传统裸机（bare metal）或是虚拟环境下的开发工作是如此的不同。并且，如此一来也改变了代码迁移到生产环境时的最终责任人。
在传统的开发场景中，很多IT组织不能为开发和QA团队提供与生产环境相同的基础设施，因此他们会在精简版本上测试，即使它们一点都不同。例如，在VMware商店，开发者也许会使用Vagrant工具来编写和测试代码。
当开发团队将代码交付给运维，以便在生产环境中部署，然而它却未能正常工作时，挑战就出现了。“在我的机器上明明能工作的啊”，这句话已经成了此类场景的惯用语，但这对决解如何让正常工作的代码更快地从开发者迁移到生产环境的问题没有任何帮助。在DevOps和容器的新纪元里，开发者必须对最终产品承担更多责任。
容器已经重定义交付
容器已经改变了业界动态（dynamic）。这是第一次，开发者的代码和环境可以被未经变动地交付给运维。实际上，在为云重新设计IT组织一文中，这种敏捷构件是下一代IT组织的前提。将代码和环境打包交付带来的好处正是大家对容器技术如此*的原因之一。在最佳实践中，关于这个现象的属于是“非易变代码”，意为一旦应用离开开发团队，就不会再实施代码变更。如果为了修复一个问题或者改变一项配置，需要改动代码，你就需要创建一个新的代码发布上游部门，然后将之推向下游部门使用。
这是一个强有力的范式。运维仅专注于将交付的容器部署到生产执行环境，而不是为了能够正确部署而改动应用。许多人褒奖容器，因为它允许运维不必再为应用的正确部署担负责任，使得他们可以确保容器运行环境的稳定。
但这并不像听起来的一样简单。事实上，将下一代应用作为容器部署是具有挑战性的。应用自身的动态性，不断迁移的执行拓扑，以及难以避免的基础设施故障，都意味着提供可靠的容器运行环境并不只是一项小的功绩。此外，消除应用执行的运维责任也引起了其他问题：总得有人为确保应用正确部署负责。如果运维不扮演这个角色，那么谁来“接锅”？
开发者承担更多的运维责任
它就是开发组织。非易变设施的逻辑意味着，任何需要改动代码的运维问题都会被送至开发部门，他们需要修改并创建一个新的构件。在很多方面，这都是说得通的。毕竟，谁能够比开发者更好地理解应用问题？并且，在开发者需要为其代码问题承担责任的认知，可能会使得他们更加仔细。Netflix称这种应用运维责任的转变为“NoOps”，这意为着不再需要运维来保证视频流服务元素运行。应用部门“接锅”了。在DevOps和微服务的时代，理想的应用部门为其代码提供支持，在问题发生时解决问题，并发行新的构件来修复它们。然而，将责任划归创建容器的应用运维团队并不是解决应用问题的万灵药，微服务应用场景下尤是如此。
还记得在忍者刀的广告里，叙述者会说，“等等，还有更多（内容）”，然后陈述购买刀的其它好处吗？微服务应用的运维亦是如此。相比于将问题提交给问题容器的负责部门，基于容器的应用运维拥有更多的好处，因为很多微服务组建需要依靠其他服务才能正确执行。例如，有一个微服务用来计算货运费，它可能需要依赖其他微服务来获取货物（会被分发）的履行中心到客户所处位置的距离。
谁来为应用的启动、可用性以及正确响应负责？如果你认为应该有其他的应用团队，那么你离答案就比较接近了。
任何团队都必须为其代码负责
如果一个问题在某个应用团队里被开发者发现，那么在识别问题的起因，并发现责任实际上在别的团队后，这个问题就需要被提交到那个团队来修复。这就是微服务能够对你如何运维应用产生一系列改变的原因。运维责任的分布引起了一些重要的挑战：应用问题如何被跟踪、修复和锁定（fixed）。
绝大多数IT组织需要着力于如何为应用问题“遗留”转移责任，或者向上交予开发团队。这个运维模式的基础是能够加速代码变更落实到生产环境的自动化DevOps的能力。它需要使用非易变构件，并且它也要求应用团队能够使用和生产环境类似的环境。
大多数基于微服务的应用组件都会调用其它服务，这就意味着开发团队必须持有应用在生产中会使用的服务的可用版本。那些服务可能并不需要是可扩展的或是全功能的，只要具有开发团队所需的最小功能即可。
此外，为了提供软件问题和跨组织边界的关联问题的根源分析，良好的监控和日志功能也是必不可少的。如果一个问题关联到一个应用部门，那么该部门必须有能力来定位服务中出现问题的位置。如果引起问题的原因位于另一个服务中，那么第一个部门应该能够为第二个部门提供数据，以使得他们能够追踪其服务内的问题，并创建补丁来修复问题。
消除开发-运维的划分
开发者必须承担更多的运维责任已是板上钉钉，我们亦可断言，容器会为开发和运维提供清晰的分界点，并使得后者能够集中精力于提供优秀的容器运行环境，有种过度简化的意味。相对于传统的方式，将代码部署到生产环境而言，转向非易变代码和共享构件是一次巨大的进步，但这并不能掩盖一个事实：总得有人承担应用运维的责任。这就如同容器并不能避免应用问题一样。它仅仅意味着责任可以被划分给那些标记着最适合解决问题的团队。是的，开发者会承担更多责任。但是有如此多的责任需要处理。
唯一合理的解决方案是，向前看，分而治之——每个团队必须承担的应用生命周期的部分职责。但是，并不像“丢到墙外，让他们解决”的旧应用世界，这种处理事情的新方式也需要跨团队协作。最后，我们将会看到运维职责变得像航空母舰甲板上的船员一样——每个小组有自己所承担的职责，但所有的团队为同一个目标而协作。
原文链接：Microservices, containers, and operations: Guess who's responsible now（翻译：孙科）
原文发布时间为：2016-06-21
本文作者：孙科
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：微服务，容器和运维：猜猜现在谁来担责