(1)数据安全
(2)代码规范
(3)系统安全
(4)用户体验性
(5)数据库性能
(6)可扩展性
(7)可维护性
(8)接口设计
(9)数据结构设计
(10)可用性
访问量
这里出现的所有问题，归根结底，主要的原因都是对用户的访问量估计不足，当有大量用户同时访问时，系统的正常服务受到了影响，这是网站发布前的预备工作不够充分导致的。线下的服务你能看到街上排队人群的长度并且能够人为的干预，但是在线的服务似乎很少能够充分考虑到用户同时访问的这个问题。
这就引出了一个问题——在网站发布以前，究竟应该做怎样的负载测试呢？又该如何设计性能测试呢？这让我想到了一个俗语‘有钱难买’好名声。glaunch可能会给你的产品带来更大的关注，但是也会带来更多的舆论压力。这是一个相当冒险的策略——一个品牌苦心经营的信誉可能瞬间遭到瓦解，用户对品牌的不信赖可能造成更加深远的影响。
另一个令人担忧的问题就是这些组织很快就将问题归咎于用户的访问数量——这似乎已经成为一个可以接受的通用借口了。更令人担心的是客户似乎不得不接受这个理由。对于一个有能力的web设计和运行公司而言，这样的行为是非常不合适的。无论出于何种原因，一个网站都不应该在推出的时候出现这种纰漏，我认为随着在线市场越来越成熟，广大的用户也将无法继续容忍这些网站这种推卸责任的态度。
虽然有些特殊、罕见的因素导致在线市场很难完全在人们的掌控之中，但这并不能成为开发人员计划失误或是测试不足的借口。大家必须先做好健壮的成本效益分析，然后再作出周详的商业决定。
假设在网站推行之前你进行了大量的前期预热炒作，是否花在测试上的人力物力和准备工作多于相关的宣传预算？你能否控制媒体的报道？你或许认为不需要在测试上投入过多的精力，甚至认为即使网站在运行的第一天出现小的故障也是可以忍受的。但是往往有些时候，小故障和大灾难就是一墙之隔，所以必须仔细考虑‘glaunch’带来的商业影响。
这里给出了避免glaunching的几点建议：
- 在设计阶段就考虑好系统的性能和负载处理能力，包括软件和硬件设备方面的要求。
- 做好健壮的成本效益分析和风险评估。
- 设计一个清晰的测试方法，用来评价系统系统的性能是否能够满足应用的需求，既包括访问按计划增长的情形，也包括出现访问高峰的情况。
- 弄清楚出现访问峰值的原因，并找到应对的方法。
- 在运行过程中进行性能测试、计算负载峰值和压力测试
- 找独立的第三方完成测试工作：不要自己为自己评估。