你也配看我的文章，我和你有何交情？
什么样的问题最好玩？诡异的问题。。。什么样的技术最好玩？逻辑复杂的技术。。。什么样的人最令人厌恶？fucking pussy，有本事对刚。
流下了没本事的泪水。
一个问题的诞生，一般都只能看到表面现象，而实际的内在则是存在各种各样的问题，而解决一个问题，则是一个逐步判断的过程，根据一些现象，推测其可能出现的问题，然后加以解决，再查看现象。。。任何形式的表演，都是为了一个目标，都有本质的point，看透不说透？不可能。。。
透过现象看本质，透过文章你能看出来我是个*不。。。啊，我那该死的三千烦恼丝。。。面对疾风吧。。。emmm，讥讽。。。
现象：在进行一个接口访问的时候，发现有部分请求无法通过，报错403forbbidon，拒绝请求。。。哼，敢拒绝我。。。
解决过程：查看nginx的访问日志，发现日志中不是全部报错，而是部分报错，有200成功的，有403forbidden的，再仔细一看，日志中包含了请求的body的大小，当body超过一定大小的时候，请求就被拒绝，而对于小的报文则返回成功。
构造报文，进行发送请求，发现当报文小于16k就成功，而大于的则通过，由于链路比较复杂，显示nginx，然后是lvs，再是后端的realserver，那么是谁拒绝了请求？
初步怀疑是nginx的参数client_max_body_size问题，因为当超过一定的大小的时候，nginx会拒绝，但是其实实际上如果是这个参数导致的问题，报错是request entiry too large，修改之后，发现依旧报错相同。
问题定位：对于链路比较长的，从而无法判断是哪部分出现了问题，从而使用构造的报文，分别请求nginx，请求lvs，请求rs，最后发现后两者都是ok的，那么问题还是在nginx上。
nginx拿来主义，所以运行的用户其实也无所谓，查看nginx的访问日志的时候，发现报错是permission denid，emmm，为何权限不足，而对于小报文则没啥影响。
默认情况下，当直接运行nginx的时候，master进程的权限是root用户，而worker的权限是nginx用户，那么就有一种可能，当报文过大的时候，会在本地进行缓存，也就是目录client_body_temp_path。
16k大钻石。。
当这个目录的权限是root用户的时候，那么就表示普通用户nginx并没有权限。
解决方法：将user用户修改为root，从而所有master和worker进程都是root用户，至此问题解决。
一项技术，无限的贴近用户，才知道能解决什么样的问题，有的时候，这种问题只是你臆想出来的。
就像k8s，有的时候别人根本就不需要这种技术，如果不能解决麻烦，这种技术再高明又有什么用？
贴近用户，你就知道在用户面前，技术再牛逼，逻辑再复杂，oho，并不关心，客户只关心你能不能解决问题，关心的是你能不能减少烦躁的时间。
越贴近用户，你就会发现技术的价值很低很低。。。有的时候，化妆的太多，只看你头发长，那你脸上抹上再多的粉，也无济于事。。。不是贬低技术，而是需要你去思考，这个技术解决了什么问题？带来了什么价值。。。可能一文不值，可能你的时间都是白白浪费的。。。
你很努力，可能不自知。。。很多东西是谬论，例如，知识是否要储备，如果你不储备，谁会给你机会？？？
在不同的场景，就是盲人摸象，每个人看到的只是一部分，而你要做的。。是变得更强。。。天下大势，分分合合。。。
解决问题，靠的不是相互指责。。。而是。。。相互配合。配合？不可能，你是leader？那就发起一次选举，看看谁是follower。。。