生产事故
快来分享你的内容吧～
生产紧急情况怎么处理？
<html> <head></head> <body> <div class="content ql-editor"> <p>大家好，我是晨光。最近这一两周，比较少冒泡，主要原因是工作略忙，其次是稍微放空了一下，所以最近也没有写文，有同学说我是“年更博主”，这个描述并不准确（狗头）</p> <p><br></p> <p>哈哈，废话不多说，下面进入正题。主要是想和大家聊聊工作中遇到的一些比较紧急的问题怎么处理。当然，肯定都是生产上发生的问题，要么是用户遇到的，要么是老板发现的。接下来将通过下面三点来给大家讲一讲我遇到问题是怎么处理的。</p> <p><br></p> <p>1、处理事情的先后顺序</p> <p>2、遇到事情不要慌</p> <p>3、定位问题并给出解决方案</p> <p>4、问题复盘</p> <p><br></p> <p><strong>一、处理事情的先后顺序</strong></p> <p><br></p> <p>正常情况下，手头肯定都是有一个或者多个任务，并行处理中。要么是写 bug，要么是改 bug，但是总会有让你查 bug 的情况。</p> <p>查 bug 要么是事件，要么就是生产问题，先判断是否紧急，如果拿不准可以问让你查问题的人。得到优先级之后，根据自己手头的工作，做个优先级排序。</p> <p><br></p> <p>1、重要且紧急</p> <p>2、不重要但紧急</p> <p>3、重要但不紧急</p> <p>4、不重要也不紧急</p> <p><br></p> <p>一般情况，优先处理 1 ，重要且紧急的任务，2 和 3 可以自己调整顺序</p> <p>不过一般我会先处理 2，因为紧急可能阻塞了别的同事工作，算是按照时间顺序来排。</p> <p>3 可能是一个持续在做的事情，一时半会儿搞不完，所以紧急度不高但要持续做。</p> <p>4 就是所有的任务都完成了，再来处理它😌优先级最低。</p> <p><br></p> <p><strong>二、遇到事情不要慌</strong></p> <p><br></p> <p>前两天，正在如火如荼的改 bug 中，突然丢过来一个生产上展示的问题。由于我还没吃午饭，所以先问了一句，紧急不？对方回复说，大老板发现的，急！</p> <p><br></p> <p>那我没辙了，只能先查问题，吃不了饭，连去卫生间都没时间。</p> <p>但当时我肯定考虑不到那么多，因为内心慌的一逼。但是越是慌乱的时候，越是需要冷静！</p> <p><br></p> <p>但是就有种很奇怪的现象，我一个人查的时候，内心慌，然后过来了一堆老板站我旁边的时候，反而内心不慌了！虽然心里不慌了，但是身体上慌😭因为无意识的发现我手抖了，不明显，轻微抖……（别嘲笑我）</p> <p><br></p> <p>内心不慌了，可能有种感觉就是，老板们比我还急，所以我不用急，慢慢来😂</p> <p><br></p> <p>最终查到的问题不算 bug，可能是产品逻辑缺失，技术改造的问题等，最终我还是改了代码兼容了一下😮💨</p> <p><br></p> <p>这件事结束后，和同事聊当时我的心里状态，她说非常理解这种感受，所以我猜大家是不是都遇到过这种情况(─.─|||</p> <p><br></p> <p>巴拉巴拉说了一大堆，主要是想和大家说，越是有领导盯着越不要慌。之前有同事查问题的时候，CTO 站他背后看他改代码！</p> <p><br></p> <p>这种时候要是你思路不清晰，慌乱不安，那你的职业生涯估计也到头了。</p> <p><br></p> <p>当然，这不是好事情，但是你近距离的可以接触领导，🌚给你表现机会，也是一种机会，哈哈哈！凡事都有两面性，不过我说的这种表现机会，bug 最好不要是你写的，不然就是公开处刑了👀</p> <p><br></p> <p><strong>三、定位问题并给出解决方案</strong></p> <p><br></p> <p>根据问题现象</p> <p>1、代码逻辑在哪</p> <p>2、下发数据是否正确</p> <p>3、调试，逻辑是否有误</p> <p>4、问题原因，给出结论</p> <p>5、怎么修复，给出方案</p> <p>上面 5 个步骤应该比较全了，按照这 5 步，基本都能定位到问题的原因。</p> <p><br></p> <p>1 需要对代码有一些熟悉度才能快速定位，要么就是有关键字可以在代码中搜索。</p> <p>2 根据找到的代码，查看服务下发的字段信息，可能是字段下发的不正确，那么就能把问题丢给后端</p> <p>3 如果服务下发没问题，那么问题大概率在前端，需要调试代码，这种时候最奔溃的就是本地环境，要么是内存不足了，要么是需要重新 npm install……就很抓马。。记得要冷静！因为有人比你还着急🤭</p> <p>4 通过调试，可以找到代码的原因，调整逻辑，可能是 if 没走进去？原因就一目了然了。</p> <p>5 原因知晓了，修复起来就很容易了。</p> <p><br></p> <p><strong>四、问题复盘</strong></p> <p><br></p> <p>问题的解决过程很快，但是如何保证同类型的问题不再发生，不管是开发 bug，还是产品逻辑，又或者是各种历史问题，如何能够完美的解决，或者有个最优的解决方案，这是个重要的问题。</p> <p><br></p> <p>对于我们自己成长来说，遇到比较具有代表性的问题，可以自己写个文档进行总结一下，类似事件回顾。</p> <p>可以有自己的复盘模板，一般情况，我会通过下面几点来复盘。</p> <p>1、问题现象</p> <p>2、问题原因</p> <p>3、解决方案</p> <p>通过上面 3 点，可以大概记录，大家也可以自己再细分小点。</p> <p><br></p> <p>以上，全文完，希望大家都不会遇到生产上的紧急突发事件，假如遇到了也不要怕，可以按照上面的步骤定位排查。最后，希望大家都能升职加薪，冲冲冲！</p> </div> </body> </html>