小张入职时是运维专员，原来隶属于运维部门，负责某业务线系统的应用维护工作。

一旦系统的生产环境出现任何故障，或者业务人员在生产环境上有任何请求，都是由小张所在的运维部门先处理，处理不了的，再联系该系统的开发团队一起处理。

由于生产环境关乎业务部门的业绩，每天收到的请求量也非常多，小张的压力很大，而且并不是每个故障或请求他都有能力或来得及处理;找开发团队，又会被开发团队说他只是把事情“左手交右手”，没有提供价值，小张很委屈也很为难。

他并没有参与系统的开发，而系统上线后的问题却需要他来应对，干着最苦最累的“背锅侠”的活，却没有什么掌声和成就感。

两年前，公司开始进行DevOps转型，把运维部门撤销了，小张“插队”到了业务线系统的原开发团队中。

公司希望借此让业务线的交付团队负责从开发到运维的整个链条，也让像小张这样的运维人员有机会参与到项目工作中，提升他们的技能和工作满意度。原来的开发人员也要参与运维，在开发中更多地考虑到生产环境运行的问题。

有重大问题时，整个团队都可以参与运维、解决问题。

但几个月后，小张发现他的具体工作并没有什么变化，生产环境的一切事务依然还是先派给他，由于这项工作已经占据了他所有的工作时间，他没有机会参与项目交付。

他感觉自己和团队里的开发人员是“同床异梦”，也没有机会拓展自己的能力。

小崔是持证DBA。原来隶属于独立的IT运维部门，该部门掌管着一切IT基础设施，如服务器、操作系统、数据库、中间件、网络以及相应的专家团队。

由于重要的权限都掌握在这些专家团队手上，业务线交付团队如果无法获得IT运维部门的支持，项目就进展不下去。当各业务线的项目需求越来越多时，IT运维部门就成了整个公司的瓶颈。

为了解决这个问题，公司开始将IT运维部门去中心化，部分领域专家“插队”到各业务线交付团队中，从而减少交付团队的对外依赖，实现“自给自足”。

小崔就是这波浪潮中的其中一员。被收编到交付部门后，他比过去更忙了。

由于DBA是比较专业的技能，多大的团队需要一个全职DBA成了一个问题。团队太小，拥有一个DBA响应力绝对没有问题，但是无法充分利用其时间;如果几个团队共享一个DBA，又会出现新的瓶颈问题。

小崔就是一个被几个交付团队“共享”的DBA，因为要疲于应付各交付团队的请求，他已经没有时间成长。

过去，由于DBA都集中在一起，他们之间可以频繁交流，相互学习，共同成长。而小崔现在收获到的只有孤独和压力。