乙個傳統企業，之前養過乙個研發團隊搞基於開源專案的雲平台（比如openstack，kubernetes 和ceph），或者從一家小公司採購進來乙個雲平台。不巧，因為各種原因，自己的研發團隊解散了，或者外部的小公司倒閉了。那麼，現在這個雲平台該怎麼處理呢？如果時光倒流，允許從頭來過，這種結局有辦法能夠避免嗎？
處理方式不外乎以下幾種：
自己搞運維團隊，如果**有問題搞不定則找外面能提供服務的**商。其實這就是自己組建l1團隊，花錢從外面買l2和l3團隊的服務。這應該是比較靠譜的做法。畢竟運維人員一般要比研發人員成本低不少，而且隨著開源專案越來越穩定，並沒有那麼多的**上的問題。但是這有幾個前提條件：
將平台遷移到新平台。這裡面有很多問題需要考慮：
如果時光倒回去，假設你是決策人，要怎麼避免這個問題呢？可從以下幾個方向進行考慮：
對於非關鍵業務環境（比如開發測試環境）或者管理平台（比如cmp），以及輔助系統（比如監控和日誌系統），可以自己團隊基於開源專案搞定。一來這些東西不處於核心的資料平面上，因此即使出了問題也影響不會太大；二來可以鍛鍊團隊；三來可以根據自己的需求進行適當的定製。
如果不想或者不能或沒錢找大廠**商，那最好能做到以下幾點：
決策過程要考慮很多因素，其中乙個關鍵步驟是區分業務環境：
下圖也許是乙個比較合適傳統企業的架構：
1. 如果是創業公司，你要說服或者替客戶想到避免廠商鎖定問題，那麼就要求在核心組建上盡量和社群保持同步。要麼直接使用社群的，如果自己有定製的話，就同步到社群。
2. 看國外公司是如何基於開源專案做產品的，openshift 和 rancher 是兩個挺好的例子。
3. 讓產品盡量保持簡單，不是越複雜約好，因為，我個人不太看好各種 on 的架構，比如 k8s on openstack，openstack on k8s 等。想著運維壓力就頭大。
4. 如果是大廠（比如華為華三這種），可以有定製，因為大廠有能力給客戶提供長期支援。
1. 隨著公有雲越來越廣泛地被企業使用者所接納，那上雲、架構設計、運維、安全等需求將會越來越多，這是msp的業務範圍。
2. 企業中會出現越來越多的沒人管或沒人能管得了的雲平台，msp 有實力的話提供開源平台的 l2 甚至 l3 運維服務的話，將會有客戶找上門。
3. 隨著混合雲的逐步推廣，網路和安全將變得越來越複雜和重要，而這兩個東西門檻又非常高，正好這是msp的業務範圍之一。
先看看vmware這5年的股價變化趨勢：
vmware vsphere 真是功能豐富、強大、穩定、可靠，還能在購買許可證上想想辦法。
現在還有cmp，對外提供自服務介面和api，分分鐘將虛擬化環境改造為雲環境。
vmware 和 aws 都合作得那麼緊密了，其價值對於aws 來說顯而易見，對使用者來說，本地vmware 環境連上雲上vmware 環境，那使用者體驗還是相當爽的。
1. 多關注企業使用者的需求，不要埋頭寫**。一直認為開源社群應該有產品經理。當然了，有人說開源社群做的是開源專案，不是產品。如果只是玩技術，那結果很可能就是自己玩得嗨，使用者最多把你的東西放在邊緣環境或政績專案上。
2. 更加關注核心模組穩定性，一開始就保持核心模組的穩定，從而減少二次定製的需求。不要只想著做大。
3. 教育好利用你們的開源專案做產品的創業公司，他們該往什麼方向做，該如何和社群分工配合，如何幫助落地到使用者的資料中心等。
4. 對多長時間後能進企業的核心生產環境更加現實一些。
1. 多關注傳統企業吧，他們才是未來你們的客戶的主力軍，不要成天只宣傳上億併發和秒殺了，這些東西傳統企業用不上估計也懂不了。他們更加關注的是穩定性、資料安全性、跟他們自己的資料中心打通、遷移成本、是否要改應用架構才能上雲、現有運維人員能夠做得了運維、成本、能否跟現有運營平台整合等問題。
2. aws 把 vmware 拉在一起合作，把 vmware 環境搬到他們的公有雲和私有雲上，推出 outposts，這些是真正關注傳統企業的舉措。aws + vmware 其實也可以模擬為 cmp + vsphere。
3. 真正的『以使用者為中心』，是要時刻想著使用者的需求，不管自己之前說過什麼（aws 之前說私有雲不是雲，只有公有雲才是，言外之意vmware更不是雲）。現在使用者需要什麼，那就提供什麼。
1. 雲可以有多種形式，vmware + cmp 可以看做雲，私有雲其實嚴格來說不是雲，至少它缺乏雲應有的規模性和彈性，公有雲才是真正的雲。
2. 上雲不能只是資源上雲，上雲更是一種理念。如果只是把應用從物理機上遷移到虛擬機器上，這並不叫上雲。上雲至少還包括開發上雲（面向雲開發，devops，cicd等）、應用上雲（面向雲制定應用的雲上架構並進行部署）等。
3. 在做雲平台決策的時候，首先要做的是對自己的業務進行分級，多少核心業務系統，多少非關鍵生產系統，多少開發環境等，然後確定不同的需求。
4. 在做雲平台決策的時候，想想做雲平台的團隊將來要是撂挑子不幹了那要怎麼辦，誰來收拾局面。如果確定了做雲的人，不管是自己人還是外面的廠商，就對他們好點，把他們當合作夥伴對待，因為他們是你出問題的時候救你命的人。
5. 算成本的時候，把養研發團隊、運維團隊、廠商支援服務的成本也一併算上。
6. 打算養研發團隊自己做雲平台的時候要想清楚，是在基礎架構層定製呢還是在管控層面定製，是不是一定要私有雲，是不是能上公有雲，團隊穩定性和成本如何，如果幾年後團隊不在了該怎麼辦。
1. 雲底層開發將來更多的會存在於大廠那裡。小的雲團隊更多依賴於開源社群，只有大廠才會有實力和業務需求養大的基礎架構研發團隊，這樣的團隊成員才有機會做真正的底層技術研發。
2. 每個雲的使用者都會需要運維人員，不管是什麼樣的客戶，連公有雲的使用者也需求運維。將來能看懂開源專案**並能修補一些簡單bug的運維人員會更有市場需求。
3. 雲運維人員要面向雲運維，以雲的理念做運維，能讓自動化工具幹的事情就不要人肉做。即使現在做的是傳統運維，有時間的時候，去考個aws的雲架構師和雲運維專家認證，會很有價值。
4. 面向業務運維，而不是面向資源運維。時刻想著從業務出發，不要一直盯著那點資源。
你雲我雲 兄弟夜談會 第三季 企業IT架構
你雲我雲 兄弟夜談會 第三季 企業it架構 你雲我雲 兄弟夜談會 第二季 5g 你雲我雲 兄弟夜談會 第一季 企業雲 主題 企業it架構 兄弟團 soa 是面向服務架構的縮寫，它是一種架構理念。早期其主要形態是企業服務匯流排esb enterprise service bus 它主要是為了滿足企業內...
都是雲桌面，VDI和VOI架構你會咋選
首先，vdi的採用的是一種集中管理和集中計算的模式的，即所有的計算和資料都集中在伺服器進行統一執行的，它的優勢就在於通過vdi強大的功能可以實現伺服器集群 高可用 熱遷移 批量大型部署 桌面桌面虛擬化vdi，支援各種終端裝置的接入，在保證資料安全和支援移動辦公及桌面漫遊上既有明顯的優勢的。其次，而v...
我和春天有個約會，阿里雲MVP第4期公布
自 2017 年 6 月 10 日，阿里雲宣傳mvp計畫啟動，並向全球公開招募。至今mvp已招募 4 期，160 mvp加入，來自全球 11 個國家，所屬技術領域 人工智慧 大資料 虛擬實境 運維等，分布程式設計客棧在物聯網 金融 工業製造業 基因 安全等產業鏈。第四期入選的mvp來自不同的地域，遍...