SE-review

Posted on Edited on In Views: Word count in article: 10k Reading time ≈ 9 mins.

软工cheatsheet

9 Acchitecture

大型网站架构

大型网站架构

大型网站软件系统特点：

  • 高并发，大流量
  • 高可用
  • 海量数据
  • 用户分布广泛，网络情况复杂
  • 安全环境恶劣
  • 需求快速变更，发布频繁
  • 渐进式发展

大型网站架构演化发展历程：

  1. 初始阶段
  2. 应用服务和数据服务分离
  3. 使用缓存改善网站性能
  4. 使用应用服务器集群改善网站的并发处理能力
  5. 数据库读写分离
  6. 使用反向代理和CDN加速网站响应
  7. 使用分布式文件系统和分布式数据库系统
  8. 使用NoSQL和搜索引擎
  9. 业务拆分
  10. 分布式服务

大型网站架构演化的价值观：

  • 大型网站架构技术的核心价值是随网站所需灵活应对
  • 驱动大型网站技术发展的主要力量是网站的业务发展

网站架构设计误区：

  • 一味追随大公司的解决方案
  • 为了技术而技术
  • 企图用技术解决所有的问题

具体解释：

  1. 初始阶段：应用程序、数据库、文件等所有资源都在一台服务器上
  2. 应用服务和数据服务分离：（有数据库服务器，文件服务器，应用服务器）不同特性的服务器承担 不同的服务角色，网站的并发处理能力和数据存储空间都得到了很大改善，但是I/O还是慢
  3. 使用缓存改善网站性能：（应用服务器增加了本地缓存，增加了远程分布式缓存）使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站访问高峰期，应用服务器成为整个网站的瓶颈
  4. 使用应用服务器集群改善网站的并发处理能力：（增加了负载均衡调度服务器，应用服务器改为了多个，形成一个集群）通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群的任何一台服务器上。部分数据库读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库，负载压力过高时，数据库成为瓶颈
  5. 数据库读写分离：（应用服务器增加数据访问模块，数据库服务器变成了主从两个服务器）应用服务器在写数据时，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器在读数据的时候，直接从从数据库获得数据。
  6. 使用反向代理和CDN加速网站响应：（在负载均衡调度服务器之前增加了CDN服务器和反向代理服务器）CDN和反向代理的基本原理都是缓存，加快用户访问速度，减轻后端服务器的负载压力。CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据。反向代理步部署在网站的中心机房，当用户请求到达中心机房后，反向代理服务器中缓存着用户请求的资源，直接返回给用户。
  7. 使用分布式文件系统和分布式数据库系统
  8. 使用NoSQL和搜索引擎
  9. 业务拆分（如新建一个消息队列服务器）
  10. 分布式服务（把上文的服务器变成分布式）

名词解释：

  1. CDN（内容分发网络Content Delivery Network）：CDN就是根据用户位置分配最近的资源，于是，用户在上网的时候不用直接访问源站，而是访问离他“最近的”一个 CDN 节点(也叫做“边缘节点”、edge node)，其实就是缓存了源站内容的代理服务器。
  2. 反向代理：反向代理是位于一个或多个 Web 服务器前面的服务器，拦截来自客户端的请求。这与转发代理不同 - 在转发代理中，代理位于客户端的前面。使用反向代理，当客户端将请求发送到网站的源服务器时，反向代理服务器会在网络边缘拦截这些请求。然后，反向代理服务器将向源服务器发送请求并从源服务器接收响应。
  3. NoSQL：非关系型数据库

流媒体应用架构

流媒体是网络带宽主要消费者
挑战：用户规模，异质性，用户有不同的能力，（有线无线，带宽的不同） 措施：分布式应用架构

简单的 服务器 网络 用户架构
问题：

  1. 随着时间的推移，服务器到客户端的带宽变化，并改变网络拥塞程度（内部、接入网、网络核心、视频服务器）
  2. 数据包丢失、拥堵造成的延迟会导致播放延迟或视频质量不佳
  3. 连续播放约束：在客户端视频播放时，播放时间必须与初始时间一致，但网络延迟是可变的（抖动），因此需要客户端缓冲器来匹配连续播放约束
  4. 其他的挑战：客户端互动：暂停、快进、后退、跳过视频；视频数据包可能丢失、重传

DASH：dynamic adaptive streaming over HTTP
服务器 § 将视频文件分成多个块 § 每个块以多种不同的速率编码 § 不同的编码率存储在不同的文件中 § 在不同的 CDN 节点复制文件 § 清单文件：提供不同片段的 URL

