OpsDev的时代来了！
2016-09-02 08:20:00   来源：来源：Docker   评论：0 点击：

最近在旧金山举办的WWDC(苹果全球开发者大会)大会上，开发者、终端用户、投资者、分析师以及竞争者全都渴望知道苹果公司(Apple)是如何保持其在手机市场领导地位以及市场份额。大会并没有发布什么令人兴奋的产品，而实际上苹果公司的股票价格有所下降。然而在不同的会议上多次提到了一个共同的主题：用户体验。

苹果公司不断地调整所有的产品和App，从而让一个拥有多款苹果产品的用户从一个产品或App切换到另一个时能够具有相似的体验，降低了用户使用新产品的门槛。苹果公司注重的是用户体验而不是产品的某些功能或者某些说明。苹果公司善于对用户体验进行思考，当他们的竞争者们通过宣传摄像头的高像素以及新款智能手机处理器有多强大来吸引顾客时，他们给用户展示的是通过iPhone拍的漂亮且富有灵感的照片而不是手机的任何技术细节。

我们都知道现在大多数人已经离不开智能手机，很多以前需要花很多时间才能完成的事情现在很快就能够完成，因为拿出手机点几下就能够获取大量信息。比如说，在拥有智能手机之前，想要在一个陌生的城镇找到一个吃饭的好地方，过去我会想想身边有谁来过这个地方，然后看下他有什么推荐。如果谁都没来过，到酒店的时候我就会问问那里的服务员。这就意味着即使我特别饿了，我必须先到酒店才能吃上饭。我还必须在离开机场之前通过谷歌地图查好去酒店的路线，然后才能坐上飞机到酒店。但是今天，我只要拿出我的iPhone打开Yelp，我就能找到我想去的餐馆。然后我可以通过Waze找到去餐馆的路线，更方便的是Waze还会推荐绕道路线，因为通常最近的路线最拥堵。然后我可以用OpenTable在去餐馆的路上预订一个座位。

如今，苹果公司考虑的是如何让我们的生活过的更加效率。通过上面的描述可以得知，为了在陌生的城镇找到一个吃饭的好地方，我需要打开很多不同的App来完成一系列的事情，苹果公司设想有一天我只要通过他们提供的服务就能够完成相同的事情，而不需要打开那么多App。这种憧憬需要一个新的产品或者服务设计模型，任何一家想要加入苹果服务以提供个性化用户体验的公司必须考虑OpsDev而不是DevOps。接下来我会解释为什么。

进入OpsDev时代

设想我们在为一个机械公司设计一款智能冰箱，用户体验大致是这样：

当你打开车门坐上车时，智能冰箱通过你的手机通知你去超市买些东西回来。它会给你三个选择，第一个超市离你最近，但是没有你最喜欢的冰欺凌;第二个超市需要多开10分钟的车程，但你能够买到你购物清单上的所有东西，并且都是你最喜欢的牌子;最后一个超市需要多开15分钟，除了有你想要的所有东西之外，还会送你一些优惠卷，这样能够让你省下12美元。一旦你选择了想去的超市，你车上的多媒体系统会给你提示最佳路线。

企业想要提供上述完整的用户个性化体验，就需要将要用的数据和服务整合在一起，包括智能冰箱提供的食品清单、连锁超市的库存数据、食品公司和连锁超市的优惠卷信息、交通和地理位置信息。这些数据存放在不同的数据中心，由不同的提供者提供。为了获取这些数据，你需要使用不同的证书、不同的处理流程以及不同的API。这种个性化服务的设计者们必须了解不同数据来源和服务的SLA(service level agreement，服务等级协议)，因为如果综合服务不能及时获取到正确的信息就会影响用户体验。作为零售商，你肯定不希望终端用户多开了15分钟车程却发现他们想要的商品已经卖完了，而且因为优惠卷不能用或者需要买些替代品，比预期多花了20美元。

