运维系统之松耦合设计

工作以来,一直坚信”平台化、易复用”的设计理念。在阿里、小米,先后见识了不少运维子系统,多多少少都和业务耦合、被业务所累,几乎找不到一个可以轻松移植的子系统。本文尝试提出一种松耦合的运维系统设计思路,纯属个人YY、当前没有实践做支撑。

概述

为什么,要以松耦合的方式,构建运维体系呢?很简单,方便运维子系统的复用。最好能做到,运维子系统 可以轻易接入 不同公司的运维体系。

怎样,才能让运维系统,松耦合的发生关联呢?运维系统,包含众多子系统,各子系统分别负责不同的运维业务。子系统之间往往”取长补短”、相互依赖,如Deploy需要CMDB的服务器信息才能完成部署业务、Monitor需要ACL才能完成数据的准入&准出等等。只要遵循统一的协议,子系统就可以享受其他子系统提供的服务;如果这个协议可以封装公司的业务属性,那么各子系统就可以蜕化成纯平台、进而可以跨公司复用——这正是本文的设计思路。

业务树

思来想去,业务树是最适合的协议平台。一方面,很多公司的运维体系以传统的服务树为核心展开,不同的子系统都挂载到服务树;服务树成为运维系统的统一portal(很多时候,我们把服务树当成CMDB的一种展示形态,略狭隘)。另一方面,以树状结构抽象公司的业务逻辑,已经证明是一条可行的道路。

定义

不妨下一个定义: 业务树,是公司业务的抽象,是统一的协议平台,是独立存在的实体,简写为BT。请注意,业务树是独立的实体,不是CMDB的”附庸”!!!

描述

一棵典型的BT,如下, business_tree.png

不同公司,BT的组织形式、描述方式不尽相同。一种可行的BT模型,为: 用字符串来命名BT的一个节点,再通过”字符串包含”运算来确定节点的父子关系。按照这种方式,上图中的BT可以描述为:

ID Name Comment
0 cop.tycs 公司,tycs
1 cop.tycs_owt.inf 团队,inf
2 cop.tycs_owt.inf_pdl.falcon 产品线,falcon
3 cop.tycs_owt.inf_pdl.falcon_service.dashboard 服务,dashboard
4 cop.tycs_owt.inf_pdl.falcon_service.gateway 服务,gateway
5 cop.tycs_owt.inf_pdl.falcon_service.gateway_job.gateway 作业,gateway
6 cop.tycs_owt.inf_pdl.falcon_service.gateway_job.gateway_cluster.aws-de 集群,aws-de

其中,cop.tycs是根节点,代表一个公司;节点cop.tycs_owt.inf代表公司下面的团队,是根节点cop.tycs的子节点,因为该节点”字符串包含”根节点。

接入

运维子系统接入BT,其实就是和BT的节点建立关联。这个关联,可以通过节点ID建立,也可以通过节点Name建立,各有优劣。

使用ID建立关联,优点为: ID在节点的生命周期内几乎不发生变化, 修改节点Name不影响关联关系;缺点为:ID是BT维护的逻辑信息,对于用户来说太抽象、不利于和用户端交互。使用Name建立关联则正好相反,容易受到节点Name变更的影响,但对用户更友好。鉴于,(1)BT节点Name变更不频繁 (2)需要提供友好的用户接口,我们选择,使用BT节点Name,与各运维子系统建立关联

运维子系统接入BT,关系描述如下。本文之描述了资产管理、权限、监控、部署这几个系统,接入BT的情况,其他子系统接入BT的情况 后续会逐渐完善。 bt.png

CMDB

CMDB接入BT的一个典型场景,就是将设备挂载到对应的业务线(BT节点)上。对应的,就是一条数据库记录,描述设备host_id和业务树节点bt_tag的对应关系。用户,可以查找某个业务线上的所有设备,可以查看某台设备属于哪些业务线。

ACL

权限系统ACL接入BT,本质上是利用BT的层级关系、实现权限的继承&覆盖等。一种典型的设计,见这里。最终,通过BT,用户 与 资源、操作发生关联。

CMDB和ACL属于基础服务,接入BT,是为了方便其他子系统使用CMDB和ACL提供的服务。

Monitor

监控系统Monitor接入BT,体现在两个方面。一方面,用户通过BT来配置监控策略,把指定的报警规则”绑定到”指定的BT节点。BT节点代表了一个业务线,关联了相应的监控数据,这样,用户就可以将特定的报警规则,应用到某业务线的监控数据上。另一方面,用户可以指定BT节点,来查看某业务线的历史数据。某个用户,可以在哪些业务线添加监控策略、可以查看哪些业务线的监控历史数据呢?这可以借助ACL实现。如,在ACL中加如下两条记录,用户A就可以在业务线cop.tycs_owt.inf_pdl.falcon添加监控策略&查看历史数据。

(1) 用户A,在BT节点cop.tycs_owt.inf_pdl.falcon,监控添加策略
(2) 用户A,在BT节点cop.tycs_owt.inf_pdl.falcon,监控查看历史数据

Deploy

部署系统Deploy接入BT后,一个典型的发布过程,可以描述为: 用户,在有权限(ACL)的业务线上,配置部署任务单;然后借助CMDB,筛选出目标服务器;最终发起上线部署。一旦Deploy接入BT,就可以享受CMDB、ACL等子系统提供的服务,多么美妙的一件事~

Init

初始化系统Init,是为了提高 初始化服务器环境 的效率 而设计的,装机上架、服务器重装时被使用。本文的Init系统,设计时遵循了如下前提:

  • (1)初始化的对象,是服务器
  • (2)初始化是”一组有序的操作”,可以通过”有序的执行一系列脚本”来实现
  • (3)一台服务器,只用于一个业务线;不同业务线,不共用服务器
  • (4)不同业务的服务器,初始化操作,有相同的基础操作、也有业务上的差异操作;先执行基础操作、后执行业务相关的操作

Init接入BT后,按照BT节点来组织初始化脚本,将通用基础操作的脚本列表 挂在高层父节点、将业务线独有的脚本列表 放在低层的子节点(越通用的操作,在BT上所处的层级越高),每个节点的脚本列表都是有序的。执行初始化操作时,根据用户填写的机器,查询到对应的BT节点(借助CMDB),对用户验权(借助ACL),然后从根节点向底层节点 依次执行BT节点上所挂载的脚本列表。

补充一句,节点挂载脚本的有序性,可以通过脚本的命名规范来解决,也可以由用户配置执行顺序。用规范来解决更好,”约定优于配置”。

结尾

未完待续。不同的运维子系统,会逐渐融入到本模型中。

敬请期待。



Prev     Next