運維工作中只要牽扯到運維開發，要去推動這件事情勢必會有幾類問題需要解決：
-
提高運維意識。從下到上，從上到下的工作都要做，對上運維工作的價值和含金量可以得到認可，對下我們的工作能夠提高效率解放自己。比如對於運維開發，我可以配合和協調，有技術困難可以解決，但是我不會追著別人去學習某些技術，因為這種事情會變味，運維意識裡有這個，那麼這個事情的意義就大不同。
-
要有明確的運維目標。這裡說是明確，光有規劃不行，要有明確的運維目標，這個目標換個角度來看就是我們工作的痛點，解決了工作的痛點才是對我們自身意識的提升，這樣也能解釋實現運維目標的意義。
-
要有明確的時間視窗。有了目標，需要我們安排指定的時間視窗來做，如果沒有時間範圍，那麼事情的進度和質量就難以追溯和保證。
我在這個事情上栽了很多的跟頭，而且會發現事情變得越來越不可控。就好比我的期望是6，達到的結果是2，反差越大，發現改進的空間很大，以至於我會陷入一個死迴圈，我會想出很多的改進方法和建議，但是這些方法和建議就會抽象成為一系列的改進任務，這些任務涉及前端，後端和設計，於是乎，每一個點我都需要確認，溝通，落實，然後事情的進度就慢下來了，對待運維平臺，要有「瘋狗」一樣的執行效率，我還記得這句話，有時候都會反問我這麼堅持做這個事情，到底為了什麼，對我們有什麼好處，甩甩手放棄算是輕鬆了，就這這句話支撐了我：當你想要放棄的時候,想想當初為什麼要開始。
我們來切入正題，即一個“悲劇”的部署安裝場景，到底是不是悲劇，碰到了那些問題，如何來解決，當時是怎麼糾結的，可以聽聽我的想法。
先來說一下例項部署的場景。
假設下面就是一個初步的安裝部署頁面。
要實現這個功能有一些目標能夠達到。比如我們目前能夠實現頁面呼叫指令碼內容，我們來看看有哪些需要注意的地方，或者容易讓人糾結的地方。
首先這個需求是否符合預期，可能不是很好理解，比如我們的需求是部署一套資料庫軟體，那麼核心引數需不需要調整，系統引數要不要初始化統一配置，資料庫額外的外掛是否需要安裝，備份是不是要配置，監控是不是要部署，後設資料是不是要自動生成。還有一點，這個環境是不是已經有例項，如果有，那麼/etc/my.cnf的預設配置就需要重新調整了，這樣一來，這個看似簡單的頁面就不滿足需求了，於是我們擴充套件之後做收斂。上面的功能都是基礎需求，我們都需要考慮，但是不是所有細節都需要統一執行，比如核心引數最佳化可能初始化執行一次就可以了。所以我們需要對指令碼化的工作做到細化，能夠實現模組化的功能，這樣就牽扯到一些邏輯的改動和最佳化。
當然從前端來說，一個難點就是日誌的執行結果回傳，能夠基本達到重新整理的效果。這個需求對很多運維來說，是比較難實現的。所以可以抽象為兩個難點，一個是進度的顯示，一個是日誌的顯示，其中日誌的顯示是重中之重。
看起來指令碼化的工作差不多了，假設我們花了一些功夫做了定製和改動。那麼接下來的事情就是指令碼的執行了。還是要引用之前畫的一張圖。
比如我們要做環境的部署，那麼執行路徑可能是ops(運維平臺）->CM(中控）->DB Server(伺服器)，或者是ops(運維平臺）->DB Server(伺服器),比如從標準化的角度來說 ops(運維平臺）->CM(中控）->DB Server(伺服器)是一個更合適的路徑，那麼指令碼從OPS端觸發，怎麼達到DB Server端，因為中間需要有一箇中轉的流程，可以使用paramiko,ansible或者salt來完成，但是怎麼無縫銜接起來就是一個難點，如果從接入管理的角度來說，可能可以抽象成為介面。看起來就是一個命令的事情，但是銜接起來確實是個麻煩。
然後來說一下資料查詢的需求，其實這是一個很基礎的需求。能夠透過介面顯示出資料來，滿足一定的查詢需求。但是有面臨一堆的問題和不確定的需求。
比如我要實現資料查詢，執行路徑按照上面的圖來看可能就是ops->CM->Server->DB，這個路徑很長，或者是ops->CM->DB,如果選中是這個路徑的話，如何開通許可權就是個難題，我們假設有100臺MySQL伺服器，寫一個指令碼批次傳送指令碼到這100臺伺服器上，在資料庫上建立1個使用者，然後開通防火牆許可權，看起來是很簡單的一件事情，但是你會發現這個方式是錯誤的，比如裡面有主從複製，你如果在從庫執行了，主從複製很可能就會斷開了，那樣你就需要處理更多的複製問題，所以有100臺伺服器，你需要做一層提取，那就是找出哪些是主庫，哪些是從庫，但是很快就會發現判斷主從還是個麻煩，因為MySQL層面就沒有一個明確的標識master還是slave,而是需要間接得到。從主庫上直接得到slave的資訊不夠直觀，如果我一臺一臺確認，又覺得這種方式太low,真要完美的銜接起來發現會碰到一層又一層的問題，最尷尬的還是後設資料不夠準確，忙活一場，發現還是缺了一些資料。
當然可以糾結，也可以做改進，我們就可以明確的梳理邊界，比如我們解決的是運維部署，那麼我們就聚焦在這個地方，看看需要投入多少的人力和時間成本來解決。一個一個初步解決，能夠快速迭代出來一些效果。反之就會發現是一點一點的迭代，但是都在完善，都沒有成型的結果。