傳統運維 VS 互聯網運維 框架體系大觀
引述因為本人喜歡研究一些哲學東西，在做運維工作中，我就想把運維工作進行一些歸納和演繹，抽象出運維行業的一些通用理念，尋找運維的未來
作為哲學歷史愛好者，其中樂趣也很多，并非像我們學得那么枯燥。不同的流派、哲學家對世界的認知實踐差別很大。例如孔子講仁義禮智信，老子講道可道，非常道，大道自然。亞里士多德說哲學是科學，而不是感覺、經驗和技術。
由此可見，同是哲學圈子里混的，但其認知實踐可以說是風馬牛不相及，但也都各有道理。同樣道理，對于我們干運維工作的同行，其傳統運維與互聯網運維有很多共同之處，但也有相隔千山萬水般的鴻溝。
話說兩人相遇，發現彼此都是干運維的，感覺找到了知音。運維有著共同的痛點，如下圖所示：
激動之余，A問B運維咋做的?B答，IOE *)*&*&，A茫然了。然后A說，互聯網運維 %￥……&%&，然后B也茫然了。彼此互相茫然了，感覺原來同是運維，卻不知對方說啥。。。。無法溝通的感覺。。。。
這種現象很奇怪，同樣是搞運維的，但感覺是完全兩個世界的運維，但其實也不奇怪。在這個世界，但凡存在的都是有其存在的道理。天上飛的，水里游的，各有各的生存之道。運維的世界那么大，我們有必要走一走看一看。
因此，我們有必要探討一下運維冰火兩重天的二元世界。
概述
近一年，關于傳統運維與互聯網運維的探討越來越多，在運維體系快速變革地環境下，運維未來的走向，便成為運維行業的關注點。
那么：
- 到底什么是傳統運維體系?
- 什么是互聯網運維體系?
- 他們的特點，異同在哪?
- 從哪里來到哪里去?
本文將從以下角度探討兩大運維體系。
1.商業封閉式系統架構 vs 開源系統架構探析
2.傳統運維 vs 互聯網運維探析
3.去IOE運動探析
4.運維自動化探析
5.運維發展趨勢探析
1、商業封閉式系統架構 vs 開源系統架構探析
每個單位組織的IT環境，不論大小復雜度，總會有個系統架構層次。有了這個架構體系，那所有的運維事情大體都圍繞著這個系統架構上的每個元素及整體進行運維保障工作。
運維體系架構從某種角度可以劃分為如下兩種：
- A. 商業封閉式系統架構(IOE架構)
- B. 開源系統架構
就上述兩種運維體系，下文做一些辨析。
1.1 商業封閉式系統架構(IOE架構)
典型的即以使用IOE(IBM、Oracle、EMC)產品軟硬件為主要元素的系統架構。
IOE架構以縱向擴展為特點，通過增加CPU、內存、擴展柜、冗余備件等方式來提高處理能力及穩定性。
該架構的處理能力主要取決于單臺(套)設備(系統)的最大擴展能力，很難通過增加設備(系統)數量來增加處理能力，換句話說該架構很難通過擴大集群規模的方式來解決問題。
隨著縱向擴展的規模增大，它的實施技術難度、管理復雜度以及隱患風險都會成比例大幅上升。基于IOE架構的典型企業如：金融業、電信業、能源業、交通運輸業。IOE典型的系統架構如下圖所示。
典型IOE架構圖
上述為IOE型系統架構，其服務器多使用小型機、大型機(還有以往的中型機);數據庫系統往往會使用Oracle;存儲則多使用知名品牌的中高端存儲陣列、帶庫等設備。服務器與存儲之間多使用SAN存儲網絡。
這些服務器、存儲等硬件本身往往就是雙冗余的，線路連線也都是雙冗余的，而且設備性能指標往往非常好，例如一臺普通中端的Power 7系列服務器可以輕松劃分出若干個系統分區或者一二十個虛擬機系統。
1.2 開源系統架構
典型的即以使用廉價PC服務器，開源產品技術為主要元素的系統架構。
開源系統架構以橫向擴展，分布式部署為特點。常通過向集群中增加單機設備資源解決存儲空間、性能以及穩定性問題，其集群規模可以小到兩三臺PC服務器，也可以大到上萬臺。
對于數據庫，可以通過分布式集群方式解決數據庫擴展性的問題。另外非結構化數據庫及分布式文件系統在處理非結構化數據的存儲與使用方面也很靈活方便。
基于開源系統架構的典型企業如：以BAT(百度、阿里、騰訊)為代表的眾多互聯網企業。
開源系統架構如圖所示：
典型開源系統架構圖
上述開源系統架構中使用了CDN和反向代理以提高網站性能。
例如我們的服務器可能部署在北京，對于北京及周邊用戶來說訪問是較快的，而對于遠離北京的用戶訪問則感覺較慢，因為數據傳輸時間比較長。
對于這種情況，常常使用CDN解決，CDN將數據內容緩存到運營商(或自建CDN)的機房，用戶訪問時先從最近的CDN機房獲取數據，這樣大大減少了網絡訪問的路徑。
對于反向代理，當用戶請求到達時首先訪問反向代理，反向代理服務器將(如：Varnish)緩存的數據返回給用戶，如果沒有緩存，才會從源站服務器獲取，這也減少了獲取數據的成本。
當然對于海量訪問請求，或龐大集群架構，則就需要分多層，綜合運用上述負載均衡以及代理(反代理)，同時可能需要引入Zookeeper等功能以協調(服務)任務調度。
從上述架構簡析中，我們便會感知到兩種運維體系的巨大差異。
俗話說隔行如隔山，現如今就算都是運維這一行，也可謂千山萬嶺。對于上述基于IOE架構的傳統運維體系，對比基于開源架構的互聯網運維體系，可以說是當前兩大運維陣營。
2、傳統運維 vs 互聯網運維探析
一個奇怪的現象
傳統運維圈子通常高度認可商業閉源產品。而對開源產品及其技術則很謹慎，很少采納，甚至認為很多開源產品不上檔次。
而互聯網運維圈子通常高度青睞開源產品、技術、理念。而對商業閉源產品則比較排斥抵觸，再好也不買。
差異可見一斑
傳統運維圈子和互聯網運維圈子各有特點，同是運維行業，但也有很多差異之處。關于傳統運維與互聯網運維的不同差異，本文總結了如下幾點差異，并在下文進行闡述。
- 架構差異
- 工作內容差異
- 知識體系差異
- 面向對象差異
- 運維人員差異
- 體制理念差異
2.1 架構差異
- 傳統運維:
這些方案的特點是通?？v向擴展能力極強，橫向擴展能力很弱。商業案例成熟穩定，方案組合重度耦合，講究兩地三中心這種典型的重量級、集中式運維管理方式。
這種架構體系具有大量成熟的商業案例，有完善的存儲保護機制，容錯機制，數據庫也講究強一致性。另外IOE架構后面通常有強大的MA維保支持體系，甚至MA人員常年駐場。
- 互聯網運維:
硬件通常使用廉價的X86服務器，甚至白盒產品。
這種開源解決方案通?？v向擴展能力很弱，橫向擴展能力很強。有大量社區、行業成熟案例。方案組合靈活，講究分布式存儲、負載集群、輕量級、模塊化、去中心化的運維管理方式。
另外互聯網系統架構通常缺少MA維保支持。開源產品更新換代甚至消亡的風險較大。
2.2工作內容差異
由于架構體系的不同，面向對象、運維理念等差異(相關內容見下文)，從而導致工作內容也會有諸多的差異性。如下列舉兩種運維體系的工作差異。
- 傳統運維
需要了解很多業務背景知識、邏輯關系、用戶環境，基于業務環境的運維工作比較復雜。
注重內外部審計工作，通常會有一些政策性地安全大家查。
通常會組織協調廠商完成信息系統項目建設，IDC維保，故障協調處理等工作。
上傳下達公司各種任務、活動。
完成工作日報、周報、月報、年報。
處理各種匯報材料及行政通知類公文等文檔。
建立可靠的網絡、存儲和服務器的備份體系，制定災難恢復計劃。典型的如兩地三中心建設。
應急預案、策略和流程的制定和改進，撰寫各種預案等。
注重提高運維服務質量，不注重成本和效益。
調研測試眾多商業產品，通過商業產品、服務去搭建運維基礎設施及服務
日常運維工作，包括系統環境部署、升級、變更、發布、故障處理等
- 互聯網運維
通常需要了解很多開源技術，需要熟悉shell/perl/python/php等語言，以促進高效運維工作。
對新技術和方案進行調研評估和引進，改進產品的服務架構，提高系統性能和健壯性，用技術去滿足業務發展需求
負責公司網站基礎架構運維，比如負載均衡、分布式緩存系統、應用中間件、分布式文件存儲系統、虛擬化等。
經常借助技術手段控制和優化成本，通過工具化及流程提升運維效率，注重運營效益
持續性優化改進，持續性發布部署新產品新業務
制定和優化運維解決方案，包括但不限于柔性容災、智能調度、彈性擴容與防攻擊。
推動及開發高效的自動化運維、管理工具，提高運維的自動化程度和效率。
全方位的性能優化，將用戶速度體驗提升到極致。
會考慮做精確的容量測算和規劃，優化運營成本。
2.3 知識體系差異
由于運維架構體系的差別，所接觸到產品，技術也就有很多差別，那么日常工作中用到的知識體系也就有很多的差異。對于網絡技術、產品，兩種運維體系共性較多，差異性不明顯。其知識體系的差異則通常表現為IOE架構與非IOE架構相關的知識體系差異。
這里首先介紹一下互聯網運維知識體系。知識不可窮盡，這里僅做舉例探討。
- 互聯網運維
本互聯網運維知識體系從網民瀏覽器終端發起，分層分級方式逐步分解到服務器基礎設施層，另外從運維管理體系、監控體系、安全體系、自動化體系、云計算等多個層次維度全方位展示了運維知識體系。
- 傳統運維
2.4 面向對象差異
- 傳統運維:
因此傳統運維面向的用戶在其數量、需求、特性通常是可控的、穩定的、集中的。
也因此傳統運維圈子適合購買商業產品，這些產品通常是比較成熟的產品，經過長期的測試和使用，有很好地最佳實踐，相對能夠較好地滿足傳統運維需求。
- 互聯網運維:
互聯網運維通常面向的是廣大互聯網用戶，因此其面向的對象關系復雜，市場多變，需求五花八門，目的目標不可控，對象海量不可控。
也因此互聯網運維的系統環境變更迭代頻繁，對自動化、彈性需求要求較高。由于各種復雜多變因素，通常導致傳統商業產品不能很好地支撐互聯網運維環境。因此被逼無奈只能選擇開源，并走自主開發這條路子。
2.5 運維人員差異
有服務器的地方就有運維
其實近年來，在這兩大運維體系之間流動的運維工程師也不在少數。本文作者就是這兩大運維圈子的跨界者。
- 傳統運維:
同時相關商業產品的培訓認證體系也相對完善，傳統行業的運維工程師在這方面有其特色。在傳統企業，培訓通常是廠商免費，合同附帶的，或者單位出錢。
比如他們通常玩過大型機、VMax、Z/os、Oracle、ITSM、PMP、ISO、PCI、某國加密產品、某國數據庫，等等一系列高逼格的玩法。
- 互聯網運維:
互聯網天生具有萬眾創新的基因，因此這片空間廣闊任鳥飛，很多大神往往不是通過各種培訓出來的，都是在各種磨練中涅槃出來的。
由于互聯網產業的迅猛發展，互聯網運維人員的薪酬也普遍高于傳統運維從業人員。
2.6 運維體制理念差異
由于架構的不同，面向對象不同，服務原則不同，因此傳統運維與互聯網運維在商業運營模式上自然有很多不同。傳統企業，有時很多運營指標是社會效益第一位的。而互聯網企業則通常是經濟效益第一位。關于兩種運維運營理念的差異，下文列舉了一些供讀者參考。
- 傳統運維
傳統運維圈子里，看重商業運維產品、服務支持、業務運營流程這些因素，但對開源產品體系比較慎重或者沒興趣。
傳統運維關注流程、關注業務、講究ITIL，ISO標準體系，通常關注業務運行的高度穩定，高度一致性、集中性。傳統運維自動化程度通常不高，但求運營穩定可靠。
傳統運維行業多是企事業單位，共和國長子長孫型企業，在運維經營指標、人事組織，薪資體系，運維KPI考核等一系列觀念和互聯網運維行業的理念還是有很大差別的。
- 互聯網運維
互聯網企業注重才華外漏，很多事情是結果導向。雖然經常搞些員工貼心小活動，但員工離職相對頻繁，創業的不少。
互聯網運維通常關注網站響應、網站性能、關注靈活快捷、分布式、開放式，關注安全體系。在很多互聯網大企業里，其運維自動化程度非常高。
3、去IOE運動探析
談起傳統運維，則通常會自然地、密切地關聯到IOE架構體系。這也是傳統運維近年來愛恨交加的根源。因此在本節內容，我們探討一下去IOE相關內容。
近年來開源技術的迅猛發展，以及國內外政策環境共同作用，引發了一場去IOE的風潮，開始使用低廉的軟硬件產品代替昂貴高門檻的IOE產品，搭建起自主開放的開源系統架構。
3.1 去IOE原因
之所以出現“去IOE”運動，其中原因總結概述如下幾條：
1.自“棱鏡門事件”之后，國家強烈意識到數據安全的重要性，開始大力提倡產品設備國產化與自主研發，這正與“去IOE”觀點不謀而合，上下一致。
2.近年來，云計算、大數據等新興IT技術的蓬勃發展，促使眾多行業開始往更加開放靈活的開放系統架構轉型。
而對于傳統的IOE架構而言，其定制與擴展靈活性有限，往往是擅長于集中式架構的管理，而很難應對大規模集群，分布式存儲計算。
3.在購買成本方面，以IOE為代表的商業產品價格昂貴(動輒上百萬元);而PC服務器則相對廉價，通常幾萬元。
在部署與管理方面，IOE產品的學習掌握門檻偏高，而開源系統環境相對容易搭建與管理。
另外IOE產品技術相對商業封閉，不易掌握。
3.2 是否要去IOE
基于上述一些原因，去IOE應時而生?？吹絼e人去IOE很成功，然后自己也想玩花的。有沒有實力資本玩花的，具體到自身企業是否要去IOE，這需要慎重考慮，三思而行。畢竟適合自身發展需要的系統架構就是好的架構。
去IOE過程，其實是系統架構的更新換代，產品的更新換代，運維理念的更新換代，運維人員的更新換代，知識體系的更新換代，等等。
因此如果冒然去IOE，可能既不會降低成本，也不會提高效率，更不會穩定架構。如下列舉幾點“去IOE”要考慮的因素：
1.自身業務是否真正需要大數據、云計算以及分布式這種海量運維體系。
2.是否已經考慮好系統架構、運維理念、人員、知識更新換代的方案。
3.自身的研發實力儲備是否夠解決大量開源產品的坑坑洼洼，并有實力搭建開源系統架構。
4.是否有足夠的資金應對“去IOE”轉型中的成本，例如從軟硬件高成本轉向人力技術高成本。
小結論：
A. 去IOE只是給予我們一些最佳實踐與選擇路線，但去IOE技術門檻較高，一般企業很難復制。
B. 從目前發展來看，去I、E案例較多，去O不容易，IOE架構與非IOE架構仍將長期并存。 一時間很難找到一些能夠完美替代以IOE為代表的成熟(且普適)產品方案。
4、運維自動化探析
4.1 為什么需要運維自動化
上節討論了傳統運維中典型的IOE問題。那么談到互聯網運維，我們大都也會立刻關聯想到運維自動化。因為運維自動化天然帶有很多互聯網開源基因，在互聯網行業有很多最佳實踐。因此本節討論一下運維自動化。
做好運維不是單靠幾個超人就能搞定的，做好維工作需要一整套運維體系解決方案。恰恰做運維自動化是很好的切入點，通過實施運維自動化，能夠很好貫穿人、事、物、流程標準。運維體系的好壞影響運維自動化的實施執行，反過來，運維自動化也會推動運維體系的建設。
當前市場上已經有很多成熟的(商業、開源)運維產品工具，各有特色也各有利弊，這也同時造成一個尷尬局面：運維人員要不斷學習和管理很多運維產品工具，但卻很難有找出一個很好適應本企業(持續不斷)定制化需要的產品工具。當企業IT規模大到一定程度(例如擁有幾千臺甚至上萬臺以上服務器規模)，對于企業的快速變化、需求的高度定制化，靈活而又龐大復雜的運維需求，很難有(或者沒有)現成的運維產品能夠滿足需要。因此很多有實力的企業都會選擇自主運維及開發。
運維自動化開發，不再單純、局限地依靠某個網管監控產品，而是需要提供體系化運維解決方案，包括系統網絡管理、CMDB資產信息管理、知識庫管理、乃至ITSM信息服務流程管理等。
4.2 運維自動化系統設計案例
下面就一個運維自動化系統案例，簡介一下該系統架構。
本解決方案立足從三大維度構建，如下圖所示。分別是IT運維流程、IT監控平臺整合、IT運維自動化。這三大維度主要具有如下幾大功能模塊。
IT運維流程：資產管理、知識庫管理、安全管理、事件管理、日常事項管理。
IT監控平臺整合：監控報警管理、日志管理、性能管理、報表管理。
IT運維自動化：應用管理、配置管理、程序運行管理。
系統功能框圖如下圖所示。
本解決方案使用的開發語言及工具：
后端及系統客戶端開發主要通過Python、Shell等程序語言實現。
信息采集寫入MySQL數據庫。
前端WEB展示以及與后臺數據層、應用層的邏輯交互通過Django框架實現。
界面修飾美化使用Bootstrap等框架工具。
部分系統功能簡介
如下圖是網民訪問實時動態分析監控。
如圖所示是基于Cacti深度定制的網絡拓撲流量監控。主要是動態實時地監控各個主要節點的網絡流量。
如圖所示是資產管理模塊中的硬件配置模塊。主要是資產的增刪改查功能。對于大量資產信息的錄入是通過后臺管理中的信息導入模塊(將固定格式的Excel資產信息表)批量錄入到系統中。該模塊主要通過Django CBV方式快速實現。
如圖所示是基于ELK深度定制的日志監控模塊?；诟黝惾罩拘畔⑦M行監控與統計。
如圖所示是系統的性能圖表展示
如圖所示是系統自動化部署模塊，具有批量查詢IP使用情況、派發客戶端、部署與配置系統等功能。自動化部署主要基于kvm、Salstack等深度開發而實現。
5、運維發展趨勢探析
5.1 運維體系構建
如上文所述，我們探析了傳統運維與互聯網運維的不同層面維度的差異，但從另一方面來看，都作為運維，還是有很多共同之處。這里將不再區分互聯網運維還是傳統運維，這里將從一個架構高度看待和規劃運維。
從人、事、物、流程這四個方面便可以很好地將運維體系進行解構，它們彼此互相作用，共同構建了一個完整實用的運維體系。下面列舉了這四個方面各自的含義及相關內容。
人：例如完善崗位職責與職業發展、提高團隊技術水平、完善技能分享與培訓、完善團隊績效考核、規范工作行為規范等。目的是要建成一支工作高效、技術水平高、團結穩定、有職業素養的運維團隊。
事：例如做好日常基礎運維工作，保障好生產業務運行。不斷探索新的運維理念與技術，探索優化系統架構。具體可以分為幾大塊，例如運維流程管理，資源架構規劃，應急與故障處理，監控與優化，安全與防護，項目及日常工作，等等。目的是要明白運維做什么正確的事，怎么正確地做事，做事有章法，穩定高效能。
物：主要是如何管理好系統運維所涉及的各種資源。例如機房環境、辦公設備、服務器、網絡設備、操作系統、應用軟件、工具等各種軟硬件資源。目的要使各類資源配置管理妥當，清楚資源屬性，知道從哪來，現在哪，要去哪。使得物盡其用，物有所值，安置妥當。
流程標準：運用流程標準將上述要素(人、事、物)有機地結合，有序科學地流轉、高效穩定地運行。例如資源規劃與采購，各種標準規范、項目規范、軟硬件配置部署規范、安全制度、工作交接，等等。
基于上述四大維度，下文給出了一個矩陣表進行表述舉例。
5.2運維路在何方
未來的運維道路在何方，我從哪來，要到那里去?這是每一個運維從業者都會面臨的問題。本文關于運維發展趨勢的一些辨析如下：
云計算等各種理念技術的發展，這些都將對運維行業帶來巨大的機遇與挑戰。很多企業都處在傳統IDC運維方式與云運維方式的探索中。
在新的形勢下，傳統運維方式與基于云計算的運維方式將長期并存，公有云與私有云及混合云運維局面將長期并存，傳統IT運維與互聯網IT運維也仍將長期并存。展開闡述如下：
- 傳統運維領域正在探索容器、自動化、云計算、開源架構等轉型之路?；ヂ摼W運維也在借鑒或使用成熟的商業產品與理念。
- 基于IOE架構的業務系統正在處于轉型中，開始逐步擁抱開源技架構。但基于開源互聯網技術的成功經驗也并非都能復制?；诨ヂ摼W開源的技術實踐正在蓬勃發展，勢頭迅猛，其中也借鑒了很多商業閉源的產品、架構、技術。
- 完全閉源的生態環境和完全開源的生態環境是兩個極端，更多的IT生態是混源狀態，雙(多)模狀態。研發與運維甚至業務之間的邊界也并非黑白分明，DevOps的理念逐步深入到各類IT的各個層面。
- 在上述大環境下，運維部門不會變的越來越清閑了，相反承擔的企業發展戰略的責任越來越大了。運維部門將由傳統的IT成本中心更多地向IT服務中心、價值輸出中心、利潤輸出中心轉變。
- 在上述發展形勢下，運維的人、事、物、流程規范都將相應發生變化，如人員數量會有變化，職位職責會有變化，設備資產會有變化，各種流程規范都將發生變化。
5.3運維人發展之路
Head
The conviction to change What do they hear and think? Are they convinced of the need for change, the vision, the plan? What is their analysis
Heart
The desire to change What do they see, feel and want? Are they triggered by a story, by examples? What is their mindset? Buzz words? What behaviour change is driving the change?
Hands
The capacity to change What do they experience? Are they capable? Do they have the necessary new organization, competen-ces, budgets, processes, products.
T型人才適用于很多行業人才。解釋如下。
T型人才是指按知識結構區分出來的一種新型人才類型。用字母“T”來表示他們的知識結構特點。“—”表示有廣博的知識面，“"”表示知識的深度。兩者的結合，既有較深的專業知識，又有廣博的知識面，這類集深與博于一身的人才。這種人才結構不僅在橫向上具備比較廣泛的一般性知識修養，而且在縱向的專業知識上具有較深的理解能力和獨到見解。
T”型人才就是：既有專業深度，又有思維廣度，能夠跨界思考和探索;既能夠在一個點上專注、投入其中，同時又能夠對外部世界保持開放的心態，接納不同的視角;既能夠對問題做根源思考，又能夠從系統的角度做整合解決方案設計。
我定義了一種人才模型，稱為“十型人才”，更適合運維人才發展之路。我對十型人才的解釋如下：
高度： 應該又高遠的視野，高屋建瓴的能力，方向掌控能力。有能力，有執行力帶領團隊走在一個道上。
深度： 應該能敏銳的抓住問題，事情的關鍵點。有比較好的毅力和韌性去做事情。
寬度： 有寬廣的技術知識面。有寬廣胸懷氣度。很好的包容協調能力。
5.4 運維路在何方
DevOps 不是一項技術，也不是一套流程和方法論，更不是一套簡單的工具產品。越來越多的跡象表明，DevOps是一種文化。
這意味著，DevOps 可以持續地、源源不斷地向業務傳遞價值，IT成為企業的生命線，事關企業生死存亡及發展大計。
這意味著，DevOps 再也不僅僅是 Dev 和 Ops 的事了，而且包括計劃、需求、設計和后續的運營。所以，不再是一個純粹的技術問題。
這意味著，DevOps 需要更廣泛地知識體系。運維只是多會些 Python，就不要說自己是 DevOps 了。
寫在最后一的句話：
此圖從整體上看是一位和尚的圖像，也就是佛教的代表，即正面是釋迦牟尼。左側頭戴方巾者為儒教的代表，即孔子。右側頭后挽個發髻的則是道教的圖像，即老子。三教共存一碑，一片圓融。這三個頭像合在一起，加上合肩、合上身，渾成一體，兩手捧“九流混元圖”，構成佛、儒、道三教及“九流”的“混元三教九流圖”。
大道自然，順勢而為。抉擇至關重要，最好的運維是在正確的領域由正確的人干正確的運維事情……
免責聲明：本文僅代表作者個人觀點，與本站無關。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考，并請自行核實相關內容。
我要收藏
個贊