客户端

§ 定期估算服务器到客户端的带宽 § 查询清单，每次请求一个数据块 - 根据当前带宽选择可持续的最大编码率 - 可在不同的时间点（取决于当时的可用带宽）选择不同的编码率，并从不同的服务器选择不同的编码率

客户确定

  • 何时请求分块（以免发生缓冲区饥饿或溢出）
  • 请求何种编码率（当带宽较宽时，质量较高质量）
  • 在何处请求数据块（可请求从 "靠近 "客户端的 URL 服务器请求或可用带宽较高的带宽）

Streaming video=encoding + DASH + playout buffering

CDN(content distribution network)
挑战：如何将内容（从数百万部视频中挑选出来）同时流式传输给数十万用户？

方案 2：在多个地理分布站点存储/提供多份视频副本（CDN）
深入：将 CDN 服务器深入到许多网络中 bring home：数量较少（10 个）的access net附近的 POP 中的较大集群 用户请求内容，服务提供商返回清单manifest

  • 使用清单，客户端以最高支持速率检索内容
  • 如果网络路径拥堵，可选择不同的速率或副本

OTT服务（Over-the-top media services），是一种通过互联网直接向观众提供的流媒体服务。 OTT 挑战：从 "边缘 "应对拥挤的互联网 § 哪些内容应放在哪个 CDN 节点？ § 从哪个 CDN 节点检索内容？以何种速率检索？

Client-Server 和 P2P架构

在客户机-服务器架构中，客户机提出请求，服务器响应许多客户机请求。客户端-服务器捕捉了专门服务器和客户端的可重用行为，而不指定服务器和客户端应如何实现。

在点对点架构中，所有实体都充当客户和服务器。这虽然很灵活，但却很难让软件很好地完成其中任何一项工作。
没有永远在线的服务器 § 任意终端系统直接通信 § 对等方向其他对等方请求服务，向其他对等方提供服务作为回报 - 自扩展性--新的对等体带来新的服务能力和新的服务需求 § 对等网络间歇性连接并更改 IP 地址 - 复杂的管理 § 例子： P2P 文件共享（BitTorrent）、流媒体（KanKan）、网络电话（Skype）

file distribution time
Client-Server:
time to distribute F to N clients
us是服务器上传的速度，dmin是用户下载的最小速度

P2P：
time to distribute F to N clients
server只需要传一份文件，总体需要传NF大小的文件，总上传速率为us+sigma

架构设计原则

软件架构定义：The fundamental organization of a system, embodied in its components, their relationships to each other and the environment,and the principles governing its design and evolution

设计目标
高性能，高可用性，高可扩展性（容量变化），高异构性，高安全性，低成本

五个原则
KISS = Keep It Simple Stupid Modularity（模块化） Separation of Concern Design for CHANGE Design for REUSE

KISS
简化的接口，解耦模块依赖关系，简单的配置

modularity
将复杂系统划分为较简单的组成部分
强内聚，松耦合
好处：

  • 更容易规划开发
  • 可定义和交付软件增量
  • 更容易适应变化
  • 更有效地进行测试和调试
  • 可以进行长期维护，而不会产生严重的副作用

separation of concerns

Concentrate on different aspects of a problem separately

方法：1.分解，将复杂问题分解为子问题，小、简单、可控 2.综合，将子问题的解决方案合成一个综合解决方案

优点，需要改动的代码是本地化的localized

比如将server分为db server和application server

Design for CHANGE

Strategy is to consider the likely changes as part of the system design，隔离软件特定部分可能发生的更改，使更改仅限于小部分内容

减少维护成本

  1. 它们可能在不同的硬件配置上运行。
  2. 它们可能执行相同的功能，但输入和输出数据的格式或输出数据。
  3. 由于可用资源不同，某些数据结构或算法也可能不同。
  4. 某些数据结构或算法可能因输入数据集的大小或输入和输出数据的大小不同而不同。
  5. 由于输入数据集的大小或某些事件的相对频率不同，在某些数据结构或算法中也会有所不同。
  6. 一些用户可能只需要其他用户需要的服务或功能的子集。这些 "要求不高 "的用户可能会要求不要强迫他们为不需要的功能所消耗的资源付费。"

Design for REUSE

To avoid “reinventing the wheel” increase ROI"return on investment"
1. lower production and maintenance cost 2.faster delivery 3.increased quality

架构模式

