《IT架构师成长和认证指南》简介及第3章 IT架构思维（三）

企业架构师思维

发布于 2025-05-30 14:03:29

2510

作者写了一本关于IT架构师成长和认证的书，希望先通过连载的形式拿出来分享，结合读者的反馈来不断调整完善。本书希望对于那些想成长为架构师，并在架构师职业发展道路上不断进阶的读者们有所借鉴和指导，也欢迎业内专家不吝赐教和斧正。

目前作者在参与信通院企业架构推进中心企业架构相关成熟度模型标准的制定工作中发现，我们目前不少的企业对于企业架构、解决方案架构（或者系统架构）的概念和范围理解上还存在混淆、偏差和不一致的地方，作者也是希望通过个人和相关业内专家的共同努力，推动企业架构和解决方案架构更加系统性、结构化、标准化，并且开放化地发展。

作者一直以为企业架构理论和实践的发展离不开企业（2B）和个人（2C），企业的架构最终还是需要由具备企业架构思维的人才进行架构运用和实践，所以企业乃至整个社会，对于架构师人才梯队的培养也是非常重要的一环。本人是IBM L3 Thought Leader 级别认证架构师，The Open Group的L3认证杰出架构师，也是TOGAF企业架构，OAA开放敏捷企业架构，以及银行业架构网络BIAN认证架构师。曾任The Open Group 架构标准组合本地化联席主席，负责领导了OAA开放敏捷企业架构标准的本地化、推动TOGAF10标准的本地化、翻译和推动BIAN相关标准的本地化工作；也作为全球企业架构师联合会（AEA）架构师执业证规范特邀专家进行了L1~L3企业架构师及各领域架构师的遵从性标准的制定工作。作者本人也是期望结合自身的架构师成长实践，为企业架构和架构师社区尽自己的一点绵薄之力。

《IT架构师成长和认证指南》全书分成两大部分共十二个章节。

第一部分讲了IT架构是什么，以及如何去做IT架构，包括IT架构思维及不同视角、方面的架构模型和方法。

架构视角包括功能视角的组件模型、数据视角的数据模型、运营使用视角的运用模型；架构方面包括关键的非功能性方面工程学，如性能工程、可用性工程和安全架构。

在架构知识体系化的介绍过程中贯穿以实际的案例，并提供了任务级别的架构模型开发方法和相关的架构制品，确保架构方法的可落地性和实践指导性。

另外还介绍了历来不同的架构风格，流行的架构建模语言和工具，方便读者对当今各种架构的来龙去脉有全面深入的理解，并能够熟练运用各种架构语言进行架构制品的产出，方便在架构社区的交流。

第二部分讲了考察一个架构师的角色和素养有哪些，基于此构建出架构师能力六边形模型，并介绍了IT架构师可获得相关认证的一些行动指南。

《IT架构师成长和认证指南》简介和第一章什么是IT架构

《IT架构师成长和认证指南》简介及第2章 IT架构师角色和素养

《IT架构师成长和认证指南》简介及第3章 IT架构思维（一）

《IT架构师成长和认证指南》简介及第3章 IT架构思维（二）

接上一篇第3章 IT架构思维（二）

本书第一章介绍了IT架构思维需要从三个不同的维度进行思考，满足不同利益相关方的关切，进行架构建模，以支撑起“屋顶”上的功能性需求和非功能性需求。进一步地，我们将架构活动分解成了需求规格化、架构设计、架构验证和架构管理四大部分。本章介绍了需求规格化相关的架构活动，前两篇是关于功能性需求的规格化，本篇将介绍对非功能性需求的相关评价要求。

3.5.3 非功能性需求清单

非功能性需求（Non-Functional Requirements，NFR）是跟业务无关的需求，其直接关系到系统可支持的用户数、并发吞吐量、响应时间及用户使用体验，关系到系统的稳定性、容错性和安全性，是系统提供服务做到多好的需求陈述，代表了一组用于判断系统服务质量状态的标准。非功能性需求通常从系统实际业务需要和重要性出发、结合监管合规要求，也可以参考同业的情况进行提出和定义。越高质量要求的非功能性需求其实现的成本会呈现指数级别上升，我们需要在实现成本和业务容忍度间找到一定的平衡。

非功能性需求一般分为运行时质量（Run-time Qualities）评价标准和非运行时质量（Non-Runtime Qualities）评价标准。运行时质量评价标准体现了系统在运行时表现出来的特质，指标可以通过对系统进行测试和监控得到，往往会作为系统的服务等级需求进行描述，其中包括：

容量（Capacity）：系统能存储和处理多少数据，能服务多少用户。容量相关的NFR需求举例：支持2000个用户同时登录，系统要保留5年的历史数据。

性能（Performance）：在一定并发请求下系统的响应时间，交易吞吐量，所支持运行的并发用户数。性能相关的NFR需求举例：峰值吞吐量为1000TPS（Transactions Per Second)，响应时间90%不低于500ms，并发用户请求数不少于200个。

可用性（Availability）：业务能够容忍的最长非计划的中断时间。可用性相关的NFR需求举例：系统的可用性要达到99.9%（每年9小时的非计划宕机时间）。

安全性（Security）：系统能够保护信息的机密性、完整性、合规性和可用性，能识别和防止未授权系统访问等，避免受到各种安全风险的影响。安全性相关的NFR需求举例：数据落地加密，传输加密，多因素认证。

易用性（Usability）：系统是否容易使用，是否可方便视障听障、老年人士等特殊人群的使用。易用性相关的NFR需求举例：提供长者关爱操作模式，操作导引。

