有些人就是想知道你再工作中遇到过哪些印象最深刻的问题，由此来了解在你的抗挫折能力。在工作中，要说遇到问题，首先公司的流程已经尽可能的把可能出现的问题都规避掉了。
减少出问题的可能
问题本身并不好，能少遇到肯定要少遇到了。在目前的开发流程中：
- 需求到来之后，首先进行需求分析，然后开发方案设计，设计不是写代码，而是准备写代码的逻辑。这个要和组员一起讨论，最终给组长看看，组长有时候会看，有时候太忙可能不看，但是会大致问一些怎么设计的。
多人讨论，避免了一个人思考的局限性，减少遗忘掉一些条件的可能性，再由组长过一下，方案设计层很少会遇到问题，如果设计的问题没人发现，那就是追责到好多人。
- 方案确定以后，建开发文档，标记对应的需求Jira，开发Jira，然后开始写代码。所有自己写的服务，接口功能都要自测
自测这一步，在部分程度上减少了代码出问题的可能性，自测要跑通，代表在正常的条件下功能是能正常运行的。这里代表着只可能出现意外的问题，自测也只是减少代码出bug的可能性。
- 测试人员在测试环境部署开发分支，测试人员来测，每个人的开发Jira都要有对应的测试Jira，并且写上测试人员要测试的功能，什么情况下是正确的，什么情况下是错误的。
测试人员完全不知道我们的代码，这一步是黑盒测试，他们测试的是多个系统之间的关联关系，一般能完全走通，不出现错误之后，才能完成测试任务，这一步又减少了问题。
- 接口联调，测试完之后，不同系统之间，部署到预生产环境，测试哪一步已经进行了联调。这个时候大家都会再看看自己的调用情况与被调用情况。确保没有问题
这一步又有很多人参与确认，又减少了问题
- 上线，如果上线失败，记录要回滚的版本号。上线前及上线后1~2天，查看日志的情况，如果出现问题，及时修复与回滚。并且在开发的代码中，异常的情况会发送邮件和短信日志。而且异常都有完整的调用链追踪，报错大盘等内部分析工具。
上线时可能遇到的问题，又可以通过回滚，部分情况会报警让人解决，其它系统可能发工单让我们解决，又排除了很多出问题的可能性。
除了上面几个相对比较笼统的流程，还有比如培训，代码规范，每次开发完代码review等情况，可以让问题减少到最低的情况。并且线上一旦出了问题，追究责任就不仅仅是一个人了。
->问题->找到对应的系统->系统负责人->开发人员->测试人员->产品经理->提需求的人
多人协作，一般犯错的单位都是多个人，一个组。就比如最近的蚂蚁金服 ant design圣诞节彩蛋问题，最终是整个团队，集体没有年终奖。所以要说自己遇到过什么大的问题，可能比较难。
听到的问题
组长，总监，老员工都会反复的强调出现问题的严重性，“我们是支付系统，和钱直接打交道，一旦出了问题，都是大事，这责任承担不起”。
听说之前有个需求，如果用户的押金没有用完，会系统自动退款，但是上线之后，产品忘记通知全国的门店，导致门店人员也会给用户退一次钱，退了两份重复的钱，过一天之后发现，已经多退了几十万元。
有的开发，没有用redis的原子操作，而是首先用get获取数据，然后判断数据是否存在，再操作，以redis这么快的速度，再大的并发情况下，毫秒之内的执行速度，如果不是原子性的操作就出现了问题。
有的一边建立websocket，一边存储数据。通过websocket通知客户端数据已经存储好了，但是发现数据没有存储好。这是因为先发的通知，然后存的数据，通知发出去了，用户来查了，数据还没存储好呢。 这是规范的问题了。
最后
大部分的问题都是在上线之前遇到的，技术上的问题貌似没有，都是业务流程上的问题。而流程上的问题，在人数众多的情况下又极大的减少了出问题的可能性。
如果遇到了问题，请珍惜.
共同学习，写下你的评论
评论加载中...
作者其他优质文章
