运维管理体系
运维的目标
1.稳定性保障
2.提高人效
3.提高资源利用率,降低成本
运维的定位
1.运维是支撑团队 合作是主旋律
7.有了CMDB,为什么还需要应用配置管理
CMDB 是面向资源的管理,应用配置是面向应用的管理
1.CMDB 是面向资源的管理,是运维的基石
传统SA建设运维的基础管理平台做的事情(备注:面向应用运维的角度做这些不够哦.....)
第1步:把服务器、网络、IDC、机柜等这几大维度先定下来;
第2步:把这些硬件的属性确定下来,比如服务器就会有 SN 序列号、IP 地址、厂商、 CPU、内存、硬盘、网卡等等;网络设备如交换机也会有厂商、型号、带宽等等;
第3步:梳理以上信息之间的关联关系,或者叫拓扑关系。比如服务器所在机柜,虚拟机所在的宿主机、机柜所在 IDC,复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系;
备注:在上面信息的梳理过程中肯定就会遇到一些规划问题,比如,
- IP地址段的规划:哪个网段用于 DB,哪个网段用于大数据、哪个网段用于业务应用等
- 机柜分配规划:哪些机柜用于做虚拟化宿主机、哪些机柜只放 DB 机器等
以上信息梳理清楚,通过 ER 建模工具进行数据建模,再将以上的信息固化到 DB中,一个资源层面的信息管理平台就基本成型了。但是,信息固化不是目的,也没有价值,只有信息动态流转起来才有价值。接下来我们可以做的事情:
第 4 步:基于这些信息进行流程规范的建设,比如服务器的上线、下线、维修、装机等流程。同时,流程过程中状态的变更要同步管理起来;
第 5 步:拓扑关系的可视化和动态展示,比如交换机与服务器之间的级联关系、状态(正常 or 故障)的展示等,这样可以很直观地关注到资源节点的状态。
如下图
2.应用配置管理是面向应用的管理,是运维的核心
面向应用,则需要应用名或者应用标识,结合上面的,应用名<---> IP 的关联关系就可以建立,当然也可以是其他唯一主机标识,如InstanceId、主机名、容器ID等
抽象除两个重要的概念:1.应用名 2.应用名和IP的关联关系,如果不和应用关联,影响力就仅仅在运维内部,但是和应用关联后就会影响整个业务架构---> 技术架构---> 研发组织架构,以及其他的平台和系统建设,都和这两个概念相关。
CMDB---> IP ---> 资源管理(如上图)
CMDB---> 应用---> 应用管理,应该管理设计如下信息:
1.应用的基础信息:研发负责人、测试负责人、运维负责人、Git地址
2.部署涉及的软件包:语言包(Java、C++、GO 等)、Web 容器(Tomcat、JBoss 等)、Web 服务器(Apache、Nginx 等)、基础组件(各种 agent,如日志、监控、系统维护类的 tsar 等)
3.应用部署涉及的目录:如运维脚本目录、日志目录、应用包目录、临时目录等
4.应用运行涉及的各项脚本和命令,如启停脚本、健康监测脚本
5.应用运行时的参数配置,如 Java 的 jvm 参数,特别重要的是 GC 方式、新生代、老生代、永生代的堆内存大小配置等
6.应用运行的端口号
7.应用日志的输出规范
8.其他。
这个梳理过程其实也是标准化的过程,上面梳理的应用相关的信息和CMDB里的资源信息是两个维度的信息,从信息管理角度来看,资源配置和应用配置解耦后会更清晰更容易管理。
上面的信息建模和固化后,下一步就是建设基于应用配置管理的流程规范(如流程中心-机器申请流程) 和 工具平台。
应用配置管理
资源配置 & 应用配置结合
效果:
1.应用名----关联--- 应用配置信息
2.IP -------关联---资源信息
1 和 2 通过【应用名-IP】的对应关系,联系到一起。
3.以上二者结合的价值
基于 应用 + 资源配置管理,后面可以做很多对业务有价值的事情,如:持续集成和发布、持续交付(如流程中心-服务发布流程&一键扩缩容流程)、弹性扩缩容、稳定性平台、成本控制等等。
8.如何在CMDB中落地应用的概念
1.如何有效的组织和管理应用(微服务)
组织成一个树形的层次结构:命名方式统一、层次结构统一
业务架构拆分:按业务维度进行拆分:电商、支付、广告,电商又包含:用户、商家、商品,商品又包含:详情、库存、评价等。
业务架构-----决定----->技术架构-------决定----->研发团队组织架构(每个小团队负责不同业务的开发和实现)
产品线waimai
业务团队C端
应用1-下单
prod
机器资源....
stag
机器资源....
test
机器资源....
dev
机器资源....
应用2-提单
prod
stag
test
dev
上面的prod、stag、test、dev属于应用的集群服务【分组建设】,当然也可以不按环境区分,比如按IDC区分,或者按服务场景区分,如:秒杀、非秒杀
应用名设定规范:
- 应用名必须以小写英文字母、数字以及下划线组合,不能以数字开头;
- 应用名长度不超过 40 个字符,尽量简单易懂;
- 不允许出现机房代号和主机名称这样的信息。
2.CMDB在基础服务体系中的核心位置
CMDB = 面向资源(ECS + RDS + Redis + MQ) + 应用
以上的应用-分组-资源的对应关系,对于周边系统都是需要的,包括但不限于如下
1.监控系统
如:只监控prod环境的机器和RDS/Redis实例资源
2.发布系统
代码编译打包发布到指定应用对应环境的所有机器上,如:持续集成、持续交付、弹性扩缩容等,另外也可以和成本控制等结合。
3.服务化框架
比如配置中心、注册中心、4层7层负载均衡、ZK等,依赖应用名(应用)+环境(集群分组信息),管理应用名,如:meituan.waimai.c.order.prod
4.基础服务
DB、缓存、MQ和应用名关联,代表哪个应该使用了这个基础服务,
使用应用名的场景:
比如应用与NameServer的对应关系,应用与topic的对应关系,
使用应用名和资源对应关系的场景:
DB\MQ ACL授权的时候需要应用的某个集群分组(可以理解为环境)下的IP的对应关系。当然配置的实现方式有多种:比如在DB中间件 或者 DB 或者操作系统上通过iptables配置
5.稳定性保障平台(服务治理平台)
降级限流、开关预案都是和应用直接关联的,不同的集群分组(如环境)策略也可能不同,策略下发到最终的服务器上,又需要应用-集群分组-资源的对应关系。
基于以上5点,CMDB和周边系统的交互,如下图
以应用为核心的运维体系,如下图