OpsDev--软件设计从Ops角度出发以规避风险

DevOps在09年被提出之后,热度一直不减。最近几年,随着容器化、微服务等概念的兴起,DevOps又开始了大规模实践。但是,随着基础设施的增加,软件设计从Ops角度出发,可以更好的规避基础设施变更带来的风险。

从苹果公司开始

开发者、用户、投资者、分析师和竞争对手都渴望在WWDC上学习到苹果公司维持其领导地位的方式。虽然没有令人兴奋的新产品发布,但是贯穿其中很多话题的核心是:用户体验。

和其他手机厂商的发布会不同,苹果公司专注于客户的体验,而不是其产品的功能和特性。当竞争者在吹捧他们新品拥有的高像素相机和处理器核心数量的时候,苹果公司展示iPhone拍摄的优美、富有灵感的照片时,没有提及设备的任何技术细节。

现在,手机已经改变了我们的生活,日常的衣食住行都可以通过手机app来协助完成。但是苹果公司认为智能设备还能使我们的生活更加高效。不同于目前每个app提供独立的功能,苹果公司希望能够将这些服务整合到一起,对于用户来说,他们只需要使用苹果的服务,而无需打开多个app。要实现这样的愿景,产品或者服务都需要有新的设计范式。任何期望通过接入苹果服务以对外提供个性化用户体验的公司,都应该考虑OpsDev而不是DevOps。

进入OpsDev的世界

我们假设一家电器公司制造的智能冰箱,为用户提供以下体验:

当我坐在车里时,智能冰箱通过手机发出提醒:冰箱存货不足,该去买些食品啦。此时,手机自动生成并推荐了三个采购方案。第一个超市不需要绕路,但是没有我喜欢吃的冰淇淋;第二个超市比第一个远10分钟,但是有所有我喜欢吃的所有食物;第三个超市更远,需要多15分钟的路程,但是它除了有所有需要采购的东西,还提供额外优惠券。我点击了其中一个方案,车载导航开始自动规划行车路线,并显示在汽车多媒体系统中。

在不久的将来,很多公司会致力于提供集成的个性化用户体验,因此不同的数据源和服务必须被整合到一起。智能冰箱通过传感器判断冰箱内的存货,超市服务提供其库存和优惠信息,其他还有交通信息、地理位置信息等等。这些数据源由不同的提供商提供,并且保存在不同的数据中心。这些数据的访问,需要特定的授权方式、API和数据处理流程。个性化服务的设计者,必须明确了解每个服务的规约,因为任务信息不能及时正确的获取,都会影响到用户体验。作为零售商,不会希望用户多花了15分钟时间过来,结果却因为需要购买的商品缺货,或者无法使用优惠券而造成损失。

由此可见,个性化软件服务的交付影响了现有的软件设计模式。DevOps克服了传统瀑布流所不能提供的快速交付能力,通过诸如代码审查、编码规范、持续集成等方式解决软件开发遇到的挑战,并且让开发直接参与到了产品上线流程。而OpsDev考虑的方面却不同。由于个性化服务依赖于底层一系列基础设施,一旦我们知道了每个独立的数据源的依赖关系和可用性,首先需要设计出将各个数据源结合在一起的组件。因此,设计者必须从运维的角度来考虑,对每个服务的依赖程度、故障修复、容错等;同时,由于每个服务相对独立由于每个服务相互独立,个性化软件服务的升级频率受其依赖的服务升级频率影响,这也需要从运维的角度考虑向下(向上)兼容。

什么是OpsDev?

OpsDev是在开发行为开始前,就需要了解应用程序依赖的所有组件,并进行建模。此外,对基础设施稳定性的考量、环境建模、安全审计措施都是第一要务。其次,应用程序组件上线后的部署环境需要被建模。再次,将组件部署到生产环境的流程必须尽可能自动化。通过以上步骤,设计和研发团队可以在开发和测试阶段复制应用程序、环境模型和自动化部署流程。这样设计、研发和测试团队可以清楚的知道应用程序在生产环境的约束和参数。在传统的项目模式下,大量时间浪费在完成验证的应用程序部署到生产环境之后才发现的缺陷。

由于部署自动化在设计之初就被考虑到,应用程序可以随时被部署到开发、测试和生产环境。这种方式不仅可以通过自动化流程加快各个环节的部署速度,还可以减少因为手工部署导致的质量问题。部署程序应该可以聚合多个独立开发的模块。每个模块都可以由独立的开发团队进行开发,并且定制适合自己的持续基础、持续交付流程。发布程序需要预先知道每个模块之间的依赖关系,这样可以快速的聚合每个通过持续集成、持续交付的流程的模块,将它们整合之后部署到集成环境或者生产环境。

通过OpsDev方法,发布方式变得更加灵活。整个部署流程被设计的可以插入验证流程。一个典型的持续交付流程可以是:发布程序首先将待发布应用程序部署到集成环境(UAT测试环境、预发布环境)上,然后触发发布前的自动化、手工验证、性能基线验证等一系列验证措施,整个过程通过之后,部署程序再将应用程序发布到生产环境,发布成功之后记录基线信息和本次变更的状态。

总结

