這是學習筆記的第 1807篇文章
之前簡單討論過一版業務樹的內容，隨着討論的深入，業務樹的建設思路也越來越清晰。
對此我設計了一個初版的業務樹建設思路，會把整個業務樹分爲四層。
分別對應的是資源服務，系統服務，業務服務和通用服務。
資源服務的一個基本單元是服務器，可以是虛擬機，物理機，也可以是docker等。這是最底層的資源服務。
系統服務包括系統應用服務，比如上面部署的nginx等，還有數據庫服務，它們都是在系統資源服務爲載體。
業務服務就是應用層面關注的服務，可能包含業務層運維的服務，數據平臺的服務，或者某個項目的產品服務等。
通用服務是基於客服體系建設的服務，它的粒度最粗，但是對於業務的理解和把握最爲直接，有效。
在這個基礎上，我們提煉出了一個核心的概念，那就是標籤系統。我們可以基於分層的思想來給各層打標籤，通過標籤的組合來實現業務的串聯。
這裏會解決一個很頭疼的問題，比如這裏有一臺服務器，上面部署了MySQL的服務，但是這個服務歸屬於哪個業務，其實對於我們來說，我們沒法得到最貼切的信息，因爲業務的分類規則和角度不同，通過組織架構來分類也可以，通過產品線規則來分類也可以，這個粒度到底是怎麼樣，其實這個是我們不能直接決定的，同時我們維護的應用信息和業務方是割裂開來的，彼此互不通曉。
以數據庫爲例，數據庫層面我們對接業務的單元是實例，即IP和端口的組合，可以基於這個基本維度來和上下層之間關聯起來。
這裏需要明確的一點是屬性和標籤是有區別的，比如對於數據庫來說，數據庫裏的數據庫角色是一個狀態值，它可能會發生變化，那麼這個屬性作爲一個標籤就不是很合適了，但是它作爲元數據的屬性是很貼切的。所以標籤系統是一個通用的入口，標籤之間的關係可以通過元數據接口來打通。實現了上下的串聯，就可以讓標籤的信息成爲一個層次設計很清晰的數據。
整個標籤系統的設計中，對於不同維度的標籤管理是有一些差別的，因爲維度和視角不同，所以添加標籤的demo會有一些差別。
但是總體來說，標籤的管理還是一個相對層次化的管理，比如對某一類服務添加標籤，添加的過程中就應該能夠查看到已有的標籤，然後在這個基礎上進行細化。
同理，添加數據庫標籤的時候也是類似，我們可以看到系統層的基礎標籤，這些標籤是不能隨意改變的，每個層面根據自己的特色去定義標籤，需要關聯一來的標籤應該是互相充分溝通的前提下添加的對等標籤。
在完成了基礎標籤的定義之後，比如完成了資源服務和系統服務的標籤，這個時候我們就可以對接業務來實現共同關係的業務維度的標籤配置。