近期在外面跑跳展示服務給客戶時，插上 USB 啟用 iPhone 手機熱點、啟用 VPN 連線，一氣呵成

Terminal 連線到 192.168.2.x 網段時卻發現無法正常連線，其他 192.168 網段皆正常

詢問同事機器狀況也得到一切正常的肯定回覆，只好口頭說明服務改動。

果然 Live Demo 不是正常人該做的事

當時症狀是 SSH 連線直接卡住沒有出現密碼輸入框，根據過往經驗判斷是防火牆或路由出現異常，考慮到防火牆近期沒有調整規劃，將重心放到檢測路由上

MacOS 上可以透過 netstat 檢測路由狀況，可以看到 192.168.2.x 被送到 bridge100 上

正常來說內網的封包流量要送到 utun6 介面 VPN 路由網段才會正常運作。

$ netstat -rn -f inet|grep 192.168
192.168.0.21       192.168.0.21       UH                  utun6
192.168.1.1        link#25            UHWIig              utun6
192.168.2          link#22            UC              bridge100      !
192.168.2.1        e.e4.41.2e.4.64    UHLWIi                lo0
192.168.2.255      ff.ff.ff.ff.ff.ff  UHLWbI          bridge100      !

TGONext - 導師計畫

在接觸 Kubernetes 的幾年間，看著相關領域快速的發展，自己也因為興趣參與開發在其上的無伺服器框架 Fission。 去年因外力使得出國計畫有所改變，後來決定投入 Kubernetes 相關的領域創業，成立原格科技 Srcmesh。

有句話說得很好: 「一個人可以走得很快，但一群人才能走得長遠」，當角色從工程師轉變身份成創業家這句話感受更為深刻，因為得強迫自己跳出舒適圈學習許多不同領域的東西， 才有辦法讓公司生存下來，而看到 TGONetworks 舉辦導師計畫的「技術創業組」時就知道正是自己所需要的。

組內每個人所在的創業階段各不相同，遭遇到的狀況也有所不同，從產品開發到團隊建立，再到公司遇到危機該如何處理以確保公司持續經營， 而這些正好作為未來公司成長的養份避免落入同樣陷阱中。

心得分享

自己剛好是在創業剛起步的階段，於是趁機和組內導師與組員的 pitch 產品內容，後續根據反饋整理幾個問題與感想分享給各位:

• 使用情境切入，更容易讓參與者融入情境 (內容太過工程師化，亮點不夠明確)
• 放大痛點，告知用與不用這套解決方案的差別
• 不要只提到「能改善」，要更具體提出「改善多少」
• 不要怕於利用過去獲得的 credit

課程推廣

為應付更龐大的流量，許多企業開始將傳統架構轉型成微服務架構，而微服務架構往往牽涉到部署與管理大規模伺服器叢集， 而 Kubernetes 不僅使用到容器技術，更結合 Google 自身多年經驗，將微服務管理變得更為輕鬆。

近年來許多 DevOps、SRE 職缺開始將 Kubernetes 列為面試加分選項，相信未來技術越加普及後會逐漸成為職缺必要條件。用一堂實體課程時間，學習新技能讓自己職業生涯越走越順!

但對於剛接觸的人來說，常會被不同用途的 Controller、Volume、Service 概念搞得頭昏眼花。因此於 2020/10/17、10/24 我會開設 2020 北部實體線下課程 「Kubernetes 容器編排平台導入」， 讓更多人能真正瞭解 Kubernetes 的精髓，並能真正應用於他們日常工作上。

課程內容

內容會從 Kubernetes 基礎開始教起，接著學習進階內容最後上機練習。

你會學到在這個部落格內的 Kubernetes 內容的精華版，並且我會分享使用於生產環境的經驗，以及該如何避免採坑。

基礎概念

• Container (Docker)
• Kubernetes 核心架構介紹
• Kubernetes Pod
• Kubernetes Service
• Kubernetes Volume
• K8S Configuration
• 實戰訓練
  • 指令使用與聲明式宣告
  • 物件組合與應用
  • 系統操作、除錯、分析

原文

• https://google.github.io/eng-practices/review/reviewer/pushback.html

Handling Pushback in Code Reviews (如何面對被推遲處理的評論)

有時開發人員會推遲處理程式審查產生的評論。要麼他們不同意你的建議，要麼他們會抱怨你太嚴格了。

Who is right? (誰是對的)

當開發人員不同意你的建議時，請先花點時間考慮一下他們是否是正確的。因為通常他們比你更接近程式碼，所以他們可能真的比起你來說對程式的某些層面具有更好的洞察力。 他們的論點有意義嗎? 從程式品質的角度來看它是否合理? 如果是的話，讓他們知道他們是對的，然後讓問題沈下去。

但開發人員也並不總是對的。在這種情況下，審核者應該更進一步解釋為什麼認為自己的建議是正確的。 一個好的解釋通常展示了「對開發人員的回覆的理解」以及有關「為什麼被要求對出做出改動」等資訊。

尤其是當審核人員認為給出的建議會改善程式品質時，便應該繼續宣揚自己的論點。只要他們相信所需的額外的工作量最終會改善整體程式品質。

提高整體程式健康狀況這件事，往往是經由每個微小的改動來發生

有時往往需要幾番解釋一個建議才能讓對方真正理解你的用意。切記，始終保持禮貌， 讓開發人員知道你有聽到他們在說什麼，只是你不同意該論點而已。

原文

• https://google.github.io/eng-practices/review/reviewer/comments.html

How to write code review comments (如何寫審核評論)

Summary (總結)

• 和藹且有禮貌的
• 解釋你的理由
• 在「給出明確的方向 (explicit directions) 」與「只點出問題點，讓開發者做決定」之間作出權衡
• 鼓勵開發者簡化程式或增加註釋，而非向你解釋這問題有多複雜

Courtesy (禮貌)

一般而言，對你正在審查其程式的開發人員來說，保持禮貌與尊重的同時，確保評論是非常清楚和有幫助。

一種方法是確保

永遠對程式碼發表評論，而永遠不要對開發人員發表評論

你可能並不總是必須遵循這種做法，但你絕對要在說出會使人不安或有爭議的事情時使用這種方法。例如:

• 糟糕的例子:

Why did you use threads here when there’s obviously no benefit to be gained from concurrency?

為什麼**「你」**要在使用併發沒有明顯益處時使用 threads?

• 好的例子

The concurrency model here is adding complexity to the system without any actual performance benefit that I can see. Because there’s no performance benefit, it’s best for this code to be single-threaded instead of using multiple threads.

在我看來，這裡使用併發模型會增加整體系統的複雜性，卻沒有帶來任何實際性能效益。由於沒有性能上的效益，我們最好在這個程式裡使用 single-threaded 而非 multiple threads。[1]