中国开源软件网

当前位置: 首页 > 互联网 >

以实现微软的数字化转型

时间:2020-06-03 22:55来源:互联网 作者:小狐

以实现微软的数字化转型(图1)

现代软件工程创造了一种文化、工具和实践,专注于高质量、安全和功能丰富的软件服务,以实现微软的数字化转型。微软核心服务和工程(CSEO,前身为微软内部IT,服务微软内部客户)团队正在实施现代软件工程愿景,以创建一种文化、工具和实践,致力于高质量、安全和功能丰富的服务,来实现微软的数字化转型。现代软件工程计划正在帮助CSEO痴迷于客户,加快新功能的交付,并提高工程效率。

1:到目前为止的旅程

截止2020年1月,微软向云计算的迁移使CSEO能够提高流程的整体敏捷性,并为由约1400个组件所组成的约600项服务,新的云技术,这些新技术只需较少的专业技能就能使用,还可快速访问其它基础架构。这样就可以按需扩展环境和资源,进一步使工程师能够更快地响应不断发展的业务需求。但是,CSEO仍然需要解决几个结构性问题,包括基本软件工程基础上团队之间的不一致性,比如编码标准、自动化、安全扫描、遵从性、发布方法、封闭的构建和发布等等。CSEO确实预料到了这一点,因为有些团队的项目组合中包含多达40%的遗留代码,这些代码由打包在一起的大型组件组成。这使得存储、扩展、可用性和操作的变得困难,因此CSEO已开始通过实施组织范围的服务评审来推动一致性。

CSEO缺乏集中的通用软件工程和相关实践,意识到无法继续以联盟的方式发展软件工程,于是CSEO投资了一个中央“基础”团队。这个团队的宗旨是在基于Microsoft Azure DevOps的公共软件工程上进行创新,同时推动整个组织在设计、编码、工具、构建和部署服务方面的一致性。CSEO通过为每个服务领域定义愿景、确定季度优先级以及通过定义的冲刺 (sprint) 节奏执行这些策略,为自己的服务带来产品工程思维。由此产生了通用软件工程和可提高人员效率的一致性以及跨团队移动性。

CSEO需要通过结合行业领先的可访问性、安全性和合规性实践来降低代码中的风险。实现合规性一直是非常具有性,这迫使CSEO从原有的流程和工具中改变,并积极应对这些领域的技术债务。不过,采用新方法的速度很慢,并且由于必须清除的技术债务数量而产生了摩擦。这妨碍了CSEO针对代码提交设置自动策略,从而确保“清洁”前进的努力。CSEO需要努力实现以无摩擦的方式,交付易于访问、安全且合规的软件和服务。

CSEO正在实施一种统一的方法来发射遥测数据,遥测数据以及有关业务流程、应用程序和基础结构的洞察,以促进交叉关联。使用正确的工具,应支持每个应用程序和服务的基本监测方案,并跨不同应用程序启用指标和交叉关联。这将:

-- 不需要学习和维护多个完全不同的遥测解决方案,只需很少或没有开箱即用的集成。

-- 向工程和业务团队通用实践,以改善服务、基础架构和业务流程的运行状况。

2:现代软件工程愿景

微软的数字化转型要求CSEO以更高的速度、更高的质量、可靠性和安全性来功能和解决方案。CSEO正在对构建、部署和服务的方式进行现代化,以尽可能快地将新功能交到用户手中。CSEO正在重新工程流程的每个部分,并以微软首席执行官萨蒂亚·纳德拉(Satya Nadella)所概括的方式建立现代软件工程实践:“为了向我们的客户移动优先、云优先的体验,我们将实现工程流程现代化—痴迷于客户、数据驱动、速度导向、注重质量。”

