赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5576 人已学习
课程目录
已完结 48 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位？
02 | 微服务架构时代，运维体系建设为什么要以“应用”为核心？
03 | 标准化体系建设（上）：如何建立应用标准化体系和模型？
04 | 标准化体系建设（下）：如何建立基础架构标准化及服务化体系？
05 | 如何从生命周期的视角看待应用运维体系建设？
06 | 聊聊CMDB的前世今生
07 | 有了CMDB，为什么还需要应用配置管理？
08 | 如何在CMDB中落地应用的概念？
09 | 如何打造运维组织架构？
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起，运维如何培养服务意识？
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难，想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点：配置管理
14 | 如何做好持续交付中的多环境配置管理？
15 | 开发和测试争抢环境？是时候进行多环境建设了
16 | 线上环境建设，要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则，聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗？有哪些关键问题？
19 | 持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障
20 | 做持续交付概念重要还是场景重要？看“笨办法”如何找到最佳方案
21 | 极端业务场景下，我们应该如何做好稳定性保障？
22 | 稳定性实践：容量规划之业务场景分析
23 | 稳定性实践：容量规划之压测系统建设
24 | 稳定性实践：限流降级
25 | 稳定性实践：开关和预案
26 | 稳定性实践：全链路跟踪系统，技术运营能力的体现
27 | 故障管理：谈谈我对故障的理解
28 | 故障管理：故障定级和定责
29 | 故障管理：鼓励做事，而不是处罚错误
30 | 故障管理：故障应急和故障复盘
31 | 唇亡齿寒，运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云？是被动选择还是主动出击？
33 | 为什么混合云是未来云计算的主流形态？
34 | Spring Cloud：面向应用层的云架构解决方案
35 | 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设
37 | 云计算时代，我们所说的弹性伸缩，弹的到底是什么？
个人成长 (5讲)
38 | 我是如何走上运维岗位的？
39 | 云计算和AI时代，运维应该如何做好转型？
40 | 运维需要懂产品和运营吗？
41 | 冷静下来想想，员工离职这事真能“防得住”吗？
42 | 树立个人品牌意识：从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点：赵成的运维体系管理课精华（一）
划重点：赵成的运维体系管理课精华（二）
划重点：赵成的运维体系管理课精华（三）
新书 |《进化：运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程，多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册
08 | 如何在CMDB中落地应用的概念？
赵成 2018-01-07
我们前面讲了应用是整个微服务架构体系下运维的核心，而 CMDB 又是整个运维平台的基石。今天我就讲讲在 CMDB 中如何落地应用这个核心概念，以及如何建立应用集群分组的思路。
如何有效组织和管理应用
微服务架构下会有很多应用产生出来，少则十几、几十个，多则上百甚至上千个。这时我们面临的第一个问题就是如何有效地组织和管理这些应用，而不是让它们在各处散乱，命名方式和层次结构可能还不统一。
你可能接触过“服务树”的概念，这个提法是小米在早期互联网运维实践的分享中传播出来的。我第一次听到这个概念是在 13 年阿里技术嘉年华大会上听小米运维的分享。再往前，这个概念应该是从百度的运维体系中借鉴出来的。
这里的服务实际对应的就是我们前面提到的应用这个概念。据我了解，在阿里和腾讯都是叫作应用，现在业界比较通用的叫法也是应用。其实叫什么并不重要，关键还是要学习到对这个概念的管理方式。
从服务树这个名字中，我们就可以了解到，有效组织和管理应用的方式，就是把它组织成一个树形的层次结构。这种管理模式，无论是在 BAT，还是在其它的互联网公司，基本都是一样的思路和模式，所以叫法虽然不同，但是思路上却是相通的，可谓异曲同工。
基于业务维度的拆分，对应产生了我们的应用拆分原则。比如对于电商公司，大的维度会有电商、支付、广告、流量和搜索等业务领域；进一步，电商业务领域里最典型的会有用户、会员、商品、交易、商家、店铺以及物流等；这里面还可以再进一步细分，比如商品会有详情、SKU、SPU、库存、评价、标签等。
讲到这里，我们再看一下技术团队的组织架构，基本上是对应着整个业务技术架构的拆分的。也就是业务架构决定了技术架构，而技术架构又决定了一个研发团队的组织架构，这个组织架构中不同的团队单元分别承担着对应业务的需求开发和实现职责。
上面这个组织架构建设的逻辑和思路，也是我们在组建团队和职责划分时可以参考的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(10)
赵成 置顶本文重点，应用集群如何管理？怎么分组？以及组织架构如何与技术架构相匹配？
欢迎大家讨论。2018-01-08 2
圣诞使者我想问下，cmdb需要体现应用的依赖关系吗？作者回复: 不需要，应用的依赖更多体现在服务调用层面，cmdb里面的应用粒度还是会比较粗。这一点后面会有文章讲到。
2018-01-10 1
宵伯特对于小的开发团队或者初创的开发团队可能在基础设施架构的管理上并没有过多的资源，而更偏向于使用云端的设施或架构，甚至如serverless之类的计算服务。这方面的运维管理会有较大的差异或者模式上的差别吗？作者回复: 体量不同，管理方式和采用的技术手段必然不一样，就跟数据量大的表和量小的表，查询方式和索引方式一定是不一样的。
量不大的时候可以怎么快怎么来，即使没有运维，问题也不大，但是要有意识，如果业务量开始快速增长了，就要有规划和设计了。2018-01-09 1
kevinsu如果业务大多是在云上呢？是否只是需要针对公司的特定需求来做即可？比如代码发布系统等等小系统，而不是去整合成一个大的系统？2019-05-16
老牛云环境下，因为存在弹性的扩容缩容，这样应用对应的资源（物理设备）是不是不固定的？那么怎么保持这种对应关系呢？2018-12-15
张sir你好，文中提到 “应用-集群服务分组-资源”，请问下你们做服务化，应用是最小的服务单元吗？还是应用下的集群分组？这样做有何用意及价值？
我们这边是 “模块-应用-资源”，模块是一个独立的子系统，应用是最新单元，资源就是这个应用所有环境的机器了，比如测试，预发，线上。整体都是基于服务树的理念2018-06-26
james应用所在容器不固定如何处理关系呢，比如弹性扩容所容以及应用down了重新启动一个docker镜像作者回复: 应用跟运行载体不一定是ip，容器id或者pod的对应关系也可以
2018-03-26
刘斌之前看过您的文章提过“应用层的CMDB”，我感觉基础设施层CMDB不会涉及应用，还是以服务器为中心。应用所在的机器（及依赖的缓存、队列等），是在应用层的CMDB？作者回复: 其实不用纠结做在哪里，关键是要看解决什么问题，怎么解决问题，cmdb只是一个概念而已。
2018-01-24
casper2ddcmdb提供API或者命令 用来查询应用 资源的信息 当cmdb信息有变化的时候 其他平台通过API或者命令 同步最新的信息作者回复: 量大的话可以通过消息方式处理变更
2018-01-16
天舟框架已经搭好，接下来就期待博主能讨论一个具体的实施方法了，比如说是纯粹基于name还是引入了tag，比如相关的组策略等等作者回复: Tag模式适用于场景更复杂，体量更大的情况下，这种情况需要更为灵活的查询和分类，我建议体量不大的话尽量简化设计。我们自己就当前情况，一直是通过相对固定的分组模式来管理。
2018-01-09
收起评论