Google SRE 團隊整理出過去二十年的十一條心得

Google 的 SRE 團隊整理出過去二十年的心得,當看故事的心態在看的:「Lessons Learned from Twenty Years of Site Reliability Engineering」,在 Hacker News 上也有討論:「Lessons Learned from Twenty Years of Site Reliability Engineering (sre.google)」。

裡面的項目大多都會在公司成長時不斷的導入,都是夠大就會遇到的。

比較有趣的是第六條,這是唯一一條全部都用大寫字母列出來的:

COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

到 Google 這個規模的架構,這邊就會規劃找完全獨立於 Google 架構的方案來用;我猜應該是傳統的 colocation 機房 (像是 AT&T 之類的),上面跑 IRC server 之類的?

在 Hacker News 上面也有其他人提到 Netflix 也有類似的規劃,需要有一個備援的管道是完全獨立於 AWS 的;另外同一則 comment 裡也有提到 Reddit 的作法是在辦公室裡面放 IRC server 備援:

Yes! At Netflix, when we picked vendors for systems that we used during an outage, we always had to make sure they were not on AWS. At reddit we had a server in the office with a backup IRC server in case the main one we used was unavailable.

IRC 還是很好用的 XD

Load Impact 的 k6 網站壓測軟體

這幾天在 Hacker News 上看到 Load Impact 推出的 k6 壓測程式,結合了 Golang 的執行效率與 JavaScript 的操作語法,讓使用者可以很簡單的進行壓力測試,在 Hacker News 上也有蠻正向的反應:「K6: Like unit testing, for performance (github.com/loadimpact)」,我唯一會在意的應該是 AGPLv3 的部份...

先看了一下資訊,看起來「Load Impact」是公司名稱,「LoadImpact」則是產品名稱,然後現在要改名變成「k6」與「k6 Cloud」:

Load Impact is now k6

Due to the success and rapid growth of the k6 open source load testing tool we decided to rebrand the LoadImpact product as k6 Cloud!

k6 裡面設計了 VU (Virtual User) 的概念,如同字面上的意義,VU 是虛擬的使用者,就技術上來說,每個 VU 都是在獨立的 JavaScript runtime 裡跑:

Each virtual user (VU) executes your script in a completely separate JavaScript runtime, parallel to all of the other running VUs.

然後他們居然把 JavaScript 裡面最「經典」的 async 架構給拔了,所以就不需要一堆 callback & promise 架構,用起來就爽很多:

For simplicity, unlike many other JavaScript runtimes, a lot of the operations in k6 are synchronous. That means that, for example, the let response = http.get("https://test-api.k6.io/") call from the Running k6 example script will block the VU execution until the HTTP request is completed, save the response information in the response variable and only then continue executing the rest of the script - no callbacks and promises needed.

翻了一下 Hacker News 上的討論與程式碼,看起來 JavaScript runtime 這部份是用 Golang 寫的 goja

文件裡面給了不少範例,像是在「Running k6」這邊有直接給出怎麼壓測,10 個 VU 跑 30 秒:

k6 run --vus 10 --duration 30s script.js

另外在 repository 裡面,「samples」這個目錄下有不少範例,可以直接先看過一次從裡面學到不少功能,之後再回去翻一次 manual,應該就會更熟悉...

隨便測了一下還蠻容易上手的,加上有 apt repository 可以直接納入系統管理,看起來應該會放著跑,之後找機會用看看,也許打 API 之類的...

AWS Site-to-Site VPN 支援 AES-GCM 了

AWS 更新了 Site-to-Site VPN:「AWS Site-to-Site VPN now supports additional encryption, integrity and key exchange algorithms」。

這次更新支援了一些新的演算法,其中 AES-GCM 的部份看起來是這次這波最重要的:

Encryption: AES128-GCM-16, AES256-GCM-16.
Integrity: SHA2-384, SHA2-512.
Diffie-Hellman groups: 19, 20, 21.

傳統的方式是 encryption algorithm + hash algorithm 搭配,所以就會出現各種排列組合,而不同的方式在實做上很容易出現安全問題,也就是這篇在討論的:「Should we MAC-then-encrypt or encrypt-then-MAC?」。

AEAD 試著用一包解決,對於實做的安全性好不少...

阻擋網站透過瀏覽器掃 localhost

五月的時候,DuckDuckGoCharlie Belmer 發了一篇關於網站透過瀏覽器掃 localhost 的文章,引起了不少重視:「Why is This Website Port Scanning me?」。

這個月陸陸續續看到一些反制方式了,比較簡單的是透過像 uBlock Origin 這類可以擋特定 url 的方式,像是 EasyPrivacy 裡面把一些大站台的 javascript script 擋下來:「uBlock Origin ad blocker now blocks port scans on most sites」。

在同一篇文章的 comment 處也有人提到 uBlock Origin 可以做的更廣泛:「Block access to 127.0.0.1/localhost and LAN address from the internet #4318」,裡面有人已經整理好丟出來了:「lan-block.txt」,看起來也可以擋一些...

要擋得比較完整的還得考慮 scan.example.com IN A 127.0.0.1 這種方式繞過去的情況?這可能需要用 extension 了...

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN),不使用 AWS 自己提供的串接服務,而是用 pfSense 串接。

