1、引言
上學那會，每當作文中引用到張良這個典故，總喜歡用 “運籌帷幄之中，決勝千里之外” 來讚美張良雄才大略，指揮若定，現在還讓我用的話，我會把這句話送給運維同學。
2013年左右，一朋友在某某國企做運維，除了拆機、裝機、做系統、協助領導上網站、打印資料..... 工作相對軟件公司的運維還是相當清閒，可以愉快的喝茶聊天發呆，偶爾也可以學點自己想學的技術充實自己，直到有一次，領導辦公室的燈泡壞了，讓它去修下，他感覺以前乾的活跟電腦沾點關係，而修燈泡只跟電有關係，次日提交離職報告，發誓去遠方追夢。
2、傳統運維職責
傳統模式下的運維一般要承擔很多工作：物理機管理、應用部署、網絡架構、dba等等，運維往往是個多面手，因爲什麼都幹，所以看起來更像是一個打雜人員，定位比較尷尬，往往不能得到公司領導的重視。
關於薪資，相對來說運維人員的工資沒有程序員的工資高，畢竟工作強度不是一個量級。
關於技術，對於運維人員來說，並不需要深入理解某某編程語言，掌握某某核心技術，出了問題，只要肯看日誌，願意谷歌，幾乎可以解決80%的問題。
關於程序員和運維的關係，很多人把運維調侃成一個 “背鍋” 角色，我覺得一般情況下讓運維背鍋並不容易，背鍋這種事情還跟運維人員的自身技術有關係，只要技術運用嫺熟，運維人員有理有據的甩鍋也是常規操作。
類比於工業時代，傳統運維人員只需能夠駕駛着別人製造的列車前進就行了。聽了這句話你也就不難理解爲什麼我們傳統的運維人員甩鍋是常規操作了。
而現代化的運維不要求你會開車，更多是參與制造汽車，最大程度上讓車自動化、智能化。如何實現？且聽下文繼續分析。
3、去人肉運維化。
運維人員更重要的是搭建和管理自動化平臺，內部開發團隊可以依賴我們的工具，但是不能依賴我們的勞動力。當然搭建一套人見人愛、花見花開的平臺絕非偶然，初期的話，可以藉助開源項目，過去有PaaS，現在我們可以藉助谷歌Kubernetes、Prometheus、Rancher等開源工具，儘快完成運維平臺的搭建，搭建完成不算完，像Kubernetes本身也會有一些自己的短板，像有狀態應用支持有限，可能要基於Operator自己開發，對於AI行業常用GPU更是支持太弱，我們需要不斷深入研究和探索工具，總之搭建這套自動化運維平臺對內一定能把運維有限的精力運用到有價值的事情上面，對外一定能夠滿足開發團隊發佈和部署的需求。
4、誰開發、誰部署、誰監控
傳統做法通常是，開發人員開發完成、提交測試、測試通過、一個郵件或者內部羣通知運維人員某天晚上11點以後開始部署，開發和測試人員在工位焦灼等待驗證功能是否正常。運維人員一封郵件發給所有干係人 “已經部署完畢、請驗證” 。開發一看 "點哪那不行" 一封郵件通知運維，趕快把日誌發過來......
傳統模式下幾乎所有公司的開發人員和運維人員都會有固有的衝突，且不管最後是誰的責任，這個過程最大問題就是開發人員不關心部署的具體細節，而運維人員不關心應用的具體實現細節，這就導致了運維和開發之間的代溝，詳盡的文檔可以解決一部分問題；但最終還是開發人員自己最瞭解自己的系統。這當然跟公司組織架構也有關係，通常都是研發一個團隊、運維一個團隊，甚至於獨立的產品線都依賴於集中式運維團隊。
那麼如果開發人員自己開發自己部署，運維人員難道啥都不用幹了嗎（天天研究技術多爽啊）？自動化平臺搭建完成就可以裁掉80%？其實不然，舉個例子，讓程序員在linux下部署個主從模式Mysql，打聽下自己身邊的程序員，不通過磕磕絆絆的搜索有幾個可以高效完成的；有人要說，這種工作不能讓運維幫忙完成啊，不會又回到從前了吧！
那麼如果通過運維人員加入開發團隊呢？
一般情況下，一個產品團隊應該能夠自給自足，獨立完成產品的部署和交付；但是產品開發初期，讓開發人員獨立完成系統基礎環境和產品運行環境的搭建不是特別現實，這時我們可以在產品團隊組建初期加入運維，讓運維扮演跟開發人員同樣角色，參與團隊內部事務。
當團隊成員都在參與需求識別、任務估算、軟件開發的時候，團隊中的運維人員需要在這個過程中識別開發團隊的活動，做好數據庫驅動設計、表結構設計、單機部署還是集羣部署、是否存在有狀態服務、比如不經常變動數據可能適合存儲到關係型數據庫，查詢頻繁的數據更適合存儲到內存數據庫，這些都需要運維人員的參與和設計，並且能夠提前做好部署和發佈的準備；
當開發團隊需要部署產品需要基礎環境時，運維人員和開發人員一定要密切配合或者通過交叉培訓的方式完成環境的搭建和部署，這個過程後期可能需要開發人員獨立完成；
完成上述工作之後，運維人員可以像開發人員一樣，把上述的運維過程轉化爲自動化代碼，使整個過程更廣泛和可靠的運行。比如一些人爲的過程，藉助Jenkins打包工具，通過編寫腳本，自動把文檔和軟件包分發到各自服務器；從而爲產品團隊輸出了自動化部署腳本、sql優化過程、監控使用等工作成果。
說到這裏很多人要說對於普通中小型公司，運維是很珍貴的資源，可能就那麼一撮人，根本不夠用，這時可以採取當工作完成到自動化這個階段運維就逐漸淡出產品開發團隊，根據個人能力，以同樣的形式融入另外一個或者多個團隊。當然運維人員的組織還在原來集中式運維部門。
5、總結
通過對比傳統運維和雲時代運維，描述了運維和開發一體化的理念和方法。這個過程要求運維人員有更強的統籌和架構設計能力。這些能力，對於雲時代的運維不正是必備的嗎？
推薦閱讀：
Kubernetes中如何使用ClusterDNS進行服務發現？
從Ice到Kubernetes容器技術，微服務架構經歷了什麼？
原創不易，隨手關注或者”在看“，誠摯感謝！