it系统架构师培训计划.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 如何使用物理架构 系统部署需要什么 具体系统细节的配置 具体系统操作规程 系统管理流程及规则 有技能的人员 系统移植方案, 特别是数据移植方案以及人员培训 小结 系统运营层面系统架构 描述部署单元的布置方法, 从而满足系统非功能性需求 列举和考虑系统管理方面的方案因素 侧重于系统运营环境的考虑 * * * * * * * * * * * * * * * * Uml: 统一建模语言 * * * * * * * * * * * * * IT技术遵循标准与目前IT系统环境 IT技术遵循的标准文档具体列举了所有项目必须遵循的标准和使用的技术, 甚至具体的产品. 这些标准可能是来自之前的工作, 企业内部的IT规范. IT标准总是存在的, 无论是公开的还是不言而喻的. 这些事实的记录会帮助IT架构师规划系统方案架构. 这个文档也记录了在方案规划或者执行过程中要绕过这些IT标准的理由和原因 另外, 任何系统模块还没有标准遵循时, 这种信息也要记录下来.这是为了将来这些实施的标准可以变成企业IT标准 目前系统环境文档是个系统清单, 包括硬件, 软件和其它IT功能环境,如防火墙, 网络地址分配,等等 可行的 vs. 不可行的 人-机分工平衡以取综合最优 非功能需求 非功能需求用来: 针对要建设的IT系统, 定义关键系统特征和限制要求. 用来估算系统容量和成本 评估系统的可行性和生存能力 用于系统部署模型的重要依据 非功能需求经常是系统架构的重要因素之前描述的非功能性需求是用这个工作文件记录下来的 可行性分析 可行性分析报告是探讨, 解释和描述建议的方案是否可行。 编写可行性报告的过程就是思考和组织建议方案的不同部分。 可行性分析经常是针对某部分系统需求, 功能或某种技术的使用。 可行性分析也是用来找出潜在可能存在的问题和风险. 这对与客户沟通以及架构师设计时都是一个重要方面。 可行性报告应该是不断更新和审核的. 同时它是作为质量保证审核以及实施计划的重要依据。 可行性分析举例 使用不同的颜色(红/黄/绿)来标示不同程度的问题 不要把风险, 问题, 假设和依赖因素混为一谈 提早从客户获取信息进行风险分析 例如, 如果客户不提供所需要的资料或信息, 这个问题带来的风险是高的. 可以有依据向客户尽早获取资料 系统运行模型 提供宏观的系统逻辑运行架构, 用来理解整体系统是如何满足业务需求的用来考虑系统主要基础架构是如何部署的以及系统组件应该如何部署 用来确认客户对系统实施的倾向和限制因素 用来执行早期的系统基本功能的流程执行验证(walk-through) 基于以上几个方面, 用来考虑系统的非功能性需求应该如何满足 用来选择实施系统组件功能的产品或应用, 衡量它们的可用性 用来估算相关系统硬件和基础建设的成本 作为选择软件和硬件产品的选择基础 系统运行模型图举例 用来估算硬件的成本及软件license的数量 系统运行模型图举例 系统LPAR的节点配置方案 系统运行模型图举例 系统节点描述 Q A IT Infrastructure 架构设计 逻辑层面的运营架构模型 规范层面的运营架构模型 物理层面的运营架构模型 总结 运营架构模型—八步规划法 八步法是按顺序来讲的. 但在实际制作过程中, 有些步骤是同步进行的或重复使用的. 是否是这种情况决定于限定因素或条件, 以及是否使用参考架构 在做每一步时, 关键的非功能性需求对架构模型的影响一定要不断核实 系统可用性, 性能, 系统管理, 安全 这个做法也包括如何制作以下工作文档: 部署单元 更新的架构决定 可行性报告 第一步:找出业务功能的位置和区域 信息来自于： 业务角色和位置 系统关系图 目前IT环境 第二步: 找出逻辑节点 逻辑节点举例 第三步: 为了满足系统管理需求的特殊逻辑节点 第四,五,六步: 找出展示, 执行和数据部署节点 第七步: 找出需要的连接节点 第八步: 回顾目前所达到的结果 建议以场景进行验证 IT Opertion 架构设计 逻辑层面的运营架构模型 规范层面的运营架构模型 物理层面的运营架构模型 总结 规范架构是把逻辑架构改变成一个技术规范架构 技术规范架构过程 在限制因素范围内和满足非功能需求的前提下, 找出必要的技术需求和功能服务用来提供业务功能 考虑一些不同的选择或方法满足同样的需求, 进行选择平衡, 对目前的架构做适当的修改 设计逻辑技术连接 评估目前架构的可行性, 对相关的架构文档进行更新 输入--组件模型, 非功能需求, 用户需求和逻辑模型 寻找技术规范节点 系统管理考虑 不同节点是如何运作的 监控(系统状况监控