隨著業務和需求的增長，需要研發進行並行開發，如何保證功能之間不受影響，防止研發打架。如何保證大家**不被覆蓋，如何保證上線的功能就是上線的**。這需要從**管理方面來進行考慮，當然推行git是基本。1.功能開發時使用功能分支，拋棄都提交到develop分支的方式，單獨拉取乙個分支進行開發，保證開發的時候只涉及當前功能；2.許可權管控：下掉開發master許可權，只保留開發許可權；3.上線的時候通過**合併的方式將功能**提交到master，合併通過cmdb平台自動完成。
當開發功能從develop到功能分支，不可避免的會遇到合併**時候的衝突問題，這個需要在合併的時候研發進行相應的處理，解決衝突。
為什麼要做多分枝講了，那麼如何實現呢？多分枝不可避免就是伺服器上需要跑多套環境，多套不可避免會造成資源衝突，比如埠/pid檔案等，還有可能造成管理混亂（多個版本都在跑，**或手動操作的時候不知道刪哪個）。如何規避這些問題，我們選擇了kubernetes來解決這些問題。實現思路為：1.預設的測試環境，**全部從develop拉取，也可以檢視當前develop分支的**是否都正常執行；2.分支環境，從功能分支進行拉取，非功能分支的都從預設環境獲取；3.分支環境的**和develop的**通過對ingress的編排實現，我們選用的時helm的charts進行實現的。
以上基本就能實現資源的發布。那麼資源的刪除呢，也是需要通過helm來實現。在ingress中把功能分支的service更換成預設的service即可。
多分枝測試避免了研發之間**的相互覆蓋（合併有衝突會提醒，只有解決了衝突之後才能完成合併，在此之前研發能夠相互進行溝通，避免覆蓋的發生），但是任何事情都有利有弊。下面簡單說說弊端：1.需要程式進行適配：由於多分枝是通過不同網域名稱進行實現的，需要給程式制定乙個規則，讓其訪問對應網域名稱下的程式；2.需要對dns進行泛解析，如果放到公網會帶來一些安全問題。edit by cherrydot
從運維角度談談故障定位 未完
一般剛畢業不久的會回答 我們有監控 看日誌等之類的答案。工作幾年的人會回答 從網路，機器，資源等方面排查有沒有問題，如果沒有問題，再看看日誌，找開發核對。也有人回答這個是開發的問題，我們運維還沒有精確到業務層面。運維人員進行故障定位時，遇到主要問題 1 業務掌握深入程度有限。不像某個應用的開發那樣，...
如何快速實現遠端運維
現如今，企業的it運維管理人員面對多方考驗，一方面企業為了減員增效，無法完全滿足匹配各地運維人員，另一方面又要面對資訊化的需求公升級，需要更高效和快速的實現it管理和運維，這對企業it管理和運維人員的要求在不斷提高，也讓it運維工程師的壓力倍增 壓力是什麼？容易陷入繁雜瑣碎的事情中去，無法關注可靠性...
精準化運維如何實現？
正如大家所知道的，it運維服務是對it基礎設施 網路系統 主機系統 儲存 備份系統 終端系統及環境等 以及軟體應用等進行服務的。一般情況下的運維資訊系統以支撐企業業務，但實際情況卻是業務受諸多因素影響，不斷變化，從而使得運維工作很難做到針對性，更別提精準二字了，當然所謂的運維價值也就不存在了。根據這...