為什麼運維（SA）普遍反對使用 CentOS 7 ？
補充一下為什麼我要使用CentOS 7，而且要求運維還 CentOS 7
--------我可以理解大爺們反對使用ubuntu，而且我也反對在伺服器上使用ubuntu。但是CentOS，大爺們還是不支持對生產環境使用CentOS 7。
- 不管是開發者，還是學生學習，都會也都應該去選擇當前穩定且最新的版本作為開發環境。不知道這一點是否還有人反對。請注意原則關鍵詞：
- 」穩定「：這一點不管是開發或運維，都是有責任保障的。
- 「最新」：老的版本會有更大的概率存在安全漏洞或者功能缺陷。而新的版本不僅漏洞出現概率小，即便是有漏洞，也可以獲得更多的社區和企業支持，更快的修復。
- 當運維將開發者在上述環境的生產成果移植到線上時，運維有責任保障對於開發來講，無移植成本。腳本開發可以寫，開發真的可以寫。
rsyslog版本還在v5.8.10。大爺，現在都v8.16.0了！我把版本號位移一下都不能跟上時代了！
要是說非得用長期版本，rsyslog的epel-6也有v8.x了。為什麼？除了人懶我真想不出來其他原因。
之前剛剛在知乎上面看到一個很有意思的問題： 有哪些產品經理認為很簡單，實則開發很難的技術？ - 前端開發
我覺得是不是應該提一個問題：有哪些程序員認為很簡單，實則實施很難的運維技術？
如果升級系統只需要找個實習生搞半個小時，那肯定給你升級，一點問題都沒有，但是並非如此。
別說升級系統，就光說升級 rsyslog
如果你的 rsyslog 架構非常複雜（比如需要從幾千台機器上過濾不同的日誌到不同的日誌收集伺服器裡面做處理），而且絕對絕對不可以容忍丟哪怕一條日誌甚至是半條日誌（長日誌被截斷），那麼升級 rsyslog 就是一件非常非常複雜的操作，複雜程度很可能超出程序員的想像。隨便舉個例子，rsyslog 各種不同的配置之下，遠端宕機或者網路出現波動，再恢復正常之後，表現如何，什麼情況下會丟日誌，什麼情況下不會？這都是需要大量的測試和源碼閱讀的，每次新版本更新之後都需要重新測試和重新閱讀源碼的你不測試，最後一個網路波動你日誌丟了，運維要承擔責任的。
對於重要的系統，很可能制定測試方案，編寫測試腳本，測試，就得幾個人搞個一個月，然後再升級（要知道 rsyslog 重啟的那一瞬間會丟日誌的，必須制訂一套很複雜的升級方案才能確保日誌不丟失），機器多的時候很可能又要搞個幾個月。一個人一個月一萬塊錢工資的話，那就意味著公司要為升級 rsyslog 版本付出可能十萬塊的成本。
升級 rsyslog 能夠給公司帶來十萬塊的利潤嗎？如果你能證明升級 rsyslog 能夠給公司帶來非常大的利益（比如性能大大提高，可以節省伺服器資源，從而降低成本），找運維老大談，我相信他會答應的。如果你證明不了，那他就未必答應了。
看來題主沒有遇過什麼絆腳石，這樣吧，我就結合自己的經驗跟題主嘮嘮嗑兩句。
首先，對於初學者或者打算學習Linux的童鞋，當然選擇最新版本來上手最好。這點是毫無疑問的，不選擇最新的，難不成還要選個淘汰的？
但是，對於工作上、對於企業上，卻又不是那麼一回事了。可以說，企業技術跟最新技術一直都是一對不可調合甚至互斥的關係。這個我打算列出以下幾點來詳說：
1、這並不是說什麼開發大爺太懶或者運維大爺太爛，而是現實往往太殘酷了
學習的時候，環境一般都是實驗室化（理想化），所遇到的問題也相對簡單。而真實的生產環境中，環境一般更加複雜，所遇到問題也複雜度也往往百倍於學習時所遇到的。這個時候，就來不得任性了，必須要循規蹈矩來。2、既然現有的環境沒有問題，為啥還要換
小米5已經出來了，那正在用小米1、2、3、4的用戶，是不是應該把當前的手機扔掉，買一台新的小米5呢？這很明顯是不可能的，又不是錢多人傻，為啥要把好端端的手機扔掉買一台最新的？結合到生產環境中，當前的系統都已經穩定的運行，為啥要扔掉再裝一個新的？！
什麼？新系統會修復bug？這個bug不關我事，我的系統一直正常運行，明顯是沒有踩這個bug的。爪窪8發布了，我作為一個Haskell的開發者，沒理由跟著歡呼吧？3、換系統往往帶來潛在的風險
一個程序要正常運行，不僅要求自己的程序沒有問題，還要求他依賴的軟體包沒有問題，而開發大爺們所開發的程序往往都引用了大量的其他程序包，有得還調用了不少的操作系統API，萬一他們出了問題呢？這裡我就分享下自己的兩個傷疤好了：傷疤一：答主以前還在讀書的時候，開發的某套系統，已經在線上跑得好好的，後來某老師把這套系統賣給了某學校用，結果上線了之後，發現運行報bug了，分析之下發現環境變數「__PUBLIC__」解析出現異常，通過兩天的排錯，答主發現這是運行環境不同所引起的，答主的環境是「5.3.9」，買了這套系統的學校環境是「5.4.0」，就差了這麼0.0.1個版本，細查該軟體包源碼後天殺的發現，有一個函數的實現被開發者們偷偷的改了，再調用這個函數的話會輸出另外一個結果。傷疤二：答主以前在make 「libgdiplus 3.x」 的時候，拋出了一個Error說某個依賴包版本太低，需要更新（比yum中最高版本還要高），然後答主通過源碼的方式編譯更新這個依賴包，沒想到這個依賴包又提示其他依賴包不夠新。。。。。就這樣，答主最後把gcc、llvm、glib都用源碼更新了一遍，最後的結果就是：原本正常的其他程序變得不正常了。換一個軟體包所帶來的風險尚且如此，那還一個內核呢？可想而知了。4、項目最擔心的就是out of control
項目是不斷壯大的，代碼量會越來越多，結構也會越來越複雜，很多中型或者大型的系統都是一個大的團隊，持續開發數年所誕生的，代碼量十萬行算少，百萬行不算多。而這種項目一旦失控，那後果是不堪設想的，說白了就是，即便出bug了，光查都查死你。而像3這種情況，簡直就是自作孽不可活的典範。因此，一些大的公司諸如騰訊阿里都會對某些重要的軟體包或者操作系統進行自維護，就是為了減少因為「某函數被偷偷改寫了」所引發的災難。5、出問題了，這個鍋誰背，這個bug誰調
好了，前面的1、2、3、4可能題主完全還一臉茫然，這點就最直接了。出問題了，誰背這個鍋？半夜出現了系統報警，誰來起床秒登VPN解決？12小時內修復這個BUG，誰自然為有能力在數十萬行代碼中遊刃有餘？
沒有沒有沒有重要的事情說三遍，除了傻子，沒有人想自找麻煩，即便你多麼勤奮，即便你多麼努力。你的勤奮和努力完全可以用在學習上，而不是自找麻煩上，不然這就不是情商的問題，直接是智商的問題了。手碼字，好累，同意的請給個「贊」
我也算是一個運維管理人員，瀏覽了樓上的一些答案，大部分贊同，但也有點補充；
如我自己評估是否要升級一個基礎系統（如操作系統，資料庫，中間件等）到一個新的版本，會考慮如下幾個因素：
1，升級能帶來什麼好處？ 性能改善？安全提升？管理能力提升？功能完善？bug消除？2，升級的難度和風險？3，業界是否有成功案例？外圍的第三方技術支持能力是否已經跟上？4，是否還可能會涉及到商務問題，升級是否會影響軟體的版權和技術支持等；我比較反對樓上某些人提到的是因為不熟悉而不升級，實際上如果能帶來明顯效果或解決重大問題，我覺得大部分運維人員很樂意去學習、測試、驗證新版本並推動升級的；(在我自己的經歷中，也都是運維推動各種基礎系統的升級換代，包括操作系統，資料庫，中間件等，從沒一次是由開發組推動的導致的，反而經常是開發的老大反對基礎系統的升級）；
但如果只是為了滿足一些新人/個人的好奇心，純粹是為了升級而升級，或者帶著「美好」的理想：升級「一定」會得到更好的結果，這種無知的想當然，那我覺得這種人在運維界呆不長久的；同樣也反對某些人的穩定導致」絕對否定「變動升級，誠然，基於穩定會否決掉很多可能的升級，特別從更高級別的領導角度來看問題，但主要原因還是升級的風險大於升級的收效；但最關鍵的是，其實很多運維的人，是無法清晰的表達升級後的量化收益的，以及相應的風險防範措施，這是高層經常否決變更的一個很重要的原因；從我自己實際的經歷，從aix4-&>aix5-&>aix6, 從rhel2 -&> rhel3 -rhel4 - rhel5 - rhel6 -rhel7 幾個大版本（甚至有些小版本）的更換，都會帶來後續的一系列變化，包括安裝方法的變化，影響上層應用的安裝部署及調優參數，備份系統（如nbu, cdp）的設置調整，個別也會影響到和主機硬體的適配以及外置存儲設置的；少數幾次升級後，會影響到上層業務應用的正常操作，需要開發人員介入協助調試；少數幾次上層應用運行異常，需原廠支持或給出新的補丁；相當一部分運維人員，是沒有掌握這種應對變更風險的項目管理能力和技術能力，所以這部分人很抗拒變更，是正常可以理解的，遠比那些不顧風險盲目進行升級的人更勝任這個崗位；
看到這個問題，我也想到當初和開發人員的一個類似溝通，為什麼java6 出了這麼多年，你們開發還老是使用java5? 為什麼java8出來了， 你們還停留在java6? 導致了一些很好的管理和調優參數都沒法用；
如果你是開發人員，可以試著從這個角度去思考和理解這個問題；
反正我自己經歷過的一個開發項目，從java5升級到java6（估計源代碼幾十萬行），花了5個開發人員接近3個月的時間全職進行；從更高層的老闆看，這幾個人月的付出是看不到明顯回報的，系統功能還是那個功能，性能也沒明顯區別；從此項目後，我有點理解我上面問開發人員的問題。從我理解，升級遷移是需要成本和有風險的，投入是需要產生回報的，如果這些問題能清晰，是否升級的結論也就可以比較簡單得到；
先說倆題外話：
- 為什麼這麼多人匿名？有什麼見不得人的？
- 什麼叫「大爺」？你家公司內不是合作，是拆台嗎？
- 你不是一個人在戰鬥，你在團隊中。
- 團隊是由各式各樣的人組成的，各類人的比例和社會上基本相同。
- 就是有很大一部分人只是混口飯吃，多一事不如少一事。（比如很多答案都提到了「誰背黑鍋」這個問題）
對於這種社會規律，要麼你就接受，要麼你就通過改進生產工具來提高勞動生產率引發小範圍「工業革命」（其實就是DevOps的思路），抱怨現象是沒有意義的。
有一個提到DevOps的答案是匿名+反諷，但是我支持字面的意思：you can you up。一個人能扛下來運維團隊的工作，沒有領導會反對，那時候混日子那部分人態度會轉變，有了失業的壓力。主觀的因素
技術本身是有優劣的，題主對「最新」+「穩定」的分析是有邏輯的，但是管理一個團隊的目標是產出高。招不到10個同樣追求極致的人，招20個一般的也能有一樣多的產出，但是質量會降低到這20個人的平均水平。9.9×10 &< 8.0×20 大家都會算。只要把握好平衡，不要出現劣幣驅逐良幣的狀況，團隊就能維持下去。這是一個人為的平衡。DevOps
最後回歸說技術，一個人扛下運維團隊的工作是絕對做得到的。代價是程序本身要提高自動化能力和設計整體容錯恢復機制。如果說「業務運維的存在，是替開發的懶惰在擦屁股。」，一樣有道理。但是，上面提到的「運維懶惰」和「開發懶惰」是兩個層次的事情。開發作為製造者，有能力破局。運維沒有能力去改進系統的功能。
系統里任何不滿意的地方，歸根結底都是開發沒做好，不要怨別人，先改變自己。centos7 換成了systemd，不少運維腳本都得重寫了。
運維和開發在使用新版本的問題上利益是衝突的。從開發看來，新版本帶來的新功能之類能為開發帶來便利。但是對運維來說，穩定是最重要的。新版本的好處主要是開發享受了，但是萬一出了問題，黑鍋是要運維背的。所以運維在更新OS這件事上，態度消極是正常的。現在不都DevOps么，自己寫的code自己管，自己上線自己維護，自己吃自己的狗食。出了問題自己半夜爬起來修，修不了滾蛋。
看來問題比較嚴重，建議貴司設立CUO(首席升級官)一職專門督辦此事。
沒錯，樓主我支持你，開發和運維就應該選擇穩定且最新的版本嘛，運維的懶惰不應該讓開發買單，開發的懶惰也更不能讓讓產品買單。
你們用的是什麼開發語言哪？C啊，那必須C11吧，GCC也得跟上5.3啊。哦，是C++啊，那一定得C++ 14啦，編譯器也搞到最新，Gcc，Clang都得更新。其實這倆古董也太老了，能重寫的都用Go重寫吧，1.6都發布了，這才符合2016這個時代嘛，
哦，你們不用這些還在用Java啊，那肯定得Java 8 吧，話說Java這麼老的也還在用啊，用Kotlin，Scala，Groovy什麼的重寫吧。另外，你也說說你們哪些同事啊，Python怎麼不是3.5.1啊；PHP怎麼沒上7啊；JS是時候使用ES2015 了，就必須得使用穩定且最新的。
上面決定了，由你來負責這件事件，能升級版本的升級版本，能更換語言的更換語言，落後的框架要拋棄，不兼容的代碼就重寫，原維護人離職的就重構，輪子要是還沒有的自己造，否則怎麼跟上這個時代，順手的相關資料庫啊，中間件啊，別管分散式不分散式，NOSQL還是SQL產品都統統升級升掉，你那一年200G的數據怎麼還放在資料庫里啊，上大數據啊。反正是能說得出穩定且最新版本的都升掉！
啊，你說我神經病，你怎麼罵人啊，我看你是工作不積極，懶惰，開發的懶惰想要產品來買單，你把電話留下，我給你介紹幾個像樣的產品經理！哦差點忘記了，不要放過Perl這貨，他的最新穩定版本是Perl 5.22.1，別以為躲了27年我就不記得！1。沒見識過這種運維大爺。
2。我的態度從來都是，開發要用啥都行。但是，但是，但是，兼容性有問題了，程序出問題，程序運行不了，不會操作了，不知道xxx怎麼做，缺少xxx包了，別甩鍋給運維就行了。系統是拿來用的，如果目前一切運轉正常，也能滿足需求，不建議升級。
以CentOS這一係為例，很多包的依賴關係錯綜複雜，某個需要用的包很可能得依賴一些特定版本才能正常運行，而它依賴的這些特定版本的包里，又有不少是得依賴其他包的某些特定版本，而且不是所有的包都會在最新的系統下良好運行的，所以對複雜系統來說，找出一套能穩定運行的匹配不是容易的事情。
追求最新版沒意義，見過多少客戶機房裡rhel5.x從裝機就跑到現在，重啟都幾乎沒有過，然後你說要升級操作系統？客戶連買來常年運行的生產軟體都十分不情願升級，更別說操作系統了。升級，或者直接用最新的系統，這個事兒，很好解決啊。誰建議用最新，直接跟上級領導打一個書面的報告，寫出來要求的系統版本號，內核版本號，以及所要求其他系統軟體版本號，領導批示了，我們運維民工直接給你換新系統啊！
如果把【阿里雲】、【美團雲】、【百度開放雲】、【騰訊雲】、【狗戴滴】、【嘔霉嬸】支持的OS做一個交集，你會發現居然是【CentOS 6.5】。
很多DB狗喜歡CentOS 5，那是因為只有這個版本上才能不折騰地裝好Oracle 10與11。那麼問題來了, 目前商業環境中使用最廣泛的rhel版本, 究竟是rhel4呢還是rhel5呢?我可沒在胡說, rhel6和7那點兒佔有量肯定不夠5看的.
為啥一定要升最新呢？你咋知道這個新版本不是個坑？雖說這事吧在Linux上很少出現，不過少年你是不是沒用過Me和Vista？
身為項目經理，在滿足以下條件，我很樂意接受新的軟硬體版本。
1，已測試過，有相關案例，有常見問題的解決方案。2，如果在生產環境出了問題，供應商（開發負責人或廠家）能負責解決，並承擔相關經濟責任。3，總體擁有成本不能超過舊體系。最後，我個人原則是——老闆你好，老闆說的對，就這麼來。那麼問題來了，一旦系統出現問題，誰來背鍋
不說運維，作為程序我也不會用centos 7，跟懶沒有毛線關係。
Python3.5都出了，為什麼2.7的用戶還是最多的。c++ 17都出了為什麼c++ 11還只是小眾，用的最多的還是C++98和C++03。vs2015都出了很久了，為什麼大學還是在用vc6.0教學？這種問題太多了，建議題主去看看。無論作為開發還是運維，要考慮的因素都有很多，成本，收益，兼容性，穩定性，熟練度，遇到問題的解決能力。且不說 centos 7換成systemd，跟centos6.X完全不一樣，很多腳本都需要重新寫，市場上都是centos6.X，你換成7想遷移都麻煩。用最新版本的東西，遇到問題，你打開baidu，google，sougou，bing沒一個答案有用的，到時候你是不是要跟產品經理說，這個問題網上還沒人遇到過也沒人解決，我也沒辦法。而且最新版本還有一個學習成本的問題，要考慮人力，物力，時間。本來現有的知識和技術完全能解決問題，你卻花時間研究一些沒用過也hold不住的東西來做。出了問題你背鍋？我們只有在現有版本存在bug或者技術上很難支持我們的需求的時候，才會升級版本。我只是看不慣題主說的 除了人懶我真想不出來其他原因。
另外，作為開發，我用的是centos6.X，c++ 03/11，Python 2.7，cocos 3.2，全部不是最新的。感覺這是一個比較好的面試話題，哈哈，多謝答主。
一般的方式都是對新的應用使用新的版本，老的一般不會動，成本、收益、風險不對等。
CentOS7的穩定性又不差。
推薦閱讀：
※CentOS 為何加入紅帽公司，會有何影響？
※為什麼很多公司不用紅帽，而用centos呢？
※如何讓更多的人參與 wiki（Linux 類）？
※企業用哪個版本的 Linux？