• mysql 自动检测主从同步状态的一个小脚本

    Slave机器的IO和SQL状态都必须为YES,才是同步状态;

    #!/bin/bash 
    #Check MySQL Slave's Runnning Status
    #Crontab time 00:10
    
    MYSQLPORT=`netstat -na|grep "LISTEN"|grep "3306"|awk -F[:" "]+ '{print $5}'`
    MYSQLIP=`ifconfig eth0|grep "inet addr" | awk -F[:" "]+ '{print $4}'`
    STATUS=$(/usr/bin/mysql -uroot -p123qwe -S /var/lib/mysql/mysql.sock -e "show slave status\G" | grep -i "running")
    IO_env=`echo $STATUS | grep IO | awk  ' {print $2}'`
    SQL_env=`echo $STATUS | grep SQL | awk  '{print $2}'`
    DATA=`date +"%y-%m-%d %H:%M:%S"`
    
    function checkMysqlStatus(){
    	if [ "$MYSQLPORT" == "3306" ]
    	then
    		/usr/bin/mysql -uroot -p123qwe --connect_timeout=5 -e "show databases;" &>/dev/null 2>&1
    		if [ $? -ne 0 ]
    		then
    			echo "Server: $MYSQLIP mysql is down, please try to restart mysql by manual!" > /var/log/mysqlerr
                mail -s "WARN! server: $MYSQLIP  mysql is down." mailcity@126.com < /var/log/mysqlerr
    		else
    			echo "mysql is running..."
    		fi
    	else
    		mail -s "WARN!Server: $MYSQLIP mysql is down." mailcity@126.com
    	fi
    }
     
    checkMysqlStatus
    
    if [ "$IO_env" = "Yes" -a "$SQL_env" = "Yes" ]
    then
      echo "MySQL Slave is running!"
    else
      echo "####### $DATA #########">> /var/log/mysql/mysql_slave_status.log
      echo "MySQL Slave is not running!" >>    /var/log/mysql/mysql_slave_status.log
      echo "MySQL Slave is not running!" | mail -s "WARN! $MYSQLIP MySQL Slave is not running." mailcity@126.com
    fi
    
  • 运气就是机会碰巧撞到了你的努力

    行动是治愈恐惧的良药,而犹豫、拖延将不断滋养恐惧。

    活着一天,就是有福气,就该珍惜。当我哭泣我没有鞋子穿的时候,我发现有人却没有脚。

    宁愿做过了后悔,也不要错过了后悔。

    学的到东西的事情是锻炼,学不到的是磨练。

    过错是暂时的遗憾,而错过则是永远的遗憾!

    勇气是控制恐惧心理,而不是心里毫无恐惧。

    人一生下就会哭,笑是后来才学会的。所以忧伤是一种低级的本能,而快乐是一种更高级的能力。

    放弃该放弃的是无奈,放弃不该放弃的是无能,不放弃该放弃的是无知,不放弃不该放弃的是执著!

    一杯清水因滴入一滴污水而变污浊,一杯污水却不会因一滴清水的存在而变清澈。

    运气就是机会碰巧撞到了你的努力。

    只有你学会把自己已有的成绩都归零,才能腾出空间去接纳更多的新东西,如此才能使自己不断的超越自己。

  • linux抓包 tcpdump命令详解

    tcpdump可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤,并提供and、or、not等逻辑语句来帮助你去掉无用的信息。

    实用命令实例

    默认启动

    tcpdump

    普通情况下,直接启动tcpdump将监视第一个网络接口上所有流过的数据包。

    监视指定网络接口的数据包

    tcpdump -i eth1

    如果不指定网卡,默认tcpdump只会监视第一个网络接口,一般是eth0,下面的例子都没有指定网络接口。

    监视指定主机的数据包

    打印所有进入或离开sundown的数据包.

    tcpdump host sundown

    也可以指定ip,例如截获所有210.27.48.1 的主机收到的和发出的所有的数据包

    tcpdump host 210.27.48.1

    打印helios 与 hot 或者与 ace 之间通信的数据包

    tcpdump host helios and \( hot or ace \)

    截获主机210.27.48.1 和主机210.27.48.2 或210.27.48.3的通信

    tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)

    打印ace与任何其他主机之间通信的IP 数据包, 但不包括与helios之间的数据包.

    tcpdump ip host ace and not helios

    如果想要获取主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包,使用命令:

    tcpdump ip host 210.27.48.1 and ! 210.27.48.2

    截获主机hostname发送的所有数据

    tcpdump -i eth0 src host hostname

    监视所有送到主机hostname的数据包

    tcpdump -i eth0 dst host hostname

    监视指定主机和端口的数据包

    如果想要获取主机210.27.48.1接收或发出的telnet包,使用如下命令

    tcpdump tcp port 23 host 210.27.48.1

    对本机的udp 123 端口进行监视 123 为ntp的服务端口

    tcpdump udp port 123

    监视指定网络的数据包

    打印本地主机与Berkeley网络上的主机之间的所有通信数据包(nt: ucb-ether, 此处可理解为’Berkeley网络’的网络地址,此表达式最原始的含义可表达为: 打印网络地址为ucb-ether的所有数据包)

    tcpdump net ucb-ether

    打印所有通过网关snup的ftp数据包(注意, 表达式被单引号括起来了, 这可以防止shell对其中的括号进行错误解析)

    tcpdump 'gateway snup and (port ftp or ftp-data)'

    打印所有源地址或目标地址是本地主机的IP数据包

    (如果本地网络通过网关连到了另一网络, 则另一网络并不能算作本地网络.(nt: 此句翻译曲折,需补充).localnet 实际使用时要真正替换成本地网络的名字)

    tcpdump ip and not net localnet

    监视指定协议的数据包

    打印TCP会话中的的开始和结束数据包, 并且数据包的源或目的不是本地网络上的主机.(nt: localnet, 实际使用时要真正替换成本地网络的名字))

    tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

    打印所有源或目的端口是80, 网络层协议为IPv4, 并且含有数据,而不是SYN,FIN以及ACK-only等不含数据的数据包.(ipv6的版本的表达式可做练习)

    tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

    (nt: 可理解为, ip[2:2]表示整个ip数据包的长度, (ip[0]&0xf)<<2)表示ip数据包包头的长度(ip[0]&0xf代表包中的IHL域, 而此域的单位为32bit, 要换算

    成字节数需要乘以4, 即左移2. (tcp[12]&0xf0)>>4 表示tcp头的长度, 此域的单位也是32bit, 换算成比特数为 ((tcp[12]&0xf0) >> 4) << 2,
    即 ((tcp[12]&0xf0)>>2). ((ip[2:2] – ((ip[0]&0xf)<<2)) – ((tcp[12]&0xf0)>>2)) != 0 表示: 整个ip数据包的长度减去ip头的长度,再减去
    tcp头的长度不为0, 这就意味着, ip数据包中确实是有数据.对于ipv6版本只需考虑ipv6头中的’Payload Length’ 与 ‘tcp头的长度’的差值, 并且其中表达方式’ip[]’需换成’ip6[]’.)

    打印长度超过576字节, 并且网关地址是snup的IP数据包

    tcpdump 'gateway snup and ip[2:2] > 576'

    打印所有IP层广播或多播的数据包, 但不是物理以太网层的广播或多播数据报

    tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

    打印除’echo request’或者’echo reply’类型以外的ICMP数据包( 比如,需要打印所有非ping 程序产生的数据包时可用到此表达式 .
    (nt: ‘echo reuqest’ 与 ‘echo reply’ 这两种类型的ICMP数据包通常由ping程序产生))

    tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

    tcpdump 与wireshark

    Wireshark(以前是ethereal)是Windows下非常简单易用的抓包工具。但在Linux下很难找到一个好用的图形化抓包工具。
    还好有Tcpdump。我们可以用Tcpdump + Wireshark 的完美组合实现:在 Linux 里抓包,然后在Windows 里分析包。

    tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

    (1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置,用来过滤数据报的类型
    (2)-i eth1 : 只抓经过接口eth1的包
    (3)-t : 不显示时间戳
    (4)-s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包
    (5)-c 100 : 只抓取100个数据包
    (6)dst port ! 22 : 不抓取目标端口是22的数据包
    (7)src net 192.168.1.0/24 : 数据包的源网络地址为192.168.1.0/24
    (8)-w ./target.cap : 保存成cap文件,方便用ethereal(即wireshark)分析

    使用tcpdump抓取HTTP包

    tcpdump  -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

    0x4745 为”GET”前两个字母”GE”,0x4854 为”HTTP”前两个字母”HT”。

    tcpdump 对截获的数据并没有进行彻底解码,数据包内的大部分内容是使用十六进制的形式直接打印输出的。显然这不利于分析网络故障,通常的解决办法是先使用带-w参数的tcpdump 截获数据并保存到文件中,然后再使用其他程序(如Wireshark)进行解码分析。当然也应该定义过滤规则,以避免捕获的数据包填满整个硬盘。

  • 商业计划

    少听身边人的话,多听有结果人的话。

    预测大趋势,就能找到大商机;预测小趋势,只能找到小商机。商机有方法,创业有思路。

    商学院百万学费收获的最有用东西

    战略方向:
    一、SWOT分析法:

    Strengths:优势;
    Weaknesses:劣势;
    Opportunities:机会;
    Threats:威胁

    意义:帮您清晰地把握全局,分析自己在资源方面的优势与劣势,把握环境提供的机会,防范可能存在的风险与威胁,对我们的成功有非常重要的意义。

    战术层面:

    二、PDCA循环规则

    Plan:制定目标与计划;
    Do:任务展开,组织实施;
    Check:对过程中的关键点和最终结果进行检查;
    Action:纠正偏差,对成果进行标准化,并确定新的目标,制定下一轮计划。

    意义:每一项工作,都是一个pdca循环,都需要计划、实施、检查结果,并进一步进行改进,同时进入下一个循环,只有在日积月累的渐进改善中,才可能会有质的飞跃,才可能取得完善每一项工作,完善自己的人生

    三、5W2H法

    What:工作的内容和达成的目标
    Why:做这项工作的原因
    Who:参加这项工作的具体人员,以及负责人
    When:在什么时间、什么时间段进行工作;
    Where:工作发生的地点
    How:用什么方法进行
    How much:需要多少成本

    意义:做任何工作都应该从5W2H来思考,这有助于我们的思路的条理化,杜绝盲目性。我们的汇报也应该用5W2H,能节约写报告及看报告的时间。

    四、SMART原则  目标管理

    Specific 具体的;
    Measurable 可测量的;
    Attainable 可达到的;
    Relevant 相关的;
    Time based 时间的;

    意义:人们在制定工作目标或者任务目标时,考虑一下目标与计划是不是SMART化的。只有具备SMART化的计划才是具有良好可实施性的,也才能指导保证计划得以实现。

    特别注明:有的又如此解释此原则
    —S代表具体(Specific),指绩效考核要切中特定的工作指标,不能笼统;
    —M代表可度量(Measurable),指绩效指标是数量化或者行为化的,验证这些绩效指标的数据或者信息是可以获得的;
    —A代表可实现(Attainable),指绩效指标在付出努力的情况下可以实现,避免设立过高或过低的目标;
    —R代表现实性(realistic),指绩效指标是实实在在的,可以证明和观察;
    —T代表有时限(time bound),注重完成绩效指标的特定期限。

    五、时间管理-重要与紧急

    急迫
    不急迫
    重要
    紧急状况
    迫切的问题
    限期完成的工作
    你不做其他人也不能做
    准备工作
    预防措施
    价值观的澄清
    计划
    人际关系的建立
    真正的再创造
    增进自己的能力
    不重要
    造成干扰的事、电话、
    信件、报告
    会议
    许多迫在眉捷的急事
    符合别人期望的事
    忙碌琐碎的事
    广告函件
    电话
    逃避性活动
    等待时间

    优先顺序=重要性*紧迫性
    在进行时间安排时,应权衡各种事情的优先顺序,要学会“弹钢琴”。
    对工作要有前瞻能力,防患于未然,如果总是在忙于救火,那将使我们的工作永远处理被动之中。

    六、任务分解法[WBS]

    即Work Breakdown  Structure,如何进行WBS分解:目标→任务→工作→活动

    WBS分解的原则:
    将主体目标逐步细化分解,最底层的任务活动可直接分派到个人去完成;每个任务原则上要求分解到不能再细分为止。

    WBS分解的方法:
    至上而下与至下而上的充分沟通;
    一对一个别交流;
    小组讨论

    WBS分解的标准:
    分解后的活动结构清晰;
    逻辑上形成一个大的活动;
    集成了所有的关键因素包含临时的里程碑和监控点;
    所有活动全部定义清楚

    意义:学会分解任务,只有将任务分解得足够细,您才能心里有数,您才能有条不紊地工作,您才能统筹  安排您的时间表

    价值创造

    七、二八原则

    巴列特定律:“总结果的80%是由总消耗时间中的20%所形成的。”   按事情的“重要程度”编排事务优先次序的准则是建立在“重要的少数与琐碎的多数”的原理的基础上。举例说明:
    80%的销售额是源自20%的顾客;
    80%的电话是来自20%的朋友;
    80%的总产量来自20%的产品;
    80%的财富集中在20%的人手中。

  • Redis持久化实践及灾难恢复模拟

    目前Redis持久化的方式有两种: RDB 和 AOF

    Redis在利用RDB和AOF进行恢复的时候,都会读取RDB或AOF文件,重新加载到内存中。

    RDB就是Snapshot快照存储,是默认的持久化方式。
    可理解为半持久化模式,即按照一定的策略周期性的将数据保存到磁盘。
    对应产生的数据文件为dump.rdb,通过配置文件中的save参数来定义快照的周期。
    下面是默认的快照设置:

    save 900 1    #当有一条Keys数据被改变时,900秒刷新到Disk一次
    save 300 10   #当有10条Keys数据被改变时,300秒刷新到Disk一次
    save 60 10000 #当有10000条Keys数据被改变时,60秒刷新到Disk一次

    第一次Slave向Master同步的实现是:
    Slave向Master发出同步请求,Master先dump出rdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。
    第二次以及以后的同步实现是:
    Master将变量的快照直接实时依次发送给各个Slave。
    但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
    Redis的主从复制是建立在内存快照的持久化基础上的,只要有Slave就一定会有内存快照发生。

    RDB的不足:从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。

    ————————————————–

    AOF(Append-Only File)比RDB方式有更好的持久化性。
    由于在使用AOF持久化方式时,Redis会将每一个收到的写命令都通过Write函数追加到文件中,类似于MySQL的binlog。
    当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
    对应的设置参数为:
    $ vim /opt/redis/etc/redis_6379.conf

    appendonly yes       #启用AOF持久化方式
    appendfilename appendonly.aof #AOF文件的名称,默认为appendonly.aof
    # appendfsync always #每次收到写命令就立即强制写入磁盘,是最有保证的完全的持久化,但速度也是最慢的,一般不推荐使用。
    appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,是受推荐的方式。
    # appendfsync no     #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不被推荐。

    AOF的完全持久化方式同时也带来了另一个问题,持久化文件会变得越来越大。
    比如我们调用INCR test命令100次,文件中就必须保存全部的100条命令,但其实99条都是多余的。
    因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。
    为了压缩AOF的持久化文件,Redis提供了bgrewriteaof命令。
    收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件,以此来实现控制AOF文件的增长。
    由于是模拟快照的过程,因此在重写AOF文件时并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
    对应的设置参数为:
    $ vim /opt/redis/etc/redis_6379.conf

    no-appendfsync-on-rewrite yes   #在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。
    auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。
    auto-aof-rewrite-min-size 64mb  #当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

    到底选择什么呢?下面是来自官方的建议:
    通常,如果你要想提供很高的数据保障性,那么建议你同时使用两种持久化方式。
    如果你可以接受灾难带来的几分钟的数据丢失,那么你可以仅使用RDB。
    很多用户仅使用了AOF,但是我们建议,既然RDB可以时不时的给数据做个完整的快照,并且提供更快的重启,所以最好还是也使用RDB。
    因此,我们希望可以在未来(长远计划)统一AOF和RDB成一种持久化模式。

    在数据恢复方面:
    RDB的启动时间会更短,原因有两个:
    一是RDB文件中每一条数据只有一条记录,不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
    另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要远小于AOF日志的加载。

    ————————————————–

    灾难恢复模拟
    既然持久化的数据的作用是用于重启后的数据恢复,那么我们就非常有必要进行一次这样的灾难恢复模拟了。
    据称如果数据要做持久化又想保证稳定性,则建议留空一半的物理内存。因为在进行快照的时候,fork出来进行dump操作的子进程会占用与父进程一样的内存,真正的copy-on-write,对性能的影响和内存的耗用都是比较大的。
    目前,通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足,达到了数据可持久化。
    即Master上Snapshot和AOF都不做,来保证Master的读写性能,而Slave上则同时开启Snapshot和AOF来进行持久化,保证数据的安全性。

    首先,修改Master上的如下配置:
    $ sudo vim /opt/redis/etc/redis_6379.conf

    #save 900 1 #禁用Snapshot
    #save 300 10
    #save 60 10000
    
    appendonly no #禁用AOF

    接着,修改Slave上的如下配置:
    $ sudo vim /opt/redis/etc/redis_6379.conf

    save 900 1 #启用Snapshot
    save 300 10
    save 60 10000
    
    appendonly yes #启用AOF
    appendfilename appendonly.aof #AOF文件的名称
    # appendfsync always
    appendfsync everysec #每秒钟强制写入磁盘一次
    # appendfsync no  
    
    no-appendfsync-on-rewrite yes   #在日志重写时,不进行命令追加操作
    auto-aof-rewrite-percentage 100 #自动启动新的日志重写过程
    auto-aof-rewrite-min-size 64mb  #启动新的日志重写过程的最小值

    分别启动Master与Slave

    假设master当掉了

    在Slave上复制数据文件:appendonly.aof,dump.rdb  拷贝到master相应的位置

    启动Master上的Redis

    不出意外,恢复成功

    在此次恢复的过程中,我们同时复制了AOF与RDB文件,那么到底是哪一个文件完成了数据的恢复呢?
    实际上,当Redis服务器挂掉时,重启时将按照以下优先级恢复数据到内存:
    1. 如果只配置AOF,重启时加载AOF文件恢复数据;
    2. 如果同时 配置了RDB和AOF,启动是只加载AOF文件恢复数据;
    3. 如果只配置RDB,启动是将加载dump文件恢复数据。
    AOF的优先级要高于RDB
  • npm常用命令(nodejs)

    npm install <name>安装nodejs的依赖包

    例如npm install express 就会默认安装express的最新版本,也可以通过在后面加版本号的方式安装指定版本,如npm install express@3.0.6

    npm install <name> -g 将包安装到全局环境中

    但是代码中,直接通过require()的方式是没有办法调用全局安装的包的。全局的安装是供命令行使用的,就好像全局安装了vmarket后,就可以在命令行中直接运行vm命令

    npm install <name> –save 安装的同时,将信息写入package.json中

    项目路径中如果有package.json文件时,直接使用npm install方法就可以根据dependencies配置安装所有的依赖包

    这样代码提交到github时,就不用提交node_modules这个文件夹了。

    npm init 会引导你创建一个package.json文件,包括名称、版本、作者这些信息等

    npm remove <name>移除

    npm update <name>更新

    npm ls 列出当前安装的了所有包

    npm root 查看当前包的安装路径

    npm root -g 查看全局的包的安装路径

    npm help 帮助,如果要单独查看install命令的帮助,可以使用的npm help install

  • tar 压缩/解压包

    tar包压缩的时候用cvf参数,解压的时候用xvf参数
    或压缩的时候用czvf参数,解压的时候用xzvf参数

    bz 包遇到了,就把z参数换成相应j参数

  • centos6 安装spawn-fcgi No package spawn-fcgi available.

    32位centos6:

    http://mirrors.neusoft.edu.cn/epel/5/i386/repoview/epel-release.html
    
    rpm -Uvh http://mirrors.neusoft.edu.cn/epel/5/i386/epel-release-5-4.noarch.rpm

    64位centos6:

    rpm -Uvh http://mirrors.neusoft.edu.cn/epel/5/x86_64/epel-release-5-4.noarch.rpm
    
    yum install spawn-fcgi
  • 墨菲定律

    1.别试图教猫唱歌,这样不但不会有结果,还会惹猫不高兴。
    2.别跟傻瓜吵架,不然旁人会搞不清楚,到底谁是傻瓜。
    3.不要以为自己很重要,因为没有你,太阳明天还是一样从东方升上来。
    4.笑一笑,明天未必比今天好。
    5.好的开始,未必就有好结果;坏的开始,结果往往会更糟。
    6.你若帮助了一个急需用钱的朋友,他一定会记得你——在他下次急需用钱的时候。
    7.有能力的——让他做;没能力的──教他做;做不来的──管理他。
    8.你早到了,会议却取消;你准时到,却还要等;迟到,就是迟了。
    9.你携伴出游,越不想让人看见,越会遇见熟人。
    10.你爱上的人,总以为你爱上他是因为:他使你想起你的老情人。
    11.你最后硬着头皮寄出的情书;寄达对方的时间有多长,你反悔的时间就有多长。
    12.东西越好,越不中用。
    13.一种产品保证60天不会出故障,等于保证第61天一定就会坏掉。
    14.东西久久都派不上用场,就可以丢掉;东西一丢掉,往往就必须要用它。
    15.你丢掉了东西时,最先去找的地方,往往也是可能找到的最后一个地方。
    16.你往往会找到不是你正想找的东西。
    17.你出去买爆米花的时候,银幕上偏偏就出现了精彩镜头。
    18.另一排总是动的比较快;你换到另一排,你原来站的那一排,就开始动的比较快了;你站的越久,越有可能是站错了排。
    19.一分钟有多长? 这要看你是蹲在厕所里面,还是等在厕所外面。
    20、计划没有变化快。
    21、欠帐总是要还的。
    22、做恶总是要遭报应的,现在未报,不是不报,只是时候未到。
    23、该来的总是要来的。
    24、明天又是一个新的开始。
    25、你越是害怕的事物,就越会出现在你的生活中。
    26、往往等公车太久没来,就走了的人,刚走公车就来了。
    27、关键时刻掉链子。
    28、越想要什么就越能得到什么。
    29、人出来混,总是要还的。
  • 移动互联网产品设计的原则

    1、 绝不考虑Web形态,一切考虑都基于APP。

    2、 产品优先级:

    (1)有趣高于功能。产品必须有趣,必须Cool,才可能形成传播和口碑。

    (2)功能高于交互。明确的功能满足明确的需求,用户不会在意炫酷交互效果。

    (3)交互高于UI。便捷、快速的交互设计为先,围绕具体功能实现UI,而非有优质UI方案为此专门设立一个功能。

    3、 聚焦:一个APP只做一件事情,一个大而全的APP意味着全面的平庸。

    4、 永远一维化:让用户在一个维度里解决具体的问题,Twitter的Timeline就是一个好的范例。而类似Facebook、Path那样的滑出式菜单则是一个灾难,因为这使得产品拥有两个维度,加大了用户理解的困难。

    5、 保持主干清晰,枝干适度。产品的主要功能架构是产品的骨骼,它应该尽量保持简单、明了,不可以轻易变更,让用户无所适从。次要功能丰富主干,不可以喧宾夺主,尽量隐藏起来,而不要放在一级页面。

    6、 不要让用户选择。同一个页面之内,有多个入口;同一个功能,有多个实现方式;同一个界面,有多个展示方式。这对于用户来说是一种痛苦而非享受,因为他们只会因此而感觉到困惑和恐惧。用户宁可采取重复操作漫长而固定的操作路径,也不愿意使用多变的快捷方式。

    7、 隐藏技术,永远展现简单的、人性化的、符合人类直觉的界面。开发不可以为了炫技而展示功能,产品不可以为了炫耀而功能堆砌。

    8、 拒绝个性化。除了依靠设计特色而立身的APP,换肤一类的个性化设计,除了让产品经理幻觉自己做了许多工作而自我满足之外,没有任何价值。它只能证明产品经理对自己的产品不自信,因为自信的产品经理凭借默认皮肤就可以满足用户。延伸开去,一个好的产品,其功能应该满足全球用户需求,无需为地区做特别定制化。

    9、 产品一定程度上是为了满足人性中的贪嗔痴,这是用户的痛点。能把握住之后,产品经理应该超越其上,用产品帮助人们得以解脱。

    10、想清楚自己究竟要做什么,不去迎合上司,不去讨好用户,不去取悦自己。

    11、分类!分类!分类!这是产品经理在确定产品主要功能构架之后,唯一应该为用户做的事情。分类无助于降低产品使用的难度,但是可以帮助用户认知产品和周边的世界。

    12、永远围绕功能而做设计,永远不要倒过来做这件事情。

    13、一个产品的基本功能不受用户认可,做加法也无济于事。

    14、想不清楚一个功能点之前,宁可不做。

    15、千万不要让用户在产品里“管理”什么。