平臺設計中的指令碼管理

前期揉入了一些功能，因為主要是面向基礎功能，所以進度略慢，如果要想一下子有種井噴的效果，那就是指令碼化和流程化大顯身手的時候了。

如果儘可能減少開發和業務同學之間的技術代溝，使用指令碼化和流程化我認為就是一個紐帶。

這裡所說的指令碼化，其實嚴格來說是校本化，工具化的延伸。是相比於基礎功能命令，SQL,介面的進一步抽象。

我來分別對指令碼管理，流程管理做一個基本的解釋，歡迎各位拍磚，拍得越狠越好，因為我希望聽到有價值的建議。

指令碼管理是在後設資料構建的基礎上的，比如對MySQL/Redis DBA來說，操作的基本粒度是資料庫例項，那麼我們就可以完全按照IP+埠來構建匹配到一個對應的例項，至於硬體，是否虛擬化，配置的明細，這些我們可以透過資訊下鑽得到更細維度的資訊，但是對於我們的操作粒度來說，例項已經足夠。

所以有了基礎的後設資料，要細化並且和管理工作結合起來，才有了充分條件。

我在構建基礎平臺的時候，隨著基礎功能的增加，越來約感覺到了複雜度和維度需要簡化，細化。後設資料的資訊可以分為多個選單，不同的功能之間有關聯關係來指定，所以在MTV的Django框架中，我配置了不少的url來支援前期的工作，但是如果是MySQL細節的工作，這個事情要這麼做起來，明顯會有一個瓶頸，主要的感覺就是要配置一連串的功能，然後透過url和view把彼此連線起來。

比如MySQL方向，我寫了30個指令碼，那麼在這種方式下我至少得配置30+的url資訊，和一連串的邏輯實現。

其實對應用來說，就是指令碼呼叫，這樣的方式就有些笨重了。所以在指令碼管理中，我期望做幾件事情，能夠改進。

1. 為了能夠快速平滑的接入，指令碼管理中的指令碼語言其實不是瓶頸，都應該全面支援，比如使用perl,使用shell,SQL等，如果指令碼本身很穩定，那麼完全可以接入進來，總之就是這個環節要開放，不一定要完全是python指令碼。平臺的開發功能是python,但是指令碼管理不一定是python。
2. 在指令碼管理中，指令碼和選單如何對映，這是個關鍵，我們可以把指令碼屬性引數化，比如指令碼名，指令碼的型別等這些也是作為一種後設資料來管理。這樣就會是一個統一的介面的方式，至於具體的連線方式，比如樹形結構或者其他可行的方式。
3. 平臺方向上可以提前規劃，但是對於開發和業務同學來說，無需配置大量的url，就可完成一些基礎或者複雜功能的擴充套件。
4. 現有的基礎架構和功能，指令碼化對於它來說也是起到促進作用。需要提前規劃和已有的基礎功能是否有可銜接的地方。
5. 指令碼管理支援檔案的上傳和指令碼內容編輯。這個就是偏具體技術的實現了，比如ACE編輯器。
6. 指令碼的引數管理，有的指令碼是1個引數，有的是2個，其實對於後臺來說，就是拿到指令碼來處理，怎麼做標識和匹配。
7. 指令碼管理中，有些指令碼是通用的，如果希望能夠持續使用，必須要提前規劃好範圍和類別。有些指令碼是具體的一些業務場景需要的，需要明確需要的引數和許可權。
8. 指令碼不光用通用和私有的範圍，而且還需要細化到具體的作用域範圍。

如果來說下流程管理。下面是我之前規劃的餓一個資料庫方向鎖要做的事情和發力的方向，但是這樣是透過流程的方式把這些貫穿起來，這個事情就好辦多了。

比如備份恢復的工作，我們分為全量備份恢復，增量備份恢復，binlog備份恢復，這個工作如果和高可用方案連線起來就會更有意義了，就可以實現一個所謂的自動化流程。

我繼續細化一下，畫出一個流程圖來說明一下。