云管平台管理的底层基础设施边界？
云管平台一定是有一个最适用的基础设施管理框架和边界的，是不是上了云管，就要想方设法把所有的基础设施都丢进去，好实现大一统管理？还是要讲究策略，精挑细选，设置准入门槛呢？
实在不想把云管平台做成一个大杂烩。
2同行回答
这个问题其实不是边界问题，是云管平台的服务目录到底是给谁做的问题。云管平台如果是面向基础设施管理员，那么就是为基础设施操作人员精简操作、减少重复操作等内容，因此这时云管平台就是成为集合各种云资源池的操作上的抽线和提炼；
如果云管平台是面向业务运维人员，那么就不得不考虑梳理业务-应用服务-资源关系，并且还要站在业务运维人员的使用场景去抽线和提炼服务内容，基础设施层的内容就相当于是消费品，其它权限、端口、防火墙、资源配置、容量、基线版本、安全巩固等等一系列基础设施上要操作的内容，业务运维人员全然不关注。但是这些仍然是需要对应的服务平台去整合统一集中，这就将云管平台服务侧（专门面向资源admin）来提供服务和操作的。
个人经验是说，云管平台首先适应输出什么内容，一定是面向谁来说。不至于跑去政府部门去报案——找错衙门发生。一定是先定位使用者，然后将使用者的用户场景进行分析和整合、剖析抽象和提炼成服务目录，然后再形成需求、开发去实现。
比如代码管理和业务应用服务自动化发布，到底该不该入云管平台，从资源交付来看，确实不应该，因为这是完全业务应用服务的事儿，资源平台完全不关注。但是若使用者就是业务应用服务运维人员，那他们就是关注代码、自动化编译和发布到指定的服务器上，并启动服务（这些场景是使用者的日常操作场景），自然就要考虑如何纳管这些代码管理、业务应用服务自动化发布等。
平台首先不能先设条件和门槛，应该是先找准用户群体，这样的平台才有生命力，有用户的平台，一定可以获得持续反馈并升级改造，平台自然就逐步提炼成了服务平台。