運維在程序員的眼中是什麼

1. 計算機行業開發與運維的區別是什麼

開發就是做程序員。這個很容易理解吧，工作就是寫代碼，寫程序。程序員開發的項目，最終發布之後，上線交工之後。就需要運維來部署和監控，相當於項目的售後服務人員。

2. 運維和黑馬程序員的其他學科相比，有什麼優勢

1、與編程學科相比，我們不需要編程思維，運維問題的解決方案相對固定，更重要的是運維不會被年齡所淘汰，是一個越老越吃香的專業，類似日常生活的老中醫。
2、與設計學科相比，不需要美術功能，沒有設計靈感一樣可以成為專業運維工程師。
3、與產品經理相比，我們不需要協調各部門關系。
4、與電子商務相比，我們不需要文案功能。
5、與測試相比，我們的薪資更高，發展更穩定，未來更有「錢」途。

3. 為什麼開發人員都看不起運維工程師

首先到底做運維還是研發，這個一方面是看個人能力，更重要的是興趣。有些研發以為運維很簡單，沒有技術含量，不願意做運維工作；而更多的運維工程師看不起自己，自認為低人一等。這些觀念本身就有偏頗。

然後再說運維這個崗位。可以說包羅萬象，很雜。就跟研發似的，語言很多，但也只能精通其一，要說同時精通c/c++和java什麼的，估計內行人看了就笑了。為啥笑？這個道理大家都明白，人的精力是有限的，很少有人能夠同時精通多重技能。反過來看運維也是一樣的，不可能什麼都精通，但需要什麼都懂。除去個人因素，就是市場因素。就業市場上，大部分公司的運維人員配比其實很少，就跟財務、人事、行政差不多，甚至更少。這樣就要求運維工程師一人身兼多職。辦公室內部小到電話網線，出了公司能夠給客戶解決問題等等。而大公司可能分的細化一些，同樣都是「運維」類崗位，有些人專職對內部，有些人專職對某項目，這樣比較有利於運維工程師向更深層次發展。
最後就是關於這個職位將來要如何走下去，這就是個人職業生涯規劃的問題。不管是轉研發，還是繼續做運維，都是個人的選擇。永遠不要去看別人如何如何，先要問自己想要什麼，想做什麼。運維到了高級就不單單是運維，更多的是架構設計，也包括研發（devops）。而研發到了高級，也必須懂運維。這些都是相輔相成的。

4. 運維在程序員眼裡是個什麼東西

在大多數程序員嚴重，管理層、運維、市場、客服等都是沒有技術含量的，因為程序員的邏輯思維能力很強，在以往的人生道路上也都是比較優秀的群體，所以往往對自身評價很高。但同時，大多數程序員心裡其實也清楚，有些事情他們也做不來，比如做市場，天天跟人打交道，往往就是絕大多數程序員最不願意做的事情。
其實，每個行業分工既然存在，就必然有其存在的價值。

5. 運維工程師是青春飯嗎

不是啊。運維工程師需求很多知識面。

網路基礎+操作系統（核心學linux）網頁鏈接+資料庫（待遇高便於提升深造）；系統運維的工作越來越有經驗，軟體工程師就是吃青春飯。做系統運維，以後可以轉向管理，職業很有前景。建議你先學一個基礎，然後工作1年再深化培訓。 可以學RHCE+CCNP+OCP,WINDOWS的我想你每天自學也沒問題可以不學，系統運維就是比較細 雜 廣 系統運維要求什麼都懂一點，主要是基於Linux、UNIX有前途，shell 網路 資料庫都需要懂一些。越老越吃香 知識不需要太多創造性的東西 了解基本規律 然後去部署排錯 以後轉管理。

6. 運維的資深運維工程師眼中的運維

