第4章 信息系统规划

1、以组织战略为起点做规划，坚持战略性、整体性、先进性、指导性、柔性、遵从性六项原则，做到“横向到边、纵向到底”，兼顾当前与长远。

2、需求挖掘分内外两条线：内部聚焦业务发展与各级管理者意向；外部导入国家战略、行业趋势、技术趋势、竞争环境、客户期望与标准规范。坚持“以原始信息获取为主、不急于给方案、谨慎交叉传递信息”。

3、引入成熟度模型（一至五级）把定性对标转成定量评价，让规划有统一标尺。

4、规划成果按“需求整合与确认→整体规划→专项规划→一致性检查”四步输出：整体规划定框架方向，专项规划定技术路线与实施路径。

5、用任务体系部署六步法（任务拆解、明确目标、匹配组织、制定策略、定义计划、监控实施）把规划变成可执行任务。

6、同步建设保障体系（组织、人员、技术、资源、数据、安全），支撑难以量化的目标。

7、方法上组合使用 SST、BSP、CSF、VCA、Zachman 等，避免单一方法的局限。

1、只做技术规划、不做战略对齐，出现“规划与战略两张皮”。

2、需求挖掘阶段过早陷入技术路线、产品功能纠缠，导致需求失真、口径不一。

3、缺少一致性检查，规划成果与需求、干系人理解之间存在偏差，评审时争议大。

4、保障体系（尤其人员、数据、安全）缺位，规划好看但落不了地。

5、外部需求引用不注出处、定性内容未做定量化转换，规划缺乏说服力。

6、分系统划分沿用“按部门切块”，未遵循技术一致性、工程一致性、职能一致性与数据一致性原则，导致系统边界不清、集成融合困难。

7、只做整体规划或只做专项规划，缺少“整体＋专项”配套与分期实施路径，规划难以直接指导具体建设。

第5章 应用系统规划

1、先分级分类再定架构，然后依次完成生命周期选择、体系结构定义、接口定义、数据定义、构件定义，形成完整的规划设计闭环。

2、架构按业务特征选型：数据处理统计类用“以数据为中心”；交互与业务规则易变用三层C/S或B/S；跨组织分布用组件分布架构。

3、详细调研坚持“六件事同时完成”：收集信息、系统需求建模、需求优先级划分、构建原型检验可行性、产生并评估候选方案、与管理层共同复查。

4、可行性从经济、技术、社会、管理四方面论证；技术可行性坚持“尽可能采用成熟技术、慎重引入先进技术、着眼具体开发环境与人员”。

5、用原型法、JAD会议、观摩法引导需求，缩短需求分析周期、减少理解偏差。

6、系统说明书做到正确、完整、一致、无二义、可修改、可跟踪。

7、借鉴软件工厂模式（专业人员、基础设施和硬件、工具和技术、流程规范和方法论、质量管理）提升交付质量。

1、只记录用户“说要什么”，未做需求优先级划分与原型验证，导致后期频繁返工。

2、过度追求先进技术，脱离实际开发环境与人员能力，项目风险陡增。

3、系统说明书要素不全（尤其无二义性与可跟踪性），设计与实现出现偏差且难追溯。

4、接口与数据定义滞后，集成阶段问题集中爆发。

5、系统设计只考虑功能，忽视可靠性、可变更性、经济性与“管理可接受”。

6、可行性研究只算直接经济效益，忽视系统带来的间接社会效益，论证结论片面。

7、只做功能设计、不做架构分层与构件定义，模块耦合度高、复用性差，后期变更牵一发动全身。

第6章 云资源规划

1、按“需求收集→资源评估和规划→预算管理→设计与实施→持续优化”五阶段推进，形成闭环。

2、用容量规划与趋势预测确定资源规模，配合负载均衡与弹性伸缩应对业务波峰。

3、业务分类部署：稳态业务放私有云（高可靠、低时延、裸机／数据库／核心业务），敏态业务放公有云；混合云做到服务门户统一、资源监控界面统一、账户权限统一。

