项目问题处理

作为主程，要是一直是开发业务需求代码，那可就屈才了不是，处理各种问题才是关键。
各种问题包含很广，人的问题、事的问题、风险甚至是事故。

需求不合理
策划给的需求不一定是合理的。
首先可能是本来需求的逻辑就不对，例如：打怪掉落物品，物品没有获取逻辑，或任务全都完成后没有下一步操作。这种逻辑不封闭，或者逻辑本身就是错的不是很多见，与策划沟通不足即可。
更多的是需求看上去很简单，但是技术实现很复杂，而即使实现了收效也不是很大，即 技术投入价值 >>>>>(远大于) 功能实现，这种需求就需要调整。沟通流程一般就是，先与策划沟通这个需求理解的是否正确（可能策划没有要那么麻烦的东西，是你想错了）；需求理解没有问题那就确认这个需求要达到的目的和重要程度，若不是很重要则商量pass掉或者修改需求，若真的挺重要（也不是策划说重要就重要，做了也玩了很久游戏的也会有自己的想法不能被策划全忽悠）那么重新衡量技术投入价值与实现功能得到收益的关系，若还是差距较大则从技术角度提出几种解决方案可以实现类似效果，若真的是收效更高那么干就完了。
PS：比较难的需求确实可以去商量，但是也要有个度，不能总是砍来砍去的，这样不但影响游戏的玩法和体验，其实也让自己止步不前了。砍掉方便了自己，但是怎么提升呢。所以合理的分辨与利用。若是时间比较充裕，也可以适当提出比较难技术实现的玩法，提出给策划然后加入到游戏中，也是自我提升的好办法。

开发难度大
这里说的开发难度大不是指的需求不合理而产生的。而是必须要面对的需求功能点。例如：一个大版本主要做的就是全服级别的一种活动，首先访问量巨大，其次可能会有服务器间的数据交换。
面对难度，作为主程肯定不能退缩，迎难而上呗。平时的学习和各种技术的涉猎不就是为了这个时候用的么。
1.确认需求，是否理解的正确，避免前面提的开发理解的是登月，策划其实说的是爬楼梯。
2.对需求进行分析并分割，确定需求的重点和难点，这时候可以确认出哪些技术已经使用过可以拿过来就用，还有哪些需要补充的技术进行补充。
3.技术选型和预研，这个工作就可以使用自己平时涉猎的知识和各种工具来补充，也可以向下分配任务，提出选型和预研的对象、目标和解决问题，最后给出选型报告。
4.把补充的技术放在实际项目中进行使用，并且对新技术的实现进行测试（一般都是进行压力测试）。

技术瓶颈
开发难度大、线上bug或者事故处理和对未来游戏功能或者体谅预估是发现技术瓶颈的几个重要途径。技术瓶颈越早发现越好，可以降低风险提前补充短板。
技术一直在发展，需求也一直在发展，用户也一直在发展，所以新技术、高科技都是各种瓶颈逼出来的。技术瓶颈一直会存在，而且不会消亡，结局他就是主程解决问题的能力。
技术瓶颈没有什么比较好的办法解决，首先就是确定短板在哪里，一般用一句话进行表述出来，若是描述不出来或者说的比较模糊要么是没有找到真正的短板，要么它就是多块短板需求分解开。确认了短板，那么解决它就没那么难了。所以确定短板可能就需要一半的力气。
PS：技术瓶颈是对个人提升超级大的的点，解决问题的能力才是主程的价值。不能回避，而且尽量多停下来思考这方面的问题。

线上bug处理
是程序就会有bug，这个是程序员的共识了吧。别跟我说：我的一行hello world能有什么bug？我也只能回复一句：那能叫程序？
从前做web开发的时候项目工期比较紧，而且程序开发要求也不是很严格，所以线上的bug多的是，而且很多bug并不是开发人员的问题，可能是各种中间件的问题，所以灵异的问题也比较多。
转入游戏行业后，开发工作做了很多减法，而且对技术深度也要求更高，开发进度的把控都比较好，要求明确且严格，所以线上bug相对少了很多。第一次的游戏上线，第一天紧张坏了，感觉会有无数的问题迎面扑来，结果一天两天三天过去了，只有一些简单的bug而已。
线上bug主要有一下几种：
1.需求的逻辑不完整，而开发也没有发现导致的卡住，这个一般都是玩家上报的，因为不是程序错误。而且比较容易修改，但是线上数据的修复可能稍微复杂一些。
2.程序错误，一般就是程序异常导致的，所以程序开发最常见的规约就是：所以的异常和错误都要抛出，并且在最顶层截获异常并打入到日志中。然后线上有个定时任务分析日志发发现一场发送邮件预警。这种一场一般都比较容易定位问题。
3.程序校验不全，最典型的就是int类型溢出或者上传负数。其他问题也有，但是这个问题也是外挂经常使用的漏洞。例如本来应该是减少道具数量，结果上传负数负负得正了。再不就是int类型溢出产生了负数。这个问题部分是玩家上报得出，但是若是隐藏的比较深，没有让其他玩家知道也就没有任何来源了，那么就需要提前做一些数据校验的工具，定期对线上数据进行校验，例如：定时查询玩家金币数量，超出阈值发送邮件。
4.软件错误，指的是例如数据库的bug、Java底层的bug、docker容器的bug等。这类问题一般都是产生比较灵异的问题，虽然出现问题的概率不大，但是肯定是有，就比如我就碰到过MySQL由于自己的bug触发自动重启，docker的bug导致一直重启一个删除掉的容器而进行大量的io操作沾满CPU。这类问题由于刚开始发现都感觉很灵异，所以无从下手，等找到问题所在了就会恍然大悟。
对于各种bug，发现就解决，不要先去追责，这样耽误进度也对团队人员管理添加风险。解决至少可以进行团队内反思，对事不对人，这是一个较好的管理方式，尽量避免同样的问题再次犯错。

线上事故处理
大型游戏线上服务器使用量也非常的大。当初有一款游戏由于有IP并且推广力度巨大，所以玩家数量级别也较高。最高时使用服务器数量数千台。有时候运维的兄弟都开玩笑说在他手里花出去的钱在北京都可以买豪宅了。
服务器众多，而且大多都是云服务器，所以各种事故层出不穷。所以不乏重大事故的出现。
线上事故处理流程：
1.重中之重是预防，例如多云、跨机房、备份、避免单点等等。
2.事故问题定位，这个是比较重要的环节，定位不准确肯定还会再次发生。例如发现大面积的CPU跑满，然后就进行各种扩容。其实CPU跑满有很多情况，例如IO巨大，程序死循环等等。若盲目扩容，肯定还会再次跑满。定位不准确肯定解决不了问题。所以要往根上抛问题。
3.事故解决与恢复，定位到问题之后解决问题就容易的多。但是解决的办法要考虑多方面，首先是回复服务，其次是避免再次出现问题，最后还有合理合法回复数据避免事故产生的后果影响玩家体验。
PS：线上事故同样的不能首先去追责，而是解决问题然后大家讨论。另外每次一线上大事故都应该做一个备忘，这可是体现你值多少钱的最有力证明。