以下是中國互聯網業界部分資深運維工程師對運維的看法（涉及隱私，相關人名採用首字母縮寫）：
CXY:
運維是一個非常廣泛的定義，在不同的公司不同的階段有著不同的職責與定位，如果以operation字面的含義去理解，認為就是敲幾行操作命令的工作，那就錯了。 對於初創公司，運維工程師的工作可能需要從申請域名開始，購買/租用伺服器,上架，調整網路設備的設置，部署操作系統和運行環境，部署代碼，設計和部署監控，防止漏洞和攻擊等等。對於大型的公司，對於運維工作的要求越來越高，也催生了更細化的運維分工：從大的方向，可以分為網站運維，系統運維，網路運維，資料庫運維，IT運維，運維開發，運維安全等方向。
很多非從業人員對運維的看法一般屬於IT運維的一個非常小的職責：裝系統^^。 一些研發工程師對運維的看法也只局限運維工作的幾個點：部署, 變更, 監控，響應。
無論做什麼運維，最基本的職責都是保證業務能夠穩定運行。所以必須成為業務穩定性的owner。有些人通常認為運維工程師像消防員，7*24小時響應異常，救火。但是穩定性的運維工程師和醫生的職業更接近。醫生也分各種科室，也有急症室，需要先判斷病人的問題，對症下葯。
業務有著各種各樣的需求，如果運維工程師能夠滿足業務需求，或者主動挖掘業務的痛點和改進方法，就能為業務實現更多的價值。
在滿足業務需求時，應該分清主次，優先面對業務快速發展非常重要的需求，例如穩定性，部署和變更效率，容量管理。穩定性不用多說，如果用戶沒法穩定使用你的業務，什麼產品特性都沒有價值。對於網路這樣極速發展的互聯網公司，每天都有大量的升級更新需要提供給用戶，如何在異地的大集群上最快的滿足產品的升級需求，同時讓用戶對升級過程無感知，這是我們的追求。當用戶會用網路來測量網路是否可以上網時，就是對運維質量的褒獎。
其次，可以橫向看看不同業務的需求。如果能夠把多個業務的需求抽象出來，把一些有通用價值的工作平台化（例如資料庫，cdn，監控，流量接入和調度，大數據的存儲和計算），也能在這個方向進行深入的發展。在網路這樣的巨大的流量和伺服器規模下，你不僅有巨大的空間和挑戰，也有著充足的資源和支持，可以開發和應用業界最前沿的技術。
有一定的積累後，可以進入到宏觀和微觀的兩個層面，從整個公司層面考慮業務的智能部署和調度（涉及網路，硬體，系統，應用開發方式等各個要點），進一步提升效率和節省成本。
如果能夠懂業務，理解業務的模式，緊密結合業務進行優化和創新，也是運維工程師體現價值的另外一種方式。有很多產品上的創新，專利的申請，論文的發表，業務指標的提升，直接或者以合作的方式由運維工程師貢獻。
YBX:
運維工程師相對研發人員來講，可以全局觀察所維護的計算機系統，特別是高階運維工程師，不存在模塊界限，這種獨特的位置帶來很多價值： 知道准確的系統瓶頸點，進而知道系統准確的容量；在系統出現瓶頸前，知道如何快速提供容量。 知道系統的風險點，可以協調風險點上下相關關聯模塊，做出冗餘策略；相比集中解決單點模塊穩定性，更合理。 長期從事相關工作，積累較多的架構設計經驗，可以指導新架構設計和審核。 從公司不同業務角度看，運維可以從中抽象相同的模塊，統一管理，形成有效的平台和自動化管理方法 同樣從公司不同業務角度看，可以統一調配資源，進而節省資源。
KZ: 設計並實現可以提高公司服務可用性，可擴展性，延遲和效率的軟體。 處理日常緊急事故，修正，替換問題組件。並設計規避問題方法。 設計和實現新的超大規模分布式系統架構和標准。 參與服務擴容計劃和預測服務增長趨勢，對軟體和系統性能進行調優。 提供在線咨詢服務和現場解決問題服務。 構建自動運維平台，解決日常問題。 構建知識庫，預測可能的問題。 XX:
運維即生產環境以及和生產環境相關的資源、服務的維護的整個過程，包括了相關的技術、流程手段，確保生產環境穩定、高效、低成本的運行。
運維一方面為對業務功能最終負責，其價值的體現為最大化助力產品價值的發揮。這通常是通過將產品功能的運行表現提升到極致來達成的。例如搜索引擎的運維重點要保障用戶在搜索時候的極致體驗：穩、快、准、新、全。而一個在線聊天系統的運維應該是確保用戶聊天過程的實時與順暢。另一方面為對在線業務的成本最終負責。其價值的體現為降低服務運行成本
運維工作的開展方式一般取決於所維護的業務特點需求，形成所需的多個主題方向進行開展。通常的解決方案中包括如下的一些主題方向：事件管理、配置管理、變更管理、容量管理等。
運維工程師的要求特別嚴苛，因為運維工程師針對不同的問題，需要不斷的補充擴大自己的知識和研究范疇。
在初級階段，優秀運維工程師會體現出格外出眾的主動性和責任心，面對陌生的業務會主動學習和拓展自己對業務對認識和相應的知識范疇，以能夠足夠的勝任業務的獨立維護。
在逐步的發展階段中，注重總結反省的工程師會逐漸成長為高階運維工程師，通常他們會有比較體系化的服務運維理解。也有一部分工程師由於出色的項目管理規劃能力，逐漸成為項目經理
再進一步的發展，高階的運維工程師對於產品的理解將非常的透徹，因而在這種情況下，高階運維工程師甚至可以成為產品的產品經理、產品研發的咨詢顧問，在產品功能的設計與開發中起到至關重要的角色。
SJY:
一個運維工程師所需的技術體系以其專業方向而異。但基本的計算機系統架構，操作系統，網路技術的掌握是基本要求。例如你可能需要熟練掌握linux操作系統的使用，熟練使用各種腳本工具來處理日常工作任務，精通TCP/IP協議棧以排查一個大規模網路系統中的流量異常問題等。更進一步的你需要形成一套軟體可運維性方面的經驗積累，以此作為後續工作的指導。
一個運維工程師在初期階段目的是掌握維護一套系統所需的所有軟硬體知識和經驗。進階階段是需要能夠設計開發一套基礎的體系軟體，以支撐業務系統的穩定可靠運行，即開發服務於軟體的軟體，以支持更大規模的業務系統，提高運維生產力。最高階段是反作用於軟體系統的構建和運行階段，使得系統從誕生階段起即具有天然的可運維性，以最大化系統的生產力，同時最小化對外部支撐資源的依賴。
ZM：
運維工程師首先應該是軟體工程師（Software Engineer），只是責任和側重有所不同。
運維工程師不是系統管理員。和系統管理員最大的差別是，運維工程師的工作不僅僅是配置和管理系統，而且可以運用軟體開發的方法來增強系統的功能、或者對數據進行分析。
運維工程師應該是軟體工程師、系統工程師等角色的綜合體，和一般軟體工程師相比、應該具有更加廣博的知識背景
運維的職責在於： 保證服務的穩定運行； 考慮服務的可擴展性； 從系統的穩定性和可運維性的角度，提出開發需求； 定位系統的問題，甚至可以直接修正bug； 對突然出現的問題做到快速響應和處理； 運維的日常工作： 需要對系統的需求和設計方案進行分析，思考在保證穩定性方面有哪些可以加強的地方，並和系統的研發人員進行有效溝通； 使用工具、或者寫程序，對運營數據進行分析； 寫程序以建立工具或平台，去加強系統的穩定性； 運維工程師最重要的是會運用編程和軟體的方法來解決問題。發展的道路應該和軟體工程師沒有很大的區別，差異只是關注點和領域方向的不同

