这是一个失败率达到99%的行业

本文通过对风车网项目的分析,揭示在线旅游行业的高失败率及旅游社交应用面临的挑战,并强调产品经理需具备产品用户属性及正确选择的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

风车网 - 团结你的旅行 站长之家Chinaz.com配图

最近各大科技博客狂推人人网风车项目失败的文章,分别由风车网CEO@陈晓峰1978 发表文章《人人旗下风车网CEO的创业失败教训总结》而文中提到的前任PM @孙庆新 也迅速发表《产品角度分析风车网项目被终止的原因》。我也仔细看了这篇文章,其中陈晓峰总结的创业失败教训非常到位,也给大家不少启示。下面是我的一些读后感,分享给大家。

一、在线旅游行业是一个失败率达到99%的行业

2011年是移动互联网的高峰,众多融资都在这一年发生,而移动旅游行业也由之而火爆,众多创业团队纷纷切入这个行业,今夜酒店特价、航班管家、酒店达人更是把移动旅游产品推向了高峰。狂欢过来剩下的只是一片狼藉,时间推进到2012年,众多从事移动旅游产品的团队纷纷倒闭,5月份的风车网,甚至在最近一次17startup沙龙中的某个做过几个旅游APP的团队也宣布转型,不再做移动旅游APP。而今夜酒店特价、航班管家、酒店达人等APP呢?一样被众多后来者,巨头打压着,但它们过得比较好,因为融到钱,也有业务收入,活下去的机会比其他人要更高一点。这就是在线旅游行业的现状,一个失败率达到99%的行业,也正面临着退烧潮。

二、选择旅游社交就意味着你的产品会非常艰难

Native APP是一个单线程的工具,用户就是通过你来完成一个任务,完成后就会离开。这就是移动互联网的现状,想想用户是在什么情况下会打开APP?那就在于零碎时间,一个不断变化的使用环境,这就导致用户是希望你能越快帮助它解决一个问题,如果无法解决那么用户就会关闭或卸载你。如果你选择做旅游社交,也就意味着你希望用户在零碎时间中花费比较多时间来进行所谓的社交,这可能吗?陈晓峰对此总结一下经验:   

对于使用频率很低的东西,做社交不是很合适(社交就应该鸡毛蒜皮,明星八卦, 愤青政治) ,比较合适做工具类产品(要简单,刚需的) ,做打包的产品(比如组团,包机这种,赚的多) ,做品牌(去哪儿接受百度投资、和携程纠葛) ,做产品销售,做专业内容(道道、 Lonely Planet、马蜂窝)。plus:不过这里面有个需求不是刚需,计划制定,它是一个补充,尤真是线下服务的补充,所以我不是很认可"第一步”、“图客圈"目前的模式是个刚需。

你是上述提及的哪一方面?从目前比较成功的在线旅游产品来看,没有一个是靠做旅游社交成功,包括马蜂窝。

三、一个好的产品经理,需要拥有自己去做的产品的个人基因

不用论坛、微博和Facebook的人做社区的产品不合适;不用360客户端的同学做客户端也不合适;不爱好旅游的同学也别做旅游产品;没有小孩的别做亲子产品;没有退休父母的同学,也别做老年人的产品;不爱摄影、不玩单反的同学, 别做相册产品;不爱AV ,不收藏种子的同学,别做海量存储产品;没有上班一台机器, 下班一台机器的同学,也别设计云存储产品。

每个产品经理应该是自己产品的典型用户,虽然这话有点大路货,但作为产品经理,你必须这样做。只有成为典型用户,你才能理解业务逻辑,才能理解用户真实的想法,才能带着用户走。所谓的产品基因其实就是你对信息组织的看法,而这种组织方式恰恰是用户一直都缺乏的,它们需要你来告诉他们怎么看待这些事物。在没有马蜂窝之前,也许我们只会跟团游,走着无数人走过的景区、路线,有了马蜂窝后,自助游越来越流行,马蜂窝的旅游攻略更是把零散的自助游信息组织在一起,教导那些正在计划着下一个旅行目的地的用户:你可以这样玩!