为了确保工程师以客户为先、为中心,CSEO通过使用通用工具收集反馈,从而使微软工程师对客户体验有深刻了解。CSEO正在与遥测技术结合使用和查看此反馈,这将有助于工程师们了解用户如何使用产品以及可能出现的问题。CSEO希望实施更高保真度的服务和业务流程监测,以便在客户甚至意识到问题之前就对问题发出警报并加以解决。CSEO希望使工程师能够可靠和安全的服务,并通过简化从提交代码到部署的过程、同时在软件构建和发布线中无缝集成合规性检查,来减少部署的前置时间。CSEO是微软商业产品的第一批客户,这使CSEO能够识别并满足在以云为中心架构中的企业的软件工程需求。CSEO与微软的产品工程团队不断合作,创造了一个良性循环,使微软的产品(例如Azure DevOps和Azure服务)更加适合企业使用。

CSEO建立了一种文化,以支持现代软件工程实践和快速交付新功能,并且通过阶段性发布的方式,更快速地向客户交付经验证的新功能,以及通过紧密集成的反馈循环和定期发布来完善这些新功能,从而使微软业务能够更快地做出响应。

虽然提高速度对于数字化转型至关重要,但不能对可靠性产生负面影响。连续的数据收集、健康信号的监测、主动检测以及快速修复,这些对于确保减少停机时间并创造高质量的客户体验也至关重要。实施现代软件工程实践是一项长期的过程,需要对思维方式、文化和工具进行根本性的改变,包括:

-- 转向现代云架构;通过组件化整体应用程序来构建微服务;在中央存储库中发布 API、NuGet 和类似版本,以实现集成;确保超过90%的自动覆盖率;与其它团队合作,采用依赖关系并与他们的服务集成,而不是试图复制它。

-- 持续集成经过的代码,并且仅从代码的主分支进行部署。

-- 通过将产品保持在可发布的状态(releasable state)从固定节奏发布转变为持续集成/连续交付,并通过自动部署管道(pipeline)对故障做出快速响应和实现快速发布。

-- 使用环形部署模式(ring-deployment)进行生产环境的实验,而不要进行用户验收(UAT)并依赖于专用的UAT环境。

-- 积极已确认的技术债务并保留相应的工程资源,以能够在其产生计划外的工作或影响服务质量之前解决它。

2.1 投资现代软件工程

CSEO 建立了强大的基础,具备用于服务组合的通用工具和平台,并将这些数据与事件、遥测和常见指标仪表板(如事件运行状况和合规性仪表板)集成在一起,每月在 CSEO 全服务回顾中审核。此基础使CSEO能够通过着重于安全性和合规性等基本能力,进而从客户的角度实施更好的事件和服务健康,来推动改善CSEO服务总体体验的通用做法。在此基础上,CSEO对现代软件工程实践和技术的持续投资,反映了微软的愿景并支持微软的文化变革。CSEO投资的三个主要支柱是:痴迷客户、快速交付、软件工程生产力。

2.2 痴迷客户

CSEO致力于提高服务和LSI(live site incident)的效率。CSEO正在合并平台,推出标准的事件流程,并根据关键指标持续评估改进的情况。随着CSEO朝这个方向努力,CSEO对业务流程健康有了更好的理解,并正在扩展工具和流程以改善对业务流程运行状况的监测。业务流程可以涵盖从现代到传统再到第三方的多种服务和技术,例如从供应商处购买服务后有关该服务付款状态的透明度,这需要跨多个的集成和代理商的手动工作来支持该过程。CSEO正在通过对跨多个服务和技术的关键业务流程进行更深入的了解,从而在服务和业务健康状况之间架起一座桥梁。这使CSEO能够收集和聚合数据,以服务和流程健康的整体画面。CSEO正在积极主动地检测流程瓶颈,以帮助减少响应时间。CSEO正使用端到端流程监测,以将可见性扩展到单个服务之外,这确保了整个业务流程的有效运行。

2.3 使用遥测平台

