你没有看错！我们这回说的是OpsDev，而不是大肆炒作的DevOps。OpsDev意味着，在开始开发流程之前，先要了解应用程序各组件的依赖关系，先要建好模型。

在最近于旧金山召开的全球开发者大会（WWDC）上，开发人员、最终用户、投资者、分析师和竞争对手都渴望了解苹果心里到底是怎么想的，以保持领导地位和市场份额。没有宣布任何令人极度激动的产品，苹果的股价实际上下跌。但是许多会议都在提到一个共同的主题：用户体验。

苹果在不断协调所有产品和应用程序，那样拥有多个苹果产品的用户从一种设备或应用程序切换至另一个时，能拥有一种无缝的体验，用户不至于迷失了方向。这家公司不是专注于产品功能或产品规格，而是专注于客户体验。苹果擅长这种套路。虽然竞争对手都在鼓吹自家的摄像头像素有多高、最新款式的智能手机核心有多多，苹果却在展示iPhone拍摄的漂亮、发人深省的照片，对于这款手机的任何技术细节根本只字未提。

我们都知道，大多数人的每一天都离不开智能手机。由于之前无法方便地获取信息，过去花大量时间才能完成的许多任务现在大大加快，以至于立即就能得到满足。比如说，在拥有智能手机之前，想在陌生城市找到一家称心如意的餐馆，我过去拼命想朋友圈中有哪些人之前去过那座城市，请他们推荐一下。要是我想不起任何人，一旦我到酒店，就会先问酒店接待员。这意味着，哪怕我已饥肠辘辘，还是先得跑到酒店。我还得掏出早在前往机场、登机之前就打印好的谷歌地图，找好前往酒店的路线。而如今，我只要掏出iPhone，打开Yelp应用程序，一旦找到我想去的地方，就可以使用Waze应用程序，告诉我前往餐厅的路线。更棒的是，Waze可以建议绕路而行，因为由于重大事故，最直接的那条路线出现交通拥堵。然后，我可以使用OpenTable应用程序预约餐厅，那样我可以保证有餐位，还可以获得预订积分。

现在，苹果认为我们的生活还可以更高效。不是使用这么多不同的应用程序来完成一连串任务，才能把我带到之前从未来过的陌生城市的一家中意餐馆，这家公司设想有一天：我使用苹果服务就能实现同样的目的，没必要打开多个应用程序。这番设想需要一种新的产品或服务设计范例。哪家公司想要提供添加到苹果服务中的功能，以便提供个性化的用户体验，它就应该考虑OpsDev，而不是DevOps。容我解释一番。

OpsDev登场

假设我们在为生产智能冰箱的一家家电公司开发下列服务。下面概述了示范性的用户体验：

你钻入车内，车子就认出了你。家里的智能冰箱告知你的智能手机停下来，购置一些食品杂货。它给你三个选项。第一家超市不需要绕路，但你钟爱的那种口味的冰淇淋没货了。第二家超市有点绕路，多10分钟的行程，不过拥有你购买清单中所有物品的所有钟爱品牌。最后，第三家超市会多15分钟的行程，但是你钟爱的所有物品都还有货，还提供优惠券，可以为你省下12美元的开销。一旦你选择好了超市，汽车会在多媒体信息娱乐系统上显示最优化的行驶路线。

在不太遥远的将来，由于许多公司试图提供一种集成的个性化用户体验，几个数据源和服务必须集成起来：来自智能冰箱的购物清单、来自连锁超市的库存数据、来自食品公司和连锁超市的优惠券数据，以及交通和地理空间数据。这些不同的数据源由不同的供应商提供，托管在不同的数据中心。想访问它们，你需要不同的登录信息、不同的流程和不同的API。这种个性化服务的设计师必须从不同的数据源和服务来了解不同的服务级别协议（SLA），因为如果集成的服务在及时地检索正确信息方面有问题，用户体验将会受到影响。作为零售商，你不希望最终用户多开了15分钟的行程，结果却发现自己钟爱的物品缺货，或者由于无法使用优惠券或由于被迫购买替代品，结果开销反而贵了20美元。

