Thinking, Coding, and Learning.

先生不知來自何方,亦不知歸去何處,年過而立,參悟生與死,淡泊名與利,但憂天下蒼生。蹤跡走紅塵,藏身山林田野,撫琴於搖滾,振筆於網路,傳道於教學;神遊金庸武俠,往返程式思考,常以此樂而忘眠。... 更多關於我

表達與溝通的差異 2020/08/01 03:21:00

這段是我跟同事分享、也是放在心裡很久,沒有寫下的東西:溝通與表達的差異。原文點這裡

Read More

面試常見的問題 2020/06/21 21:32:31

面試是雙向的,資方要用人,勞方要找機會,雙方透過面試找到彼此的交集、找到共事的可能與機會。本文整理數百次面試經驗過程中,常見的面試問題,希望可以協助更多求職者順利找到理想工作。

問題分成以下幾類:

  • 一、履歷的問題
  • 二、自我介紹的問題
  • 三、面試過程的問題

這些問題種類,裡面各有代表性的各別整理問題的現象。

最後整理一些建議做法,給求職者參考。

Read More

淺談分散式交易 2020/05/16 13:30:00

分散式交易 (Distributed Transactions) 指分散在各個運算單元的一系列任務操作 (Operations) 或任務 (Tasks)、有次序的 (Ordered)、且彼此是隔離 (Isolation)、最終達成一致的過程。達成一致 指的是全部動作都成功、或者全部動作都失敗,後者則透過 Rollback 還原。

分散式交易對應的就是單機交易,也就是在一個運算資源上,完成交易動作,電商最常見的案例就是:

  • 1) 完成訂單 (含付款)
  • 2) 完成扣庫存

這兩的操作 (Operations) 滿足次序性、最後達成交易,也就是關聯式資料庫常說的 ACID 原則。如果這個過程是在分散式系統,就必須有其他機制達到此需求。

常見的分散式交易有幾種協議,像是:

  1. 基於 X/Open 國際聯盟的 Distributed Transaction Processing Model (DTP),簡稱 XA,用來達到強一致性,符合 ACID 原則的協議:
    1. 二階段提交 (Two Phase Commit, 2PC)
  2. 三階段提交 (Three Phase Commit, 3PC)
  3. 另外就是屬於最終一致性、符合 BASE 原則的消息對列 (Message Queue) 方式。

本文整理 XA、二階段提交 (2PC)、三階段提交 (3PC)、TCC (Try-Confirm-Cancel) … 等基礎概念。文章資料主要參考自 Distributed Systems: Concepts and Design (5th Edition)分佈式事務:All or nothing 兩篇的整理。

Read More

寫文件常見的問題 2020/05/09 16:53:00

這段 隨筆 整理的關於 寫文件常見的問題,寫文件跟寫程式一樣,都是需要訓練的。本文整理的是觀察到普遍的錯誤認知,造成普遍的刻板映像。

Read More

災難還原 - 實戰演練 2020/04/30 00:21:00

Using AWS for Disaster Recovery 整理 AWS 針對災難還原的實踐原則,而去年 (2019) 我在公司真實執行災難演練,這是第二次的經驗。這段過程,在年初 (2020/01/08) 的 AWS reInvent reCAP 2019 跟大家分享整個執行過程。

Read More

在整理 如何量測系統的容量? 給自己挖了一個坑,整理這篇,先起個頭。可靠性工程 (Reliability Engineering)1 是系統工程的子項目之一,概念上非常類似於 可用性 (Available),但不全然。依據 Practical Reliability Engineering 的定義,可靠性如下:

The probability that an item will perform a required function without failure under stated conditions for a statd period of time.
可靠性是指某套系統在指定的環境下,在要求的時間內成功持續執行某個功能的機率。

這段定義在 SRE 序中也有引用。

這篇整理個人的理解與簡單總結,不見得與一般的書本一樣,主要專注在 What (可靠性的定義)、How (工程實踐)。

Read More

溝通的原理 2020/03/24 16:53:00

溝通就是把資訊從自己腦袋裡挖出來,然後透過載體,像是用語言、文字、圖畫、藝術、肢體 …. 傳達給另一個人,讓對方知道你在想啥。溝通的理想結果是彼此 100% 知道彼此的感受、體驗、想法,藉由此相互的理解,然後進一步的合作、協作、或者是情感交流。一般透過語言的溝通程序大概如下圖:

整個過程有幾個階段:

  1. 你想說的
  2. 你說出來的
  3. 我聽到的
  4. 我理解的

本文同步發佈在 Matters: 廢文:溝通的原理

Read More

摘要密碼學與資訊安全 2020/03/07 21:42:30

整理一些 密碼學 (Cryptography)資訊安全 (Information Security) 的專有名詞、重要概念、密碼學演算法、應用協議、資訊安全概念,主要資料都參考自 Wikipedia。

  • 本文非一次性整理,相關筆記漸進式整理上來。
  • 本文只是個人學習的梳理,可能有誤,如有建議歡迎給予指導,感謝。