CSEO使用的是基于Azure Monitor的统一遥测平台,该平台可帮助实现服务质量的持续改进。该平台与诸如Kusto、Azure Cosmos DB、Azure Application Insights和Log Analytics等异构数据源集成,以收集、处理和发布来自应用程序、基础结构和业务流程的数据。统一的遥测平台可帮助获取端到端视图,并生成有关CSEO的可行动的见解,还能通过常见的可视化来更好地检查原始数据和Application Insights数据,以用于确定团队、Live Site、以及服务评论的相关性。CSEO正致力于交付高度相关的洞察,用以聚合组件服务、客户体验和业务流程的健康状况。这将产生上下文数据,这些数据不仅可识别事件,还可识别根本原因和建议的下一步操作。CSEO正在使用业务流程监视(BPM)通过跟踪多个服务和业务组的成功交易和客户影响来监测真实可用性和性能。

增强了数据支撑的工单,将根据对业务影响程序而优先排序的问题视图并补充潜在原因,包括通过机器学习判断原因和评估严重性、对给定事件分配更智能的变更,以及类似情况归因。这些数据增强的工单,让团队可以专注于最重要的工单并减少解决问题的时间。

CSEO正在将综合监测集成到统一的遥测平台管道(pipleline)中,以帮助服务工程师可视化和跟踪服务的性能、减少检测问题所需的时间,并查明中的瓶颈。为了达到可持续的质量水平,CSEO对所有关键服务,尤其是业务交易量相对较低的那些服务,进行综合监测。为了满足CSEO中那些孤立的和异构解决方案的需求,CSEO使用综合监测来第三方应用程序的新功能和性能,并无缝处理各种身份验证协议,包括Microsoft Azure中的平台即服务(PaaS)组件、公司防火墙连接和多重身份验证。CSEO正在构建平台,以启用负载、压力和可用性的机制,并门户和 API,使 CSEO 团队能够加入并其配置。

2.4 服务健康报告

CSEO在监测整个组织的服务运行状况指标和关键绩效指标(KPI)以了解客户的情绪并确保服务可靠、合规以及表现良好。CSEO在使用一致的标准,这有助于确保在服务层次结构中的任何级别聚合数据,并在不同团队组之间进行比较。监测和报告服务健康状况需要登录和集成CSEO统一的遥测平台、自定义维度和基于Power BI构建的服务健康状况仪表板。CSEO在Azure Monitor的基础上构建更集成的体验,并通过统一遥测平台丰富的上下文数据,并创建一组被定义的服务运行状况衡量指标和分析器,以跟踪可能影响服务可靠性的事件,例如即将进行的计划性维护或与更改合规相关变动。这使CSEO能够主动、快速地检测和解决问题。CSEO定义的服务健康措施,可以更轻松地跨各种技术启用服务健康报告,包括Application Insights、自定义服务监视和第三方服务。

CSEO必须将服务健康状况与业务流程健康状况起来,并确定问题的优先顺序,以便工程师能够以减少业务负面影响的方式解决这些问题。CSEO积累的经验包括端到端业务流程运行状况的可视化,以及通过分析遥测数据来检查业务流程底层服务的运行状况。CSEO正在模板化业务流程监测的可视化,并且正在扩展这些模板以简化其它相关指标的可视化。

CSEO还简化了面向工程师的服务健康和工程基础数据流,并减少使用的仪表板和工具的数量。CSEO正在使用内部工具作为所有服务负责人的关键存储库,以查看服务运行状况和其它相关KPI。该工具的集成工作流程会在服务达到定义的阈值时服务负责人,从而可以更方便地将任何需要的补救工作按优先顺序排入重点待办列表(backlog)中。

2.5 拥抱Live Site文化

2.6 利用客户反馈来推动发展

