这是关于企业DevOps系列博客的第七篇。该系列由DevOps从业者Nigel Willie和首席执行官Sacha Laboury共同撰写，云蜂。希望如此，你们大多数人都读过凤凰计划。如果没有，我们强烈推荐。（这实际上是所有CloudBees新员工必读的书。）那些曾经这样做过的人，会意识到作者所经历的关键问题之一是对关键技术专家布伦特的严重依赖，布伦特解决了每个人的问题。书中清楚地表明，布伦特，尽管他是有能力，是一个僵局，因为一切都通过一个人。任何集中化的团队都会带来这种风险。这是一个基本的反对意见，许多人提出了一个中央DevOps团队或职能的想法。我们承认这是一个合理的关切。我们上一篇关于创建服务热线建议了一些潜在的方法。无论结构或结构如何，您都必须选择避免成为进度瓶颈的关键。在大型企业中，这可能非常困难，因为DevOps计划往往是引人注目的旗舰计划。因此，高级利益相关者非常渴望展示快速的进展。当然，这是一个比客户冷漠更值得面对的问题！当你试着保存很多盘子的时候，提醒自己一些事情是值得的纺纱。很多供应商现在以服务的形式提供功能。例如，车险返现，CloudBees-Jenkins Enterprise提供了一个交付框架，它将集中控制和一致性与客户自助服务相结合。以更灵活的方式分解以前的基于大师的项目，或者更灵活的团队来分解基于大师的架构。所有这些都支持在更大范围内推行自助服务方式企业。是否使用外部或内部能力，我们建议您优先考虑客户自助服务作为核心能力。要实现这一点，需要完成一些基础工作：通过API公开服务、集成到端到端流的定义模式、具有拖放功能的模板化管道，等等，今天许多大型企业采用矩阵式组织结构。我们不打算在这些文章中讨论各种组织结构的优点，但是，我们将为在这种类型的组织中工作的任何人提供具体的建议。任何服务都需要维护和升级。这可能会导致短时间的服务中断。根据经验，如果一个服务是在组织内的业务流之间共享的，大数据的趋势，淘客qq群，那么就中断达成协议可能需要进行重要的协商。相信你的个人优先权是人类的本性。在矩阵式组织中，跨业务流的优先级需要一致同意。在构建任何服务时，除了通常的考虑因素（可用性、可伸缩性、服务延迟等），在将使用者分配到服务器、主机、可用性区域、LPAR时，还需要考虑这个因素，等等很短，提供集中化功能时的关键考虑事项应是：您的客户可以在任何可能的情况下实现其所需功能的自助服务。任何服务都应尽可能考虑通过客户进行细分，以帮助围绕停机进行优先级讨论。一旦建立了基础，您的重点应该是客户体验和易于接受。任何中央IT团队的作用是使其客户能够通过完全支持的、一致的自动化能力快速交付。将依赖性强加于一组个人。跟着来自Sacha和nigerenterprise DevOps的Enterprise DevOps博客系列：简介Enterprise DevOps：我不会从这里开始：理解您的DevOps起点Enterprise DevOps：上下文是KingEnterprise DevOps:创建服务线Enterprise DevOps:论治理企业DevOps:脊椎是关键企业DevOps:转移到自助服务企业DevOps:朱迪亚人民阵线，还是不要为小东西操心企业DevOps:有意义度量的13个原则，5118大数据，第1部分企业DevOps:4度量的进一步考虑，第2部分Sacha Labourysacha是瑞士人，1999年毕业于EPFL。在EPFL期间，他开始了他的第一个咨询业务-Cogito Informatique。2001年，他作为核心贡献者加入了marcfleury的JBoss项目，并实现了JBoss最初的集群特性。Sacha后来成为JBoss欧洲公司的总经理，领导该战略并帮助招募合作伙伴，推动了该公司在该地区的发展。2005年，他被任命为首席技术官，负责监管所有JBoss工程设计部2006年6月，JBoss被Red Hat收购(纽约证券交易所：RHT). 作为首席技术官，Sacha在JBoss软件与redhat产品的集成和产品化方面发挥了关键作用。2007年，Sacha成为Red Hat中间件部门的联合总经理。他于2009年离开红帽公司，永久免费的云服务器，并于2010年3月创立了CloudBees。在Twitter上关注Sacha。