LOADING

Follow me

甭提 DevOps 了,咱们搞 OpsDev 吧!【zoues.com】
一月 17, 2017|DockerPaaS

甭提 DevOps 了,咱们搞 OpsDev 吧!【zoues.com】

甭提 DevOps 了,咱们搞 OpsDev 吧!【zoues.com】

DevOps称得上是IT界最著名的合并词了,媒体在这方面已做了长篇累牍的报道,网上这方面的文章更是不计其数。它是指开发人员关注的问题与从系统管理员到数据库管理及其他岗位的支持程序员的运维职能结合起来。

甭提 DevOps 了,咱们搞 OpsDev 吧!

但是我们是否其实首先应当将DevOps叫作OpsDev,以体现系统的基本架构需求?

应用程序互联带来的影响


展望未来,许多公司会试图提供一种综合的、个性化的数字化用户体验,以此获利。在这种体验中,几种在线服务将集成起来,跨诸多渠道和用户接触点,打造一种貌似统一的、随时联通的客户体验。

这意味着,客户与品牌或商家互动的体验将涵盖许多互联的应用程序,它们都由不同的代码库和数据源组成,托管在不同的数据中心,由不同的团队设计和开发,使用不同的技术和API等。

运维团队的责任


从运维的角度来看,虽然应用程序和代码可能相分离,但是在这个始终互联的世界,需要确保服务的所有部分都始终顺畅运行,确保没有出现服务中断的情况。很显然,交付互联的、个性化的应用软件给应用程序的设计模式、开发模式和运维模式带来了影响。

后来出现了DevOps,帮助公司更好地将软件交付给最终用户。DevOps实践通常源自于软件交付的开发(Development)方面,因为它们最初是为了解决开发人员在开发实践方面的挑战而出现的,比如敏捷开发、代码审查及代码标准、构建自动化和持续集成及更多实践。

但是最终,DevOp涵盖从开发直到运维的整条软件交付管道,其真正价值(及最大的投资回报)最终还是体现在运维方面――一旦应用程序进入到生产环境,其价值切实提供给最终用户。

从这个意义上来说,我们可以杜撰一个新术语:OpsDev――一开始就想到了那个终极目标。

OpsDev意味着前期就考虑到运维的方方面面――在整个过程的早期就顾及应用程序的可运维性、安全性和规模等。

可以从应用程序的初期设计阶段来解决诸如此类的问题,比如“我们将如何管理这个?”,“它会如何扩展规模?”,或者“我们如何将这个迁移到新的数据中心?”。

此外,可以在设计产品的同时,设计和开发交付管道本身的自动化;交付管道包括所有工具链、流程和测试等部分,将代码由持续集成(CI)阶段一路引领到生产环境。

管道本身是应用程序的一个关键部分,而不是事后添加上去的。这确保了在整个软件交付过程中,工件和配置在所有环境上都正确无误,确保产品质量更好,并减少手动任务引起的错误,加快交付,并简化生产环境下的运维。

切记:先裤子,后鞋子


比如说,在开始软件开发过程之前,必须明确应用程序各组件的依赖关系,并建立模型。

  • 此外,首先是要认真考虑基础设施稳定性、环境建模、安全和审查/合规措施。应用程序的组件是桩模块(stub),它们不需要是最终形式。

  • 其次,必须为各组件将部署到生产场景的环境建立模型。

  • 第三,将各个组件部署到目标环境的过程必须尽可能实现自动化。

如果做到上述几点,设计团队和开发团队就能在开发和测试阶段,以一致、可重复的方式,复制应用程序和环境模型以及自动化流程。

如果在开发和测试阶段轻松复制生产环境和流程,独立的设计团队、开发设计和测试团队很早就知道生产环境的制约和参数,那样他们在开发应用程序时就会想到那些制约和参数。OpsDev确保了更高的稳定性和可靠的运维。

而在传统的应用程序交付模式中,常常大量的时间浪费在为应用程序排除故障上:应用程序在试运行数据中心得到了质量保证(QA)团队的批准,但是在生产数据中心下却无法顺畅运行。而一旦部署到生产环境,由于应用程序一部署就完蛋(由于配置漂移等问题),发布给最终用户的过程常常大大延迟。

发布管道


在 OpsDev方法中,发布(Release)管道负责编排将应用程序部署到开发、测试、试运行或生产等环境的工作,它不仅加快了借助自动化和并行化部署到各个环境的整个过程,还尽量减少了容易出错的手动任务,从而改善了质量。版本管道合并了组成发布管道的几个提交(Commit)管道。提交管道是单个的持续集成或特性/组件管道,发布管道可能包括由几个团队开发的几个应用程序组件。

发布管道要明白应用程序组件之间的依赖关系,并将那些组件调配到试运行环境和生产环境。发布管道可能有手动或自动审批关卡,确保发布已得到批准,按合适的部署时间表来进行。

与ITSM集成


借助OpsDev方法,发布管道可以与ITSM(信息技术服务管理)和APM(应用程序性能监控)解决方案集成起来。管道可以“将报告发回”给那些工具,要求批准自动化任务,代码进入到整个管道的不同阶段时,记录任务已完成,或者这些工具可触发由管道编排机制实现自动化的某些下几个步骤。

与服务求助台工具集成相似的是,发布管道还能启动APM解决方案,一旦应用程序已部署到位,就可以监控性能和负载测试,或者一旦收到来自监控工具的某些信号,就执行自动化任务,比如扩展规模或遇到故障后自动切换。

结束语


软件已普遍出现在我们互联生活的方方面面,应用软件在如今消费者的用户体验中扮演了重要角色;这样一来,掌握我们交付和管理软件更新的方式对于如今的公司企业获得成功而言至关重要。由于这些数字化服务与应用程序组件(SaaS、设备中的软件、数据中心中的软件、移动应用程序、Web应用程序及更多)的相互关系更为紧密,我们要鼓励广大开发人员将Ops放在首位,加快观念由DevOps向OpsDev转变。

切记,你也许开发出了最令人惊叹的杀手级功能。但是如果好几个月后才能看到这项功能部署到生产环境,并让它可靠运行,那么它对你或你的客户来说又有什么用处可言?OpsDev动真格,不玩虚的。

云头条编译|未经授权谢绝转载

相关阅读:

中高端IT圈人群,欢迎加入!

献给开发运维人士的八大SaaS监控工具

开源就业报告:DevOps和网络炙手可热

「云头条」人见人爱的九大开源DevOps工具

从Ansible到XebiaLabs:开发运维工具市场的顶级厂商

DevOps是如何让6万用户失望的?

托管服务终结DevOps!

调查发现,了解DevOps的公司与不了解DevOps的公司差距就是那么大

到底什么是DevOps工程师?|「云头条」

运维技能大全 | Devops Tools 周期表

从Amazon的DevOps到AWS的崛起

Docker如何改变了DevOps行业?

DevOps八荣八耻

甭提 DevOps 了,咱们搞 OpsDev 吧!

no comments
Share

发表评论