不同视角下的网站性能：

用户视角：用户在浏览器上直观感受到的⽹站响应速度。

  • 用户计算机和⽹站服务器通信的时间
  • ⽹站服务器处理的时间
  • 用户计算机浏览器构造请求解析响应数据的时间

开发人员视角：应用程序本身及其相关⼦系统的性能。

  • 响应延迟
  • 系统吞吐量
  • 并发处理能⼒
  • 系统稳定性

维护人员视角：基础设施性能和资源利用率。

  • ⽹络运⾏商的带宽能⼒
  • 服务器硬件的配置
  • 数据中⼼⽹络架构
  • 服务器和⽹络带宽的资源利用率

高性能关系数据库：读写分离，业务分库，分表，

高性能缓存架构的三个问题：

  1. 需要经过复杂运算后得出的数据，储存系统无能为力
  2. 读多写少的数据，储存系统有心无力
  3. 缓存系统需要解决：缓存穿透，缓存雪崩，缓存热点

缓存穿透：指缓存和数据库中都没有的数据，用户不断发起请求
方案：接口增加校验，没取到的数据设置为key-null，

缓存雪崩，缓存失效后系统性能急剧下降
方案：缓存过期时间随机，将热点数据均匀分布在不同的缓存数据库中，设置热点数据永不过期

缓存热点：大部分业务请求命中同一份缓存数据
方案：复制多份，不同缓存副本设置不同的过期时间

负载均衡技术：
分类： DNS负载均衡，硬件负载均衡，软件负载均衡
算法：

  • 轮询：服务器不宕机，服务器与负载均衡器不断连
  • 加权轮询：服务器性能有差异
  • 负载最低优先：连接数、请求数、CPU负载，IO负载，需要采样
  • 性能最优优先：处理速度，需要采样
  • Hash：源地址，ID

Web前端性能优化

  1. 浏览器访问优化：减少http请求，使用浏览器缓存，启用压缩，CSS放在页面最上面，JavaScript放在页面最下面，减少Cookie传输
  2. CDN加速
  3. 反向代理

应用服务器性能优化：

使用消息队列后，用户请求的数据发送给消息队列后立即返回，再由消息队列的消费者进程从消息队列中获取数据，异步写⼊数据库，有削峰作用

高可用性

可用性是指系统掩盖或修复故障的能力，在规定的时间间隔内，累计服务中断时间不超过规定值 mean time between failures/(*+mean time to repair)

容错性：分布式系统即使在硬件/软件/网络可靠性较低的情况下也能保持可用性，通过组件的恢复和复制实现容错

CAP理论： 没有CA架构
-一致性： 每次读取都会收到最新写入的内容，否则就会出错 -可用性： 每个请求都会收到（无错误的）合理响应，但不保证其中包含最新写入内容 -分区容错： 尽管节点之间的网络丢弃（或延迟）了任意数量的信息，系统仍能继续运行

流程>服务>功能

微服务架构风格是一种将单个应用程序作为一套小型服务来开发的方法，每个服务都在自己的进程中运行，并通过轻量级机制（通常是 HTTP 资源 API）进行通信。 这些服务围绕业务功能构建，可通过全自动部署机制独立部署。

允许持续的发布和部署

特点：

  • 通过发布的接口将服务作为构建模块（组件）。
  • 围绕业务能力组织。
  • 开发团队对生产中的软件负全责
  • 智能终端和哑管道
  • 分散控制语言
  • 分散式数据库：每项服务都管理自己的数据库，可以是相同数据库技术的不同实例，也可以是完全不同的数据库系统，一种称为多语种（Polyglot）的方法。
  • 基础设施自动化
  • 故障设计：微服务团队希望看到对每个单独服务的复杂监控和日志设置，如显示运行/停止状态以及各种运行和业务相关指标的仪表板。
  • 演进设计 将服务分解视为另一种工具，使应用开发人员能够控制应用程序中的变化，而不会减缓变化速度。微服务可以独立替换和升级。

对比：

  1. 单体应用程序将其所有功能集中在一个进程中，并通过在多个服务器上复制该单体来进行扩展。微服务架构将每个功能元素都置于单独的服务中，并通过将这些服务分布在不同服务器上进行扩展，并根据需要进行复制。
  2. monolith 多个模组在同样的进程，微服务，模组在不同的进程
  3. 数据库部署，monolith，一个db，微服务架构，多个db，application db

四代

  • 容器调度
  • 服务发现和容错
  • 边车模式和服务网络
  • 无服务器架构