7. 做it運維，和做程序員的區別

運維：系統運維、主機運維、系統維護，編程相對程序員少，對技術的廣度、心理素質要求較高；
程序員：使用某種編程語言或者幾種編程語言進行產品研發，或者做項目，編程較多。

8. 程序員面試，為什麼感覺很多都和運維有關

不會運維的程序員不是好程序員。 這個信條要時刻謹記，不管是面試還是自己平時在工作中都要堅持這個准則，因為這對你以後的發展大有裨益。

一直以來，很多圈外人對我們程序員的觀念就是永遠的一本正經，著裝單一，了無生趣，聰明絕頂，其實這是他們對程序員的誤解，因為多才多藝，多姿多彩的程序員比比皆是，但是傳統的觀念或者說以偏概全的觀念蒙蔽了他們的雙眼，而他們自己又沒有嘗試去了解，所以導致人雲亦雲，給程序員披上了一層灰。

同樣的，我們大部分程序員的觀念也跟他們差不多，認為程序員就只是搬磚擼碼的，至於各種部署伺服器相關的工作應該是運維做的，其實非也，如果真的這樣認為的話，那就真的太不把自己當程序員了。為什麼這么說呢？因為我們程序員是實實在在擼碼開發產品的群體，可是如果我們開發出來的東西只能自個在本地玩耍，卻不能眾樂樂，那還有什麼意義，此時，你可能會說，交給運維啊，那麼如果沒有運維呢，就沒法玩了，所以我們不能總是將希望寄託在別人身上，當自己有能力能夠將系統進行部署的時候，那就該學會部署。

