雪花紛紛落下，片片各得其所。

體系篇

1、對象為實體

對象是一個實際存在的某物，它具備某種能力或提供某種服務，對象是一個實例或實體，比如具體部署的一個硬件設備或一個應用系統、一個數據庫實例均是對象，多個對象以某種邏輯關系組成架構，換句話說架構是由對象所組成的。

對象的顆粒度定義大小由架構管理能力而定，架構管理能力越強，對象分解則越細。當一個架構所組成的所有對象是運行正常時，架構一定是運行正常的，如果不是，則是架構分解過程中出現了對象定義遺漏。

一般而言，在一個架構中會存在多種對象，此時需要將對象進行分類定義，以便于管理及分析，在復雜情況下，分類是一個樹形結構，分類的過程就是對架構解構的過程，完全窮盡、相互獨立是分類很重要的原則。

分類是根據對象屬性進行的，嚴格來說，一些對象被歸為同一類，是因為他們具備相同的屬性，相同的屬性包含兩層意思，一種是具備相同的屬性字段，一種是具備相同的屬性值。

2、屬性為指標

對象是組成架構的基本單元，屬性是組成對象的基本單元，一個對象的屬性包括它具體的所有內在的能力、功用以及外在的特性，除去屬性，對象為空，對象的本質是一堆屬性的集合。

換句話可以說，架構是由屬性構成的，屬性就是一個配置項（一個可配置的項目），配置一個屬性的過程就是操控架構的過程，所以對象不是配置項，屬性才是配置項，歷來的CMDB概念對此有著定義上的問題。

由于不同對象有著不同的屬性，所有對象的所有屬性，可以抽象成一個屬性池，由一個一個字段所構成，這個屬性池即是描述架構的基本語義。

屬性池的設計梳理在工具意義上是必要的，每一類對象擁有哪一些屬性，需要進行定義，此時只是一個數據建模的過程，還不是對象實例化的過程，不同分類的對象可能擁有重疊的屬性字段。

由于屬性是可配置的，也是可監測的，一個不可被監測的屬性一定是不可配置的，不管這個工具監測的人工監測，所以屬性能以一種指標的形式進行監控。

3、動作為事件

對于一個對象的屬性的配置過程，可以稱之為動作，也就是操作，架構的管理在絕大多數情況下，是對對象的操作形式體現出來的，一開始是人工手工執行，慢慢發展到利用工具進行執行。

當屬性定義完整的情況下，動作的執行結果就是屬性的變化，我們也可以稱之為一個架構事件，將動作進行標準化及自動化的過程，就是架構自動化的過程，一切架構自動化的目的與結果都是圍繞對象屬性的，所以屬性池的總集就是理論上架構動作的總集。

理論上可以將所有對象的屬性對應的可能操作進行梳理，形成一個動作集，將動作的執行腳本化、程序化，再經由對屬性改變的結果進行監測驗證，來加以判斷執行及回饋。

當自動化程度較高時，可以根據動作執行與屬性值的變化邏輯判斷進行跨對象的動作執行，此時形成處理流程或叫調度編排，動作的執行結果與對象屬性值是校驗下一個步奏基本的邏輯判斷單元。

動作也是橋接虛擬架構與架構本體的一個窗口，它對應是可能是一個腳本也可能是一個啟停手冊，動作是可以根據對象分類進行劃分的，即每一類對象可能有哪一些操作動作，這些操作動作的多少其實就預示著架構維護能力的強弱。

4、視圖為架構

架構對于不同專業職能的人員有著不同的面向，這也意味著不同職能分工的人對架構都有著自己的視角，本質上不同專業職能的人員事實上是面對架構中不同對象的不同屬性，此時視圖的意義就會凸顯。

本質上視圖就是不同角色對架構的不同切片，不同角色的人會根據自己的專業職能范圍，繪制出自己管理對象的范圍，由于在架構中對象之間均存在關系，所以視圖會以系統結構的形式呈現。