10 requirements

需求的定义：需求是对应当执行的任务的规范说明，描述系统的行为特性或属性，是一种对系统开发进程的约束。

用户需求的获取过程：

  1. 识别用户类别：用户群的访问权限或安全级别；用户群在业务操作中执行的任务；用户群使用的特性；用户群使用产品的频率；用户群在应用领域和计算机专业技能经验；用户群使用的平台（台式机、笔记本、平板、智能手机等）；用户群的语言；用户群是直接还是间接与系统交互
  2. 确定干系人代表：干系人是指积极参与项目的某个人、群体或组织，可能会受项目过程和结果的影响或影响项目的过程和结果。有开发组织以外（直接间接用户，采购人员，软件供应商），开发组织（开发部门经理，市场人员，公司业主） ，项目组（项目经理，业务分析人员，设计师）
  3. 确定决策者：在软件项目中，需要在关键路径上做决定，或是解决一些冲突，接受（或拒绝）某个需求变更或者批准一组即将发布的需求。决策人或决策小组对决定工作方向、保证项目进度具有重要作用。决策规则：决策领导做决定；小组投票，少数服从多数；小组投票，但结果必需获得一致通过；小组讨论和协商达成共识，每个人都拥有这个决定并承诺支持；决策领导授权一个决策人；小组达成决策，但允许有人有权否定小组决定
  4. 需求达成共识：对需求或其中某部分达成一致是客户-开发关系的核心。客户确认：需求描述了他们的需要；开发人员确认：理解需求并且可以实现；测试人员确认：需求是可验证的；管理层确认：需求满足业务目标。

需求基线，一个特定时间点的需求快照，一组需求，作为后续开发的基础。

定义良好的需求三要素：

  • 可验证性：可以验证
  • 必要性：为解决利益相关者的问题或实现利益相关者的目标，系统必须满足或具备的条件、
  • 可量化性：由可测量的条件限定，并受到约束。

条件 主体 动作 客体 约束 值

戴维斯关于需求规格重要性的假设 在产品生命周期越晚发现故障，修复故障的成本就越高

需求质量特性：必要，实现无关，明确，一致，完整，唯一，可行，可追溯，可验证

11 operations

软件系统生命周期的绝大部分时间是在使用中度过的，而不是在设计或实施中。
系统总成本的 40-90% 是在出生后产生的

SRE的信条

  1. 确保对工程学的持久关注
    • 运营时间不超过 50%；
    • 每 8-12 小时待命班次不超过两次活动，不少于一次活动
    • 应为所有重大事件撰写调查报告（紧急事件）
  2. 在不违反服务 SLO 的情况下追求最大变更速度
    • 业务/产品确定系统的非 100% 可用性目标和错误预算（错误预算）=1-可用性目标。
    • 中断不再是一件 "坏事"--它是创新过程中的一个预期部分。
  3. 监测
    • 紧迫性： 警报（立即行动） > 工单（行动） > 日志（仅供参考）
  4. 应急响应
    • 可靠性是平均故障时间 (MTTF) 和平均修复时间 (MTTR) 的函数
    • 人类会增加延迟 - 尽可能实现自动化。
    • 待命 (轮值) "游戏手册"（MTTR 提高 3 倍）和 "灾难角色扮演"。
  5. 变革管理
    • 70% 的中断 (中断) 是由于实时系统中的更改造成的。
    • 将人从环路中移除：实施渐进式推出；快速准确地发现问题；出现问题时安全地回退更改
  6. 需求预测和产能规划
    • 确保有足够的容量和冗余来满足预计的未来需求，并提供所需的可用性。
    • 三个必经步骤： 准确的有机需求预测，预测时间应超过获取容量所需的准备时间 在需求预测中准确纳入无机需求源 定期对系统进行负载测试，将原始容量（服务器、磁盘等）与服务容量相关联
  7. 调配
    • 结合变更管理和容量规划
  8. 效率和性能
    • 有效利用资源可节省（大量）成本。
    • 应密切监控和维护性能（响应速度

