騰訊社交業務規模龐大，歷史悠久，架構復雜。從運維的全局角度來看，無論從運維技術還是監控難度都很大。傳統的監控手段和思想已經無法應對如此海量的場景，騰訊社交網絡運營部歷經十年的建設，在運維監控領域經過了多個建設階段。近幾年通過創新的方法引入了多種技術手段并實踐落地，將監控技術帶入一個新的運維高度，本次將主要分享四個創新技術點。本文整理自聶鑫在 ArchSummit 2017 深圳站上的演講，原題為《騰訊海量監控包袱與創新》。

寫在前面

十年前我到騰訊的時候，運營部剛成立，正好開始做 DO 分離這件事情，研發和運維開始分離了，由專門的團隊來做運維這件事情，但當時沒有太好的運維解決方案和思路，所有的東西都需要靠自己摸索，監控就是其中最大的一個困難點。當時我們主要還在做“補功課”，補齊各種基礎的監控指標和能力。直到 12 年之后業務開始面臨到了很多新的挑戰，高速發展的業務和移動化的進展加快，讓我們面臨的監控難度也越來越大，所以開始有了很多監控相關的新的嘗試。

我們的運維說簡單一點，主要在做三件事情。第一個就是控制業務架構：空間、QQ、QQ 音樂這些服務架構是怎么部署的。第二個，自動化能力：各個團隊，各個公司在自動化運維，智能化運營，精細化運營，包括現在很火的 DevOps，都算是自動化能力的體現。第三部分就是監控能力。這也是運維三個不變的主題之一，也是今天主要講的，聚焦在這里和大家一起來探討一下。

先拋幾個數據。我們現在有將近 20 套監控系統，指標有將近 300 多個，監控的實例超過 900 萬，最可怕的是我們每天有近 5 萬條短信告警，人均 500 條。去年收告警最多的運維，一天能收 1500 條短信，收告警比較多的研發同學，每天也有 1200 條短信。不知道大家有沒有體驗過這種感受，手機里面一天有 1000 條短信過來，這是很讓人崩潰的一件事情。

首先要先簡單介紹一下我們正在做的監控，從 06 年開始到 14 年，我們的監控圍繞著三個目標：“快”，“準”，“全”。大部分建設基本都是圍繞這三個目標去做事情的。首先要求我們的告警能夠覆蓋很全，能主動發現用戶的各種犄角旮旯的異常，為此衍生了各種各樣的監控手段，這就是為什么目前我們會有 20 套監控體系。其次我們希望告警非常快，一出問題馬上發出來，同時希望告警準，誤告警少。目前每天有將近 5 萬條告警，人均幾百條，說明當前告警是不準的。能不能解決好這件事情？可能就成為了在監控領域運維的一種技術和一種藝術。后面分享的幾個比較有意思的小創新，就是它融入了很多老運維同學的運營藝術在里面。

這是我最近剛剛更新的數據，可以看得到我們每天的監控實例非常的龐大。從 09 年開始，當時只有幾套監控，隨后每年都在增長，在 14 年后開始有一些減少，主要是 14 年開始，我們自己也開始在檢討了，發現為了完成快、準、全這三個目標，去建各種各樣的監控系統其實不持久，很多建設都只是在解決“點”上的問題，并沒有體系化解決“面”上的問題，并沒有深層次挖掘其中的關系。所以開始有計劃的去做減法，適當裁減了一些系統。

快速進入到今天的重點，最近我們又做了哪些不一樣的“新”事情。說到創新，這么多的監控系統，存在必有它的合理性，我們去建設新的創新并不是要否定過去監控系統的存在，主要還是希望通過解決歷史中一些不合理的架構演進，用一些創新的方法，讓我們的監控能夠朝真正的快、準、全這個方向去發展，而不是局部優化或者推翻重做這樣子的一個思路。所以下面的一些創新的方法，可能大家會發現運用的技術并不是特別牛逼，可能不是特別了不起的算法。

ROOT

第一個就是代號 Root 的項目，意在找到造成告警的故障根源。這個項目從 12 年我們就開始做，在 14 年的時候在業界分享過。這個是基于業務架構，結合數據流，通過一些算法，能夠將告警進行分析、篩選，從中發現出有價值的告警，推斷出造成告警的故障根源。