正如你所见，提供这种个性化的软件服务影响了设计范例，现在必须倒过来。虽然DevOps往往始于开发人员带头克服的挑战（比如代码审查、代码标准、构建管理和持续集成），但是一旦应用程序进入到生产环境，最终归运维团队管控；OpsDev一开始就想到了结局。一旦我们了解了不同数据源的依赖关系及可用性，之后就能设计出把一切连接起来的组件。此外，智能冰箱软件会不断更新。支持新的传感器，提供不同种类的数据。个性化服务还必须跟上新类型的数据，那样服务才能提供不同的个性化服务。对个性化服务而言，软件更新的频率可能取决于来自这种个性化体验依赖的其他服务的软件更新。所以，设计师必须开发一种自动化系统，从它依赖的服务收到更新警报，并且立即建议，表明服务的哪些部分会受到这类更新的影响，何时更新个性化服务，以便与服务的其余部分实现同步。

OpsDev是什么东东？

OpsDev意味着，在开始开发流程之前，先要了解应用程序各组件的依赖关系，先建好模型。此外，考虑基础设施稳定性、环境建模、安全和审计/合规措施得放在第一位。应用程序组件是桩模块（stub），它们不需要是最终形式。其次，必须为组件最终部署到生产场合的前期环境建好模型。第三，将各组件部署到目标环境的过程必须尽量自动化。通过执行上述任务，设计团队和开发团队可以始终如一地复制应用程序和环境模型，并复制开发和测试阶段中的自动化流程。通过在开发和测试阶段轻松复制生产环境和流程，设计、开发和测试团队很早就能知道生产环境的制约因素和工作参数，那样他们在开发应用程序时就能想到那些制约因素和工作参数。在传统模式中，大量时间浪费在了对试运行或生产数据中心中的质量保证团队批准的应用程序进行故障排查。由于环境略有不同，批准的应用程序一进入试运行或生产环境就不能用，部署常常只好被取消。

此外，在OpsDev方法中，发布管道（release pipeline）起到编排作用，负责将应用程序部署到开放环境、测试环境、试运行环境和生产环境，不仅会通过自动化和并行机制，加快部署到各个环境的整体过程，还会通过尽量减少容易出错的手动任务来改进质量。发布管道可以聚合构成发布版本的几条提交管道（commit pipeline）。一条提交管道是单个的应用程序管道，它负责编排持续集成和持续测试。发布版本可能含有由几个项目团队开发的几个应用程序。每个项目团队可能会有自己的提交管道。不同团队为不同应用程序构建的提交管道可以聚合成一个发布管道。发布管道会了解诸应用程序之间的相互依赖关系，并且将那些应用程序调配到试运行环境和生产环境。发布管道会有手动和自动批准机制，确保版本已经批准，处于合适的部署时间表。

通过OpsDev方法，发布管道可以与信息技术服务管理（ITSM）和应用程序性能监控（APM）等解决方案集成起来。发布管道寻求批准的方式是，将即将部署的应用程序的电子材料清单发送到ITSM解决方案（“服务台”），然后打开变更请求工单。IT主管将通过ITSM仪表板，收到即将部署的通知。然后，ITSM解决方案可以通过ITSM审查和批准工作流程来调配请求。一旦得到IT主管的批准，ITSM解决方案可以将信号发送到发布管道、确定部署时间表。成功部署后，发布管道就会更新相应变更请求的状态，向ITSM解决方案告知已成功部署。

发布管道还可以与APM解决方案集成起来。发布管道可以将应用程序部署在试运行环境，并启动APM解决方案来监控性能和负载测试。APM可以报告应用程序是否满足SLA。如果满足，应用程序可以进而部署到生产环境。否则，发布管道将被停止，并且生成警报，表明未能满足目标SLA。在生产环境中，APM解决方案可以监控事务、性能和负载。当它达到某个阈值时，APM就会通知发布管道，通过在数据中心部署更多的应用程序，以增添更多的服务器容量。一旦收到来自APM的请求，发布管道就会向ITSM解决方案提出变更请求。一旦得到ITSM解决方案的批准，发布管道就会将同一组应用程序部署到更多的服务器，提供更多容量。该容量不再需要时，APM就会通知发布管道关闭一些服务器，让服务器回到资源池，用于其他用途。

正如你看到的那样，物联网和基于用户体验的移动应用程序遍地开花，公司再也不能以传统的开发范例来开发产品，那是由于组成单一用户体验的SaaS服务和应用程序组件（设备中的数据、数据中心中的软件、移动应用程序以及Web应用程序）之间的相互关系日益紧密。苹果在竭力让我们的生活变得更高效，为此鼓励苹果开发人员首先考虑用户体验，并提供集成的苹果个性化服务，这也许会加快从DevOps到OpsDev的思想转变。（Anders Wallgren原创）

