簡介這份PPT資源聚焦區(qū)級大數(shù)據(jù)資源平臺(tái)建設(shè)的可行性研究面向政務(wù)信息化規(guī)劃人員、大數(shù)據(jù)平臺(tái)架構(gòu)師及智慧城市項(xiàng)目從業(yè)者幫助讀者理解從現(xiàn)狀分析到落地實(shí)施的完整論證思路。資源包共1個(gè)pptx文件約2.61MB以圖文并茂的幻燈片形式呈現(xiàn)便于直接用于匯報(bào)或方案參考。內(nèi)容圍繞項(xiàng)目概況、現(xiàn)狀分析、需求分析、總體框架與詳細(xì)建設(shè)方案展開涵蓋城市駕駛艙、數(shù)據(jù)資源中心、統(tǒng)一數(shù)據(jù)管理門戶等模塊并給出5PB存儲(chǔ)、百萬級數(shù)據(jù)分鐘級計(jì)算、200人并發(fā)開發(fā)等性能指標(biāo)以及14臺(tái)大數(shù)據(jù)平臺(tái)服務(wù)器、20臺(tái)共享交換軟件等硬件配置建議。同時(shí)梳理了六位一體大數(shù)據(jù)資源體系、數(shù)據(jù)標(biāo)準(zhǔn)規(guī)范與安全保障要求并論證了項(xiàng)目建設(shè)的必要性。目前已有180人學(xué)習(xí)適合需要撰寫政務(wù)大數(shù)據(jù)平臺(tái)可研報(bào)告或搭建數(shù)據(jù)資源體系的讀者參考借鑒。1. 大數(shù)據(jù)資源平臺(tái)建設(shè)可行性研究一份PPT背后到底要論證什么很多做數(shù)據(jù)平臺(tái)的朋友第一次接到“可行性研究方案”這個(gè)任務(wù)時(shí)第一反應(yīng)是打開PPT模板往里填字。但真正落地過的人都知道可行性研究不是寫作文它是一份給決策層看的“風(fēng)險(xiǎn)與收益說明書”。一份大數(shù)據(jù)資源平臺(tái)建設(shè)可行性研究方案核心要回答三個(gè)問題當(dāng)前的數(shù)據(jù)現(xiàn)狀到底痛在哪、建這個(gè)平臺(tái)需要投入多少資源、建成之后能不能真正跑起來并產(chǎn)生價(jià)值。它適合的人群很明確——正在被數(shù)據(jù)孤島折磨的數(shù)據(jù)負(fù)責(zé)人、需要向上匯報(bào)立項(xiàng)的技術(shù)主管、以及被拉來寫方案但不知道從哪下手的工程師。這份PPT不是技術(shù)文檔它的每一頁都在為“要不要批這筆預(yù)算”服務(wù)所以寫法和技術(shù)方案完全不同。2. 可行性研究方案的四層論證結(jié)構(gòu)從業(yè)務(wù)痛點(diǎn)推到技術(shù)選型2.1 第一層把業(yè)務(wù)痛點(diǎn)翻譯成數(shù)據(jù)語言可行性研究最容易翻車的地方是通篇講“數(shù)據(jù)很重要”但說不出具體哪里痛。我一般會(huì)先做一輪數(shù)據(jù)資產(chǎn)盤點(diǎn)把現(xiàn)狀用數(shù)字?jǐn)[出來。比如某公司的業(yè)務(wù)系統(tǒng)有12個(gè)每個(gè)系統(tǒng)獨(dú)立維護(hù)自己的數(shù)據(jù)庫客戶信息在CRM、訂單系統(tǒng)、客服工單里各存一份字段定義還不一致。這種現(xiàn)狀不能只寫“存在數(shù)據(jù)孤島”要寫成“客戶主數(shù)據(jù)在3個(gè)系統(tǒng)中字段不一致率達(dá)37%導(dǎo)致月度經(jīng)營分析報(bào)表需要人工核對2天”。盤點(diǎn)的具體做法是列一張表把數(shù)據(jù)源、數(shù)據(jù)量、更新頻率、負(fù)責(zé)人、當(dāng)前使用方式全部填進(jìn)去。這張表不需要多漂亮但必須真實(shí)。我見過太多方案在這一步就開始編數(shù)字后面所有論證都建立在假數(shù)據(jù)上評審時(shí)被問一句“這個(gè)37%怎么算出來的”就露餡了。盤點(diǎn)維度需要記錄的內(nèi)容常見坑數(shù)據(jù)源系統(tǒng)名稱、數(shù)據(jù)庫類型、表數(shù)量漏掉Excel和手工臺(tái)賬數(shù)據(jù)量當(dāng)前存量、日增量、年增長預(yù)估只算存量不算增量更新頻率實(shí)時(shí)/小時(shí)/天/周把“應(yīng)該實(shí)時(shí)”當(dāng)成“已經(jīng)實(shí)時(shí)”數(shù)據(jù)質(zhì)量空值率、重復(fù)率、字段不一致率抽樣太少導(dǎo)致偏差使用現(xiàn)狀誰在用、怎么用、痛點(diǎn)是什么只問IT不問業(yè)務(wù)這張表填完之后痛點(diǎn)自然就浮出來了。比如你會(huì)發(fā)現(xiàn)某個(gè)核心表的空值率高達(dá)25%但業(yè)務(wù)部門一直在用這張表做決策。這種發(fā)現(xiàn)比任何形容詞都有說服力。2.2 第二層技術(shù)架構(gòu)的可行性論證怎么寫才不空技術(shù)可行性不是列一堆技術(shù)名詞就完事。評審的人想看到的是你選的這套架構(gòu)在當(dāng)前團(tuán)隊(duì)能力和預(yù)算下能不能跑起來。我通常從三個(gè)維度論證數(shù)據(jù)接入能力、存儲(chǔ)計(jì)算能力、服務(wù)輸出能力。數(shù)據(jù)接入方面要明確支持哪些數(shù)據(jù)源類型。關(guān)系型數(shù)據(jù)庫、日志文件、API接口、消息隊(duì)列這四類基本覆蓋大多數(shù)場景。每類給出具體的接入方式比如MySQL用CDC方式做增量同步日志用Filebeat采集API用定時(shí)拉取。不要寫“支持多種數(shù)據(jù)源”這種廢話要寫“支持MySQL、PostgreSQL、Oracle的CDC增量接入支持Kafka、RabbitMQ的消息訂閱支持HTTP API的定時(shí)輪詢”。存儲(chǔ)計(jì)算方面需要根據(jù)數(shù)據(jù)量和查詢模式做選型。如果數(shù)據(jù)量在TB級別、查詢以聚合分析為主列式存儲(chǔ)加MPP引擎是常見選擇。如果數(shù)據(jù)量在PB級別、需要處理非結(jié)構(gòu)化數(shù)據(jù)對象存儲(chǔ)加Spark生態(tài)更合適。這里的關(guān)鍵是給出量化依據(jù)比如“當(dāng)前存量數(shù)據(jù)8TB日增量200GB按3年保留期計(jì)算總存儲(chǔ)需求約230TB考慮3副本冗余需要690TB裸容量”。服務(wù)輸出方面要說明平臺(tái)建成后數(shù)據(jù)怎么被消費(fèi)。常見方式包括JDBC/ODBC查詢、REST API、數(shù)據(jù)文件導(dǎo)出、消息推送。每種方式要說明適用場景和性能預(yù)期比如“JDBC查詢支持并發(fā)50P95響應(yīng)時(shí)間在3秒以內(nèi)”。注意技術(shù)可行性論證里最忌諱寫“采用業(yè)界領(lǐng)先的XX技術(shù)”。評審專家聽到這種話只會(huì)覺得你沒想清楚。要寫具體版本、具體參數(shù)、具體限制。2.3 第三層經(jīng)濟(jì)可行性要算三筆賬經(jīng)濟(jì)可行性是決策層最關(guān)心的部分但很多技術(shù)出身的寫方案時(shí)只會(huì)算硬件采購成本。實(shí)際上要算三筆賬建設(shè)成本、運(yùn)營成本、收益預(yù)估。建設(shè)成本包括硬件采購、軟件授權(quán)、人力投入、實(shí)施費(fèi)用。硬件按存儲(chǔ)、計(jì)算、網(wǎng)絡(luò)分別列軟件授權(quán)要區(qū)分商業(yè)軟件和開源軟件開源軟件雖然免費(fèi)但要考慮支持成本人力投入按人月計(jì)算要寫明每個(gè)角色投入多少人月實(shí)施費(fèi)用包括咨詢、集成、培訓(xùn)。運(yùn)營成本包括電力、機(jī)柜、帶寬、運(yùn)維人力、軟件續(xù)費(fèi)。這部分容易被忽略但三年下來往往超過建設(shè)成本。我一般會(huì)按建設(shè)成本的30%到50%估算年運(yùn)營成本。收益預(yù)估是最難的部分因?yàn)閿?shù)據(jù)平臺(tái)的收益往往是間接的。常見做法是算三塊人力節(jié)省原來需要5個(gè)人做報(bào)表現(xiàn)在2個(gè)人、決策效率提升原來月度報(bào)表要等3天現(xiàn)在實(shí)時(shí)可查、業(yè)務(wù)機(jī)會(huì)通過數(shù)據(jù)分析發(fā)現(xiàn)的新增長點(diǎn)。前兩塊可以量化第三塊只能定性描述。# 簡單的三年TCO估算模型 # 參數(shù)說明 # hardware_cost: 硬件采購總價(jià)萬元 # software_cost: 軟件授權(quán)總價(jià)萬元 # labor_cost: 人力投入總價(jià)萬元 # implement_cost: 實(shí)施費(fèi)用萬元 # annual_opex_ratio: 年運(yùn)營成本占建設(shè)成本比例一般0.3-0.5 def tco_3year(hardware_cost, software_cost, labor_cost, implement_cost, annual_opex_ratio0.4): capex hardware_cost software_cost labor_cost implement_cost opex_per_year capex * annual_opex_ratio total capex opex_per_year * 3 return { 建設(shè)成本: capex, 年運(yùn)營成本: opex_per_year, 三年總成本: total } # 示例硬件200萬軟件80萬人力150萬實(shí)施50萬 result tco_3year(200, 80, 150, 50) print(result) # 輸出{建設(shè)成本: 480, 年運(yùn)營成本: 192.0, 三年總成本: 1056.0}這個(gè)模型雖然簡單但能把賬算清楚。評審時(shí)如果有人問“為什么運(yùn)營成本這么高”你可以拆開解釋電力占多少、運(yùn)維人力占多少、軟件續(xù)費(fèi)占多少。2.4 第四層組織可行性——誰來做、怎么推組織可行性是最容易被低估的部分。很多方案技術(shù)上無懈可擊但忽略了“誰來運(yùn)維”這個(gè)致命問題。我一般會(huì)從三個(gè)角度論證團(tuán)隊(duì)能力、組織架構(gòu)、推進(jìn)節(jié)奏。團(tuán)隊(duì)能力方面要盤點(diǎn)現(xiàn)有團(tuán)隊(duì)的技術(shù)棧。如果現(xiàn)有團(tuán)隊(duì)只會(huì)寫SQL那方案里就不應(yīng)該出現(xiàn)需要寫Scala的要求。如果確實(shí)需要新技術(shù)要給出學(xué)習(xí)曲線和培訓(xùn)計(jì)劃。常見做法是“核心平臺(tái)由2名有大數(shù)據(jù)經(jīng)驗(yàn)的工程師負(fù)責(zé)業(yè)務(wù)開發(fā)由現(xiàn)有ETL團(tuán)隊(duì)轉(zhuǎn)型安排為期6周的專項(xiàng)培訓(xùn)”。組織架構(gòu)方面要明確平臺(tái)建成后的歸屬。是放在IT部門下面還是獨(dú)立的數(shù)據(jù)中心和業(yè)務(wù)部門的關(guān)系是服務(wù)型還是管控型這些問題不解決平臺(tái)建成后就會(huì)陷入“誰都在用、誰都不負(fù)責(zé)”的困境。推進(jìn)節(jié)奏方面要分階段設(shè)定里程碑。我一般建議分三期第一期做數(shù)據(jù)接入和基礎(chǔ)存儲(chǔ)周期3個(gè)月第二期做計(jì)算引擎和開發(fā)平臺(tái)周期4個(gè)月第三期做數(shù)據(jù)服務(wù)和門戶周期3個(gè)月。每期結(jié)束要有明確的交付物和驗(yàn)收標(biāo)準(zhǔn)。3. 從PPT到落地可行性研究方案里的技術(shù)選型怎么寫才經(jīng)得起追問3.1 數(shù)據(jù)接入層的選型邏輯與參數(shù)配置數(shù)據(jù)接入是平臺(tái)的第一道關(guān)口選型時(shí)主要考慮三個(gè)因素?cái)?shù)據(jù)源類型、實(shí)時(shí)性要求、數(shù)據(jù)量級。對于關(guān)系型數(shù)據(jù)庫如果要求秒級延遲CDC方式是首選如果只要求天級同步批量抽取就夠了。對于日志類數(shù)據(jù)Filebeat加Kafka的組合比較常見對于API類數(shù)據(jù)定時(shí)任務(wù)加斷點(diǎn)續(xù)傳是標(biāo)配。以CDC接入MySQL為例常見做法是用Debezium加Kafka Connect。配置時(shí)需要注意幾個(gè)關(guān)鍵參數(shù)snapshot.mode決定初始快照方式一般選initialpoll.interval.ms控制輪詢頻率默認(rèn)500毫秒數(shù)據(jù)量大時(shí)可以調(diào)到1000max.batch.size控制單批處理量默認(rèn)2048內(nèi)存充足時(shí)可以調(diào)到4096。{ name: mysql-cdc-connector, config: { connector.class: io.debezium.connector.mysql.MySqlConnector, database.hostname: mysql-host, database.port: 3306, database.user: cdc_user, database.password: ******, database.server.id: 184054, database.server.name: business_db, table.include.list: order_db.order_info,crm_db.customer, database.history.kafka.bootstrap.servers: kafka:9092, database.history.kafka.topic: schema-changes.business, snapshot.mode: initial, poll.interval.ms: 1000, max.batch.size: 4096, decimal.handling.mode: double } }這段配置里table.include.list指定要同步的表建議按業(yè)務(wù)域分批配置不要一次性全庫同步。decimal.handling.mode設(shè)為double是為了避免Decimal類型在后續(xù)計(jì)算中出現(xiàn)精度問題如果業(yè)務(wù)對精度要求極高可以改為string然后在計(jì)算層轉(zhuǎn)換。3.2 存儲(chǔ)計(jì)算層的選型對比與容量規(guī)劃存儲(chǔ)計(jì)算層的選型直接決定平臺(tái)的能力上限和成本下限。常見方案有三類MPP數(shù)據(jù)庫如Greenplum、ClickHouse、Hadoop生態(tài)HDFS加Spark、云原生方案對象存儲(chǔ)加Serverless計(jì)算。三類方案各有適用場景。方案類型適用數(shù)據(jù)量查詢延遲運(yùn)維復(fù)雜度成本特點(diǎn)MPP數(shù)據(jù)庫TB級秒級中等硬件成本高運(yùn)維成本低Hadoop生態(tài)PB級分鐘級高硬件成本低運(yùn)維成本高云原生方案彈性秒到分鐘低按量付費(fèi)長期成本高容量規(guī)劃是這一步的核心。我一般按“存量數(shù)據(jù)×副本數(shù)×1.3”估算存儲(chǔ)需求1.3是預(yù)留的索引和臨時(shí)空間。計(jì)算資源按“并發(fā)查詢數(shù)×單查詢內(nèi)存×1.5”估算1.5是預(yù)留的調(diào)度開銷。比如存量8TB、3副本、并發(fā)20、單查詢2GB內(nèi)存存儲(chǔ)需要31.2TB計(jì)算需要60GB內(nèi)存。注意容量規(guī)劃不要按當(dāng)前數(shù)據(jù)量算要按三年后的數(shù)據(jù)量算。我見過太多平臺(tái)上線半年就撐不住了就是因?yàn)橐?guī)劃時(shí)只看了眼前。3.3 數(shù)據(jù)服務(wù)層的接口設(shè)計(jì)與權(quán)限模型數(shù)據(jù)服務(wù)層是平臺(tái)和業(yè)務(wù)之間的橋梁設(shè)計(jì)好壞直接影響用戶體驗(yàn)。接口設(shè)計(jì)要遵循三個(gè)原則統(tǒng)一入口、版本管理、限流保護(hù)。統(tǒng)一入口是指所有數(shù)據(jù)服務(wù)通過同一個(gè)網(wǎng)關(guān)暴露方便監(jiān)控和鑒權(quán)版本管理是指接口要帶版本號避免升級時(shí)影響已有調(diào)用方限流保護(hù)是指每個(gè)調(diào)用方要有QPS上限防止個(gè)別業(yè)務(wù)拖垮整個(gè)平臺(tái)。權(quán)限模型常見的有三種RBAC基于角色的訪問控制、ABAC基于屬性的訪問控制、PBAC基于策略的訪問控制。大多數(shù)場景用RBAC就夠了角色按“數(shù)據(jù)域操作類型”劃分比如“訂單域只讀角色”、“客戶域讀寫角色”。如果涉及敏感數(shù)據(jù)需要在RBAC基礎(chǔ)上加列級權(quán)限和行級權(quán)限。-- RBAC權(quán)限模型的核心表結(jié)構(gòu) -- 用戶表 CREATE TABLE sys_user ( user_id BIGINT PRIMARY KEY, username VARCHAR(64) NOT NULL, dept_id BIGINT, status TINYINT DEFAULT 1 ); -- 角色表 CREATE TABLE sys_role ( role_id BIGINT PRIMARY KEY, role_name VARCHAR(64) NOT NULL, data_domain VARCHAR(32), operation_type VARCHAR(16) ); -- 用戶角色關(guān)聯(lián)表 CREATE TABLE sys_user_role ( id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, grant_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 數(shù)據(jù)資源表 CREATE TABLE data_resource ( resource_id BIGINT PRIMARY KEY, resource_name VARCHAR(128), domain VARCHAR(32), sensitivity_level TINYINT ); -- 角色資源關(guān)聯(lián)表 CREATE TABLE sys_role_resource ( id BIGINT PRIMARY KEY, role_id BIGINT NOT NULL, resource_id BIGINT NOT NULL, permission VARCHAR(16) -- read/write/admin );這套表結(jié)構(gòu)的關(guān)鍵在于data_domain和sensitivity_level兩個(gè)字段。data_domain把數(shù)據(jù)按業(yè)務(wù)域隔離sensitivity_level標(biāo)記敏感級別。查詢時(shí)先通過用戶角色找到可訪問的資源再根據(jù)敏感級別決定是否脫敏。4. 可行性研究方案避坑指南五個(gè)讓評審翻車的常見問題4.1 數(shù)據(jù)量估算拍腦袋評審一問就露餡現(xiàn)象方案里寫“當(dāng)前數(shù)據(jù)量約10TB”評審問“怎么算出來的”答“大概估的”。原因是沒有做實(shí)際盤點(diǎn)或者只盤點(diǎn)了數(shù)據(jù)庫存量漏掉了日志、文件、備份等數(shù)據(jù)。解決方法是按數(shù)據(jù)源逐項(xiàng)盤點(diǎn)每項(xiàng)給出計(jì)算依據(jù)。比如“訂單庫當(dāng)前1.2TB日增5GB按3年保留期計(jì)算增量約5.4TB合計(jì)6.6TB”。所有數(shù)字都要能追溯到源頭。4.2 技術(shù)選型只寫“采用XX技術(shù)”不寫為什么現(xiàn)象方案里列了一堆技術(shù)名詞但沒說為什么選這個(gè)不選那個(gè)。評審問“為什么用Kafka不用RabbitMQ”答不上來。原因是沒有做選型對比。解決方法是在方案里加一張選型對比表列出候選方案、優(yōu)缺點(diǎn)、適用場景、最終選擇理由。哪怕理由只是“團(tuán)隊(duì)更熟悉”也比不寫強(qiáng)。4.3 收益預(yù)估全是定性描述沒有量化指標(biāo)現(xiàn)象方案里寫“提升數(shù)據(jù)利用效率”、“支撐業(yè)務(wù)創(chuàng)新”但沒有具體數(shù)字。評審問“能省多少人”答“大概能省幾個(gè)”。原因是沒和業(yè)務(wù)部門對齊預(yù)期。解決方法是提前找業(yè)務(wù)方確認(rèn)可量化的收益點(diǎn)比如“月度報(bào)表制作時(shí)間從3天縮短到半天”、“數(shù)據(jù)查詢響應(yīng)從分鐘級降到秒級”。每個(gè)收益點(diǎn)要有基線值和目標(biāo)值。4.4 忽略運(yùn)維成本三年TCO算下來嚇?biāo)廊爽F(xiàn)象方案里只算了建設(shè)成本沒算運(yùn)營成本。評審問“每年運(yùn)維要花多少”答“沒細(xì)算”。原因是只關(guān)注了一次性投入。解決方法是按建設(shè)成本的30%到50%估算年運(yùn)營成本并拆解到電力、機(jī)柜、帶寬、人力、軟件續(xù)費(fèi)各項(xiàng)。如果運(yùn)營成本過高要考慮調(diào)整方案比如用云服務(wù)替代自建。4.5 推進(jìn)計(jì)劃沒有里程碑評審不知道什么時(shí)候能見到東西現(xiàn)象方案里寫“項(xiàng)目周期12個(gè)月”但沒有分階段交付物。評審問“3個(gè)月后能看到什么”答“還在開發(fā)”。原因是沒有做階段劃分。解決方法是分三期每期3到4個(gè)月每期有明確的交付物和驗(yàn)收標(biāo)準(zhǔn)。第一期交付數(shù)據(jù)接入和基礎(chǔ)存儲(chǔ)第二期交付計(jì)算引擎和開發(fā)平臺(tái)第三期交付數(shù)據(jù)服務(wù)和門戶。每期結(jié)束要有可演示的成果。5. 讓可行性研究方案通過評審的三個(gè)進(jìn)階技巧5.1 用原型驗(yàn)證代替紙上談兵如果條件允許在寫方案之前先做一個(gè)最小原型。不需要全量數(shù)據(jù)抽1%的數(shù)據(jù)跑通接入、存儲(chǔ)、查詢?nèi)鞒叹托?。原型的作用是?yàn)證技術(shù)選型是否可行同時(shí)給評審提供直觀的演示。我一般會(huì)花兩周時(shí)間搭一個(gè)Demo環(huán)境用真實(shí)數(shù)據(jù)跑幾個(gè)典型查詢把響應(yīng)時(shí)間和資源消耗記錄下來。這些數(shù)據(jù)寫進(jìn)方案里比任何形容詞都有說服力。原型驗(yàn)證的重點(diǎn)是三個(gè)指標(biāo)接入速度、查詢延遲、資源占用。接入速度按“每秒處理記錄數(shù)”衡量查詢延遲按“P95響應(yīng)時(shí)間”衡量資源占用按“CPU和內(nèi)存使用率”衡量。如果原型階段就發(fā)現(xiàn)某個(gè)技術(shù)選型達(dá)不到預(yù)期及時(shí)調(diào)整比上線后返工成本低得多。5.2 把評審專家當(dāng)成用戶來設(shè)計(jì)匯報(bào)邏輯可行性研究方案的匯報(bào)對象通常是技術(shù)評審專家和業(yè)務(wù)決策者。技術(shù)專家關(guān)心架構(gòu)合理性和技術(shù)風(fēng)險(xiǎn)業(yè)務(wù)決策者關(guān)心投入產(chǎn)出比和業(yè)務(wù)價(jià)值。匯報(bào)時(shí)要針對不同角色調(diào)整側(cè)重點(diǎn)。對技術(shù)專家講架構(gòu)設(shè)計(jì)、選型對比、風(fēng)險(xiǎn)應(yīng)對對業(yè)務(wù)決策者講成本收益、業(yè)務(wù)場景、推進(jìn)節(jié)奏。我一般會(huì)準(zhǔn)備兩個(gè)版本的匯報(bào)材料一個(gè)詳細(xì)版給技術(shù)評審包含架構(gòu)圖、選型對比表、參數(shù)配置一個(gè)精簡版給決策層包含成本收益表、里程碑計(jì)劃、風(fēng)險(xiǎn)清單。兩個(gè)版本的核心數(shù)據(jù)要一致但呈現(xiàn)方式不同。5.3 風(fēng)險(xiǎn)應(yīng)對要具體到“如果發(fā)生我們怎么辦”可行性研究方案里必須有一章講風(fēng)險(xiǎn)。但很多方案只列風(fēng)險(xiǎn)不寫應(yīng)對比如“技術(shù)風(fēng)險(xiǎn)選型不當(dāng)”。這種寫法等于沒寫。正確的做法是每條風(fēng)險(xiǎn)都要有應(yīng)對措施。比如“技術(shù)風(fēng)險(xiǎn)CDC接入在高峰期延遲超過10秒。應(yīng)對措施配置Kafka分區(qū)擴(kuò)容預(yù)案當(dāng)延遲超過閾值時(shí)自動(dòng)增加消費(fèi)者實(shí)例。責(zé)任人平臺(tái)組。觸發(fā)條件延遲持續(xù)5分鐘超過10秒。”風(fēng)險(xiǎn)清單一般包括技術(shù)風(fēng)險(xiǎn)、數(shù)據(jù)風(fēng)險(xiǎn)、組織風(fēng)險(xiǎn)、進(jìn)度風(fēng)險(xiǎn)四類。每類列2到3條具體風(fēng)險(xiǎn)每條按“風(fēng)險(xiǎn)描述、影響程度、發(fā)生概率、應(yīng)對措施、責(zé)任人”五個(gè)字段填寫。影響程度和發(fā)生概率用高、中、低三檔標(biāo)注應(yīng)對措施要具體可執(zhí)行。提示風(fēng)險(xiǎn)應(yīng)對措施不要寫“加強(qiáng)管理”、“提高意識(shí)”這種空話。要寫具體動(dòng)作比如“每周做一次數(shù)據(jù)質(zhì)量抽檢”、“預(yù)留10%的預(yù)算作為應(yīng)急資金”。5.4 一個(gè)讓我少熬三個(gè)通宵的習(xí)慣我現(xiàn)在寫任何可行性研究方案都會(huì)在動(dòng)筆之前先做一件事找三個(gè)不同角色的人聊半小時(shí)。找一個(gè)業(yè)務(wù)方聊痛點(diǎn)找一個(gè)運(yùn)維聊現(xiàn)狀找一個(gè)財(cái)務(wù)聊預(yù)算口徑。這三場對話下來方案的骨架就清楚了而且每個(gè)數(shù)字都有出處。最怕的是閉門造車寫了80頁評審時(shí)被問“這個(gè)數(shù)據(jù)問過業(yè)務(wù)嗎”然后全場沉默。提前聊過心里有底匯報(bào)時(shí)被追問也能接得住。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取