拥抱风险原则：

  1. 平衡不可用风险与快速创新和高效服务运营目标之间的关系
    • 优化用户的整体满意度--功能、服务、性能和可靠性。
    • 用户通常不会注意到服务的高可靠性和极端可靠性之间的区别。
  2. 通过管理风险来管理服务可靠性（如 99.99% 或更高）
    • 降低系统故障的几率
    • 确保可靠性的成本随着可靠性的增加而非线性增加。冗余机器/计算资源的成本。机会成本（开发新的产品功能）
  3. 衡量服务风险
    • 低可靠性的成本：用户不满、伤害或失去信任；直接或间接的收入损失；品牌或声誉影响；不受欢迎的新闻报道
    • 基于时间的可用性。可用性 = 正常运行时间/（正常运行时间 + 停机时间）
    • 总可用性（合计可用性，Google 首选）。可用性 = 成功请求/总请求

MTBF:mean time between failures
MTTR:mean time to repair
MTBF=uptime / num_of_failures MTTR=downtime / num_of_failures Availability= MTBF / (MTBF+MTTR)=uptime/(uptime+downtime)

错误预算可以调整激励机制，强调 SRE 与产品开发之间的共同所有权。错误预算更容易决定发布速度，并有效化解与利益相关者关于中断的讨论,并允许多个团队就生产风险得出相同的结论，而不会产生怨恨。

服务级别术语 - 服务水平指标 (SLI)：对所提供服务水平的某些方面进行仔细定义的量化测量 例如，请求延迟、错误率、系统吞吐量、可用性。通常在一个时间窗口内汇总：比率、平均值或百分位数 - 服务级别目标（SLO）：由 SLI 衡量的服务级别的目标值或值范围。应成为确定工作优先级的主要驱动力。例如，每个请求的平均延迟时间应低于 100 毫秒。例如，谷歌计算引擎的可用性应达到 99.95 - 服务级别协议 (SLA)：与用户签订的明示或默示合同，包括达到（或未达到）其所包含的 SLO 的后果

实践中的指标

  1. 您和您的用户关心什么？
    • 通常是一些有代表性的指标：不要太多，也不要太少
    • 面向用户的服务系统（如前端）：可用性、延迟和吞吐量
    • 存储系统：延迟、可用性和耐用性
    • 大数据系统：吞吐量和端到端延迟
  2. 收集指标
    • 服务器端： Prometheus/Zabbix/Borgmon；定期日志分析
    • 客户端工具
  3. 聚合：平均值与百分位数

琐事的定义：是指与生产服务相关的工作，这些工作往往是手工的、重复的、可自动化的、战术性的，缺乏持久价值，并且随着服务的增长而呈线性增长。

SRE 组织有一个公开的目标，即把每个 SRE 的操作工作（即劳作）时间控制在 50%以下。每个 SRE 至少应将 50% 的时间用于工程项目工作，以减少未来的工作量或增加服务功能。

典型的 SRE 活动大致分为以下几类： 软件工程：编写或修改代码，以及任何相关的设计和文档工作。 系统工程：配置生产系统、修改配置等。 辛劳：与运行服务直接相关的重复性、手工等工作。 管理费用： 与运行服务无直接联系的管理工作

分布式系统监控：
白盒监控：日志、JVM 日志、HTTP 日志等内部指标，依赖于检查系统内部的能力，允许检测即将来临的问题、被重试掩盖的故障等 黑盒监控：测试外部可见行为，以症状为导向，代表主动而非预测的问题： "系统现在无法正常工作" 仪表板：服务核心指标视图 警报：供人阅读的通知

监控系统（黑盒）的四大黄金信号 延迟：服务一个请求所需的时间 流量：衡量对系统的需求量，以高级系统特定指标衡量 错误：请求失败率 饱和度：服务的 "满负荷 "程度。在某个小窗口（如一分钟）内测量第 99 百分位数的响应时间，可提供饱和的早期信号。

紧急警报的基本哲学

  • 每次传呼机响起，我都应该能做出紧急反应。我每天只能做出几次紧急反应，然后就会感到疲劳。
  • 每个警报都应具有可操作性。
  • 每个警报的响应都应该需要人类的智慧。如果一个警报只需要机器人做出反应，那么它就不应该是一个警报。
  • 警报应涉及新颖的问题或前所未见的事件。
  • 应由专人找到并消除问题的根源；如果无法解决，则应完全自动化警报响应。

随叫随到(On call)：在工作和非工作时间都能接听电话，以保持服务的可靠性和可用性。 值班工程师的生活：一旦收到并确认页面，值班工程师应立即对问题进行分流，并努力加以解决，可能需要其他团队成员的参与并根据需要进行升级。 平衡On call 数量平衡：我们坚信 "SRE"中的 "E（工程）"。至少50%的SRE时间用于工程设计，其余时间用于待命的比例不得超过25%。 质量平衡：在每个待命班次中，工程师应有足够的时间处理任何事故（紧急事件）和后续活动。 每起事件 6 小时，这是与同一根本原因相关的一系列事件和警报，将作为同一事后分析的一部分进行讨论。 Avoiding Inappropriate Operational Load (>50%)

