[BOOK] 创新工场CEO训练营教材:创业就是要细分垄断

很久沒翻書了，一年可能翻不超過 3 本吧?! 這本書在五月中就看到的，那也沒特別有興趣，直到前陣子重感冒後，人厭厭的，只好找點東西刺激一下，開始亂找書來翻，於是乎就從天貓下單了，買了本實體書，不貴，才賣 25 RMB，貴反而在於台灣的快遞(22 RMB)，結果在中國境內就等了 5 天在運輸，拿到書都 7 天了，早知道慢是慢在中國境內，就都改用集運了(11 RMB)，整本書才 163 頁。

這本書的封面最大咖的是 李开复 ，在台灣的社群網站上褒貶不一，我以為會講很多，但只有一個章節，才 30頁（還有幾頁後記）。但開頭第一章說得不錯，提提人才的重要，也鼓勵老闆要分享股份，你是想當個 1000萬美元等級持有 60% 股份呢，還是 10億美金等級持有 20% 股份？所以介紹這本書給自己的老闆，可能也有點暗示要多給點股份吧 *誤*

接著則是 汪华（谷歌中国商务发展总部） 和 傅盛（360/可牛/金山/獵豹移動） 交錯的分享，講得自己的臉好像打了好幾次 XD 這本書醒腦的地方就是這兩位分享的論點，也代表身在台灣很難看清中國市場，更別說台灣幾乎進入已開發中的國家，各行各業的領頭羊早已建制公會築起堡壘，更別說巷弄超商已涵蓋了九成以上的生活必需服務。

我認為比較重要的是提及在一個想做的事業上，要選擇一個長遠有大需求市場的紅海，但起步是一個夠小夠養活自己的藍海，類似寫專利時，要有個 domain 足以讓專利申請通過 XDD 接著面對既有市場時，則是要想想自己提供的改善是否有五倍、十倍的效益，例如比既有產業多 5 倍的效率，單純一兩倍的效益可能不足以撼動原產業，當事業在 A 輪尾聲發現成長無法持續時，就該軸轉了，也代表很多公司無法募到 B 輪，實在是成長停滯了，未來越來越不光明。

這些思維很不錯，的確是要做大事的方向，透過這本書了解 VC 的思維，也間接讓自己的策略改觀，除此之外，這些思維站在找工作上也很受用的，也可用在評鑑公司的健康情況。

例如A輪尾之前，要確認事業營運是否持續高成長，像是營業額或是服務使用人數等，用這個概念去看台灣相關的新創，大概可以找到 cloudmosa 是很健康的，整個團隊人數不大(<30人)，用戶數年年翻倍，更別說在 remote browser 的領域上也堪稱第一，而公司的大戰場就是更廣域的 mobile browser 領域，一堆科技文在評比 mobile browser 時，肯定都會提提 Puffin Web Browser。

整本書我都在享受 汪华 和 傅盛 提到的策略，雖然越看越有動力，但那些策略就像企業管理一樣，沒那個環境，就沒使出的機會，只能先醒腦一下，在看看 side project 可以在找哪些來試試了。此外，這本書尾聲還提及台灣人創業習慣（還用中國台灣這字眼）跟趨勢科技營運策略（當作傳產）打臉一下 XD 或許，這大概這本書沒翻成繁體進入台灣市場的主因吧？！

有興趣可以翻 Amazon CN 電子書 或是試試 天貓 吧，另外，百度閱讀 也可以線上試讀第一章。

透過 Nginx proxy_pass 架構，進行 Service migration

有一個舊網站已活了數年，改造的方向不外乎提升 SEO、移除不需要的檔案、增加系統安全、架構拆分，或是基本的 Web Framework 的抽換使用等等。對於一個 IoT 產業來說，包袱多多，像是 device 不見得會更新到新版，更別說會跟隨 HTTP 301/302 去取得新資源，甚至新網站的開發還沒辦法一步到位全部切換，只好透過 Nginx proxy_pass 架構去處理相容並扛流量了。

在此使用 upstream 管理舊機器們，並且添加新的 log format 多紀錄 $upstream_addr 資訊以便後續維護：

log_format add_proxy_pass '$remote_addr - $remote_user [$time_local] [=$upstream_addr=] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"';

resolver 8.8.8.8;
upstream oldserver {
hostname1;
hostname2;
hostname3;
}

後續，都是在 nginx server {} 定義範圍下。

更改 log 記錄格式：

access_log  /var/log/nginx/access.log add_proxy_pass;

預期 http client 能處理 HTTP 301/302 的服務位置，給予更佳的 SEO URL：

location ~ old_page\.php$ {
return 301 $scheme://$host/new/page/;
}

對於不能用 HTTP 301/302 的，則改用 proxy_pass 機制：

location ~ ^/old/resource {
proxy_pass http://oldserver$uri;
}

對於，有些文件很清楚要更改內文關鍵字的，可以善用 ngx_http_sub_module：

location /old/resource/file\.json {
proxy_pass http://oldserver$uri;
sub_filter_types *;
sub_filter_once off;
sub_filter '//old.hostname/' '//cdn.hostname/';
}

也可以順順換成 CDN 架構囉。

AWS 筆記 - AWS ELB 與 Nginx 之 DOS 惡意攻擊者的處理方式

這個緣由是這樣的，有一台 Server 被狂打，但架構是:

Remote client <-> AWS ELB <-> Web server (Nginx) <-> Application

當有用戶非常好心地發大量 request 來檢查機器漏洞，若 Nginx 預設都沒多做設定，那 access.log 都會只記錄到 AWS ELB IP ，也就是不能把 access.log 紀錄的 IP 拿來 ban ，會變成 ban 掉 ELB。

而 AWS 提供的 Security group 預設是從 Allow 的角度，若要特意 ban 掉某個 IP 會有點難搞，例如要改寫防火牆規則，因此，最後就改成從實體 server 去阻擋遠端 client request 了。

步驟一：先讓 Nginx 可以記錄到真實的 remote ip

/etc/nginx/nginx.conf

http {
    # ...
    real_ip_header X-Forwarded-For;
    set_real_ip_from 0.0.0.0/0;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    # ...
}

如此一來，access.log 的 remote_addr 就可以不是 AWS ELB IP 了。

步驟二：用 Nginx 去 deny ip

/etc/nginx/conf.d/your-service.conf

server {
  # ...
  deny RemoteIP;
  # ...
}

這樣設定後，在用 sudo nginx -t 檢查語法後，就可以啟用了

在此不用 iptables 去阻擋的主因是封包進來的 IP 都是 AWS ELB ，所以才改從 Nginx/App 這層取阻擋。缺點就是 access.log 還是一直肥，好處是可以觀察 access.log 看看對方是不是放棄攻擊了？XD

未來若碰到 DDOS 就...