前言
从 2020 年 10 月份以来，肩负数据库运维工作，已经快 1 年半了。
还记得第一次去客户现场做运维，是因为我的另一个做这块的同事要结婚，才把这个挑子换到我肩上的。那会是去广州，我同事替我在腾讯云复现客户现场的环境，并一个字一个字的写好了文档，提前教我操作，并叮嘱各种注意事项。这次由于要写笔记才回忆起来，还是蛮暖心的，原来是有这么个人曾经这么细心的教过我！（为什么我的记忆里很少留下这种回忆呢？）
正文
一、杀鸡不用宰牛刀
运维多了，有些问题一看就明白了怎么回事了，很多问题重启都能解决（虽然感觉有点不负责），有些问题通过最粗糙的日志就能知道问题在哪（可以理解成 main 日志，也即程序入口日志）。
找到日志后，在 linux 上就是用 vim 命令从日志文件里找关键词了。
二、重视系统周边
一般一个大型的应用，都不止一个服务，每一个服务都有对应的日志。例如我们的分布式数据库，底层的文件系统使用的就是 hadoop。当主程序找不着问题时，就应该去周遭最接近的服务找，比如 hadoop 的 namenode 日志 以及 datanode 日志。
步骤梳理（持续更新）：
- 检查各个服务的运行状态，最典型的就是服务挂掉了，找到之后检查对应服务的报错日志。
- 检查主程序日志，关键词（例如
Exception找异常，insert找插入数据的 SQL）定位关键位置。 - 查看最接近的周遭服务的日志（我们这里就是 hadoop），也是关键词定位。
- 本地模拟现场环境（既然是咱们的程序，这个环境的搭建，就必须得学会的），复现出问题之后，找写程序的人。
原则：我们可以不解决问题，但一定要能定位到最接近的问题，我们做开发的可以把商务问题抛出去，我们做软件的可以把硬件问题抛出去，我们做底层的可以把上层应用的问题跑出去，我们做运维的可以把程序问题抛出去……这些都是对的，但本职要做好：定位出问题离自己最近的可能位置。