你没有看错！我们这回说的是OpsDev，而不是大肆炒作的DevOps。OpsDev意味着，在开始开发流程之前，先要了解应用程序各组件的依赖关系，先要建好模型。

在最近于旧金山召开的全球开发者大会（WWDC）上，开发人员、最终用户、投资者、分析师和竞争对手都渴望了解苹果心里到底是怎么想的，以保持领导地位和市场份额。没有宣布任何令人极度激动的产品，苹果的股价实际上下跌。但是许多会议都在提到一个共同的主题：用户体验。

苹果在不断协调所有产品和应用程序，那样拥有多个苹果产品的用户从一种设备或应用程序切换至另一个时，能拥有一种无缝的体验，用户不至于迷失了方向。这家公司不是专注于产品功能或产品规格，而是专注于客户体验。苹果擅长这种套路。虽然竞争对手都在鼓吹自家的摄像头像素有多高、最新款式的智能手机核心有多多，苹果却在展示iPhone拍摄的漂亮、发人深省的照片，对于这款手机的任何技术细节根本只字未提。

我们都知道，大多数人的每一天都离不开智能手机。由于之前无法方便地获取信息，过去花大量时间才能完成的许多任务现在大大加快，以至于立即就能得到满足。比如说，在拥有智能手机之前，想在陌生城市找到一家称心如意的餐馆，我过去拼命想朋友圈中有哪些人之前去过那座城市，请他们推荐一下。要是我想不起任何人，一旦我到酒店，就会先问酒店接待员。这意味着，哪怕我已饥肠辘辘，还是先得跑到酒店。我还得掏出早在前往机场、登机之前就打印好的谷歌地图，找好前往酒店的路线。而如今，我只要掏出iPhone，打开Yelp应用程序，一旦找到我想去的地方，就可以使用Waze应用程序，告诉我前往餐厅的路线。更棒的是，Waze可以建议绕路而行，因为由于重大事故，最直接的那条路线出现交通拥堵。然后，我可以使用OpenTable应用程序预约餐厅，那样我可以保证有餐位，还可以获得预订积分。

现在，苹果认为我们的生活还可以更高效。不是使用这么多不同的应用程序来完成一连串任务，才能把我带到之前从未来过的陌生城市的一家中意餐馆，这家公司设想有一天：我使用苹果服务就能实现同样的目的，没必要打开多个应用程序。这番设想需要一种新的产品或服务设计范例。哪家公司想要提供添加到苹果服务中的功能，以便提供个性化的用户体验，它就应该考虑OpsDev，而不是DevOps。容我解释一番。

OpsDev登场

假设我们在为生产智能冰箱的一家家电公司开发下列服务。下面概述了示范性的用户体验：

你钻入车内，车子就认出了你。家里的智能冰箱告知你的智能手机停下来，购置一些食品杂货。它给你三个选项。第一家超市不需要绕路，但你钟爱的那种口味的冰淇淋没货了。第二家超市有点绕路，多10分钟的行程，不过拥有你购买清单中所有物品的所有钟爱品牌。最后，第三家超市会多15分钟的行程，但是你钟爱的所有物品都还有货，还提供优惠券，可以为你省下12美元的开销。一旦你选择好了超市，汽车会在多媒体信息娱乐系统上显示最优化的行驶路线。

在不太遥远的将来，由于许多公司试图提供一种集成的个性化用户体验，几个数据源和服务必须集成起来：来自智能冰箱的购物清单、来自连锁超市的库存数据、来自食品公司和连锁超市的优惠券数据，以及交通和地理空间数据。这些不同的数据源由不同的供应商提供，托管在不同的数据中心。想访问它们，你需要不同的登录信息、不同的流程和不同的API。这种个性化服务的设计师必须从不同的数据源和服务来了解不同的服务级别协议（SLA），因为如果集成的服务在及时地检索正确信息方面有问题，用户体验将会受到影响。作为零售商，你不希望最终用户多开了15分钟的行程，结果却发现自己钟爱的物品缺货，或者由于无法使用优惠券或由于被迫购买替代品，结果开销反而贵了20美元。

