免费流量：策略不错但打不倒微信
29日，淘宝官方微博发布消息，确认淘宝网和来往将与运营商达成合作，为符合条件的用户推出免费流量服务。无独有偶，和这个消息同时传播的其他行业动态还有：1、易信宣布用户数突破3000万（日活跃用户28%）；2、微信推出公众服务帐号收费服务。
这三条消息在同一时间推出，并且都是和移动IM相关，特别是其中两款产品所涉及的内容都是免费流量，这样的巧合在行业内不能说是破天荒，但至少是巧合中的巧合了。对整个移动IM通讯市场而言，这样的情况也充分说明，当前的移动IM已经不再是白热化竞争，而是已经到了兵戎相见的地步了。
在这几条消息中，我注意到：之前易信推出时的杀手锏是免费流量，而目前来往的狙击招式也是免费流量，通过免费流量狙击微信，看来已经是易信和来往不约而同选择的策略方式。不过，针对两家竞争对手均纷纷推出免费流量对战微信的举措，微信让人大跌眼镜的却是破天荒地推出收费服务。
微信疯了吗？
不能说微信在这个日子里特意推出收费服务是对另外两款产品的蔑视，但在市场信心方面，微信显然是有着巨大的自信和底气的，并没有因为易信和来往利用免费流量招式给自己增加压力，尤其在来往正式对外推广运营时，马云多次隔空叫板微信，但微信并没有发文一字回应对方的叫板。或许，微信团队对来往和易信发起的挑战，根本就没当一回事。
另外一方面，易信和来往主打免费流量竞争的方式，无论在策略还是用户实质需求方面，都是一个不错的打痛点方式（微信的通讯流量可没免费过）。不过，这种策略虽然整体看上去很好，但我仍然不太认同这种以小惠利去勾引用户的招式，对于今天的微信而言，其发展力量和成功因素显然不再受流量成本制约。因为对于微信，其自有应对市场挑战的底气和本领，其中产品体验和社交网络的优势，也已经奠定微信的地位。
微信虽然拥有QQ用户导入的优势，但微信也还有属于其自身的独特功能和优势，其中最为特别的就当数图片社交和公众平台。
微信构筑的社交沟通模式，基础层面来看，微信已经实现将语音文字和图片社交结合，基本的文字和图片沟通加上图片社交，同时再赋予堪称行业无可匹敌的公众平台，已经完全将微信的其他竞争者杜绝到了另一个世界。而我们回头来看易信和来往，二者的产品功能和属性都只是基础沟通，微信所具备的图片社交和公众帐号，易信和来往都做得一塌糊涂。
这种使用先天产品优势构筑的堡垒，已经使得用户在社交网络需求方面如鱼得水，特别在巩固了用户之间社交关系的情况下，很少有用户愿意更换移动IM而换来社交网络中断或破裂的结果。虽然也有无数人吐槽微信的朋友圈和公众帐号，但不得不承认这确实是微信的两大杀手锏，因而易信和来往不想要通过免费流量打败微信，首先更应明白免费流量的重要性与微信构筑的社交重要性，哪一个对用户而言更重要。
更何况，按照目前的通讯成本来看，易信和来往所提供的免费流量对用户而言，根本就不是大成本，无法达成让用户为这点流量就更换社交关系的可能。因此，联合产品+社交关系的优势，微信目前不仅可以神色自若地生存，而且还可以完全在逆势环境下推出收费功能，让自己获得更好。这个，就是微信的底气和自信，也是我个人认为易信和来往用免费流量无法撼动微信的主要原因。
关于这点，我的一个朋友甚至说，微信完全可以将朋友圈和公众平台剥离出来，独立运营。
不过，易信和来往用免费流量的方式虽然无法撼动微信，但这种策略也不是无一是处，对于要大力站稳市场和赢取一定程度的口碑，易信和来往施展的这种招式也能起到一定的意义。再者，易信和来往推出免费流量服务，对于微信的监督和促进产品品质提升，也同样具备良好的行业公平竞争作用。
总的来说，易信和来往使用免费流量的策略虽然不错，也能给行业带来一定程度的积极作用，但这种策略目前还对微信无法造成致命冲击。但是，对于市场垄断和产品创新竞争而言，易信和来往的这种方式值得鼓励，因为只有相关的产品展开品质和服务的竞争，才能使得行业整体发展水平进入一个全新的阶段，最终受益的，才会是用户。
（朱翊/文，微信公众帐号：zhuyiweixin）
Hadoop运维记录系列(十二) 从公司离职有几天了，今天回去看同事，想一起吃饭，没成想摊上大事了。说下午hadoop集群的机房停电了，然后集群就启动不了了，几个人从下午4点多折腾到8点多还没搞定，有几台服务器找不到硬盘，还有内网ping不通的。反正是有10来台服务器起不来datanode和tasktracker了。于是在原公司蹭了个饭，花了20分钟解决了一下。
由于这几台服务器挂机，namenode没有达到有效数据块的阀值所以一直处于safemode。
然后逐个解决，同事反馈比较多的情况是硬盘设备在/dev找不到，看了一下，/dev下设备存在，但是没有分区，OPS偷懒，只是把硬盘挂上了，没有fdisk就直接mkfs.ext3了。所以/dev下的设备都是sdb,sdc...而正确的话应该是sdb1,sdc1这样的。所以同事以为硬盘找不到了，就一直没有处理。发现这个问题以后，直接把/dev/sdb挂载到/data1,/data2...。该故障恢复。
还有一类故障是硬盘挂上了，但是datanode无法启动，启动后报Cannot lock storage /data3/... The directory is already locked。看了一下，路径权限没问题，也没有进程占用该路径。怀疑是硬盘出错。mount看了一下，硬盘处于rw状态，应该是没啥问题，但是还是启动不了，于是将该硬盘umount掉，然后重新mount，还是不行，于是做了个测试，直接把该硬盘mkfs.ext3。再重新挂载，然后创建相应的文件夹，赋予权限。再启动datanode，这时候理论上应该是正常并负载均衡数据块，但datanode还是挂了，报了一个DiskChecker volsFailed故障，于是判断该硬盘有物理损坏，格式化都不好使了。直接从hadoop配置文件里摘除，重启datanode正常。
最后一个故障是某一台服务器，内网网卡无法ping通同网段内的服务器。外网可以连接，看了一下ifconfig，IP信息，MAC信息都正确无误，于是怀疑是路由或者网卡问题，但一般来说，网卡不太会出问题，先从路由看起，果不其然被蒙对了。ip route命令看了一下linux的路由表。发现里面的内网地址192.168网段被转发到了一个错误的10.8的VPN tunnel上面。将该路由记录从路由表删除后，立刻就通了，相当的爽，20分钟解决全部战斗。
完了以后跟他们开玩笑说，你们以后可以管我叫观世音了。然后说，干脆公司把我返聘回来当顾问得了，或者把hadoop集群的运维业务外包给我得了，出了问题你们都回家，我来加班帮你们搞定。
这个事情我总结了如下几点：
一、大公司不应该为了图便宜去找廉价机房，停电真是受不了，尽管我之前的公司并不在意数据这事，但是发生大规模宕机终归不是什么好事，带来的后续问题太多。抠门也得抠的是地方，该花的钱不能省。
二、大规模分布式集群运维的人才问题将成为瓶颈，鉴于分布式系统的复杂程度，要求运维人员的水平相对比网站运维要高得多。随着技术的发展，用工具把hadoop搭起来不是问题，但是在大规模集群下的维护将成为大问题，要面对各种各样可能发生的奇怪的故障，综合知识要求非常高。不光要精通linux，还要精通网络，还要精通自动化运维方式，还要精通编程，让传统运维去维护hadoop是mission impossible的事。map/reduce开发其实很简单，只要掌握了开发的思想，一天时间包教包会。运维很可能是最终阻碍hadoop落地的障碍，分布式系统太复杂了，水很深，坑很多。需要比较长时间的积累，然后需要知识面很广，思路很活跃才行。像我们这种互联网公司搞hadoop运维都会遇到种种困难，何况是其他人了。
三、没事别回以前的公司。
本文出自 "实践检验真理" 博客，谢绝转载！
没有评论:
发表评论