对于物联网或者基于用户体验的移动app厂商来说,传统的软件开发流程无法适应它们的产品,因为它们都会对很多SaaS服务有依赖,且应用程序包含很多组件(物联网设备中的app、移动设备中的app、数据中心的后台服务、网页服务等)。像苹果这样鼓励开发者优先思考用户体验,并提供个性化服务的公司,可能会加速思考方式从DevOps向OpsDev的转变。
文章转载自 开源中国社区 [http://www.oschina.net]

时间: 2024-09-17 06:57:06

OpsDev--软件设计从Ops角度出发以规避风险的相关文章

《挖掘管理价值:企业软件项目管理实战》一2.4 软件设计过程

2.4 软件设计过程 挖掘管理价值:企业软件项目管理实战 软件设计是根据需求的内容,运用计算机理论.技术和工具将其合理地.有机地.具体地转化为功能,并演示其实现的方法.过程和结果.设计人员在理解了用户的需求之后,首先在自己的脑海中会有一个大致的概念和思路,然后考虑如何去实现这些功能,当然这需要一定的专业知识和实践经验.这里就不阐述软件或数据库设计的理论知识了,而重点介绍如何将设计人员脑子里对软件的设计和理解反映到文字.图形和流程上,使得用户可以了解计算机是如何实现他们的需求的.我们用图 2-9

如何写软件设计文档

软件设计的不同模型:瀑布式.快速原型法以及迭代式 自从1968年提出"软件工程"概念以来,软件开发领域对于借鉴传统工程的原则.方法,以提高质量.降低成本的探索就从未停止过.而在这个过程中,提出了许多不同的软件开发模型,典型的有:瀑布式,快速原型法,以及迭代式开发等. 瀑布式模型 是由W.W.Royce在1970年最初提出的软件开发模型,在瀑布模型中,开发被认为是按照需求分析,设计,实现,测试 (确认), 集成,和维护顺序的进行. 快速原型法 快速原型模型的第一步是建造一个快速原型,实现

网站优化需要从用户的角度出发

其实与网站优化相关的因素有很多,比如链接.域名和url等,我想说:成功的网站优化策略是从网站建设之初就开始,并且贯穿了网站建设的全过程.网站优化注重的是每一个细节问题,但是不管是哪个细节应该遵循 "从用户的角度出发"这一原则. 一.用户体验和搜索引擎优化的关系 网站优化并不是单纯的搜索引擎优化,还包括对用户体验方面的优化,由于搜索引擎优化对网站的 响表现的更直观明显,所以很多人将网站优化与搜索引擎优化等同起来,而实际上网站优化的核心仍是用户体验优化. 网站的最终目的就是将流量转化成真正

ANDROID首席设计师谈移动与软件设计

  在 2014 年Accel设计大会上,Android 设计副总Matias Duarte就软件设计接受 The Verge 主编Josh Topolsky访问,在采访时他强调并呼吁:过去设计的出发点是为不同设备开发各自的独立应用,但今时不同往日,软件设计者应当琢磨如何只开发一款应用,并在不同设备上运行. 观看地址:优酷 Matias 在 Google 任职已近 4 年,之前供职于 Palm.Helio.Danger,在用户体验设计方面积累了精深经验和良好口碑. 在访问中,Matias 首先分

智能手机软件设计的人性化和严谨性

注意:本文未经勘误,可能包含少量错别字 如果说到智能手机,iPhone和http://www.aliyun.com/zixun/aggregation/11210.html">Nokia是两个不得不提的家伙,iPhone正在全球如日中天吞噬智能手机的市场份额,而Nokia这个巨头则依然称霸美国以外巨大部分地区,Twitter上@kcome兄认为Nokia在美国市场的失败是个谜,或许那位老兄还会想到Palm-Pre和Android,恩,我觉得Palm时代已经过去了,Android时代还没到来

由学习《软件设计重构》所想到的代码review(一)

前言 对于一个程序员来讲如何来最直接的来衡量他的技术能力和产出呢?我想最直观的作法是看他的代码编写能力,就拿我经常接触的一些程序员来看,他们买了很多技术重构类书籍,但是看完后代码编写能力并没有显著提高.有人说可以用代码review工具啊,但是像市面上的这些代码review工具,只能帮助我们解决表面的bug和规范点,还无法帮助我们发现更深层次的设计问题. 下面我将结合<软件设计重构>这本书谈谈在进行代码review的时候,需要关注的哪些点. 一.技术债务 何为技术债务? 技术债务是有意或无意的做

软件设计的复杂度

什么是软件设计的复杂度 软件技术发展的使命之一就是控制复杂度(Complexity).从高级语言的产生,到结构化编程,再到面向对象编程.组件化编程等等.关于复杂度的定义并不一致,想要详细了解的可以读读The Many Faces of Complexity in Software Design. 英文中Complex和Complicated有着微妙的不同.但总结起来,软件复杂度偏负面意义,包括两个要点: - 难以理解 (难以维护和扩展.) - 无法预测行为 复杂度是随着软件规模不断扩大而必然产生

软件设计漫谈之二:设计模式只是一把锤子!

              设计模式只是一把锤子!     谈起设计模式,那是几乎无人不知,无人不晓,大名鼎鼎的"GOF"(中文有的翻译为"四人帮")惊世之作,真是"平生不识GOF,学尽设计也枉然!"     然而,设计模式真的是软件设计的"瑞士军刀",切.削.锯.钻样样精通么?     读过设计模式的朋友估计不少,但真正注意过<设计模式>的副标题的估计很少,而这个副标题却是避免误解设计模式的关键.<设计模式

从一个圈套For循环来谈软件设计[原创]

设计|循环|原创 从一个圈套For循环来谈软件设计 武汉华中师范大学信管系 谢刚 摘要:就自己的一次实际经历来谈谈软件设计过程中应该注意的一些细节 关键字:软件设计 需求分析      前段时间,跟外面公司设计一个MIS系统(使用工具是PB8.0+MSSQL),是一个关于安全生产的.为了体现我们设计人员的高质量服务,我在<需求说明>之外又帮他们设计了一个功能,就是:在每次这个功能窗口打开时,到数据库中去自动检测看看有没有冲突数据:也就是说,两个一模一样的器材是否被安装了到了两个不同的机器上.这