diff --git a/Observability/summary.md b/Observability/summary.md
index f549c6cc..62f38ed6 100644
--- a/Observability/summary.md
+++ b/Observability/summary.md
@@ -1,5 +1,11 @@
 # 第九章：系统可观测性
+:::tip <a/>
+Troubleshooting any problem without the error log is like driving with your eyes closed.
 
+在没有错误日志的情况下诊断任何问题无异于闭眼开车。
+
+-- by Apache
+:::
 可观测性（Observability）一词最早出现在控制论领域，是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念，已有着几十年的历史。随着云原生时代的到来，2018 年，CNCF 率先将可观测性的概念引入 IT 领域，并称可观测性是云原生时代必须具备的能力。
 
 从生产所需到概念发声，加之包括 Google 在内的众多大厂一拥而上。至此，”可观测性“逐渐取代”监控“，成为云原生技术领域最热门的话题之一。
\ No newline at end of file
diff --git a/ServiceMesh/summary.md b/ServiceMesh/summary.md
index c16db455..f4a47ec3 100644
--- a/ServiceMesh/summary.md
+++ b/ServiceMesh/summary.md
@@ -1,5 +1,11 @@
 # 第九章：后微服务时代
 
+:::tip <a/>
+计算机科学中的所有问题都可以通过增加一个间接层来解决。如果不够，那就再加一层。
+
+-- by David Wheeler
+:::
+
 承载我们应用工作负载的形式已经从”物理机“过渡到”容器“，容器意味着创建（包括初始化）和销毁高度自动化，具备极强弹性。此时，基础设施的功能（服务发现、负载均衡、熔断限流、路由等）与业务代码的集成需要在低成本前提下保证相同的生命周期。物理机时代，基础设施功能添加到业务代码的最佳方式无疑是 SDK，而容器时代，基础设施的功能添加到业务代码的最佳方式变成了 Sidecar。Sidecar 模式解耦了基础设施和核心业务。
 
 Kubernetes 的崛起标志着微服务时代的新篇章，通过基础设施层解决分布式架构问题，微服务服务治理也开启了全新的进化，并衍生服务间通信的基础设施层 ServiceMesh。当非侵入性的 ServiceMesh 技术从萌芽走向成熟，当 Istio 横空出世，人们才惊觉：原来微服务也并非只有侵入性一种“玩法”。
diff --git a/architecture/arc.md b/architecture/arc.md
index 6b027e4b..37d66889 100644
--- a/architecture/arc.md
+++ b/architecture/arc.md
@@ -1,6 +1,6 @@
 # 1.6 以解决问题为目的推进架构演进
 
-理解云原生的代表技术之后，这一节，我们继续讨论如何把这些技术融入到到架构设计中，解决现实问题。
+理解云原生的代表技术之后，这一节，我们继续讨论如何把这些技术融入到到架构设计中，享受技术红利并解决现实问题。
 
 首先，没有完美应对所有变化的架构，技术架构很多时候是依据当时的技术条件来设计的，当制约因素改变的时候，技术架构也要相应变化。所以说好的架构是演进而来的，不是设计出来的，架构演进的目的一定是解决某一类问题，我们不妨从“解决问题”的角度出发，来聊一下云原生架构如何设计，如图 1-38 所示，传统架构向云原生架构的演进。
 
diff --git a/architecture/summary.md b/architecture/summary.md
index de493c98..89f76d2f 100644
--- a/architecture/summary.md
+++ b/architecture/summary.md
@@ -1,4 +1,10 @@
 # 第一章：云原生技术概论
+:::tip <a/>
+
+你知道比 Web 服务更难拓展的是什么吗? 寻找可以持续 20 年且仍然感觉良好的基础思想.
+
+-- by Shopify 创始人 Tobias Lütke
+:::
 
 云原生是一个很抽象的概念，解读云原生往往用抽象的解释解释抽象。话有些绕，但我想你能理解它的意思：用“不可变基础设施”、“声明式API”、“容器”这样的描述会让云原生的概念更加难以理解。
 
diff --git a/consensus/Paxos.md b/consensus/Paxos.md
index 1658d690..0cb75414 100644
--- a/consensus/Paxos.md
+++ b/consensus/Paxos.md
@@ -8,4 +8,4 @@
 
 提及分布式系统，大部分同学都能想到 Paxos。Paxos 是 Leslie Lamport 在 1990 提出的一种**基于消息传递且具有高度容错特性的协商共识算法**，也是当今分布式系统最重要的理论基础，几乎就是“共识”两个字的代名词。Paxos 于分布式系统而言，更有甚者说”没有 Paxos 的一堆机器叫做分布式；有 paxos 协同的一堆机器叫分布式系统“。
 
-Paxos 算法虽然重要，但是也因算法复杂而著名，围绕着该算法曾经发生过非常有趣的事情，这些也已成为人们津津乐道的一段轶事。直接切入 Paxos 算法本身未免望文生畏，我们就从这段轶事开始。
+Paxos 也因算法复杂而著名，围绕着该算法曾经发生过非常有趣的事情，这些也已成为人们津津乐道的一段轶事。直接切入 Paxos 算法本身未免望文生畏，我们就从这段轶事开始。
diff --git a/http/summary.md b/http/summary.md
index ed25eeb7..9394665d 100644
--- a/http/summary.md
+++ b/http/summary.md
@@ -1,5 +1,12 @@
 # 第二章: 构建”足够快“的网络服务
 
+:::tip <a/>
+
+永远不要低估一辆满载着磁带在高速公路上飞驰的旅行车的带宽。
+
+-- by《计算机网络》作者 Andrew S. Tanenbaum
+:::
+
 不少人的第一直觉是“网络路由跳点的数量、运营商线路的质量决定着线路带宽的大小、速率的高低”，由此断定网络因开发者不可控而无法插手。基本没错！不过呢，应用层的请求能否与传输协议提倡方式的匹配，对提升传输效率、构建足够快的网络目标也施加不小的影响，最容易体现这一点的便是各类网络优化技巧。
 
 相信大部分读者知晓一道经典的面试题“浏览器打开 url 到页面展现，中间发生了什么？”，面试官通常用这道题来考察候选者对网络知识掌握的广度和深度。那我们不妨就根据这道面试题的思路出发，通过解析 HTTP 类型的应用服务，逐步探究 DNS、HTTP、SSL、QUIC 和传输层等各个环节原理以及该如何一步步构建“足够快”的网络服务。
diff --git a/network/summary.md b/network/summary.md
index e42e00f0..ea224efe 100644
--- a/network/summary.md
+++ b/network/summary.md
@@ -1,5 +1,11 @@
 # 第三章：深入 Linux 内核网络
 
+:::tip <a/>
+只要你每天比别人多学一点，不超过三年你就能鹤立鸡群
+
+-- by 代码大全
+:::
+
 如果你是业务开发工程师，了解 HTTP 协议再加点 TCP 知识基本就够用了，但如果是 SRE/DevOps 或是性能优化工程师，需要做细致的监控和优化时，这些知识显然不够。
 
 云计算广泛应用的当下，传统的物理网络已经完成向虚拟网络 NFV 的转变，扁平的网络结构也在朝向基于 SDN 分层网络结构迈进。这些变化在降低成本和加强控制力的同时，也对系统承载的能力、对研发人员的技能要求也达到了史无前例的高度。那些过去不会成为瓶颈的网络基础部分，如今也面临着需要支持大规模、高并发数据处理的挑战。