因為我們剛才提過，我們有 5 萬條告警，其實騰訊的業務總體服務體驗還是很好的，至少沒有讓人感覺有特別多故障，為什么出現一方面有 5 萬條告警，另一方面好像服務質量還行？可以肯定的有大量的告警是重復和無效的。我們啟動建設 Root 智能分析的目的是希望能夠解決這個問題。

第一，我們需要能夠了解業務架構，這也是運營上的一種思路，“基于業務架構去運營”。在我們的內部里面，是會對一些核心服務架構進行梳理，比如繪制出架構圖來，維護并運營起來。

第二，有了架構圖，我們可以比較方便地去獲取架構之間的訪問關系，有很多手段。同時 20 套監控系統中有大量的數據是帶有一定的邏輯訪問關系的，從中做一些簡單的篩選，就能夠獲取架構中的訪問關系。這個圖是實際的系統截圖，紅線就代表里面有大流量，灰線代表里面流量比較低，是非常容易做得到的。但是這里也有個問題，架構是網狀的，人肉眼來看是很難去區分這里面到底和誰有真正直接的關系，或者說告警發生的服務，和告警的故障根源服務到底是怎么樣的關系。

我們用一些簡單的算法進行“降維”，比如上面的網狀業務訪問關系，可以通過有向的窮舉的方式抽取成鏈條狀，形成服務訪問關系鏈。然后將各種告警往上疊加。我們將各種各樣的告警疊加在這個業務架構的鏈路上面去，比如說當某一種告警產生的時候，就往鏈路上去疊加，其他的告警類似處理，循環著繼續這樣去處理，最后你會發現訪問關系鏈路上面已經疊滿了各種告警。在同一個時間片范圍內就可以開始去分析，根據運維的檢驗，可以推測出架構中哪一條鏈路或者多條鏈路的故障現象和故障根源最有可能發生。

我們假設告警和故障根源的關聯在數據上是有一定的關系，這個關系可能是一種相近性，我們認為兩個服務之間的告警隔的非常近，那么互相產生影響可能性會非常的大，把我們全部業務進行這種降維處理后，大概有四百多萬條鏈路進行計算，當告警發生的時候，就很容易通過一些算法浮現出最有可能的告警根源是哪里？

過去我們很苦惱，每個新的告警對我們的工作都會造成騷擾，但基于 ROOT 這樣的方法論上，我們發現告警越多越好，告警越多越能夠幫我們去把這個關聯做得更精確。

這張圖是我們的系統展現，比如說從這里把告警進行一些疊加，中間可能隔開了，也許它自己沒有接入告警，或者自己的告警并沒有和這個問題現象相關，這是很常見的一種形態。那我們開始算，首先這個算法就會在一定的時間片范圍內，它有一定的范圍，大概前 15 分鐘，后 5 分鐘，因為告警本身自己就會有發送和接收的延時，我們在這里會取前 15 分鐘，后 5 分鐘的時間片，認為這個時間片范圍內的告警才有關聯度。第二個部分就是時間相關性，底下這個服務它每天都在告警，那么其實它的時間相關度是非常低的，它和這條告警產生根源故障的關聯也非常的低，屬于臟數據應該剔除掉。這個算法里面會把這部分的數據作為一個垃圾剔除掉，這個垃圾就是我們剛說的 5 萬條告警。

也有人挑戰過這個問題，你們為什么不去把它梳理一下？把這個梳理干凈了不就很準了嗎？我們也想做這個事情，但是那個包袱實在是太重了。當前我們已經沒有辦法去把所有的臟數據通過人工梳理的方式去掉了，只能夠通過一些額外的算法分析出這些臟數據存在的干擾，能夠把它過濾掉。這個里面就是通過一些時間相關性和時間片的范圍，然后通過鏈路關系和時間關系，一起來決定準確性，這也是我們在尋求告警關聯分析準確度上的一個探索。

我們將告警分成了原因告警和現象告警，原因告警才是造成那個故障的根源，現象告警可能只是故障的結果，其實看不出來故障根源在哪里。

舉例說，用戶 QQ 里面不能發消息了，往往不一定是 QQ 有問題，很有可能后面數據庫宕掉了。在一個多運維團隊協同分工運營體系下，前端負責人很多時候不知道后面那臺數據庫宕掉了，所以現象和結果往往是關聯不起來的，我們這個方法是希望能夠做到這一點。

