默认分类
未读
Day21-07｜4.7.5 强化TCP/IP堆栈以抵御拒绝服务攻击
Day21-07｜4.7.5 强化 TCP/IP 堆栈以抵御拒绝服务攻击：连接资源也需要架构治理 本文对应《系统架构设计师教程（第2版）》第4章“信息安全技术基础知识”4.7.5“强化TCP/IP堆栈以抵御拒绝服务攻击”。本节关注网络协议栈在遭遇连接洪峰、半连接洪水、异常报文和慢连接时如何保护有限资
默认分类
未读
Day21-06｜4.7.4 端口扫描
Day21-06｜4.7.4 端口扫描：从暴露面发现到最小化服务入口 本文对应《系统架构设计师教程（第2版）》第4章“信息安全技术基础知识”4.7.4“端口扫描”。端口扫描既是攻击者发现服务入口的常用手段，也是安全人员进行资产盘点、配置核查和漏洞治理的重要方法。系统架构师不能只把扫描看作一个工具动作
默认分类
未读
Day22-02｜4.8.2 安全风险管理
Day22-02｜4.8.2 安全风险管理：把不确定的威胁转化为可决策、可跟踪的风险 本文对应《系统架构设计师教程（第2版）》第4章“信息安全技术基础知识”4.8.2“安全风险管理”。安全风险管理不是列一张漏洞清单，而是持续识别资产、威胁、脆弱性和影响，评估风险等级，选择处置策略，并验证残余风险是否
默认分类
未读
Day21-08｜4.7.6 系统漏洞扫描
Day21-08｜4.7.6 系统漏洞扫描：把“发现问题”变成可闭环的风险治理 本文对应《系统架构设计师教程（第2版）》第4章“信息安全技术基础知识”4.7.6“系统漏洞扫描”。漏洞扫描是利用自动化工具和规则，对主机、网络设备、操作系统、中间件、数据库、应用组件和配置进行检查，识别可能被利用的弱点。
默认分类
未读
Day22-01｜4.8.1 计算机信息系统安全保护等级
Day22-01｜4.8.1 计算机信息系统安全保护等级：让安全投入与系统重要性相匹配 本文对应《系统架构设计师教程（第2版）》第4章“信息安全技术基础知识”4.8.1“计算机信息系统安全保护等级”。安全保护等级的核心思想，是根据系统受到破坏后对公民、法人、其他组织、社会秩序和公共利益可能造成的损害
默认分类
未读
Day23-01｜5.1.1 软件工程定义
Day23-01｜5.1.1 软件工程定义：用系统化方法交付可持续演化的软件 本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.1.1“软件工程定义”。软件工程不是“写代码的流程”，而是应用系统化、规范化和可度量的方法，对软件进行开发、运行、维护和演化。系统架构设计师需要把业务目
默认分类
未读
Day23-02｜5.1.2 软件过程模型
Day23-02｜5.1.2 软件过程模型：按不确定性组织需求、设计、验证与交付 本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.1.2“软件过程模型”。软件过程模型是对软件开发活动、顺序、反馈和交付方式的抽象。它不是项目必须照搬的固定模板，而是帮助团队在需求稳定性、技术风险、
默认分类
未读
Day23-03｜5.1.3 敏捷模型
Day23-03｜5.1.3 敏捷模型：在持续反馈中交付价值并控制架构风险 本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.1.3“敏捷模型”。敏捷模型强调以短周期、可运行增量、持续反馈和拥抱变化的方式开发软件。它不是“不要计划、不要设计、不要文档”，也不是把需求随意交给开发人
默认分类
未读
Day23-05｜5.1.5 软件能力成熟度模型
Day23-05｜5.1.5 软件能力成熟度模型：让组织从“靠人交付”走向“可预测改进” 本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.1.5“软件能力成熟度模型”。软件能力成熟度模型（Capability Maturity Model，CMM）及其后续的 CMMI，为评价和
默认分类
未读
Day23-04｜5.1.4 统一过程模型（RUP）
Day23-04｜5.1.4 统一过程模型（RUP）：以架构为中心、用例驱动的迭代式工程 本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.1.4“统一过程模型（RUP）”。RUP（Rational Unified Process，统一软件开发过程）是一种以用例驱动、以架构为中心
默认分类
未读
Day24-01｜5.2.1 需求获取
Day24-01｜5.2.1 需求获取：从“用户说了什么”走向“系统真正要解决什么” 本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.2.1“需求获取”。需求获取是通过访谈、观察、问卷、研讨会、原型、文档分析、场景分析和领域研究等方式，发现并理解利益相关者需要解决的问题、希望获
默认分类
未读
Day24-02｜5.2.2 需求变更
Day24-02｜5.2.2 需求变更：用可追踪的决策控制变化，而不是压制变化 本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.2.2“需求变更”。软件系统在开发、部署和运行过程中必然会发生需求变化，原因包括业务策略调整、法规变化、用户反馈、技术约束、竞争压力、缺陷修正和外部系