正如你所见，提供这种个性化的软件服务影响了设计范例，现在必须倒过来。虽然DevOps往往始于开发人员带头克服的挑战（比如代码审查、代码标准、构建管理和持续集成），但是一旦应用程序进入到生产环境，最终归运维团队管控；OpsDev一开始就想到了结局。一旦我们了解了不同数据源的依赖关系及可用性，之后就能设计出把一切连接起来的组件。此外，智能冰箱软件会不断更新。支持新的传感器，提供不同种类的数据。个性化服务还必须跟上新类型的数据，那样服务才能提供不同的个性化服务。对个性化服务而言，软件更新的频率可能取决于来自这种个性化体验依赖的其他服务的软件更新。所以，设计师必须开发一种自动化系统，从它依赖的服务收到更新警报，并且立即建议，表明服务的哪些部分会受到这类更新的影响，何时更新个性化服务，以便与服务的其余部分实现同步。

OpsDev是什么东东？

OpsDev意味着，在开始开发流程之前，先要了解应用程序各组件的依赖关系，先建好模型。此外，考虑基础设施稳定性、环境建模、安全和审计/合规措施得放在第一位。应用程序组件是桩模块（stub），它们不需要是最终形式。其次，必须为组件最终部署到生产场合的前期环境建好模型。第三，将各组件部署到目标环境的过程必须尽量自动化。通过执行上述任务，设计团队和开发团队可以始终如一地复制应用程序和环境模型，并复制开发和测试阶段中的自动化流程。通过在开发和测试阶段轻松复制生产环境和流程，设计、开发和测试团队很早就能知道生产环境的制约因素和工作参数，那样他们在开发应用程序时就能想到那些制约因素和工作参数。在传统模式中，大量时间浪费在了对试运行或生产数据中心中的质量保证团队批准的应用程序进行故障排查。由于环境略有不同，批准的应用程序一进入试运行或生产环境就不能用，部署常常只好被取消。

此外，在OpsDev方法中，发布管道（release pipeline）起到编排作用，负责将应用程序部署到开放环境、测试环境、试运行环境和生产环境，不仅会通过自动化和并行机制，加快部署到各个环境的整体过程，还会通过尽量减少容易出错的手动任务来改进质量。发布管道可以聚合构成发布版本的几条提交管道（commit pipeline）。一条提交管道是单个的应用程序管道，它负责编排持续集成和持续测试。发布版本可能含有由几个项目团队开发的几个应用程序。每个项目团队可能会有自己的提交管道。不同团队为不同应用程序构建的提交管道可以聚合成一个发布管道。发布管道会了解诸应用程序之间的相互依赖关系，并且将那些应用程序调配到试运行环境和生产环境。发布管道会有手动和自动批准机制，确保版本已经批准，处于合适的部署时间表。

通过OpsDev方法，发布管道可以与信息技术服务管理（ITSM）和应用程序性能监控（APM）等解决方案集成起来。发布管道寻求批准的方式是，将即将部署的应用程序的电子材料清单发送到ITSM解决方案（“服务台”），然后打开变更请求工单。IT主管将通过ITSM仪表板，收到即将部署的通知。然后，ITSM解决方案可以通过ITSM审查和批准工作流程来调配请求。一旦得到IT主管的批准，ITSM解决方案可以将信号发送到发布管道、确定部署时间表。成功部署后，发布管道就会更新相应变更请求的状态，向ITSM解决方案告知已成功部署。

发布管道还可以与APM解决方案集成起来。发布管道可以将应用程序部署在试运行环境，并启动APM解决方案来监控性能和负载测试。APM可以报告应用程序是否满足SLA。如果满足，应用程序可以进而部署到生产环境。否则，发布管道将被停止，并且生成警报，表明未能满足目标SLA。在生产环境中，APM解决方案可以监控事务、性能和负载。当它达到某个阈值时，APM就会通知发布管道，通过在数据中心部署更多的应用程序，以增添更多的服务器容量。一旦收到来自APM的请求，发布管道就会向ITSM解决方案提出变更请求。一旦得到ITSM解决方案的批准，发布管道就会将同一组应用程序部署到更多的服务器，提供更多容量。该容量不再需要时，APM就会通知发布管道关闭一些服务器，让服务器回到资源池，用于其他用途。

正如你看到的那样，物联网和基于用户体验的移动应用程序遍地开花，公司再也不能以传统的开发范例来开发产品，那是由于组成单一用户体验的SaaS服务和应用程序组件（设备中的数据、数据中心中的软件、移动应用程序以及Web应用程序）之间的相互关系日益紧密。苹果在竭力让我们的生活变得更高效，为此鼓励苹果开发人员首先考虑用户体验，并提供集成的苹果个性化服务，这也许会加快从DevOps到OpsDev的思想转变。（Anders Wallgren原创）