CSEO通过反馈回路机制将客户体验放在软件工程流程的中心。反馈循环可作为由假设驱动的产品改进的基础,这种改进方式基于实际的情绪和使用数据。通过使用与Microsoft Office产品套件相同的工具,CSEO使反馈提交尽可能容易。“发送微笑”功能可跨多个渠道和关键用户接触点自动收集反馈。CSEO还将此工具用作集中式数据,用于存储、分审和分析反馈,将其聚合到可操作的洞察中。CSEO最佳实践、培训和工具,以帮助工程师理解这些反馈,并鼓励采用反馈循环和实验方法,例如功能发布(flighting)和环形周期部署,帮助衡量产品变更的影响。有了这些基本组件,CSEO探索将反馈数据与相关遥测相关联的方法,以便可以更好地了解产品可用性问题以及服务问题对客户的影响。CSEO还使用受控部署来消除对UAT环境的需求,不过这会降低整体交付速度。

2.7 快速交付

为了痴迷于客户,CSEO在各个方面都获得并保护了客户的信任。但要推动这一目标,CSEO的主要重点必须是服务质量。CSEO在跟踪交付指标,以便在确保服务可靠性的同时,缩短从吸收客户需求到可用性和反馈的交付周期。CSEO正在通过检查交付管道(pipeline)中较早的问题并一种快速进行实验并降低风险的方法,来帮助工程师实现这一目标。CSEO正在构建反馈循环机制,以确保能够在部署新功能时理解用户体验,并且如果客户反应或服务运行状况信号不如预期的那么好,将执行自动回滚。

为了痴迷于客户,CSEO还必须高质量的服务。CSEO缩短了从收到客户要求到解决方案交付到客户手中的准备时间。缩短交付周期,使得CSEO能够在安全、兼容、可访问、可靠和高质量服务的同时,和接收反馈,这对于建立与客户的信任至关重要。CSEO工程师不断检查管道中较早的问题,从而能够快速进行试验,同时降低了发布过程的潜在负面影响。

2.8 集成安全性、可访问性和基础

CSEO提倡“左移”过程,其中的工作应尽早在过程中进行。这使CSEO避免了冲刺和冲刺之间的技术债务负担。CSEO还在人员工作流程中部署了“闸门”以简化的方式建立安全性并通过静态和动态安全性工具自动服务,以确保持续合规性。CSEO将在扫描过程中发现的bug记录在Azure DevOps中,以便人员可以在那里直接修复它们,而不必首先从安全工具中进行分类。此外,CSEO计划应用机器学习功能,以便实时发现这些错误,并在构建时立即采取措施。这使人员可以使用与功能错误相同的工程进行分类、划分优先级和跟踪。

CSEO有一个独立的供应商,负责评估应用程序中的可访问性,但这在过程的后期发生。为了进一步向上游推进,CSEO推动在过程中采用可接入洞察工具,并将公开与可接入功能相关的 Bug 作为管道工作流的一部分。

此外,CSEO通过将基础设施集成到任务管道中,使工程团队能够利用正在部署的防护,并且正在推广持续集成的实践,以便所有生产环境中的版本(包括热修复程序)均来自主版本并持续应用所有适用的合规步骤。每个发布请求都必须具有成功的构建,以确保主版本处于可用状态,并且始终可以为进入生产环境而做好准备。在主版本中维护高质量代码将最大程度地减少构建失败,从而最终降低投入生产的时间。

2.9 安全地部署到客户

CSEO在创建一个环境,使团队在构建想法和原型之前先对其进行,并且CSEO实际上专注于以一种快速失败、安全失败的思维方式来鼓励客户接受有风险的创新。CSEO提高对速度的关键,是以一种一致、精简且流程化方式向客户安全部署。增量式暴露和性能是通过受控部署向用户部署新功能的关键,CSEO可以迅速开始接收客户反馈。CSEO通过利用服务指标(例如交付流水线中的等待时间和故障)在流程中进行检查和平衡,从而捕获性能下降并在超过预定义的阈值时启动自动回滚。实现安全的部署实践,结合精简和良好的管道,是实现持续集成、持续部署(CI/CD)模型的两个关键元素。

2.10 启用代码重用

