技术实践层

GL-TECHNOLOGY

层组基础进阶高级32 节点

§1组简介

组目录:本质层方法论层技术实践层域·概念与需求域·架构设计域·实现与构造域·测试域·部署域·运维域·演化与弃用域·质量属性域·团队与康威域·方法论主干域·跨域横切·质量属性横切·技术债横切·团队与康威案例层

本组 32 个节点，类型为层组，域 H，覆盖阶段 基础 / 进阶 / 高级。

§2成员节点目录

节点 ID	名称	层/来源	阶段	简介
TEC-F-01	需求可追溯性与影响分析	技术实践 technology	进阶	以需求库为中枢，把需求条目、属性与上下游制品（干系人需求、系统需求、设计、测试、代码）建立可查询的追踪关系，并以结构化查询支持变更影响分析的需求管理平台化落地。
TEC-F-02	需求技术债识别与度量	技术实践 technology	高级	识别并度量需求技术债——理想规格与实际实现之间的差距——的技术做法，把需求层的债务纳入技术债管理（TDM）的识别与度量阶段，使需求质量缺口可被发现与跟踪。
TEC-N-01	交付效能度量与仪表化	技术实践 technology	进阶	把交付效能指标的采集、聚合与呈现平台化：从版本控制与流水线事件自动计算并持续反馈，并以治理机制约束指标被博弈（gaming）的风险，使度量服务于改进而非考核。
TEC-N-02	团队拓扑落地与规模化	技术实践 technology	高级	在规模化组织中落地团队拓扑四类型与三交互模式，以认知负荷管理与快速流动为约束、显式定义团队交互方式的组织实践，用于把团队结构与被期望的架构对齐。
TEC-G-01	AWS 良好架构框架	技术实践 technology	进阶	AWS 发布的云架构最佳实践对照框架，以运营卓越、安全、可靠性、性能效率、成本优化、可持续性六大支柱组织设计原则与评审问题，用于一致地度量工作负载与最佳实践的偏差。
TEC-G-02	GCP 良好架构框架	技术实践 technology	进阶	Google Cloud 发布的云架构建议框架，以运营卓越、安全隐私与合规、可靠性、成本优化、性能优化、可持续性六大支柱及 AI/ML、金融等跨支柱视角，指导设计安全、高效、韧性、高性能且可持续的云拓扑。
TEC-G-03	Azure 架构中心	技术实践 technology	基础	Microsoft 维护的 Azure 架构中心，汇集云架构风格目录（N 层、微服务、事件驱动等，含适用性、收益与挑战）与安全部署实践，指导按业务驱动与非功能需求选择风格并安全发布变更。
TEC-G-04	ThoughtWorks 技术雷达	技术实践 technology	进阶	Thoughtworks 技术咨询委员会每年发布两次的技术快照，以技术/方法条目（blip）经四象限与四环（Adopt/Trial/Assess/Caution）组织，表达对技术采用程度的带观点推荐，并明确不追求全面、不接受厂商付费影响。
TEC-H-01	SonarQube 静态分析平台	技术实践 technology	进阶	SonarQube Server 是面向持续集成的静态代码分析平台，以规则引擎自动检测代码坏味道、缺陷与安全热点，并通过质量门控把分析度量转化为变更准入判断，同时区分整体代码与新代码以支撑增量治理。
TEC-H-02	SQALE 技术债评估方法	技术实践 technology	高级	SQALE 是一套以生命周期期望为基准、力求客观可复现地评估源代码质量并量化技术债的方法，由若干基本原则与质量模型、分析模型、指数、指标等组件构成，供组织与厂商实现。
TEC-H-03	技术债量化度量指标	技术实践 technology	高级	技术债量化度量把代码缺陷折算为可计算的债务规模与比率：以修复成本累加得到技术债额，用技术债比率（债务与开发成本之比）映射可维护性评级，并区分整体代码与新代码以支撑增量治理。
TEC-H-04	依赖结构度量与渐进收紧治理	技术实践 technology	高级	依赖结构度量与渐进收紧治理把组件间的依赖关系折算为稳定性与抽象度等可计算指标，用归一化距主序列距离定位偏离健康线的组件，并以先告警、后报错的级联阈值在受控节奏内把结构拉回健康区间。
TEC-I-01	持续集成服务与流水线	技术实践 technology	进阶	持续集成服务与流水线是把「频繁合并回主线、每次合并自动构建并运行测试」制度化的技术载体：由单一代码主线、自动化构建与测试执行、结果回传与即时反馈构成，使集成错误在产生后最短窗口内暴露。
TEC-I-02	关键字驱动测试框架	技术实践 technology	高级	关键字驱动测试（KDT）是 ISO/IEC/IEEE 29119-5 定义的一种自动化测试框架范式：把测试操作抽象为可复用的关键字，测试用例由「关键字＋参数」序列描述，驱动层负责解释执行，从而将测试意图与底层脚本实现分离。
TEC-I-03	xUnit 测试框架族	技术实践 technology	进阶	xUnit 测试框架族是按「测试类—测试方法—断言—夹具」结构组织并自动执行单元测试的一类框架，命名源自 JUnit 及其衍生家族；它把测试书写、发现、执行与报告统一为开发者可直接使用的代码骨架，是单元测试与测试驱动开发的主要工具载体。
TEC-J-01	Kubernetes 部署编排	技术实践 technology	进阶	Kubernetes 是容器编排平台，其 Deployment 控制器以声明式方式管理无状态工作负载的创建、扩缩与更新，默认采用滚动更新策略，并通过保留历史 ReplicaSet 支持版本回退。
TEC-J-02	不可变基础设施实现	技术实践 technology	进阶	不可变基础设施实现指部署后的实例不再被就地修改，任何变更都通过从受测基础镜像重建新实例并替换旧实例来完成，从而消除运行期配置漂移。
TEC-J-03	蓝绿部署	技术实践 technology	进阶	蓝绿部署维护两套尽可能相同、均可承担全量负载的生产环境，任一时刻仅一套承载流量；新版本在另一套环境验证通过后整体切换流量，异常时切回原环境实现快速回滚。
TEC-J-04	金丝雀发布	技术实践 technology	高级	金丝雀发布先把新版本部署到不接用户或仅接少量用户的基础设施上，再按健康指标逐步放大流量与用户比例直至全量，从而把新版本故障的爆炸半径限制在受影响的小范围内。
TEC-J-05	部署自动化	技术实践 technology	进阶	部署自动化把从构建产物到各环境的部署过程脚本化、参数化并纳入版本控制，使任何持有凭据者都能把任意已构建制品一致地部署到任意环境，且过程尽量幂等、可重复。
TEC-J-06	部署流水线工具化	技术实践 technology	基础	部署流水线把从提交到生产的构建过程拆分为多个置信度递增的自动化阶段，前一阶段产出的制品供后续阶段逐级晋级，生产部署通常是流水线的最后一个阶段。
TEC-K-01	断路器与重试退避	技术实践 technology	进阶	断路器、超时与重试是一组协同的远程调用稳定性实现：超时限制等待，断路器在失败达阈值后快速失败以阻止级联，重试仅针对幂等操作的瞬时故障并以指数退避加抖动控制节奏。
TEC-K-02	可观测性信号采集	技术实践 technology	进阶	通过 traces、metrics、logs 等信号从系统外部推断内部状态，以回答未知未知与为何发生；工程界习称三支柱，其价值关键在于信号可关联而非数量多少。
TEC-K-03	服务等级目标与错误预算	技术实践 technology	高级	用 SLI（好事件/总事件）度量服务水平，设定小于 100% 的 SLO 目标，并以错误预算等于 100% 减 SLO 驱动发布与加固决策；SLA 则是含后果的对外契约。
TEC-K-04	混沌工程实践	技术实践 technology	高级	在生产中对系统做受控实验以建立对其抵御动荡条件能力的信心：定义稳态、提出假设、注入真实事件、比较对照组与实验组以证伪，并最小化爆炸半径。
TEC-K-05	无指责复盘实践	技术实践 technology	进阶	无指责复盘是一种事故发生后的书面复盘，其记录对象包括影响范围、处置与缓解过程、根因分析与后续行动项，而它的定义性特征在于聚焦方向：考察导致事件的那些系统性原因与当时的决策情境，而不是追查哪个个人或团队该被追究。它之所以被称为一种文化而不只是一份文档，是因为它同时规定了两件事——产出什么内容，以及以什么态度对待参与者。书中把它归入提升系统抵御人为失误能力的手段之列，与测试、回滚机制、渐进发布、监控与可观测性、界面设计并列，说明它的定位是组织层面的可靠性工程实践，而非单纯的行政流程。理解这一定义要抓住三组区分。
TEC-K-06	DORA 交付指标	技术实践 technology	基础	用一组软件交付效能指标衡量组织的交付吞吐与稳定性；当前官方口径为五项指标，由早期四键扩展而来，并已用失败部署恢复时间取代平均修复时间。
TEC-L-01	架构适应度函数工具化	技术实践 technology	高级	把架构约束与质量目标转写为可自动执行、可量化判定的校验，并借助测试、静态分析、监控与部署流水线门禁等机制持续运行，使架构意图不再依赖人的记忆与自觉。
TEC-L-02	绞杀者渐进式替换	技术实践 technology	高级	在遗留系统之上或之旁增量构建新实现，通过可切换的接缝与路由逐步把功能与数据迁移过去，逐步替代旧系统，而非一次性整机重写。
TEC-M-01	质量模型工具化	技术实践 technology	进阶	把 SQuaRE 系列标准的质量特性与子特性框架落为可操作的检查表、需求模板与评价工具，使质量关切在需求、设计与评价之间以同一坐标被规定、测量与比较。
TEC-M-02	可维护性量化	技术实践 technology	高级	把可维护性与技术债转写为可计算指标：以修复违规的成本估计债务本金、按对可维护性的影响折算利息，沿质量子特性组织规则与评分，使变更成本可比较、可追踪。
TEC-M-03	可修改性战术实现	技术实践 technology	进阶	可修改性战术的实现，指把推迟绑定时间、局部化变更与防止涟漪效应这三类设计决策落到具体结构机制上，包括接口与间接层、易变决策的封装位置、依赖方向约束与依赖反转，目标是缩小每一次修改的影响半径。第八章节把这些手段归入三个抽屉。一是提升内聚，做法是拆分职责过杂的模块、把散落各处的同类职责重新归拢。二是降低耦合，做法是加壳封装、插入居间者、把公共能力抽成共享服务、约束模块可见与可依赖的范围。三是推迟绑定，做法涵盖构件替换、编译期参数化、切面、配置期赋值、资源文件、运行期发现、参数解释、共享仓库与多态分派。

§3组内关系图

前置依赖实现依据推导案例印证对比冲突

技术实践层：组内关系图（组内共 32 个成员，按度数裁剪展示 24 个）：内联 24 个节点、29 条组内边，连线按边类型着色（六类配色见下）；构建期确定性计算，无运行期脚本。

§4学习路径提示

本组内存在 0 条前置依赖边（prerequisite），推荐先掌握前置知识点，再进入依赖它的节点。