4、服务模式按用户角色选型：IaaS面向系统管理员、PaaS面向开发人员、SaaS面向普通用户、FaaS面向函数化微服务与事件驱动场景。

5、存储按访问模式选型（块存储／文件存储／对象存储），设计备份冗余与灾难恢复，配套容量规划与性能优化。

6、云数据中心遵循可用性、冗余性、弹性、可扩展、性能优化、安全隐私、灵活性、可管理性、节能环保原则，落地“面向服务、资源池化、高效智能、按需供给、低碳环保”五要素。

7、成本上做预算管理＋费用监控＋成本效益分析，避免资源闲置。

1、未做容量规划与增长预测，资源要么不足影响业务，要么长期闲置浪费预算。

2、忽视多租户隔离与数据安全，存在数据泄露与越权访问风险。

3、混合云只做“公私叠加”，未统一门户、监控与权限，运维复杂度反而上升。

4、只算采购成本、不算运营与迁移成本，预算中期失控。

5、网络规划未考虑多路径容错与扁平化，成为数据中心的性能瓶颈。

6、云服务模式选型“一刀切”（一律IaaS或一律SaaS），未按用户角色与业务场景匹配，资源利用率与成本双输。

7、只重视迁移上线，缺少“持续优化”环节，资源使用与业务目标逐步脱节，性能与成本问题长期积压。

第7章 网络环境规划

1、按“建设背景→需求分析→项目预算→技术方向→网络拓扑结构设计→IP等逻辑资源规划”推进；预算涵盖设备、线路、配套、建设、运维、优化成本。

2、城域网采用核心层／汇聚层／接入层三层架构，接入层面向园区、楼宇、小区提供有线和无线接入。

3、拓扑按需选择（总线、星形／双星形、树状、环形、网状、复合型、层级型），关键节点采用双星形或网状结构提升可靠性。

4、VLAN划分综合业务特性、地理连接、安全要求确定（按端口／MAC／网络层协议／IP组播／策略／用户定义），VLAN ID（1~4096）谨慎规划，并同步设计VLAN间路由、STP防环、DHCP部署。

5、无线网做好频率、覆盖范围、传输容量、基站站址、组网五项规划，基站选点综合考虑电力、网络、干扰、安全与施工维护。

6、建立网络管理五大功能：故障管理、配置管理、性能管理、计费管理、安全管理。

1、拓扑设计无冗余，中心节点成为单点故障，一旦故障全网瘫痪。

2、VLAN ID分配随意，后期扩展与故障排查困难。

3、STP与DHCP设计缺失，出现环路广播风暴、地址冲突。

4、重有线轻无线，无线覆盖与容量规划不足，实际使用体验差。

5、缺少统一网管与监控，故障定位靠人海战术，恢复时间长。

6、IP等逻辑资源规划不完整，未同步做地址规划与IPv6演进考虑，扩容时出现地址冲突、改造困难。

7、只做物理网络设计，缺少逻辑网络与安全设计，业务隔离与访问控制靠事后打补丁。

第8章 数据资源规划

1、按业务场景稳定程度选择方法：业务相对固定、积累少用基于稳定信息过程；业务常变、积累多用基于稳定信息结构；涉及决策用基于指标能力。

2、按“职能域”而不是现行机构部门划分规划范围，由业务人员与系统分析员组成小组，形成“两条主线、三种模型、一套标准”。

3、建立数据资源管理基础标准：数据标准体系、元数据标准化、数据元标准化、数据分类与编码标准化。

4、数据按量与管理需求选择架构：小数据量用集中式，大数据量、高并发用分布式（分区／分片＋一致性机制）。

5、数据质量遵循“预防为主、根因修正、嵌入业务流程、系统强制执行、与服务水平关联”，围绕定义高质量数据、识别关键数据与业务规则、初始评估、排序改进、部署质量操作展开。

6、数据安全按“识别需求→制定制度→定义细则→评估风险→实施控制”五步落实，运营上执行因需可知与最小特权。

