這篇文章主要介紹了運維開發(fā)中有哪些問題的相關(guān)知識，內(nèi)容詳細(xì)易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇運維開發(fā)中有哪些問題文章都會有所收獲，下面我們一起來看看吧。
運維工作中只要牽扯到運維開發(fā)，要去推動這件事情勢必會有幾類問題需要解決：
提高運維意識。從下到上，從上到下的工作都要做，對上運維工作的價值和含金量可以得到認(rèn)可，對下我們的工作能夠提高效率解放自己。比如對于運維開發(fā)，我可以配合和協(xié)調(diào)，有技術(shù)困難可以解決，但是我不會追著別人去學(xué)習(xí)某些技術(shù)，因為這種事情會變味，運維意識里有這個，那么這個事情的意義就大不同。
要有明確的運維目標(biāo)。這里說是明確，光有規(guī)劃不行，要有明確的運維目標(biāo)，這個目標(biāo)換個角度來看就是我們工作的痛點，解決了工作的痛點才是對我們自身意識的提升，這樣也能解釋實現(xiàn)運維目標(biāo)的意義。
要有明確的時間窗口。有了目標(biāo)，需要我們安排指定的時間窗口來做，如果沒有時間范圍，那么事情的進度和質(zhì)量就難以追溯和保證。
我在這個事情上栽了很多的跟頭，而且會發(fā)現(xiàn)事情變得越來越不可控。就好比我的期望是6，達(dá)到的結(jié)果是2，反差越大，發(fā)現(xiàn)改進的空間很大，以至于我會陷入一個死循環(huán)，我會想出很多的改進方法和建議，但是這些方法和建議就會抽象成為一系列的改進任務(wù)，這些任務(wù)涉及前端，后端和設(shè)計，于是乎，每一個點我都需要確認(rèn)，溝通，落實，然后事情的進度就慢下來了，對待運維平臺，要有「瘋狗」一樣的執(zhí)行效率，我還記得這句話，有時候都會反問我這么堅持做這個事情，到底為了什么，對我們有什么好處，甩甩手放棄算是輕松了，就這這句話支撐了我：當(dāng)你想要放棄的時候,想想當(dāng)初為什么要開始。
我們來切入正題，即一個“悲劇”的部署安裝場景，到底是不是悲劇，碰到了那些問題，如何來解決，當(dāng)時是怎么糾結(jié)的，可以聽聽我的想法。
先來說一下實例部署的場景。
假設(shè)下面就是一個初步的安裝部署頁面。
要實現(xiàn)這個功能有一些目標(biāo)能夠達(dá)到。比如我們目前能夠?qū)崿F(xiàn)頁面調(diào)用腳本內(nèi)容，我們來看看有哪些需要注意的地方，或者容易讓人糾結(jié)的地方。
首先這個需求是否符合預(yù)期，可能不是很好理解，比如我們的需求是部署一套數(shù)據(jù)庫軟件，那么內(nèi)核參數(shù)需不需要調(diào)整，系統(tǒng)參數(shù)要不要初始化統(tǒng)一配置，數(shù)據(jù)庫額外的插件是否需要安裝，備份是不是要配置，監(jiān)控是不是要部署，元數(shù)據(jù)是不是要自動生成。還有一點，這個環(huán)境是不是已經(jīng)有實例，如果有，那么/etc/my.cnf的默認(rèn)配置就需要重新調(diào)整了，這樣一來，這個看似簡單的頁面就不滿足需求了，于是我們擴展之后做收斂。上面的功能都是基礎(chǔ)需求，我們都需要考慮，但是不是所有細(xì)節(jié)都需要統(tǒng)一執(zhí)行，比如內(nèi)核參數(shù)優(yōu)化可能初始化執(zhí)行一次就可以了。所以我們需要對腳本化的工作做到細(xì)化，能夠?qū)崿F(xiàn)模塊化的功能，這樣就牽扯到一些邏輯的改動和優(yōu)化。
當(dāng)然從前端來說，一個難點就是日志的執(zhí)行結(jié)果回傳，能夠基本達(dá)到刷新的效果。這個需求對很多運維來說，是比較難實現(xiàn)的。所以可以抽象為兩個難點，一個是進度的顯示，一個是日志的顯示，其中日志的顯示是重中之重。
看起來腳本化的工作差不多了，假設(shè)我們花了一些功夫做了定制和改動。那么接下來的事情就是腳本的執(zhí)行了。還是要引用之前畫的一張圖。
比如我們要做環(huán)境的部署，那么執(zhí)行路徑可能是ops(運維平臺）->CM(中控）->DB Server(服務(wù)器)，或者是ops(運維平臺）->DB Server(服務(wù)器),比如從標(biāo)準(zhǔn)化的角度來說 ops(運維平臺）->CM(中控）->DB Server(服務(wù)器)是一個更合適的路徑，那么腳本從OPS端觸發(fā)，怎么達(dá)到DB Server端，因為中間需要有一個中轉(zhuǎn)的流程，可以使用paramiko,ansible或者salt來完成，但是怎么無縫銜接起來就是一個難點，如果從接入管理的角度來說，可能可以抽象成為接口?？雌饋砭褪且粋€命令的事情，但是銜接起來確實是個麻煩。
然后來說一下數(shù)據(jù)查詢的需求，其實這是一個很基礎(chǔ)的需求。能夠通過界面顯示出數(shù)據(jù)來，滿足一定的查詢需求。但是有面臨一堆的問題和不確定的需求。
比如我要實現(xiàn)數(shù)據(jù)查詢，執(zhí)行路徑按照上面的圖來看可能就是ops->CM->Server->DB，這個路徑很長，或者是ops->CM->DB,如果選中是這個路徑的話，如何開通權(quán)限就是個難題，我們假設(shè)有100臺MySQL服務(wù)器，寫一個腳本批量傳送腳本到這100臺服務(wù)器上，在數(shù)據(jù)庫上創(chuàng)建1個用戶，然后開通防火墻權(quán)限，看起來是很簡單的一件事情，但是你會發(fā)現(xiàn)這個方式是錯誤的，比如里面有主從復(fù)制，你如果在從庫執(zhí)行了，主從復(fù)制很可能就會斷開了，那樣你就需要處理更多的復(fù)制問題，所以有100臺服務(wù)器，你需要做一層提取，那就是找出哪些是主庫，哪些是從庫，但是很快就會發(fā)現(xiàn)判斷主從還是個麻煩，因為MySQL層面就沒有一個明確的標(biāo)識master還是slave,而是需要間接得到。從主庫上直接得到slave的信息不夠直觀，如果我一臺一臺確認(rèn)，又覺得這種方式太low,真要完美的銜接起來發(fā)現(xiàn)會碰到一層又一層的問題，最尷尬的還是元數(shù)據(jù)不夠準(zhǔn)確，忙活一場，發(fā)現(xiàn)還是缺了一些數(shù)據(jù)。
當(dāng)然可以糾結(jié)，也可以做改進，我們就可以明確的梳理邊界，比如我們解決的是運維部署，那么我們就聚焦在這個地方，看看需要投入多少的人力和時間成本來解決。一個一個初步解決，能夠快速迭代出來一些效果。反之就會發(fā)現(xiàn)是一點一點的迭代，但是都在完善，都沒有成型的結(jié)果。
關(guān)于“運維開發(fā)中有哪些問題”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“運維開發(fā)中有哪些問題”知識都有一定的了解，大家如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。
重慶分公司
重慶分公司