正如你所看到的，想要交付这种个性化软件服务就必须转变传统的设计模型。DevOps趋向于从开发者主导的挑战开始(例如：代码评审、代码标准、构建管理和持续集成)，最后当应用程序上线于生产环境时运维人员才会参与进来。OpsDev正好相反，只有当我们理解了不同数据来源的相互依赖性和可用性时，我们才能设计组件并将各组件连接在一起。此外，智能冰箱软件会不断更新，使用新的传感器提供不同种类的数据。个性化服务软件必须持续获取新型数据来提供不同的个性化服务，软件的更新频率取决于所依赖的其他服务。因此，设计者必须开发一套自动化系统，用于获取依赖服务更新提示并立即分析这些更新会影响服务的哪些组件，以及决定何时更新个性化服务来同步依赖服务。

OpsDev是什么?

OpsDev指的是在应用程序正式开发之前，必须首先理解和模型化不同组件的依赖。此外，还必须事先重点考虑基础服务稳定性、环境建模、安全性和审计/合规措施。应用程序组件是存根的，他们不必处于最终形式。其次，对生产中部署组件的环境必须进行建模。再者，不同组件部署到目标环境的流程必须尽可能自动化。通过上述方式，设计和开发团队可以在开发和测试阶段以一致的方式复制应用程序和环境模型以及自动化部署过程。在开发和测试阶段，通过简单地复制生产环境及部署过程，设计、开发和测试团队可以尽早知道生产环境的限制和参数，这样他们在开发应用程序时可以充分考虑这些约束和参数。而使用传统的模型，大量的时间将浪费在排除由质量保证部门在模拟环境(译者注：Staging，在正式进入生产环境前模拟生产环境的阶段)或生产环境找到的问题。很多时候部署会被取消，因为环境因素略有不同，验证通过的应用程序将无法部署到生产环境中。

此外，借助OpsDev可以使用版本发行管道工具在开发、测试、模拟和生产环境编排应用程序的部署，这样不仅能够通过自动化和并行化加快不同环境的整体部署流程，还能够减少易出错的手动任务从而提高整体质量。版本发行管道工具由多种提交管道(commit pipeline)组成，一个提交管道是一个独立的应用程序管道，用于编排持续集成和持续测试。一个发行版可能包括多个由不同工程团队开发的应用程序，每一个工程团队可以拥有他们自己的提交管道。将不同团队的不同应用程序提交管道集成在一起就构成了一个版本发行管道工具。版本发行管道工具知道应用程序的相互依赖性并且能够将应用程序整理到模拟和生产环境中。版本发行管道工具使用手动和自动两种批准方式确保发行版已被批准以及确保部署流程的正确性。

使用OpsDev，版本发布管道工具能够集成ITSM(Information Technology Service Management，IT服务管理)和APM(application performance monitoring，应用性能监控)解决方案。版本发布管道工具通过往ITSM服务台发送一份即将部署应用程序的电子清单来寻求批准，并且开启一个变更请求。IT服务主管在ITSM服务页面上就会看到即将部署应用程序的通知，然后进行评审以及相应的批准流程。当IT服务主管审核通过后，ITSM就会发送信号给版本发行管道工具让其进行部署。部署成功后，版本发布管道工具会通过更新变更请求状态告知ITSM应用程序已经成功部署。

版本发布管道工具也可以集成APM解决方案，版本发布管道工具将应用程序部署在模拟环境中，然后通知APM监控性能和负载测试。APM会报告应用程序是否到达SLA，如果是，应用程序可以继续部署到生产环境。否则，版本发布管道工具就会终止部署，并且报警说应用程序未到达目标SLA。在生产环境中，APM能够监控事物、性能和负载。当到达一定的阀值时，APM就会通知版本发布管道工具在数据中心部署更多的应用程序来增加服务能力。当收到APM的请求时，版本发布管道工具会往ITSM上创建一个变更请求，当ITSM批准后，它就会部署更多的应用程序来提供更多的服务能力。当服务能力过盛时，APM就会通知版本发布管道工具关闭一些服务，将资源留给其他服务使用。

正如大家所了解，IoT以及基于手机应用用户体验的不断扩张，企业不能再使用传统的开发模式开发产品，因为SaaS服务和应用程序组件(设备软件、数据中心软件、手机应用和Web应用)相互依赖性的增强组成了单一且密切相关的用户体验。苹果公司，通过鼓励开发者首先考虑用户体验以及提供完整的苹果个性化服务这种变革使我们的生活变得更加效率，这也将加快DevOps到OpsDev思想的转变。

【编辑推荐】