視圖是由對象及關系組成的，視圖中對象的多少、屬性的多少以及相互之間的關系，包括視圖中的對象的排列布局，取決于用戶對架構的理解與抽象。

由于視圖只是架構的一個切片，當用戶需要查看管理更大的架構范圍時，此時視圖與視圖之間可以建立關聯，所以對象與對象可以組合，視圖也可以與視圖組合。

對架構的切片越多，意味著對架構的理解越深入，也表示對架構的描述越精確，就好比對一個社會或一個人，你從更多層面去審視它，你就會對它的理解越發深入，真實情況就是所有層面的總和。

5、關系為邏輯

在模型層面，關系是基于對象分類的，在對架構進行解構時，即將架構的對象進行分類后，每個分類之間可能存在關系即可明確，這個定義并不是必要的，它更多是在關系數據校驗時發揮作用，或者對繪制視圖進行行為約束。

在實例層面，關系只屬于于視圖，而不屬于對象，不同的對象在不同的視圖中可能存在不同的關系，關系的存在與否取決于用戶的視角即視圖。

關系的性質是由兩個對象本身的屬性決定，而不是關系本身，這意味著不需要賦予關系任何屬性，這是從體的層面而言；從用的層面而言，在架構層面，我們只需要知道兩個對象存在著關系，就能滿足我們一切構建與操作所需要的所有結構信息了。

不需要對關系本身的數據再做一些頭上安頭的重復定義，導致數據結構或模型的復雜化，只有在繪制視圖時，才需要建立關系，而建立的方法是指定哪些對象有關系即可，而不需要指定它們有哪一種關系。

這在系統設計與數據結構設計時有著重大意義，所以關系數據是在記錄哪一些視圖中哪一些對象存在關系。

我們說兩個對象之間存在關系，是因為這兩個對象之中的某些屬性存在關系，在完美的配置模型下，關系的構建不是以對象出發的，而是從對象的屬性出發。

因為兩個對象之間的屬性存在關系，所以兩個對象才存在關系，所以兩個視圖才存在關系，而這種基于屬性級的終極配置模型只有在高度自動化的環鏡中才有可能實現。

6、場景為服務

任何架構的維護者均是面向對象的，做好服務工作的前提是識別出架構所存在的對象有哪一些，只有這些對象的運作良好，才有可能提供合格的服務，視圖的繪制是為了描述理解架構。

視圖本身就是承載服務的使用場景，基于一個視圖的使用其實就是在提供服務，比如查看這個視圖運行情況或基于這個視圖對架構進行維護操作，這本身就是一個服務場景。

服務是由一個一個的場景所組成的，識別出一個服務擁有的所有場景，并進行有效的管理，這是做好服務交付的必要環節，梳理服務場景的過程或能就會帶來新的視圖需要，大多數組織并沒有真正理解他們的服務是什么。

一個網絡維護組、一個機房運行組、一個系統維護組，這些組織都是在做一個服務提供，它們的服務交付的客戶其實并不是業務方，而是其它的專業組，正是因為對服務的理解片面，進而導致服務場景的梳理無從下手，從視圖也是毫無目的。

其實對視圖的監控其實就是對服務的監控，對視圖的操作其實就是服務的動作。通過場景可以把上述的一切進行有效組織，進行服務交互。

工具篇

1、基礎數據

• 需要定義對象的分類樹

• 需要定義分類的圖標

• 需要定義屬性池

• 需要定義分類與屬性的關系

• 維護或導入對象數據

• 維護或導入關系數據

2、視圖管理

• 負責對象與對象的組裝

• 數據維護模式：用戶可以手工拖拽對象數據進行關系構建，以類VISIO的操作方式，對象的位置與圖標均可拖拽維護，每畫一根關系線則在這個視圖數據層面創建了一條關系數據，在視圖上刪除一個關系線條即在數據層面做了關系數據刪除。

• 建模關聯模式：用戶可先畫好視圖，再手工拖拽對象數據進行關聯映射到視圖中。

• 可以基于一個視圖進行對象關系數據的導入，提供算法將對象與關系自動進行布局排列，且可手工進行調整。

