數據庫，做爲企業重要IT基礎設施之一，在數字化中扮演着重要的角色。其是否運行平穩、是否處於最佳狀態、是否可方便的擴展等，進而是否能知足業務現狀及將來發展，這些對於企業相當重要。要達到上述目標，取決於兩個方面：數據庫產品自身能力、數據庫服務能力。能夠說「產品+服務」，決定了最終的結果如何。但在很長一段時間裏，對於前者（產品）有不少手段去了解、評估；但對於後者（服務）卻少有有效的衡量方法。在過去的3、四十年裏，傳統數據庫市場主要是以國外大型商業數據庫爲主，其服務能力通過多年積累已相對成熟、完善，並構建起一整套標準及相應的配套服務團隊。但隨着近些年來數據庫市場有了明顯的變化，一是以開源爲主導數據庫方案在不少公司得以使用；二是國產數據庫也層出不窮，並愈發呈現蓬勃發展之勢；三是分佈式、雲化技術特色爲表明的新數據庫形態逐步被人認知並投入使用。針對這種新的變化，過去按單一產品做爲衡量標準就不太合適，急需一種通用的行業標準來度量數據庫服務能力。數據庫
近期，信通院發表的《數據庫服務能力成熟度模型》，由此應運而生。它的推出，有助於企業決策者，找到數據庫服務重點，獲取當前數據庫總體現狀，識別其中的不足並找準關鍵問題及差別，進而提供數據庫服務能力的改進方向和意見，規劃企業將來的數據庫發展藍圖。本文根據以前信通院發表的《數據庫服務能力成熟度》爲基礎，加以我的的一些理解分析。當前這一標準，正處於規範發佈階段，其具體細節和評價方式、標準還有待落實，也但願更多數據庫從業者參與其中。爲提升國內數據庫總體服務質量，貢獻本身的一份力量。本文部份內容引用信通院發佈《數據庫服務能力成熟度》報告及網名「失速的腦細胞」的一篇文章。安全
原文參考：www.jianshu.com/p/d672951c5c1a性能優化
1. 成熟度模型概述服務器
1).評估標準：能力框架與能力域網絡
這次發佈的數據庫服務成熟度模型，將能力框架劃分爲三個能力域，分別是：規劃設計能力、實施部署能力和運維運營能力。其可對應到數據庫從選型評估、規劃設計、部署實施、運維保障、開發優化等多個方面。在三個能力域內，又進一步劃分爲27個能力項，其中規劃設計能力域包含8個能力項，實施部署能力包含7個能力項，運維運營能力包含12個能力項。具體可參考下圖：架構
2).評估對象：服務方和使用者
併發
此模型的評估對象，既能夠是數據庫服務提供商、也能夠是數據庫雲廠商；甚至是數據庫產品的使用者。前者做爲數據庫服務的提供者，此模型是能夠做爲甲方選擇服務者的一種參考依據。後者做爲數據庫用戶自身，也能夠做爲評估自身的技術能力的有效抓手。app
3).評估標準：能力等級劃分框架
在評估標準上，模型提出了五個等級，分別是初始級、可重複級、穩健級、量化管理級、優化級，其能力等級依次遞進。從初始級，完成目標具備必定的偶然性，被動應答需求和問題的初始級；到具有必定經驗和技術積累的可重複級；到具有知識庫、流程和規章制度，保障目標達成成功率的穩健級；到可以量化並可以監控服務過程當中每個環節，而且具有較高服務的工具和相對完備流程制度和方法論的量化管理級，以及最高級別，可以不斷可以引入新的技術和理念，超預期達成目標，分享最佳實踐成爲行業標杆的優化級。
其實上面能力等級劃分，很容易映射到企業數據庫管理階段的發展。
初始級
在最原始的階段，企業的數據庫運維每每依靠於我的。我的的能力、水平直接影響運維效果。當出現問題時，人肉搞定。此時問題的解決，是沒有總結積累、沒有傳承的。稍微好些的是，創建一套相對簡單的處理流程。出現問題，可遵循此流程；但具體的處理方法是無章可循的。
可重複級
問題出現的多了，天然而然的想法是把常見的問題和解決記錄下來，也就慢慢有了經驗的傳承（構建原始的知識體系）。加之以前的規範流程，就有了一套標準。當問題出現時，依據處理流程及處理方法，按圖索驥便可。再進一步的，能夠將這些解法能夠腳本化、工具化，提升處理效率。
穩健級
當可重複級積累到必定階段，就達到穩健級。此時構建的知識體系、流程、規範、制度已日趨完善。此時，是一個比較「自在」的階段，若是沒有大的目標，是能夠小富即安了。
量化管理級
如再上一個臺階，就涉及到對服務的度量問題。由於只有達到可度量的狀態，才能夠不斷提高，追求更高的管理目標。此外，也纔有機會作到預測式管理，而非被動響應式。要想作到量化這一目標，是須要對數據庫使用有着更高層次的認識。舉個例子，如何評估你單位的數據庫開發質量。爲了達到這一目標，是須要你定義具體的指標及指標的評定標準，進而還須要經過系統、工具輔助完成指標的收集、管理、優化等工做。具備表明性的指標，甚至能夠造成行業標準，指導其餘企業的管理工做。
優化級
到了優化級別，不只僅侷限於提高數據庫管理、使用水平，甚至可直接提高企業業務能力。其不在限於單一指標，而是提出新的概念，幫助從更多角度看待這一問題。甚至能夠反饋產品，持續改進。對外，能夠將已有內容造成行業通用化標準，引領行業的總體發展。
4).評估維度：流程+制度+方法+人員+交付物
流程
根據發展等級，從初始的針對個別問題的簡單流程，到通用化、標準化；進而逐步完善、趨於完整；再到創建流程評估體系；最終造成不斷迭代完善的流程。
制度
從沒有制度，到有了簡單制度保障，再到造成完善制度，制度實施評估等。
方法
從無到有，從我的經驗，到經驗傳承；從知識庫造成，到構建自有的方法論。
人員
從初、中、高級的人才梯隊建設，到人員的能力培養體系的創建；從全面的人才，到專有化分工的人才配置；從簡單的我的教授，到造成企業自有甚至行業標準的學習考察認證體系。
交付物
從無任何傳承媒介，到文檔的積累；從簡單腳本到複雜工具、平臺、系統；從單一處理型的工具，到收集、評估、預測、處理、優化等系統集合。從內部使用，到可輸出外部等。
2. 規劃設計域
1).架構規劃諮詢
架構規劃，是數據庫服務的重中之重。好的架構設計，不只能夠知足企業現狀發展，還可知足將來必定階段的發展要求。於此同時，還須要兼顧企業基礎設施、運維能力、應用開發、財務成本、業務特徵、風險評估等因素。
基礎設施
在作架構規劃時，需考慮企業自身基礎設施現狀及發展規劃。包括但不限於服務器、存儲、網絡、安全等相關配套設施。如考慮雲方案（公有云、私有云、混合雲、跨雲）等，還須要考慮雲廠商的選擇，是自建仍是直接選擇雲數據庫產品等等問題。基礎設施，做爲數據庫的「底座」，其好壞對數據庫的總體投產效果，很是重要。
運維能力
這裏談到的運維能力，包括軟和硬兩個方面。軟的方面，主要是指人的狀況（即自有人員的能力、結構、技術特色等）。硬的方面，則是指企業運維體系、平臺等方面。
應用開發
企業現有的應用開發技術棧、開發模式、開發體系等。
財務成本
企業的財務情況、總體週期狀況、主要財務考覈指標（如ROI）等。
業務特徵
行業、企業、業務特色，是否具備高增加性、不肯定性、波動性等特徵。企業現有所處階段，及週期內會經歷階段。
風險評估
是否面臨政策、法務、合規、監管類要求；是否有對數據一致性、業務連續性等的硬性要求。
評估要點：這一能力域的考覈標準更可能是軟的方面，例如人員資質、項目經驗、行業經驗等考察要點。服務方如在上述知足狀況下，可以總結出發展趨勢，可以前瞻性地指導企業架構規劃，而非簡單地解決具體問題，將會爲企業帶來更大價值，甚至改變企業初衷。
2).容災備份規劃
保證數據安全，是數據庫的核心職能之一。容災備份，正是爲了知足這一要求。服務方需根據客戶對RTO、RPO的具體要求，結合其自身狀況，制定出符合要求的容災架構和備份策略。在作這兩方面設計以前，通常都須要對客戶的業務應用作梳理，爲後續制定不一樣的分級策略作好準備。
容災架構
根據客戶的容災需求，可考慮單機房容災、同城容災、異地容災、多中心容災策略等。在技術方案上，可綜合考慮應用級、系統級、數據庫級、存儲級等不一樣的容災技術。
備份策略
備份策略上，一方面須要考慮客戶的業務訴求，也須要考慮來自合規、監管類的要求。根據不一樣需求，創建其多層次的備份體系。此外，針對「多餘」的這份數據，除了數據保護單一功能外，是否可帶來更多附加價值也值得探索。
評估要點：這一能力項更可能是看中方案的成熟、穩定，特別是相關案例實踐。畢竟容災類的需求典型特色是，可能永遠也用不到，但一旦啓用毫不
能出現問題。備份這塊則更多強調在知足保護與成本間的平衡，重點考察的是方案的靈活性和成本收益的量化評估。
3).數據安全規劃
數據安全，是數據庫承載的又一核心職能。這裏包括的內容較廣，包括但不限於數據的生產、傳輸、存儲、訪問安全。安全問題涉及面很普遍，從基礎設施（服務器、存儲、網絡）、系統（操做系統、應用系統、數據庫系統）到開發規範、終端安全等。這是一個典型的木桶原理，即數據的安全性，取決於總體安全體系的最短那塊板。所以，在制定數據安全規劃時，不能僅僅侷限於數據庫端，要從全局角度去考慮。對於數據庫自己來說，從基本的用戶、角色、權限劃分，到數據的安全訪問；從數據的加密存儲，到數據的行列級訪問權限；從數據的脫敏處理，到數據全生命週期的安全管控（審計等）。
評估要點：這一能力項，強調基本安全能力的同時，更爲強調全面性。除了從數據使用的方面考慮外，也包括了必要的制度、規範及實施策略等。
4).產品選型規劃
在明確了架構規劃後，這一步將要完成具體產品（包括平臺、版本、補丁等）的選擇。在選擇時，須要細化以前架構階段收集到的那些信息以外，還須要進一步收集用戶的業務特徵，爲作好必要的選型測試（即POC）作好準備。這一步的難點在於，如何構建符合客戶真實需求的評測標準。常見通用的測試標準（如TPC組織系列），僅僅能表明通用性場景，對客戶真實業務來講，不太具有參考意義。所以需制定有針對性的測試標準，包括常見的功能測試、性能測試、可用性測試、擴展性測試、應用開發適配、數據遷移、兼容性等。若是是採用雲數據庫，則還需考慮更多問題。評估要點：評估要點在於「切合度」。如何根據前面獲得的信息選擇最爲適合的產品，並構建符合客戶真實業務場景的選型測試來幫助客戶完成這一步驟。針對客戶需求的準確把握及對行業、業務特色的深入理解，有助於完成這一過程。
5).開發規範設計
不一樣數據庫，有其不一樣特色。如何發揮出數據庫的最大效能，取決於如何根據其優劣點來設計結構、訪問邏輯等。開發規範設計正是根據數據庫特性與開發的相關性，從SQL代碼編寫、表設計、索引設計、其餘數據庫對象設計等多方面提供全面細緻的開發規範指導，規範數據庫需求方在業務系統開發過程當中數據庫的設計與開發，防範低效的數據庫設計、低質量的結構化查詢語言代碼的出現，提高業務系統質量和開發效率。
評估要點：這一過程的難點在於，如何量化質量和效率。必要的工具、平臺對落實規範，評估效果很是有好處。能夠從事前、事中、過後，多個角度來進行評估，儘可能將可能的風險降到最低。
6).數據庫運維規範設計
數據庫運維規範設計主要指數據庫服務方根據數據庫及業務系統特色，提供數據庫標準化運維體系，如組織架構、管理流程、管理規範、變動管理流程等，保證系統長期、穩定、安全運行，強化數據庫標準化管理，減小故障停機時間，在出現各種異常時有標準處理流程與處理方法可依。
評估要點：規範好制定，落地是難點。既要保證不出問題，又要兼顧必要的效率。比較好的方式是工具平臺化，如能有可量化角度看待則更優，甚至經過AIOps等新興手段，則可進一步提升運維效率，規避風險。
7).數據模型物理化設計
數據模型物理化設計是指在開發部門完成業務模型、邏輯模型設計後，數據庫服務方根據所選數據庫的特性，結合各個邏輯模型的業務特性，如併發、讀寫、數據特徵等，進行數據模型的物理化設計，肯定其對應的表類型、索引設計等，從而得到高效持久的運行效率。
評估要點：如何確保物理模型符合預期，測試是必要的環節之一。能經過對客戶業務的抽取提煉，將其核心邏輯描繪爲數據庫語言，進而驗證模式是否符合預期。此處難點在於對業務提取和抽取能力。
8).數據生命週期設計
這一能力項，也是我我的以爲服務方作的不太好的地方。數據生命週期，是指針對數據的產生、應用、消亡的整個過程進行頂層設計。根據業務特色、增加速度等，制定對應的擴展性設計（知足數據產生要求）、數據分層設計（知足對熱、溫、冷數據）不一樣訪問特色的設計、數據消亡（包括數據歸檔、壓縮、轉儲、清理等）。
評估要點：從業務特色，抽象出數據特色，幫助用戶創建起從端到端的概念。
3. 實施部署域
1).單機部署
單機部署能力，包括具體部署方案、實施計劃、測試驗證方案等內容。包括但不限於基礎環境（硬件、軟件）檢查與準備、數據庫系統安裝、初始化配置、安全加固、部署驗證、組件集成、測試評估、交付上線等環節。這其中有幾個容易忽視的點：
基礎環境檢查與準備
各個客戶環境千差萬別，如何適配差別化環境，前期的檢查準備工做很重要。其中包括對硬件的檢查、基準性能測試（爲後期驗收測試作準備）、軟件系統版本（含補丁）等狀況作好摸底。與數據庫軟件的預安裝條件進行對比，判斷是否知足基本條件。與客戶充分溝通，瞭解第一手的環境狀況。
安全加固
在部署完畢、初始化配置完成後，須要作好必要的安全加固工做。將安全基礎工做作到上線以前，儘可能減小可能的風險問題。
組件集成
數據庫不是孤立系統，是須要與客戶方的其餘系統一塊兒組成基礎平臺。這裏面可能包括客戶方的監控系統、日誌系統、安全系統、審計系統、備份系統、大數據平臺、資源管理平臺、數據中臺等等。在交付上線以前，要作好與這些系統的對接。這些工做很是瑣碎，但很是有必要。這一工做是否順利，取決於前期對客戶系統的調研是否完備？客戶方（或第三方）配合是否默契等
測試評估
在作好上述準備工做後，交付上線以前還須要作好測試評估工做。這一步驟包括功能測試、性能測試、異常測試等。經過這一過程，讓客戶對新上系統有個全面的認識。
交付上線
測試經過後，擇期對客戶交付上線，正式將系統由客戶方接管。通常建議有個過渡期，幫助用戶逐步熟悉掌握。
對於雲端環境，上述過程又有所不一樣。相對而言，雲端環境比較標準，工做也會少些。
評估要點：這一能力項，強調過程的完備、詳實程度。一方面這與具體參與人員的能力有關，另外一方面與實施過的項目積累經驗有關。特別是對於前期、後期的工做更是如此。
2).集羣部署
集羣部署，與單機部署大體步驟相同。特殊之處在於集羣環境，是多機構成，所以對網絡要求更高，必要的前期測試必定要進行。此外，集羣是總體發揮做用，集羣內各組件之間的配合很重要，所以對調試安裝的要求更高。
評估要點：同「單機配置」
3).容災架構部署
容災架構部署，要比前二者更爲複雜。具體部署難度，取決於多種因素，包括技術方案、容災環境等。不一樣的容災方案，帶來的實施難度不一樣，以前談到的容災架構可能包括在應用級、系統級、數據庫級、存儲級等多種狀況，可能涉及多方的配合，不只僅單指數據庫單系統。最終的容災效果，也是取決於多方的配合狀況。至於容災環境，因容災涉及到多個環境，可能包括同城單機房、同城多機房、異地多機房等狀況。特別是對網絡質量，要求很高，須要作對應測試，這是前提。此外，部署後的測試工做對於容災也很重要。如何真實驗證出容災效果？對數據一致性會帶來什麼影響？如何回切等問題都須要考慮。最終給客戶提交的，不只是容災環境，還包括必要的切換文檔、演練文檔、測試報告等。
評估要點：要點在於對容災核心需求的知足程度，這是要與客戶有充分的溝通，獲得一手的需求，設計出適合的系統。此外，與多方協同配合、測試驗證演練也是必不可少的部分。
4).同步架構設計與部署
同步架構，與容災有些相似，也是對多個環境的部署，差別在於需求爲數據同步。須要關注點也與前者相似，涉及同步方案的不一樣所帶來的差別。這裏需關注兩點：一是同步效果的評估，二是對源端系統的影響。這兩方面是須要單獨評估設計的。
評估要點：相似上面，關注點在同步需求的知足程度及多方配合。
5).數據庫遷移
數據庫遷移，狀況比較複雜，差別在於遷移目的、遷移目標和技術方案等。這裏麪包含的兩種狀況：
同構遷移
遷移先後的數據庫相同。此時只要完成數據遷移便可，通常結構、應用等不須要修改。這種狀況相對簡單。常見的好比更換硬件等需求。
異構遷移
遷移先後的數據庫不一樣，這種狀況要複雜不少。通常除了數據遷移外，還包括結構遷移、應用改造、遷移驗證等問題。若是遷移先後的數據庫架構有大的差別，例如從單機到分佈式等，則須要改造的內容更多。
遷移還有幾個重要問題：遷移是在線仍是離線？對時間窗口如何定義？如何作數據一致性驗證？如何對遷移先後的應用功能、性能進行驗證等問題？上述問題，均須要在方案中體現。這部份內容會不少，不展開了，可參考我以前寫的一篇文章《如何作一次完美的數據庫遷移》
評估要點：方案的全面性，特別是遷移中、遷移後的評估等工做，上述甚至可佔到總工做一半以上的內容。
6).數據庫升級
數據庫升級，通常可分爲原地升級、異地升級兩種。前者相對簡單，主要問題在於升級影響、時長、回退方案等問題。後者來講，更爲複雜些，有點相似於遷移流程，這裏不展開了。
評估要點：方案的全面性
7).數據庫整合
數據庫整合，通常是從資源角度考慮，重點須要評估整合後資源是否知足須要？有無業務風險等問題。必要時，整合方案以前加入測試工做。
評估要點：方案的全面性
4. 運維運營域
1).基礎運維
基礎運維，包含的內容比較繁雜。重點在於標準化、規範化，即數據庫的產品化能力是否成熟，是否經過文檔、系統提供出來。而不是僅經過黑盒的方式提供，這對於用戶使用來講意義重大。除了常規的操做外，是否提供了開放能力，方便用戶經過自有平臺運維也很重要，特別是對於中大規模的企業而言。
評估要點：標準化、規範化、文檔化、平臺化
2).雲化運維
雲化運維，重點是在於對雲端資源的管理、安全及開放能力。
評估要點：成熟度
3).數據庫監控
數據庫監控，對於數據庫穩定運行很是重要。監控的主要問題是幾個方面：
指標全面性
指標覆蓋可否全面，能監控到數據庫的方方面面，包括但不限於實例級、對象級、語句級等。
報警可收斂
過多的指標監控，只會形成報警風暴，如何作到報警收斂，突出核心重點，也是監控一個要點。
開放集成性
可很方便的將數據庫監控與客戶其餘報警平臺集成，造成統一總體，進而可實現報警的聯動，從基礎設施、到系統、數據庫、應用直至業務。以此可實現報警問題溯源，方便定位追查問題。
評估要點：成熟度、全面性、擴展性、集成能力
4).健康檢查
也就是咱們常說的巡檢，經過這一能力可對數據庫的當前運行狀態有所瞭解，對可能出現的問題作到提早預警、提早處理。固然，如今巡檢形式也在發生變化，不少健康檢查的工做融合到數據庫內部或平臺自身能力中。可在平常運行中，隨時發現問題。特別是近些年來，在AIOps上的探索，也對健康檢查帶來一些新的思路。
評估要點：全面性、前瞻性
5).SQL審覈
SQL審覈，對保證數據庫應用質量、保證安全運行很重要，以前在這方面的重視程度不足，近些年來獲得了普遍的關注。不少公司自研本身的審覈平臺，也有一些開源的方案，商業產品中也紛紛加強了這一能力。在功能上，包括結構級、語句級、執行特徵等。這項工做通常經過平臺完成，能夠採用半自動、自動的方式進行，可大幅解放DBA的平常工做。這部分常見的問題是SQL審覈的智能化程度、對多數據源的支持、對事前、事中、過後的全流程支持等。
評估要點：平臺化、智能化、可量化
6).備份恢復
備份恢復，是保證數據安全的最後一道防線。功能上除了常規的備份配置、做業監控外，更重要的是恢復驗證、備份集的管理。一方面在備份有效性上的加強，一方面是成本與代價間取得平衡，知足數據安全需求的同時，減小客戶成本支出。此外，還能夠進一步挖掘其潛在能力，例如對開發支持、準生產驗證、審計要求等的知足。
評估要點：平臺化、成本收益
7).安全審計
安全審計，功能要點在於全面性、詳實可信且兼顧成本。這方面主要是知足合規性的要求，防患可能的風險。
評估要點：全面性
8).應急方案演練
應急演練，以前每每重視程度不夠，不少公司從未進行過應急演練。不少應急方案都存在文檔中，束之高閣。但出現緊急狀況時，應急方案反而不適應現狀沒法使用，失去了最本質的意義。所以這塊的要點，是保證應急方案與系統環境的適應匹配，保持最新的狀態。次之，則是儘可能經過平臺化能力（而非文檔化），將應急方案沉澱下來，這有助於應急響應的時效性和有效性。應急演練每每不是單一系統的，須要聯合基礎設施、數據庫、應用系統、業務部分等多方，協同完成。如今也有專門針對應急需求的產品出現，可配置多種資源協同完成應急演練。
評估要點：有效性、時效性、可協同
9).培訓
培訓，是提升數據庫產品使用效果，最爲有效的手段之一。經過提高客戶方能力，可有效提高使用效果，相較而言服務方投入也不大。培訓重點在於摸清客戶需求，有針對性提出培訓方案，可知足客戶從基礎運維、架構設計、應用開發、性能優化等多種角度的培訓需求。此外，具備必定影響力的產品，還可經過創建認證體系等方式，將培訓從單一客戶、開放到普通用戶甚至學生等羣體，構建本身的用戶生態。
評估要點：標準化、定製化
10).性能優化
性能，幾乎是全部客戶的要求，不少問題最後都歸結爲性能問題。針對性能的優化工做，是個較爲複雜的問題。可包括數據庫自身、基礎環境、生態工具、架構設計、開發優化等多方面。要想從全局的角度審視性能問題，是比較困難的，能夠藉助一些APM工具。針對數據庫服務方而言，通常仍是侷限在數據庫自身性能、SQL語句優化等方面。建議採起的措施是平常收集性能基線數據，當出現問題時可對比分析，快速診斷，並給出優化建議。此外，針對客戶進行必要的優化培訓，也是有幫助的。上述優化工做，可經過工具、平臺來完成，提升總體優化效率。甚至有的有實力的廠商，提供自治優化的能力，經過人工智能+知識庫的結合，幫助客戶實現自動優化。
評估要點：優化評估方法、工具、平臺
11).模型優化
模型優化，每每是較容易忽視的一點。這裏所說是模型，可能包括業務模型、邏輯模型、物理模型，對數據庫服務商來講，通常會侷限在物理模型階段。固然，若是對業務模型、邏輯模型有認識，會對客戶帶來更大價值，但這兩點須要對業務有較爲深刻的理解。針對模型的優化，是有固定的方法論的，可經過知識庫、文檔、平臺沉澱下來。
評估要點：模型方法論
12).數據生命週期管理
數據生命週期管理，是對客戶數據實現全流程的管理。從數據產生、使用、歸檔到銷燬多個階段的管理。這一能力，通常是經過平臺來完成這些管理動做。相對而言，這方面的成熟經驗很少。
評估要點：方法論、成熟平臺
韓鋒頻道：
關注技術、管理、隨想。
長按掃碼可關注
QQ羣號：763628645
QQ羣二維碼以下， 添加請註明：姓名+地區+職位，不然不予經過
本文分享自微信公衆號 - 楊建榮的學習筆記（jianrong-notes）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。