9 月 19 日摩拜单车宕机，有可能的系统瓶颈有哪些？请大牛分析

[lavdemo]

第二天从 36kr 看到新闻 http://36kr.com/p/5053188.html 里面有段话有点意思“晚上 10 点 50 分，摩拜单车 CEO 王晓峰发了一条朋友圈：“抱歉的同时，求 1 、 系统安全高手 2 、架构师高手，以应付不断增加的需求 ””。 可否请技术大牛分析下，到底发生了什么，他们系统的瓶颈有可能是什么？

[ITOutsider]

摩拜的 hr 不知道在干什么 投了简历一点回应也没用 不知道他们后端几个人负责

[zts1993]

瓶颈就是没有抗住攻击，我猜。。

我觉得不太可能因为业务发展一夜直接就扛不住，实际上最近唱衰的人挺多。感觉不能仔细推敲。。

[yghack]

技术储备不足

[nangonglili]

从全栈性能管理的角度来看，可能造成性能问题的原因大致可以分成几种：
1.前端 APP 的性能问题
2.传输网络的性能问题
3.后端服务的性能问题
4.基础设施的性能问题
5.第三方服务的性能问题

我们来分析下摩拜这次宕机事件，最有可能的性能问题是什么：
1.首先，从直观上来看，并不是由于 APP 本身的质量导致的性能问题；
2.其次，从摩拜发布的消息来看，前海征信还未正式接入，排除了第三方服务导致的性能问题；
3.最后，用户能正常查看到车辆，但在解锁车辆操作时失败，不符合网络瓶颈导致的无法访问特征。
因此，我们有充分的理由怀疑摩拜后端服务和基础设施性能存在瓶颈。

结合摩拜的现状，再分析下可能引起问题的技术原因：
1.后端应用架构的技术问题：在系统设计之初，采用高性能、高可用的系统架构显然至关重要。
2.后端代码质量：良好的编码习惯和足够优化的算法，正确地对数据库进行操作，能在现有架构的基础上极大地提高系统的处理能力。
3.基础设施优化能力：对操作系统内核、中间件、数据库的优化能力，是传统运维人员的价值所在。
所以说，架构师、程序员、运维一个都不能少。

从业务方面来看，可能是什么原因：
1.业务自然增长导致的瓶颈出现，这种可能性比较低，通常情况下，运维部门对业务的自然增长带来的性能压力都有足够的预估能力并及时做出调整，否则那也太对不起运维两个字了。
2.突发高峰期的性能瓶颈，从摩拜宕机事件来看， 9 月 19 号并不是什么特殊的日子，不太符合突发业务高峰期的特征。
3.系统升级、代码迭代等导致的性能事故，是否是由于摩拜内部进行了系统升级等操作导致的问题，恐怕也无从得知。
4.竞争对手或者黑客恶意攻击导致宕机，这也是很有可能的，否则 CEO 也不会求系统安全高手吧。

如何避免和跟踪性能问题？
还是那句话，你得有一个好的技术团队，使用优秀的系统架构，良好的编码，牛逼的运维。光有这些还不够，你还得把应用性能提到关注日程上，你得关注用户的体验，你得感知用户的体验，你得引入一种全栈性能管理的方法。否则，运营团队、开发团队、运维团队各自忙成狗，却没有就用户体验达成共识，那再忙也是瞎忙。
目前市面上有许多厂商提供专业的应用性能管理（ APM ）解决方案，比如云智慧的透视宝产品，通过跟踪 APP 用户行为，跟踪后端应用请求处理代码栈，跟踪基础设施性能状态，可以把从前到后各环节、从上到下各层次关联在一起进行分析，找出性能瓶颈及其原因。感兴趣的同学，请自行百度“云智慧透视宝脑补吧。
对于摩拜这样的创新型互联网企业，用户体验至关重要，既事关运营问题，也事关性能问题，本文就性能问题进行了一些分析和总结，抛砖引玉，仅代表个人意见，不喜勿喷。