自動化平臺開發小結（六）

 

最近幾天還在不斷的改進平臺裡的事情，而翻了下之前寫過的文章，發現從起步到現在也有一個多月了。如果不是看看自己總結的文章，好像啥也沒幹。

在此期間，我設立了兩個里程碑，第一個月跌跌撞撞，算是技術積累，從初期的規劃，熟悉Python和Django,到撿起多年塵封的web技術，一個月很快就過去了。第二個月是規劃設計，主要實現基礎的架構和功能設計，花大力氣重新定義了統一的模板風格，對ORM的一些基礎實踐，保證基礎可控。而到了最近開始接入一些業務的時候，發現需要做的事情要比想的還要多，或者可以這麼理解，需要解決的問題比預想的多。

問題比想的多，也比想的嚴重，越是發現問題，反而有一種喜悅的感覺，因為透過一些資料的重構和連線，發現了原來不曾發現的問題，原來一問三不知的問題現在有了答案，而且還有了圖表展現。與此同時選單比以往多了不少，遠比初期規劃的多了一倍，這意味著工作量增加了不止一倍。我來說說自己的一些理解。

確切的說，是從這周開始，我開始接入業務的資訊。本來主要是給MySQL方向支援，但是發現其他的方向上的需求其實更迫切。所以大家如果能達成共識，而不是抱著幫我，配合我的態度，事情其實可以做出另外一個境地。

我按照我完成的進度來說說。

1.基礎功能的許可權粒度

對於許可權的粒度和控制是我在初期的建設中最關注的，我想了很多，也遇到了技術瓶頸，最後還是自己想明白了之後，發現原來是固步自封。

比如對ORM的拿捏，最開始是無法控制，一到定義表關係的時候就很糾結，一來需要熟悉，同時又要定製各類需求。突破這個瓶頸期確實花了一些時間，最後果斷拋棄了外來鍵，大量的關聯表，而只是依賴於自帶的ORM來實現一些基礎的增刪改查，而對於複雜的查詢需求，是透過定製SQL下沉到DAO層來實現。後期對錶資訊的關聯做一些管控，盤子大了之後，可以注意到很多看似不重要的地方。

2.後設資料稽核

後設資料的稽核比自己想象的要複雜，棘手。這個工作量無異於重新搭建和設計一套CMDB.

後設資料的資訊主要的問題在下面幾個方面：

1）後設資料缺少

如果整理這部分資訊，就會發現因為各種原因，每個人幾乎都有一套自己的後設資料源。儘管已有一個後設資料平臺，多套平臺集合起來，而且分成不同的類別，可以說是混沌狀態，而且最讓人糾結的是到底缺少了那些資訊，還很難去定位。這個工作是個體力活，也是很不招人待見的事情。

2）後設資料資訊錯誤

後設資料存在的意義就是有效，可以參考，這是對後設資料的信任或者是依賴，也是對平臺的信任。所以一旦這個紐帶建立不起來，其他的都是白扯。結果在整理的過程中發現，有些伺服器的硬體資訊是錯誤的（你說我咋知道，因為顯示是0），有些是資料庫的主從狀態，這個資訊靠人工確認是很難的。我們可以有其他的解法。

3）後設資料資訊狀態未知

後設資料的資訊狀態未知，這個問題非常糾結，簡單來說，就是我們也不知道這個資訊到底對不對。這個需要透過多種方式來彌補，比如多系統的資料互動，來得到一個相對來說有參考價值的資訊來源。或者就是透過流程來控制，後設資料資訊的維護不應該是人工透過修改按鈕來觸發。

3.Echarts的備份視覺化

實現這個是想讓平臺看起來能用，讓一些大家都不知道的資料能夠更明確，比如備份的資料，一天備份了多少次，備份集大小是多少，備份多長時間，如果我們得到資料，沒有分析層的支援，那麼就是一個黑盒，蒙著頭幹活而已。

所以透過視覺化的方式來展現，就可以清晰的看到，那些地方可以改進。

4.非同步資料來源同步

要想不閉門造車，就是能夠更多參考其他的可借鑑之處，對於資料來說也是類似，如果資料庫去維護機架位的資訊，肯定是很困難的，但是讓系統部的同學去維護，就是一個很自然的事情。所以我們可以直接參考這些資訊，可以做異構系統的資料來源資訊同步。兄弟部門開好API，定義好規則和方式就很容易操作了。

5.paramiko介面接入

這個部分沒有話太多的時間，就是簡單的接入，支援ssh的方式去操作一些命令。目前的效果還不理想，後續繼續改進。

6.接入celery，flower資訊接入

這部分的資訊比較有借鑑意義。同事調研了celery的內容，但是因為前後端的一些技術原因，沒有很好的把資訊利用起來，所以我有平臺，他有基本的一些東西，我們就可以結合起來。

這個部分的工作做好了，後續就是一個很不錯的功能，如果自己搞，從頭再來，意義不大。

7.單點例項管理

這部分資訊很有意思，如果是測試環境，可能就不需要從庫了，但是需要週期性的備份。

如果是流轉業務，可能就不需要從庫或者備份了。

所以我設立了一個單點例項管理，可以管理這些資訊