虽然数量很少,在CSEO的服务中不到5%,但CSEO仍在支持使用本地和加入域的Azure虚拟机的应用程序。这导致需要不断修补、升级软件并执行基本的基础设施维护任务。这也阻碍了CSEO扩展应用程序以适应增长的能力。CSEO将继续进行投资,以将这些应用程序转换为基于Microsoft Azure平台即服务(PaaS)和基于软件即服务(SaaS)的解决方案,从而利用Azure的规模和可用性。CSEO通过体系结构指南和工具以实现该目标,包括迁移数据、将现有功能重构为API,并通过重用他人已经发布的API来构建轻量级应用程序等。

促进数据和代码重用以更快地构建解决方案并与面向服务的体系结构保持一致,这要求人员可以轻松地发布和发现API。CSEO通过创建一套通用的一致性API准则以及一个用于发现的中央目录和搜索体验,来构建API经济。CSEO正在根据API准则集成验证,并使团队能够将API发布集成到Azure DevOps管道中,并且正在定义并一组常见的API运行状况分析。CSEO还将继续致力于实现“内源”式增长的实践,来实现API外部代码的共享。这将帮助将现代软件工程实践扩展到微软内部的其它组织,在这些组织中业务主导的工程或“影子IT”正在出现。

3:工程生产力

CSEO正在基于最新的Azure工具(例如Azure DevOps)在通用工程中为工程师一流的统一标准和实践。一致的环境使CSEO工程师可以在项目和团队之间平稳过渡。改进的自动化、一致性和集中式工程,使软件工程师能够更好地专注于的核心角色。这也减少了入职培训的时间,并使CSEO工程师在整个项目中更加灵活。

3.1 提高一致性

CSEO正在创建和支持标准,以规范CSEO组织实践,同时继续让团队在这些边界内进行自我。这有助于确保CSEO拥有更精简的团队和更高效的工程师。这些标准包括使用以下内容:

-- Azure DevOps中常见的工作项分类和路径结构。通过标准化工作项分类和区域以及迭代的路径结构,CSEO允许工程师通过一致的机制将每个团队的工作与CSEO目标和优先级起来,从而专注于工程。CSEO正在促进从Azure DevOps进行CSEO范围的查询,以可交付成果,例如合规性、可访问性和交付计划。

-- 生产环境的命名标准。拥有针对不同环境(、生产和类似环境)的标准命名约定,将使它们易于区分,并允许整个组织中基于特定于环境的策略自动化。

-- Azure DevOps的标准了一种用于标记相关项目的轻量级方法。为此,CSEO创建一组有限的并补交化,这些与常见迭代路径结合使用,从而一种跟踪一段时间内完成进度的简便方法。

3.2 集成人员工具

3.3 轻松发现资源

CSEO不断与工程师核实工程运行状况,并针对其它微软产品组进行基准。调查反馈表明,寻找与工程相关的资产一直是一项。CSEO正在努力地以简单可靠的方式共享功能并减少冗余设计。CSEO希望可以在一个中心位置轻松找到最佳实践,这将有助于工程师从汇报的角度了解需要使用的端到端流程和工具,以保持应用程序正常运行。CSEO通过投资来应对许多此类机会,例如建立API经济、扩展服务运行状况,以及为服务运行状况数据部署通用报告工具。此外,CSEO正在建立一种机制来和维护端到端的软件工程流程文档,并定义一种在组织内发布、维护和发现软件工程最佳实践的方法;影子IT组织也可以使用它。

3.4 通用设计

CSEO正在利用微软的产品设计,来设计外观及功能与其它微软产品一样的解决方案。CSEO希望能够满足当今消费者对产品质量的期望,这意味着应该对每个用户界面(UI)和用户体验(UX)进行设计,使其具有可访问性、响应能力以及熟悉的行为、状态、运动和视觉造型。在复杂但通用的组件(例如标题、导航菜单和数据网格)上,这可能意味着每个需要相同组件的CSEO团队的工程时间将成倍增加。为此,CSEO正在投资:

