
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
采用开发运营文化和实践的组织在努力解决一个横亘几十年的IT悖论:如何授权敏捷团队对生产环境进行小幅、频繁、低风险的更改,以满足用户并改善业务,又不影响可靠性、安全性、性能以及其他运营服务级别?
开发运营实践和工具弥补了IT变更管理流程方面的不足,这些不足会导致重大事件、需要根本原因分析的复杂问题、导致部署延迟的糟糕基础架构依赖项以及长期性安全问题。开发运营成功的几个例子如下:
使用私有云和公有云的组织借助安全的基础架构即代码,使环境的部署和拆除实现自动化。
敏捷开发团队借助左移的持续集成/持续交付(CI/ CD)管道,使测试实现自动化,并简化构建和部署工作。更高级的团队在管道中加入了安全验证,并积极采用开发安全运营(devsecops)。
IT运营团队加大监测和部署人工智能运营(AIOps)平台的力度,以改善可见性和事件响应,从而改进管理复杂的无服务器部署、微服务架构和混合多云网络这一能力。
这些都是解决IT敏捷和运营悖论的战略性要素,但是如果没有一项战略就盲目开展这些计划,可能导致没有业务价值的IT结果。更为糟糕的是,它有时可能导致IT部门在自动化方面过度投入,影响了完成业务优先事项。
比如说,假设你在更新改造一款遗留的三层应用软件,同时将其转移至公有云,你就要决定实施哪种级别的自动化。应该如何定义什么足够好?又该如何为开发运营方面的改进定义成功标准?
有一些问题和参数有助于回答这个问题。一些人可能称之为服务等级需求,另一些人可能称之为非功能性需求。在一些情况下,高度参与的利益相关者会需要每天发布和99.999%的可靠性。而在另一些情况下,让利益相关者积极定义需求会比较困难。
任何一种情况都带来了挑战,但是敏捷性所需的共同点是首先定义客户、客户角色和成功标准。如果利益相关者的规范性过强,将他们列出的需求与业务层面上很合理的需求区分开来很重要。如果他们的需求没有明确定义,将成功标准记入文档特别重要。
许多组织定义产品管理或业务关系管理方面的职责,以记录和共享目标角色、成功标准和业务需求。将这种客户理念引入到开发运营团队和实践是一条较佳实践,将帮助组织确定要投入于哪些方面的自动化、进行多大的投入。
总之,无法强行要求敏捷性。只有加强领导人和参与者的协作,才能获得敏捷性。敏捷团队必须按照自我组织的原则和标准来运营。他们必须兼顾业务需要的改进与解决数据、运营和技术债务所需的工作。设置优先级、定义成功标准以及确定什么是较小可行产品,需要定义客户角色,并了解客户的需求和价值。
当组织采用这些类型的实践时,就不必强行要求敏捷性。敏捷性成为了共同的价值观和完成工作的标准方法。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!