其實不僅僅是程序員，優秀的運維工程師也是需要會開發擼碼的，因為有時候他們也需要開發一些小工具來進行驗證，或者開發網頁來進行服務的管理，所以說程序員和運維都是相輔相成的。

像我們現在很多的公司都沒有明確的人員分工，特別是小公司連運維都沒有，所以就談不上讓運維去部署了，那麼怎麼辦呢？肯定就是開發人員自己去部署了，如果不會部署的話就可以去網上查找資料，其實總體來說不會很難，因為我看過很多運維其實也是在網上找資料按步聚進行操作。

另外公司之所以這么要求，一方面是基於人員成本的考慮，畢竟如果一個人能幹好的事為啥非得招兩個人；另一方面可能基於公司的發展問題，像一般的小公司確實沒必要專門招一個運維，不過隨著公司的發展，後期肯定會招專業運維，畢竟專人做專事，事半功倍。

永遠記住「不會運維的程序員不是好程序員」，其實作為程序員不能總是把自己陷在擼碼的深淵，除了擼碼，我們還要學會產品需求分析、簡單的UI畫圖、資料庫分表分庫及性能優化、運維伺服器部署、單元及系統測試等等，總的來說，要想成為優秀的程序員，我們有必要把產品線上的每一個環節都略知一二，這是經驗收獲，一定會成為我們日後發展的資本。

技術迭代是需要時間的，而且公司預算不多的話，會選擇現有系統繼續使用。有的企業也會選擇維穩，不會輕易開發新系統代替現有系統。

這是一個非常好的問題，作為一名IT從業者，我來回答一下。

首先，在當前的大數據、雲計算時代，程序員在面試的過程中，經常會遇到與運維相關的問題，尤其是有自身產品（平台類）的企業，往往對於程序員的運維類知識有比較多的要求，所以當前的程序員，尤其是Java程序員，要想獲得較強的崗位競爭力，一定要重視運維類知識的學習。

在當前的大數據時代背景下，很多程序員在日常開發過程中，需要與運維人員進行配合，所以程序員在面試過程中，經常會被問及與運維相關的問題，通過這樣的問題，也能夠全面了解程序員是否面對過大用戶的並發問題，這對於判斷程序員是否適合當前的招聘崗位也有一定的參考價值。

以大數據開發崗位為例，程序員在進行大數據任務開發的過程中，不可避免地需要與運維人員打交道，其中大數據平台的搭建就是比較繁瑣的過程，另外還有一系列產品的安裝和部署，這些通常都需要運維人員來完成。對於一款平台類產品來說，運維人員的技術能力能夠在很大程度上決定軟體平台的性能，而且運維人員與開發人員的配合也非常關鍵。

當然，對於程序員來說，如果能夠自己掌握一定的運維知識，對於開發任務的開展還是很有幫助的，如果什麼問題都需要運維人員來完成，不僅需要更多的運維人員，同時也會影響項目的整體開發進度。從這個角度來看，隨著未來大數據技術的逐漸落地，程序員掌握一定的運維類知識，對於提升自身的工作效率，還是很有幫助的。

在程序員面試過程當中，通過一些運維知識也能夠更加直觀地了解到程序員的技術棧，相對於比較復雜的開發問題來說，運維知識的脈絡還是比較清晰的，通過運維知識能夠在一定程度上擠出一些「技術水分」，這也是很多面試官比較願意問運維問題的主要原因。另外，對於一些創業型公司來說，程序員掌握一定的運維類知識，也會節省一些投入，尤其在產品研發的初期。

從技術體系結構來看，要想解決大用戶的並發問題和系統擴展性問題，通常需要從兩個角度出發，一個角度是技術選型，比如採用擴展性比較強的大數據平台，另一個角度就是硬體擴充，但是硬體擴充的前提是要有一個可擴充的平台體系，而通過運維知識，程序員的交流會更明確，技術方案也比較直觀。

從崗位任務劃分的角度來看，程序員的工作任務與運維人員的工作任務有比較明確的邊界，但是在雲計算技術的推動下，程序員接觸運維場景的情況也在不斷增加，比如通過雲計算平台的支撐，很多傳統的運維類任務，程序員也會比較方便地完成，比如安全配置等等。

