整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
.前言
關(guān)于javascript中的this對(duì)象，可能已經(jīng)被大家說爛了。
即使是這樣，我依然決定將這篇文章給水出來。畢竟全國(guó)在新型肺炎的影響下，公司沒法正常復(fù)工。
除了刷刷手機(jī)，還是要適當(dāng)?shù)膶W(xué)習(xí)一下。
廢柴是真不好當(dāng)，勞逸結(jié)合才是王道。
面試官：你能給我解釋一下javascript中的this嗎
我：（當(dāng)然可以哇，胸有成竹，咳咳）javascript中的this對(duì)象是指函數(shù) 運(yùn)行 時(shí)，在函數(shù)內(nèi)部生成的一個(gè)對(duì)象。
面試官：那你大概說一下它的用法吧
我：（我覺得我需要開始吹水了）
我：好，我大概說幾種使用場(chǎng)景。（下面都是我一個(gè)人的戲）
比如下面這個(gè)全局函數(shù)test
<script>
function test(){
}
</script>（事實(shí)勝于雄辯，雖然不能給面試官看結(jié)果，但是氣勢(shì)上已經(jīng)拿到一分）
除了作為普通函數(shù)使用之外， test全局函數(shù)也可以作為構(gòu)造函數(shù)去使用，那么函數(shù)內(nèi)部的this對(duì)象指向的是構(gòu)造函數(shù)創(chuàng)建出來的實(shí)例 。
在test構(gòu)造函數(shù)中，this.a=10這行是關(guān)鍵代碼。
假設(shè)我們?cè)诓恢纓his對(duì)象是什么的情況下，這行代碼僅僅是給this對(duì)象添加了一個(gè)屬性a，并且賦值為10 。
然后看測(cè)試結(jié)果打印出來的對(duì)象o，發(fā)現(xiàn)o也多了一個(gè)屬性a，它的值也為10 。
所以不難想到在test函數(shù)運(yùn)行時(shí)，this綁定到了new出來的對(duì)象上，即this指向了構(gòu)造函數(shù)創(chuàng)建出來的實(shí)例o；
第一種this的使用場(chǎng)景就吹完了，如果這樣啰嗦的回答面試官，估計(jì)就直接讓我回家了。
所以總結(jié)一下我這樣回答面試官：
在比如下面這個(gè)obj對(duì)象的increase方法。
var obj = {
a: 10,
increase: function(){
this.a++;
}
}現(xiàn)在我們?nèi)フ{(diào)用obj對(duì)象的increase方法
obj的increase方法中的關(guān)鍵代碼為this.a++，該函數(shù)調(diào)用完成后，在去打印obj對(duì)象，發(fā)現(xiàn)obj對(duì)象中a的屬性值由10增加為11。
那么increase方法這中的this.a++的效果實(shí)際上等效于obj.a++。
所以對(duì)于 第二種對(duì)象方法中的this，它指向的就是該對(duì)象本身。
那么到這里，我已經(jīng)我的能力范圍內(nèi)回答完了面試官的問題。
（如果幸運(yùn)的話，面試官應(yīng)該還不會(huì)趕我走）
面試官：說了這么多，那我這里有幾個(gè)實(shí)例代碼，你來給我分別說一下這幾個(gè)示例代碼輸出都是什么吧。
（接著面試官扔給我?guī)讖垖憹M了代碼的A4紙）。
我：（突然心慌慌，但是不能慫，按照前面說的幾種場(chǎng)景往里套唄）
（看到這個(gè)心情愉快呀，這不就是我剛說的this的第一種使用場(chǎng)景嗎。而且是將全局函數(shù)作為普通函數(shù)使用，那函數(shù)里的this指向的就是window。那既然函數(shù)f中的this指向的是window對(duì)象，那this.age就相當(dāng)于window.age。然后我不慌不忙的回答面試官）
題目一按照代碼執(zhí)行的輸出順序，第4行的輸出結(jié)果為20，第7行的輸出結(jié)果也是20（面試官不說話，應(yīng)該是默認(rèn)了我的回答是正確的）。
（這個(gè)乍一看跟題目一有些相似，只是在第3行中對(duì)age的定義有了變化，而且在第6行還多了一個(gè)打印輸出。
在往下看，發(fā)現(xiàn)函數(shù)f依然是作為普通函數(shù)去使用的，那既然是這樣，第3行的this.age=40也就相當(dāng)于window.age=40。
所以第3行代碼執(zhí)行的時(shí)候肯定會(huì)覆蓋第1行對(duì)age的賦值。到這里我微微一笑，開始回答面試官）
題目二按照代碼執(zhí)行的輸出順序，第6行輸出結(jié)果為20；第4行當(dāng)輸出結(jié)果為40；第8行當(dāng)輸出結(jié)果為40。
（這個(gè)題目一看還是我前面說的this的第一種使用場(chǎng)景，只是全局函數(shù)作為普通函數(shù)使用）
題目三按照代碼執(zhí)行的輸出順序，第5行輸出20；第8行輸出20。
（額，這個(gè)代碼有點(diǎn)長(zhǎng)呀，但是不能慌。
看完前8行覺得沒啥問題，第9、10行看完后心里咯噔了一下。
將obj的getName方法賦值給了一個(gè)變量fn，然后打印fn()？？？
靜下心想一想，第9行實(shí)際上是以聲明式方式創(chuàng)建了一個(gè)全局函數(shù)fn，然后在第10行調(diào)用fn。
接著我陷入了沉思，那調(diào)用fn時(shí)，這個(gè)this到底是指向obj對(duì)象呢，還是指向全局的window對(duì)象。
大腦飛速旋轉(zhuǎn)，想到剛開始對(duì)面試官說的那句話：javascript中的this對(duì)象是 函數(shù)運(yùn)行時(shí) ，在函數(shù)內(nèi)部生成的一個(gè)對(duì)象。
于是我不斷的重復(fù)這句話，然后一個(gè)激靈反應(yīng)上來，既然是this是函數(shù)運(yùn)行時(shí)生成的，那我應(yīng)該關(guān)注fn函數(shù)運(yùn)行時(shí)的情況呀。
先拋開函數(shù)fn是由obj的getName方法賦值生成的這個(gè)事情。
fn生成以后，它是一個(gè)全局函數(shù)，這個(gè)毋庸置疑。再者，fn運(yùn)行時(shí)是以普通函數(shù)的方式調(diào)用的。
那fn函數(shù)在運(yùn)行時(shí)，內(nèi)部的this對(duì)象就是window了，那第10行打印就是全局的"babi"了，恩，一定是這樣。
擦擦汗在繼續(xù)看，又發(fā)現(xiàn)了16行的代碼，感覺和第10行代碼有些異曲同工之處。
接著前面的思路往里套，不管otherObj.getName是怎么創(chuàng)建的，它在運(yùn)行的時(shí)候是作為otherObj對(duì)象的方法運(yùn)行的，那這就符合前面說的第二種使用this的場(chǎng)景：對(duì)象方法中的this，它指向的就是該對(duì)象本身。
想完這些抬頭看了一下面試官，一言不發(fā)甚至有些不耐煩，于是虛虛的回答他）
題目四按照代碼執(zhí)行的輸出順序，第10 行的輸出結(jié)果為"babi"；第17行的輸出結(jié)果為"mini"。
（此時(shí)看到面試官眉頭舒展，微微一笑）
面試官：好，那這個(gè)問題到此結(jié)束......
面試官的靈魂拷問結(jié)束后，回到家里把記得的示例代碼都驗(yàn)證了一遍，竟然發(fā)現(xiàn)都對(duì)了。
于是默默的獎(jiǎng)勵(lì)自己一個(gè)雞腿。
聲明：文章中場(chǎng)景純屬捏造，切勿當(dāng)真。小小總結(jié)，歡迎拍磚。
原文 http://www.cnblogs.com/HouJiao/p/12252885.html
喜歡小編的可以點(diǎn)個(gè)贊關(guān)注小編哦，小編每天都會(huì)給大家分享文章。
我自己是一名從事了多年的前端老程序員，小編為大家準(zhǔn)備了新出的前端編程學(xué)習(xí)資料，免費(fèi)分享給大家！
如果你也想學(xué)習(xí)前端，可以觀看【置頂】文章。也可以私信【1】 領(lǐng)取最新前端練手實(shí)戰(zhàn)項(xiàng)目
前一節(jié)中我們借助于 Chrome devtools 實(shí)現(xiàn)了對(duì)線上 Node.js 應(yīng)用的 CPU/Memory 問題的排查定位，但是在實(shí)際生產(chǎn)實(shí)踐中，大家會(huì)發(fā)現(xiàn) Chrome devtools 更加偏向本地開發(fā)模式，因?yàn)轱@然 Chrome devtools 不會(huì)負(fù)責(zé)去生成分析問題所需要的 Dump 文件，這意味著開發(fā)者還得額外在線上項(xiàng)目中設(shè)置好 v8-profiler 和 heapdump 這樣的工具，并且通過額外實(shí)現(xiàn)的服務(wù)來能夠去對(duì)線上運(yùn)行的項(xiàng)目進(jìn)行實(shí)時(shí)的狀態(tài)導(dǎo)出。
加上實(shí)際上預(yù)備章中除了 CPU/Memory 的問題，我們還會(huì)遇到一些需要分析錯(cuò)誤日志、磁盤和核心轉(zhuǎn)儲(chǔ)文件等才能定位問題的狀況，因此在這些場(chǎng)景下，僅僅靠 Chrome devtools 顯然會(huì)有一些力不從心。正是為了解決廣大 Node.js 開發(fā)者的這些痛點(diǎn)，我們?cè)谶@里推薦大家在使用 Node.js 性能平臺(tái)，即原來的 AliNode，它已經(jīng)在阿里巴巴集團(tuán)內(nèi)部承載了幾乎所有的 Node.js 應(yīng)用線上運(yùn)行監(jiān)控和問題排查，因此大家可以放心在生產(chǎn)環(huán)境部署使用。
本節(jié)將從 Node.js 性能平臺(tái) 的設(shè)計(jì)架構(gòu)、核心能力以及最佳實(shí)踐等角度，幫助開發(fā)者更好地使用這一工具來解決前面提到的異常指標(biāo)分析和線上 Node.js 應(yīng)用故障定位。
本書首發(fā)在 Github，倉(cāng)庫地址：https://github.com/aliyun-node/Node.js-Troubleshooting-Guide，云棲社區(qū)會(huì)同步更新。
Node.js 性能平臺(tái)其實(shí)簡(jiǎn)單的說由三部分組成：云控制臺(tái) + AliNode runtime + Agenthub，如下圖所示：
具體的部署步驟可以查看官方文檔：自助式部署 Runtime。借助于 Node.js 性能平臺(tái)的整套解決方案，我們可以很方便地實(shí)現(xiàn)預(yù)備章節(jié)中提到的絕大部分異常指標(biāo)的告警分析的能力。在生產(chǎn)實(shí)踐過程中，實(shí)際上在筆者看來，Node.js 性能平臺(tái)解決方案其實(shí)僅僅是提供了三個(gè)最核心卻也是最有效的能力：
換言之，Node.js 性能平臺(tái)作為一個(gè)產(chǎn)品本身功能也在不斷迭代新增修改中，但是以上的三個(gè)核心能力一定是第一優(yōu)先級(jí)保障的，其它邊邊角角的功能則相對(duì)來說響應(yīng)優(yōu)先級(jí)沒有那么高。
實(shí)際上我們也理解作為使用平臺(tái)的開發(fā)者希望能在一個(gè)地方看到 Node.js 線上應(yīng)用從底層到業(yè)務(wù)層的所有細(xì)節(jié)，然而我個(gè)人感覺不同的工具都有應(yīng)該有其核心的能力輸出，很多時(shí)候不斷做加法容易讓產(chǎn)品本身定位模糊化以及泛而不精，Node.js 性能平臺(tái)實(shí)際上始終在致力于讓原本線上黑盒的運(yùn)行時(shí)狀態(tài)，能更加直觀地反饋給開發(fā)者，讓 Node.js 應(yīng)用的開發(fā)者面對(duì)一些偏向底層的線上疑難雜癥能夠不再無所適從。
I. 配置合適的告警
線上應(yīng)用的告警實(shí)際上是一種自我發(fā)現(xiàn)問題的保護(hù)機(jī)制，如果沒有告警能力，那每次都會(huì)等到問題暴露到用戶側(cè)導(dǎo)致其反饋才能發(fā)現(xiàn)問題，這顯然對(duì)用戶體驗(yàn)非常的不友好。
因此部署完成一個(gè)項(xiàng)目后，開發(fā)者首先需要去配置合適的告警，而在我們的生產(chǎn)實(shí)踐中，線上問題通過錯(cuò)誤日志、Node.js 進(jìn)程 CPU/Memory 的分析、核心轉(zhuǎn)儲(chǔ)（Core dump）的分析以及磁盤分析能夠得出結(jié)論，因此我們需要的基本的告警策略也是源自以上五個(gè)部分。幸運(yùn)的是平臺(tái)已經(jīng)給我們預(yù)設(shè)好了這些告警，大家只需要選擇一下即可完整這里的告警配置，如下圖所示：
在 Node.js 性能平臺(tái) 的告警頁面上有 快速添加規(guī)則，點(diǎn)開選中后會(huì)自動(dòng)生成告警規(guī)則的閾值表達(dá)式模板和報(bào)警說明模板，我們可以按照項(xiàng)目實(shí)際監(jiān)控需求進(jìn)行修改，比如想要對(duì) Node.js 進(jìn)程的堆內(nèi)存進(jìn)行監(jiān)控，可以選中 Memory 預(yù)警 選項(xiàng)，如下圖所示：
此時(shí)點(diǎn)擊 添加報(bào)警項(xiàng) 即完整了對(duì)進(jìn)程堆內(nèi)存的告警，并且將出現(xiàn)告警時(shí)需要點(diǎn)擊 通知設(shè)置->添加到聯(lián)系人列表 來添加的聯(lián)系人加入此條規(guī)則，如下圖所示：
那么在例子中的這條默認(rèn)的規(guī)則里，當(dāng)我們的 Node.js 進(jìn)程分配的堆內(nèi)存超過堆上線的 80%（默認(rèn) 64 位機(jī)器上堆上限是 1.4G）時(shí)會(huì)觸發(fā)短信通知到配置綁定到此條規(guī)則的聯(lián)系人。
實(shí)際上快速添加規(guī)則列表中給大家提供的是最常見的一些預(yù)配置好的告警策略，如果這些尚不能滿足你的需求，更多定制化的自定義的服務(wù)告警策略配置方法可以看官方文檔 報(bào)警設(shè)置。并且除了短信告警，也支持釘釘機(jī)器人推送告警消息到群，方便群發(fā)感知線上 Node.js 應(yīng)用態(tài)勢(shì)。
II. 按照告警類型進(jìn)行分析
按照 I 節(jié)中配置完成合適的告警規(guī)則后，那么當(dāng)收到告警短信時(shí)就可以按照策略類型進(jìn)行對(duì)應(yīng)的分析了。本節(jié)將按照預(yù)備節(jié)中比較常見的五大類問題來逐一講解。
a. 磁盤監(jiān)控
這個(gè)是比較好處理的問題，在快速添加的規(guī)則里實(shí)際上我們會(huì)在服務(wù)器的磁盤使用超過 85% 時(shí)進(jìn)行告警，那么收到磁盤告警后，可以連接到服務(wù)器，使用如下命令查看那個(gè)目錄占用比較高：
sudo du -h --max-depth=1 /
找到占比比較高的目錄和文件后，看看是否需要備份后刪除來釋放出磁盤空間。
b. 錯(cuò)誤日志
收到特定的錯(cuò)誤日志告警后，只需要去對(duì)應(yīng)的項(xiàng)目的 Node.js 性能平臺(tái) 控制臺(tái)找到問題 實(shí)例 去查看其 異常日志 即可，如下圖所示：
這里會(huì)按照錯(cuò)誤類型進(jìn)行規(guī)整，大家可以結(jié)合展示的錯(cuò)誤棧信息來進(jìn)行對(duì)應(yīng)的問題定位。注意這里的錯(cuò)誤日志文件需要你在部署 Agenthub 的時(shí)候?qū)懭肱渲梦募敿?xì)可以參見文檔 配置和啟動(dòng) Agenthub 一節(jié)中的 詳細(xì)配置 內(nèi)容。
c. 進(jìn)程 CPU 高
終于到了前一節(jié)中借助 v8-profiler 導(dǎo)出 CPU Profile 文件再使用 Chrome devtools 進(jìn)行分析的異常類型了。那么在 Node.js 性能平臺(tái) 的整套解決方案下，我們并不需要額外的去依賴類似 v8-profiler 這樣的第三方庫來實(shí)現(xiàn)進(jìn)程狀態(tài)的導(dǎo)出，與此相對(duì)的，當(dāng)我們收到 Node.js 應(yīng)用進(jìn)程的 CPU 超過我們?cè)O(shè)置的閾值告警時(shí)，我們只需要在控制臺(tái)對(duì)應(yīng)的 實(shí)例 點(diǎn)擊 CPU Profile 按鈕即可：
默認(rèn)會(huì)給抓取的進(jìn)程生成 3 分鐘的 CPU Profile 文件，等到結(jié)束后生成的文件會(huì)顯示在 文件 頁面：
此時(shí)點(diǎn)擊 轉(zhuǎn)儲(chǔ) 即可上傳到云端以供在線分析展示了，如下圖所示：
這里可以看到有兩個(gè) 分析 按鈕，其實(shí)第二個(gè)下標(biāo)帶有 (devtools) 的分析按鈕實(shí)際上就是前一節(jié)中提到的 Chrome devtools 分析，這里不再重復(fù)講解了，如果有遺忘的同學(xué)可以再去回顧下本大章前一節(jié)的內(nèi)容。我們重點(diǎn)看下第一個(gè) AliNode 定制的分析，點(diǎn)擊第一個(gè)分析按鈕后，可以在新頁面看到如下所示內(nèi)容：
這里其實(shí)也是火焰圖，但與 Chrome devtools 提供的火焰圖不一樣的地方在于，這里是將抓取的 3 分鐘內(nèi)的 JS 函數(shù)執(zhí)行進(jìn)行了聚合展示出來的火焰圖，在一些存在多次執(zhí)行同一個(gè)函數(shù)（可能每次執(zhí)行非常短）的情況下，聚合后的火焰圖可以很方便的幫助我們找到代碼的執(zhí)行瓶頸來進(jìn)行對(duì)應(yīng)的優(yōu)化。
值得一提的是，如果你使用的 AliNode runtime 版本在 v3.11.4 或者 v4.2.1 以上（包含這兩個(gè)版本）的話，當(dāng)你的應(yīng)用出現(xiàn)類死循環(huán)問題，比如由于異常的用戶參數(shù)導(dǎo)致的正則回溯（即執(zhí)行完這個(gè)正則要十幾年，類似于 Node.js 進(jìn)程發(fā)生了死循環(huán)）這類問題時(shí)，可以通過抓取 CPU Profile 文件來很方便地定位到問題代碼，詳細(xì)信息有興趣的同學(xué)可以看下 Node.js 性能平臺(tái)支持死循環(huán)和正則攻擊定位。
d. 內(nèi)存泄漏
與 CPU 高的問題一樣，當(dāng)我們收到 Node.js 應(yīng)用進(jìn)程的堆內(nèi)存占據(jù)堆上限的比率超過我們?cè)O(shè)置的閾值時(shí)，我們也不需要類似 heapdump 這樣的第三方模塊來導(dǎo)出堆快照進(jìn)行分析，我們還是在控制臺(tái)對(duì)應(yīng)的 實(shí)例 點(diǎn)擊 堆快照 按鈕即可生成對(duì)應(yīng) Node.js 進(jìn)程的堆快照：
生成的堆快照文件同樣會(huì)顯示在 文件 列表頁面，點(diǎn)擊 轉(zhuǎn)儲(chǔ) 將堆快照上傳至云端以供接下來的分析：
與上面一樣，下標(biāo)帶有 (devtools) 的分析按鈕還是前一節(jié)中提到的 Chrome devtools 分析，這里還是著重解析下 AliNode 定制的第一個(gè)分析按鈕，點(diǎn)擊后新頁面如下圖所示：
首先解釋下上面的總覽欄目的內(nèi)容信息：
這部分的信息旨在給大家一個(gè)概覽，部分信息需要深入解讀堆快照才能徹底理解，如果你實(shí)在無法理解其中的幾個(gè)概覽指標(biāo)信息，其實(shí)也無傷大雅，因?yàn)檫@并不影響我們定位問題代碼。
簡(jiǎn)單了解了概覽信息的含義后，接著我們來看對(duì)于定位 Node.js 應(yīng)用代碼段非常重要的信息，第一個(gè)是默認(rèn)展示的 可疑點(diǎn) 信息，上圖中的內(nèi)容表示 @15249 這個(gè)對(duì)象占據(jù)了堆空間 97.41% 的內(nèi)存，那么它很可能就是一個(gè)泄漏對(duì)象，這里又存在兩種可能：
要判斷是哪一種情況，以及追蹤到對(duì)應(yīng)的代碼段，我們需要點(diǎn)擊圖中的 簇視圖 鏈接進(jìn)行進(jìn)一步觀察：
這里繼續(xù)解釋下什么是簇視圖，簇視圖實(shí)際上是支配樹的一個(gè)別名，也就是這個(gè)視圖下我們看到的正是前面一節(jié)中提到的從可疑泄漏對(duì)象出發(fā)的支配樹視圖，它的好處是，在這個(gè)視圖下，父節(jié)點(diǎn)的 Retained Size 可以直接由其子節(jié)點(diǎn)的 Retained Size 累加后再加上父節(jié)點(diǎn)自身的 Shallow Size 得到，換言之，在這個(gè)視圖下我們層層展開即可以看到可疑泄漏對(duì)象的內(nèi)存究竟被哪些子節(jié)點(diǎn)占用了。
并且結(jié)合前一節(jié)的支配樹描述，我們可以知道支配樹下的父子節(jié)點(diǎn)關(guān)系，并不一定是真正的堆上空間內(nèi)的對(duì)象父子關(guān)系，但是對(duì)于那些支配樹下父子關(guān)系在真正的堆空間內(nèi)也存在父子節(jié)點(diǎn)關(guān)系的簇節(jié)點(diǎn)，我們將真正的 邊 也用淺紫色標(biāo)識(shí)出來，這部分的 邊 信息對(duì)于我們映射到真正的代碼段非常有幫助。在這個(gè)簡(jiǎn)單的例子中，我們可以很清晰的看到可疑泄漏對(duì)象 @15249 實(shí)際上是下屬的 test-alinode.js 中存在一個(gè) array 變量，其中存儲(chǔ)了四個(gè) 45.78 兆的數(shù)組導(dǎo)致的問題，這樣就找到了問題代碼可以進(jìn)行后續(xù)優(yōu)化。
而在實(shí)際生產(chǎn)環(huán)境的堆快照分析下，很多情況下簇視圖下的父子關(guān)系在真實(shí)的堆空間中并不存在，那么就不會(huì)有這些紫色的邊信息展示，這時(shí)候我們想要知道可疑泄漏對(duì)象如何通過 JavaScript 生成的對(duì)象間引用關(guān)系引用到后面真正占據(jù)掉堆空間的對(duì)象（比如上圖中的 40 多兆的 Array 對(duì)象），我們可以點(diǎn)擊 可疑節(jié)點(diǎn)自身的地址鏈接 ：
這樣就進(jìn)入到以此對(duì)象為起點(diǎn)的堆空間內(nèi)真正的對(duì)象引用關(guān)系視圖 Search 視圖：
這個(gè)視圖因?yàn)榉从车氖嵌芽臻g內(nèi)各個(gè) Heap Object 之間真正的引用連接關(guān)系，因此父對(duì)象的 Retained Size 并不能直接由子節(jié)點(diǎn)的 Retained Size 累加獲取，如上圖紅框內(nèi)的內(nèi)容，顯然這里的三個(gè)子節(jié)點(diǎn) Retained Size 累加已經(jīng)超過 100%，這也是 Search 視圖和簇視圖很大的不同點(diǎn)。借助于 Search 視圖，我們可以根據(jù)其內(nèi)反映出來的對(duì)象和邊之間的關(guān)系來定位可疑泄漏對(duì)象具體是在我們的 JavaScript 代碼中的哪一部分生成。
其實(shí)看到這邊，一些讀者應(yīng)該意識(shí)到了這里的 Search 視圖實(shí)際上對(duì)應(yīng)的就是前一節(jié)中提到的 Chrome devtools 的 Containment 視圖，只不過這里的起始點(diǎn)是我們選中的對(duì)象本身罷了。
最后就是需要提一下 Retainers 視圖，它和前一節(jié)中提到的 Chrome devtools 中解析堆快照展示結(jié)果里面的 Retainers 含義是一致的，它表示對(duì)象的父引用關(guān)系鏈，我們可以來看下：
這里 globa@1279 對(duì)象的 clearImmediate 屬性指向 timers.js()@15325，而 timers.js()@15325 的 context 屬性指向了可疑的泄漏對(duì)象 system / Context@15249。
在絕大部分的情況下，通過結(jié)合 Search 視圖 和 Retainers 視圖 我們可以定位到指定對(duì)象在 JavaScript 代碼中的生成位置，而 簇視圖 下我們又可以比較方便的知道堆空間被哪些對(duì)象占據(jù)掉了，那么綜合這兩部分的信息，我們就可以實(shí)現(xiàn)對(duì)線上內(nèi)存泄漏的問題進(jìn)行分析和代碼定位了。
e. 出現(xiàn)核心轉(zhuǎn)儲(chǔ)
最后就是收到服務(wù)器生成核心轉(zhuǎn)儲(chǔ)文件（Core dump 文件）的告警了，這表示我們的進(jìn)程已經(jīng)出現(xiàn)了預(yù)期之外的 Crash，如果你的 Agenthub 配置正常的話，在 文件 -> Coredump 文件 頁面會(huì)自動(dòng)將生成的核心轉(zhuǎn)儲(chǔ)文件信息展示出來：
和之前的步驟類似，我們想要看到服務(wù)端分析和結(jié)果展示，首先需要將服務(wù)器上生成的核心轉(zhuǎn)儲(chǔ)文件轉(zhuǎn)儲(chǔ)到云端，但是與之前的 CPU Profile 和堆快照的轉(zhuǎn)儲(chǔ)不一樣的地方在于，核心轉(zhuǎn)儲(chǔ)文件的分析需要我們提供對(duì)應(yīng) Node.js 進(jìn)程的啟動(dòng)執(zhí)行文件，即 AliNode runtime 文件，這里簡(jiǎn)化處理為只需要設(shè)置 Runtime 版本即可：
點(diǎn)擊 設(shè)置 runtime 版本 即可進(jìn)行設(shè)置，格式為 alinode-v{x}.{y}.{z} 的形式，比如 alinode-v3.11.5，版本會(huì)進(jìn)行校驗(yàn)，請(qǐng)務(wù)必填寫你的應(yīng)用真實(shí)在使用的 AliNode runtime 版本。版本填寫完成后，我們就可以點(diǎn)擊 轉(zhuǎn)儲(chǔ) 按鈕進(jìn)行文件轉(zhuǎn)儲(chǔ)到云端的操作了：
顯然對(duì)于核心轉(zhuǎn)儲(chǔ)文件來說，Chrome devtools 是沒有提供解析功能的，所以這里只有一個(gè) AliNode 定制的分析按鈕，點(diǎn)擊這個(gè) 分析 按鈕，即可以看到結(jié)果：
這里第一欄的概覽信息看文字描述就能理解其含義，所以這里就不再多做解釋了，我們來看下比較重要的默認(rèn)視圖 BackTrace 信息視圖，此視圖下展示的實(shí)際上是 Node.js 應(yīng)用在 Crash 時(shí)刻的線程信息，許多開發(fā)者認(rèn)為 Node.js 是單線程的運(yùn)行模型，其實(shí)這句話也不是完全錯(cuò)誤，更準(zhǔn)確的說法是 單主 JavaScript 工作線程，因?yàn)閷?shí)際上 Node.js 還會(huì)開啟一些后臺(tái)線程來處理諸如 GC 里的部分任務(wù)。
絕大部分的情況下，應(yīng)用的 Crash 都是由 JavaScript 工作線程引發(fā)的，因此我們需要關(guān)注的也僅僅是這個(gè)線程，這里顯然 BackTrace 信息視圖中將 JavaScript 工作線程做了標(biāo)紅和置頂處理，展開后可以看到 Node.js 應(yīng)用 Crash 那一刻的錯(cuò)誤堆棧信息：
因?yàn)榫退阍?JavaScript 的工作線程中，也會(huì)存在 Native C/C++ 代碼的穿透，但是在問題排查中我們往往只需要去看同樣標(biāo)紅的 JavaScript 棧信息即可，像在這個(gè)簡(jiǎn)單的例子中，顯然 Crash 是因?yàn)橐晥D去啟動(dòng)一個(gè)不存在的 JS 文件導(dǎo)致的。
值得一提的是，核心轉(zhuǎn)儲(chǔ)文件的分析功能非常的強(qiáng)大，因?yàn)樵陬A(yù)備節(jié)中我們提到其生成的途徑除了 Node.js 應(yīng)用 Crash 的時(shí)候由系統(tǒng)內(nèi)核控制輸出外，還可以由 gcore 這樣的命令手動(dòng)強(qiáng)制輸出，而本小節(jié)我們又看到核心轉(zhuǎn)儲(chǔ)文件的分析實(shí)際上可以看到此刻的 JavaScript 棧信息以及其入?yún)ⅲY(jié)合這兩點(diǎn)，我們可以在線上出現(xiàn) CPU Profile 一節(jié)中提到的類死循環(huán)問題時(shí)直接采用 gcore 生成核心轉(zhuǎn)儲(chǔ)文件，然后上傳至平臺(tái)云端進(jìn)行分析，這樣不僅可以看到我們的 Node.js 應(yīng)用是阻塞在哪一行的 JavaScript 代碼，甚至引發(fā)阻塞的參數(shù)我們也能完整獲取到，這對(duì)本地復(fù)現(xiàn)定位問題的幫助無疑是無比巨大的。
本節(jié)其實(shí)給大家介紹了 Node.js 性能平臺(tái) 的整套面向 Node.js 應(yīng)用開發(fā)的監(jiān)控、告警、分析和定位問題的解決方案的架構(gòu)和最佳實(shí)踐，希望能讓大家對(duì)平臺(tái)的能力和如何更好地結(jié)合自身項(xiàng)目進(jìn)行使用有一個(gè)整體的理解。
限于篇幅，最佳實(shí)踐中的 CPU Profile、堆快照和核心轉(zhuǎn)儲(chǔ)文件的分析例子都非常的簡(jiǎn)單，這部分的內(nèi)容也更多的是旨在幫助大家理解平臺(tái)提供的工具如何使用以及其分析結(jié)果展示的指標(biāo)含義，那么本書的第三節(jié)中，我們會(huì)通過一些實(shí)際的生產(chǎn)遇到的案例問題借助于 Node.js 性能平臺(tái) 提供的上述工具分析過程，來幫助大家更好的理解這部分信息，也希望大家在讀完這些內(nèi)容后能有所收獲，能對(duì) Node.js 應(yīng)用在生產(chǎn)中的使用更有信心。
作者：奕鈞
于如何運(yùn)營(yíng)一個(gè)社區(qū)，本文作者總結(jié)了一個(gè)“七步運(yùn)營(yíng)”的方法，七個(gè)環(huán)節(jié)分別為：熟悉產(chǎn)品——競(jìng)品分析——社區(qū)氛圍與種子用戶——拉新與促活——留存與轉(zhuǎn)化——老用戶召回——站好最后一班崗。
首先給大家分享一個(gè)案例，大約在2014年初的時(shí)候，我曾經(jīng)接手過一個(gè)地方門戶網(wǎng)站的家居論壇。這是一個(gè)縣區(qū)級(jí)城市的地方門戶網(wǎng)站，當(dāng)?shù)氐某Ｗ∪丝谠诎偃f左右，城區(qū)人口30萬左右，該門戶網(wǎng)站在當(dāng)?shù)刈龅檬殖晒Γ瑢儆诋?dāng)?shù)氐膹?qiáng)勢(shì)門戶，日瀏覽量超過46萬次，日獨(dú)立IP1.5萬左右。這個(gè)網(wǎng)站的家居版塊一直沒有做起來，數(shù)據(jù)不溫不火，在上一任運(yùn)營(yíng)離開后，基本瀕死。
2月底我接手時(shí)，因?yàn)樯弦蝗芜\(yùn)營(yíng)人員已離職近一個(gè)月，論壇基本上一直處于無人管理的狀態(tài)，UV不到200，PV不到500。論壇里基本沒有什么用戶發(fā)言，更不要說有優(yōu)質(zhì)的內(nèi)容了，滿屏都是各種亂七八糟的廣告貼，以及SEO們發(fā)的外鏈貼，整個(gè)論壇基本癱瘓。我花了4個(gè)月的時(shí)間，將論壇的各項(xiàng)基本功能恢復(fù)，訪問量上升到UV1500，PV過萬。
首先我花了一兩個(gè)星期左右來熟悉論壇以及整個(gè)門戶的各方面情況，然后對(duì)這個(gè)社區(qū)論壇存在的問題做出了一個(gè)初步判斷：由于運(yùn)營(yíng)的斷層，家居論壇人氣很低，但是仍有用戶在關(guān)注；論壇的基本體制還是健全的，只是缺乏管理。于是，我通過下面的運(yùn)營(yíng)方法和手段，逐步地將這個(gè)論壇挽救了過來。
社區(qū)里的廣告帖、外鏈帖等垃圾帖，對(duì)于論壇整體環(huán)境的危害是母庸置疑的。充斥著廣告、外鏈的版面，是很難吸引到用戶的。就好像一個(gè)小區(qū)里，遍地都是垃圾的話，還會(huì)有人愿意來住嘛？所以，我首先做的是將社區(qū)打掃干凈，這樣才好招徠八方游客。
刪帖的工作，一般論壇都會(huì)有防水墻自動(dòng)處理，但還是會(huì)有一些帖子會(huì)成為漏網(wǎng)之魚，需要人工操作刪帖。這個(gè)工作我從剛開始接手論壇一直做到離開前，不僅僅是刪除每天新出現(xiàn)的垃圾帖，因?yàn)閺?qiáng)迫癥的緣故還在空閑的時(shí)候?qū)⒅暗呐f帖篩選出來刪除掉，這大概是一個(gè)社區(qū)論壇運(yùn)營(yíng)管理人員最基本的工作了吧，像百度貼吧的運(yùn)營(yíng)總監(jiān)就曾經(jīng)說過，百度貼吧每天要?jiǎng)h除近200萬的垃圾帖，可謂是運(yùn)營(yíng)不息，刪帖不止。
在社區(qū)論壇的環(huán)境打掃干凈之后，我就開始著手內(nèi)容的運(yùn)營(yíng)，首先用到了社區(qū)運(yùn)營(yíng)里最常用的手段：用馬甲以用戶的身份發(fā)帖。這種方法在新社區(qū)運(yùn)營(yíng)初期時(shí)最為常用，運(yùn)營(yíng)工作人員不僅要做發(fā)帖的樓主，制造有爭(zhēng)議性的話題，還需要用馬甲來自己為自己喝彩鼓掌，精分成好幾個(gè)不同立場(chǎng)的用戶發(fā)起討論。要說明的是，這里用馬甲的目的只是生產(chǎn)一些內(nèi)容，活躍論壇的氣氛，并不會(huì)涉及惡意造假的行為。
大部分人都是愛看熱鬧的，就像生活中如果有人在吵架的話，很快就會(huì)有一大群不明真相的群眾來圍觀。而表現(xiàn)在網(wǎng)絡(luò)上時(shí)，就是我們都愛看“吵架”帖，吵得越厲害越好，嗯，“前排兜售瓜子板凳，強(qiáng)勢(shì)圍觀”。所以，在社區(qū)運(yùn)營(yíng)時(shí)，有爭(zhēng)議性的話題是一直需求的，如果能有一些知名人士、意見領(lǐng)袖來參與，那就更好了，更容易引爆氛圍，吸引大量用戶。
大約是在3月初的時(shí)候，經(jīng)理和負(fù)責(zé)招商的主管一起策劃了一場(chǎng)大型的線下團(tuán)購(gòu)活動(dòng)，我開始做線上的活動(dòng)預(yù)熱。
當(dāng)時(shí)采取的都是一些比較常規(guī)的動(dòng)作，比如發(fā)活動(dòng)預(yù)熱帖、活動(dòng)主題報(bào)名帖、話題炒作帖等，同時(shí)還通過利用公司內(nèi)部的資源，申請(qǐng)了總站首頁和論壇主板置頂?shù)囊恍┱摺?/p>
我當(dāng)時(shí)對(duì)這樣的做法持保留意見，在我看來，在社區(qū)論壇剛剛做好第一步和第二步的時(shí)候，就開展大型的線下活動(dòng)，有些操之過急的感覺，覺得應(yīng)該在開展線上活動(dòng)和線下小活動(dòng)之后，一方面到時(shí)候論壇有一定的氛圍人氣，另一方面有之前的資源和經(jīng)驗(yàn)積累，舉辦大型活動(dòng)時(shí)也更駕輕就熟一些。不過，這次線下活動(dòng)的實(shí)際效果還是非常好的，也成為了家居論壇成長(zhǎng)的一個(gè)轉(zhuǎn)折點(diǎn)。之后我一直在考慮，有可能是我過于保守，在社區(qū)人氣不夠的情況下，通過大型活動(dòng)來吸引人氣，也是一種值得一行的策略。
在大型線下活動(dòng)的預(yù)熱征集帖上線后不久，在經(jīng)理的指導(dǎo)下，我們又開始策劃線下常規(guī)活動(dòng)作為補(bǔ)充，一方面繼續(xù)拉新，一方面為大活動(dòng)造勢(shì)。
在我看來，社區(qū)運(yùn)營(yíng)中常規(guī)型的線上線下活動(dòng)，有助于讓用戶對(duì)社區(qū)的黏度大大提高，同時(shí)可以形成一定的品牌效應(yīng)，有助于用戶記住社區(qū)的亮點(diǎn)，利于傳播。
3·15前后，我們的大型線下活動(dòng)落地并取得了不錯(cuò)的效果，參與用戶的數(shù)量和轉(zhuǎn)化率讓大老板和參與的商家都十分滿意。由于這篇是討論關(guān)于社區(qū)運(yùn)營(yíng)方面的工作，就不在這里細(xì)說了。
活動(dòng)舉辦后，我提出對(duì)參與活動(dòng)的用戶進(jìn)行跟蹤報(bào)道。本來比較理想的情況是用戶在參加活動(dòng)后自發(fā)的進(jìn)行內(nèi)容產(chǎn)出，然而由于之前家居論壇的基礎(chǔ)運(yùn)營(yíng)不夠，用戶自發(fā)發(fā)帖的主動(dòng)性仍不高，另一方面是參與活動(dòng)的用戶群體并不是預(yù)期中的8090后的年輕人，而是40歲以上的年齡偏大的群體，對(duì)于論壇發(fā)帖不是很熟悉。因此為了吸引用戶，只能自己去做采編工作，回來后以第三人稱視角去描述裝修過程。
對(duì)于社區(qū)中的用戶來說，他們很容易產(chǎn)生如同在現(xiàn)實(shí)社區(qū)中生活的心理，因此會(huì)在很多時(shí)候表現(xiàn)的像現(xiàn)實(shí)生活中一樣非常關(guān)心鄰居家的雞毛蒜皮的小事，關(guān)注他人的故事，所以如同裝修論壇里的裝修日記、親子社區(qū)里的寶媽日記、旅游社區(qū)里的游記等等這樣的內(nèi)容，雖然常常內(nèi)容非常簡(jiǎn)單，文案配圖也不夠?qū)I(yè)，但是卻能吸引眾多的用戶點(diǎn)擊互動(dòng)。所以我在用戶還無法做內(nèi)容產(chǎn)出時(shí)，代為做這些內(nèi)容產(chǎn)出。
4月前后，公司領(lǐng)導(dǎo)在與一個(gè)地方兄弟站學(xué)習(xí)交流后，對(duì)論壇的整合型內(nèi)容輸出加大了要求，于是我們?cè)谶\(yùn)營(yíng)時(shí)投入了相當(dāng)一部分精力來做各種大的裝修攻略，整合各種裝修知識(shí)帖。
與碎片化的內(nèi)容相比，整合型內(nèi)容（大型攻略帖、集合帖）具有較高的整體性，同時(shí)對(duì)文案編輯的要求較高，因而一般情況下是沒有用戶來做這個(gè)的，但是這些干貨內(nèi)容是支持社區(qū)的內(nèi)容骨架，就像主食一樣，味淡卻又不可缺失。
由于這個(gè)論壇之前有運(yùn)營(yíng)一段時(shí)間，雖然接手前流失了很多用戶，但是我還是從之前的帖子中找到了一些由于論壇冷清而離開的意見領(lǐng)袖，一個(gè)個(gè)與他們進(jìn)行溝通交流，召回了一部分。同時(shí)，在論壇中尋找一些積極份子，培養(yǎng)他們成為新一批的意見領(lǐng)袖、發(fā)帖達(dá)人。這一部分人，在之后都貢獻(xiàn)了許多優(yōu)質(zhì)的內(nèi)容，同時(shí)也在日常發(fā)帖中帶動(dòng)了論壇氣氛，在線下活動(dòng)中也為我們提供了非常多的助力。
做社區(qū)的時(shí)候，有一批人是繞不開的，那就是意見領(lǐng)袖，意見領(lǐng)袖對(duì)社區(qū)的重要性眾所周知，因而社區(qū)運(yùn)營(yíng)人員需要和他們保持良好的關(guān)系，成為朋友。
畢竟是地方上的家居論壇，與本土商家聯(lián)系很緊密，自身盈利的需求使得我們無法避免的要為商家做宣傳。同時(shí)商家本身也有在論壇中發(fā)言的需求和意愿，因此如何避免商家在社區(qū)中盲目的發(fā)布廣告帖，成為了我們面臨的一個(gè)問題。
我們采取的做法是堵不如疏，與其陷入“商家發(fā)廣告帖——我們刪帖——商家向我們抱怨”的怪圈，不如對(duì)商家進(jìn)行引導(dǎo)。我們對(duì)商家進(jìn)行培訓(xùn)或者說是忽悠，告訴他們?cè)趶V告泛濫的時(shí)代，單純的廣告帖在論壇中不僅無法起到推廣的作用，還只會(huì)破壞論壇的環(huán)境，失去用戶。因此，符合規(guī)范的發(fā)言才有利于商家在社區(qū)論壇中獲得更好的回報(bào)。
我們?cè)谝?guī)范商家發(fā)言的時(shí)候，發(fā)現(xiàn)之前的版規(guī)已經(jīng)不太適合當(dāng)時(shí)的環(huán)境了。實(shí)際上，我們本該在制定好社區(qū)規(guī)則之后，再做商家的規(guī)范化要求，甚至應(yīng)該說，我們本應(yīng)該在第一步清理垃圾帖之后就將新的社區(qū)規(guī)則發(fā)布出來。
在運(yùn)營(yíng)一個(gè)社區(qū)時(shí)，社區(qū)規(guī)則的制定是必須的，完成的越早越好，同時(shí)還需要根據(jù)環(huán)境的變化不斷做新的調(diào)整和補(bǔ)充。
四月中旬的時(shí)候，終于有一批用戶在論壇中發(fā)一些優(yōu)質(zhì)的內(nèi)容——裝修日記。在優(yōu)質(zhì)內(nèi)容產(chǎn)出后，我們不僅對(duì)帖子進(jìn)行一些加精華、送分送花的操作，鼓勵(lì)他們；同時(shí)還用馬甲號(hào)進(jìn)行互動(dòng)，以滿足用戶的心理需求，激勵(lì)他們繼續(xù)發(fā)帖。為了讓他們的發(fā)帖積極性更高，我們做了一期裝修日記評(píng)比，并臨時(shí)抽調(diào)了一批禮品贈(zèng)送給他們。
做社區(qū)的同仁大概都會(huì)發(fā)現(xiàn)，如果單純靠運(yùn)營(yíng)編輯來產(chǎn)出內(nèi)容的話，畢竟數(shù)量有限，而且內(nèi)容多樣性遠(yuǎn)遠(yuǎn)不夠，而社區(qū)中可謂臥虎藏龍，社區(qū)中的用戶如果能夠充分調(diào)動(dòng)起來，可以讓社區(qū)更富活力，同時(shí)更有多樣性。
當(dāng)論壇的人氣上漲，氛圍漸好時(shí)，用戶會(huì)出于種種需求發(fā)布一些優(yōu)質(zhì)的內(nèi)容，這是論壇開始有活力的標(biāo)志，這第一批種子需要運(yùn)營(yíng)人員像呵護(hù)幼苗一樣驚心呵護(hù)，像幼兒園老師鼓勵(lì)小朋友發(fā)言一樣鼓勵(lì)他們繼續(xù)說下去。
在裝修日記評(píng)比活動(dòng)后，我們陸續(xù)做了幾期線上活動(dòng)，主要以“話題討論”為主。在這里需要說明的是，按照一般情況來說，我們的線上活動(dòng)嚴(yán)重滯后了，但是由于之前領(lǐng)導(dǎo)層對(duì)整合型攻略十分重視，放棄了社區(qū)運(yùn)營(yíng)中常見的如“搶樓”、“投票”等線上活動(dòng)，因而直到5月份策略有所松動(dòng)時(shí)，才開始做線上活動(dòng)。不過線上活動(dòng)如“搶樓”、“投票”、“話題討論”、“評(píng)選”、“比賽”等對(duì)于拉動(dòng)社區(qū)論壇的氣氛、活躍人氣還是非常有效果的。
在商家入駐的越來越多后，我們學(xué)習(xí)了兄弟站的經(jīng)驗(yàn)推出了商家?guī)欤_辟了獨(dú)立的版面以滿足商家的宣傳需求，培訓(xùn)商家如何做整合型的大帖以及如何正確的與社區(qū)中的用戶進(jìn)行溝通交流。同時(shí)為了各方面的需求，對(duì)部分商家做了人物專訪。
在社區(qū)的用戶越來越多，氛圍越來越好，合作的商家也漸多之后，我們開始籌備做大型的線上活動(dòng)——裝修日記大賽。
但是在籌備階段中，我突然想到隨著社區(qū)逐漸火熱，涌入的新人也越來越多，越來越多的新人可能面臨著操作上的疑問，因此開始做社區(qū)新手指南以及FAQ。
嗯，這個(gè)東西本來應(yīng)該是和社區(qū)規(guī)則一起出臺(tái)的。
舉辦裝修日記大賽這樣的大型線上活動(dòng)，一方面是為了商業(yè)化的利益，另一方面更是為了吸引用戶產(chǎn)出更多的優(yōu)質(zhì)內(nèi)容，同時(shí)讓內(nèi)容的產(chǎn)出保持常態(tài)化。當(dāng)時(shí)我們已經(jīng)積累了一部分優(yōu)質(zhì)的用戶與原創(chuàng)的內(nèi)容，論壇的氛圍也非常活躍，因而裝修日記大賽的推動(dòng)已經(jīng)是水到渠成。7月初裝修日記大賽活動(dòng)上線后，家居論壇的數(shù)據(jù)已經(jīng)達(dá)到UV1500，PV上萬。
以上，就是我在接手家居論壇后的四個(gè)月里，所做的一些運(yùn)營(yíng)工作。
在這里要說明的是，這是我第一次做社區(qū)運(yùn)營(yíng)工作，因此這十四步中有許多步驟的前后順序相當(dāng)值得商榷，比如社區(qū)規(guī)則的制定、社區(qū)新手指南及FAQ的推出、意見領(lǐng)袖的召回以及培養(yǎng)、線上活動(dòng)的開展等等，都應(yīng)該放在運(yùn)營(yíng)早期就做。當(dāng)時(shí)由于缺乏經(jīng)驗(yàn)，基本上是摸著石頭過河，這些運(yùn)營(yíng)工作有的是在經(jīng)理的指導(dǎo)與建議下做出的，有的是借鑒學(xué)習(xí)別的地方站，還有的就是自己平時(shí)混跡百度貼吧、豆瓣、天涯、貓撲時(shí)，覺得社區(qū)本來就應(yīng)該這么做。因而做的時(shí)候一些地方都是懵懵懂懂，知其然不知其所以然，缺乏整體的規(guī)劃與統(tǒng)一的思路。不過本著紀(jì)實(shí)的角度，還是一步步的從頭記錄下來。
后來我一直都有在對(duì)那四個(gè)月的社區(qū)運(yùn)營(yíng)工作進(jìn)行反思，也和別的社區(qū)運(yùn)營(yíng)人員溝通交流過，也研究了一些知名的社區(qū)的運(yùn)營(yíng)歷程與思路。總結(jié)了一些想法，和大家一起討論：
由于直到我離職的時(shí)候，都還不知道什么是運(yùn)營(yíng)，什么是產(chǎn)品，因此這些運(yùn)營(yíng)有的是在經(jīng)理的指導(dǎo)與建議下做出的，有的是借鑒學(xué)習(xí)別的地方論壇，還有的就是作為一個(gè)資深網(wǎng)民，覺得社區(qū)本該如此。故而現(xiàn)在看來，運(yùn)營(yíng)思路缺乏整體的規(guī)劃與清晰的思路。
后來，當(dāng)我初步了解互聯(lián)網(wǎng)產(chǎn)品的運(yùn)營(yíng)知識(shí)后，也研究了一些知名社區(qū)的運(yùn)營(yíng)歷程與思路，與其他社區(qū)運(yùn)營(yíng)同學(xué)交流之后，產(chǎn)生了一些新的想法：
（1）務(wù)虛和務(wù)實(shí)兩種社區(qū)類型的比較
社區(qū)運(yùn)營(yíng)時(shí)，一種是像百度貼吧、豆瓣、知乎這樣，傾向于務(wù)虛，偏向于討論一些陽春白雪的主題，另一種則是如十九樓、萬家熱線這樣的地方論壇，傾向于務(wù)實(shí)，偏向于討論一些親民、接地氣的話題。
而我個(gè)人認(rèn)為，在社區(qū)產(chǎn)品中，后期生長(zhǎng)出的百度貼吧、豆瓣小組、知乎的一個(gè)顯著優(yōu)勢(shì)就是在于，它們將用戶的興趣聚焦為一個(gè)點(diǎn)，而不是地方論壇或是天涯、貓撲這樣的聚集為面。用戶的需求是越來越多元化的，一個(gè)個(gè)百度貼吧、豆瓣小組、知乎問答，將用戶的需求不斷細(xì)化，根據(jù)不同的需求，有相應(yīng)的產(chǎn)品空間。在聚焦為面的論壇中，有一個(gè)問題即是用戶的多元化需求并不能在籠統(tǒng)的一個(gè)版塊很好的得到滿足。
不過地方論壇的優(yōu)勢(shì)在于接地氣，越是接地氣的論壇，越是容易受當(dāng)?shù)鼐W(wǎng)民的喜愛。它有一種具象化的特質(zhì)，將論壇中的一個(gè)個(gè)虛擬的網(wǎng)友轉(zhuǎn)化為現(xiàn)實(shí)生活中同處于一座城市的朋友的傾向，從線上到線下的轉(zhuǎn)化更有優(yōu)勢(shì)。
（2）社區(qū)與資訊的比較
社區(qū)與資訊最大的區(qū)別，大概就是UGC要比PGC內(nèi)容空間大很多。另一方面，資訊要求的是權(quán)威性，可靠性，新聞性，而社區(qū)內(nèi)要接地氣，要雞毛蒜皮，講述身邊人的故事，資訊中是一種中心化的視角，聚光燈圍繞著精英分子、知名人物，而社區(qū)則是每個(gè)人都有自己的故事。
（3）我對(duì)產(chǎn)品社區(qū)的一些想法
現(xiàn)在做APP產(chǎn)品的很多，一般都會(huì)有做配套的產(chǎn)品社區(qū)。我覺得產(chǎn)品社區(qū)，不僅僅是對(duì)產(chǎn)品的體驗(yàn)社區(qū)，不僅僅是用戶提交各種使用產(chǎn)品后的體驗(yàn)報(bào)告的地方，而是用戶用來交流的地方。用戶為了什么而使用產(chǎn)品，那么就讓用戶為了什么而交流。
如果是做互聯(lián)網(wǎng)家裝的產(chǎn)品社區(qū)，那么要的是裝修日記、裝修故事、裝修問題等，如果是做私廚的產(chǎn)品社區(qū)，那么要的是美食方面的美食故事、美食經(jīng)驗(yàn)、菜譜等等；如果是旅游類的產(chǎn)品社區(qū)，比如像攜程的社區(qū)——旅游攻略社區(qū)，就是為用戶提供鮮活、真實(shí)的旅游攻略、游記。
如果把社區(qū)當(dāng)作一個(gè)大院兒，我們要做的大概就是召集鄰居，辦一個(gè)篝火晚會(huì)，聽他們挨個(gè)說自己的故事。講故事的人想獲得掌聲或是安慰，聽故事的人則要滿足人類的窺探欲，人們都需要交流，我們需要他們?cè)谖覀兊纳鐓^(qū)交流。
現(xiàn)如今，經(jīng)過兩年多來不斷的學(xué)習(xí)、交流與總結(jié)，在對(duì)運(yùn)營(yíng)工作歷練更多，對(duì)產(chǎn)品領(lǐng)域系統(tǒng)學(xué)習(xí)之后，我對(duì)于如何運(yùn)營(yíng)一個(gè)社區(qū)總結(jié)了一個(gè)“七步運(yùn)營(yíng)”的方法，七個(gè)環(huán)節(jié)分別為：熟悉產(chǎn)品——競(jìng)品分析——社區(qū)氛圍與種子用戶——拉新與促活——留存與轉(zhuǎn)化——老用戶召回——站好最后一班崗。下面對(duì)這七個(gè)環(huán)節(jié)做一個(gè)系統(tǒng)介紹：
作為運(yùn)營(yíng)人員，與產(chǎn)品團(tuán)隊(duì)、技術(shù)團(tuán)隊(duì)相比，相對(duì)來說接觸產(chǎn)品要晚一些。可能是社區(qū)產(chǎn)品進(jìn)入研發(fā)期才開始介入，也有可能是產(chǎn)品1.0版上線后，公司因?yàn)榉N種需要才開始搭建產(chǎn)品社區(qū)，甚至還有可能是前任社區(qū)運(yùn)營(yíng)離職，臨時(shí)加入或者調(diào)崗補(bǔ)坑。無論哪種情況，當(dāng)我們接手這個(gè)社區(qū)產(chǎn)品的運(yùn)營(yíng)工作時(shí)，需要做的第一件事情就是熟悉產(chǎn)品。
就像神槍手上陣前要檢查槍支彈藥，賽車手比賽前要檢查座駕一樣，社區(qū)運(yùn)營(yíng)人員在運(yùn)營(yíng)前需要對(duì)所運(yùn)營(yíng)的產(chǎn)品有一個(gè)深度的了解。
總的來說，有以下幾點(diǎn)：
現(xiàn)如今的互聯(lián)網(wǎng)行業(yè)，已經(jīng)很難找到一個(gè)沒有競(jìng)爭(zhēng)對(duì)手的細(xì)分市場(chǎng)了。如果真的是接手了一個(gè)沒有競(jìng)爭(zhēng)對(duì)手的社區(qū)產(chǎn)品的話，那么恭喜你，挑戰(zhàn)與機(jī)遇并存。
孫子兵法有云：“知己知彼百戰(zhàn)百勝”，在對(duì)所要運(yùn)營(yíng)的產(chǎn)品各方面都非常了解之后，做競(jìng)品分析就很有必要。對(duì)于競(jìng)品的運(yùn)營(yíng)分析，可以從下面幾個(gè)維度來進(jìn)行：
如果時(shí)間充裕的話，還可以競(jìng)品用戶的身份深入使用產(chǎn)品，加入競(jìng)品的種子用戶群，與競(jìng)品的種子用戶、運(yùn)營(yíng)人員接觸交流。
競(jìng)品運(yùn)營(yíng)分析只是手段，通過競(jìng)品運(yùn)營(yíng)分析，可以讓我們
對(duì)于社區(qū)產(chǎn)品來說，良好的社區(qū)氛圍至關(guān)重要，而良好社區(qū)氛圍的打造與第一批種子用戶的質(zhì)量也有極大的相關(guān)性。
比如知乎在最早期，通過嚴(yán)格的邀請(qǐng)制度使得種子用戶全部為互聯(lián)網(wǎng)行業(yè)以及投資圈、媒體圈的大佬，這批種子用戶被邀請(qǐng)后在獲得榮譽(yù)感的同時(shí)，也對(duì)自己的種子用戶身份高度負(fù)責(zé)，為知乎產(chǎn)出了一批高質(zhì)量的內(nèi)容，幾乎奠定了知乎的社區(qū)氛圍。
在早期社區(qū)氛圍培養(yǎng)時(shí)，常用的模式就是馬甲運(yùn)營(yíng)，運(yùn)營(yíng)工作人員以馬甲的身份產(chǎn)出優(yōu)質(zhì)內(nèi)容，進(jìn)行互動(dòng)，形成一個(gè)我們所需要的社區(qū)氛圍的雛形，吸引種子用戶。
此外還需要對(duì)內(nèi)完善如社區(qū)規(guī)則、新手指南、FAQ等“社區(qū)基礎(chǔ)設(shè)施”；對(duì)外完善如百科、問答、文庫、經(jīng)驗(yàn)等“品牌基礎(chǔ)設(shè)施”。當(dāng)然如果是接盤俠，那么還需要像我之前做的那樣，對(duì)社區(qū)論壇進(jìn)行大掃除，清理違規(guī)貼和垃圾帖。
在早期運(yùn)營(yíng)的時(shí)候，還需要多多收集用戶反饋與意見，與產(chǎn)品團(tuán)隊(duì)合力探尋產(chǎn)品與市場(chǎng)的完美契合，驗(yàn)證PMF。
種子用戶以在目標(biāo)用戶群體的意見領(lǐng)袖為最佳，一般種子用戶的獲取方式有以下幾種：
獲取種子用戶后，需要與種子用戶多多溝通，多多交流，建立種子用戶群，讓種子用戶對(duì)社區(qū)更有參與感。
在良好的社區(qū)氛圍建立后，種子用戶不斷的吸引新用戶加入，PMF也驗(yàn)證完成，就可以開始大規(guī)模的用戶拉新了。制定拉新方案前需要明確目標(biāo)用戶群體的密集區(qū)、如何達(dá)到用戶、如何吸引用戶等問題。
常用的拉新手法：
（1）內(nèi)容拉新
如之前所說的，在早期是通過社區(qū)運(yùn)營(yíng)人員產(chǎn)出大量?jī)?yōu)質(zhì)內(nèi)容，向目標(biāo)用戶群體進(jìn)行內(nèi)容擴(kuò)散，吸引新用戶；對(duì)種子用戶群體產(chǎn)出的內(nèi)容中，進(jìn)行優(yōu)質(zhì)篩選，編輯整理后進(jìn)行擴(kuò)散，可以參考的案例如“知乎日?qǐng)?bào)”、“貼吧精選”。
（2）活動(dòng)運(yùn)營(yíng)
舉辦活動(dòng)，也是拉新的常用方式。結(jié)合自身產(chǎn)品特征和活動(dòng)目標(biāo)、活動(dòng)預(yù)算、運(yùn)營(yíng)能力去開展活動(dòng)吧，不管是大型活動(dòng)、常規(guī)活動(dòng)、小型活動(dòng)，還是線上活動(dòng)、線下活動(dòng)，千萬記得多多做預(yù)案，做過程記錄，活動(dòng)完了最后要做好掃尾工作和復(fù)盤。
（3）病毒營(yíng)銷
可能是一篇優(yōu)秀的文案，一個(gè)走心的視頻，也可能是一個(gè)有趣的互動(dòng)H5，亦或是精妙的活動(dòng)，讓你的產(chǎn)品在社交媒體上大肆傳播。
（4）借勢(shì)營(yíng)銷
可以是內(nèi)容的熱點(diǎn)借勢(shì)，也可以是在活動(dòng)中添加熱點(diǎn)元素，關(guān)鍵是要契合自身產(chǎn)品特質(zhì)與用戶屬性，一些負(fù)面屬性的熱點(diǎn)如無把握還是不要追的好。
（5）打造網(wǎng)紅
如果能夠像知乎那樣有一批自帶粉絲光環(huán)的優(yōu)質(zhì)種子用戶的話是最好的了，如果沒有的話，在已有的種子用戶中選出兩三個(gè)優(yōu)質(zhì)用戶，將他們打造成網(wǎng)紅，通過他們的光暈效應(yīng)來提高產(chǎn)品本身的品牌曝光度，進(jìn)而吸引新用戶。
（6）其他拉新手法
例如SEO/SEM；地推；PR報(bào)道；線下廣告等方式；還有如對(duì)社區(qū)中的內(nèi)容進(jìn)行原創(chuàng)保護(hù)，轉(zhuǎn)載時(shí)須注明內(nèi)容出處及原作者，像“知乎”就是這么干的；讓社區(qū)中的內(nèi)容可以一鍵分享，讓產(chǎn)品有更多機(jī)會(huì)傳遞到社交網(wǎng)絡(luò)中；優(yōu)化不友好的注冊(cè)頁面等等。
拉新時(shí)需要注意平臺(tái)的承載能力以及產(chǎn)品的服務(wù)范圍，更重要的是，拉新之后一定一定要立馬促活，拉新只是手段，沒有激活的用戶等于白白浪費(fèi)先期投入。
① 新手關(guān)懷
新用戶來到一個(gè)新的社區(qū)內(nèi)就像一個(gè)剛出生的孩子一樣，運(yùn)營(yíng)人員要像父母帶寶寶一樣關(guān)懷她。設(shè)置新手提示、新手指南，教會(huì)她如何在社區(qū)愉快的玩耍，讓她看到社區(qū)的精妙所在；在她注冊(cè)后24小時(shí)內(nèi)，給她發(fā)一封歡迎的郵件；給新用戶新手禮包，一些限時(shí)的高階道具等等，都是很好的新手關(guān)懷，當(dāng)然最好的就是社區(qū)內(nèi)有良好的氛圍，老用戶對(duì)于新用戶非常的友好并樂于幫助新人。
② 及時(shí)響應(yīng)
在新用戶注冊(cè)后，能夠及時(shí)得獲得老用戶的互動(dòng)或者是關(guān)注，可以通過機(jī)器人馬甲實(shí)現(xiàn)，也可以通過加大新用戶的推薦權(quán)重來實(shí)現(xiàn)；在新用戶回復(fù)或者發(fā)帖后，能夠及時(shí)得到老用戶或者社區(qū)運(yùn)營(yíng)人員的響應(yīng)，讓他們有一種被關(guān)注的感覺。
③ 魔法數(shù)字
通過數(shù)據(jù)分析，找到用戶在使用產(chǎn)品時(shí)穩(wěn)定下來的標(biāo)準(zhǔn)。比如說對(duì)“知乎”來說，據(jù)說這個(gè)“魔法數(shù)字”是3，也就是如果一個(gè)新用戶在短期內(nèi)回答了三個(gè)問題，那么他就會(huì)成為知乎的活躍用戶。想辦法讓新注冊(cè)的用戶盡快達(dá)到魔法數(shù)字吧，比如說在注冊(cè)時(shí)推薦感興趣的話題小組或是社區(qū)風(fēng)云人物等。
④ 激勵(lì)體系
與產(chǎn)品同學(xué)合力，建立一套良好的激勵(lì)體系，讓新用戶的每一步都被肯定，讓老用戶樂意于傳播產(chǎn)品，幫助新用戶。可以參考游戲化思維，設(shè)置經(jīng)驗(yàn)值、等級(jí)、勛章、道具、老帶新獎(jiǎng)勵(lì)等等。
一般來說，用戶在產(chǎn)品上付出的時(shí)間與精力越多，離開成本就越高；沉淀的關(guān)系鏈越多，離開成本就越高；產(chǎn)出的內(nèi)容，留下的個(gè)人印跡越多，離開成本就越高。
因此，運(yùn)營(yíng)人員可以通過活動(dòng)、社群、建立私人聯(lián)系等等方式，讓用戶更有參與感，讓用戶之間有更多建立關(guān)系鏈的機(jī)會(huì)，讓用戶在產(chǎn)品中產(chǎn)出更多內(nèi)容。讓用戶滿意，給用戶驚喜，提高用戶的忠誠(chéng)度，這樣他們才愿意留下來。還有一個(gè)常用的促進(jìn)留存的方法就是“簽到”，簽到升級(jí)、簽到送積分、簽到抽獎(jiǎng)等等，此方法對(duì)于強(qiáng)迫癥人群尤其有效。
目前社區(qū)產(chǎn)品的轉(zhuǎn)化方式一般是：廣告模式、電商模式、服務(wù)模式，典型的案例如地方論壇、下廚房、O2O產(chǎn)品社區(qū)等。
運(yùn)營(yíng)在做用戶轉(zhuǎn)化時(shí)，要多多衡量商業(yè)價(jià)值與微笑價(jià)值，盡可能的選擇對(duì)用戶體驗(yàn)傷害低的轉(zhuǎn)化方式，結(jié)合自身產(chǎn)品特征思考出更高明的轉(zhuǎn)化方式，典型的負(fù)面案例就是某吧。
老用戶可能因?yàn)榉N種原因，離開了社區(qū)。然而召回一個(gè)老用戶的成本，要遠(yuǎn)低于拉攏一個(gè)新用戶。老用戶的價(jià)值更是遠(yuǎn)遠(yuǎn)高于新用戶：老用戶熟悉產(chǎn)品，老用戶有更為豐富的關(guān)系鏈，老用戶尤其是在社區(qū)產(chǎn)品中，會(huì)留下許多內(nèi)容產(chǎn)出與個(gè)人印跡。
常用的召回模式如郵件/短信召回、活動(dòng)召回、獎(jiǎng)勵(lì)召回等，讓老用戶獲得如付費(fèi)道具一定時(shí)間內(nèi)免費(fèi)用的權(quán)益，或是贈(zèng)與額外道具、勛章等；通過關(guān)系鏈讓活躍用戶召回老用戶，并給予雙向獎(jiǎng)勵(lì)，這都是不錯(cuò)的召回方式。
每一個(gè)產(chǎn)品都有產(chǎn)品周期，從產(chǎn)品上線到拉新促活，再到留存轉(zhuǎn)化，再到收割，最后下線。不過很少有產(chǎn)品會(huì)走到這一步，為了整個(gè)運(yùn)營(yíng)流程的完整性，在這里姑且寫出來吧。
當(dāng)產(chǎn)品下線提上日程時(shí)，一個(gè)方面成本回收，這個(gè)時(shí)候有可能產(chǎn)品和技術(shù)團(tuán)隊(duì)已經(jīng)先撤了，運(yùn)營(yíng)團(tuán)隊(duì)慢慢的也會(huì)逐漸收編；另一個(gè)方面由于社區(qū)產(chǎn)品會(huì)有大量的用戶產(chǎn)出，因此需要考慮如何妥善處置，可能是數(shù)據(jù)遷移到自家公司的另一個(gè)產(chǎn)品上，也可能是數(shù)據(jù)遷移到友商那。無論是怎樣的情況下，運(yùn)營(yíng)人員都需要站好最后一班崗。
在這七個(gè)運(yùn)營(yíng)環(huán)節(jié)中，對(duì)于運(yùn)營(yíng)人員有四個(gè)貫徹始終的需要擁有的能力：
運(yùn)營(yíng)是個(gè)技術(shù)活，也是個(gè)細(xì)致活，還是個(gè)體力活，然而所有的付出，在看到數(shù)據(jù)上漲，收到用戶贊賞，產(chǎn)品漸漸長(zhǎng)大時(shí)，都會(huì)化作點(diǎn)點(diǎn)滴滴的喜悅，支持著我們一路前行！
最后還要感謝《人人都是產(chǎn)品經(jīng)理》的作者蘇杰老師、《產(chǎn)品前線》的作者蘭軍老師、《經(jīng)·理@互聯(lián)網(wǎng)產(chǎn)品經(jīng)理的進(jìn)階修煉》的作者楊曉平老師、 “運(yùn)營(yíng)控”的作者飛魚船長(zhǎng)、“今日雞血”的作者薄荷老師、“類類有話說”的作者類延昊老師、《用戶力》的作者郝志中老師、《產(chǎn)品的視角：從熱鬧到門道》的作者Luke老師等，本文的一些觀點(diǎn)援引自各位老師的著作，也是通過對(duì)各位老師前輩的作品的學(xué)習(xí)，才能讓我在今天可以對(duì)社區(qū)運(yùn)營(yíng)有如今這樣的認(rèn)知。
作者：唐向陽，先后在騰訊家居、地方論壇、搜房家居、創(chuàng)業(yè)公司、傳統(tǒng)企業(yè)等多種類型公司從事運(yùn)營(yíng)工作。
本文選自蘭軍等編著的《運(yùn)營(yíng)前線2》一書 ，點(diǎn)擊鏈接了解更多優(yōu)質(zhì)內(nèi)容：https://item.jd.com/12164754.html
未經(jīng)出版社或作者書面授權(quán)，禁止轉(zhuǎn)載，違者追究法律責(zé)任。
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