會自己搞主要有幾個考慮:

  • 考慮到 AWS Transit Gateway 的費用,每掛一個上去就要多收一次錢,另外上面處理的流量要再收費。
  • 應用的流量不大,所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity,算是夠用了。
  • 而且應用在寫的時候也考慮到斷線後的處理,加上用戶端的網路本來就不怎麼穩定,AWS Transit Gateway 的 SLA 再怎麼高,我也還是得處理斷線時的後續機制,不如就不要那麼緊張...

在設定的時候要注意的事情:

  • EC2 的 Source IP/Destination IP 檢查要關掉,這算是基本盤。
  • VPC 內的 Routing 要確認過一輪。
  • EC2 上的 Security Group 對於 pfSense 的主機得全開,因為 pfSense 會丟出不屬於他自己 IP address 的封包,也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing),這些都還是會經過 Security Group 的檢查,而 Security Group 能設定的數量有限,基本上應該會全開...
  • pfSense 在設完 IPsec 後,同樣在 pfSense 上面的 firewall 需要手動加開,因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法,只是老方法還是很好用...

Mozilla 對 Alexa Top 1M Sites 的分析

MozillaAlexa Top 1M Sites 偏安全面向的分析:「Analysis of the Alexa Top 1M Sites」。

對一般情況比較有用的應該是看絕對數字,也就是哪些功能是大家都優先採用了... 然後可以看出 HPKPSRI 果然是大家都懶得上的功能 (事倍功半 XDDD)。

另外也可以當作是安全性確認的 list,把 HTTP header 類的安全性設定都放上去了。

靜態站台的選擇...

Hacker News 首頁上看到的文章,講 Jekyll 一路跟 Amazon S3Amazon CloudFront 接上去的步驟:「Jekyll CBCD Pipeline to the Cloud」。

我看了以後覺得好麻煩 @_@

然後回頭看 Hacker News 上的評論:「Jekyll Static Web Hosting – Deployment Pipeline on AWS | Hacker News」,看到這段:

What a nightmare. I'm sure there are use cases for a setup like this, but this is not the system I'd like to maintain. I use Jekyll because of it's simplicity. I edit my site in my favorite text editor and rsync to shared hosting.

好多人都有同感啊 XDDD

另外有人提到 Netlify 這個服務:

After I discovered Netlify, I'm kind of thinking "why bother". It's free, I just push to my repo and they take care of all the building/publishing/hosting/CDNs, and they're very responsive for support and have high availability. I'm a very happy customer (or rather leech, as I don't pay anything).

下面評價看起來還算不錯,而且有 free tier 可以用,也許可以找機會玩看看...

掃網域下主機名稱的方式...

原文是講滲透測試的前置作業,需要將某個特定 domain 下的主機名稱掃出來:「A penetration tester’s guide to sub-domain enumeration」。

最直接的還是 DNS zone transfer (AXFR),如果管理者沒設好 DNS server 的話,這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。

看了一下有幾種方式:

應該有人可以提到所有的東西再寫成程式 XD

Alphabet (Google) 的 Project Loon 拿到授權,支援波多黎各的救災計畫

Project LoonAlphabet (Google 的母公司) 透過熱氣球建立網路的計畫。

這次波多黎各災後已經好幾個禮拜了,但還是有大量的基地台還是不通。於是 Project Loon 從 FCC 得到實驗性的執照,建立行動網路:「Alphabet’s Internet balloons will try to restore cell service in Puerto Rico」。

Nearly 82 percent of cell sites in Puerto Rico and 57 percent in the US Virgin Islands are out of service, the FCC said in its daily damage report yesterday. In nearly all counties in Puerto Rico, more than 75 percent of cell sites are not working, and "22 out of the 78 counties in Puerto Rico have 100 percent of their cell sites out of service." Large percentages of residents are also without cable or wireline service.

在 FCC 的公告裡提到授權了 900Mhz 頻段:「FCC GRANTS EXPERIMENTAL LICENSE FOR PROJECT LOON TO OPERATE IN PUERTO RICO」(PDF 檔但是標題是「Microsoft Word」...)。

Project Loon obtained consent agreements to use land mobile radio (LMR) radio spectrum in the 900 MHz band from existing carriers operating within Puerto Rico.

不過由於要讓使用者可以使用現有的 SIM 卡連上網,需要當地電信業者的合作,Google 目前還沒完全確認:

Alphabet hasn't announced a schedule for providing service in Puerto Rico, and the company says it is still determining whether it will be able to help.

Project Loon must be integrated with the network of a cellular company in order to provide service, and Alphabet is “making solid progress on this next step," the spokesperson said. Project Loon is part of Alphabet's X division, formerly known as "Google X."

是一戰成名的機會...

Pinboard 放出使用的 Database Schema

Twitter 上看到 Pinboard 放出他們的 DB Schema,可以看出他怎麼設計一個 bookmark site 的:

檔案在 Pinboard Database Schema 這邊可以看到。

比較好奇的是沒有用 utf8mb4,這代表 4 bytes 的 UTF-8 資料存不進去。另外是 user_tags 這個表格的設計方式,當初在使用 MySQL 設計 tag 架構也有類似的作法...

然後有些 index key 是多餘的 XDDD