最後，程序員在進行面試的過程中，如果遇到的運維類問題並不清楚，一定要如實回答，因為運維類知識需要一個積累的過程，而且經驗往往非常重要，所以很多運維類知識，在短期內是無法掌握的，如果盲目擴展自己的知識面，會為後續的工作帶來很多麻煩。

如果有互聯網、大數據、人工智慧等方面的問題，或者是考研方面的問題，都可以在評論區留言，或者私信我！

一、提問之前的准備

首先，最重要的是，你自己一開始就應該想清楚：

只有明確這些根本性的問題，才能正確高效地完成面試。

二、提問的原則

假定你對上一節的三個問題，已經有了清晰的想法，那麼接下來就可以設計如何提問了。

有一些提問的原則，是你應該遵循的：

三、考察專業能力

為了確認面試者是勝任的，你可以問一些與職位相關的專業方面的問題。（不過通常來說，一次面試不足以看出一個人的專業能力。）

比如，你的招聘職位是系統管理員，你可以問"如何快速地在50台機器上部署Linux？"（提示：正確答案不是刻錄50張安裝光碟。）

另外，你還應該向面試者了解他的過去，因為過去是未來的最好預測依據。不過，提問的重點不要僅僅是他過去的成果，更要關注在當時的環境中，他是如何決策和實施的。

四、考察綜合素質

因為人是會發展的，所以某種程度上，面試者的綜合素質要比他的專業能力更重要。

所以，具體的技術問題（如何調用API、什麼是設計模式、編程語言的語法等等）可以少問一些，更應該關注面試者的事業心、對工作的熱情、進取心、自律能力、毅力等方面。

下面是一些典型問題：

五、考察理性思維

某些情況下，你可能需要了解面試者的分析判斷能力，看他能否全面地思考問題、客觀地評價自己。

那麼，你可以依次提出這樣三個問題：

這里的重點是，讓面試者從正反兩方面評價一件自己熟悉的東西，看看他的思維是否片面。答案無所謂對錯，只要面試者有一個明確的立場，能夠從正反兩方面說出令人信服的理由，就可以了。比如，某個軟體的口碑不好，但是面試者說他很喜歡，而且說得出一大堆理由，清楚地解釋了這種軟體的優點和缺點在哪裡，這樣就很好。

不邀自來。眾所周知，越大型的公司，分工越明確。在BAT裡面，有專門的前端，後端，ops，dba等等。他們專研一方面，所以有深度，有沉澱。遇到問題了，找到相應的人，能夠快速解決問題。

但絕大多數中小公司，更偏愛樣樣都會的全棧，恨不得你一個人把所有活兒做完。並不一定需要有多大深度，能幹活兒就行了。

再說，現在提倡devops，開發懂點運維，能夠更好地定位問題，部署和架構項目，這是需求，也是趨勢。

對小公司而言基本沒有專門的運維，所以需要研發具備一些運維的知識，比如資料庫的搭建、nginx、jdk部署，其它開源中間件，比如Kafka、es等等

其實這個目前真正大規模用的少，炒概念的多，很多公司根本沒機會用. 但是他會問

我覺得很自然的事，為什麼總有人說得高大上？裝個軟體，調個參數，做個邏輯卷，調一調網路，配置一下分布式組件，搞個文件系統程序員就應該不會？

這些工作，我們公司一般運維人員搞不定的。所以用啥，自己整。

個人觀點，計算機知識就必須全面，才能做好一個程序員吧？

而且看大家回復，我有8成猜對，有8成以上的架構師，不懂底層，知識面也沒傳說中那麼廣。

現在devops在流行，說白了企業為了省成本，研發要干一部分運維的活。運維只負責硬體網路和k8s維護，其他什麼部署啦，服務編排啦，通通交給程序員做。

不過這樣倒也合理，運維只負責全公司通用的設施建設，至於cicd，服務編排，熔斷限流等等，都和業務強相關，交給開發做比較貼近實際業務

9. 運維、測試、程序員，這些技術崗位哪個更有前景

在一個初具規模的互聯網公司，從業務方面出發，有很多崗位類型，比如運營、客服、市場、產品、設計、技術等等。

在這些大類下面，還要細分各種小類，以技術為例，可分為前端（客戶端）、後端、測試、運維、DBA等等，這些都是技術類崗位。

那麼如果想從事這些技術崗位，該如何選擇，哪一個更有前途呢？

