2017年6月30日 星期五

[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 電子書 或是試試 天貓 吧,另外,百度閱讀 也可以線上試讀第一章。

2017年6月15日 星期四

透過 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 架構囉。

2017年6月14日 星期三

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 就...