在伦敦DevOps Enterprise Summit 2017 (DOES17) 大会上,第二天早晨的主题演讲探讨了在迁往云平台过程中DevOps 所扮演的角色,高效率团队的创建和培养必须适应高度管控的环境,以及如何通过更切实的工作成果促进业务价值的流动。
三个主题演讲拉开了London DOES17 大会第二天的议程,第一场演讲名为“抱歉了运维先生/ 女士,我们并没有忘掉你:Hiscox 公司DevOps 之旅的下半程”,由Hiscox 公司首席技术官 Jonathan Fletcher 倾情奉献。Fletcher 首先介绍了 Hiscox 如何在 2015 年着手从集中化的 IT 职能转型为联盟模式的 IT,以及通过实现持续交付在工作效率方面获得的收益。 DOES 16 上曾经介绍过这段旅程,虽然 Hiscox 昂首阔步地提高了自己的灵活性(从每周约 2 次部署加快至每天约 50 次部署),但他们的团队意识到自己并未实现真正意义上的“DevOps”,他们不断地问自己:“Ops 到底是什么”。去年以来,Hiscox 启动了一项以云平台为目标的迁移项目,通过对高效组织 IT 实现方式方面在过去和未来的趋势进行全面的思考,该项目得到了全面推动,他们还在通过自己的发现作为催化剂,全面推动 DevOps 方法的实现,进而获得更多业务价值。
在使用 Microsoft Azure 和 Amazon Web Services(AWS)进行过实验和概念证实后,Hiscox 最终选择了 Azure,做出这一决定的一个重要因素在于,Hiscox 原本就使用微软技术开发了很多软件。在探讨过向着“云为先”进行的转变后,Fletcher 称在自己公司内部目前部署的基础架构全面退役之前,他们的 IT 总成本有可能继续攀升。因此迁移工作必须尽可能快地完成,并且应用程序通过重构(或使用原生云技术重新开发)必须能带来投资回报才有必要这样做,否则就只能是“尽快平移(Lift and shift)并关闭自己的数据中心:迁移然后修复”。直接上云并不能解决 Hiscox 面临的所有挑战,此外还必须在人员、流程,以及技术方面进行大量投入。
在讨论 Hiscox 公司 IT 的未来时,Fletcher 认为重点在于能带来竞争优势的高价值任务,IT 只是其中的“中介”,以及将各种技术能力集成在一起的“粘合剂”,而非价值创造者本身。IT 机构的方方面面都应使用相同的流程、工具,以及文化意识形态。
不应区分“IT 和业务”,我们的努力应该以 BizDevOps 为最终目标。
云计算和基础架构即代码(IaC)的使用让IT 部门必须具备截然不同的核心技能,但学习态度本身比目前具备的技术和技能更重要。Hiscox 正在努力培养“ T 型”人才,这种人才应该对 IT 知识有着更广泛的普遍认知,同时在一个或多个领域内更为专精,这就需要改变人才的招募策略和内部培训方式。
第二场主题演讲由 Northrop Grumman 公司的 Suzette Johnson 和 Lockheed Martin 公司的 Robin Yeman 担纲,探讨了“在高度管控的环境中培养高绩效团队”。Johnson 和 Yemen 均谈到了自己在敏捷和 DevOps 方面的第一个以及最新一个举措,例如为美国军方“Warfighter”项目开发用于数据收集的大规模系统,以及为美国政府部门开发的机密资产管理系统。此外他们还介绍了在这一过程中学到的四个重要经验:跨组织协作、培养敏捷团队和文化、构建基础架构,以及可度量的流程和成功。
跨组织协作的核心宗旨在于就项目愿景进行充分沟通,确保得到所有管理层关键人员的支持。客户也必须参与到项目生命周期的早期阶段,这样才能获得持续不断的反馈,并且有助于构建业务案例。必须为内部团队确定相应的辅导人员,并培养相关的技能,敏捷团队和文化必须以信任和协作为基础,为此还需要提供恰当的持续培训和相关激励措施。敏捷和 DevOps 的成熟度评估也有助于更好地理解组织 / 部门目前所处的位置。
自动化和集成工具对大规模实施至关重要,一切必须具备相应的章程,并为配置管理能力提供妥善的版本控制机制。
Johnson 和 Yemen 都认为,为项目提供支撑的基础架构,例如通用框架、模式和模板,必须由高度管控环境内部的团队负责构建和维护。自动化和集成工具对大规模实施至关重要,一切都需要进行配置管理。最后他们呼吁大家更加重视流程与成功与否的可度量性。团队必须理解要解决哪些问题,以及与这些问题有关的情况(例如面对反应、计划和透明度,团队该如何进行沟通)。同时有必要定义成功的标准,并提前明确对结果是否成功进行验证所需的指标。此外还要由多位有关人员对结果进行验证,以确保可以高效提供所需业务价值。
第二天的最后一场主题演讲“更切实的工作成果 – 如何破除“正在进行中”这个能力杀手”由Leankit 公司培训和发展部主管 Dominca DeGrandis 提供。DeGrandis 开场首先提问“为什么我们的工作看起来总是负担很重”,并建议通过看板(Kanban)设计针对扼杀工作能力的一切东西获得更高能见度,借此降低工作负担。很多人认为自己其实可以用比实际情况更快的速度完成工作任务,因此可以承担更多职责。有时候,倦怠文化(Burnout culture)也会起到一定作用,但通常这是因为人们不希望团队分崩离析,因此更迫切地希望着手一些新的工作,而不是涉足那些不够刺激的工作,但实际上他们并未意识到这些请求底有多重要,或者仅仅是因为上级让他们这样做。每个人遇到的这些负担通常会对组织所能提供的业务价值产生消极影响。
如果业务价值的交付过程受阻,首先需要确定相关局限:计划外的工作、优先级冲突,以及依赖性。
“DevOps 文化”与精益原则的结合可以帮助我们更加专注于确定整个组织内部的信息和价值流,进而缓解工作负担,促进学习和持续改进的价值,鼓励更深入的配合和信任,最终培养更出色的领导力并相互尊重。客户价值持续不断的流动可以塑造更开心的客户,但面对这种流动,最大的障碍在于正在进行中(Work in progress,WIP)的工作实在是太多了。价值的流动可通过规划工作流程,实现更切实的工作成果,确定工作受阻的具体位置等方式加以促进。
如果业务价值的交付过程受阻,首先需要确定相关局限:计划外的工作、优先级冲突,以及依赖性。现代化的(复杂)世界中满是各种不确定性,计划外的工作始终无法彻底消除,因此需要制定好计划,将自己置身于不会因为计划外的工作对自己造成太多不利影响的境地。此外还要能预见到优先级的冲突,例如对于时间敏感型,由节奏驱动的工作,需要降低其他工作的优先级,并让这些安排能够体现在看板中。依赖性也是不可避免的,我们的工作本身就位于一个相互依赖的大网中,而依赖性本身的影响力是不对称的,每个依赖性都会导致延期的可能性加倍。此外,依赖性也必须能够可见。DeGrandis 在最后的总结中提到,为了改善流程减少超负荷工作的情况,必须妥善处理WIP,如果尚未对WIP 加以限制,那么不妨从现在开始(施加能反映当前现实情况的限制),同时我们必须让工作获得更切实的成果,才能改善价值的流动。
有关 DevOps Enterprise Summit London 2017 大会的更多信息请访问大会官网。大会活动的视频录像可访问 IT Revolution YouTube 频道,并可访问 DevOps Enterprise GitHub 查看演示文稿。
阅读英文原文: Cloud Migrations, Highly Regulated Environments, and Making Work Visible: DOES17 London Day Two
评论