共计 8335 个字符，预计需要花费 21 分钟才能阅读完成。
简介： 软件工程畛域存在一个共识：保护代码所破费的工夫要远多于写代码。而整个代码保护过程中，最触目惊心与动人心魄的局部，莫过于问题排查（Trouble-shooting）了。特地是那些须要 7×24 小时不间断保护在线业务的一线服务端程序员们，大大小小的问题排查线上救火早已成为粗茶淡饭，一不小心可能就吃成了自助餐 —— 竖着进躺着出，吃不了也兜不住。本文分享作者在服务端问题排查方面的一些教训，包含常见问题、排查流程、排查工具，结合实际我的项目中产生过的惨痛案例进行现身说法。
一 问题排查
1 常见问题
Know Your Enemy：知己知彼，百战不殆。
日常遇到的大部分问题，大抵能够归到如下几类：
- 逻辑缺点：e.g. NPE、死循环、边界状况未笼罩。
- 性能瓶颈：e.g. 接口 RT 陡增、吞吐率上不去。
- 内存异样：e.g. GC 卡顿、频繁 FGC、内存泄露、OOM
- 并发 / 分布式：e.g. 存在竞争条件、时钟不同步。
- 数据问题：e.g. 呈现脏数据、序列化失败。
- 平安问题：e.g. DDoS 攻打、数据泄露。
- 环境故障：e.g. 宿主机宕机、网络不通、丢包。
- 操作失误：e.g. 配置推错、删库跑路（危险动作，请勿尝试..）。
上述分类可能不太齐备和谨严，想传播的点是：你也能够积攒一个这样的 checklist，当遇到问题百思不得其解时，急躁过一遍，兴许很快就能对号入座。
2 排查流程
医生：小王你看，这个伤口的形态，像不像一朵沉没的白云？
病人：… 再不给我包扎止血，就要变成火烧云了。
疾速止血
问题排查的第一步，肯定是先把血止住，及时止损。如何疾速止血？常见形式包含：
- 公布期间开始报错，且公布前一切正常？啥也别管，先回滚再说，恢复正常后再缓缓排查。
- 利用曾经稳固运行很长一段时间，忽然开始呈现过程退出景象？很可能是内存泄露，默默上重启大法吧。
- 只有多数固定机器报错？试试隔离这部分机器（敞开流量入口）。
- 单用户流量突增导致服务不稳固？如果不是惹不起的金主爸爸，请怯懦推送限流规定。
- 上游依赖挂了导致服务雪崩？还想什么呢，降级预案走起。
保留现场
血止住了？那么祝贺你，至多故障影响不会再扩充了。卸下锅，先喘口气再说。下一步，就是要依据线索找出问题首恶了。作为一名排查新手，你须要有尽量保留现场的意识，例如：
- 隔离一两台机器：将这部分机器入口流量敞开，让它们静静期待你的检阅。
- Dump 利用快照：罕用的快照类型个别就是线程堆栈和堆内存映射。
- 所有机器都回滚了，咋办？别慌，如果你的利用监控运维体系足够健全，那么你还有多维度的历史数据能够回溯：利用日志、中间件日志、GC 日志、内核日志、Metrics 指标等。
定位起因
OK，排查线索也有了，接下来该怎么定位具体起因？这个环节会综合考验你的技术深度、业务相熟度和实操教训，因为起因往往都千奇百怪，须要 case by case 的追踪与剖析。这里给出几个排查方向上的倡议：
- 关联近期变更：90% 以上的线上问题都是由变更引发，这也是为什么团体平安生产的重点始终是在管控“变更”。所以，先不要急着否定（“必定不是我刚加的那行代码问题！”），置信统计学概率，好好 review 下近期的变更历史（从近至远）。
- 全链路追踪剖析：微服务和中台化流行的当下，一次业务申请不通过十个八个利用解决一遍，都不好意思说本人是写 Java 的。所以，不要只盯着本人的利用不放，你须要把排查 scope 放大到全链路。
- 还原事件工夫线：请把本人设想成福尔摩斯（柯南也行），摆在你背后的就是一个案发现场，你须要做的是把不同工夫点的所有事件线索都串起来，重建和还原整个案发过程。要置信，工夫戳是不会骗人的。
- 找到 Root Cause：排查问题多了你会发现，很多疑似起因往往只是另一个更深层次起因的表象后果之一。作为福尔摩斯，你最须要找到的是幕后凶手，而不是雇佣的杀人犯 —— 否则 TA 还会雇人再来一次。
- 尝试复现问题：含辛茹苦推导出了根因，也不要就急着开始修 bug 了。如果能够，最好能把问题稳固复现进去，这样才更有说服力。这里揭示一点：可千万别在生产环境干这事（除非你真的 know what you’re doing），否则搞不好就是二次挫伤（你：哈哈哈，你看，这把刀过后就是从这个角度捅进去的，轨迹齐全一样。用户：…）。
解决问题
最初，问题根因曾经找到，如何完满解决收尾？几个根本准则：
- 修复也是一种变更，须要通过残缺的回归测试、灰度公布；切忌火急火燎上线了 bugfix，后果引发更多的 bugs to fix。
- 修复公布后，肯定要做线上验证，并且放弃察看一段时间，确保是真的真的修复了。
- 最初，如果问题曾经回升到了故障这个水平，那就拉上大伙好好做个故障复盘吧。整个处理过程肯定还有晋升空间，你的经验教训对其他同学来说也是一次很好的输出和自查机会：幸福总是类似的，故障也是。
3 排查工具
手里只有锤子，那看什么都像钉子。作为工程师，你须要的是一整套工具箱。
问题排查其实就是一次继续观测利用行为的过程。为了确保不脱漏要害细节，你须要让本人的利用变得更“可观测（Observable）。
晋升利用可观测性有三大利器：日志（Logging）、监控（Metrics）、追踪（Tracing）。在我之前所做的我的项目中，这三块能力别离是由 SLS、Alimonitor / AliMetrics / Tsar、EagleEye 提供的，这里就不再开展形容了。
另外也很举荐 Arthas 这个工具，十分实用和棘手，置信很多同学都曾经用过。
二 系统优化
只学会了问题排查还远远不够（当然技能必须点满，shit always happen），再纯熟也只是治标不治本。如果想从本源上躲避问题，必须从零碎自身登程：依照性能、稳定性和可维护性三个方向，继续优化你的零碎实现，扼杀问题于摇篮之中，让本人每天都能睡个安稳觉。
老板：既要快，又要稳，还要好。哦，工资的事你别放心，下个月肯定能收回来。
系统优化的三个根本方向：性能（Performance）、稳定性（Stability）、可维护性（Maintainability）。三者之间并不是齐全独立的，而是存在着简单的相互作用关系，有时甚至会此消彼长。
最优良的软件系统，并非要把这三个方向都做到极致，而是会依据本人理论的业务需要和场景正当取舍，在这三者之间达到一个综合最优的动态平衡状态，让各方面都能做到足够好即可。
所以，优化不只是一门迷信，也是一门艺术。
1 性能优化
问：要跑出最快的圈速，是车手重要，还是赛车重要？
答：全都重要。
没有哪个男人会不喜爱高性能跑车，也没有哪个女人会心愿在看李佳琦直播时忽然卡顿。
性能，是各行各业工程师们独特谋求的终极浪漫。
性能指标
指标（Indicators）是掂量一件事物好坏的迷信量化伎俩。对于性能而言，个别会应用如下指标评估：
- 吞吐率（Throughput）：零碎单位工夫内能解决的工作负载，例如：在线 Web 零碎 – QPS/TPS，离线数据分析系统 – 每秒解决的数据量。
- 响应工夫（Response Time）：以 Web 申请解决为例，响应工夫（RT）即申请从收回到收到的往返工夫，个别会由网络传输提早、排队提早和理论解决耗时几个局部独特组成。
- 可伸缩性（Scalability）：零碎通过减少机器资源（垂直 / 程度）来承载更多工作负载的能力；投入产出比越高（现实状况是线性伸缩），则阐明零碎的可伸缩性越好。
此外，同一个零碎的吞吐率与响应工夫，个别还会存在如下关联关系：吞吐率小于某个临界值时，响应工夫简直不变；一旦超出这个临界值，零碎将进入超载状态（overloaded），响应工夫开始线性增长。对于一个有稳定性要求的零碎，须要在做性能压测和容量布局时充分考虑这个临界值的大小。
注：其实按更谨严的说法，性能就是单指一个零碎有多“快”；上述局部指标并不纯正只代表零碎快慢，但也都与快慢非亲非故。
性能剖析
今人有句老话，If you can’t measure it, you can’t improve It.
要优化一个零碎的性能（例如 Web 申请响应工夫），你必须首先精确地测量和剖析出，以后零碎的性能到底差在哪：是申请解析不够快，还是查问 DB 太慢？如果是后者，那又是扫描数据条目阶段太慢，还是返回后果集太慢？或者会不会只是利用与 DB 之间的网络提早太大？
任何简单申请的处理过程，最终都能够拆解出一系列并行 / 串行的原子操作。如果只是逮住哪个就去优化哪个，显然效率不会太高（除非你运气爆棚）。更正当的做法，应该是保持 2/8 准则：优先剖析和优化零碎瓶颈，即以后对系统性能影响最大的原子操作；他们很可能就是 ROI 最高的优化点。
具体该如何去量化剖析性能？这里列出了一些工具参考：
- 零碎层面：tsar、top、iostat、vmstat
- 网络层面：iftop、tcpdump、wireshark
- 数据库层面：SQL explain、CloudDBA
- 利用代码层面：JProfiler、Arthas、jstack
其中很多工具也是问题排查时罕用的诊断工具；毕竟，无论是性能剖析还是诊断剖析，目标都是去了解一个零碎和他所处的环境，所须要做的事件都是类似的。
优化准则
你应该做的：下面曾经提了很多，这里再补充一点：性能优化与做性能需要一样，都是为业务服务的，因而优化时千万不要忙着自嗨，肯定要联合指标需要和利用场景 —— 兴许这块你想做的优化，压根线上就碰不到；兴许那块很难做的优化，能够依据流量特色做非通用的定制优化。
你不应该做的：即陈词滥调的提前优化（Premature-optimization）与适度优化（Over-optimization）—— 通常而言（并不相对），性能优化都不是收费的午餐，优化做的越多，往往可维护性也会越差。
优化伎俩
罕用的性能优化伎俩有哪些？我这里总结了 8 个套路（最初 1 个是小霸王多合一汇总套路）。
1）简化
有些事，你能够抉择不做。
- 业务层面：e.g. 流程精简、需要简化。
- 编码层面：e.g. 循环内缩小高开销操作。
- 架构层面：e.g. 缩小没必要的形象 / 分层。
- 数据层面：e.g. 数据荡涤、提取、聚合。
2）并行
有些事，你能够找人一起做。
形式：单机并行（多线程）、多机并行（分布式）。
长处：充分利用机器资源（多核、集群）。
毛病：同步开销、线程开销、数据歪斜。
- 同步优化：乐观锁、细粒度锁、无锁。
- 线程代替（如协程：Java WISP、Go routines、Kotlin coroutines）。
- 数据歪斜：负载平衡（Hash / RR / 动静）。
3）异步
有些事，你能够撒手，不必死等。
形式：音讯队列 + 工作线程 + 告诉机制。
长处：晋升吞吐率、组件解耦、削峰填谷。
毛病：排队提早（队列积压）。
- 防止适度积压：Back-pressure（Reactive 思维）。
4）批量
有些事，你能够合起来一起做。
形式：屡次繁多操作 → 合并为单次批量操作。
案例：TCP Nagel 算法；DB 的批量读写接口。
长处：防止单次操作的固有开销，均摊后总开销更低。
毛病：期待提早 + 聚合提早。
- 缩小期待提早：Timeout 触发提交，管制提早下限。
5）工夫空间调换
游戏的实质：要么有闲，要么有钱。
- 空间换工夫：防止反复计算、拉近传输间隔、分流缩小压力。
案例：缓存、CDN、索引、只读正本（replication）。
- 工夫换空间：有时候也能达到“更快”的成果（数据量缩小 → 传输工夫缩小）。
案例：数据压缩（HTTP/2 头部压缩、Bitmap）。
6）数据结构与算法优化
程序 = 数据结构 + 算法
- 多理解一些“冷门”的数据结构：Skip list、Bloom filter、Time Wheel 等。
- 一些“简略”的算法思维：递归、分治、贪婪、动静布局。
7）池化 & 部分化
共享经济 & 小区超市
池化（Pooling）：缩小资源创立和销毁开销。
- 案例：线程池、内存池、DB 连接池、Socket 连接池。
部分化（Localization）：防止共享资源竞争开销。
- 案例：TLB（ThreadLocalBuffer）、多级缓存（本地部分缓存 -> 共享全局缓存）。
8）更多优化伎俩
- 降级红利：内核、JRE、依赖库、协定。
- 调参巨匠：配置、JVM、内核、网卡。
- SQL 优化：索引、SELECT *、LIMIT 1。
- 业务特色定制优化：e.g. 凌晨业务低峰期做日志轮转。
- Hybrid 思维（长处联合）：JDK sort() 实现、Weex/RN。
2 稳定性优化
稳住，咱们能赢。—— by [0 杀 10 死] 正在期待复活的鲁班七号
维持稳定性是咱们程序员每天都要思考和探讨的小事。
什么样的零碎才算稳固？我本人写了个小工具，本地跑跑素来没出过问题，算稳固吗？淘宝网站几千人保护，但双十一零点还是常常下单失败，所以它不稳固喽？
稳固是绝对的，业务规模越大、场景越简单，零碎越容易呈现不稳固，且带来的影响也越重大。
掂量指标
不同业务所提供的服务类型千差万别，如何用统一的指标去掂量零碎稳定性？规范做法是定义服务的可用性（Availability）：只有对用户而言服务“可用”，那就认为零碎以后是稳固的；否则就是不稳固。用这样的形式，采集和汇总后就能失去服务总的可用 / 不可用比例（服务时长 or 服务次数），以此来监测和量化一个零碎的稳定性。
可是，通过什么来定义某个服务以后是否可用呢？这一点的确跟业务相干，但大部分同类业务都能够用相似的形式去定义。例如，对于个别的 Web 网站，咱们能够按如下形式去定义服务是否可用：API 申请都返回胜利，且页面总加载工夫 < 3 秒。
对于阿里云对外提供的云产品而言，服务可用性是一个更加须要分外器重并继续晋升的指标：阿里云上的很多用户会同时应用多款云产品，其中任何一款产品呈现可用性问题，都会间接被用户的用户感知和放大。所以，越是底层的基础设施，可用性要求就越高。对于可用性的更多细节指标和概念（SLI / SLO / SLA），可进一步参考云智能 SLA 理解。
可用性测量
有了上述可用性指标定义后，接下来该如何去精确测量零碎的可用性体现？个别有如下两种形式。
1）探针模仿
从客户端侧，模仿用户的调用行为。
- 长处：数据实在（客户端角度）
- 毛病：数据不全面（繁多客户数据）
2）服务端采集
从服务端侧，间接剖析日志和数据。
- 长处：笼罩所有调用数据。
- 毛病：缺失客户端链路数据。
对可用性数据要求较高的零碎，也能够同时使用上述两种形式，倡议联合你的业务场景综合评估抉择。
优化准则
你应该做的：关注 RT 的数据分布（如：p50/p99/p999 分位点），而不是平均值（mean）—— 平均值并没有太大意义，更应该去关注你那 1%、0.1% 用户的精确感触。
你不应该做的：不要尝试承诺和优化可用性到 100% —— 一方面是无奈实现，存在太多主观不可控因素；另一方面也没有意义，客户简直关注不到 0.001% 的可用性差异。
优化伎俩
罕用的稳定性优化伎俩有哪些？这里也总结了 8 个套路：
1）防止单点
父母：一个人在外漂了这么多年，也该找集体稳定下来了。
如何防止？
- 集群部署
- 数据正本
- 多机房容灾
只堆量不够，还须要具备故障转移能力（Failover）。
- 接入层：DNS、VipServer、SLB。
- 服务层：服务发现 + 健康检查 + 剔除机制。
- 应用层：无状态设计（Stateless），便于随时和疾速切换。
2）流控 / 限流
计划生育、上学调剂、车牌限号、景区限行 … 人生处处被流控。
- 类型：QPS 流控、并发度流控。
- 工具：RateLimiter、信号量、Sentinel。
- 粒度：全局、用户级、接口级。
- 热点流控：防止意料之外的突增流量。
3）熔断
上午买的股票熔断，早晨家里保险丝熔断 … 淡定，及时止损而已。
- 目标：避免连锁故障（雪崩效应）。
- 工具：Hystrix、Failsafe、Resilience4j。
- 性能：主动绕开异样服务并检测复原状态。
- 流程：敞开 → 关上 → 半开。
4）降级
没工夫做饭了，明天就吃外卖吧 … 对于衰弱问题，还是得少一点降级。
触发起因：流控、熔断、负载过高。
常见降级形式：
- 敞开非核心性能：进行利用日志打印
- 就义数据时效性：返回缓存中旧数据
- 就义数据精确性：升高数据采样频率
5）超时 / 重试
钉钉不回怎么办？每 10 分钟 ping 一次，超过 1 小时打电话。
超时：防止调用端陷入永恒阻塞。
- 超时工夫设置：全链路自上而下布局
- Timeout vs. Deadline：应用相对工夫会更好
重试：确保可重试操作的幂等性。
- 音讯去重
- 异步重试
- 指数退却
6）资源设限
双 11 如何防止女友败家？提前把本人信用卡额度调低。
- 目标：避免资源被异样流量耗尽
- 资源类型：线程、队列、DB 连贯
- 设限形式：资源池化、有界队列
- 超限解决：返回 ServiceUnavailable / QuotaExceeded
7）资源隔离
双 12 女友还是要败家？得嘞刷你自个的卡吧，别动我的。
- 目标：避免资源被局部异样流量耗尽；为 VIP 客户提供服务质量保障（QoS）。
- 隔离形式：队列划分、独立集群；留神解决优先级和资源分配比例。
8）平安生产
女友哭着说再让我最初剁一次手吧？平安第一，宁愿疼爱也不要肉疼。
程序动态性：开关、配置、热降级。
- Switch：类型平安；侵入性小。
审核机制：代码 Review、公布审批。
灰度公布；分批部署；回滚预案。
- DUCT：主动 / 手动调整 HSF 节点权重。
可维护性优化
前人栽树，后人乘凉。
前人挖坑，前人凉凉。
保护的英文是 maintain，也能翻译成：维持、供应。所以软件维护能有多重要？它就是软件系统的呼吸机和食物管道，维持软件生命的必要供应。
零碎开发实现上线，不过只是把它“生”下来而已。软件真正能施展多大价值，看的是交付后继续的价值兑现过程 —— 是一直茁壮成长，为用户发光发热？还是缓缓腐化，逐步被用户所忘记？这并不是取决于它当下刹时是否足够优良（性能）和靠谱（稳固），而是取决于将来 —— 是否在一直变动的市场环境、客户需要和人为因素中，始终保持足够优良和靠谱，并且能越来越好。
相比性能和稳定性而言，可维护性所体现的价值往往是最久远、但也最难在短期内可兑现的，因而很多软件我的项目都抉择了在后期就义可维护性。这样决策带来的结果，就跟架构设计一样，是简直无奈（或者须要十分高的老本）去补救和挽回的。太多的软件我的项目，就是因为越来越不可保护（代码改不动、bug 修不完、feature 加不上），最初只能缓缓沦落为一个谁都不想碰的遗留我的项目。
掂量指标
相比性能和稳定性而言，可维护性的确不太好量化（艺术成分 > 迷信成分）。这里我选取了几个偏定性分析的指标：
1）复杂度（Complexity）：是否复杂度可控？
- 编码：简洁度、命名一致性、代码行数等。
- 架构：组件耦合度、档次清晰度、职责单一性等。
2）可扩展性（Extensibility）：是否易于变更？
- 须要变更代码或配置时，是否简略优雅、不易出错。
3）可运维性（Operability）：是否不便运维？
- 日志、监控是否欠缺；部署、扩容是否容易。
重要性
这里给了几个观点，进一步强调可维护性的重要性。
- 软件生命周期：保护周期 >> 开发周期。
- 破窗效应、熵增定律：可维护性会趋向于越来越差。
- 遗留零碎的危害：了解难度，批改老本，变更危险；陷入一直踩坑、填坑、又挖坑的循环。
优化准则
你应该做的：遵循 KISS 准则、DRY 准则、各种代码可读性和架构设计准则等。
你不应该做的：引入过多临时性、Hack 代码；性能 Work 就 OK，欠一堆技术债（进去混总是要还的）。
优化伎俩
罕用的可维护性优化伎俩有哪些？这里我总结了 4 个套路：
1）编码标准
无规矩，不成方圆。
- 编码：举荐《Java 开发手册》，另外也举荐 The Art of Readable Code 这本书。
- 日志：无盲点、无冗余、TraceID。
- 测试：代码覆盖度、自动化回归。
2）代码重构
别灰心，代码还有救。
- 何时重构：任何时候代码中嗅到坏滋味（bad smell）。
- 重构节奏：小步迭代、回归验证。
- 重构 vs. 重写：须要综合思考老本、危险、并行版本保护等因素。
- 举荐浏览：Refactoring: Improving the Design of Existing Code。
3）数据驱动
置信数据的力量。
- 零碎数据：监控笼罩、Metrics 采集等，对于了解零碎、排查问题至关重要。
- 业务数据：一致性校验、旧数据清理等；要置信，数据往往比代码要活得更久。
4）技术演进
技术是第一生产力。
- 死守阵地 or 紧跟潮流? 须要综合评估危险、生产力、学习老本。
- 以后方向：微服务化、容器化。
三 结语
Truth lies underneath the skin – 真谛永远暗藏在表象底下。
对，就在这句话底下。
欢送各位技术同路人退出阿里云云原生利用研发平台 EMAS 团队，咱们专一于宽泛的云原生技术（Backend as a Service、Serverless、DevOps、低代码平台等），致力于为企业、开发者提供一站式的利用研发治理服务，内推中转：pengqun.pq # alibaba-inc.com，有信必回。
