身为一个程序员，遇到线上问题那都是家常便饭的事儿。
如果你在深夜看到一群同事围在一起，他们是在共同探讨什么哲学问题么？非也，他们一定是遇到了线上BUG。
线上问题只要影响到了核心业务流程那便是事故，所以一旦事故发生，无论你在约会，还是周末打游戏，甚至是在睡觉，只要接到了来自公司的电话，那只能赶紧连上公司网络加班了。
线上问题是复杂多变的，我们一般将bug分为系统级别和业务级别bug。
业务部署在整套系统上运行，一旦出现系统级别bug则业务会被严重拖垮。如CPU爆满、服务不可用、甚至服务器宕机等都属于系统级别的bug。
如果是CPU100%，那是由哪个线程，哪个类，甚至是哪个方法导致的？
若是业务流程正常但是部分服务性能拉跨，那么如何快速定位到问题在哪儿？
因为是线上发生的事儿，所以重点在于如何迅速解决。
以下分享我最常用的一些问题排查工具。
出现了业务bug那就纯纯的是开发或测试的锅了。
bug确定后第一步一定是先看日志，只要你写需求的时候日志打的全，一般出现了问题日志或者告警都会第一时间推送。
通过日志我们可以定位到bug对应代码的位置，但这仅仅是第一步，因为你只知道哪里出了问题，并不知道代码出了什么问题(除非一眼就能看出)。
所以下一步，看数据，数据是业务应用的核心。若通过日志和页面表现查看到你的主流程是没有问题的，那么下一步就是要确定表的数据是否有问题，数据存在bug的表现会是各方面的，可能是用户反馈，也可能是流程错误，这要取决于你表的设计。
切记！！线上数据是重中之重，当你决定要修复数据，在处理之前一定要做好备份，这样起码可以保证事情不会变的更糟。一般情况下修改线上数据这种活都需要你写好SQL，然后经过leader审批再交给DBA来操作，一定不要干出删库跑路这种事哟。
假设验证了你数据是OK的，那么问题就极大可能出现在了代码层面。
当代程序员最难过的瞬间无非就是有一个非常紧急的线上bug需要你来解决，但是摆在你面前的却是一堆屎山代码！！
修改业务bug最重要的是要将bug点修改掉并且保证其它业务还能正常运行，这是牵一发而动全身的事情，否则bug只会越改越多。
所以平时应该预知到这些风险，做好代码设计。总结一下定位业务bug的正确步骤：
一般公司都有自己的代码设计规范。比如由外到里包装代码，每一个方法都要有对应的职责，并且一个方法不要超过100行，一个类不要超过1000行代码等。清晰的结构可以让你和他人更好地review代码，避免看起来一头雾水。
写业务逻辑有两种方式，一种就是简洁明了的线性逻辑，另一种就是通过封装代码来减少代码耦合提高内聚性，也就是我们说的设计模式的使用。两种方式各有优缺点，但是工作多年了咱写的代码也不能直里直气的，多少得带点”艺术“对吧？推荐一下我经常使用但是也不会特别复杂的设计模式。
当然了这也能够体现出你在公司的不可替代性！
都说小事故伤身，大事故提桶。。一般发生事故后写一张事故单是不可避免的。除了详细描述好事故发生的经过，背锅人，解决方案，后续的事故跟进也是一系列流程的事，多则需要数周去跟进。事故的发生对于团队的技术发展和成型往往起着积极推进作用，所以对于每一个团队来说事故一定是不可避免的。每次事故发生我们都要思考如何完善系统，打破技术壁垒。并且遇到事儿也不要慌，如果是大问题，那么首先背锅的一定是leader！
其实呢一般公司最喜欢的是能快速解决问题的员工，即便这些问题可能是由你创造的。
最后免费分享给大家一份Python全套学习资料，包含视频、源码，课件，希望能帮到那些不满现状，想提升自己却又没有方向的朋友。
学好 Python 不论是就业还是做副业赚钱都不错，但要学会 Python 还是要有一个学习规划。最后大家分享一份全套的 Python 学习资料，给那些想学习 Python 的小伙伴们一点帮助！
Python所有方向的技术点做的整理，形成各个领域的知识点汇总，它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。
观看零基础学习视频，看视频学习是最快捷也是最有效果的方式，跟着视频中老师的思路，从基础到深入，还是很容易入门的。 
光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。 
检查学习结果。 
我们学习Python必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有阿里大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。 
这份完整版的Python全套学习资料已经打包好，需要的小伙伴可以戳下方链接免费领取
