資源生命周期管理

“學長，幫忙建立幾台機器”，“學長，這幾台機器的幫忙加下監控”，“學長，這幾台機器可以下線了”，”學長…哎…哎…别跑 "…這就是運維工作的常态

看似雜亂無章的瑣碎小事，實則萬法歸一，殊途同歸:資源的生命周期管理 。沒錯，運維工作的本質就是資源的生命周期管理。所謂的資源正是你們所熟知的伺服器、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 維護可以流程化、自動化

應用平台

上線了應用平台，以應用為中心串聯起了運維中繼資料，形成了完整的資料閉環

簡而言之，運維工作的本質是以應用為中心的資源的生命周期管理，運維自動化是手段，運維中繼資料是靈魂