某年某月某日的某一天，我被紧急拉入一个微信群组里。
领导告诉我，客户的一个软件（MySQL）无法启动，需要研发支援解决。这个项目，我从来没有跟过。现在出现了问题，领导是拉我来救火的。
简单交代一下背景。
我们公司有研发部、产品部、生产部等等部门。一般来说，产品部负责与客户直接对接，完成诸如安装、演示、升级等功能。我司的产品部，（在我们软件部的耳濡目染下），技术水平还不错，Linux玩得很溜。一般的技术他们都能解决。也就是说，转到研发部的问题，都会稍微有一点“棘手”。
因为是直属领导下派，没有任何推诿，放下其他工作，直接接手。
接下来，看一下我当时的调试环境。
客户电脑使用的是公司内部网络，无法实施远程连接调试。
这就比较麻烦。一般来说，有问题远程连接一下，就能比较快速地解决和定位问题。现在只能依靠对方工程师手敲代码，返回结果。不仅效率低下，而且不确定性增多：对方工程师，可能是技术高手，也可能是技术小白。
沟通群里有七、八个人，包括我的领导、产品部同事、对方工程师、对方的领导等。所有的指令，都在大家的监控之下。所以说，指令必须是有目的的、精确的。任何一点差错，都会增加沟通的成本，拉低客户心中我方的技术水平和公司形象。
如何正确地装逼成为重中之重。
我深吸一口气，开始我的装逼之旅。
第一步，一个明知故问的重要问题：“做了什么改动？”
得到的回答，不出所料，程序员听了一千遍的：“什么都没改。”
没有关系。不管对方回答什么，基本不影响我们的调试过程。因为有时候，即使改动了什么，也是因为引发了别的问题才导致出现问题。
但是这句话是一定要问的。这句话的底层意思是：“我司的产品都经过严格测试没有任何质量问题的，一定是做了什么改动才导致现在的问题。”
开天辟地“定调”第一步，完成。
第二步，发送明确的指令给对方，等待对方的结果。
这一步，有几个点要注意：
1、能用指令描述的，不要用文字描述。
比如，不要说“打开xx文件，让我看下里面的内容”，直接发指令“cat 文件”，对方照着写就行。
再比如，需要较高权限的操作，“不要说先切换到root，再执行指令”，直接发指令“sudo 指令”。
因为不清楚对方的技术水平，所以步骤尽量傻瓜化。
2、指令一定要绝对正确。特别是路径、参数，不要出现错误。可以的话，先在自己的电脑上实验一下。
3、能用一条指令解决的，不要分成两个指令。这样会增加步骤，提高沟通成本。比如，使用绝对路径，而不要先“cd 目录；ls”，直接“ls 目录”。
4、尽量让对方拍照回复。如果出现拼写错误或者其他低级错误，能及时发现。
具体调试过程这里不写。其实问题并不难，只是比较少见，某度也搜索不到。
反正在一步一步的排查之下，问题解决了。
第三步，总结陈词。
当我想要松口气的时候，对方领导，在群里发了这样一个消息：
@我 @对方工程师 请分析一下是什么原因导致的？@我方产品同事 以后的产品还会不会出现同样的问题？
虽然我心里知道，这个问题是升级导致的，但是直接这样说的话，会很有问题：如果是我方升级的，对我方形象和人员不利；如果是对方升级的，对对方工程师不利。大家都是干活的，要惺惺相惜，不能落井下石。
我斟酌了一下，这样回复的：
我看到的现象是：配置文件更改导致无法启动。怀疑是在升级软件的过程中，操作人员/操作系统出于系统保护的目的，仅升级了核心程序（mysqld运行没有问题），而对配置文件进行了改名、备份（而不是删除）。恢复配置文件后启动成功。
轻描淡写地说明问题原因和解决方法（也显得自己很牛），着重强调操作人员成功的地方，说明操作人员的好意，同时不排除是系统的问题。
对方没有再继续追问。
救火成功。
总结：
1、能当救火队，是你的价值所在。每一次救火，都是一次展示专业度的机会。抓住机会，好好表现。
2、不要相信任何人的“什么都没改”。
END