第二個部分，我們將告警分成持續性告警，波動性告警，關聯性告警。“持續性告警”屬于臟數據，往往是不重要也不緊急的，我們認為不需要立刻去處理。“波動性告警”也是處理起來比較糾結的一點，很多告警會被監控發現，但故障一下子恢復，指標很快恢復，這種告警應該去區別對待，可以根據業務的重要性去做處理，服務如果重要那么可能就要處理分析一下；如果不重要，站在我的立場，我覺得可以不處理。

我們會更加去關注“關聯性告警”，它是有因有果，就應該立刻去處理。有一個簡單的數據，這是最后的結果，我們發現那 5 萬條告警里面，有 65% 屬于持續性告警，不是那么重要，可能不一定真的要把它清理掉，但是對于告警分析來說沒有那么重要。波動告警又占到了 24%，也就說我們有將近 1/4 的告警，只是發生了一下故障很快就恢復了，無論是作為運維，還是作為研發，還是作為技術化團隊里邊的 QA，都沒有必要在這里面去投入過多的人力或者精力，這種波動告警是我們這個體系里面應該過濾掉的。最后一部分，只有不到 10% 的告警才是真正能夠去關聯出原因的，有現象有原因的，這部分告警才是最重要的，我們需要重點去關注的一部分告警。

后面是簡單的一個算法，這種鏈路怎么去判斷權重，哪個應該告警，哪個應該不告警，這里有個簡單的面積算法。簡單解釋一下，根據告警連續，如果一連續它的長度就加，如果不連續它的縱向就減，最后算出一個簡單的面積來。

比較典型的例子，就像這種，同樣是 7 個節點的一條鏈路，同樣是有四個告警疊加的，最后算下來面積它們的面積是不一樣的，算出來會發現很有意思，非常準確能夠分析出關聯性，關聯性越大的，它的面積一定是最大的。最新的基于AI的新算法已經落地，具有更高的準確性。

代碼很簡單，分享給大家。

DLP

16 年初我們開始做 DLP，很有意思，它的英文就是 Dead Live Point，有人很難理解，這個和監控有什么關系？當然前面提到，我們有 5 萬條告警，每個運維都要收好幾百條，到底運維應該收哪些，到底研發應該收哪些？怎么分工才合理？

我作為運維團隊的負責人經常會參加一些故障的復盤會，故障復盤里面會要求寫改進措施，基本上第一條就是告警太多，告警被忽略掉了。大家常常會問：這個故障有沒有告警？一般來說，我們 20 多套監控系統在觀測故障，大多數情況下告警都可以發現，但往往告警都被忽略掉了，沒有人看的過來。說明一個現象，就是我們的告警泛濫已經成為我們發現和解決故障的一種致命的騷擾，所以在這里面，我們很迫切能夠去區分出到底哪些是最重要的。DLP 是我們能夠去區分哪些告警應該去立刻處理，哪些告警可以緩一緩，或者有分工的處理。

DLP 這衡量業務生死的指標，它有幾個要求：

第一，這套告警體系里面是不允許有閥值這個概念的，比如說你告訴我告警超過三次，你就要告警，No，在我們這里面是不允許，比如說業務訪問量正常情況下大概每天 1000 萬量，跌下來了，比如跌到 800 萬，你就得有告警，No，在我們這里也不支持。在我們這里面不允許用閥值，在我們這里面只有一個指標，就是成功率。

第二，一個服務只能有一個生死指標，為什么會有這么樣一個奇怪的要求？我們服務只有幾萬個，為什么會有 900 萬個監控點？舉個例子，我們有的服務會有超過 400 個監控點來監控這個服務的各種緯度運行狀況，比如說它打開 Linux 文件句柄數，內存使用量要監控，磁盤 IO 也要監控，還包括很多業務緯度監控，比如業務成功率，失敗率，各種訪問量、購買量、在線數等等這些監控造就了一個服務可能會超過 400 的監控點，那么當這 400 個監控點有 20 個人關注這個服務，一旦發生告警，這個告警量自然就會很多，這就是為什么會有 5 萬個告警出來。所以在這里面，我們“粗暴”的假設，一個服務只能有一個生死指標，就好像一個人死了還是活著，就只有 0 和 1 的選擇。