• 管道線路類對象以線條方式存在，此類對象與對象的關系線條屬于不同的視覺效果與數據類型。

• 視圖可以容器化，在繪制一個視圖時，可以將視圖的多個對象進行設定為容器，此時在圖中多個對象會折疊成一個容器，可點擊再展開容器，此時視圖中的容器的所有對象會展開，以便更復雜的視圖表達。

• 每一個視圖的維護與查看權限均可設置，即誰能改誰能看，每一個視圖需要有自己的名稱與版本時間記錄。

3、場景管理

• 負責視圖與視圖的組裝、指標與指標的組裝、動作與動作的組裝。

• 視圖組合：可設置視圖之間可以相互嵌套與組合，從一個視圖點擊跳轉到另外一個視圖，或者以平鋪模式、分層模式將多個視圖進行整合。

• 指標管理：基于一個視圖進行場景設置，可定義在視圖中能查看不同分類對象的哪一些屬性指標，在不同的場景下關注的對象的屬性集可能不一樣。并可設置哪一些指標影響對象的狀態，不同的狀態將可反映到對象不同的顏色閃爍。

• 操作管理：選擇一個視圖設置與視圖每個對象關聯的操作動作，它可以關聯一個腳本執行或調用一個自動化軟件的API入參，甚至只關聯到一個啟停操作文檔，這些操作以按鈕方式集成視圖之中。

• 調度管理：在場景中可設置跨對象的操作執行，這種調度執行與場景進行綁定，可進行定制開發。

• 場景管理：經過指標與操作與視圖的綁定，形成一個可執行的服務場景，開啟時會加載視圖數據與指標數據與操作動作，供用戶監控與操作交互。每一個場景可以單獨命名。

• 圖層管理：可在場景中選擇不同分類的對象設置按不同的對象屬性作為顯示對象名稱。

• 文檔關聯：可點擊調用場景中任意對象相關的巡檢、保養、維護、文檔與工單記錄，以面向對象的方式組織其它分散的數據與信息。

• 查詢搜索：可輸入任意對象的任意屬性或任一視圖名稱或場景名稱進行搜索定位。

4、集成接口

• 負責工具與工具的組裝

• 對象數據集成：可對外采集其它系統的對象數據，也可批量導入對象表格。

• 關系數據集成：基于視圖可對外采集其它系統的關系數據，也可批量導入關系數據。

• 性能數據集成：將對象屬性與監控性能指標進行對應映射，實時顯示性能情況。

• 告警數據集成：將告警級別與對象顏色進行設置匹配，實時顯時告警情況。

• 操作數據集成：外接其它自動化軟件，在點擊執行操作按鈕時，傳遞對象的屬性信息作為入參條件，驅動其它軟件的命令操作或執行腳本。

• 圖形數據集成：可導入CAD、VISIO等圖紙資源。

• 對外服務接口：以API方式提供視圖與場景調用以及對象的搜索查詢功能。

應用篇

1、工具應用

打造一款靈活的拓撲管理工具，利用這個工具靈活的繪制拓撲的能力，繪制各類架構視圖，從數據中心的基建、曖通、弱電到網絡、主機到系統及應用關系均可將原來分散的線下圖紙轉為統一集中的管理，把大量在規劃設計階段的圖紙重新發揮價值，轉移到運營段來利用管理。

它的繪制能力可以跟VISIO相對應，除去精確度，它甚至可以將絕大多數的CAD圖紙能人肉轉譯過來，它的繪制能力必須高度重視用戶體驗，靈活讓它沒有專業應用的限制，簡潔讓它易于上手，設計的美感能讓它以把架構之美、抽象之力賦予使用者。

同時它的數據集成能力以及線上協作能力，讓它可以真正從設計到運維，并可以跨專業、跨工具的進行數據整合，同時它可以讓運營端的工程師們把它做為一個靈活管理工具，隨時根據自己的運維需要進行視圖繪制。

如此跨專業的信息協作以及人員離職的架構知識可以有效留存在組織之中，這些大量的視圖可以工程師快速閱讀、理解、分析架構情況。