這五個崗位，可以做一個分類，前端和後端、運維和DBA、測試

前端和後端屬程序類，也就是通常大家知道的程序員，主要是根據產品的需求開發出軟體，屬於公司的技術核心，非常重要。沒有程序員的軟體公司，也不好意思稱為軟體公司。

運維和DBA，這兩個崗位的主要工作是管理伺服器程序運行的環境和依賴的數據。運維可以看成是伺服器管理員，所有跟伺服器相關工作都是由他處理，比如伺服器程序運行環境CPU、內存、磁碟資源監控、網路是否穩定監控，伺服器程序依賴的軟體安裝等等。DBA就是資料庫管理員，專門管理生產環境的資料庫如MySQL、Redis。這兩個崗位的工資不一定比程序員低，但是市場需求沒有程序員旺盛。一家軟體公司可以沒有運維和DBA，但是不能沒有程序。運維和DBA一般只有上規模的企業配備，小公司都由程序員兼任，畢竟如果公司只有個位數的伺服器，完全沒有必要專門配備一個運維，老闆也不願意花這個錢。

測試，雖然也是技術崗位，但是我個人感覺他們的工作不和技術掛鉤，他們的工作就是不斷使用程序員開發出來的軟體，找出其中的BUG和漏洞。與此同時，他們的另一項工作就是督促程序員幹活，修BUG。

論這些崗位的技術含量，我覺得測試是最低的，低端的測試幾乎沒有技術門檻，只要有軟體使用經驗，基本上都能乾乾測試的活，畢竟只是用用軟體找找BUG嘛，而程序和運維則不行，必須掌握基礎的技術技能才能上崗。當然高端的測試另當別論，他們也可以牛逼到天上。

其次是運維，當然並不是說運維這個崗位沒有技術含量，同樣運維的技術含量也很高，只是通常情況下，程序員都會點運維的工作，裝裝環境，監控下伺服器運行情況，都沒什麼問題。反過來，運維卻不一定會程序員的工作。我覺得運維應該是脫胎與程序員，然後隨著行業的發展，獨立成為一個崗位，本質上還是依附與程序員。

最後則是程序，一個合格的程序員，不但要掌握程序員本職的技術，還需要會伺服器運維的技術，比如自己搭建一個測試環境，這樣的技能是必須的，所以對伺服器必然要有較為深入的了解。同時需要會DBA的技術，通常DBA是在數據量巨大的情況下才會配備，大多數時候一家公司不需要DBA，DBA的工作的都由運維或者程序員兼職的。與此同時，程序員還需要測試技能，當程序員寫出來一個程序時，免不了要進行自測，寫測試用例等等，只有經過自己測試，才可以將功能提交給專門的測試人員進一步測試。

所以，對於這三類崗位，我覺得程序員的技術含量是最高的。

我們再來說說這些崗位的發展前景。

對於一個大公司來說，會有專門的研發部門、運維部門、測試部門，然後設有研發總監、運維總監、測試總監，這些領導在公司的身價不相上下，不存在誰壓誰一頭的情況。但是在小公司通常只有一個技術部，這個部門管轄所有技術類員工，包括程序、運維、測試，甚至有的公司還會包含設計人員。而技術部門的領導十有八九是程序員出身，幾乎不太會是運維或測試出身。因為一個軟體公司的技術部門，沒有運維和測試，照樣可以運轉，雖然有可能轉的不順溜，但是一定可以轉，但是沒有程序員，即便運維和測試配備的多麼強大，這個部門也轉不起來。其次一個技術部門程序員的數量絕對是壓制運維和測試人員數量的。因此在程序員中出技術部門領導的概率遠大於在運維和測試中出領導，除非真的遇到難得一見的人才。

所以，如果你想從事互聯網軟體行業的技術崗位，要想選其中比較有前途的技術類崗位，那麼首選程序員，當然，更多的機會也意味著有更大的競爭，同時也有更大的難度，你選擇程序員不見得一定會成為技術部門的領導，選擇測試和運維也不意味著職業生涯會默默無聞，只是相對來說程序員的情景更加明朗。

與此同時，關於35歲程序員會被淘汰的觀點，其實運維和測試的危險性更大，仔細想想難道不是嗎，運維和測試並沒有比程序員更有優勢，反而劣勢一大堆，那麼肯定比程序員先一步面對淘汰，這是市場規則。