第三，是不建議用業務指標做生死指標，這個也很難理解。互聯網產品業務第一，什么東西都是以業務為主的，業務必須第一保障，看指標當然看業務指標，在線數跌了一定是有問題，購買量跌了一定是有問題，這的確是事實，但是作為技術運營線，作為運維，或者說作為最前沿的技術研發，這些指標的一些漲和跌是不是應該馬上去處理的？事實是這個指標的漲跌，可能和很多非技術因素有關系，比如說發布原因造成的，比如活動造成的，這些大家都見過，做一個活動，購買量一定會漲，活動一結束一定會跌，但這些指標是不是我們技術運營線要去第一關注的？在我們這個體系里面也是假設應該由產品人員關注而不是技術人員，我需要知道的是這個業務是死還是活著。所以這在里面，我們不太建議用業務指標作為 DLP，業務指標會被我們人為轉化成為成功率，比如我們會把購買量和購買失敗量兩個指標折算購買成功率，用 DLP 來監控這個購買成功率。

有了前面的三個假設，就可以采取一些簡單的統計學算法幫助我們發現異常指標，比如我們用的的 3 西格瑪算法，拿到環比同比，昨天上周的數據，用 3 西格瑪一算就能獲得一個波峰區間來，你的業務指標只要在這個波峰區間之內變動的，我們基本上就能夠知道這個業務要不要告警了。

上面截圖中的每一段文字就是一個監控點，而此截圖僅僅來自一個服務。僅僅織云 monitor 監控就有 125 萬個指標。這就是為什么我們的告警會有那么多的原因了。所以我們會從這些監控服務中抽出一些關鍵的指標生成 DLP。

當然我們會對告警做各種各樣的數據分析，比如多維數據匯聚。把主調，被調 IP 的聚集度，主調、備調的失敗率，錯誤碼、返回碼、訪問碼的聚集度等數據，并結合 ROOT 做的根源故障推薦，給用戶一個全新的故障定位分析體驗。

這個系統在我們這邊目前使用情況相當的不錯，都有點出乎我的意料，正式推動這件事情大半年，準確率基本上在 95% 以上，一旦這個告警告出來，基本上就一定有問題，漏告的情況下極少。現在有一些技術團隊基本上開始以 DLP 告警為主了，其他的告警為輔。團隊開始由尷尬的監控陷阱中脫身出來，故障處理更有節奏了，從突發故障數量的下降就可以明顯感覺到。

DLP，Root 雖然不算是個技術上很難的創新，但是對于解決監控告警數量的問題特別有幫助。

全鏈路監控

最后一個也是我們最近在做新的一個事情，全鏈路監控。除前面提到 20 多套運維監控系統，我們還有很多其他的數據源，比如有很多產品指標數據，服務器日志數據，用戶日志數據等等各種各樣的數據源。這些數據以前對我們運維來說是負擔，但是現在隨著大數據的興起，我們發現這個數據也是一個寶藏，蘊藏著大量有價值的信息。我們現在在做全鏈路監控建設，是希望能夠去幫助我們數據的生產者、消費者去合理地把數據用起來，能夠幫助我們的生產者有辦法去消費這些數據，過去是做不到的。

要舉個例子大家才能理解什么叫全鏈路，這個圖是 QQ 業務的一個局部服務的架構圖，標記 QQ 里面好朋友見發消息的時序，消息在整個騰訊的體系里會經過 51 個步驟，這里面任何一個地方出問題了，都可能會造成丟消息。過去為了監控丟消息這個情況，整個系統中的這 51 個狀態點都會去埋點，就是做染色，故障發生時可以很快知道消息到底在 51 個系統中的哪個地方丟掉的，這就是早期的染色監控方式。但隨著時間服務架構越來越復雜，產品越來越多，這種方式已經很難推行，特別是站在運維的角度，希望通過這種方式去完成各種業務架構的監控，做不到了，因此“織云全鏈路監控方式”就誕生了。

我們會把基礎監控、特性監控，現網的各種日志，各大系統中的文本類數據等灌到我們的日志中心里去。經過一系列的篩選，提取一些特征，計算一些中間值，形成全連路數據。現在我們也用到一些很多的一些開源組件比如 Elasticsearch 再做一些展現，然后全鏈路監控平臺大概的結構就是這個樣子，最終我們希望能夠幫助用戶去做很多分析。

