隨著業務的發展，新技術的迭代，公司研發採用了微服務架構或是上雲等等，這沒有考慮運維成本和效率，帶來運維極大的複雜性，讓運維純手工，苦不堪言，痛苦。從現象來看，運維和研發之間的矛盾更加嚴重。
這是現狀，這也是趨勢，作為運維自己應該主動改變，做新型架構下的運維（sre，devops）。
第一是思維的改變，理解當前的困境，不是某乙個人導致的。把目標放到業務效率，穩定，成本上。而不是以前單純的上線工具人。這就是要有端到端思維，理解他人，利用自己能力，經驗，工具，開發能力，團隊協作，組織能力，文化氛圍來解決矛盾。時刻都要想著：效率，穩定，成本。
第二是sre，現狀的運維都叫sre，他源自google，netflix是最佳實踐。叫站點穩定性工程師。利用軟體工程的方法來解決穩定性（運維）問題。就是用開發軟體，開源工具來提高穩定性和效率。這也需要技術架構和企業文化的支援，拋開這一切，光喊口號都是刷流氓。
第三是devops，其實devops和sre在運維看來，我認為是差不多，從表面上看，是解決運維和研發之間的矛盾。深層次講：都是業務迅速發展下的技術變革，上雲，微服務等等讓運維複雜性大大增加，運維不得不解決問題，這才是運維轉變的核心原因。
第四是理解研發，作為運維，你的改變更加迫在眉睫。但是實踐運用會有非常大的阻礙，比如研發不理解，還是老套路等等，所以不要責怪研發只知道開發需求**。你應該嘗試主動溝通，分享你的看法，理性友好交流，互相促進，成就彼此。所以不要責怪研發只知道開發需求**
第五要學習開發語言和了解更好的開源工具，比如jekins，cmdb，python，各類中介軟體等。
持續學習，保持謙虛，敬畏技術，在技術的快速潮流之下，不進則退。前進，銘記初心，真理。才是唯一答案。
我從傳統研發到現在，也在不停的轉型中，說說我的改變。
在之前：負責應用上線，研發需要啥我就跟他搭建啥，資料庫，中介軟體完全安裝我的理解和認知來。沒有穩定性和效率的概念，上線後，**能跑起來就不在關心。其他時間寫寫指令碼巡檢伺服器，做監控等等。這最大的問題就是重複，機械的工作，找不到工作的意義。
在之後：學習開發語言python，了解新的技術架構（docker，k8s，雲，分布式架構）等待。加強owner意識，積極溝通。統一中介軟體資料庫版本和部署架構，寫指令碼一鍵部署。規範應用上線流程，編寫應用規範，部署標準，監控標準等待。編寫部門wiki，部署cmdb，利用gitlab和jekins，ansible，監控等等工具。很多任務作雖然還沒有能力形成平台或服務。但是在效率上有非常大的提公升。這其中沒有組織能力來支撐推行起來非常難，堅持就是突破。
核心還是放在：效率，穩定，成本上來。
重新認識container
我還清楚的記得，第一次從 那兒聽說container這個詞 結果他給我解釋了半天還是似懂非懂的。今天，偷閒翻了下posa4,發現裡面對container的解釋特別清楚。粗略的理解下來是，為了分離關注點，而實現的對系統資源的封裝。豁然開朗的發現，os就是應用程式的container。突發奇想的，開發乙...
重新認識測試
以前總覺得測試是軟體開發的邊緣職位，開發人員才是軟體生命週期的核心人員。隨著對網際網路公司的了解，逐步了解到測試的重要性。以bat為例，三家公司均設定了測試開發工程師崗位，該崗位的主要職責就是編寫自動化測試案例，通過對 的邏輯進行分析，設計出能夠覆蓋大部分 的測試用例。如阿里的測試開發工程師的崗位描...
重新認識ARC
雖然用了很久的arc，感受了 簡潔。但是對arc底層實現並不了解。今天抽空研究了下，做些簡單地總結。一 strong 1.區域性變數 對於區域性變數來說，在超出作用域的地方由編譯器自動插入release。大概轉化為 在非arc返回的autorelease型別的方法 在blog手碼大概 如有錯誤還望指...