开发者、终端用户、投资者、分析师和竞争对手都急于了解苹果在最近旧金山举行的WWDC大会上想要保持其领先地位和市场份额。没有新的令人振奋的产品被宣布，苹果的股价实际上下跌了。但有一个共同的主题在许多会议中反复出现：用户体验。苹果正在不断调整所有产品和应用程序，这样一个拥有多个苹果产品的用户可以在从一个设备或应用程序切换到另一个设备或应用程序时获得无缝的体验，而不会丢失用户对他们正在做什么的上下文。公司关注的不是产品特性或产品规格，而是客户体验。苹果有这种想法的诀窍。尽管苹果的竞争对手们都在吹嘘他们的相机拥有百万像素的像素和最新型号的智能手机的机芯数量，但苹果却轻松地展示了iPhone拍摄的美丽、鼓舞人心的照片，甚至连手机的技术细节都没有提过。我们都知道，没有智能手机，我们再也活不下去了。很多过去花了很多时间的任务——因为信息无法从我们的指尖获取——现在已经加速到即时满足的程度。例如，在拥有智能手机之前，为了在一个新的城镇里找到一个好地方吃饭，我曾经试着想起我的人际网络中曾经拜访过的人，并向他们提出建议。如果我找不到旅馆的接待员的话，我可以问一下旅馆的接待员。这意味着我必须先去酒店，尽管我非常饿。我不得不拿出我在去机场之前打印的谷歌地图，然后登上飞机找到去酒店的路。今天，我可以打开我的iPhone，打开Yelp应用程序，一旦我找到我想去的地方，我就可以用我的Waze应用程序指引我去餐馆。更妙的是，Waze可以建议您绕道而行，因为最直接的路线会因重大事故而发生大规模交通堵塞。然后，我可以使用我的OpenTable应用程序在餐厅预订房间，这样我就可以确保我的餐桌，同时还可以获得开放桌奖励积分。现在，苹果认为我们的生活可以更高效。公司没有使用那么多不同的应用程序来完成一系列任务，让我去一个我从未去过的新城的一家不错的餐厅，而是设想有一天我可以使用苹果服务来实现同样的目标，而不必打开多个应用程序。这个愿景需要一个新的产品或服务设计范式。任何一家公司如果想提供苹果服务中包含的功能来提供个性化的用户体验，就必须考虑OpsDev而不是DevOps。让我解释一下。输入OpsDev假设我们正在为一家生产智能冰箱的电器公司提供以下服务。下面是用户体验的概要示例：当你爬进去时，你的车会认出你。家里的智能冰箱已经通知你的智能手机停下来取些食品。它给你三个选择。第一家超市不需要绕道，但那里没有你喜欢的冰淇淋。第二家超市有一点绕道，增加了10分钟的开车时间，但它有所有你最喜欢的品牌在你的购物清单上。最后，第三家超市将增加15分钟的开车时间，但所有你喜欢的商品都有存货，另外还提供一张折扣券，可以让你省下12美元的购物账单。一旦你选择了超市，汽车会在其多媒体信息娱乐系统上显示最优化的驾驶路线。在不久的将来，随着公司试图利用提供集成的个性化用户体验，几个数据源和服务必须集成在一起：智能冰箱中的杂货清单、连锁超市的库存数据、食品公司和连锁超市的优惠券数据、交通和地理空间数据。这些不同的数据源由不同的提供者提供，并托管在不同的数据中心。要访问它们，您将需要不同的凭据、不同的进程和不同的api。此个性化服务的设计者必须了解来自不同数据源和服务的不同服务级别协议（SLA），因为如果集成服务在及时检索正确信息时出现问题，用户体验将受到影响。作为一个零售商，你不希望终端用户在额外的15分钟车程中发现他们最喜欢的产品缺货，而杂货店的账单实际上要高出20美元，因为他们不能使用优惠券，或者因为他们被迫购买代用品。正如您所看到的，这种个性化软件服务的交付影响了设计范式，现在必须颠倒过来。虽然DevOps倾向于从开发人员主导的挑战（例如，代码评审和代码标准、构建管理和持续集成）开始，但一旦应用程序被提升到生产环境中，它最终就成为运营团队的掌舵人；OpsDev从最终目标开始。一旦我们理解了不同数据源的相互依赖关系及其可用性，我们就可以设计将所有数据连接在一起的组件。此外，智能冰箱软件也在不断更新。新的传感器可以提供不同种类的数据。个性化服务还必须跟上新的数据类型，这样才能提供不同的个性化服务。个性化服务的软件更新频率可由来自该个性化体验所依赖的其他服务的软件更新驱动。因此，设计者必须开发一个自动化系统来接收来自它所依赖的服务的更新警报，并立即就服务的哪个组件将受到此类更新的影响以及个性化服务何时必须更新以便与其他服务同步提出建议。什么是OpsDev？OpsDev意味着在开发过程开始之前，必须首先理解和建模各种应用程序组件的依赖关系。此外，首先要考虑基础设施的稳定性、环境建模、安全性和审计/合规性措施。应用程序组件是存根，它们不需要是最终形式。第二，必须对为生产部署组件的环境进行建模。第三，将各种组件部署到目标环境的过程必须尽可能自动化。通过执行上述操作，设计和开发团队可以以一致的方式复制应用程序和环境模型，以及开发和测试阶段的自动化过程。通过在开发和测试中轻松地复制生产环境和过程，设计、开发和测试团队将很早就知道生产约束和参数，以便在开发应用程序时考虑到这些约束和参数。在传统的模型中，大量的时间浪费在对已经由QA批准的登台或生产数据中心中的应用程序进行故障排除。而且通常情况下，必须取消部署，因为已批准的应用程序在到达登台或生产环境时会死机，因为环境稍有不同。此外，在OpsDev方法中，一个协调应用程序部署到dev、test、staging和production环境的发布管道不仅可以通过自动化和并行化来加速各种环境中的部署过程，但它也可以通过减少容易出错的手动任务来提高质量。发布管道可以聚合多个组成发布的提交管道。提交管道是一个单独的应用程序管道，用于协调连续集成和继续测试。一个版本可能包含多个项目团队开发的几个应用程序。每个项目团队都可以有自己的提交管道。不同团队针对不同应用程序的提交管道集合可以聚合到一个发布管道中。发布管道将了解应用程序之间的相互依赖关系，并将这些应用程序封送到登台和生产环境中。发布管道可以有手动和自动审批门，以确保发布得到批准，并且按照正确的部署计划进行。从OpsDev方法来看，发布管道可以与ITSM（信息技术服务管理）和APM（应用程序性能监视）解决方案集成。发布管道可以通过将即将部署的应用程序的电子物料清单发送到ITSM解决方案（"服务台"）并打开更改请求单来寻求批准。IT主管将通过ITSM仪表板获得即将部署的通知。然后，ITSM解决方案可以通过ITSM审批工作流来封送请求。在得到IT主管的批准后，ITSM解决方案可以将信号发送到发布管道以安排部署。成功部署后，发布管道可以通过更新相应更改请求的状态来通知ITSM解决方案成功部署。发布管道还可以与APM解决方案集成。发布管道可以在登台环境中部署应用程序，并启动APM解决方案以监视性能和负载测试。APM可以报告应用程序是否满足SLA。如果应用程序可以继续部署到生产环境中，则可以将其部署到环境中。否则，发布管道将停止，并生成有关未能满足目标SLA的警报。在生产环境中，APM解决方案可以监视事务、性能和负载。当它到达