比如說用戶的數據在我們這邊，這里一列代表了各種數據源，這個案例是個用戶在空間玩直播的案例，它的數據在我們這邊由各種不同的數據源上報上來。這里會把所有的數據列出來，把公共特性的值抽象出來做個對比，如果發現用戶的一些值出現了異常，就可以去做告警了，可以產生一些新的運維事件，就能驅動產品和研發去改進。

這個事情一開始做的時候覺得也挺困難的，各種各樣的日志格式也不一樣，數據形式也不同，甚至都有懷疑說這個方式做不做的下去，但是發現不斷深入去做，這里面發掘出來的一些有價值的數據反倒是越來越多，舉個例子，原來我們都說用戶直播的時候卡頓，我們也不知道是為什么，但現在好了，只要這個用戶一上來，通過所有的數據匯聚就可以知道他用的什么機型，我們還會收集用戶的 CPU，CPU 一直是 100%，很有可能這個機器不是特別高效，比如說它的網絡，有的可能在用 3G 玩直播，可能在一些特殊的場景下，比如電梯里面。

我們一個同事在北京機場玩直播玩不了，終端沒有任何提示的案例。通過全鏈路系統我們技術人員一看，很快發現它的 IP 發生了變化，由 4G 變成了北京機場 wifi，故障發生在 ip 切換后。原來他過去有去過北京機場，所以再次進北京機場的時候他的手機就自動連 WiFi，北京機場 WiFi 是要登陸的，但是他自己沒意識到，APP 也沒有提示，直播自然會失敗。

過去這類個案的投訴只能請研發撈取用戶的日志來分析定位，而現在運維就能快速定位。整個過程很流暢，比以前快太多了。全鏈路的數據對于我們運維和技術人員去定位故障非常有幫助，這個項目在我們現在也是主推的一個項目。

踐行機器學習

后面分享的是一些我們也在探索的部分（201712 月最新的進展已經在織云 AIOps 里面落地，請參考最新分享），所以寫的是踐行，我相信同行們都在做這件事情，跟大家交流一下，包括幾個部分，主要是機器學習相關的。

我們自己總是給自己樹一個愿景：咖啡運維，希望我們做運維的坐在那里喝咖啡就行了，花了十年時間還沒有到這個目標。

這是我們以前的做法，對數據進行各種各樣的分析，大家都用過，各種曲線圖對比，這都是老套路，匯聚、對比、閥值、分布、聚類，這個我們都用過，但是幫助有限。

踐行機器學習 AI 運維，我們首先試水了文本處理領域，比如說這是“織云輿情監控”，就用了機器學習 NLP 處理。

這個項目還要從一個有趣的例子說起，早年我接觸過一個老板，他抱怨說我們的服務質量不好。他的理由很簡單，他每天上百度上去搜，有負面反饋，“空間打不開”這幾個字，搜索排名第一。因此得到結論，我們的服務質量不行。他不管我們自己的監控數據質量多好，認定外面的輿情是負面的，就認為我們的服務質量不行，所以當時我也很苦惱，這個事情我怎么解決？現在我們有了高雅的解決方法，“織云輿情監控”。我們用了一些機器學習中的自然語言處理 (NLP) 方法，通過對各種渠道收集到的用戶的反饋內容進行文本分析，找出異常。

語義分析首先要分詞，然后做情感分析，發現到底是表揚我們的還是批評我們的，如果是批評我們的，它的量會不會有波動，正常每天 20 幾 30 幾，如果突然短暫時間內各種渠道有很多人反饋有問題了，基本上就會有故障，這個語義分析就是我們對機器學習文本這邊的嘗試，效果還蠻好的，這個現在我們所有的產品團隊都在用。

第二部分就是機器圖像學習，前面有一個有滾動條的圖，大家會發現一個模塊下將近有 400 屬性，當一旦有問題的時候，它的監控曲線有很多圖都是類似的，所以我們也在做圖像之間的相似性學習，有 400 個屬性沒關系，也不判斷閥值，就看你曲線長的像不像，我們人很容易判斷，機器也能判斷出來，這也是個挺好的思路，這對完全告警收斂有一定的幫助。

第三個部分是告訴 AI 規則是什么，通過一些有監督學習的方式，讓機器首先去做一些粗判，人工去做一些監督，訓練機器，對曲線的形態有準確的判斷，對我們的告警檢測會相當有幫助。（201712 月最新的進展已經在織云 AIOps 里面落地，請參考最新分享）