四、选择比努力更重要

陈晓峰告诉我们的更多是选择老板、选择团队、选择下属的经验,而孙庆新则在博文中《产品角度分析风车网项目被终止的原因》告诉我们风车网会失败的真实原因。这些经验对于新来者都是非常重要的,在两篇文章中,看到许多不一样的地方,这就是所谓的盲点吧。

 

本文引用自站长之家 http://www.chinaz.com/start/2012/0803/266710.shtml

<think>好的,用户想了解性能测试中请求通过率的行业基准或参考标准。首先,我需要明确什么是请求通过率。请求通过率通常是指在性能测试期间成功处理的请求占总请求数的比例,通常以百分比表示。这是衡量系统可靠性和稳定性的重要指标。 根据现有的知识,请求通过率的行业标准可能因不同应用场景而异。比如金融系统对通过率的要求可能比普通网站更。一般来说,大多数系统会要求通过率达到99%以上,关键系统可能要求99.9%甚至更。不过,这需要具体参考行业标准或企业内部制定的SLA。 接下来,我需要查阅提供的引用资料。引用[1]提到HBase的性能测试包括单次请求平均延迟和吞吐量,但没有直接提到通过率。引用[2]讨论基准测试在服务器和数据库选型中的应用,可能涉及性能指标验证。引用[3]则强调选择正确的基准测试和收集相关数据的重要性。 用户的问题可能涉及如何确定通过率的合理阈值。需要结合测试目的,比如压力测试下允许一定失败,而稳定性测试则要求更的通过率。此外,不同行业的标准不同,比如电信、金融等行业可能有更严格的要求。 需要进一步说明影响通过率的因素,如系统架构、网络环境、测试场景设计等,并建议用户根据实际业务需求制定标准。同时,可以推荐参考国际标准如ISO 25010,或行业内的最佳实践,例如互联网公司常用的“三个九”或“四个九”的可用性标准。 总结回答时,应分点说明行业基准、测试类型的影响、参考标准来源,并给出实施建议,如结合SLA、分场景制定标准、关注失败原因分析等。确保引用相关文献,如引用[3]中关于正确选择基准测试的问题。</think>在性能测试中,请求通过率的行业基准需要结合具体场景和系统要求进行判断。以下是关键参考标准和分析框架: ### 一、行业通用基准参考 1. **基础要求** - 常规系统(如电商、门户网站):请求通过率需 ≥ **99%** - 关键系统(如金融交易、医疗系统):要求 ≥ **99.9%**(即"三个九"可用性) - 可用系统(如云计算基础设施):要求 ≥ **99.99%**("四个九")[^3] 2. **测试类型差异** - **压力测试**:允许通过率短暂下降(如95%-98%),需关注系统恢复能力 - **稳定性测试**:需维持通过率 ≥ 99.5% 且无持续下降趋势 - **峰值测试**:在极限负载下通过率可能降至90%-95%,但需确保不出现雪崩效应 ### 二、标准制定依据 1. **业务需求优先** - 根据SLA(服务等级协议)定义阈值,如金融交易系统要求单笔交易失败率 < 0.1%[^2] - 参考同类系统指标:如通信行业HTTP请求通过率通常要求 ≥ 99.95%(ETSI TS 103 782标准) 2. **失败类型权重** - 软性失败(如超时重试成功)可部分容忍 - 硬性失败(如数据丢失)必须严格限制(通常要求=100%) ### 三、实施建议 1. **分场景制定标准** ```python # 示例:动态阈值判断逻辑 if 测试类型 == "日常负载": 要求通过率 >= 99.9% elif 测试类型 == "双十一峰值": 允许通过率 >= 99% ``` 2. **复合指标关联分析** - 通过率需与响应时间、TPS(每秒事务数)联合分析 - 典型异常模式:通过率99%但P99延迟>3秒,可能隐藏性能瓶颈[^1] 3. **参考权威标准** - ISO 25010软件质量模型:可靠性维度要求故障率 ≤ 0.1% - TPC基准测试:事务成功率需100%才能记录有效测试结果
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值