一、配置網絡
在使用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.會議中對產品同學的要求，不要認為研發的同學去講解，產品的同學就沒事可做了，相反，產品的同學可能要做的事情更重要了，產品的同學需要用心聆聽研發同學的講解，盡量盡早的發現研發同學對于需求的誤解。而研發同學也往往會讓產品的同學更清楚得認識到哪些功能可能是暫時行不通的，甚至研發的同學還可能給產品的同學提供新的思路。
當然各個團隊自己的評審需求的流程可能都不一樣，可以根據自己的需要來做調整。這個方案在我們團隊經歷的項目過程中實施，個人感覺還是有效果的，沒有消滅研發過程中再去發現細節問題，但有效的減少了此類問題，特別是誤解。