-- 一致性和CSEO特定模式的最低要求:为了更好地使每位CSEO工程师都能有效地高质量的体验,CSEO正在一套高质量的共享UI组件和UI/ UX指南。为了为所有并满足可访问性要求,CSEO在指导和组件方面的重点是自适应Web /桌面(最小为320px)CSEO正在工程资源和指导,以达到一致性的最低要求,并争取在CSEO核心应用程序中100%采用该最低要求。

-- UI工程和可访问性效率:通过将基本的辅助功能构建到每个组件中,例如ARIA(可访问的富Internet应用程序)对比度和制表符顺序,CSEO使设计和实现一致的可访问产品变得更加容易。CSEO还将为每个组件辅助功能指南和最佳实践,目的是通过使用预构建的组件和样式来提高效率并减少工程工作量。

3.5 入职培训计划

使新聘人员了解CSEO的工程技术不仅很重要,这样能够具有良好的入职整合体验,而且对于确保CSEO文化变革势头也至关重要。由基础小组设计的为期三天的介绍课程可帮助新员工从高层次理解CSEO组织,有关CSEO文化、技术和现代工程实践的关键概念,其中包括为期两天的Azure培训。CSEO90天的自定进度的入职培训课程,以根据地理位置、职位和团队进行调整。此外,在首次入职培训之后的30天,CSEO将另一轮培训,以确保对CSEO组织的具体了解。补充培训还包括:

-- 项目经理和工程师日,用来突出并庆祝CSEO的转型进展。

-- 为项目经理开设的特殊课程,旨在教育新员工对CSEO项目经理的期望。

-- 敏捷培训,介绍敏捷Scrum并加深对敏捷概念的理解。

-- 建立交流和讲故事技能的沟通培训。CSEO正在试行“通过讲故事的影响力”培训课程,以帮助员工找到有说服力的关键信息,为利益相关者相关见解,并培养如何在即席对话中发挥影响力。

4. 结论

CSEO正在微软内部实现现代软件工程的愿景。CSEO正在倡导“Live Site优先”的文化,使用数据服务和业务流程运行状况的信号,来告知客户与新想法和新功能有关的快速迭代。CSEO通过转向“DevOps”模型来支持这一点:标准化流程和自动执行策略控制着持续集成和持续部署的过程。这种文化以及支持该文化的工具和活动,增加了对工程流程的可见性,提高了服务质量和交付水平,并提高了对客户体验的洞察力,所有这些确保了CSEO不断改进和调整服务范围,以便支持现在和将来的数字化转型过程。文/宁川

本文相关词条概念解析:

客户

中国古代户籍制度中的一类户口﹐与主户相对而言﹐泛指非土著的住户。它不是一个统一的阶级或阶层﹐其中包括有地主﹑自耕农﹑城市小商贩﹑无业游民。可以指用金钱或某种有价值的物品来换取接受财产、服务、产品或某种创意的自然人或公司。是商业服务或产品的采购者,他们可能是最终的消费者、代理人或供应链内的中间人。传统观念认为,客户和消费者是同一概念,两者的含义可以不加区分。但是对于企业来讲,客户和消费者应该是加以区分的。客户是针对某一特定细分市场而言的,他们的需求较集中;而消费者是针对个体而言的,他们的需求较分散。在市场学理论中,供应商必须在销售事前了解客户及其市市场的供求需要,否则事后的“硬销售”广告,只是一种资源的浪费。现代社会中,“顾客就是上帝”是企业界的流行口号。在客户服务中,有一种说法,“客户永远是对的”。不过各方有不同的演绎,也就是客户二字的不同定义。客户一词源于称呼习惯。一个顾客是常常光顾某店铺或主户的人,他时常光顾或买东西,与店主或主户维持良好关系。

网友评论

相关文章