Peopleware：腦力密集產業的人才管理之道
Peopleware: Productive Projects and Teams.
當我開始作為一個新手主管時，沒有經驗而茫然，就找書來學習，這本是我第一本學習管理領導的書，閱讀之後收穫許多，我也從而盡量實踐書中的許多觀點作法。但也遇過認為書中內容「很扯」的主管。您的看法如何呢？
分享我所整理的這本書知識重點與個人理解拙見～
2023年12月27日 星期三
2023年12月20日 星期三
ACCELERATE：精益軟體與 DevOps 背後的科學 - 知識整理
去年讀了「ACCELERATE：精益軟體與 DevOps 背後的科學 (Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations)」，
將知識重點、個人見解與實務經驗做了整理。
ACCELERATE：精益軟體與DevOps背後的科學-重點整理、個人見解與實務經驗
2020年1月20日 星期一
關於 SSL 憑證的一些事
在網際網路的世界，
一般為了資料傳輸的安全會使用SSL協定進行加密傳輸，
因此需要使用憑證進行加密，
再加上 Google、Apple 等網路資訊巨擘對資料傳輸安全重視與鼓勵倡導而更加普及與重要。
如 Google 的搜尋演算法在某些類型情境下，
會針對搜尋結果中的網站（例如：電商）是否使用 HTTPS 協定，
用來作為搜尋結果排序的其中一個影響因子。
又如Apple iOS App 要求所有連結後台與網頁都必須採用 HTTPS 傳輸協定。
而憑證本身是不含、也與使用何種傳輸層安全性協定（如：SSL、TLS各版）無關的。
憑證是層層組織單位簽發授權，
他是一個階層式結構。
在所有作業系統如Windows、Mac、Android等等，
都會內建全球的各家根憑證，
這些根憑證組織單位會簽發其下的中繼憑證，
中繼憑證又可以簽發自己下層的中繼憑證，
但只有根憑證會預設就含在作業系統之中。
末端網站使用的憑證檔案，
其內容必須含有簽發給你憑證的組織單位資訊，
也必須含有這個簽發給你憑證的組織單位其憑證的簽發組織單位資訊，
如此一路往上層直到其所屬的根憑證簽發單位。
而作業系統就可以依照憑證檔案裡的根憑證資訊來對照到作業系統內建的根憑證組織單位，
進而可以一路解開你傳輸的資料內容。
以 Google 網站為例，
當我們連結這個網址： https://www.google.com/ ，
可以看到網址列左邊有一個鎖，
點擊鎖頭圖示之後可以查看憑證資訊，
如下圖：再點擊「憑證(有效)」
下圖我們可以看到 Google 的憑證階層，
他們的憑證是被簽發給 *.google.com 網址使用，
也就是鎖有 google.com 下的站台網址都可以使用這張憑證，
例如： https://translate.google.com/
而簽發出這張憑證的簽發單位寫在畫面中的「簽發人名稱 > 一般名稱」
這畫面是 Max 系統的畫面，在其他作業系統可能會有不同的畫面，
但仍然會有相同意思的欄位資訊。
在畫面上方的憑證階層區塊中點擊 GTS CA 101 ，
可以看到其資訊如下圖，
畫面中顯示他是一個「中繼憑證授權」，
也就表示他並不在作業系統中預設含有的憑證列表中，
因為他不是根憑證。
在點擊最上層的 GlobalSign，
出現這張憑證的資訊如下圖，
畫面顯示出他是「根憑證授權」，
也就是在作業系統預設含有的根憑證裡，
這樣 Google 網站綁定的憑證檔案其內容資訊就足夠供 Client 端憑證管理機制對應識別 Server 端( Google )綁定的憑證是否正確可處理。
當某個站台綁定憑證後，
藉由HTTPS連線時，
出現憑證不安全的錯誤訊息，
大致上都是憑證本身有問題
如：Chrome 出現「NET :: ERR_CERT_AUTHORITY_INVALID」、
Firefox 出現「無法辨認節點的憑證簽發者。」，
這表示憑證本身沒有含有足夠憑證簽發者資訊，
憑證簽發者資訊是需要含有層層向上一路到根憑證。
從瀏覽器的設定功能，
可以搜尋到「憑證」的設定功能頁面，
裡面應該可以看到目前 Client 端憑證管理裡面已經含有的根憑證有哪些，
甚至有的可以看到已經含有的中繼憑證有哪些，
中繼憑證並不是作業系統一開始預設就含有的，
而是後來被下載到 Client 端留存的。
如果某個站台使用的憑證僅含有中繼憑證資訊，
這樣並不能確保 Client 端可以安全正確的使用 SSL 連線到該站台。
如果 Client 端瀏覽過其他站台是使用跟該站台同樣的中繼憑證簽發單位，
但其含有完整到根憑證的資訊，
這樣會自動下載中繼憑證資訊留存到 Client 端的憑證管理內，
而後瀏覽前述所提僅含有中繼憑證資訊的站台就可以正常運作 SSL 連線。
但如果 Client 不曾瀏覽到和問題憑證相同簽發單位的完整憑證站台，
憑證管理裡面沒有該中繼憑證所隸屬的根憑證資訊，
則瀏覽憑證僅含有中繼憑證資訊的站台就會出現問題，
無法確保建立安全的連線。
例如：
某A站台使用的憑證為「TWCA Secure SSL Certification Authority」簽發，
並且其憑證檔內容僅到標註簽發者為 TWCA Secure SSL Certification Authority，
則瀏覽其站台會出現「NET :: ERR_CERT_AUTHORITY_INVALID」、「無法辨認節點的憑證簽發者。」錯誤訊息。
若是瀏覽另一個站台B，其憑證為「TWCA Secure SSL Certification Authority」簽發，
並且憑證檔案裡也含有顯示「TWCA Secure SSL Certification Authority」的憑證為「TWCA Global Root CA」簽發的所需使用資訊，
因為「TWCA Global Root CA」為根憑證，
作業系統會自動下載補上「TWCA Secure SSL Certification Authority」的憑證資訊到憑證管理裡。
下次瀏覽A站台就不會遇到「NET :: ERR_CERT_AUTHORITY_INVALID」、「無法辨認節點的憑證簽發者。」的錯誤訊息了。
各家作業系統都會有自己的憑證管理，
Chrome、Edge、Safari 等瀏覽器使用作業系統的憑證管理，
但是 Firefox 是自己內建憑證管理機制。
所以，若是上面的所述的憑證問題例子，
你使用 Chrome 瀏覽而補充了作業系統憑證管理中的中繼憑證所屬資訊，
往後你不再遇到上述問題，
你換用 Firefox 瀏覽時，
而你之前沒有機會用過 Firefox 補充到該中繼憑證資訊，
還是會遇到如「無法辨認節點的憑證簽發者。」這樣的錯誤。
一般開發時，
你可能會因為沒有買或申請公認的 CA 憑證（上述所討論的憑證），
而需要自簽憑證，
若不想遇到瀏覽時憑證檢核無法通過的問題，
則需要將自簽憑證匯入 Client 的憑證管理之中，
但最好還是使用個公認的 CA 憑證來開發會比較方便。
一般為了資料傳輸的安全會使用SSL協定進行加密傳輸，
因此需要使用憑證進行加密，
再加上 Google、Apple 等網路資訊巨擘對資料傳輸安全重視與鼓勵倡導而更加普及與重要。
如 Google 的搜尋演算法在某些類型情境下，
會針對搜尋結果中的網站（例如：電商）是否使用 HTTPS 協定，
用來作為搜尋結果排序的其中一個影響因子。
又如Apple iOS App 要求所有連結後台與網頁都必須採用 HTTPS 傳輸協定。
而憑證本身是不含、也與使用何種傳輸層安全性協定（如：SSL、TLS各版）無關的。
憑證是層層組織單位簽發授權，
他是一個階層式結構。
在所有作業系統如Windows、Mac、Android等等，
都會內建全球的各家根憑證，
這些根憑證組織單位會簽發其下的中繼憑證，
中繼憑證又可以簽發自己下層的中繼憑證，
但只有根憑證會預設就含在作業系統之中。
末端網站使用的憑證檔案，
其內容必須含有簽發給你憑證的組織單位資訊，
也必須含有這個簽發給你憑證的組織單位其憑證的簽發組織單位資訊，
如此一路往上層直到其所屬的根憑證簽發單位。
而作業系統就可以依照憑證檔案裡的根憑證資訊來對照到作業系統內建的根憑證組織單位，
進而可以一路解開你傳輸的資料內容。
以 Google 網站為例，
當我們連結這個網址： https://www.google.com/ ，
可以看到網址列左邊有一個鎖，
點擊鎖頭圖示之後可以查看憑證資訊，
如下圖：再點擊「憑證(有效)」
他們的憑證是被簽發給 *.google.com 網址使用，
也就是鎖有 google.com 下的站台網址都可以使用這張憑證，
例如： https://translate.google.com/
而簽發出這張憑證的簽發單位寫在畫面中的「簽發人名稱 > 一般名稱」
這畫面是 Max 系統的畫面，在其他作業系統可能會有不同的畫面，
但仍然會有相同意思的欄位資訊。
在畫面上方的憑證階層區塊中點擊 GTS CA 101 ，
可以看到其資訊如下圖，
畫面中顯示他是一個「中繼憑證授權」，
也就表示他並不在作業系統中預設含有的憑證列表中，
因為他不是根憑證。
在點擊最上層的 GlobalSign，
出現這張憑證的資訊如下圖，
畫面顯示出他是「根憑證授權」，
也就是在作業系統預設含有的根憑證裡，
這樣 Google 網站綁定的憑證檔案其內容資訊就足夠供 Client 端憑證管理機制對應識別 Server 端( Google )綁定的憑證是否正確可處理。
當某個站台綁定憑證後，
藉由HTTPS連線時，
出現憑證不安全的錯誤訊息，
大致上都是憑證本身有問題
如：Chrome 出現「NET :: ERR_CERT_AUTHORITY_INVALID」、
Firefox 出現「無法辨認節點的憑證簽發者。」，
這表示憑證本身沒有含有足夠憑證簽發者資訊，
憑證簽發者資訊是需要含有層層向上一路到根憑證。
從瀏覽器的設定功能，
可以搜尋到「憑證」的設定功能頁面，
裡面應該可以看到目前 Client 端憑證管理裡面已經含有的根憑證有哪些，
甚至有的可以看到已經含有的中繼憑證有哪些，
中繼憑證並不是作業系統一開始預設就含有的，
而是後來被下載到 Client 端留存的。
如果某個站台使用的憑證僅含有中繼憑證資訊，
這樣並不能確保 Client 端可以安全正確的使用 SSL 連線到該站台。
如果 Client 端瀏覽過其他站台是使用跟該站台同樣的中繼憑證簽發單位，
但其含有完整到根憑證的資訊，
這樣會自動下載中繼憑證資訊留存到 Client 端的憑證管理內，
而後瀏覽前述所提僅含有中繼憑證資訊的站台就可以正常運作 SSL 連線。
但如果 Client 不曾瀏覽到和問題憑證相同簽發單位的完整憑證站台，
憑證管理裡面沒有該中繼憑證所隸屬的根憑證資訊，
則瀏覽憑證僅含有中繼憑證資訊的站台就會出現問題，
無法確保建立安全的連線。
例如：
某A站台使用的憑證為「TWCA Secure SSL Certification Authority」簽發，
並且其憑證檔內容僅到標註簽發者為 TWCA Secure SSL Certification Authority，
則瀏覽其站台會出現「NET :: ERR_CERT_AUTHORITY_INVALID」、「無法辨認節點的憑證簽發者。」錯誤訊息。
若是瀏覽另一個站台B，其憑證為「TWCA Secure SSL Certification Authority」簽發，
並且憑證檔案裡也含有顯示「TWCA Secure SSL Certification Authority」的憑證為「TWCA Global Root CA」簽發的所需使用資訊，
因為「TWCA Global Root CA」為根憑證，
作業系統會自動下載補上「TWCA Secure SSL Certification Authority」的憑證資訊到憑證管理裡。
下次瀏覽A站台就不會遇到「NET :: ERR_CERT_AUTHORITY_INVALID」、「無法辨認節點的憑證簽發者。」的錯誤訊息了。
各家作業系統都會有自己的憑證管理，
Chrome、Edge、Safari 等瀏覽器使用作業系統的憑證管理，
但是 Firefox 是自己內建憑證管理機制。
所以，若是上面的所述的憑證問題例子，
你使用 Chrome 瀏覽而補充了作業系統憑證管理中的中繼憑證所屬資訊，
往後你不再遇到上述問題，
你換用 Firefox 瀏覽時，
而你之前沒有機會用過 Firefox 補充到該中繼憑證資訊，
還是會遇到如「無法辨認節點的憑證簽發者。」這樣的錯誤。
一般開發時，
你可能會因為沒有買或申請公認的 CA 憑證（上述所討論的憑證），
而需要自簽憑證，
若不想遇到瀏覽時憑證檢核無法通過的問題，
則需要將自簽憑證匯入 Client 的憑證管理之中，
但最好還是使用個公認的 CA 憑證來開發會比較方便。
2019年11月25日 星期一
編譯 HAProxy for Windows
HAProxy 官網並沒有提供編譯好的 Windows 軟體，
使用者必須在官網下載 Source Code 後，自行編譯。
我使用 Cygwin 進行編譯，
下載 Cygwin 安裝檔安裝，
安裝過程中，會讓使用者選擇要安裝的額外編譯環境套件，
例如： cmake、gcc-core、cygwin32-gcc-core 等
安裝好之後，Cygwin 安裝檔先不要刪除，
因為後續編譯過程如有缺少編譯環境需要的工具套件，
還是會需要用到它把工具套件安裝進來。
我使用的是 HAProxy 2.0.8 版，
若要使用其他版本可至官網下載。
將下載來的 source code tar 解壓縮並放置在 Cygwin 安裝目錄下的 home 目錄內。
路徑如：
可以使用一些 Linux 的指令，如： ls 。
切換目錄到 /home/haproxy-2.0.8
使用 make 指令開始編譯 HAProxy，我的電腦大概花了 十幾、二十分鐘才編譯好。
編譯完成後，到 haproxy-2.0.8 目錄將 產生出來的 haproxy.exe 及 在 C:\cygwin64\bin\cygwin1.dll 複製出來，
新開一個目錄置放這兩個檔案。
在執行 haproxy 時，需要先建立一個 haproxy.cfg 配置 haproxy 運行的設定。
以下是一個簡單範例：
但是使用這樣的預設值編譯出來的結果，
在配置 SSL 時，
啟動 HAProxy 會發生問題，
才知道沒有含 SSL 的模組被編譯進去。
使用指令查看 HAProxy 在編譯時，有什麼選項可以使用將選擇的套件編譯進去
從顯示的說明，有四個套件是建議啟用：
USE_PCRE : enable use of libpcre for regex. Recommended.
USE_REGPARM : enable regparm optimization. Recommended on x86.
USE_STATIC_PCRE : enable static libpcre. Recommended.
USE_OPENSSL : enable use of OpenSSL. Recommended, but see below.
所以在使用 make 指令時，需要給它啟用這四個模組的參數：
所以這時候需要在使用 Cygwin 安裝軟體，將缺少的套件安裝進來。
我因為先前已經單獨安裝 Git 工具，而它內含了 openssl 工具，
所以我不需要在 Cygwin 在安裝 openssl，
過程中，一邊 try make 一邊補缺少的套件，
最後我安裝了如下的套件：
但仍無法安裝 USE_STATIC_PCRE ，
最後將其剔除，
另外，需要從 Cygwin 目錄中，增加複製 dll 供 HAProxy 執行檔使用：
cygcrypto-1.1.dll
cygpcre-1.dll
cygssl-1.1.dll
cygwin1.dll
cygz.dll
使用者必須在官網下載 Source Code 後，自行編譯。
我使用 Cygwin 進行編譯，
下載 Cygwin 安裝檔安裝，
安裝過程中，會讓使用者選擇要安裝的額外編譯環境套件，
例如： cmake、gcc-core、cygwin32-gcc-core 等
安裝好之後，Cygwin 安裝檔先不要刪除，
因為後續編譯過程如有缺少編譯環境需要的工具套件，
還是會需要用到它把工具套件安裝進來。
我使用的是 HAProxy 2.0.8 版，
若要使用其他版本可至官網下載。
將下載來的 source code tar 解壓縮並放置在 Cygwin 安裝目錄下的 home 目錄內。
路徑如：
C:\cygwin64\home\haproxy-2.0.8開啟 Cygwin64 Terminal，這是一個類 Linux 的環境，
可以使用一些 Linux 的指令，如： ls 。
切換目錄到 /home/haproxy-2.0.8
RYAN.CHEN@TWTY3NB ~ $ pwd /home/RYAN.CHEN RYAN.CHEN@TWTY3NB ~ $ cd .. RYAN.CHEN@TWTY3NB /home $ ls haproxy-2.0.8 haproxy-2.0.8.tar.gz RYAN.CHEN RYAN.CHEN@TWTY3NB /home $ cd haproxy-2.0.8
使用 make 指令開始編譯 HAProxy，我的電腦大概花了 十幾、二十分鐘才編譯好。
$ make TARGET=cygwin $ make install
編譯完成後，到 haproxy-2.0.8 目錄將 產生出來的 haproxy.exe 及 在 C:\cygwin64\bin\cygwin1.dll 複製出來，
新開一個目錄置放這兩個檔案。
在執行 haproxy 時，需要先建立一個 haproxy.cfg 配置 haproxy 運行的設定。
以下是一個簡單範例：
global
defaults
timeout connect 90s
timeout client 90s
timeout server 90s
frontend dashboard
bind *:80
mode http
default_backend dashboard_back
backend dashboard_back
mode http
server dashboard_node_1 10.13.15.10:18083
server dashboard_node_2 10.13.15.11:18083
但是使用這樣的預設值編譯出來的結果，
在配置 SSL 時，
啟動 HAProxy 會發生問題，
才知道沒有含 SSL 的模組被編譯進去。
使用指令查看 HAProxy 在編譯時，有什麼選項可以使用將選擇的套件編譯進去
$ make help
從顯示的說明，有四個套件是建議啟用：
USE_PCRE : enable use of libpcre for regex. Recommended.
USE_REGPARM : enable regparm optimization. Recommended on x86.
USE_STATIC_PCRE : enable static libpcre. Recommended.
USE_OPENSSL : enable use of OpenSSL. Recommended, but see below.
所以在使用 make 指令時，需要給它啟用這四個模組的參數：
$ make TARGET=cygwin USE_PCRE=1 USE_REGPARM=1 USE_STATIC_PCRE=1 USE_OPENSSL=1 $ make install然後，你會發現可能發生錯誤，大致是編譯環境缺少需要的工具套件，
所以這時候需要在使用 Cygwin 安裝軟體，將缺少的套件安裝進來。
我因為先前已經單獨安裝 Git 工具，而它內含了 openssl 工具，
所以我不需要在 Cygwin 在安裝 openssl，
過程中，一邊 try make 一邊補缺少的套件，
最後我安裝了如下的套件：
但仍無法安裝 USE_STATIC_PCRE ，
最後將其剔除，
$ make TARGET=cygwin USE_PCRE=1 USE_REGPARM=1 USE_OPENSSL=1 $ make install
另外，需要從 Cygwin 目錄中，增加複製 dll 供 HAProxy 執行檔使用：
cygcrypto-1.1.dll
cygpcre-1.dll
cygssl-1.1.dll
cygwin1.dll
cygz.dll
2019年11月12日 星期二
MQTT Broker 選擇
目前有幾款免費的 MQTT Broker，
但是免費且支援 Cluster 架構的很少。
最知名的 Broker - Mosquitto，
我個人沒有找到官方文件指出可以架設 Cluster HA 的機制，
之前聽也 Survey 過 MQTT Broker 的同事說過它不支援。
最後挑了三套作評估：VerneMQ、EMQX、HiveMQ。
這三套都支援 Cluster 架構。
HiveMQ 本來是個付費軟體，但在今年大約四五月的時候，推出了免費的 Community 版。
在細看 Community 版和付費版的差異後
發現 Community 版不支援 Cluster，
所以也就淘汰它了，
不然他是個純 Java 開發的軟體，這點倒對我個人有吸引力。
MQTT Broker 最後我選用了 EMQX 有幾個考量評估的點：
- 知名度和討論度：
- Wiki 上的一篇文章 Comparison of MQTT implementations 所列的產品，它在表中呈現出來功能較為豐富。
- 在 Google Trend 的比較中，它都算是比較高談論度。在中國最高，因為這套主要是中國人開發維護的。
- 在GitHub 上（2019/10） Watch：321、Star：5078、Fork：964、Contributors：43，在競爭對手中，都是最高的
- 免費： Apache License 2.0
- 提供 Cluster HA架構： 它是極少數免費 Broker 有提供 Cluster
- 持續維護的狀況：Contributors：43，近一年主要有維護的人員數，也是比競爭對手高。GitHub上的 Issue，也持續有回覆和討論。
- 功能性：除了 MQTT 規格特性以外，也提供 Dashboard 可以觀看連線狀況，並提供 REST API 可以即時設定和取得連線狀態和Client 資訊，例如：使用者帳號
- 支援多種作業平台，包含 Windows ，這點剛好是對我們單位的加分條件
1. 在我們 Survey Broker 的過程，不同的 Broker 都提到測試、驗證、支援這一套
2. 他是很老牌的 Client Library
3. 有多種程式語言版本： Java、 C、C#、JavaScript等等，這樣可以依照不同的情境需要選用對應的程式語言。
4. Java等部份版本支援斷線自動重連
5. 大多數語言支援HA，除了C#、Python、Embedded C/C++
訂閱：
文章 (Atom)