對于絕大多數企業來說，企業的資訊化建設是随着企業業務的發展不斷推進的，而随着企業業務的複雜化和多元化，對于資訊化系統的要求也越來越高，對于資訊化建設的整體架構、內建整合、資料治理、安全管控的要求也在不斷提升，而內建底座就是從企業資訊化建設的角度出發，搭建統一、标準、柔性、可複用、可擴充的IT架構，解決企業資訊化建設過程中缺乏整體規劃、內建整合難度大、安全管控不到位等問題。
內建底座主要包括IDM統一認證平台、MDM基礎資料平台、ESB企業服務總線三個産品，産品之間互相支撐，同時對外提供資料和服務。對于企業而言，內建底座更多的是提供一套系統解決方案，奠定企業IT基礎，是以在實施內建底座項目時，要立足長遠，要充分考慮企業未來的資訊化發展趨勢。
1總體說明
內建底座主要包括三個産品：IDM統一認證平台、MDM基礎資料平台、ESB企業服務總線，其中IDM平台基于5A管控體系實作統一使用者、統一認證、統一授權、統一審計、統一應用管控等安全管控；MDM通過支援組織、崗位、人員等主資料的同步分發，實作主資料的标準化，實作全生命周期的主資料管理；ESB作為內建通道，通過API管理将業務系統接口注冊、代理到ESB平台，并通過平台實作集中監控、認證、限流、報警等功能，在滿足IDM、MDM以及上下遊系統的內建管理的同時實作服務接口的集中化管理。
1.1內建架構
內建底座方案的內建主要是基于IDM和MDM作為資料的集中維護平台，通過ESB進行服務API的管理，建構內建通道，進而實作IDM、MDM以及上下遊系統的打通。由業務系統作為基礎資料的源頭，這些基礎資料通過ESB同步至MDM平台進行統一管理，保證基礎資料的準确性、唯一性、完整性；MDM将組織、人員等基礎資料分發至IDM生成對應認證賬号資訊，用于支援統一認證等業務；整個內建過程中，ESB作為服務總線負責對各個系統的接口和服務進行注冊和管理，同時建構系統資料對接的內建流程。
1.2業務場景
內建的業務場景內建主要是基于IDM和MDM的資料同步分發，其中包括業務系統到MDM的主資料同步，主資料到下遊系統的下發（包括下發IDM），以及IDM下發賬号到下遊系統等。
1.主資料同步：
1)源頭推送資料（或者推送查詢辨別）至ESB的內建流程；
2)ESB內建擷取源頭資料（或者通過查詢辨別從源頭查詢資料）後，在內建流程内部調用MDM的接口，将資料寫入MDM，同時生成任務和日志，并回寫源頭系統；
3)ESB內建流程調用MDM的自動送出接口将任務送出至MDM的BPM工作流中，BPM工作流調用MDM接口實作資料向下遊系統的分發。
2.主資料分發：
1)主資料分發采用推送的方式，在MDM的BPM工作流中觸發推送；
2)下遊系統需要提供資料接收接口，在MDM中配置該接口，并在MDM的BPM工作流中調用MDM的分發接口（分發接口内部調用下遊系統接收接口）實作資料分發；
3)下遊系統接收資料後，接口内部進行系統寫入，完成後調用MDM的日志回寫接口進行資料回寫操作。
3.賬号分發：
1)賬号分發主要是通過IDM将登入使用者資訊分發至下遊系統，實作各系統的統一認證和單點登入；
2)IDM賬号分發主要是将IDM的賬号資訊通過任務的形式分發下遊系統，和MDM的分發方式類似；
3)在賬号資訊進入IDM平台，可以手動或自動的方式生成分發任務，再通過IDM内置的BPM工作流進行自動送出；
4)在BPM工作流内調用IDM的分發接口将資料推送至下遊系統的資料接收接口中，而下遊系統的資料接收接口則配置在IDM平台的應用管理中；
5)下遊系統完成資料寫入後調用IDM的日志回寫接口進行資料回寫操作。
1.3實施模式
內建底座主要包括IDM、MDM和ESB三款核心産品，通過反複的内部演練以及實際項目的磨練，目前內建底座已經逐漸形成了一套标準的實施規範，包括主資料的規劃、資料同步分發、賬号管理、統一認證、API管理等，是以目前內建底座更多采用産品 + 教育訓練的傳遞模式，即我們提供産品以及基于雲平台的環境部署、産品安裝，同時提供對于各個産品、內建方案、接口開發的教育訓練，由夥伴或者客戶方來完成具體的實施和建設工作，而在實施過程中，我們進行遠端或現場的技術支援和指導。
內建底座的實施模式需要輕實施、重教育訓練，強調夥伴或客戶在實施過程中的參與，這樣做的好處在于：
1.降低項目參與度，減輕工作量，能将項目團隊投入到更多的項目中，滿足公司發展需要；
2.内部團隊有更多的機會參與項目、了解業務，了解産品和方案在實際項目中的應用，有利于團隊的建設和成員能力的培養；
3.教育訓練夥伴或客戶熟悉産品的使用和項目實施，發揮夥伴方、客戶方的優勢，加快項目實施傳遞的效率；
4.夥伴或客戶掌握到産品和方案的精髓後，更有意願去推動更多的同類項目，進而提供更多的商機，提高産品出貨量。
1.4實施流程
內建底座項目的實施流程也是遵循規範的項目實施流程，包括需求調研、環境部署、實施傳遞、上線驗收、後期運維等階段，但是和實施類項目不同，內建底座采用産品 + 教育訓練的模式，是以更多的工作是需要傳遞夥伴或客戶方完成的，項目團隊更多的是起到輔助的作用。
1.需求調研：由項目團隊和實施方共同完成，項目團隊提供調研模闆、調研大綱、調研思路，雙方共同參與明确項目需求和範圍，實施方了解業務、需求，同時熟悉産品的使用，便于後續的實施傳遞；項目團隊提供資料協助實施方完成調研，同時搭建測試環境，教育訓練實施方了解産品的使用，同時項目團隊需要在調研過程中了解客戶的業務，強化業務能力，也為後續項目提供借鑒；
2.環境部署：環境部署一般由項目團隊或内部運維團隊負責，內建底座采用雲平台的部署方案，提供一鍵部署腳本和對應的文檔，可以實作快速部署；在實際項目中一般會部署兩套環境：一套測試環境采用非高可用部署，在前期調研階段部署，用于給客戶示範、調研需求和産品使用教育訓練；一套生産環境，一般在正式實施時部署，采用高可用部署，搭建開發、測試、生産環境，滿足後續項目開發、測試、生産運作需要；
3.實施傳遞：內建底座主要采用産品 + 教育訓練的實施模式，實施傳遞的主體一般是合作夥伴或客戶的資訊化團隊，項目團隊主要是根據前期調研的需求協助輸出對應的标準規範、藍圖資料，以及在實施過程中提供産品教育訓練、技術指導、方案支援等，一般提供遠端支援，但可以根據實際情況，提供短期的現場支援；
4.上線驗收：上線、驗收和實施一樣，主體也是合作夥伴或客戶的資訊化團隊，項目團隊以支援、輔助為主，協助實施方輸出上線文檔、上線流程、復原政策等，協助實施方完成項目的整體上線試運作，以及最終的項目驗收；
5.後期運維：一般運維工作内部會移交運維團隊，具體運維工作由夥伴或客戶方進行，内部運維團隊隻負責解決一些産品使用、功能上的問題，同時針對夥伴或客戶方經常出現的問題進行技術指導和教育訓練，協助夥伴或客戶更加深入地掌握産品和方案，以促進後續更多的合作。
對于內建底座項目，在實施傳遞過程中，在不同的時間節點，需要傳遞的文檔清單如下：
2需求調研
需求調研是項目實施的第一項工作，也是非常重要的工作，由于前期項目團隊、夥伴、客戶、業務廠商的熟悉程度不夠，缺乏足夠的信任，往往需要一段時間的磨合，是以在這個階段需要經常溝通、互相交流、加強合作、達成共識，為項目的成功奠定基礎。
內建底座項目又是一個跨組織、跨業務、跨系統的項目，是以調研時往往需要對客戶的需求、實際的業務、系統的情況、廠商的配合等各個層面進行調研，更需要項目團隊掌握溝通技巧、了解産品方案、熟練調研流程。在溝通過程中，需要不斷輸出內建底座的實施方案，引導客戶、廠商按照內建底座的标準模式進行實施，降低實施傳遞的難度，以達到項目的快速傳遞。
2.1主資料管理
主資料的調研一般需要從項目的整體規劃和實際業務出發，梳理主資料的具體範圍，以及每一類主資料的編碼、屬性、來源、目标、內建等内容，具體内容可以包括：
1.項目規劃：項目規劃一般在客戶進行項目立項時就會明确，規劃具體的建設内容和建設範圍，但是在項目開始實施時，實施團隊需要和客戶反複進行讨論，一方面是對具體實施範圍進行确定，确定哪些做，哪些不做；二是對客戶進行引導，使項目的實施過程遵循內建底座的标準流程，便于後期實施傳遞和上線驗收的推進；
2.核心業務：調研過程中要充分了解客戶的核心業務，梳理業務時結合現有的業務系統進行分析，明确業務運作過程中可能涉及的主資料，同時在梳理過程中也要對客戶的業務進行分析整理，積累對業務的認知和了解，為後續項目的實施、售前、産品開發等提供借鑒；
3.類别明确：明确本期項目需要建設的主資料類别，如果單純從內建底座的角度，一般隻需要建設組織、崗位、人員等人事相關基礎資料，但是為了滿足客戶的業務需要，同時加強內建底座的實際應用場景，可以考慮根據實際業務建設一些重要的主資料，支撐業務的同時也為後續深度主資料治理和資料中台建設奠定基礎；
4.編碼規則：主資料的編碼規則一般有兩種情況：一是由源頭系統提供，MDM平台直接引用源頭系統編碼，二是在MDM平台配置編碼規則，在資料同步到MDM平台時自動生成。第一種直接複用源頭系統，MDM無需進行處理，但是需要源頭系統保證編碼規則的唯一性、準确性；第二種MDM需要配置編碼規則，可以保證唯一性、準确性，但是在同步時需要将編碼回寫源頭系統，二者各有優勢，在實際項目中可以根據實際需要靈活選擇；
5.屬性定義：MDM支援中繼資料管理，可以根據實際需要配置各類主資料的屬性資訊，一般屬性的定義需要包括以下内容：源頭系統包括的屬性，并且需要分發到下遊系統，實作多系統共享；在實際業務運轉過程中需要維護使用的屬性；
6.參考資料：參考資料由業務系統提供，一般由源頭系統提供，MDM平台參考進行配置，同時由于各個系統參考資料的定義是不同的，是以涉及資料下發時，需要明确下遊系統的參考資料定義方式，并在MDM平台進行關聯配置；
7.校驗規則：主要是針對不同的屬性配置校驗方式，如非空、數字、唯一、長度等，主要是為了保證主資料的規範性、完整性，降低人工維護時産生的異常資料；
8.來源系統：針對每一類主資料需要明确主資料的權威來源，來源于哪個系統的哪個子產品，是否能采用推、拉的方式進行資料推送，是否可以配合進行擴充等；
9.目标系統：針對不同的主資料需要明确都有哪些業務系統進行接收，是否有對應的接收接口，是否能夠配合進行擴充，接收時需要接收哪些中繼資料等；
10.內建方式：內建底座的資料內建支援推、拉、定時等方式，但是為了保證資料的及時性，絕大多數采用推、拉的方式，一般會涉及上下遊系統的改造，包括上遊系統的實時推送，以及下遊系統的資料接收接口等，在調研時要明确具體的內建方式以及相關資料接口。
2.2.統一認證
統一認證主要是基于內建底座的IDM平台實作的，平台提供了CAS、OAuth、接口三種認證方式，滿足不同場景、不同系統的對接需求。在前期調研過程中，要明确需要對接統一認證的系統有哪些，分别采用哪種開發語言、技術架構，針對不同的語言、架構提供認證方式，具體實施時由系統方根據認證标準自行配置處理。
IDM平台支援密碼內建，包括密碼同步、密碼分發，但是在實際項目中，不建議進行密碼內建，一方面進行密碼傳輸的過程中，容易造成密碼洩露，增大安全風險；另一方面實作統一認證之後，登入直接采用統一認證，使用IDM的密碼進行認證，不需要保持業務系統和IDM的密碼一緻。
2.3統一API
內建底座的統一API主要是基于ESB的API管理功能實作，在ESB的SMC管理控制台中将各個業務系統的接口統一注冊進來，支援Web、Rest、Http等不同類型的服務接口，注冊後的接口可以在應用內建中調用，也能通過代理的方式提供給其他系統。
在項目調研過程中，主要需要明确接入的業務系統有哪些，除了內建底座内部的接口注冊以及應用內建配置外，是否有其他系統需要進行接口注冊，是否有單據內建、憑證內建等內建需求，是否需要在ESB進行接口統一管理。
對于注冊在ESB中的接口，需要明确對于接口安全、資料安全、資料加密、安全認證、異常報警等機制的需求，根據需要進行标準制定，以便後續實施過程中進行對接。
2.4标準規範
內建底座的标準規範主要包括以下内容：
1.主資料資料規範：根據制定的主資料範圍，制定每類主資料的相關資料标準，包括編碼、屬性、參考資料等；
2.主資料管理規範：從組織管理角度出發，針對主資料的管理組織、管理角色、管理人員、維護流程等内容制定統一的标準要求；
3.主資料內建規範：基于制定的主資料範圍、屬性，以及對接的上下遊系統，制定資料內建标準，包括推送、拉取的方式，觸發的機制，推送的内容和業務系統等；
4.主資料清洗規範：主要針對MDM平台的資料初始化，對于現在系統中已有的曆史資料，在初始化同步到主資料平台時，如何進行清洗、合并、标準化處理；
對于主資料的資料規範、管理規範、內建規範、清洗規範，一般會合并到同一個主資料标準規範文檔中。
5.MDM主資料平台接口說明：MDM平台的接口标準文檔，該文檔會根據MDM平台的開發和更新進行更新。
6.IDM身份管理平台接口說明：IDM平台的接口标準文檔，該文檔會根據IDM平台的開發和更新進行更新。
7.ESB企業服務總線服務标準：ESB平台的标準說明文檔，主要針對ESB平台服務接口的開發标準、協定支援等。
8.IDM統一認證對接标準：主要針對IDM統一認證相關的内容說明，包括統一使用者說明，CAS、OAuth、接口認證說明，以及統一密碼實作說明等，參考如下。
3環境部署
內建底座采用雲平台的部署方式，在實際項目中一般由内部實施團隊或内部運維團隊負責部署安裝，一般會建議部署兩套環境，一套是基于3台伺服器的非高可用環境，一般用于前期調研時對客戶進行産品示範、樣例說明，以及針對夥伴或客戶資訊化團隊的教育訓練工作；另一套環境是在調研後期或藍圖确認後部署的正式環境，采用至少5台伺服器的高可用環境，内部至少部署開發、測試、生産三個環境，以保證在實施過程中的可以進行産品的配置、環境的搭建。
3.1K8S部署
內建底座采用雲平台部署方案，現在K8S的雲平台部署已經建構了一鍵部署腳本，可以通過腳本實作快速部署，同時支援離線部署，即使在内網環境下，也可以完成環境部署工作。并且針對3台非高可用和5台高可用提供不同的部署腳本，可以滿足不同使用場景的需要。
3.2産品部署
內建底座除了包括IDM、MDM、ESB三款核心産品外，還有UMC雲管理平台，主要用于配置和管理K8S叢集，以及叢集内部的環境、容器、産品、元件等配置與部署，以及外部Nginx的接入配置等。對于UMC上容器、産品的部署，也支援通過一鍵部署腳本進行操作，并提供由對應的部署文檔。
3.3 安全政策
內建底座一般面對企業級客戶，并且涉及了企業的核心資料，為了保證資料的安全性，需要從網絡、伺服器、産品等多個層面保證系統的安全性，主要包括：
1.在準備伺服器時建議搭建堡壘機，通過堡壘機跳轉通路真實伺服器，提高伺服器安全性；
2.伺服器防火牆隻開放内部伺服器之間的IP互通，不開放外部IP和端口的通路，對于部署外部Nginx的伺服器，根據部署的環境對應開放相應的端口；
3.對于Redis、資料庫、産品等相關密碼都需要采用複雜密碼，并且保證密碼是不一樣的，避免密碼洩露的可能。
3.4環境測試
環境部署後需要對環境進行整體測試，包括産品功能、服務接口、內建流程，要根據實際業務需求對功能、壓力進行測試，保證功能可用的同時，也要保證伺服器的穩定性和并發壓力。主要測試内容：
1.IDM、MDM、ESB的各個功能子產品，包括頁面顯示、資料管理、配置功能等，以及ESB設計器的連接配接，工程、服務、流程的開發部署等；
2.IDM、MDM、ESB的相關服務接口，包括資料提供、資料接收、任務處理、token認證等；
3.IDM認證壓力測試：對IDM的CAS、OAuth、接口認證進行壓力測試，基于JMeter模拟實際業務場景進行并發壓力和穩定性測試，主要測試高并發的認證登入以及低并發長時間的穩定性（8-10小時）；
4.MDM資料接口測試：針對主資料的同步、分發、查詢接口進行壓力測試，主要測試低并發、大資料量的情況；
5.測試後需要輸出對應的測試報告。
4實施傳遞
內建底座采用産品 + 教育訓練的實施模式，項目的實施傳遞主體為夥伴或客戶資訊化團隊，而内部項目團隊主要負責産品教育訓練和技術支援，以遠端支援為主，根據具體項目進度和實際情況，可以短期進行現場技術支援，但實施的主體也是夥伴方，而非項目團隊。
對于內建底座項目，主要的實施内容包括：
1.資料內建：以主資料為主，進行MDM和上下遊系統之間的主資料同步分發，其中包括了IDM的資料同步，以及IDM使用者資料的分發；
2.應用內建：以IDM為主，實作各個系統的統一認證，搭建統一認證中心；
3.服務內建：以ESB為主，将各個系統的服務接口注冊到ESB平台進行統一管理。
4.1産品教育訓練
産品教育訓練是內建底座項目中非常重要的部分，由于采用的産品 + 教育訓練的模式，是以需要通過教育訓練讓實施方充分了解産品的特性、使用場景，以及對于不同的業務場景，應該如何通過産品配置進行實作。教育訓練的主要内容需要包括：
1.內建底座的整體內建架構、資料架構、內建方式等；
2.內建底座和上下遊系統內建時，內建的内容、內建的方式，提供的資料；
3.MDM平台資料管理維護的方式，主資料模型的配置過程，包括模型定義、屬性定義、編碼規則、校驗規則，以及同步分發過程中的系統注冊、分發範圍、接口調用等；
4.IDM平台組織、崗位、使用者的管理維護方式，擴充字段的配置，密碼政策的配置，統一認證的配置，同步分發的相關接口說明等。
4.2資料內建
主要是主資料的同步分發，包括：
1.從源頭系統主資料同步MDM平台；
2.MDM平台資料下發下遊業務系統；
3.MDM平台組織、崗位、人員資料下發IDM；
4.IDM使用者資料下發需要接入統一認證的系統，保證賬号一緻。
資料內建的過程中，需要主推标準的內建方案，內建底座内部的資料內建可以直接複用預置的相關服務樣例，和上下遊系統對接時直接根據藍圖階段制定的标準規範。推薦實施方式：
1.主資料同步采用推送模式，由源頭系統觸發推送資料，通過ESB開發應用內建流程實作源頭系統到MDM平台的資料寫入；
2.MDM平台下發由下遊系統提供接收接口，內建底座提供标準的資料格式，采用MDM的推送（或推拉）模式将資料（或任務辨別）發送給下遊系統；
3.IDM的賬号下發和MDM一樣，也是由下遊系統提供接收接口，IDM采用推送（或推拉）模式将資料（或任務辨別）發送給下遊系統。
4.3應用內建
應用內建主要是基于IDM平台建構統一認證體系，打通系統通路的壁壘，IDM平台提供CAS、OAuth、接口認證三種認證方式，業務系統根據自身系統情況自行選擇，實施團隊協助提供配置樣例和說明文檔。
一般內建底座的IDM實施會以統一使用者、統一認證、統一審計、統一應用管控這4A為主，而統一應用管控是在IDM平台配置各個系統資訊，統一審計是對資料的統計、分析和監控，是以統一使用者、統一認證往往是內建底座項目中最多的内容。
1.統一使用者：IDM使用者分發下遊系統，保證IDM和下遊系統登入賬号的一緻性，建議采用推送模式，IDM提供标準的參數格式，下遊系統提供資料接收接口，由IDM平台推送使用者資料至下遊系統；
2.統一認證：基于IDM的标準認證方式，以下遊系統為主配置統一認證。
4.4服務內建
以ESB的API管理為主，對業務系統的服務接口進行API注冊、API管理、API代理、安全政策、監控預警等内容。
1.配置ESB應用內建時進行服務接口的引用；
2.其他系統內建時調用ESB代理接口，通過ESB進行日志記錄、監控、預警等；
3.推薦對接的接口都注冊到ESB中，基于ESB進行監聽和管控；
4.對于IDM、MDM、ESB等内部使用的接口，全部注冊到ESB中通過應用內建調用；如果支援外部系統調用，則需要對接口進行代理；
5.如果項目中存在單據內建、憑證內建的業務內建需求，則需要通過ESB進行API的注冊、代理，業務系統直接調用代理接口；
6.如果需要保證資料安全性，建議采用資料加密、token認證等機制進行接口控制。
5上線驗收
上線驗收和實施傳遞一樣，也是以夥伴方的實施團隊為主進行推動，内部項目團隊在這過程中進行輔助支援，以保證項目的順利上線，包括上線前期的資料準備，風險評估，以及上線後的運作監控、産品問題修複等。
5.1上線準備
在上線前需要對上線需要做的工作提前進行梳理，形成上線文檔，明确上線時間、上線步驟、初始化資料、接口切換等内容，由于內建底座項目涉及各個系統的內建與切換，是以需要和客戶方提前約定時間，在不影響客戶業務運作的情況下進行更新切換，特别是存在曆史系統的更新的情況。
1.上線時間：上線的開始、結束時間，資料準備、系統切換的時間節點，需要明确到具體時間點；
2.上線步驟：上線的具體流程，包括資料伺服器準備、環境部署、資料初始化準備、系統切換、接口切換等，并且需要明确每個節點的人員和時間節點；
3.初始化資料：包括IDM、MDM的資料初始化以及業務系統的資料初始化，明确資料初始化的時間節點和負責人；
4.接口切換：原有系統的接口切換步驟，包括舊接口的停用以及新接口的啟用時間節點等。
5.2風險預案
風險預案主要是針對上線過程中可能出現的問題進行提前預估，并制定解決政策，如果上線過程中出現問題，可以按照風險預案進行緊急補救。一般情況下由于內建底座采用雲平台部署，可以直接通過資源同步快速部署生産環境，同時在上線前也會在測試環境進行模拟驗證，是以大多數情況下上線會比較順利。
但是由于內建底座會和各個業務系統內建，是以可能出現業務系統互動異常的情況，是以針對各種可能出現的問題要提前進行預估，如上線後無法實作統一認證攔截，統一認證成功後無法跳轉業務系統，資料內建時出現資料同步失敗，ESB代理的API無法調用等問題，針對每一個可能的問題都需要制定問題排查處理的政策，保證可以快速進行問題定位和處理。同時也需要做好最壞的準備，即上線復原，如果問題比較嚴重，上線後無法滿足業務使用，則需要制定復原政策，復原到上線前的狀态。
5.3 上線監控
在項目上線後需要實施團隊實時關注項目運作情況，包括IDM認證情況、MDM/IDM的資料同步分發情況，ESB服務接口的調用情況，同時也需要對伺服器的運作情況進行監控，保證各個産品可以穩定運作。
上線監控階段不僅需要實施團隊進行監控，客戶方的資訊部門以及業務人員也要參與其中，主要是确認業務運作是否順利，是否存在資料異常等問題，并且對過程中的問題進行記錄和回報，實施團隊及時跟進處理，保證項目的順利上線，以便于推動後續的驗收。
5.4驗收推進
在上線運作穩定之後，實施團隊需要開始整理項目驗收資料推動項目驗收，根據項目的具體情況，驗收資料也會有所差別，對于內建底座項目，一般至少要包括以下内容：
1.伺服器資訊，環境部署清單，部署文檔和資料，相關登入賬号和密碼；
2.需求說明書、設計說明書、使用手冊、操作手冊、标準規範、內建說明等藍圖資料；
3.産品測試報告、安全報告等測試相關資料；
4.項目運維文檔、常見問題處理等運維相關資料。
項目的驗收推送也是以實施方為主，内部項目團隊主要是提供相關資料模闆和說明，協助實施方出具相關驗收資料。
6後期運維
後期運維主要包括兩部分内容：一是由夥伴的實施/運維團隊進行的日常運維，一是由内部運維團隊進行的遠端技術支援，主要處理實際業務中出現的産品級問題。
6.1運維團隊
由于內建底座采用産品 + 教育訓練的方式，是以運維會以夥伴方為主，夥伴方根據實際情況建立運維團隊進行日常的維護，協助客戶進行問題定位與處理，主要處理客戶實際業務中出現的使用問題、相關流程的優化、配置的優化等，以及客戶業務變更時出現的流程調整等内容。
内部運維團隊主要負責解決産品級問題，如果産品在實際運作過程中，如果出現産品BUG，内部運維團隊需要協助進行問題定位與處理，同時對于産品在使用過程中也要對夥伴和客戶進行指導，加強使用方對産品的深度了解。同時為了保證內建底座的應用效果，一般在項目上線後也會進行一些産品更新，這些更新工作需要内部運維團隊提供更新說明，協助夥伴方完成更新。
6.2運維流程
針對項目中運維工作，需要制定标準的運維規範和流程，包括客戶使用産品的方式，使用過程中的注意事項，出現問題時回報的管道、回報的方式，運維團隊問題處理的步驟、時間節點等。運維的目的不僅僅是消除問題，同時也是向客戶輸出知識的過程，通過指導、教育訓練，使客戶能充分掌握産品的使用，甚至能自行進行問題的定位與處理。
6.3運維手冊
項目運維手冊在項目上線後就需要整理，在驗收前需要提供給客戶，以便在項目運維過程中能及時進行問題處理，将出現問題時對業務的影響降低到最小。不同于藍圖、産品等相關檔案，運維手冊是一個需要不斷完善的文檔，在實際運維過程中，需要根據日常的運維情況将新出現的問題及時整理到運維手冊中，一方面可以幫助客戶更好的掌握産品的使用和問題的處理，同時也能為後續接手運維的人員可以更快速地熟悉工作。