全部 默认分类 (1) Linux 与系统运维 (3) 容器与云原生 (23) 云平台与虚拟化 (6) DevOps 与自动化 (9) 数据库与中间件 (3) 监控与日志 (3) 网络与安全 (3) 运维面试与成长 (2) 架构设计 (6)
架构评审流程：从申请、预审、正式评审到整改闭环 的封面
08-08
架构设计

架构评审流程：从申请、预审、正式评审到整改闭环

架构评审的目的不是证明方案“足够高级”，而是在投入大量研发和运维成本之前，尽早发现需求遗漏、单点故障、容量不足、安全风险、数据问题和不可运维设计。一套有效的评审流程必须有明确入口、固定材料、可追踪结论和整改闭环。 一、评审适用范围 出现以下情况时，应发起架构评审： 新系统、新平台或重要基础设施建设；

1
0
0
一次完整的架构评审应该检查什么：从需求、可靠性到成本的实战清单 的封面
08-08
架构设计

一次完整的架构评审应该检查什么：从需求、可靠性到成本的实战清单

架构评审不是让几位专家对着架构图“挑问题”，而是在投入大量建设成本之前，系统性识别需求遗漏、单点风险、容量不足、安全缺陷和不可运维设计。好的评审结论应当能够转化为明确行动。 一、评审前需要哪些材料 业务背景、范围与关键用户流程； 功能需求和非功能需求； 系统上下文图、组件图、部署图与数据流图； 容量

1
0
0
高可用、容灾、备份和双活有什么区别：架构设计与选型指南 的封面
08-08
架构设计

高可用、容灾、备份和双活有什么区别：架构设计与选型指南

高可用、容灾、备份和双活经常被混在一起讨论，但它们解决的问题并不相同。备份不能直接提供高可用，双活也不能代替备份。架构设计前必须先确定业务希望抵御哪类故障。 一、高可用 高可用关注局部组件故障时，业务能否继续提供服务。常见手段包括多实例、负载均衡、主从切换、健康检查和自动拉起。 例如两个应用实例部署

2
0
0
架构师必须掌握的非功能需求：可靠性、性能、安全、成本与可运维性 的封面
08-08
架构设计

架构师必须掌握的非功能需求：可靠性、性能、安全、成本与可运维性

很多系统功能都能正常演示，上线后却频繁超时、难以扩容、无法审计或成本失控，根本原因往往不是功能缺失，而是非功能需求没有被明确设计和验证。 一、什么是非功能需求 功能需求回答系统提供什么能力，非功能需求定义这些能力应达到的质量水平。它们必须可量化、可测试，并且与业务重要性一致。 二、可靠性与可用性 可

3
0
0
如何从业务需求设计系统架构：从目标、约束到可落地方案 的封面
08-08
架构设计

如何从业务需求设计系统架构：从目标、约束到可落地方案

架构设计最常见的错误，是在需求还没有说清楚之前就开始选择数据库、消息队列或 Kubernetes。正确顺序应当是先理解业务，再确定质量目标和约束，最后选择能够满足目标的技术方案。 一、先确认业务目标 架构师首先要知道系统为谁服务、解决什么问题、怎样衡量成功。建议至少回答： 核心用户是谁，最重要的业务

1
0
0
从运维工程师到架构师：思维方式、能力模型与成长路线 的封面
08-08
架构设计

从运维工程师到架构师：思维方式、能力模型与成长路线

很多运维工程师已经能够熟练处理 Linux、网络、数据库、容器和监控，却仍然觉得自己距离“架构师”很远。差距通常不在工具数量，而在看问题的层次：运维关注系统能不能运行，架构师还要回答为什么这样设计、业务增长后如何演进、故障会影响多大范围，以及成本是否值得。 一、从执行任务转向解决业务问题 接到“建设

1
0
0