有效排除故障需要两个因素：

  • 了解如何一般性地排除故障（即不需要任何特定的系统知识）
  • 扎实的系统知识

故障排除过程的一般模型 假设演绎法： 根据对系统的一系列观察结果和理解系统行为的理论基础，我们反复假设故障的潜在原因，并尝试测试这些假设。将理论与证据进行比较；对系统进行处理和观察,直到找出根本原因。

常见误区：

  • 查看不相关的症状或误解系统指标的含义。
  • 误解如何改变系统、输入或环境，以便安全有效地测试假设。
  • 对问题所在提出不可能的理论，或抓住过去问题的原因不放，认为既然发生过一次，就一定会再次发生。
  • 寻找实际上是巧合或与共同原因相关的虚假相关性。

实践中：

问题报告：一份有效的报告应该告诉你预期的行为、实际的行为，如果可能，还应该告诉你如何重现这种行为。 记录调查和修复活动，以备将来参考。 分流： - 评估问题的严重性 - 止血应该是您的首要任务：使系统在这种情况下尽可能良好地运行。 将故障群集的流量转移到其他仍在运行的群集、 整体丢弃流量以防止出现连锁故障，或 禁用子系统以减轻负荷

检查：检查系统中的每个组件。监控系统：所有指标；系统和应用程序日志；调用跟踪；更改日志；工作流日志

诊断

简化和减少 查看组件之间的连接--或者说，查看组件之间的数据流--以确定特定组件是否正常工作。 系统地从堆栈的一端开始，依次检查每个组件，然后向另一端推进。

询问 "是什么"、"在哪里 "和 "为什么"。找出发生故障的系统在做什么、然后询问故障原因，并它的资源被用到了哪里，或者它的输出流向了哪里。

最后触动它的是什么 配置改变或服务负载类型发生变化。 将系统性能和行为的变化与系统和环境中的其他事件联系起来，也有助于构建监控仪表板；

总结：

从头开始在每个组件中建立可观察性，包括白盒指标和结构化日志。 记录工作流程和变更。 在设计系统时，在各组件之间设置易于理解和观察的接口。 确保在整个系统中以一致的方式提供信息，加快诊断和恢复的时间。 采用系统化方法排除故障，而不是依靠运气或经验，有助于缩短服务恢复时间，从而为用户带来更好的体验。

紧急事件响应 测试（受控故障）引发的紧急情况 变化引发的紧急情况 过程引发的紧急情况

所有问题都有解决方案。 时间和经验表明，系统不仅会崩溃，而且会以人们以前无法想象的方式崩溃。 让更多的队友参与进来，寻求帮助，做任何你必须做的事情，但要快。 非常重要的是，一旦紧急情况得到缓解，不要忘记留出时间进行清理、撰写事件报告，以及... 吸取过去的教训。不要重蹈覆辙。 记录故障历史（中断），写下预防策略和战略。 提出大问题，甚至是不可能的问题： 如果......会怎样？ 鼓励主动测试

有效的事故管理是限制事故造成的干扰并尽快恢复正常业务运营的关键。 精心设计的事件管理流程的要素 递归责任分工：事件指挥官，业务工作：事故期间修改系统的唯一小组，沟通：事件响应工作组的公众形象，规划：支持行动 公认的指挥所：作战室或 IRC 实时事件状态文件 清晰、实时的事件指挥官交接。

事后总结是对事件、事件影响、为减轻或解决事件而采取的行动、根本原因以及为防止事件再次发生而采取的后续行动的书面记录。 事后总结目标：记录事件、充分了解所有促成事件的根本原因、采取有效的预防措施，降低再次发生的可能性和/或影响。

总结：

一个系统总成本的 40-90% 是在出生后产生的。 软件工程：侧重于设计和构建软件系统 网站可靠性工程：关注软件对象的整个生命周期，从开始、部署和运行、完善到最终和平退役。 SRE： SRE 是工程师。 SRE 专注于系统可靠性。 SRE 专注于运营建立在分布式计算系统之上的服务。 SRE 取得压倒性成功的关键在于其运行原则的性质（第 2 部分），例如，包含风险、服务水平目标、消除劳累、监控等。 SRE 在实践中不断发展。