7、用数据湖（存储层、数据管理、数据治理、查询分析、可视化、流处理、机器学习工具）承载多源异构数据。

1、按现行部门划分数据，造成数据孤岛，跨部门共享交换困难。

2、无统一数据标准，同一信息存在多种分类与编码，集成成本高。

3、数据质量只做纠正不做预防，问题反复出现；未从流程与系统设计找根因。

4、数据安全活动缺失，敏感数据无分级、无授权管理。

5、只建平台不建治理，数据“进得来、用不上”。

6、数据架构选型脱离数据量与管理需求（小数据量上分布式、大数据量却用集中式），架构与业务发展不匹配。

7、元数据与数据元定义不规范（不唯一、含糊、不能单独成立），口径歧义导致集成共享困难。

第9章 信息安全规划

1、以保密性、完整性、可用性、可控性、不可否认性五大属性为目标，坚持系统性、适用性、时效性、确定性、可行性、易用性、合规性七项原则。

2、规划按时间跨度分层：短期规划（应急方案）、中长期规划（1~3年体系化）、远景规划（3年以上战略构想）。

3、引入SABSA框架，从业务、架构、设计、构建、实施、服务管理六个视图建立完整安全架构，并按“战略与规划→设计→实施→管理与衡量”生命周期运行。

4、用信息系统安全保障模型三维度（保障要素、生命周期、能力成熟度）评价保障能力，按等保五级确定防护要求。

5、技术上组合使用身份认证（双因素、USBKey、生物识别）、访问控制（DAC／Role-BAC／Rule-BAC／MAC）、入侵检测、防火墙、网闸、防病毒、数据加密。

6、运营上落实最小特权、因需可知、职责分离、双人控制、岗位轮换、强制休假、特权账户管理，防范内部威胁。

7、合规性覆盖国家法律法规、国家标准、行业监管、内部管控。

1、只堆技术产品不建管理体系，安全建设与业务脱节，投入大效果差。

2、规划缺时效性与可行性，无法落地为具体措施。

3、忽视内部威胁（授权侵犯、人员渎职），无职责分离与岗位轮换机制。

4、未做定期风险评估与合规检查，事件发生后才被动补救。

5、安全运营缺少量化指标，无法证明安全投入的价值。

6、安全规划“一刀切”，未按短期／中长期／远景分层，紧急风险处置与长期体系建设混淆，资源投入失焦。

7、未做等级保护定级与备案，防护强度与定级不匹配，或过度防护浪费投入、或防护不足留有隐患。

第10章 云原生系统规划

1、明确云原生代码三部分（业务代码、三方软件、非功能特性代码），把重心放在业务代码，非功能能力下沉到平台。

2、遵循服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进七项原则。

3、按业务场景选架构模式：服务化、Mesh化、Serverless、存储计算分离、分布式事务、可观测架构、事件驱动架构。

4、实施按五步路线图推进：微服务采用＋容器云平台构建→服务管理和治理→持续交付及安全→自服务敏捷响应基础设施→增强生产环境韧性和安全性。

5、用Mesh化把熔断、限流、降级、重试、隔仓等分布式能力下沉，业务代码零侵入；以零信任重构访问控制。

6、可观测性以SLO度量为核心（并发度、耗时、可用时长、容量），通过日志、链路跟踪、度量支撑SLA优化。

7、用IaC、GitOps、Kubernetes Operator实现交付与运维全流程自动化。

1、一上来就大规模微服务化，服务数量爆炸但治理能力跟不上。

2、只关注功能上线，不建可观测性，故障定位靠猜、恢复时间长。

3、忽略分布式事务，跨服务数据不一致，返工成本高。

4、架构封闭、不具备持续演进能力，技术栈升级困难。

5、未做韧性建设与故障注入演练，生产环境一出问题就雪崩。

6、跳过“服务管理和治理”直接做持续交付，服务规模增长后服务编排、API定义与协同失控。

7、未落实“所有过程自动化”（IaC／GitOps／K8s Operator），交付仍靠人工，环境差异导致上线事故频发。