Read More

整理 Key Management Service (KMS) 的學習筆記,包含以下:

  • 一、基本概念
  • 二、基本使用
  • 三、整合應用
  • 四、常見問答

KMS 需要有密碼學與資訊安全的概念,所以另外整理 摘要密碼學與資訊安全 的筆記。

Read More

為什麼要使用容器? 2020/02/08 22:37:00

下班前 (02/07 Fri) 同事問 Container 除了可以讓應用程式在本機與正式環境一樣,跟 VM 比較起來還有什麼好處?認真說可以說很多,簡單整理 我在三分鐘內口述的東西,因為要趕公車,三分鐘到了我就先跑了XDD,這段文字是在公車上敲下的,原文點 這裡

當下第一個直覺就是清楚的資源邊界:隔離性,衍生的議題就是 資源管理成本。第二個想到的就是 資安,衍生議題就是 系統維運 (Operations) 。所以先針對這兩個部分描述。

Read More

事件管理的維度 2020/02/02 12:43:00

最近因為武漢肺炎事件,國家必須用各種方式通報國民,包含嚴重性、通報的方法、交付有意義的資訊。

這整個過程就是事件管理是一樣的。摘錄我在 2017 年分享的一段想法:淺談系統監控與 CloudWatch 的應用,其中第四部分談的異常通報 就是談事件通報與管理的核心概念。

Read More

我認識的計算機科學家 2020/02/01 15:37:03

整理我認識的計算機科學家。

Read More

Hello Hugo 2020/01/20 19:55:31

去年針對 文件持續交付 找了一些工具,當時以 K8s 官方網站作為目標,研究他使用的工具以及架構,後來這件事情就沒有時間持續往下。最近想把個人的入口網站,做更完善的整理,試了一些東西,最後腦海還是出現去年研究 Hugo 的想法,所以整理一下研究的筆記。

Read More

如何意識到問題的存在 2019/12/28 18:21:00

在組織裡推動事情,最困難的往往不是技術上的執行問題、不是成本問題、溝通問題、協作問題,困難的是:

如何讓高層、主管、團隊成員 意識 (Awareness) 到:這是一個必須被正視的問題

當問題被正視了,大家都 Awareness 了,接下來才有開始討論如何解決、如何 有效定義目標與執行、落地、資源才會進來 …

Read More

SRE 讀書會 Round3 結語 2019/12/08 15:01:30

SRE 讀書會 Round 3 從今年 2019/03/15 開始,在 2019/12/05 (四) 的寒流之下完結了,大家頂著 15 度低溫、加上下著雨,依舊準時出席讀書會,走完這次最後的章節。

Read More

今年一整年,起了好幾個跨部門、跨組織的任務,在這過程一直在嘗試讓一個成員、或者讓一個團隊可以自主完成任務的方法,過程中踩了很多雷,像七傷拳一樣,常常是還沒發拳自己就先中了內傷,內力不夠深厚打七傷拳才會傷到自己,後來慢慢梳理出一套可以執行的方法,年底也看到成果了。

除了這些大範圍的協作,工作上經常交付任務給團隊執行,交辦的方式會是口頭交辦、公開的指派、正式的賦予權責,交辦的對象則有自己團隊的資深、到資遣成員,協作團隊的成員 … 不管怎樣的交付任務,都需要一個有效的方法來確立目標是可以執行。

這篇整理了一些歷程與土炮方法,分成以下幾個部分:

  • 一、給任務前,管理者的思考
  • 二、情境領導:不同成員的引導
  • 三、執行與落地
Read More

Study Notes - CloudFront 2019/11/02 03:30:00

CloudFront 是 AWS 非常重要的服務,用了幾年,斷斷續續有一些心得與想法,這次換個方式整理筆記,先全部用 Q and A 方式記錄學習。

本文整理的 Delivery Method 以 Web 為主

Read More

最近有朋友問我一些測試的問題,問題層面很廣,像是去一家新創 Startup 如何 Build Up QA Team?自動化測試該用哪一套?測試的方法論該怎麼落地?聊到後來我發現問題背後的期待有問題,期待是什麼?

測試想要一步到位

基於這個前提,後來我把觀察到的現象與問題寫下,起筆是 2018/07/03 的隨筆,陸陸續續整理以下文章:

這篇文章整理上述文章的想法與整合。

本文的思路,後來整理成專文: 如何意識到問題的存在

Read More

這幾年工作關係,經常讀一些資料,但有幾篇是經常重複閱讀、重複分享,這幾篇文字影響我很多,整理起來需要分享時比較快 XD

  • Jeff Bezos - Amazon CEO
  • Werner Vogels - Amazon Web Services CTO

所有文章標題都是原文連結。

Read More

