我會分為下面三個維度來討論下。
1.公司對你的定位
2.業務價值和技術價值
3.關於運維開發的推進方法
1.公司對你的定位
在IT行業其實不乏換工作的機會，關鍵是看你是怎麼定位的，是怎麼理解你的期望的。
而把這個問題做一層收斂，其中的一個面就是公司對你的定位。
技術上能夠很深入，而脫離了業務，其實話語權就會少一些。
業務上關注更多，技術上其實少了很多的鑽研，競爭力就少了一些。
而工作經驗的核心其實就是解決問題的能力，新浪的肖總說過，這個是和你處理的個數是成正比的。
公司不養閒人，公司的核心就是要盈利，所以很多時候其實我們考慮問題的時候要麼太簡單了，要不太過於現實了。
這句話怎麼理解，如果做過客戶現場支援的同學就會有一種很明顯的感受，在前線的壓力實在太大了，但是一旦深入了技術細節，感覺好像一下子耳根清淨，是另外一番境地了。
最終問題要解決，勢必會牽扯業務，而通過技術的手段去解決，認為簡單是很多人其實更願意去從事技術價值更高的工作，當然這個出發點不一定錯誤。
而另外很多人過於現實，是一切都會以業務價值來衡量。我給一個非運維的朋友說過，如果按照你一切按照業務價值的衡量，運維這個崗位就不需要了。
在這裡我倒不是和大家討論運維的位置，而是從公司對你的定位來理解你的角色。
我也幫助過不少公司做過一些招聘的推薦工作，根據我的理解，他們更傾向於找到經驗豐富，有自己想法的人，如果技術足夠好，沒有管理經驗可以慢慢培養，而如果只有管理經驗就比較尷尬了。
運維的工作其實很難去根據業務價值的維度去衡量，打個比方，如果有1000臺資料庫要維護，你說你很累，但是加加班也能做到,那麼開始的時候你是很有幸福感的。
那麼第二年還是1000臺伺服器，有些人就會疑惑了，1000臺也好好的，已經穩定執行了，所以運維的工作就相對來說沒那麼重要了。
很多時候你沒法直接根據一些體面的數字來關聯起來，所以我們一般採用的方式就是減少伺服器規模，提高效能之類的。很多人的公司沒BAT那麼大體量，所以效能提高個2倍，5倍對業務來說影響可能沒那麼關鍵。
所以我們想做很多事情，但是得不到更多的認可，這就是技術價值的一個痛點，而如果只是承接了業務，業務非常熟，但是脫離了這個平臺，公司對你的依賴會大大降低。
因為你的經驗很難在其他公司去複製，這是業務價值的一個痛點。
所以說運維的路子本身會越走越窄，我提了很多次運維開發，以至於現在我都懶得提了，具體進步了多少呢，其實發現很多人，包括我自己，都有強烈的拖延症，事情就這麼拖下來了。
2.業務價值和技術價值
先來說一個常見的漩渦，業務價值低的系統產生的業務價值不高，所以很多新技術在這裡使用的意義不大，被認為不值得做。
業務價值高的系統產生的業務價值高，新技術使用的風險較大，所以很多新技術的推動就有一定的阻力或者更多的考量維度。
如果在一個漩渦之中，那就是新技術推廣真難，如果用混合思路，那就可能是在業務價值低的系統中試水，然後在業務價值高的系統中逐步推進，所以沒有了前奏，後面的事情要推動就很難了。
混合可能是個好事，但是最終會導致事情和原來的預期差別很大。差別有多大呢，比如你目前使用的是油氣車，以後的大趨勢又是電能，在兩者之前權衡，可能最後選擇的就成了油氣混合動力汽車，因為從很多人的角度來說，需要一個過渡，過渡中就需要有一個特殊的載體，既能滿足需求A,也能滿足需求B.
最後我們的需求就可能是C而不是A或者B了，這是好事還是壞事，真不好說，也不能一棍子打死，在不同的場景下可能意義大不同。
這是一個比較經典的圖。
在我們的工作中，做業務肯定會和業務方打交道，我們的工作中有太多的瑣事或者碎片時間是被這一類工作涵蓋的。
做過很多業務的同學，肯定會有一肚子的苦水，各種不規範，不標準，最後很多問題處理協調起來最終都是在做妥協。
我的理解是業務的高度就是信任，如果達到一種高度的信任，那麼去推動任何的事情來說都會容易很多。比如開發提了一個需求，只要你否定，而且給出理由，他們就絕對的信服。
這種狀態肯定是你們彼此做了很多的磨合和摩擦之後才可能有的。當然還是需要你能多為他們著想，從換位思考，能夠快速解決問題，而不是過分看重形式，其實很多事情都不完全是流程，甚至帶有個人情感的因素了。
為什麼在這裡提一下業務價值和技術價值，其實做運維開發的方向也是如此。用劉強東的話說，運維就好比在高速公路上給賽車換輪胎的角色，保證賽車的成績，同時能夠更快更好的支援。
3.關於運維開發的推進方法
很多人一看我們在做運維繫統，都會不大理解，我們找一些專業開發很快也能做好，或者總喜歡先從這個東西的核心價值入手。我的想法是運維工作本身就很難體現出成績，但是如果能夠提高效率，降低出錯的概率，而且這個事情很有挑戰，那麼這個事情還是值得考慮去做一下的。
做好了，你就是這個問題的終結者，觸類旁通，否則，就還是守舊。
關於運維平臺的事情，其實做了很多的磨合，擺在我面前的有很多的難點：1.做平臺的方向問題 2.做平臺的人員投入不足 3.做平臺的技術儲備不足 4.上層對這件事情的認可和支援。
上面的每一個點，都需要做很多的工作，事情要做，要推動，光有支援還不夠，細節的事情怎麼推動，團隊的人員怎麼聚合起來，從思維上到行動上，感覺是一個又一個的漩渦。
所以我總結了以下幾點，供參考。
1.主動思考，規劃，產出一定是文件，形式不重要，但是沒有輸出就沒有開始
2.共同提高，發揮團隊成員的優勢，不一定要讓所有人都全面掌握，要帶來希望，當然最好的方式是隻需要成員做功能接入就可以，那麼前期的工作就得自己做，這個工作量的事情就是另外一個大坑了。
3.怎麼做事情，無論規劃討論，原型討論，需求討論，討論都建議是半成品，成品，沒有基本的東西沒有說服力
4.關於進度的把控，如何跟進讓別人不覺得催，同時也不用所有細節都要一一來跟進，避免太瑣碎
5.從上到下如何來溝通，支援和明確支援確實不同，明確支援的話需要人，需要時間，需要價值產出，需要考慮資源的事情怎麼平衡。
所以面對一些問題和走過的一些坑，我開始做一些細節的改進了。
大家能夠根據自己的情況來參考，希望對你有一些幫助。
我的分享就到這裡，謝謝大家。
群友互動：
問題1:
問：做平臺的一個繼承性問題我覺得比較大，核心人員走了的話，來了新人，有可能帶來一套新的系統，甚至原來的系統覺得太複雜，覺得爛程式碼不想看，甚至一樣的功能在他熟悉的系統中做一次
答：這種情況在開源社群裡也很常見，很多開源產品維護一段時間就不維護了，要不開分支，要麼重新開發設計。達到一定程度之後就會有這種情況。公司裡來說，這種造輪子的現象，在人員流動較大的一些公司裡是比較普遍的了。這種情況下，如果有一些完善的文件，穩定的使用場景，或者是技術架構，程式碼層面好一些，被替掉的可能性也會小一些。
問題2：
所以從開始開發就要詳細的文件紀要，寫個架構圖呢，還是要寫個詳細的uml類圖呢，很多人覺得開發的功能你看程式碼就好
話外音：這個是最受不了的，程式碼看得懂業務邏輯不清楚也是一臉懵逼，連蒙帶猜的，再要是程式碼又不規範，命名完全不知所以的更是大坑了
答：
我覺得介面上的變化很大，但是能夠保留一些也不錯。主要是需求和通用設計層面的東西。
我以前也不愛可以寫文件，但是發現都整理好了，沒文件沒法體現。
這樣很多事情還是不明確。看不懂，不會做的概率就會大一些。
話外音：我想這就是大部分人看了一眼之前別人寫的程式碼就像自己重新寫的原因吧