幹壞事是進步最大的原動力
在 Twitter 上看到一個很久前的討論：
— lordlee (@lordlee) December 29, 2021
裡面提到了「Timing Details With cURL」，可以給一個 template 進去輸出內部資訊：
time_namelookup: %{time_namelookup}
time_connect: %{time_connect}
time_appconnect: %{time_appconnect}
time_pretransfer: %{time_pretransfer}
time_redirect: %{time_redirect}
time_starttransfer: %{time_starttransfer}
———
time_total: %{time_total}
不過我實際測試發現現在的 curl 版本要加上 \n 才會換行，之後可以拿來 debug 看看...
AWS 放出前幾天 us-east-1 出事的報告了：「Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region」，Hacker News 上的討論「Summary of the AWS Service Event in the Northern Virginia (US-East-1) Region (amazon.com)」也可以看一下，裡面也有人提到儘量閃開 us-east-1。
而爆炸當天的討論「AWS us-east-1 outage (amazon.com)」也可以看一看，裡面還有聊到企業文化的問題...
AWS 的 us-east-1 除了是 AWS 最早的區域以外，也是目前 AWS 內功能最多的區域 (大多數新功能在第一波都會開放 us-east-1 使用)，然後也是最便宜的區域，所以會有很多人都用這個區域提更服務。
也因為這樣，這個區域也是 AWS 內最大的區域，加上 AWS 是目前最大的公有雲，導致了這個區域的很多東西會遇到以前的人都沒遇過的問題，大概每年 (或是每兩年) 就會有一次比較嚴重的 outage，算是為了價錢而選擇 us-east-1 的人要注意的。
說到價錢，如果是為了找價錢比較低的區域，另外一個可以考慮選擇是 us-west-2，出新功能與新產品時也常常會被放進第一波，目前看起來的歷史記錄應該是比 us-east-1 好不少...
這次出問題的主要是內部控制用的網路 (被稱為 internal network) 擁塞，而非客戶在用的網路 (被稱為 main network)：
To explain this event, we need to share a little about the internals of the AWS network. While the majority of AWS services and all customer applications run within the main AWS network, AWS makes use of an internal network to host foundational services including monitoring, internal DNS, authorization services, and parts of the EC2 control plane.
後面也有提到因為壅塞而導致 monitoring 系統受到影響，只能就手上的 log 去分析猜測，然後逐步排除問題，而 deployment 系統也使用內部網路，所以更新的速度也快不起來...
不過基本上可以預期明年或是後年應該還是會再來一波...
Twitter 發了公告請大家改密碼：「Keeping your account secure」。不只是 Twitter 自家的密碼，如果你有重複使用同一組密碼，也建議一起修改：
Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password.
雖然使用 bcrypt，但因為透過 log 記錄下了未加密的密碼，所以就中槍了：
We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.
Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.
這時候就要再推 Password manager 這種東西了，在每個站台都使用完全不同的密碼，可以降低這類問題帶來的衝擊...
LINE 將內部的座位表由 Excel 管理，改用 Web 界面了：「Excel管理の座席表をLeafletでWeb化した話」，這邊不確定是全球的 LINE，還是只有日本的 LINE...
如果跟日本人有過業務合作的話，就會知道他們對 Excel 的用法只能用
出神入化
來形容啊... 所以看到 LINE 特地寫了一篇來說明他們開發內部系統的事情，覺得還蠻有趣的...
起因是今年四月換辦公室，所以就順便換系統，把本來用 Excel 管理的座位表改用 Web 管理 (然後用了 Leaflet 這個 JavaScript Library)：
人員の増加に対応するために、今年の4月、LINEはJR新宿ミライナタワーに移転しました。移転に伴い、IT支援室ではいくつかの新しい社内システムを導入しましたが、今日はその1つである「座席表」についてお話させていただきます。
這是 Excel 版本的樣子：
這是新版本的樣子，UI 上有更多互動的界面可以操作：
然後文末提到了總務業務量減少，而且因此變更座位變自由了而大受好評 (大概是不會讓總務煩死，所以就可以更自由換來換去 XDDD)：
今回開発した座席表は総務の業務軽減に始まったプロジェクトでした。そして実際に導入後には、座席表の管理にかけていた総務の業務を大幅に削減することに成功しました。また、利用者からもかなり好評で、「これを待っていたんですよ！」といった声もあり、社内コミュニケーションの円滑化に一役買うことができているようです。誰の席でも自由に変更できるという点についても、これまでのところトラブルの報告を受けることなく運用できています。
翻了一下英文版的 blog，好像沒有提到這件事情？XDDD