整理 EKS 的 Networking 相關的問題,主要有規劃、管理 … 等觀測,如下:

  • VPC Consideration: 規劃的考量
  • VPC-CNI Utilization: VPC IP 的使用狀況
  • Cluster AutoScaler: Worker Node 的 AutoScale
Read More

軟體交付的三體問題 2019/10/17 00:16:00

這段個別剪接出來的三分鐘錄影,是今年 (2019) 四月我在新竹敏捷 (交大) 分享的,我稱為 軟體交付的三體問題

Read More

EKS 學習筆記 2019/10/13 19:41:58

整理相關 EKS 的學習筆記,包含規劃 (Planning)、建置 (Provisioning)、管理 (Management / Operation) 等。

Read More

上一篇 整理了使用 kubeadm 安裝 K8s Cluster / Worker Nodes / CNI … 等,同樣的,本文整理使用 AWS EKS 安裝 K8s v1.14 的筆記,安裝過程則以 AWS CLI 為主,同樣方式也可以使用 eksctl、AWS Console、CloudFormation 執行。

如同之前提及,雖然 EKS 是 Managed Service,但是實際上只有針對 Master Nodes,而 Worker Nodes 還是需要自行管理以及維護的,另外針對 Ingress、使用者權限、Log 蒐集、資源監控、網路 (CNI 相關) … 等,還是需要額外規劃。

筆記內容:

  1. 準備: IAM User, IAM Role, VPC Subnets
  2. 建置: EKS Master Nodes, ConfigMap, CNI, Worker Nodes
  3. Q and A
Read More

這也是個朋友問的問題,問題截圖如下:

先不管誰有沒有穿褲子,從整體來看,重新整理問題:

系統發生異常時,第一時間如何快速止血?

底下整理我經常在處理分析時的思路。

Read More

淺談效能測試 整理了關於 Capacity、Reliabilty、Stability 的概念與定義。本文針對如何量測 系統容量 (Capacity),整理怎麼做的方法論,可以當作 Capacity Plan Guideline。

系統容量是透過 量測 (Measure) 出來的,結果是數據統計的報表,而 測試 的結果通常是 pass or fail,故本文的描述不用 測試 這個動詞。

這篇文章整理的是如何執行的概念,但不包含以下:

  1. 介紹工具
  2. 環境如何建置
  3. 如何設計架構
  4. 如何優化架構
Read More

CloudWatch Agent (底下簡稱 CWA)awslogs 的後續版本,提供了更強大的功能與整合能力。整理 CWA 的基本概念、如何安裝與配置、以及常見問題。

本文範例為 地端 (On-Premise) Linux (Ubuntu 16.04) 為例。

  1. 體驗
  2. 簡介
  3. Q and A
Read More

Infra 團隊適合 Scrum? 2019/09/13 23:43:00

朋友 Scott Liao 問了一個好問題:

底下整理當時在 FB 上的想法。

Read More

幾段隨筆,談 IoC / DI 與管理的想法。

Read More

什麼是好軟體? 2019/09/11 09:50:30

一段在公車上寫的 memo,問題是:

什麼是好軟體?

Read More

逆向工程與系統架構 2019/09/09 09:50:30

這段 memo 談的是: 逆向工程與系統架構

Read More

以下這張照片是 Jan, 2015 在 AWS Virginia Data Center 火災的照片:

圖片來源: Amazon data center on fire in Virginia - CNN

其實災難,不管是個人還是在企業,隨時隨地都有可能發生。當企業成長到一定的規模,災難還原計畫,就越來越重要。但是做災難還原準備工作,本身在公司裡面不是所謂的 產出 任務,他屬於 備援 計畫,而且災難復原在傳統的 IT 架構裡,所需要的預算、人力、資源、時間是相當龐大的,大部份的老闆,對於這件事情是不會支持,或者也不太願意投資的。最多做所謂的 異地備援 就算是很不錯的了。

以下整理 Whitepaper - Using AWS for Disaster Recovery (Oct, 2014) 內容。大部份的圖檔都是文件裡擷取出來。

Read More

top 2019/09/08 18:45:00

整理 Linux 效能工具 top 的一些資訊,範例是在 ubuntu 16.04, AWS EC2 c5.large 上的資訊。

Read More

會議的普遍現象 2019/08/25 09:33:00

原文是我 03/26 在公車上寫下的 memo,主要是依照 開會原則 提及的想法,整理看到的問題。

Read More

簡譯這篇精彩的分享:Scaling Infrastructure Engineering at Slack

才 2.5y ,就可以把整個 Infrastructure Engineering 弄成這樣的規模。她提到的有很多情境,架構、招募、組織 … 很有感 … XD

要聽她說 (她有點激動 XD) 。。。

Read More

證照有無用論? 2019/08/14 21:42:30

這篇也是我在上下班路上,在 Facebook 寫的 隨筆。問題如下:

朋友問:要不要去考證照?

這算是老問題。我分成幾個層次來看這件事情:

  1. 基本技能
  2. 解決問題
Read More