2、行業應用

拓撲的管理對于架構越復雜、對象越多、關系越復雜的服務管理越有意義，除去熟悉的IT運維，還有像電力行業的通信網絡管理、電網的電力傳輸調度、公安的辦公網、視頻專網管理、運營商的通信資源管理。

這些網絡結構復雜的行業均存在大量的運維交互需求，一些歷史陳舊的工具還頑強的束縛著工程師們，經過這這幾年年移動互聯網的洗禮，工程師人群對傳統工具交互的不滿越來越大。

甚至一些城市的管廊跟管道、交通的軌道管理，是通通可以用拓撲管理的形式橋接他們的運維應用。

可視化只是人機交互的形式，基于一個靈活的拓撲管理工具，可以在不同的行業做出更多的縱深應用，靈活的繪制能力跟開放的集成能力是廣度與深度兩個重要保證，這對工具的抽象能力也提出極高的要求。

3、平臺應用

上面提到的在線拓撲管理工具有兩種推廣做法，一種是按軟件方式按客戶、項目去計費實施，一套一套去部署，它的易用性決定了它的售前POC是一種低成本的，甚至銷售人員也可以用它來快速繪制一個行業的DEMO場景，只要他具備一點點行業理解知識。

還有一種模式是按SaaS模式，即提供一個在線繪制拓撲工具，它可以免費試用，讓用戶零門檻的先嘗試繪制自己的架構圖，如果他們的確繪制方便，他們就會有意欲查看架構圖中的對象信息，甚至對接監控數據，這樣后續按月按年進行收費。

理論上用戶可以用這個平臺搭任何他們想要的模型，繪制任何平面圖紙，甚至多個圖紙的組合交互，這種基于可視化交互的拖拽才是更具實用意義的模模搭，它的應用廣度跟深度可以走的更遠。

這幾年物聯網熱潮漸起，事實上基于拓撲圖的可視化是物聯網很好的交互平臺，任何用戶可以在這個平臺把自己的物聯網架構快速實現繪制，不管它是一個家居的物聯網，還是一個工業4.0的數字工廠設備交互，物聯網的多場景模式，決定了未來它的服務場景數量巨大。

必須提供一個開放的讓用戶可自定義的可視化交互模式，才能將分散的物聯網設備及關系實現納管；現在談的智能建筑，物業與運營管理，這個智能樓宇里面的任何一層樓甚至任何一個子系統，都需要一個基于圖形的交互方式，不采用這種用戶可自定義的拓撲繪制的方式進行交付管理是不可想象的。

拓撲的本質是節點與關系，如果進一步抽象，把一個流程環節也可以對象化，你可以把一個政府所有的電子政務流程進行繪制，并可以把每個流程的關聯關系梳理出來，甚至可以對每個政務流程環節當前的辦理數量與排隊數量進行監控調度。

一個停車位也可以是一個對象，一個會議室也可以是一個對象，希望構建出來的平臺是可以面對一切物理結構跟邏輯結構的，只要這個復雜的結構有承載服務，就有對它進行解構跟監視、操控的需要。

在這個平臺上納管的對象越多、能監控的指標與能操作的動作越多，平臺的意義就越發明顯，隨著它的屬性池的豐富、自動化程度越高，可以發展成為一個操作系統，你也可以說它是底層所有工具的UI。

人類越來越希望以一種符合直覺的方式去管理一切，可視化的需求會隨著這個過程不斷涌現，高度的自動化沒有實現之前，可視化交互整合的需求會一直處于上升趨勢，一旦自動化程度發展到封裝大多數場景，人類會慢慢放棄洞悉其內部運作的訴求，也就是說對架構的切片會隨著自動化發展而遞減。

因為大量的現實會告訴我們，這種打開黑匣子往里看的沖動更多是一種情緒上而不是理性上的，機器會接管一切，它以一種更加自然的方式交付服務，而可視化將退回到另一個位置，一如黑夜之中，你仰望夜空的星光點點。