前面提到“全鏈路數據”項目里蘊含著大量的數據寶藏，但這些寶藏目前想要分析出來還相當的困難，這里面全是大量的無規則文本，人肉去做分析難度非常大，機器可以做的到，我們能夠做輿情分析，那么對于日志上下文的分析也是有可能實現的。

值得關注點

最后對于監控，除了技術和創新，還有其他值得關注的地方。

過去為了實現快、準、全，我們在監控平臺上做了很多的技術優化，但真正運用的比較好的監控還需要持續的“運營”。如何去運營監控有很多的方法論。比如說我們的指標怎么建立，我們的閉環怎么形成，如何建立監控生態，把相關的團隊，各個團隊全部能夠卷進，比如 QA、研發、運維的角色是什么，怎么去定義，包括這些產品的服務質量考核怎么和監控結合起來，并通過運維指標的變化來反推產品質量優化，這都是我們運維團隊需要思考的。

TIPS

最后是一些小的運維經驗分享，看著小但對運維效率提升很有益處，值得參考。

比如輿情監控相當建議有能力的團隊去嘗試一下，相當的準，對于產品的體驗來說，產品體驗好不好，看數據是一方面，看反饋比看數據還要有效，這是我們切身體會，如果有能力的團隊可以考慮一下輿情的監控。

機器的自動處理（服務自愈），運維人力一般不可能有研發和業務增長快速，有很多事情一定要盡早開始實現自動化處理，比如有些基礎的告警能夠讓機器去處理的就應該讓機器盡早處理，方法也很簡單。

移動運維，還有就是借助方便的手機端處理運維工作，微信還有 QQ 這些工具非常方便，我們現在很多的故障都是在微信里面處理的，在微信可以打開自己的工具，直接就把故障給處理掉了，也很方便。

最后想提一下“告警的分級”。站在運維的角度怎么去做告警分級，和站在研發或產品的角度并不相同，在告警分級這里面有個簡單的規則：合適的人處理合適的告警。

第一個是告警它本身就要級別。第二個，時間上一定要分級，比如該什么時間發的，該什么時間不發的，什么時間應該讓大家去休息和睡覺的，還有范圍也要分級，升級機制也要分級。前面我們之所以有 5 萬條告警，在于之前沒做好規劃，比如一個告警有 20 個關注人，一旦發生問題，這 20 個人都會收到告警，這 20 個人都認為別人在處理，自己都不處理，繼續睡覺，結果帶來的壞處就是，這個告警沒有真正指定到人。所以在告警的一個范圍上應該去做些思考的，告警剛剛發生的時候應該發給誰，告警如果一直沒有被恢復應該發給誰，告警產生了嚴重的質量問題后，或者對一些指標數據產生了影響之后，應該升級到什么規模，這些應該在運維體系里面應該去做。

去年 7 月我在 ArchSummit 深圳站上與大家分享了《騰訊海量監控包袱與創新》，當時大會設置的運維專題仍聚焦在?運維新挑戰上，去年 12 月北京站則設置的是?新一代 DevOps，可以看出大家關注的運維技術熱點已經快速變化。

今年的 ArchSummit 深圳站策劃已經出來了，與運維架構有關的是：不可阻擋的 AIOps。

Gartner 在 2016 年時便提出了 AIOps 的概念，簡單來說，AIOps 就是希望基于已有的運維數據（日志、監控信息、應用信息等）并通過機器學習的方式來進一步解決自動化運維沒辦法解決的問題，同時 Gartner 也預測，到 2020 年，AIOps 的采用率將會達到 50%。

到時候會有哪些新實踐？ArchSummit 深圳站的內容，可以點擊?閱讀原文進行了解，敬請期待。

作者介紹

聶鑫，騰訊運維總監。從開發到運維，伴隨騰訊社交網絡運營部成長的十年，負責過騰訊社交產品所有業務運維工作。目前主要負責 QQ、空間等產品運維團隊管理工作。經歷多個業務產品的誕生到蓬勃，伴隨著運維團隊的成長和成熟，見證著騰訊一代代運營技術的創新和發展。作為運維界老兵有好多故事想和大家講，也特別愿意聽聽各位經歷的酸甜苦辣