自动化:摆脱应用发布困境的途径

日期: 2010-12-26 作者:罗伯特∙里夫斯&乔迪∙亨特 来源:TechTarget中国

  每一天,世界各地系统管理员几乎都被困在会议室里,试图找出某项重要应用最新部署的出错原因。在一个看似平常的小改动之后,应用出现了故障。但没人知道出错的原因,更不用提如何修复这一故障。这时,高级经理走进会议室,想要知道何时能够解决问题。他得到的答案是:“我们目前正在进行修复。”但事实往往并非如此。

  这是因为,大多数机构都不相信自动而正确地部署一个现代化、基于Web的多层应用所需的多种快速变更的组件其实是可行的。投入更多的人力不仅费用昂贵(前提是你能够找到许多技术熟练的人员),而且还会带来更多的错误。随着应用变得愈发复杂,而且变更愈发迅速,今后经常会存在这种在部署后苦苦寻求答案的会议。

  解决的方法是实现应用部署自动化,以便减少配置错误,并实现更高的应用运行时间、更加一致的部署、更大的合规比率和更低的行政成本。本篇文章着眼于为应用管理带来诸多难题的应用发布管理,并探讨如何让自动化发挥帮助。

  了解应用发布的难题

  应用发布管理是将新的应用发布从开发到测试直至部署的移动过程。由于这些新发布是满足业务目标的关键,所以必须以低成本进行迅速部署,而不影响其它系统,同时还要确保遵从组织、行业或政府的法规。

  以下为应用发布的四个步骤:

  •   打包—创建多个必须同时部署的配置项
  •   部署—利用打包的内容来安装应用并配置其操作环境
  •   推广—向更关键的环境提供经过测试的打包,比如:从开发到质保,或从质保到生产
  •   合规—记录实施的适当部署流程,并验证部署配置

  这些看似简单的步骤往往在复杂的现代应用环境和现代IT组织中很难实现。如今,基于服务的应用可能包含成百甚至是上千个针对应用服务器、数据库、网络服务器、信息中间件和授权服务的关键配置项。每个组件必须正确配置,以便与构成应用的其它组件的现有版本相配合。随着时间的推移,组件搭配发生变更,错误得到发现并修复,或者增添了新的功能,这时,配置漂移就会造成一系列问题。

  这一复杂的“移动部件”组合由研发人员传递给操作人员,而他们各自有不同的(通常是手动或非正式的)跟踪和发布变更的系统。这正是造成80%的关键任务中断的人员和流程因素。根据Gartner公司于2010年发布的一份研究报告指出:“到2015年,80%的关键任务中断将由人员和流程问题造成,而其中超过50%的停用是由变更/配置/发布的整合和传递问题造成的。”

  这里有一个来自于客户的真实案例。一家公司的质保团队发现并修复了一个过时的中间件组件的问题,但却没有更新用于将此应用推向数十个客户环境的脚本。其后果是,第二天,IT部门收到了大量邮件投诉该应用出现故障。这样的意外应用故障每天都在困扰着企业的IT部门,导致用户工作效率流失,增加额外的故障排除和诊断费用,并降低了用户对IT的满意度。

  “蛮力”的解决办法是高薪聘用更多的员工和顾问。这些专家试图编写和维护部署脚本,以期实现应用部署自动化并管理复杂的应用环境。另一种常见的方法是,在每个测试与部署环境中手动部署每一个应用发布。即使一家公司能够找到这样的资源并负担得起这种方法,它也会崩溃于应用环境的高度复杂性、每周的众多变更、以及研发和操作人员之间所需的大量协调工作。

  自动化解决方案
 
  应用发布的自动化方法必须包含发布流程的全部四个阶段(打包,部署,推广与合规),通过易于开发和维护的工作流来促进部署包在不同操作人员之间的传递,避免各种错误的发生。

  关键的高层次要求如下:

  •   模型驱动的配置管理能够降低复杂性并确保发布的可靠性和可预测性
  •   参数化的应用模板能够确保在不同发布环境保持部署的一致性,如开发、质保、推出和生产
  •   基于角色的访问控制能够确保只有拥有适当授权的员工才可以授权和执行变更,这有助于满足安全和其它合规需求
  •   高度粒状和精确的恢复功能能够撤消任何对应用环境完整性产生威胁的变更

  由企业级配置管理数据库(CMDB)支持的数据模型能够描述并跟踪每个应用所需的各种组件。配置数据模型可捕捉应用环境配置的快照,包括配置项细节及其相互依赖性。该模型是应用环境的抽象表述,可以用于应用环境的相互比较或与 “黄金标准”配置进行比较,从而达到审计目的。此外,该模型也可以被安全地编辑,或作为新的配置推出,从而完全消除对脚本的需要。这有助于确保可靠和可预测的发布,特别是考虑到在现代化应用中存在大量频繁变更的“活动部件”。

  变更和发布管理应不仅只是变更批准。您的解决方案应有助您执行任务自动化,并对授权和生产一致的应用发布打包以及部署环境拥有严格的控制权。随着变更数量的增加和应用环境复杂性的上升,这种长期的一致性将有助于避免计划外的停机和暴增的管理成本。鉴于目前参与应用发布周期的人员和组织的数量(如商业伙伴和外包商)、应用发布的节奏以及对法规遵从日益增多的需求,这些都令这种可扩展性变得至关重要。同时,这一方法还减少了为应对突如其来的应用发布期限而雇用更多人员的需求。

  自动化的应用发布解决方案应还能支持虚拟和物理基础构架,以便使企业能够经济高效地在这两种环境中部署变更,或按照业务需求的变化来迁移应用。

  自动化的工作流以及能够轻松创造自动化工作流的工具可有助提供统一和一致的流程—甚至是当变更的责任随着时间的推移在不同团队之间转移的时候。拥有一致的、自动化的流程非常重要,尤其是当企业改组其支持职能以配合变化中的组织架构,或将部分责任外包给外部供应商的时候。

  对粒状配置的信息的支持使管理员得以将变更控制在较低水平。这比更换整个配置文件更为高效,并减少了出错的可能以及相关的停机时间。

  另一个关键要求是拥有发现功能,从而复制现有的基础架构环境,并捕捉已知的良好配置来作为未来部署的模型。自动化的发现大大降低了用于创建部署打包的成本和时间,同时也减少了用于发现不合规的配置的时间,从而对其进行变更以确保成功部署。

  另外一个有用的工具是快照。它能够长期跟踪配置变更,捕捉环境之间的差异,并报告这些差异,以便进行审计和配置漂移管理。快照可通过提前发现配置错误,帮助IT组织避免应用停用,并在停用发生时大大加速对故障的排除和修复。

  开箱即用的合规模板基于行业标准、法规和控制,为基础架构和应用资源提供了更多控制,并协助管理漏洞和风险。这些模板还帮助IT人员减少了重复性工作,使他们能够采用经过验证的流程,从而避免昂贵而费时的部署错误。

  平台透明的打包掩藏了部署Java EE、.NET及其它应用程序的复杂性,使低技术水平工人得以打包和部署新应用版本。这减少了部署成本,并使组织能将资深员工分配到更具战略意义、价值更高的项目,同时保留他们使用最能满足其需求的应用平台的能力。

  发布自动化解决方案还必须支持复杂的商业应用环境。 例如,IBM® WebSphere ®门户将一套完整的内容管理系统和IBM WebSphere应用服务器相结合。该组合的结果是,不仅需要管理上千个WebSphere配置项,同时也需要管理与网络应用相关的内容,例如:应用程序、主题和门户组件。

  最后,请记住,应用发布仅仅是应用运维挑战的一部分。 IT经理还必须管理项目和组合、应用性能与配置合规。发布自动化解决方案应该与其它IT运行工具紧密合作,实现跨孤岛的工作流,从而进一步降低成本,防止会导致应用停用的错误,并加速业务响应能力。

  前景

  源源不断的新应用以及对现有应用的提高都是现代企业的命脉。企业需要这些新的功能来吸引客户,提高员工生产力,开拓与供应商和其他业务伙伴的新联系,并进入(甚至创建)新的市场。

  缓慢、不一致和不可靠的应用部署都是在剥夺用户、业务伙伴和客户所急需的、用以应对不断变化的业务条件的灵活度。由错误配置造成的应用停用降低了用户的工作效率,甚至会影响企业的销售收入。这使得企业更加难以降低成本、适应新的业务挑战并满足严格的合规要求。

  愈来愈多的企业发现,他们无需忍受失败的部署、不断膨胀的支持成本以及无法解释的停用。相反,他们正在使用应用发布自动化工具来减少目前与应用部署相关的难题、延迟和成本。

  BMC BladeLogic应用发布自动化解决方案能够应对本文所讨论的所有挑战。如欲了解更多信息,请访问:www.bmc.com/products/product-listing/bmc-bladelogicapplication-release-automation.html.

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 多云工作负载迁移:自动化是何作用?

    云计算正在发展进入一个崭新的、更成熟的阶段。云规划和部署的关注点已经从低效应用的远程托管转至对云的支持,并将其作为开发人员所使用的虚拟应用平台。

  • Puppet Enterprise为自动化提供陈述性解决方案

    Puppet令组织科做出快速、可重复的变更,同时还可以自动确保云端或本地跨物理机与虚拟机(VM)的系统和设备的一致性。

  • 敏捷业务驱动云端BPM

    企业架构师已开始使用云来减轻业务流程管理基础设施费用。现在他们又在寻找方法用于其它的地方,如应用程序开发、自动化、协作和动态案例管理。

  • 为什么软件测试需要变革?

    世易时移,现今的科技发展一日千里,软件测试这门科学也到了该进行革命的时候了。没有想法的测试人员可能在测试这条路上不会走得太远。