上个月，我们开始分享微软的DevOps之旅，通过微软几个团队的故事，以及他们如何采用DevOps。作为本系列的下一个故事，我们想分享一个团队从传统的操作角色到站点可靠性工程（SRE）角色的转变：Xbox可靠性工程和运营（xREO）团队的故事。当微软决定通过云游戏流媒体（projectxcloud）将Xbox游戏带给任何地方的玩家时，这种转变并不容易，而且是出于必要。为了提供具有一流客户体验的尖端技术，团队必须重新定义其工作方式，改进与开发团队的协作，投资于自动化，并参与应用程序生命周期的早期阶段。在本博客中，我们将回顾团队在这一过程中收集到的一些重要经验教训。要了解整个团队的故事，请参阅xREO团队的旅程。一致的游戏要求和协作的需要一致的体验对于成功的游戏流媒体会话至关重要。为了确保游戏玩家体验到从云端流出的游戏，它必须让人感觉它是在附近的游戏机上运行的。这意味着要创建一个全球分布的云解决方案，在许多数据中心运行，接近最终用户。Azure的全球基础设施使这成为可能，但运行在众多Azure区域之上的系统是一个严峻的挑战。Xbox开发人员已经开始设计和构建这项技术，他们明白他们不可能仅仅构建这个系统，然后"把它扔到墙上"交给运营部门。这两个团队必须在整个应用程序生命周期中走到一起并进行协作，这样就可以从一开始就考虑如何在生产环境中操作系统来设计系统。在考虑操作的情况下构建云解决方案在许多大型组织中，开发和操作团队在筒仓中工作是很常见的。开发人员在规划和构建系统时并不总是考虑操作，而操作团队即使在生产中部署和操作代码，也无权接触代码。在整个生命周期中，系统的可靠性是整个系统的重要组成部分。在一种新的方法中，让xREO团队参与到设计阶段，可以形成一个协作的环境，做出联合技术选择，并构建一个可以满足扩展需求的系统。利用容器明确定义所有权开发团队和xREO团队共同做出的第一个技术决策是利用容器技术实现微服务体系结构。这使得开发团队可以将他们将拥有的.NET核心微服务封装起来，并从运行容器的云基础设施中移除依赖关系，该基础设施将由xREO团队拥有。两个团队早期做出的另一项技术决策是使用Kubernetes作为底层容器编排平台。这使得xREO团队能够利用azurekubernetes服务（AKS），这是一个托管Kubernetes云平台，简化了Kubernetes集群的部署，消除了团队在多个Azure区域运行多个集群时所面临的大量操作复杂性。这些共同选择明确了所有权——开发者负责容器内的一切，而xREO团队负责AKS集群，其他Azure服务则负责托管这些容器的云基础设施。每个团队拥有各自产品在生产中的部署、监控和操作。这种方法创建了明确的责任，并允许在生产中更容易地进行事件管理，这在基础设施和应用程序逻辑具有代码依赖性的单片体系结构中非常具有挑战性，当事情发生横向变化时很难解决。通过基础设施自动化进行扩展xREO团队投资的另一个最佳实践是基础设施自动化。在每个Azure区域上手动部署多个云服务是不可伸缩的，并且需要花费太多时间。使用一种称为"基础设施即代码"（IaC）的实践，团队使用azureresourcemanager模板来创建云环境的声明性定义，允许以最小的工作量部署到多个Azure区域。通过以代码形式管理基础设施，还可以使用持续集成和持续交付（CI/CD）来部署它，以进一步自动化将新的Azure资源部署到现有数据中心、更新基础设施定义或在需要时将新的Azure区域联机。IaC和CI/CD都允许团队保持精干，避免重复的日常工作，并消除了手动步骤带来的大部分人为错误风险。团队可以专注于进一步改进平台及其弹性，而不是花时间在手工工作和检查清单上。现场可靠性工程xREO团队的旅程始于为玩家带来最佳客户体验的需要。这是一个很好的例子，它展示了那些想要通过尖端的创新来取悦客户的团队，他们必须改进他们设计、构建和操作软件的方式。改变他们的操作方法并与开发团队更紧密地合作是xREO团队经历的真正转变。有了这种新的思维方式，团队现在可以继续构建更具弹性的系统，并进一步扩展系统，从而将云游戏流的承诺传递给每个玩家。资源xREO团队的全部故事其他故事：微软的DevOps之旅Microsoft游戏栈