運營自動化的產品該如何設計？
如何在設計產品的時候，就能實現產品的運營自動化設計（包括病毒式增長、社區氛圍維護）。
諸如這樣的專場活動：專場詳情 - 內推網(neitui.Me)，如果不再需要運營介入，怎麼從產品的角度來實現用戶增長與轉換呢？
增長黑客中所提到的腳本自動化運營，通過爬取合適渠道的用戶郵箱，通過EDM郵件實現轉換，或者是通過操作自動化，模塊化產品，根據用戶選擇來進行產品的調整。除此之外，還有其他的什麼辦法可以使整個產品更具有活力嗎？
內部運營的話，找個電商後台看看，再在自己電腦上裝個bbs ，搞一堆插件，看看它們的設計邏輯，一結合。
再想牛逼，向網遊學習。
搞來搞去無非就是研究活動營銷和成長體系。
至於你要爬數據，群發郵件，那是另外一套。那得自己研究。首先得看你拿到的數據有沒有用。感覺略流氓。
套路到處都可以學。
有沒有效果，得看：
1、你對自己的業務研究得有多透。
2、對人性把握有多深。
3、了解關鍵資源。
我們拿QQ會員活動運營平台架構設計實踐——高效自動化運營來
舉個例子！
QQ會員活動運營平台（AMS），是QQ會員增值運營業務的重要載體之一，承擔海量活動運營的Web系統。在過去四年的時間裡，AMS日請求量從200-500萬的階段，一直增長到日請求3-5億，最高CGI日請求達到8億。在這個過程中，AMS在架構方面發生了大幅度的調整和變遷，我們走過了一段非常難忘的技術歷程。
一、海量活動運營的挑戰和我們的應對思路
一個產品業務的發展總是離不開運營二字，而運營的表現形式很多會體現到活動需求上，越是重運營的產品業務，通常會產生越多的活動運營開發需求。當我們說起「活動」，很多人的第一反應會覺得這是一個並不會有很多技術難度的一個東西。通常來說，如果我們只做1-2個活動，那的確是沒有太多技術難度的，但是，如果我們將這個量級提升到做1000個活動，甚至更多的時候，這就成為一個的技術難題。 1. 活動運營業務的挑戰和難題（1）騰訊SNG增值業務面臨海量活動運營開發的挑戰騰訊的增值產品部在QQ會員體系、遊戲運營、個性化等各個業務上都需要持續高強度的運營性活動來促進用戶的拉新、活躍和留存，這裡本身已經產生了非常多的運營需求。而且，自2014年開始，隨著移動互聯網邁向成熟階段，手Q平台上的手游運營需求大爆發，一個月需要上線的活動出現數倍的增長。
（2）活動開發的複雜性開發一個活動本身需要一定的工作量。尤其是大型的推廣活動，這類型的活動對功能和性能的要求比較高。一個典型的大型活動通常有數千萬的用戶參與，因此，對性能要求比較高，如果再涉及到「秒殺」或者「搶購」類型的高並發功能時，對於基礎支撐系統是一個強力的挑戰。活動功能眾多，包括禮包、抽獎、分享、邀請、兌換、排行、支付等，這些不同的參與和表現形式，也會涉及更多的後端介面通信和聯調。例如，我們的遊戲運營業務涉及上百款遊戲，而不同的遊戲對應不同的服務介面，就遊戲相關的通信介面，就涉及上千個。還有一個非常重要的問題，就是活動運營的安全和可靠性。因為，我們的活動，大多涉及較重要的實物獎品發放，如iphone、ipad等高價值禮包，對安全要求很高。
（3）活動運營開發人力難題傳統手工開發模式，普通活動也需要1周的開發周期，而典型大型活動更是需要1-2周開發周期，開發和測試工作量繁重。並且，很多活動是在指定節假日推廣，通常有嚴格上線時間要求。在緊迫並且快速增長的運營需求面前，人力非常有限。 目前，全年活動上線超過4300個。
2. 活動本質和我們的方法論
通過對不同業務的活動模式的分析和抽象，我們發現事實上絕大部分活動都可以用一組「條件」和「動作」的方式進行抽象和封裝，進而形成通用的「條件」（Rule）和「動作」（Operation）活動組件，不同條件和動作的組合使用，變成活動邏輯的實現。然後，我們希望通過平台化和框架驅動開發的方式，將這些組件統一封裝。同時，在框架和平台層面，為活動組件的運行提供高可靠、高性能、具備過載保護和水平擴展能力的框架支撐環境。活動組件只需要封裝自身業務邏輯，核心功能框架自動支持，從而實現活動運營開發的徹底自動化。
AMS所需要承擔的任務，就是實現這個規劃。需要面臨的，主要是解決三個方面的問題：
（1）建設高效活動開發模式（運營開發自動化）。
（2）搭建高可靠性和高可用性的運營支撐平台。
（3）保證活動運營業務的安全。
二、構建高效活動運營開發模式
2012年初，也就是在AMS產生之前的活動開發模式，相對比較隨意，也並沒有一套嚴格和完整的框架支持，組件的復用程度不夠高。因此，我們開發一個活動，經常需要耗時1周多。當時，開發活動的其中一個特點就是「各自為政」，每個運營開發同學，各自產生了一批前端和後端組件，CGI層也產生了很多不同規則的入口。這些各自實現的組件，結構比較凌亂，不成體系，維護起來也比較困難。最重要的是，這樣的組件對於活動開發來說，使用複雜，復用率低，以至於開發效率也比較低。在當時，活動運營需求也出現了一定程度上的堆積，很多需求沒有人力支持，產品同學也覺得我們上線活動比較慢。
1. 系統架構分層和統一基於這個問題，我們當時想到的第一個解決方案，就是整合前端和後端組件，重新搭建一個結構清晰和統一的系統。將這個系統的介面分層、復用、簡化的原則，逐步構建一個完整的體系。而且，從我們開發的角度來說，最重要的目的，是為減少活動開發的工作量，解放開發人員，提升研發效率。
我們的前端組件通過一個叫Zero的框架統一整合，前端每一個功能以組件的形式出現，統一維護和復用。CGI層則進行了代碼重構，實行框架驅動式開發，將每一個業務邏輯功能，收歸到一個唯一的入口和統一的體系中。核心功能框架自動支持，已有活動功能組件可直接配置使用。如果沒有新的功能接入，運營開發只需要配置一份簡單的參數，就可以完成後端功能邏輯，不再需要寫代碼。對於基礎支撐服務，則以平台化的模式進行管理，做統一接入和維護。當我們做完系統結構的調整後，我們終於實現，通過一份活動配置，來控制前端和後端的組件組合。每一個條件、發貨等動作，都可以隨意動態組合，參與條件通過「與」、「或」、「非」等組合方式，選擇對應的動作，實現活動功能邏輯。
從那時開始，活動開發變得簡單了不少，需要寫的代碼大幅度減少，基本變成「填寫參數」的工作。一個活動項目的代碼從之前的1000-2000行，變成了不到100行。例如，如下圖中，本來需要寫不少邏輯代碼的領取禮包，在前端只變成了一行參數。
清晰的結構提升了系統可維護性，更為重要的是，活動開發效率也得到了極大的提升。
在開發人力不變的情況下，我們活動開發的效率實現了大幅提升，產品的需求積壓的情況，得到有效的緩解。
2. 高可視化開發模式（自動化運營）
然而，到了2014年，隨著「移動互聯網「的快速發展和逐步成熟，我們也迎來了」手游大爆發「時代。因為手游的開發周期更快，幾乎每個月都有很多款新的手游上線，很快手游活動運營的需求出現了爆髮式的增長。AMS承擔的活動需求，迅速從每個月上線60多個上升到200個的量級，在此背景下，開發人力再次捉襟見肘，需求的積壓問題進一步加劇。
既然說到開發人力，就必須介紹一下我們當前的活動項目模式。我們騰訊是一家成熟的互聯網公司，研發流程的每一個環節（設計、重構、開發、體驗/測試、發布），都由不同獨立角色完成。一個普通的移動端活動項目耗時，按照最最快速、最理想的模式計算：設計1天，重構1天，開發2天，體驗/測試1天，也至少需要5天工作日 ，也就是研發周期至少1周時間。理想是美好的，現實總是殘酷的。在實際項目實施過程中，因為各種資源協調和外部因素影響，通常無法達到如此完美的配合，因此，一個普通活動的研發周期，往往都超過1周。
忽然新增100多個需求，無論對於任何團隊來說，都是一個巨大的壓力。於是，我們不得不採用另外一種思路，來看待活動運營，是否可以嘗試不投入開發人力？我們稱之為「自動化運營「， 自動化的本質，就是構建足夠強大的平台和工具支撐，讓運營同學自己完成活動開發。前面，我們提到，開發普通活動時，每一個功能點已經變成了一份簡單的配置，而活動開發的工作，就是將這個配置的活動參數填入到頁面按鈕上。如果，我們實現一個可視化工具，將這個填寫配置的工作，變成拖拽按鈕的功能，這樣就可以徹底告別「寫代碼「的工作。
最終的結果，是我們做一個可視化拖拽的活動模板系統。運營同學只需要經過適當的培訓，就能學會如何使用。首先，運營同學將活動設計圖上傳，模板系統自動切圖（完成重構工作），然後，配置活動功能，通過拖拽按鈕功能組件（本質上是一個div透明蒙層），插入到頁面中。然後點擊體驗和發布，最終完成活動上線。因為我們的功能組件是早就經過嚴格測試，才提供給運營同學使用，通常不需要技術測試同學來做測試。因為從那時開始，運營同學開始大規模替代開發、重構、測試的工作，然而，她們是一群不了解技術細節的人，這裡也無形增加了活動的上線風險。因此，除了這個活動模板的實現之外，我們還根據AMS平台的特性，搭建了一系列的支撐平台和工具。
簡而言之，就是為了避免「人為的失誤「，人的失誤不能靠人本身來避免，而要靠平台和程序來保證和檢測。因此，我們建設了強大而且智能的配置檢查系統和活動數據監控。舉個例子，本來資源池裡有100個禮券，但是，運營同學誤配置為200個，這個時候平台就會檢測並且提示運營同學，這裡配置不正確。自動化運營給我們帶來了研發流程級別的優化，在活動研發流程中，我減少了重構、開發和測試的流程，使得活動項目研發周期大幅度縮短，活動項目研發效率出現質的飛躍。手游運營需求的積壓問題，得到根本和徹底的解決。
我們的高效活動開發模式的構建完成，也促使我們的AMS平台業務規模快速的增長。我們一個月上線的活動項目數，在2015年10月時，上線活動超過400個，而其中有80%以上屬於運營同學「開發「的模板活動。
三、可靠性與性能支撐建設
我們通過構建高效的活動開發模式，促使我們AMS運營平台的業務規模和流量規模，都在過去的三年多時間裡，出現了100倍的增長，同時在線的活動超過1000個。與此同時，AMS平台的可靠性和穩定性，也成為至關重要的指標之一，平台如果出問題，影響面變得很廣。AMS平台的架構分為四個層級，分別為：入口層、業務邏輯層、服務層、存儲層（CKV的NoSQL存儲），還有一個離線服務和監控系統。
1. 可靠性活動運營業務，對平台的可靠性非常敏感，因為這裡涉及到很多高價值禮包的發放，部分還涉及支付環節，穩定壓倒一切。在保證可用性方面，我們做幾個方面的工作：
- 所有服務與存儲，無狀態路由（L5）。這樣做的目的，主要是為了避免單點風險，就是避免某個服務節點掛了，整個服務就癱瘓了。實際上，即使像一些具有主備性質（主機器掛了，支持切換到備份機器）的接入服務，也是不夠可靠的，畢竟只有2台，它們都掛了的情況，還是可能發生的。我們後端的服務，通常都以一組機器的形式提供服務，彼此之間沒有狀態關係，支撐隨機分配請求。
- 支持平行擴容。遇到大流量場景，支持加機器擴容。
- 自動剔除異常機器。在我們的路由服務，發現某個服務的機器異常的時候，支持自動剔除，等它恢復之後，再重新加回來。
- 監控告警。實時統計成功率，成功率低於某個閥值，告警通知服務負責人。
在告警監控方面，AMS平台的建設更為嚴格，我們力求多渠道告警（rtx、微信、郵件、簡訊），多維度監控（L5、模塊間調用、自動化測試用例、AMS業務監控維度等）。即使某些監控維度失效，我們同樣可以第一時間發現問題。當然，我們也會控制告警的周期和演算法，做到盡量減少騷擾，同時，又能真正發現系統問題。
可靠性另外的一個挑戰，就是過載保護。不管我們系統擁有多少機器，在某些特殊場景下，終究有過載的風險，例如「秒殺「和」定時開啟「之類的推廣面前。AMS當前同時在線的活動超過1000，已經太多了，這些活動中，偶爾總會有大流量推廣，並且業務方甚至根本沒有周知到我們。無論在何種場景下，我們必須做到AMS平台本身不能」雪崩「，如果集群掛掉，就影響全量用戶，而做過載保護只是拋棄掉了部分用戶請求，大部分用戶還是能夠獲得正常的服務。在過載保護方面，我們採取了一些並不複雜的措施：
- 平台入口的過載保護。經過業務特性和機器運營經驗，設置Apache最大服務進程/線程數，確保在這一個數目下，機器不會出現宕機或者服務掛掉。
- 後端眾多發貨介面的保護。AMS平台的背後涉及數以百計的後端服務介面，他們性能參差不齊。通過AMS平台內部限流，保護弱小的後台介面。因為，如果將它們壓垮了，就會造成某類型的介面完成不可用。
- 服務降級。旁路掉非關鍵路徑，例如數據上報服務。
- 核心服務獨立部署，物理隔離。雞蛋不能放在同一個籃子里，物理隔離的目的，就是避免業務之間相互影響，保護其他服務正常工作。
2. 秒殺場景的業務保護
秒殺在活動運營中，是比較常見的一種參與形式，它帶來的挑戰除了流量衝擊的問題，還會帶來高並發下的業務邏輯安全問題。這個時候，我們必須引入適當的鎖機制，來規避這些問題。它和線程安全是同一類型的問題。首先是用戶的session鎖，也就是說，同一個子活動功能中，同一個用戶，在前一次發貨請求結束之前，禁止第二個請求。之所以要這樣做，是因為，如果同一個用戶發起兩個並發請求，在一個臨界時間內，可能導致禮包多發。例如下圖中的A用戶，在第一個請求成功寫入參與成功標誌位之前，第二請求是可以通過「條件判斷「，仍然可以進入發貨環節，這樣的話，就可能會讓A用戶獲得2個禮包。
還有一個鎖是基於多個用戶的秒殺保護鎖，場景是類似的，Session鎖，只是變為多個並發用戶，請求同一個禮包，同樣在判斷禮包餘量數目的臨界時間裡，有可能產生「超發「（禮包多發了）。問題很明顯，採用鎖當然就可以解決，但是，採用何種的鎖機制，又是一個值得思考的問題。因為，業務場景不同，選擇的解決方案自然不同。我們從三個不同的思路，來討論秒殺的實現機制。
- 隊列服務。這是相對比較簡單的一種實現思路，我們直接將秒殺的請求放入隊列中的，逐個執行隊列里的請求，就像強行將多線程變成單線程。然而，在高並發的場景下，請求非常多，很可能一瞬間將隊列內存「撐爆」，然後系統又陷入到了異常狀態。或者設計一個極大的內存隊列，也是一種方案，但是，系統處理完一個隊列內請求的速度，通常無法和瘋狂湧入隊列中的請求數相比。也就是說，隊列內的請求會越積累越多，並且排在隊列後面的用戶請求，要等很久才能獲得「響應「，無法做到實時反饋用戶請求。
- 悲觀鎖思路。悲觀鎖具有強烈的獨佔和排他特性，用戶請求進來以後，需要嘗試去獲取一個鎖資源，獲得鎖資源的請求可執行發貨，獲取失敗的則嘗試等待下一次搶奪。但是，在高並發場景下，這樣的搶奪請求非常多，並且不斷增加，導致這種請求積壓在伺服器。絕大部分請求一直無法搶奪成功，一直在等待（類似線程里的「餓死「）。用戶也同樣無法獲得實時響應和反饋。
- 樂觀鎖思路。相對於「悲觀鎖」採用更為寬鬆的加鎖機制，採用帶版本號 （Version）更新。實現就是，這個數據所有請求都有資格去修改（執行發貨流程），但會獲得一個該數據的版本號，只有版本號符合的才能更新成功（版本不相符，也就是意味著已經被某個請求修改成功了），其他用戶請求立刻返回搶購失敗，用戶也能獲得實時反饋。這樣的好處，是既可以實現鎖的機制，又不會導致用戶請求積壓。
我們業務鎖採用的是樂觀鎖的實現方式，因為我們的一個發貨流程通常耗時超過100ms，在高並發下，都容易產生請求積壓，導致我們無法做到實時反饋。我們的實現，確保不管用戶是否請求秒殺成功，都能在500ms內獲得實時反饋。並且，我們將這個實現廣泛使用到各個秒殺和搶購活動中，曾經支撐過5w/s的秒殺活動，表現非常平穩和安全。
四、業務安全體系建設
隨著業務規模的增長，AMS平台每天發出去的發貨操作也越來越多。在非節假日每天發貨5000多萬，在高峰的時候，發貨超過2億。同時，這裡活動中含有很多高價值的東西，例如ipad、iphone、高價值虛擬道具，甚至還有一些活動推廣使用現金禮包（財付通到賬）。如此，我們的業務安全比普通的互聯網產品的要求更高，更嚴格。
1. 傳統安全打擊維度和惡意用戶
成熟的互聯網公司通常都會有自己的安全團隊，一般通過數據建模的方式，搭建出一個惡意用戶黑名單的資料庫，然後持續維護這些惡意賬號和IP等信息，更新數據。然後，我們這個服務接入到裡面去。惡意工作室手持大量的賬號和IP，而我們通過這個惡意資料庫，將它們攔截掉。但是，數據建模的演算法不管如何精細，為了防止誤殺真實用戶，總會存在打擊率的問題，它們通常無法攔截下全部惡意請求，總會有少數的漏網之魚。而我們所思考的，就是在這個基礎上，結合業務，增加新的安全保護策略。可能會有很多人會想，追加參與門檻是否可以取得進一步的保護效果呢？例如，在傳統安全打擊策略的基礎上，再加上業務限制，例如將活動參與條件設置為超級會員（20元一個月的付費會員），這樣的話，我們以更高的門檻來攔截惡意請求。
在以前很長一段時間裡，我都認為這種方法應該是靠譜的，因為提高了參與的門檻。直到有一次，我們捕獲到一批好幾萬的惡意QQ號碼（都是一些號碼很長的垃圾號碼），它們竟然全部都是超級會員，惡意工作室竟然花費了不少錢給它們開通20塊錢一個月的超級會員。從那個時候開始，我開始明白，付費會員身份限制，也是不可靠的。超級會員的身份帶給這些惡意號碼更多的便利，反而可以給它們獲取更多高價值禮包的機會，將獲得東西兌現成金錢，然後覆蓋掉惡意工作室的「投資成本」。
2. 業務安全支撐體系建設AMS建設多個維度，全方面的安全支撐能力。我們將這些安全建設，又分為四個維度：
- 入口安全：和用戶對接的CGI入口，過濾惡意和攻擊請求，保護業務邏輯安全等。
- 人的失誤：開發和運營同學在管理端的誤操作或者配置錯誤，人的失誤不能靠人去保證，而應該建設平台級別的許可權管理和智能檢測，讓人不容易「失誤」。
- 運營監控：多維度建設對業務狀態的監控，確保快速發現問題。
- 審計安全：將敏感的許可權充分收歸、管理、監控，確保可控可追溯。
本文為2015年《中國軟體開發者大會》（SDCC）的大會分享的文字版
QQ會員活動運營平台架構設計實踐--高效自動化運營 - 舒潤 - 博客園
運營自動化，我怎麼覺得這事兒這麼玄乎呢。
俗話講， 三分產品，七分運營。一個產品想要活下來，想要做大，想要越做越好，運營的作用其實是非常重要的。 本人鄙陋，目前想不到有哪些產品是可以實現「自動化運營」的。
如果非要說的話，或許有一些技術性非常強的產品，對運營的依賴是比較弱的。典型的比如搜索引擎，主要還是看搜索結果的準確性，搜索質量好了，用戶量是能自然的增長，獲取更多的份額。但即使是這類產品，完全不做運營也是吃虧的，有好的技術的基礎上在好好運營一下，效果也肯定比完全不做運營要好。
為什麼說運營如此重要呢？ 我覺得是因為，運營的手段要比產品的建設更靈活、更快，靠運營能夠解決的各種奇奇怪怪的問題，適應各種不同的場景。而不是所有的問題都是能靠產品化的方式解決的，把一個方案固化為產品的成本還是比較高的，也比較機械。比如問題描述里提到的爬取郵箱自動轉化之類的方法，解決的還是比較通用、有共性的問題，但一個產品的運營過程中遇到的問題是會很多的，自動化的方法可能很難全部很好的解決。
增長黑客最近比較火，國內目前有幾家從分析的角度出發的SAAS產品還不錯，比如神策和GrowingIO，可以同時服務於產品和運營。分析的結果要產生效果往往需要結合運營自動化來實現。我們公司開發了一個產品幫助運營實現客戶交互的程序化，操作方式非常靈活簡單。從規劃，部署到效果跟蹤都不需要技術人員協助。
下面有一個我們操作界面的視頻：
您也可以訪問我們的網站（www.touty.io）了解更多的信息。
謝邀……
不過我不懂
┐(′～｀；)┌悲傷辣么大
首先研究一下你這個「運營自動化」針對的是什麼產品。研究範圍包括不限於：
- 用戶是如果獲取的
- 產品主線功能
- 用戶行為軌跡
- ……
然後，你再確認一下，你的「運營」目標是什麼。
再然後，假設一下，如果這個「運營」不做「自動化」，為了達成目標，你都需要做什麼，需要怎麼做，需要使用哪些資源，需要考察哪些指標，需要按照怎樣的步調去實施你的運營策略。
最後，把上一步的東西儘可能自動化。這個過程需要不斷得試錯及論證。
=================分割一下=================
還有另外一種做法，找一個對標的公司，把它們的「運營自動化的產品」設計照抄過來。
這個問題可以拋給Python開發者，如何更智能地把一些非必要流程簡化，並且自動化、智能化。
另，現在所謂單純的扒客戶聯絡信息已經很落後了，假設你是客戶，收到一封EDM，你會有多大的幾率去點開？
更多的是要根據客戶行為分析（Python上有很多該類庫），然後匹配給客戶他此刻最想得到的內容，這時候才是增加點擊率、閱讀達成率的關鍵因素。
自動化也好，智能化也罷，前提是人的需求，從客戶潛在意識角度出發，而不強加給客戶你想讓他看的——給客戶他現在最想要的信息
推薦閱讀：