资源生命周期管理

“学长，帮忙创建几台机器”，“学长，这几台机器的帮忙加下监控”，“学长，这几台机器可以下线了”，”学长…哎…哎…别跑 "…这就是运维工作的常态

看似杂乱无章的琐碎小事，实则万法归一，殊途同归:资源的生命周期管理 。没错，运维工作的本质就是资源的生命周期管理。所谓的资源正是你们所熟知的服务器、db、redis、s3 以及流量等计算资源、存储资源和流量资源，而生命周期则大致包含创建、部署、监控、扩容、下线等阶段

而资源生命周期管理的核心和灵魂则是运维元数据的管理和维护

何为运维元数据?即运维管理的基础数据

服务器的物理属性: ip、配置、地理区域

服务器环境属性: 测试环境 还是线上环境

服务器的应用属性 属于哪个应用，应用的负责人是谁，属于哪个部门

资产的命名，db redis 的连接地址、账号密码等等

资产成本问题

EC2 总是有部分机器，不清楚是谁在使用，用来做什么，无人认领

团队成员经常变化，人员调岗，资产成本需要确认新归属

数据库下线，Redis 不再使用后，并无感知，应用下线后机器未回收

资产监控问题

应用上线、机器上线、Redis 上线后，漏配置监控，或未加入维护监控

监控的报警人、通知人，无法及时设置，人员职责变化，无法及时更新

操作自动化

当应用停止服务后， 需要确定当前机器是否有其它应用部置，确定机器是否下线

资产统计

确定每个应用，使用了多少机器、什么配置、使用了什么数据库、哪些 Redis

我们需要一个元数据管理平台，需要能精确的维护运维资产的各项元数据，及时、准确、实时，并且在多个运维系统间能实时同步、相互一致

而维护这套元数据，并且实时准确自动化的更新，从去年到今年，我们经历了非常多的准备工作、实施工作，至今，我们依然在不断更新，不断完善

利用表格来收集

18 年 10 月，通过表格的方式整理了全公司的应用列表、机器列表、DB 列表、Redis 列表。这种方式最大的问题，需要随时手动维护表格，不及时、不准确、格式错乱

利用 jenkinsfile 来收集

发起 jenkins 统一项目，制定 jenkinsfile 标准，利用发布的强需求，来收集应用元数据信息

解决了应用与 IP 的关系维护，及时准确，缺点是统计比较麻烦，项目环境 IP 打散在分支中，扩容时 IP 也容易遗留

通过 jenkins 的发布通知，维护应用与负责人之间的关系，但比较粗糙

jumpserver 来收集信息

jumpserver 上线后，孵化出 JumpGroup、JumpNode 标签，用于确定 EC2 的归属，精确到三级部门

利用 EC2 登录强需求，来精确 EC2 与团队的归属关系

归属的及时性、确定性，依然需要通过手动来维护

CMDB 资产管理系统

CMDB 资产管理上线后，可以查询与管理每个资产的详细元数据信息

但管理团队归属依然偏手工维护，准确率、及时性不高

SQL 审核平台

SQL 审核平台上线后， 解决了数据库的团队归属问题

运维工单系统

运维工单系统自动化，依次上线了 EC2、DB、Redis 的自动化申请

解决了新申请资产的归属问题，谁申请则资产归属于相应的团队

并且可以在资产申请时，同时维护需要的资产元数据信息

jenkinsfile 切换为动态 IP

上线了 jenkinsfile 切换动态 IP 功能，Jenkinsfile 中不再配置 IP 列表

应用与 IP 的关系维护在数据库中，容易统计，项目环境 IP 不再分散在分支中，扩容及下线的 IP 维护可以流程化、自动化

应用平台

上线了应用平台，以应用为中心串联起了运维元数据，形成了完整的数据闭环

简而言之，运维工作的本质是以应用为中心的资源的生命周期管理，运维自动化是手段，运维元数据是灵魂