一、配置网络
在使用Vmware Workstation10.2测试过程中，发现可能部分物理机100M网卡不能正常识别，换到了1000M网卡上
测试能正常识别虚拟网卡
Centos7系统的网卡设备命名有所变化，可参考CentOS 7下网络设备命名，个人感觉既然
学习新系统，完全没必要换成传统的识别名方式，要勇于接受新知识~
1.通过编辑文件修改网络配置
vim /etc/sysconfig/network-scripts/ifcfg-eno16777736 HWADDR=00:0c:29:14:34:51 TYPE=Ethernet BOOTPROTO=static DEFROUTE=yes PEERDNS=yes PEERROUTES=yes USERCTL=no NM_CONTROLLED=no IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME=eno16777736 ONBOOT=yes IPADDR=192.168.117.128 NETMASK=255.255.255.0 GATEWAY=192.168.117.2 DNS1=192.168.117.2 |
关键配置：
TYPE=Ethernet
BOOTPROTO=static
NAME=eno16777736
ONBOOT=yes
IPADDR=192.168.117.128
NETMASK=255.255.255.0
GATEWAY=192.168.117.2
DNS1=192.168.117.2
cat /etc/resolv.conf
nameserver 192.168.117.2
2.通过文本工具nmtui修改网络配置(RHEL7/CentOS7默认安装,前提需要开启NetworkManager.service才可以使用)
yum -y install NetworkManager-tui
nmtui-edit eno16777736 修改网卡配置
nmtui-connect eno16777736
重启网络
systemctl restart network
systemctl status network
修改主机名：
vim /etc/hostname
centos7.simlinux.com
退出重新登录即可生效
二、关闭不必要的服务
最小化安装的Centos7系统并没有nano、vim、wget、curl、ifconfig、lsof命令，这里首先安装一下：
yum -y install nano vim wget curl net-tools lsof
可以通过netstat和lsof查看系统都运行了哪些服务，将不必要的进行关闭
systemctl stop postfix systemctl stop avahi-daemon systemctl disable postfix systemctl disable avahi-daemon systemctl list-unit-files 查看正在运行服务的状态报告 systemctl start httpd.service 启动服务 systemctl stop httpd.service 关闭服务 systemctl restart httpd.service 重启服务 systemctl reload httpd.service 重新加载服务 systemctl disable httpd.service 开机不启动 systemctl enable httpd.service 开机启动 systemctl status httpd.service 查看服务运行状态 systemctl show httpd.service 显示服务或任务的属性 systemctl list-dependencies httpd.service 检查服务依赖关系 systemctl is-enabled httpd.service 检查服务是否开机启动及级别 systemctl -H 192.168.117.128 start httpd.service 启动192.168.117.128机器上的httpd服务 |
现在有许多
文章提出要加强中国
软件质量，必须进行第三方
软件测试，2005年6月2日信息产业部中国软件测评机构联盟成立，规范第三方软件测试，但是我认为，第三方软件测试的时候尚未到来。主要原因如下：
软件企业对软件测试仍旧不够重视
现在在中国软件企业的高层领导对于软件测试仍旧不够重视，软件就是编程的思想仍旧深深的扎生在许多企业高层领导的脑海中。编码才是真正的软件
工作，测试可有可无。编码能够产生真正的产品，而测试不能，所以测试工作往往可以由程序员自己来执行，由于思路的局限性，这样的测试往往没有较好的结果。在一个项目中为了尽早提交软件产品，往往对测试压缩，压缩再压缩，使测试就是简单的走过场，甚至没有测试。并且测试人员往往让刚刚走出校门的大学毕业生已尽快熟悉企业产品为目的进行测试，而在国外软件测试工程师的水平要求比
软件开发工程师的水平要高的许多，只有这样才可以发现更多的缺陷。对软件测试的不重视程度，往往大大增加售后服务的费用。这样的结果导致软件公司给第三方软件测试公司报价及低，但工作量又十分庞大，软件测试公司没有盈利的空间。
国家机构的垄断
许多国家机构也发现软件第三方测试市场，他们对企业软件进行测试，发放国家认可的证书。这就给民间的软件测试公司的成立带来了很大的压力，这些企业的创办者经过测试很难给企业发放这些证书。所以许多软件企业纷纷停止这项业务，而转入更容易赚钱的其他项目，比如软件测试培训。而需要第三方软件测试的企业也找国家直属的企业进行产品认证。
第三方软件测试需要测试人员具有相当实力的测试水平，然而在中国大学课程中几乎没有一门课程能够系统
学习到软件测试理论和技巧的，而由于企业对软件测试的不够重视，即使有一定年限工作的工程师也水平及其有限。
大的国内公司揽包第三方测试
许多产品的测试往往需要进行第三方测试，比如软件本地化测试。
微软的产品，生产一个就要产生世界各地本地化版本，如果这些工作都让微软来做，得不伤势。而国内许多大企业，他们一直与这些大的国际企业有着长年的友好关系。他们往往可以接下测试任务，在社会上招聘测试工程师，号称赴某某大公司工作，然而项目一旦完毕，就将这些人员解散。
由于没有建立起一套正规的游戏规则，所以给软件测试公司的大量开辟带来了许多不利因素，虽然业界业认识到了第三方测试的重要性，但是在目前条件下成立测试公司路途仍旧十分艰难。但本人认为测试公司的大规模成立势在必行，经过市场的不断完善，在三到四年后可能形成规模。由于嵌入式软件和一产品为主在软件企业越来越多，他们开发出来一套产品后，主要的工作是对产品的维护和性能优化。比如数字机顶盒软件，杀病毒软件等等。他们成立一个测试部门没有必要，而第三方测试正是他们需要的。立志与创建中国软件民间测试公司的朋友们，做好充足准备，属于我们的日子即将到来。
摘 要：不确定性是项目的主要特征之一,但现有的风险管理理论和方法多数是针对项目风险结果的,存在管理思想和对象局限性。通过对项目风险管理理论的梳理,分类和识别项目不确定性,在此基础上不断弥补信息缺口,对项目风险带来的威胁和机会统一管理,可以有效地改变传统项目风险管理面向项目风险后果的被动管理的弊端,使项目风险管理由原来被动地应对和管理项目风险后果转变为主动的增加项目价值式的管理。
项目内外部环境的复杂性以及项目本身的一次性、独特性等特点,使得项目存在着大量的不确定性。项目不确定性的存在使项目的管理者及其他相关利益者,在无法确知行动结果的情况下制定项目目标和行动计划,在项目的实施中逐渐调整,给项目带来各种风险,有时甚至会改变项目的主要目标和行动计划。如2008年北京奥运场馆项目实施过程中,根据世奥官员和专家的建议,对建设标准和竣工时间都做了变更。随着科技的飞速发展,各种不确定性发生的可能性大量增加,造成的风险规模也日益扩大,使得面向项目不确定性的风险管理
工作有了更大紧迫性。风险管理就是将项目的不确定性事件或活动,努力转化为项目的确定性事件或活动的过程。然而现有的项目风险管理理论和实践主要是针对项目风险结果,缺乏对引发项目风险结果的不确定性事件进行识别、预防和规避的研究。在这种风险管理过程中,项目管理人员不是直接管理项目不确定性,而是被动地接受项目的不确定性结果,并用面向风险结果的方法进行管理。本文从项目不确定性的角度出发,分析了现有项目风险管理研究中存在的不足,在此基础上,提出了面向不确定性的管理模型,并对项目不确定性的分类、弥补信息缺口的途径进行了研究。
一、现有项目风险管理缺陷分析
最早的正式开展项目风险管理的研究机构是美国造价工程师协会,在1992年成立专门的项目风险管理委员会,1995年推出“项目风险管理字典”,1998年推出项目风险管理手册。由于对项目风险管理的研究历史较短,使得人们对项目风险管理的认识还有相当的局限性。现有的风险管理工作存在诸多缺陷,主要表现为:
1、管理思想的局限性。人们对风险的认识是从巨大损失开始的,1953年,通用汽车公司的一场火灾震动了美国企业界和学术界,这场火灾成了风险管理科学发展的契机。所以,传统的风险管理常被视为一种保险,一个缓解不确定性的缓冲区。风险研究多数是针对损失进行的,没有很好地研究应该如何去抓住项目不确定性所带来的机遇问题。项目风险管理的目标是如何将损失减少到最低程度,放弃了抓住“机遇”的努力。这种面向项目损失的管理模式采取风险“应对”的方式进行风险管理,往往丧失了“变坏事为好事”的时机。现代
项目管理认为,从项目最初的定义与决策阶段就应该通过项目风险管理去对项目的不确定性做好转化工作,努力实现“变坏事为好事”,做好项目风险损失转化为项目风险机遇的管理工作。因为此时人们对于项目的影响力较高,如果此时积极开展项目风险管理的话就有可能抓住各种“变坏事为好事”的机遇。
2、管理对象的局限性。传统的项目风险管理主要是针对项目风险的识别、度量、应对和监控的技术研究,没有对引发项目风险的不确定性事件进行深入研究。美国项目管理协会(PMI)开发的项目管理知识体系(PMBOK)中,对项目风险的研究亦是如此。这种管理方式导致人们在项目风险管理中,一是过于关注项目已设定好的目标,忽视对这些目标以外目标的不确定性的应对。二是过于关注如何减少风险损失,忽略风险可能带来的收益。三是使风险管理工作滞后,在项目设计阶段开始介入,错过了不确定性最大的项目定义与决策阶段。四是传统的风险研究往往只涉及到静态风险,无法处理由各种心理因素及环境等不确定性所造成的动态风险。因此,这种管理方式使人们总是处于一种被动“应对”地位,不利于通过增加信息和数据等手段主动降低项目不确定性,也不利于进一步提高项目风险管理的水平和能力。尽管有些学者认识到了这一点,并做了一些补充与完善,以便更直接地对项目不确定性开展管理,但是由于理论基础方面的缺陷,使得效果并不理想。
二、面向项目不确定性的风险管理方法
第一,面向不确定性的项目风险管理应以项目价值认知为基础。由于项目管理的根本目标是满足和超越项目利益相关者的要求与期望,所以面向不确定性的项目风险管理也要为这一目标服务,从对项目价值的认知和分析着手,明确项目风险管理目标,实现项目价值的最大化和项目成本的最小化。
第二,识别项目的不确定性。通过对项目的不确定性进行识别,能更好地认识和分析项目的不确定性,开展对项目不确定性的直接管理,并使应对措施更加有效。此外,这种方法使得项目风险管理过程更具一般性和普遍性,能够更有效地提高人们对于项目不确定性分析与管理的能力,从而避免被动地对项目风险后果进行管理。
第三,弥补项目信息缺口。项目的全部事件可以分成三种类型:第一种是确定性事件,此时人们知道项目事件是否肯定发生(P=1或P=0)(P是指事件发生的概率,以下同);第二种是不确定性事件,此时人们不知道其是否肯定发生,但是人们知道其发生的概率(P<1);第三种是完全不确定性事件,此时人们不但不知道项目事件是否发生,而且也不知道项目事件发生的概率(P=?)。
根据这种分类可知:正是因为存在信息缺口才造成了人们不能确定项目某种事件是否确定发生,而这种不确定性才是引发项目风险后果的根本原因。因此,任何项目的风险性来自于项目的不确定性,而任何项目的不确定性根本来源在于人们在项目信息方面的缺乏(信息缺口)。面向不确定性的项目风险管理方法要通过对于项目不确定性因素的深入认识和分析,不断搜集项目信息,弥补信息缺口,降低项目的不确定性,有效地进行项目风险管理。这种面向不确定性的项目风险管理方法对于人们通过
学习和积累去拓展自己的认识能力给予应有的重视,更注重通过提高组织对于项目不确定的认识去开展项目的风险管理,所以这种项目风险管理方法是一种主动的管理方法。第四,统一管理项目的威胁和机会。面向不确定性的项目风险管理方法从分析并消减项目的不确定性入手开展项目风险管理,强调对项目风险机会的管理,因为项目风险机会是对项目价值提升的直接贡献。因此,这一方法将威胁管理和机会管理统一于同一个项目风险管理过程进行度量。项目风险管理过程与“风险”的定义是平行的。既然将风险定义为机会和威胁,那么机会管理和威胁管理就需要通过一个过程来实现。要通过机会的度量和分析,抓住“机遇”变“坏事为好事”。
在以上分析的基础上,本研究提出了面向不确定性的项目风险管理的方法模型。通过这套方法不仅可以有效地将项目风险管理向前推进到针对项目不确定性的管理层次,从而实现对于项目风险损失和风险机会的有效管理,同时还可以不断地提高项目组织的风险管理能力。的认知出发,通过分析和认识项目所涉及的不确定性,进一步针对这些不确定性去开展信息的收集,从而努力去降低项目的不确定性和风险性,最终分析应对项目风险所存在的机会与威胁的措施,并通过实施这些措施来有效地管理项目,分析损失和机遇,达到提高项目价值的目的。实际上这一系列过程是一种学习的过程,人们可以随着项目的开展不断地提高组织对于项目不确定性的管理能力。因此,这会一种积极主动地开展项目风险管理的方法,也是管理项目风险的主导性方法与过程。虽然在这一面向不确定性的项目风险管理过程中,也会不可避免地出现一些无法预料的风险性事件,但是由于人们注重从项目价值的角度来分析项目不确定性,并通过收集信息来降低项目的不确定性,这会使得人们对项目风险的认识和采取应对措施的主动性和有效性大为提高。
三、面向不确定性的项目风险管理程序
通过以上对面向不确定性的项目风险管理方法的分析,与传统的项目风险管理过程相比较,本研究重点从识别项目的不确定性、弥补项目信息缺口及项目机会和损失度量三个步骤探讨如何开展面向不确定性的项目风险管理。
1、识别项目的不确定性。为更好地开展项目不确定性的识别活动,需要用全新的观念和视角去认识项目的不确定性。一些学者从不同的研究视角在这方面做了一些探索性的研究,如下表所示。在借鉴表中研究成果的基础之上,本文按照引发项目不确定性的原因,将项目不确定性分为四类:(1)项目目标的不确定性。由于人们的主观意愿和期望会随着人们所掌握的项目信息的增长和对于自我需求认识的不断加深而发生变化,结果就会造成项目目标的不确定性。这既包括人们根据客观事物的发展变化而做出的项目目标修订,也包括人们根据自己的意愿改变而对项目目标的调整。(2)项目活动的不确定性。项目具有的一次性和独特性等特点决定了项目所需开展的活动会具有一定的不确定性,同时由于项目活动之间的作用机制的复杂性,彼此之间会产生积极或消极的相互影响,这也会造成项目的不确定性。因此项目活动的不确定性既包括为实现项目目标所需的项目活动的不确定性,又包括各项目活动间关系的不确定性两个方面.(3)项目活动环境与条件的不确定性。项目活动是在一定的环境与条件下开展的。而环境是一个复杂的、动态的系统,这个系统又时刻对项目活动产生影响,从而引发项目的不确定性。这包括项目活动的外部环境和内部条件两方面的不确定性,其中项目外部环境的不确定性是指项目所处微观和宏观环境的各种意外变动所带来的不确定性,项目内部条件的不确定性是指项目组织内部条件方面的各种变动所造成的项目不确定性。(4)项目技术与管理方法的不确定性。这是指项目所采用的技术和管理方法所产生后果的不确定性,其中包括由于项目技术方法的不成熟或不易掌控而造成项目技术后果的不确定性、以及由于项目管理方法中的权变而造成的后果的不确定性。项目技术后果的不确定性和项目管理后果的不确定性,都会给项目带来一定的不确定性。
2、弥补项目信息缺口。项目风险管理最有效的途径是努力去降低项目的不确定性,而降低项目的不确定性的根本出路在于消除和减小项目的信息缺口。图2显示了面向消除项目不确定性的项目风险管理模型。由图2可知,真正主动的项目风险管理应该从增加项目的信息以消除项目信息缺口入手,因为只有这样才会通过降低项目的不确定性去管理好项目风险。项目最初的不确定性可能是一种完全的不确定性,即人们既不知道项目的风险损失和收益(L=?,B=?),也不知道项目风险收益和损失的概率(P(B)=?,P(L)=?)。但是,人们可以通过收集更多的信息去了解项目风险损失或收益,从而确定或假定项目风险损失或收益(P=?,P(L&B)=1或0)。更进一步,人们可以收集更多的信息和深入地认识项目风险发生的概率(P),使得项目风险概率从P=?变化到P<1,即有Pi<1和∑Pi=1;从理论上说,最终人们可以通过收集信息而使得Pi=1或Pi=0,完全消除项目的不确定性。虽然这种情况只是一种理想境界,但是人们只要通过不断提高自己的认知能力,并且随着项目的展开不断认识它,就一定能够最终达到这一目标。
3、项目的机会与损失度量。项目的风险是给项目带来的损失(Loss)或收益(Benefit)的可能性,因此,项目的风险结果可以用下面的公式来描述:Rp=Σni=1Li×Pi+Σmj=1Bj×Pj其中:Rp为项目风险后果,Σni=1Li×Pi为项目风险损失,Σmj=1Bj×Pj为项目风险收益或机会。项目的机会或损失需要一同评价和估量。这种度量主要包括四个方面:
一是项目机会和损失可能性的度量。这是度量工作的首要任务,由项目管理者或专家通过历史和现有信息作出判断。pmp.mypm.net
二是项目机会和损失结果的度量。这是用以分析和估计项目风险结果的程度。主要使用期望值法、模拟仿真法和专家决策法等方法。三是项目机会和损失影响范围的度量。这是用以分析和估计项目风险影响范围的大小。主要使用模拟仿真法和专家决策法等方法。四是项目机会和损失发生时间的度量。这是用以分析和估计风险发生的时间。
四、结论
面向不确定性的项目风险管理方法,能够直接管理引起项目风险的不确定性事件,因此,可以有效地改变传统项目风险管理面向项目风险后果的被动管理的弊端,使项目风险管理由原来被动地应对和管理项目风险后果转变为主动地增加项目价值式的管理。这种方法从项目价值认知着手,通过分类和识别项目不确定性事件,能够不断弥补信息缺口,对项目风险存在的威胁和机会统一管理,有效地提高整个项目管理的成功度、效益与效率,增强项目组织的风险管理的能力。
渗透测试，是为了证明网络防御按照预期计划正常运行而提供的一种机制。
渗透测试的分类实际上渗透测试并没有严格的分类方式，即使在
软件开发生命周期中，也包含了渗透测试的环节，但根据实际应用，普遍认同的几种分类方法如下：
方法分类
1、黑箱测试
黑箱测试又被称为所谓的“Zero-Knowledge Testing”，渗透者完全处于对系统一无所知的状态，通常这类型测试，最初的信息获取来自于DNS、Web、Email及各种公开对外的服务器。
白盒测试与黑箱测试恰恰相反，测试者可以通过正常渠道向被测单位取得各种资料，包括网络拓扑、员工资料甚至网站或其它程序的代码片断，也能够与单位的其它员工（销售、程序员、管理者……）进行面对面的沟通。这类测试的目的是模拟企业内部雇员的越权操作。
3、隐秘测试
隐秘测试是对被测单位而言的，通常情况下，接受渗透测试的单位网络管理部门会收到通知：在某些时段进行测试。因此能够监测网络中出现的变化。但隐秘测试则被测单位也仅有极少数人知晓测试的存在，因此能够有效地检验单位中的信息安全事件监控、响应、恢复做得是否到位。
目标分类
对MS-SQL、
Oracle、
MySQL、Informix、Sybase、DB2、Access等数据库应用系统进行渗透测试。
3、应用系统渗透
对渗透目标提供的各种应用，如ASP、CGI、JSP、PHP等组成的WWW应用进行渗透测试。
4、网络设备渗透
对各种防火墙、入侵检测系统、网络设备进行渗透测试。
渗透测试工具
渗透测试是一种利用模拟黑客攻击的方式，来评估计算机网络系统 攻击步骤
安全性能的方法。通常的黑客攻击包括预攻击、攻击和后攻击三个阶段；预攻击阶段主要指一些信息收集和漏洞扫描的过程；攻击过程主要是利用第一阶段发现的漏洞或弱口令等脆弱性进行入侵；后攻击是指在获得攻击目标的一定权限后，对权限的提升、后面安装和痕迹清楚等后续
工作。与黑客的攻击相比，渗透测试仅仅进行预攻击阶段的工作，并不对系统本身造成危害，即仅仅通过一些信息搜集手段来探查系统的弱口令、漏洞等脆弱性信息。为了进行渗透测试，通常需要一些专业工具进行信息收集。渗透测试工具种类繁多，涉及广泛，按照功能和攻击目标分为网络扫描工具、通用漏洞检测、应用漏洞检测三类。
什么是A/B测试?
A / B测试，即你设计的页面有两个版本(A和B)，A为现行的设计， B是新的设计。比较这两个版本之间你所关心的数据(转化率，业绩，跳出率等) ，最后选择效果最好的版本。
A / B测试不是一个时髦名词。现在很多有经验的营销和设计
工作者用它来获得访客行为信息来提高转换率。这是一种很有效的方式，并且由于各种分析工具的发展，
测试成本也越来越低，因此很多电商网站都会采用。
但是大部分人对于A/B测试只有一个基本的认知，如何将它的效应发挥到最大?本文提供19个建议。
1、减少页面摩擦
页面摩擦就是用户在浏览网页的过程中遇到了一些阻碍，会降低转换率。通常造成页面摩擦的原因有三：
信息栏——要求用户填写信息
步骤指引——网站地图太复杂
长页面——太长的页面会磨掉用户的耐心。
最好的状态是一种“不在场”的状态，就像人的身体一样，没有病痛的时候你不会记得身体的存在。用户用得行云流水，所有的步骤都顺理成章，这才是最好的体验。
2、信息输入焦虑
有的用户不愿意输入太多信息，因为不确定输了那么多信息以后会不会得到应有的回馈(有的人填了一大推信息之后得到一封广告邮件之类的东西，会产生一种被坑的感觉)。越多的信息需要填写，用户流失率就会越高。
但如果用户很明确知道他们的努力可能会换来什么回馈，他们就很乐意按照网页的指引一步一步往下走，也愿意填那些表格。
3、明晰每一个页面的目的
有时候“目标清晰”比什么都重要，回答下面3个问题，你可以省略很多不必要的步骤|：
这个页面是什么?让用户清晰地知道他到了哪一个步骤;
我可以再这里干什么?让用户一眼看明白这一个页面是为了展示什么;
为什么我要在这个页面?要把核心优势直观展示出来。用户不需要去思考在这一页可以干什么，自然也不需要思考为什么要在这一页停留。
用户都很懒，一旦他弄不明白他在哪个网页上可以做什么，他可能马上就关掉那个网页。
4、倾听用户需求
一个B2C的网站，最好是把B和C都找来，听听他们各自的需求，请他们互相提要求。请用户试用网站，并观察他们的使用习惯，这总是有百利而无一害的。
最后，单独留下C，请他们说说更深层的意见，以及他们是如何与网站交互，哪些功能很好，哪些多余等等。
5、定价
对于电商网站来说，定价是一件至关重要的事。消费者除了关心数字，还关心价值，除了数字，还可以在文案、图片上面做工作。一个完美的定价不是一味只考虑便宜，而是要让消费者觉得他占到了便宜。
6、尝试提价
不要想当然地认为价钱便宜就一定会提升销量，反之，价格高也不等于销量少。有的消费者看到价钱便宜的商品会懒得点开看，因为觉得“便宜没好货”，实际上那个商品质量还不错——所以定价要秉着一分货一分钱的原则。
此外，还可以尝试小额的加价。比如一次加2%，看看销售量如何，在消费者承受范围之内再加个2%，小额的加价不会让用户觉得你在漫天要价。 7、测试社交因素
很多产品旁边都有一键分享至社交网站的功能。但是，电商们有真正调查过这些功能会提升还是抑制销量吗?
我看过一个很有意思的调研报告：说是一个祛痘产品的页面因为有了分享功能而减少了25%的销量。毕竟，有的敏感的商品消费者是不愿意和别人分享的(设想一下如果人家买的是杜蕾斯或是什么，你也要他分享到Facebook上吗)。
8、把广告位放低一点
常识可能告诉你广告位越高越显眼就会给目标页面带来更多流量——但是A\B测试通常就是要测那些自以为是常识的东西。
你花了一定的成本获得了一个位置很好的广告位，这个广告为你提升了50%的销量，但实际上这些收益还抵不上你为广告花费的成本。稍微算一算你就知道投入产出比了。这个报告告诉我们：即便你认为是常识的东西，也不妨去做一个A\B测试。
9、测试每一个“黄金准则”
上一条告诉你要测试常识性的东西，这一条还要补充一点：测试看起来是黄金准则的准则。黄金准则之所以黄金，也是因为经过了无数次的测试(那么也不在乎再多倍测试一次)，比如标题党会让客户对你的信誉产生质疑，这就是一条黄金准则。
但是，非常时段可以用一些非常方法，如果销售结果总是不如预期，那么你也可以去测一下是不是某条黄金准则出了问题。
10、利用一些工具
如果你需要找到数据变动的原因又不想花太多时间，可以用一些第三方工具，比如Silverback，可以帮你记录用户在网页上的操作并给出有效的数据。
11、时刻记得支撑起转化率的“三只脚”
相关性：你的登陆页是否满足用户的预期?你能保持这种风格的连贯性?
价值：你能符合用户的价值期待吗?你能给他们想要的东西?
应激性：用户知道自己来这个网站要干什么吗?用户知道要怎么操作吗?
12、试试不同的遣词
微小的网页调整会改变转化率，微小的用词上的改变当然也可以引起不同的结果。比如，“Join Now”和“Buy Now”哪一个更能刺激用户的购买欲?测试一下。同理，整个网页上的文案风格的转变也能造成不同的效果。
13、一个页面只展示一个信息
转化率最高的页面都有一个共同特点：一个页面集中展示一个信息，不要让你的用户感到迷茫，让他们看一眼就知道想干什么可以干什么。
14、测试哪个属性是最吸引的
一个商品有无数个属性，价格、颜色、材质、产地，等等，那一种属性对用户构成最致命的吸引?一个一个地尝试。再一次重申，不要想当然的替消费者决定他们在标题里最想看到的是哪一个，你要测试才知道。
15、连小得变态的细节都不放过
2007年AJ Kohn测试了两个域名www.YourDomain.com和www.yourdomain.com，仅仅是首字母大小写的问题，结果令人大吃一惊：大写的那个点击率比小写的高出53%!这个事件说明有时候你看不上眼的小细节也能造成很不同的后果。
16、完美?No!
有的人想要做出“完美”的登录页面，可是我想告诉你，没有完美的页面，A\B测试的精髓就是让每一次测试的结果都比上次更好。
那句广告语是怎么说的?没有最好，只有更好。
17、寻求成本更低的测试方式
A\B测试不是要让你用最新的技术、最新的软件或者算法，大部分时候一个纸上的原型或者线框里5秒钟的测试都能帮你找到方向。好好利用那些简单、低廉的测试方式。
18、等到测试完成
上文里无数次地强调不要想当然，在测试没有结束之前，所有的数据都可能是片面的，不要想着用部分的结果去替代全部。
19、永远不停地测试
A\B测试的精髓就在于：永远不要满足于目前的结果，总有更好的解决方案。一次的A\B测试也许能提升50%甚至更好的转换率，但这并不意味着到顶了。生命不息，测试不止。
转载请注明来自“柳大的CSDN博客”：http://blog.csdn.net/poechant
更多文章请浏览CSDN专栏《Nginx高性能Web服务器》或服务器后端开发系列——《实战Nginx高性能Web服务器》
Nginx 的 HttpUpstreamModule 提供对后端（backend）服务器的简单负载均衡。一个最简单的 upstream 写法如下：
upstream backend {
server backend1.example.com;
server backend2.example.com;
server.backend3.example.com;
}
server {
location / {
proxy_pass http://backend;
}
}
1、后端服务器
通过 upstream 可以设定后端服务器，指定的方式可以是IP 地址与端口、域名、UNIX 套接字（socket）。其中如果域名可以被解析为多个地址，则这些地址都作为 backend。下面举例说明：
upstream backend {
server blog.csdn.net/poechant;
server 145.223.156.89:8090;
server unix:/tmp/backend3;
}
第一个 backend 是用域名指定的。第二个 backend 是用 IP 和端口号指定的。第三个 backend 是用 UNIX 套接字指定的。
2、负载均衡策略
Nginx 提供轮询（round robin）、用户 IP 哈希（client IP）和指定权重 3 种方式。
默认情况下，Nginx 会为你提供轮询作为负载均衡策略。但是这并不一定能够让你满意。比如，某一时段内的一连串访问都是由同一个用户 Michael 发起的，那么第一次 Michael 的请求可能是 backend2，而下一次是 backend3，然后是 backend1、backend2、backend3……在大多数应用场景中，这样并不高效。当然，也正因如此，Nginx 为你提供了一个按照 Michael、Jason、David 等等这些乱七八糟的用户的 IP 来 hash 的方式，这样每个 client 的访问请求都会被甩给同一个后端服务器。（另外，由于最近发现很多网站以不留原文链接的方式盗取本博博文，所以我就在这插一下本博的地址“http://blog.csdn.net/poechant”）具体的使用方式如下：
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server.backend3.example.com;
}
这种策略中，用于进行hash 运算的 key，是 client 的 C 类 IP 地址（C 类 IP 地址就是范围在 192.0.0.0 到 223.255.255.255 之间，前三段号码表示子网，第四段号码为本地主机的 IP 地址类别）。这样的方式保证一个 client 每次请求都将到达同一个 backend。当然，如果所 hash 到的 backend 当前不可用，则请求会被转移到其他 backend。
再介绍一个和 ip_hash 配合使用的关键字：down。当某个一个 server 暂时性的宕机（down）时，你可以使用“down”来标示出来，并且这样被标示的 server 就不会接受请求去处理。具体如下：
upstream backend {
server blog.csdn.net/poechant down;
server 145.223.156.89:8090;
server unix:/tmp/backend3;
}
还可以使用指定权重（weight）的方式，如下：
upstream backend {
server backend1.example.com;
server 123.321.123.321:456 weight=4;
}
默认情况下 weight 为 1，对于上面的例子，第一个 server 的权重取默认值 1，第二个是 4，所以相当于第一个 server 接收 20% 的请求，第二接收 80% 的。要注意的是weight 与 ip_hash 是不能同时使用的，原因很简单，他们是不同且彼此冲突的策略。
3、重试策略
可以为每个 backend 指定最大的重试次数，和重试时间间隔。所使用的关键字是 max_fails 和 fail_timeout。如下所示：
upstream backend {
server backend1.example.com weight=5;
server 54.244.56.3:8081 max_fails=3fail_timeout=30s;
}
在上例中，最大失败次数为 3，也就是最多进行 3 次尝试，且超时时间为 30秒。max_fails 的默认值为 1，fail_timeout 的默认值是 10s。传输失败的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 响应时间。
有一种情况需要注意，就是 upstream 中只有一个 server 时，max_fails 和 fail_timeout 参数可能不会起作用。导致的问题就是 nginx 只会尝试一次 upstream 请求，如果失败这个请求就被抛弃了 : (……解决的方法，比较取巧，就是在 upstream 中将你这个可怜的唯一 server 多写几次，如下：
upstream backend {
server backend.example.com max_fails fail_timeout=30s;
server backend.example.com max_fails fail_timeout=30s;
server backend.example.com max_fails fail_timeout=30s;
}
4、备机策略
从 Nginx 的 0.6.7 版本开始，可以使用“backup”关键字。当所有的非备机（non-backup）都宕机（down）或者繁忙（busy）的时候，就只使用由 backup 标注的备机。必须要注意的是，backup 不能和 ip_hash 关键字一起使用。举例如下：
upstream backend {
server backend1.example.com;
server backend2.example.com backup;
server backend3.example.com;
}
转载请注明来自“柳大的CSDN博客”：http://blog.csdn.net/poechant
更多文章请浏览CSDN专栏《Nginx高性能Web服务器》或服务器后端开发系列——《实战Nginx高性能Web服务器》
Cacti是一套基于PHP,MySQL,SNMP及RRDTool开发的网络流量监测图形分析工具。被广泛的用于对服务器的运维监控中，Cacti提供了一种插件式的管理，只要按要求写好特定的模板，那么你就可以对任何服务进行流量监控。本文就是要为大家介绍两个模板，分别是MongoDB和Redis的Cacti模板，使用它，你可以对你的MongoDB和Redis服务进行流量监控。
1，升级
python，此时如果是系统默认的python版本，会出现以下错误
python setup.py install Traceback (most recent call last): File "setup.py", line 3, in ? from redis import __version__ File "/usr/local/src/redis-2.4.11/redis/__init__.py", line 1, in ? from redis.client import Redis, StrictRedis File "/usr/local/src/redis-2.4.11/redis/client.py", line 240 with self.pipeline(True, shard_hint) as pipe: ^ SyntaxError: invalid syntax |
2，安装python，先配置python环境，下载python源代码
wget http://www.python.org/ftp/python/2.5.2/Python-2.5.2.tar.bz2 $ tar –jxvf Python-2.5.2.tar.bz2 $ cd Python-2.5.2 $ ./configure $ make $ make install [root@mysqlvm2 Python-2.5.2]# python Python 2.4.3 (#1, Jun 11 2009, 14:09:37) [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> |
Version还是2.4.3的，解决办法如下：
#cd /usr/bin
#ll |grep python //查看该目录下python
#rm -rf python
重新做个软连接就可以了
[root@mysqlvm2 Python-2.5.2]# ln -s /usr/local/bin/python /usr/bin/python
[root@mysqlvm2 Python-2.5.2]#
[root@mysqlvm2 Python-2.5.2]# python
Python 2.5.2 (r252:60911, Aug 4 2014, 14:43:36)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
3，然后下载redis的模板
wget http://mysql-cacti-templates.googlecode.com/files/better-cacti-templates-1.1.8.tar.gz
配置监控脚本
mongodb或redis的监控所需到的是你下载目录中的better-cacti-templates-1.1.8\scripts下的
ss_get_by_ssh.php 这个脚本 这个脚本需要放在cacti的服务端。
如果你cacti是装到/var/www/html/cacti/目录下。
把该文件放在其下面的scripts目录下。别忘了看下权限。要有执行权限。
然后修改该文件。主要修改一下选项，大概在40行。
# ============================================================================
$ssh_user = 'root'; # SSH username
$ssh_port = 22; # SSH port
$ssh_iden = '-i /root/.ssh/id_rsa'; # SSH identity
##修改根据你的配置，你的ssh连接用户，还有认证私钥的位置。
大该在50行，还可以修改其默认的去探测的端口（如果redis不是正常默认端口启动需要修改这些）。
$redis_port = 6379; # Which port redis listens on
4，导入模板，模板目录为better-cacti-templates-1.1.8\templates
在cacti界面导入界面，创建redis服务器的Graph，如下所示：
5，去查看Graph效果图，如下所示：
工作过程中有时候会接收到
数据库服务器器load 飙高的报警,比如:
load1 15.25 base: 8.52,collect time:2014-08-30
如何处理load 异常飙高的报警呢？ 本文尝试从原理，原因，解决方法来阐述这类问题的解决思路。
一 原理分析
CPU作为服务器的关键资源经常成为性能瓶颈的根源,CPU使用率高并不总是意味着CPU工作繁忙，它有可能是正在等待其他子系统。在进行性能分析时，将所有子系统当做一个整体来看是非常重要的，因为在子系统中可能会出现瀑布效应。衡量CPU 系统负载的指标是load,load 就是对计算机系统能够承担的多少负载的度量,简单的说是进程队列的长度。简单的例子比如食堂有五个窗口，当有小于五个学生来打饭，五个窗口都能及时处理，但是当学生个数超过5个，必然会出现等待的学生。请求大于当前的处理能力，会出现等待，引起load升高。
Load Average 就是一段时间(1min,5min,15min)内平均Load。平均负载的最佳值是1，这意味着每个进程都可以在一个完整的CPU 周期内完成。
14:50:31 up 166 days, 1:54, 295 users, load average: 0.05, 0.04, 0.00
二 原因分析
一般导致
MySQL服务器load飙高的原因可能有以下几种情况:
1 业务并发调用全表扫描/带有order by 排序的
SQL语句.
2 SQL语句没有合适索引/执行计划出错/update/delete where扫描全表,阻塞其他访问相同表的sql执行.
3 存在秒杀类似的业务比如聚划算10点开团或者双十一秒杀,瞬时海量访问给数据库带来冲击。
4 数据库做逻辑备份(需要全表扫描)或者多实例的压缩备份(压缩时需要大量的cpu计算,会导致系统服务器load飙高)
5 磁盘写入方式改变 比如有writeback 变为 write through
RAID卡都有写cache(Battery Backed Write Cache),写cache对IO性能的提升非常明显,因为掉电会丢失数据,所以必须由电池提供支持。
电池会定期充放电,一般为90天左右,当发现电量低于某个阀值时,会将写cache策略从writeback置为writethrough,相当于写cache会失效,这时如果系统有大量的IO操作,可能会明显感觉到IO响 应速度变慢,cpu 队列堆积系统load 飙高。
6 其他 欢迎补充 。
三 解决方法
在Load average 高的情况下如何鉴别系统瓶颈？如何判断系统是否已经Over Load呢？要去检查判断是CPU不足，还是io不够快造成或是内存不足？
这里笔者处理的方式 一般根据cpu数量去判断,也就是Load平均要小于CPU的数量,负载的正常值在不同的系统中有着很大的差别。在单核处理器的工作站中,1或2都是可以接受的。多核处理器的服务器(比如24核)上,load 会到达20 ，甚至更高。以多实例混合公用一台24核物理机为例,当DBA收到数据库服务器load 飙高报警后，一般的处理步骤
a) 数据库层面
1 top -u mysql -c 检查当前占用cpu资源最多的进程命令。-c 是为了显示出进程对应的执行命令语句，方便查看是什么操作导致系统load飙高。
2 根据不同的情况获取pid 或者MySQL的端口号
3 如果是MySQL 数据库服务导致laod 飙高，则可以使用如下命令
show processlist;
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND <> 'sleep' AND TIME>100;
或
orzdba 工具检查逻辑读/thread active的值。用法orzdba --help
orztop 工具检查当前正在执行的慢sql,用法orztop -P $port
4 获取异常的sql之后，剩下的比较好解决了。结合第一部分中的几条原因
a 选择合适的索引
b 调整sql 语句 比如对应order by 分页采用延迟关联
c 业务层面增加缓存，减少对数据库的直接访问等
b) OS 系统层面 检查系统IO
使用iostat 命令查看r/s(读请求),w/s(写请求),avgrq-sz(平均请求大小),await(IO等待), svctm(IO响应时间)
r/s ,w/s是每秒读/写请求的次数。
util是设备的利用率。如果它接近100%，通常说明设备能力趋于饱和(并不绝对，比如设备有写缓存)。有时候可能会出现大于100%的情况，这多半是计算时四舍五入引起的。
svctm是平均每次请求的服务时间。这里有一个公式：(r/s+w/s)*(svctm/1000)=util。举例子：如果util达到100%，那么此时 svctm=1000/(r/s+w/s)，假设IOPS是1000，则svctm大概在1毫秒左右，如果长时间大于这个数值，说明系统出了问题。
await是平均每次请求的等待时间。这个时间包括了队列时间和服务时间，也就是说，一般情况下，await大于svctm，它们的差值越小，队列时间越短，反之差值越大，队列时间越长，说明系统出了问题。
avgqu-sz是平均请求队列的长度。毫无疑问，队列长度越短越好。
BigInteger在Java8里增加了一组方法：
| public byte byteValueExact() public int intValueExact() public long longValueExact() |
这些方法后面都有Exact()，在老的JDK版本中，已经有了byteValue,intValue,longValue()为什么还要再增加这些方法呢？
因为在原来的方法中，如果BigInteger的值溢出了要目标类型的范围，是不会有任何提示的，那么我们的程序很可能在一个很隐蔽的错误下执行，没有任何错误输出，但是程序依然会继续执行，这种错误很难很难查。。。。。（大家可以想象一下，一个数值被突然改变了，不是很仔细的看，很难看出来），
有了新的XXXExact()方法，这一切都好办了，XXXExact()方法会在溢出的时候，抛出一个异常
public long longValueExact() { if (mag.length <= 2 && bitLength() <= 63) return longValue(); else throw new ArithmeticException("BigInteger out of long range"); } |
这样，我们就是可以在溢出时得到一个通知，进行处理。
项目过程的初期一项重要的
工作就是评审需求，每个公司或者团队可能都有自己的一套流程、方案，但有效的
需求评审，离不开产品和研发的共同参与。本文所分享的方案主要是针对这一轮或若干轮产品、研发共同参与的评审。
这样的需求评审在研发侧往往只有研发主管尽心去了解了具体的需求细节，在研发参与需求评审的会议上，大部分研发的同学也像走马观花一边纯粹听了一遍产品的同学朗读需求文档，事后开发的时候又发现很多细节问题，有没有？？
下面是要给大家分享的一个方案，这个是我在我们项目组中推行实践过的方案。
其实说起来很简单，就是把需求评审会议上的角色转换一下，让研发的同学来讲解需求文档，让产品的同学来听。貌似每个产品的同学听到这个方案都是先叫好的，好像是让他们从这个会议的朗诵角色中解脱了，负担轻了一大截似的。其实，应该说产品的同学负担会更重了。
那么下面讲讲实施细则
1.要求研发的同学在评审之前仔细阅读需求文档并有所思。一般到了研发参与评审的阶段，需求文档已经包括了相当的细节。而研发的同学应该有自己的思想，要能够挑出文档中的问题，能够做到有效的补充。这对于研发的同学来说是提高了要求。在我们团队实施这一方案的初期，由于团队规模本就不大（5人以下），所以当时我给出的要求是每个人都要熟悉我们负责部分的需求，要能提出有效的问题，评审时随机挑选一名同学来进行讲解，讲解完后其他同学的问题也可以提出。对于规模稍大的团队可能需要做些修改，可以把需求切割，再把团队切割（3人一组也许比较好），照例还是要求一部分人必须熟悉至少一块需求。这样做的目的主要是由一种压迫感“强制”研发侧的同学去思考产品需求，后面应当逐步转化为“自觉”的去思考才算达到了目的。
2.文档的要求，研发的同学需要时间来熟悉文档，哪怕让他看一遍可以在上下班的路上来思考，但起码应该在评审的前一天就有文档发到研发手里，让研发的同学可以开始熟悉需求。具体的哪些方面应该细节化，哪些方面可以延时细节化，视研发和产品直接的配合习惯来确定，这方面需要产品的同学把握。
3.会议中对产品同学的要求，不要认为研发的同学去讲解，产品的同学就没事可做了，相反，产品的同学可能要做的事情更重要了，产品的同学需要用心聆听研发同学的讲解，尽量尽早的发现研发同学对于需求的误解。而研发同学也往往会让产品的同学更清楚得认识到哪些功能可能是暂时行不通的，甚至研发的同学还可能给产品的同学提供新的思路。
当然各个团队自己的评审需求的流程可能都不一样，可以根据自己的需要来做调整。这个方案在我们团队经历的项目过程中实施，个人感觉还是有效果的，没有消灭研发过程中再去发现细节问题，但有效的减少了此类问题，特别是误解。