Mac 網路分享,導致連線異常

Mac 網路分享功能建立 bridge100 導致連線內網異常

ta-ching chen

1 minute read

近期在外面跑跳展示服務給客戶時,插上 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      !

從菜鳥開始,工程師學 Pitch

TGONext 導師計畫 - 技術創業組,心得分享

ta-ching chen

1 minute read

TGONext - 導師計畫

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

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

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

心得分享

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

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

收費課程 - Kubernetes 容器編排平台導入

讓機器管機器,你才能專注在最有價值的工作上

ta-ching chen

1 minute read

課程推廣

為應付更龐大的流量,許多企業開始將傳統架構轉型成微服務架構,而微服務架構往往牽涉到部署與管理大規模伺服器叢集, 而 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
  • 實戰訓練
    • 指令使用與聲明式宣告
    • 物件組合與應用
    • 系統操作、除錯、分析

Google 如何進行 Code Review - 6

一窺 Google 內部程式審核的指導原則 - Handling Pushback in Code Reviews

ta-ching chen

1 minute read

原文

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

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

Who is right? (誰是對的)

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

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

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

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

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

Google 如何進行 Code Review - 5

一窺 Google 內部程式審核的指導原則 - How to write code review comments

ta-ching chen

1 minute read

原文

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]