系统运维

在前三篇中，已经讨论了：异常设计原则、异常分类模型、异常抛出策略。本篇回答两个个更重要的问题： 异常在系统中如何流动？ 异常应该在哪里被处理？ 异常处理，本质是架构边界设计。

什么时候抛出异常？什么时候是if-raise，什么时候是try-except-raise？正确的异常抛出策略不仅能让代码更加健壮，还能在不影响性能的前提下提供清晰的错误信息。

本文聚焦异常架构设计的异常分类，从核心责任等维度展开，区分平台与应用异常，详细讲解应用异常的客户端（4xx）、业务（299）、服务端（5xx）三层架构及未知异常处理。

异常的架构设计，是业务无关的，大多数开发工程师都不会特别关注，什么时候抛异常，什么时候处理异常都看心情和习惯。互联网上关于异常的系统性研究文章几乎没有，我将花费一段时间，由浅入深探究异常架构设计。

好的异常处理，不是为了让程序“不报错”，而是为了让错误发生得清晰、体面且可控。防御性编程是态度，快速失败是策略，用户友好是修养，可观测性是生命线。

团队治理项目多了，管理不能乱。在父子项目架构下，职责划分要像切菜一样清晰。Submodule 最大的优势在于解耦，它允许各团队保留独立的 Git 权限和不同的开发节奏。

异常处理（Exception Handling）的设计往往能体现一个团队编码规范质量，直接对性能分析、故障发现、故障诊断等起到重要作用，本文介绍异常Exception设计在系统可维护性和故障感知上的。

云原生的技术理念是将应用与基础设施解耦，实现高度可扩展、弹性和可靠的系统，其代表技术包括微服务、容器、服务网格、不可变基础设施与声明式API。

CD Pipeline 从镜像仓库到生产环境，流水线在项目建设初期定义，可重复执行。在编排 Pipeline 中使用配置及代码、声明式API的理念。

本文介绍了 CI Pipeline 的设计理念和基本情况，容器镜像作为云原生时代的通用制品，建立镜像仓库进行托管是必要的。

在理想状态下，CI与CD可构成“提交即发布”的全自动化流水线，但中大型组织常将其拆分为独立流程。本文从管理与技术双重视角，解析这一“反直觉”做法的原因。

GitHub Actions创建issue时，自动回复工作流；GitHub Pages 提供 Serverless 的静态站点托管，变更简化到一个git push，实现了自动化运维、免运维。

学习 GitHub Actions 中的核心概念基础知识，其核心理念包括「事件驱动」、「基础设施即代码」，不止于运维流水线，而是与 Git 代码仓库原生集成、开箱即用的超能力。

流水线技术是实现CI/CD的关键技术，个人开发者关注 GitHub Actions，中小型企业选择阿里云效或GitLab，极客或中大型企业技术转型探索和尝试Tekton、Argo CD。

本文介绍声明式 API 与 Docker-Compose 容器编排工具，配置即代码，开箱即用的特性解决命令式操作繁琐、依赖管理难等问题。

从前端项目部署实践中，学习DevOps与CI/CD。容器化部署（Docker、Kubernetes）已成为现代软件交付的默认选项，本文介绍容器化部署前端项目的2种实践：多阶段构建、构建与容器化分离。

一个完整的日志聚合系统（日志服务）通常包含以下四大核心模块：日志生成模块、日志采集模块、日志存储模块以及日志查询模块。

从前端项目部署实践中，学习DevOps与CICD。本文介绍了服务部署的三个阶段，阶段三，使用Git工具与手动部署，是最小可行方案。

文章围绕提问展开探讨，指出以交互次数衡量提问效率与质量，3 次交互以内最佳。列举伸手党、反驳性人格等愚蠢提问类型，强调提问前做好 OCQD 准备，提问时诚恳尊重，提问后做好记录、多方求助与问题闭环。

一次服务重启引发的系统故障，无状态服务应是可重启的、自配置的、易于迁移的。不应该将状态维持的负担转嫁到第三方人员中。