扩展性（Scalability）：在不降低性能的情况下，系统是否支持通过资源的扩展以支持增加的业务负载。扩展性相关的NFR需求举例：支持基于资源使用率的资源自动横向扩展，当CPU使用率达到90%时，自动扩展新的服务实例。

系统管理（System Management）：是否提供一组服务便于运维人员进行系统管理和运维。系统管理相关的NFR需求举例：需要为系统管理员提供系统管理界面，提供系统运行手册，故障、异常处理操作手册等。

非运行时质量一般很难通过测试得到，需要更长的时间进行评价，非运行时质量评价标准包括：

可维护性（Maintainability）：系统支持bug修复、增加功能、提升性能等变更的难易程度。

可管理性（Manageability）：系统可被测试、部署、监控、启停的难易程度。这区别于作为运行时质量指标的系统管理。

合规性（Compliance）：系统能够满足各种监管法规的要求，如信息安全法，个人隐私保护法，企业制定的各种标准规范。

可靠性（Reliability）：系统组件在一定时间内或者提供一定的服务次数后失效的概率。

环境影响（Environment Impact）：系统是否会对用户产生伤害，包括物理伤害、精神伤害、财务损失等，是否会对环境产生影响，如碳排放，噪音等。

可移植性（Portability）：系统能否方便地移植到其他操作系统、应用容器环境或硬件上。

互操作性（Interoperability）：系统是否方便同其他系统进行数据的交换，信息的集成。

我们以几个重要的经常使用的运行时非功能指标为例，进一步说明其含义。

3.5.3.1 系统可用性

系统能够执行其必须功能的状态称为系统可用，系统可用性是衡量系统使用就绪的指标。系统可用性是从用户的视角来看待系统，通常表示为在约定的服务时间内，客户实际可以正常使用服务的时间比例。系统可用是系统对终端提供功能服务的最基本要求。

系统不可用时可能存在两种情形：

1. 计划停机时间，系统在计划停机时间进行计划任务，如维护升级，备份，演练或业务原因。

2. 非计划停机时间，系统出现某些故障导致系统不可用。

针对两种情形，存在三种组合的可用性概念，分别是高可用（High Availability， HA），持续运营（Continuous Operations， CO）和持续可用（Continuous Availability，CA）。

高可用（HA）代表不存在非计划的故障停机时间，系统允许计划内的停机。这是对用户的承诺，在非计划停机的时间内，需要确保用户作业不被中断。比如系统承诺在周一至周五上午 8：00 至下午 5：00 提供服务，在此期间不应发生计划外中断，任何中断肯定会影响用户，因为他们可能正在执行重要工作。高可用仍保留了安排系统停机时间的窗口，只要将系统停机时间安排在承诺的可用期之外即可。比如，日间确保系统可用性期间系统的可靠运行，而在夜间保留计划内停机时间进行数据备份和清理工作。

持续运营（CO）代表不存在计划停机，系统一直运营，除非出现非计划的故障停机。要达到持续运营的等级，系统需要具备高可用设计，提高系统整体可靠性，消除需要计划停机维护的工作。

持续可用（CA）代表系统不存在计划停机，也不会出现非计划的故障停机。这类的系统主要是民生相关的关键系统，如电力、通信、银行核心系统等，系统需要具备极高的可靠性和极高的可用性设计。

系统高可用性需求跟系统的角色相关，越是关键的核心系统，对其的高可用性设计要求越高。关键系统的意外停机，会导致业务损失，造成极大的社会影响，还要承受监管压力，停机时间越长，对企业的利益损害越严重。我们通常采用几个9来评价高可用性设计，其含义是在系统计划的工作的时间内非计划停机时间的占比。

可用性比率（Availability） = 实际正常可用时间/计划工作时间 * 100%

下表列出了一些几个9可用性指标，在一年内可允许非计划停机时间：

表 3-2不同可用性指标可允许的非正常停机时间

我们可以看到可用性比率提升一个9，可允许的非正常停机时间显著减少。

影响可用性的因素包括系统平均正常可用时间（Mean Time To Failure，MTTF）和系统平均恢复时间（Mean Time To Recover，MTTR）。

图3-8 影响可用性的因素MTTR和MTTF

可用性的计算公式可以转变为：

可用性比率（Availability）=

MTTF主要受到系统的可靠性和软件质量（如bug数）的影响，系统可靠性越高，越是采用高可用的架构，MTTF时间越长。对于解决方案架构师，除了关注系统的高可用架构，还需要考虑如何减少系统平均恢复时间。系统恢复时间MTTR取决于多个因素，比如故障是否存在预案，故障诊断的及时性，是否存在供操作员使用的故障恢复手册，系统是否可以自动检测故障并进行恢复等。通常系统恢复时间MTTR要执行包括故障检测、报告、诊断、隔离、备份、替换、恢复、测试、重新同步、重启等动作，如果是人工处理，需要有完备的预案和进行定期的演练，缺少预案或者缺乏定期演练，系统正常运行时间MTTF越长，其故障恢复MTTR要花的时间也会变长，一旦长时间运行的系统出故障，操作员可能对如何进行恢复和处理就会显得不熟练。

系统可用性的非功能性需求可以从两个方面进行梳理，一是针对系统的不同用户，需要整理出不同时间段的可用时间和中断时间，或者计算出不同时间段的可用性要求，如下表所示。

表 3-3系统用户服务运用阶段表