赵成 置顶2018-01-08本文重点，应用集群如何管理？怎么分组？以及组织架构如何与技术架构相匹配？
欢迎大家讨论。 2
2018-01-10我想问下，cmdb需要体现应用的依赖关系吗？作者回复: 不需要，应用的依赖更多体现在服务调用层面，cmdb里面的应用粒度还是会比较粗。这一点后面会有文章讲到。
1
2018-01-09对于小的开发团队或者初创的开发团队可能在基础设施架构的管理上并没有过多的资源，而更偏向于使用云端的设施或架构，甚至如serverless之类的计算服务。这方面的运维管理会有较大的差异或者模式上的差别吗？作者回复: 体量不同，管理方式和采用的技术手段必然不一样，就跟数据量大的表和量小的表，查询方式和索引方式一定是不一样的。
量不大的时候可以怎么快怎么来，即使没有运维，问题也不大，但是要有意识，如果业务量开始快速增长了，就要有规划和设计了。 1
2019-05-16如果业务大多是在云上呢？是否只是需要针对公司的特定需求来做即可？比如代码发布系统等等小系统，而不是去整合成一个大的系统？
2018-12-15云环境下，因为存在弹性的扩容缩容，这样应用对应的资源（物理设备）是不是不固定的？那么怎么保持这种对应关系呢？
2018-06-26你好，文中提到 “应用-集群服务分组-资源”，请问下你们做服务化，应用是最小的服务单元吗？还是应用下的集群分组？这样做有何用意及价值？
我们这边是 “模块-应用-资源”，模块是一个独立的子系统，应用是最新单元，资源就是这个应用所有环境的机器了，比如测试，预发，线上。整体都是基于服务树的理念
2018-03-26应用所在容器不固定如何处理关系呢，比如弹性扩容所容以及应用down了重新启动一个docker镜像作者回复: 应用跟运行载体不一定是ip，容器id或者pod的对应关系也可以
2018-01-24之前看过您的文章提过“应用层的CMDB”，我感觉基础设施层CMDB不会涉及应用，还是以服务器为中心。应用所在的机器（及依赖的缓存、队列等），是在应用层的CMDB？作者回复: 其实不用纠结做在哪里，关键是要看解决什么问题，怎么解决问题，cmdb只是一个概念而已。
2018-01-16cmdb提供API或者命令 用来查询应用 资源的信息 当cmdb信息有变化的时候 其他平台通过API或者命令 同步最新的信息作者回复: 量大的话可以通过消息方式处理变更
2018-01-09框架已经搭好，接下来就期待博主能讨论一个具体的实施方法了，比如说是纯粹基于name还是引入了tag，比如相关的组策略等等作者回复: Tag模式适用于场景更复杂，体量更大的情况下，这种情况需要更为灵活的查询和分类，我建议体量不大的话尽量简化设计。我们自己就当前情况，一直是通过相对固定的分组模式来管理。