1、雲與虛擬化的區別是什麼？雲多了什麼？
【問題描述】：
1：達到什麼樣的硬件規模，才有上私有云的必要？
有幾百上千那是上，有的10臺 20臺 也是上。每個企業可能衡量的標準不一樣。怎麼判斷要不要上？
2：已有虛擬化的情況下，上雲到底能帶來什麼樣的幫助？
雲比虛擬化多了什麼？
解答：
多了雲服務，一種基礎設施封裝服務模式。虛擬化提供不了SAAS，PAAS，也提供不了計費、計量、服務開發和自服務定製。
虛擬化只是一種比較方便支持雲計算的一種技術手段，並不是雲計算。
那麼就回到問題，要不要上私有云？其實我們這裡分析的是上私有云是有什麼訴求，這些訴求是否值得投入，投入產出如何。
上雲、雲管理的訴求1：有把基礎設施強烈服務化得需求，很多時候這種訴求來源於資源規模大，組織結構分工細化，基礎設施部門面向多個開發環境，迫切需要通過封裝自身的服務，把自身的服務能力說清，把服務運行成本、責任分清，雲服務提供式一種良好的方式。訴求2：大規模資源有效利用、批量管理的需求。雲計算是規模效益，規模上不去，效益體現不出來，因此，要根據自身的能力和規模，看看是否值得去上，是否能夠持續投入。訴求3，也是最重點的需求，供給矛盾是否突出，決定了是否走這條道路，虛擬化環境現在管的很好，很方便，能夠滿足業務需求，那麼，個人認為這個矛盾還沒有到要改變生產力的時候，什麼時候變呢？基礎設施要求的速度現有手段跟不上，不能滿足應用快速擴容的彈性能力，不能滿足應用更高層面，比如PAAS\\SAAS方面的需求，或者說需要通過標準手段對架構管控，海量運維。這時就是矛盾突出之時，也是入雲日。
因此，在有資金和人力支持的情況下，基礎設施利用現有的虛擬化進一步到雲計算環境（還要考慮網絡、存儲、流程的投入），是可以的，但不是必須的，需要考慮自身成本、規模，量體裁衣。
2、在虛擬化建設基礎之上，三個私有云建設方向如何選擇？
【問題描述】：
當虛擬化的規模與日劇增，對自動化、標準化、流程化和服務質量需求的迫切性達到一定程度後，我們會選擇開展企業私有云建設。
私有云建設目前大致存在三個方向：
1.在原虛擬化的基礎之上，採用現成大廠商提供的各級（IAAS、PAAS、SAAS）雲管理平臺產品，進行虛擬化的統一接入、統一管理和統一流程。
2.在原虛擬化的基礎之上，利用標準開源的框架，如openstack，Kubernetes，根據企業自身需求，量身開發屬於自己的雲計算需求。
3.在原虛擬化的基礎之上，從基礎框架到軟件需求全部根據企業自身需求，量身開發，更加貼切企業實際，安全係數高，可靠性強。
對以上私有云建設三個方向有何見解？企業究竟該如何選擇方向？
解答：
建議如下：
商業銀行選擇那個路線，還是需要看自身的戰略規劃和人員素質能力的。這兩個路線主要區別如下：
開源私有云：代碼自助可控，平臺兼容性、定製化能力強，但需要具有大量的人員和財務投入，並且是持續不斷的投入，人員素質和財務一定要跟上，同時，開源產品的版本迭代快，健壯性不夠，方向性不明確（沒準大家一股腦換了一個框架\\產品）,這樣帶來的糾錯成本很高。總之，自身利用開源搭建和開發私有云，對自身能力帶來的很大的挑戰，要求企業能夠打持久戰，並能夠不斷的在社區中豐富和汲取養分。還有一層，就是開發、維護都有自身完成，無第三方風險轉嫁。
商用軟件：缺點大家很清楚，容易被廠商綁定，兼容性差，定製化差，隨著規模的擴大成本增長明顯，但特點是實施週期短，對於企業本身的人員素質較自開發的情況要求低很多，主要是產品經理和用戶的角色。並且對於系統的維保、OLA可以通過商務的方式轉嫁部分風險。比較適用於企業規模不大，求儘快上雲的情況。
最後說一點的是，很多商用軟件都是基於開源私有云搭建而成的，可以考慮兩者優勢結合，通過開源的方式增強開放性，通過商用的方式減少自身建設成本。
目標是第三點，但要求企業自身的能力加強，可以考慮基於開源的商用產品，並且要求足夠開放，逐步積累經驗，慢慢做到2個並存，逐步代替。
3、上私有云對企業有什麼樣的要求？
【問題描述】：
1：運維水平有哪些要求？或者說上了雲之後需要具備的素質或努力的方向
對運維團隊有哪些典型的要求？制度規範，技術水平，角色人員？
2：標準化程度要求？
制度規範，企業整體IT治理的階段水平？
解答：
運維水平最大的要求是自動化的運維工具使用、跨領域的協同、運維組織結構調整，和運維文化的轉變。
自動化運維工具應對海量運維、最基本的要求就是配置管理的準確性，要不誰敢上去自動化呢？
跨領域協同在私有云建設中很重要，在大企業中，網絡、計算、存儲、中間件等領域，往往都是獨立的部門，有獨立的變更和實施流程，但在私有云的設計、和運維上，這必須是一體的，哪怕有個虛擬團隊承接。這也就是說，一般情況下，應進行組織結構的調整。
人員要具有面對海量基礎設施運維的能力，要有架構團隊、需求分析團隊。人員要具備運維工具的開發能力，這一點建議百度一下 google的SRE團隊，是一個非常好的定位。
談起標準化，是重中之重，也是私有云最有特點和最有優勢的一環，企業架構管控做的好，標準化程度高，決定了雲計算的層次，SAAS服務的提供，依賴於高度的標準化。要從物理硬件層、OSNETDBSTORAGE各領域完成標準化，然後在繼續規範應用的部署模式，逐步規範形成標準，有利於PAAS的提供，真對具體應用標準話，才能完成SAAS的轉變。
4、企業雲平臺建設一共分幾期？還是一步到位？
解答：
雲平臺很少有一步到位的，往往最開始的階段是滿足最基礎的需求，例如計算虛擬化，存儲虛擬化，然後網絡虛擬化，然後容器，監控，大數據，編排，數據庫，等等應用。其實，這個和雲計算的分層也是有很大關係的。從iaas到paas，再到saas，層層遞進。企業的雲平臺建設，往往也是遵循這個規律。在實踐中，可能會有一些交集。
通常都是分幾期的。第一期為試點項目，第二期根據一期結果形成規範，標準，成為新開發應用的標準平臺。第三期逐漸將老應用遷移到雲平臺上。
5、如何在不做大改變的情況，實現私有云的升級改造？應該關注那些方面的問題？
解答：
如果把服務器作為數據中心中應用的一個點，網絡、存儲則往往屬於面，屬於底層基礎設施，改造難度和風險較計算資源高。在傳統行業中，沒有一個新環境的契機，逐步改造，也是很難的。必然帶來的網絡和存儲在搭建私有云中有些技術跟不上。
之前談過私有云的理解，不一定私有云一定要去用新技術，例如SDN，存儲虛擬化，私有云重點是實現面向客戶服務模式的支撐，資源的彈性和快速服務能力。在這一點上，一般企業通過採用將現有的環境，向標準化配置努力，大力推動自動化能力開發和建設，使之與雲平臺結合，同時增強前期容量規劃的方式，也可以逐步實現雲環境，同時，結合新建的契機，逐步使原來的基礎設施更替為更好支持雲計算特點的技術及設備。
6、怎麼判斷某個系統是否部署在私有云上，有哪些判斷指標？
解答：
最典型一個詞來描述“雲原生”應用。給您一個參考，敏捷開發的12原則，滿足這12原則的應用，基本上在雲計算的這種分佈式、虛擬化的環境中可以很好的運行。這裡，個人認為，最重要的是集群化、支持應用補償機制、模塊化。
只使用一份基準代碼，但是可以部署到多個環境
應用之間的依賴關係要是顯示指定的，比如用配置文件描述，不要用隱式的代碼關聯
配置要用環境變量的方式來提供給應用，而不是用代碼裡面的常量或者代碼相關的方式提供
代碼用到的資源，如數據庫，消息隊列，分佈式文件系統等，要作為可attach的資源的方式來提供，不要寫死到代碼。資源都用資源字符串的形式提供，可從環境變量注射到應用並立即提供服務
嚴格將編譯，發佈，生產等環境進行隔離，即使要改動生產配置，也需要用持續發佈的方式從編譯開始構建並自動發佈到生產系統，不要直接更改生產系統
無狀態的進程的方式提供服務，應用需要做到自身無狀態無共享。如果需要保持狀態或者共享，需要使用外置的服務的方式來提供，比如外置session管理器等
使用地址與端口綁定的方式提供服務，例如某個應用服務的消費者只需要知道uri地址與對應的端口，綁定之後即能消費該服務
通過進程模型的方式進行橫向擴展，即應用或者微型的服務是可以通過多實例的方式來橫向擴展併線性擴展支撐能力的
通常的應用進程要設計成可以快速啟動和優雅終止銷燬的模式，這樣能夠方便故障恢復與橫向擴展
開發環境與線上環境等價，儘可能的保持開發，預發佈，線上生產環境的相同。要能做到持續發佈需要儘可能的縮小本地與線上生產環境的差別。儘量反對在不同的環境下使用不同的後端服務
把日誌作為事件流來對待，彙總整個的日誌來監控平臺的應用和環境，這樣經過大數據綜合分析更能發掘出問題的根本原因
-
管理或者其他的任務作為一次性進程來對待，例如執行一次性的系統檢查，快照一次健康狀態等等。
7、私有云的容量如何評估？成本如何計算？如何才能做到成本和效率的平衡？
解答：
私有云的容量需要根據業務來評估：
以一般金融行業，有web區，有app，有db。需要根據運行在私有云上的業務的多少，來統計所需要的資源的多少。例如，web區，需要nginx，需要考慮HA和LB，那麼就需要2臺以上；如果多個業務共享nginx，那麼就需要多個nginx來分擔業務壓力。
成本計算：
一般私有云平臺上，都有一個celimeter這個模塊，專門用來計量CPU，內存，網絡的使用量，可以統計出使用私有云的資源，相對傳統環境節省了多少資源。
至於成本和效率的平衡，一般在私有云建設初期很難做到。設備的購置，部署，人員的配置等等都是一筆不小的開支；私有云真正的優勢體現，應該在後期的使用中容量如何評估，這個肯定是沒有普適標準的了。
容量通常從三方面考慮：計算能力、存儲容量、網絡帶寬。這三方面可以說也是數據中心最基本的三大核心要素了，我們都知道，雲計算是以規模取勝的，這個規模如何決定？究竟是20節點，50節點，還是100+節點，這個得根據你自己的業務需求來考慮了，在小規模情況下，為了高可用，如果可用容量評估是N，那你就按2N來計算，私有云一般不會像達到公有云那種規模，所以通常也不可能達到很多佈道師口中的 虛機隨便掛，真掛了你宿主機資源沒有了，咋整？
至於成本，得看你的方案了，你是採用開源自建，還是與廠商合作共建，合作情況下如何分工，哪些外包出去，這個你得仔細考慮。通常，如果人力資源有限，技術實力有限，那就由承包給廠商來實施吧，不然到後面也是個爛攤子。但是，全部外部給廠商的不足也是明顯的，一不小心你就被鎖定，每年燒錢的跑不掉的了，尤其是項目上馬後，停也停不下來了。
8、私有云環境下的統一資源納管怎樣實現？
解答：
這個重點考驗的是雲平臺的開放度。
企業在自身選擇雲平臺的時候要充分考慮自身的環境，有多少類型要涉及，有多少平臺要納管，是否支持異構，是否支持模塊化接入。
建議將雲平臺納管層面定位為工具框架，實現足夠的開放性，標準化接口和統一格式接入，各個領域按標準完成自身自動化封裝、自身配置採集、統一視圖展示在雲平臺上，雲平臺通過流程引擎調度個領域模塊，實現操作、納管。
在實施層面，基本上則是領域負責制，每個想要被納管的平臺（計算、存儲、網絡等），完成自身的開發和服務的註冊。
9、私有云是否需要支持多租戶？多租戶和單租戶本質區別有哪些？
解答：
多租戶的概念包含三層用戶集成：
數據中心層
基礎架構層
應用程序層
雲計算技術設計中的重要內容是多租戶的基礎架構和應用程序層集成。此集成經過特別的調整，可節約成本和開發具有高度可伸縮性的 SaaS 應用程序，而這是以犧牲安全性和客戶隔離需求 (segregation requirement) 為代價。很多情況下，這樣的設計都是有效的，儘管可能不太適用於金融應用程序。
在數據中心租用空間並提供服務器、路由器和線纜以支持多個客戶軟件，這項功能自從硅谷創立初期就已經存在，因此用戶對於數據中心層多租戶應該並不陌生。如果正確實現此配置，則該配置能夠提供最高級別的安全需求，它用防火牆和訪問控制來滿足業務需求，還定義了對提供 SasS 的基礎架構的物理位置的安全控制。大多數情況下，可以將數據中心層多租戶用作服務供應商，向公司提供場地來安置硬件、網絡以及軟件。
基礎架構層的多租戶是最簡單軟件棧概念，一個棧專用於一個特定客戶。與數據中心層多租戶相比，此配置更節約成本，因為棧是根據實際的客戶賬戶部署的。在這種情況下，可以根據實際的服務使用來增加硬件需求。另外，基礎架構層的每個用戶都可以選擇高可用性。每個客戶都知道棧，所以軟件和硬件最佳實踐提供了一些實現選項。
應用程序層多租戶需要在軟件層和基礎架構層基礎上進行架構實現。需要修改現有軟件架構，包括應用程序層的多租戶模式。例如，多租戶應用程序需要一些應用程序方法和數據表來訪問和存儲不同用戶賬戶的數據，這會犧牲安全性。但如果正確實現此操作，就可以節省成本。對於小部件和簡單的 Web 應用程序，應用程序層多租戶是一個可行的解決方案，因為單個開發人員可以更快地開發軟件，也負擔得起調整規模的費用。不足之處在於更復雜的應用程序架構和實現；與基礎架構處理多租戶不同的是，如果基礎架構發生變化，應用程序團隊需要保持編程模式的可伸縮性和可靠性，而且在未來可用。
多租戶服務指定從在軟件應用程序中構建並直接訪問的 HTTP RESTful 接口或 WSDL Web 服務終端訪問。這些服務是建立多租戶模式的面向服務的應用程序的關鍵，因為它們可重用於多種事務類型。
應用服務器是應用程序和基礎架構層多租戶的關鍵部件，因為多租戶會影響安裝、配置和應用程序代碼。對於基礎架構層，應用服務器的多租戶意味著調整更快、更廣，它配置了額外的服務器，其中包括應用服務器安裝、配置和應用程序代碼。多租戶層不需要更改代碼（除非應用程序設置了特別的需求），調整也很簡單，一般由 IT 運營機構完成，而不是由開發人員重新設計應用程序源代碼。通常，如果添加了新客戶，則需要添加一個相同配置的棧，以便更輕鬆地滿足安全需求。
10、私有云平臺架構中，安全規則和方案怎麼制定？
解答：
1) 雲計算物理層安全
雲計算物理層面臨著對計算機網絡與計算機系統的物理裝備的威脅，是指由於周邊系統環境和物理特性導致的網絡安全設備和線路的不可用，從而造成所承載的網絡應用不可用。主要表現在自然災害、電磁輻射、三防（防火、防水、防塵）及惡劣的工作環境方面，而相應的防範措施包括抗干擾系統、物理隔離、防輻射系統、供電系統的冗餘設計和可靠性備份，採取前後上下等多種通風方式。
2) 虛擬化資源層安全
虛擬化層是雲計算代表性的屬性之一，也是現階段雲計算數據中心實施最為廣泛的技術，基於服務器的虛擬化技術，可以將單臺物理服務器虛擬出多臺虛擬機並獨立安裝各自的操作系統和應用程序，從而有效提升服務器本身的利用效率。但是這種虛擬化技術也帶來了一些安全風險，比較典型的有基於虛擬化所衍生的一些安全漏洞，以及針對VM-VM虛擬機流量交換的安全問題。
虛擬化軟件導致的安全漏洞風險：這個問題可以從2個方面來看，一方面，以虛擬化應用程序本身可能存在的安全漏洞將影響到整個物理主機的安全。黑客在利用漏洞入侵到主機系統之後，可以對整個主機上的虛擬機進行任意的配置破壞，從而導致系統不能業務，或者是將相關數據進行竊取,如果黑客侵入了虛擬機配置管理程序，則會直接影響到其管理的全部虛擬機的安全。另一方面，基於虛擬化環境開發的各種第三方應用程序的漏洞安全。這些應用程序是雲服務交付的核心組成，包括Web前端的應用程序、各種中間件應用程序及數據庫程序等，即使在傳統網絡安全環境下，他們仍然會因為編程技術的缺陷而存在多個安全漏洞，在雲計算環境下，這些安全漏洞會繼續存在，典型如各種WEB會話控制漏洞、會話劫持漏洞及各種注入攻擊漏洞。同時為了適應或使用虛擬化環境下的各種API管理接口，也可能產生一些新的安全漏洞。
雲計算虛擬機流量交換的安全新風險：在虛擬化環境下，單臺物理服務器上可以虛擬化出多個完全對立的虛擬機並運行不同的操作系統和應用程序，各虛擬機之間可能存在直接的二層流量交換，而這種二層交換並不需要經過外置的二層交換機，管理員對於該部分流量既不可控也不可見，在這種情況下，管理員需要判斷VM虛擬機之間的訪問是否符合預定的安全策略，或者需要考慮如何設置策略以便實現對VM之間流量的訪問控制。
3) 多租戶IaaS服務層安全
多租戶環境下的基礎安全服務主要體現在IaaS服務層。IaaS作為雲計算的重要組成部分，其將基礎設施包括網絡、存儲、計算等資源進行虛擬化等處理，能夠為每個用戶提供相對獨立的服務器計算資源、存儲資源以及在承載網上設定專有的數據轉發通道，這種雲計算的模式已經得到IT業界的廣泛認可.在本次大地保險雲安全平臺的建設過程中，基於IaaS模型下的各種安全服務體系的建設其是重點所在，根據現階段的需求來看，這部分服務主要包括針對雲計算防火牆服務、雲計算負載均衡業務。不同的租戶可以根據自身的業務需求，合理的選擇部署雲安全防火牆服務或者是防火牆疊加負載均衡業務。部署該安全服務後，每個租戶可以獲得邏輯上完全屬於自己的防火牆和負載均衡。租戶可以根據自身需求，設定自身的各種安全防護策略，生成自身獨有的安全日誌分析報告。同時對於部分需要負載均衡的業務，也可以設置獨立的負載均衡的算法，以保證業務的可靠性運行。當然，考慮到應用層的安全風險一直是互聯網的重點防護對象之一，各種基於web應用層的安全攻擊會導致用戶業務系統的權限被竊取以及關鍵數據的洩露，未來也可以考慮增加一些新的諸如IPS入侵檢測等增值服務，用戶可以根據自身業務系統的安全級別合理選擇是否租用該漏洞防護服務等。這部分的內容後續將作為重點進行論述。
4) PaaS/SaaS應用層數據安全
在雲安全體系的建設過程中，PaaS和SaaS的安全建設也非常重要。和IaaS的建設思路不同，PaaS的安全建設，其關鍵在於平臺開放的思想下，開發者應用平臺及數據庫系統對於多開發者數據安全的適配。典型問題包括針對開發者的用戶身份認證，開發者的平臺和數據庫的訪問使用權限控制，不同開發者數據的安全隔離、及操作行為審計等內容。為此需要在數據庫的開發及平臺應用環境開發過程中考慮到上述安全風險的防護。而在SaaS模型下，應用系統級的多租戶共享涉及到的應用層安全問題，除了多租戶身份認證和權限控制及數據庫安全隔離等需求外，還需要考慮針對應用環境的代碼級的安全審計等問題，確保提供給租戶的應用程序本身的安全具備很高的水平，不會輕易被黑客等攻擊者利用其內在的各種安全漏洞。在本次的大地保險雲建設過程中，這部分的安全通過合理配置數據庫及應用程序來進行保證。
5) 建立安全運維體系，確保系統安全
除了前面提到的各種安全措施，還需要在運維管理方面建立相應的安全措施，形成完善的運維體系，以確保整個系統安全。
--專業安全運維團隊
配備了一支高水平的專業安全運維團隊,安全團隊的成員都經過嚴格挑選，具備良好的道德修養和職業操守，同時具備極高的專業安全技術水平。安全團隊有嚴格安全保密制度，有效的安全操作管控能力，以及長效的安全審計機制。
--日常安全流程
安全運維團隊實行7X24小時安全值守服務，隨時監控和處理日常安全問題。對於常見的網絡攻擊和入侵探測等，大多數都由雲平臺自動化處理，少數情況需安全人員人工判斷後加以處理。同時，安全團隊還及時對各系統運維人員的安全服務請求作出響應，配合各系統運維人員做好安全防範工作。
--應急響應流程
一旦發生特大的網絡攻擊或新類型的安全問題，安全運維團隊將啟動突發安全事件應急響應流程。應急響應流程將緊急調動各方資源，臨時提升雲平臺防護門檻，組織專家會診安全問題，制定緊急應對方案並立即實施。對於新型安全問題，將即刻啟動安全防禦新功能開發，並儘快上線啟用，保證安全系統的及時升級和安全的長效性。
--安全消防演習
安全團隊不定期會進行必要的安全消防演習，以考驗各種安全流程和資源在實戰狀態下的有效性。消防演習一般不做事前通知，並在可控範圍內發起模擬網絡攻擊和黑客入侵，同時記錄各安全處理環境的效率和結果，最終評判整個安全體系的防衛和響應能力。
11、上雲之後對IT部門的架構有什麼樣的影響？
解答：
雲計算使傳統意義上的數據中心從原來的成本中心轉變成服務中心，支持向公司內部輸出規範的、有質量保證的服務，降低服務成本、運營成本的同時促進IT部門運維模式發展變革，簡化系統建設、運維工作，提升工作效率。
對於金融保險業，雲計算有其獨特的價值：
縮短上線週期：
雲計算的引入能夠顯著縮短硬件資源、平臺環境、應用系統的部署週期，支持各部門在最短時間內以“隨需即取”的方式獲取系統部署所需的一切服務資源，運維管理團隊即可根據服務模板實現遠程快速部署和動態調整，減少重複性建設工作，支撐業務的快速發展變化。
進一步實現綠色節能：
雲計算構建於池化的硬件資源基礎上，並進一步實現服務化封裝及更高層級的細粒度服務複用，從而相應降低對數據中心機房的電力、製冷、空間消耗，實現機房綠色節能。
促進運維模式發展變革：
針對業務需求部門提供自助式服務，需求部門依據定製的雲服務目錄選取所需的計算資源、存儲空間、網絡服務、基礎平臺環境等服務項並提交申請，運維管理團隊根據定製成型的服務模板，依靠自動化技術及雲管理平臺來交付規範的、有質量保證的服務，將傳統運維模式轉變為以服務為中心的方式，降低系統建設、運維、管理工作量。
運維人員角色的轉變，image維護人員，雲服務實施人員，持續運維人員，和資源管理人員，角色不通 與傳統運維，日後運維多是 運維需求調研開發運維產品上線，自動業務需求梳理開發相關軟件上線。
CIO之家 www.ciozj.com 微信公眾號:imciow
閱讀更多 CIO之家 的文章
