星期日, 8月 26, 2018

SRE Book Ch 1&2


古人的名言說得好:『知易行難』。知道 Google SRE 這本書已經好一段時間了,還是最近才開始因為讀書會而好好的認真讀過。讀完前幾章的心路歷程是這樣的:
  1. 竊喜。過去的經驗畢竟還是有些用處的,看到有一樣的想法,不禁覺得英雄所見略同,還好這些日子沒白活。
  2. 扼腕。看著同樣的經歷活生生被寫在書本上,會覺得如果早點讀過,或許就不需用血淋淋的教訓去換取經驗。
  3. 期盼。個人的經驗總有限制,看到那些被寫出來的,沒經歷過的知識被整理得這麼完整,總想著若能真的實現該有多好,哪怕只是部分也好。
Google 也真夠意思,頭一兩章就擲地有聲,毫不囉唆,把 SRE 這件事整理歸納的很好。其中特別讓人感興趣的觀點是,Google 說 99.999% 跟 100% 根本沒差,SLA 從來就不是越高越好。甚至還引進 Error Budget 這個工具。
In general, for any software service or system, 100% is not the right reliability target because no user can tell the difference between a system being 100% available and 99.999% available. There are many other systems in the path between user and service (their laptop, their home WiFi, their ISP, the power grid…) and those systems collectively are far less than 99.999% available. Thus, the marginal difference between 99.999% and 100% gets lost in the noise of other unavailability, and the user receives no benefit from the enormous effort required to add that last 0.001% of availability.
人才濟濟如 Google,在 Dev 團隊與 SRE 團隊之間終究還是會有思維上的衝突,到底是該追求開發功能與速度,還是要維持高 availability 而盡量減少變動?Error Budget 是這麼看的:

假設我們的 SLA 是 99.95%,就表示每一季度可以接受 64.8 分鐘的 downtime。SLA 既然是 agreement,那就表示只要高於 99.95% 就是過關的,那麼這 64 分鐘就是可以拿來運用的預算:
  • 如果這一季度我們做得還不錯 (或是運氣特別好),沒有 downtime,那麼我們就有 64 分鐘的預算來上一些可能會有風險的新功能,萬一出事 SRE 團隊也不用太著急,因為情況不見得會失控
  • 如果這一季度 Dev 團隊的品質把關不夠嚴謹,已經有 40 分鐘的 downtime 了,那麼 Dev 團隊就乖一點,摸摸鼻子回頭想想怎麼改善
於是觀念一轉 ,突然間海闊天空了。原本吵得不可開交的爭執,變成大家來分餅,來分這塊 64 分鐘的 Error 大餅 (SRE 也可能想試一些較為 aggressive 的 infra change) 。

我們把場景換成 Dev 和 QA 之間 (如果有 QA 團隊的話),是不是 bug free 本身就是個假議題呢?如果沒有 P0 bug,是不是只要讓客戶維持在高度滿意的狀態即可,偶有 P1 或 P2 的 bug 只要傷害範圍不會太大即可?然後 QA 再也不會因為堅持完美而推遲 release,或是 Dev 再也不會為了嚐鮮而不顧產品品質?

同理如果是一個聰明的小孩,要做好 Mother Relationship Management 的話,就可以想想如何定義每個月的調皮預算 (Naughty Budget) — 把媽媽對於小孩乖巧度的期待控制在一個『有點乖又不會太乖』的程度,就可以適當的調皮搗蛋追求刺激,卻又不至於遭到被痛打的命運。

PS: 關於 SLA 這件事最好還是由業務端的人員去跟客戶好好商量 — 畢竟媽媽是無法開除小孩的,但客戶卻可以 XD


lec-1 (2022-05-12) Accelerating deep learning computation & strategies

雖然用 DNN train/predict model 也好一陣子了,但這週才是第一次搞懂 cuDNN 是作什麼的 以前好奇過 tensorflow/pytorch 是怎麼做 convolution 的,FFT 不是比較好嗎? 下面的 reference 就給了很好的解釋: Wh...