深度好文

这篇文章是很久之前的一篇《回溯算法详解》的进阶版，之前那篇不够清楚，就不必看了，看这篇就行。把框架给你讲清楚，你会发现回溯算法问题都是一个套路。 废话不多说，直接上回溯算法框架。 解决一个回溯问题，实际上就是一个决策树的遍历过程 。你只需要思考 3 个问题： 1、路径：也就是已经做出的选择。 2、选择列表：也就是你当前可以做的选择。 3、结束条件：也就是到达决策树底层，无法再做选择的条件。 如果你不理解这三个词语的解释，没关系，我们后面会用「全排列」和「N 皇后问题」这两个经典的回溯算法问题来帮你理解这些词语是什么意思，现在你先留着印象。 代码方面，回溯算法的框架： result = [] def backtrack(路径, 选择列表): if 满足结束条件: result.add(路径) return for 选择 in 选择列表: 做选择 backtrack(路径, 选择列表) 撤销选择 其核心就是 for 循环里面的递归，在递归调用之前「做选择」，在递归调用之后「撤销选择」 ，特别简单。 什么叫做选择和撤销选择呢，这个框架的底层原理是什么呢？下面我们就通过「全排列」这个问题来解开之前的疑惑，详细探究一下其中的奥妙！ 一、全排列问题 我们在高中的时候就做过排列组合的数学题，我们也知道 n 个不重复的数，全排列共有 n! 个。 PS： 为了简单清晰起见

(深度好文)重构CMDB，避免运维之耻 CMDB，几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛，因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱。 那么到底错在哪儿了？该如何去重构它？ 今天我想从我的角度来和大家探讨一下业务失败的原因，基于失败再去看重构的逻辑，也许会成功。 从失败中寻找成功的逻辑，往往是最有效的，那我们就来逐一看看： 1、组织的设计问题 我必须把核心原因归结成这一条，很多公司把CMDB的建设责任放到基础设施建设部门，由他们主导承建。最后他们梳理出来的核心逻辑是面向基础设施资源的管理，你在他们的CMDB中都能看到如下菜单，AIX主机是哪些，中间件有哪些，大小机有哪些，Oracle有哪些等等，这些都是和公司的IT运维部门组织结构是一一对应的。组织的隔离是CMDB失败的核心原因！ 这个里面能看到一些CMDB管理能力错位，拿两个例子来说一下： A、中间件。 一直搞不明白为什么中间件要作为一个单独的对象来管理，“皮之不存，毛将附焉”。没有主机，没有业务这个皮，哪来的中间件。把他单独拿出来管理，纯粹就是为了满足组织的一个管理视角。从来没人想过，这是主机上的一个资源对象，应该是一个附属资源，其实对他的信息管理和机器上的CPU、网卡一样。 B、进程对象，比如说数据库 这个是另外一种管理错位，是专业的管理平台应该去履行的管理职责，结果放到CMDB平台中了