如何线上解决问题

线上系统为何经常出错？数据库为何屡遭黑手？业务调用为何频频失败？连环异常堆栈案，究竟是哪次调用所为？ 数百台服务器意外雪崩背后又隐藏着什么？是软件的扭曲还是硬件的沦丧？

● 前言
由于代码 bug(本身或三方)、环境、硬件等原因，线上服务出现故障/问题几乎不可避免。例如，常见的现象包括请求超时,卡顿,死机等等。
作为一名开发人员,除了写好代码,排查解决线上的问题也是必须掌握的生存技能. 在生产环境中,是很难进行debug的,常常只能依靠一些工具/命令/平台来获取程序运行时的信息,包括但不限于log(异常堆栈),监控平台的输出,Jvm运行情况等等.
当你找到并解决了一个别人没搞定的问题时,会有巨大的成就感.就有人这么问过我 "你是怎么想到的?你是怎么定位到问题的? " 我一般只能说 "很简单/全看脸/靠经验",这里都会觉得排查问题要考经验,但是很难解释清楚到底是什么样的经验帮助你排查出了问题, 我这里总结一下,靠经验指的是 "依赖基础知识和对系统环境的了解,运用各种工具得出的数据进行总结分析来定位问题和解决问题"的过程, 有的人会有误区,认为靠经验是把所有碰到的问题以及解决方法 全部记录下来,再碰到问题时就能对号入座了 我认为这是绝对错误的做法, 在我们动手解决问题之前，第一步是要知道What（是什么），然后是Why（为什么），最后才是How（怎么做）。抛弃前两步直接上手How 只会事倍功半
● 常见问题
○ 环境异常
常见的 cpu负载过高,硬盘满了,I/O满了,带宽满了(连接数满了),可用内存不够等等.这些问题如果是在Linux系统下可以通过 top(cpu)、free(内存)、df(磁盘)、dstat(网络流量)、pstack、vmstat、strace(底层系统调用) 等工具获取系统异常现象数据。
○ 业务异常
调用服务api超时,线程死锁,多线程并发问题,频繁gc,连接泄露等等
● 方法论
排查问题就像柯南破案一样,不停分析线索,推理的过程.那么在进行推理之前,我们先明确几个事情:

1. 世界是唯物的,计算机是一门科学,这里只有0和1,是和否,这里发生的问题只有必然没有偶然,所有问题都如墨菲定律所言的一样,我们玩的是本格推理,玄学的思路和解决方案我们即不讨论也不接受的
2. 系统出现异常是很正常的事,现在一个不算复杂的系统上,一次用户请求可能要经过发送请求，DNS解析，运营商网络，负载均衡，服务器，虚拟机（容器），视业务逻辑的复杂程度可能还要调用组件，缓存，存储和数据库等。每个环节都可能出现问题，有的组件又是分布式的，大大增加的排查问题的难度，所以出现问题后不要慌，保持好的心态。
3. 还原恢复是首要目的,找到问题并解决是次要的
   ● 流程
   ○ 收集信息
   ■ 了解现场情况,评估影响范围 先评估出问题的影响范围,是全网还是某个账户,是目标的网络访问有故障还是整条链路都不通了
   ● 问题的表现是什么? 无响应? 报错?
   ● 问题是什么时候发现的?
   ● 是否可以重现?
   ● 有没有规律
   ● 系统最近的一次更新时间和内容(包括但不限于代码,配置,网络,服务器等)
   ● 受影响的用户范围
   ● 监控反馈
   ● 看日志
   ■ 应用的检查
   ● 最近是否有更新(程序/配置)
   ● 软硬件是否有变更
   ● 日志里是否有异常
   ● 重启是否生效
   ■ 数据库检查
   ● 数据库配置是否有变更
   ● telnet端口是否畅通
   ● show processlist
   ● sql在本地和远程执行都正常吗
   ■ 硬件环境
   ● 硬盘剩余空间
   ● top / free
   ● ping / telnet 是否有丢包
   ● traceroute -l
   ● 时区字符集文件句柄数等参数
   ● 监控系统
   ■ 总之就是尽可能的收集有效信息,然后去排除分析:
   ● 通过变更记录来定位问题,很多问题是因为新版本上线,变更造成的
   ● 通过影响用户,复现问题,能稳定复现的问题排查就很容易了
   ● 查看日志 数据记录,定位问题
   ● 如果没办法从日志里面直接发现异常,那么只能通过特定的工具 去监视应用到底在干什么
   ● 原则就是 找出系统正在执行“什么”，询问系统“为什么”执行这些操作，以及系统的资源都被用在了“哪里”可以帮助你了解系统为什么出错。这个过程中尤其要注意并不是所有的证据都是可信的,要有注意甄别真假
   ○ 恢复服务
   ■ 摘机 在不影响整体业务的情况把出问题的n个服务/机器 下线
   ■ 重启 专治各种cpu/内存/线程池爆满
   ■ 回滚 回滚到出问题之前的状态(程序/配置)
   ■ 降级 比如:Nginx修改权重
   ○ 保留现场
   ■ 运行日志 出问题期间的Log文件
   ■ 运行状态 比如Jvm的线程dump
   ■ 保留现场与恢复服务看实际情况 很难分先后
   ○ 排查问题
   ■ 看清本质
   ● 看到一件现象或一件事情，要看实质而不只是表面的东西,排查问题也一样切忌先入为主，有时候你觉得极其简单，看似非常不可能发生的事情，可能就是原因，不要轻易的排除掉某项原因。
   ■ 定位方向
   ● 从大到小 先查宏观的问题再查细节
   ● 从上到下 从异常发生的入口逐步深入想下
   ● 并不是所有问题的适用这样的规律,由量变产生质变的问题就只能微观分析,再宏观诊断
   ● 这个阶段一定耐心细心
   ○ 验证
   ■ 开发/测试环境验证
   ■ 生产环境的A/B测试
   ● 归档记录
   ○ 记录问题 针对具体问题的反思,应该在代码,组件,环境中做出那些调整,避免再出现同类型的问题
   ○ 记录排查解决问题的过程 对过程的反思,我们的思路,使用的工具,是否都正确,能否更高效