🔧 阿川の電商水電行
1. 前言
這是一個關於我新進時期的故事。在某個專案的裝置環境中，發生了一起網路延遲的事件。
雖然不算災難，但現場的人卻心神不寧。
「今天的網路是不是特別慢？」
那時的我，其實內心非常焦慮。
整個網路都異常緩慢，其他團隊的工作也幾乎停擺。
身為菜鳥的我，面對「該怎麼做才好」的狀態，感到無從下手...
這次，我想輕鬆地回顧一下新手時期那些「雖然苦澀，但現在回想起來令人莞爾的」失誤故事。
本文將重點放在當天網路延遲事件的失敗經歷及從中獲得的學習，而非技術細節。
2. 新人時期的我與自建環境
當時我被分配到一個處理自建 L2 / L3 交換機的專案中。
專案由伺服器、儲存設備和網路三個團隊組成，而我負責網路部分。
這個專案的網路架構大概是這樣的：
- 共有三台交換機（實際上更為複雜，但簡化說明）
- 其中兩台通過堆疊功能作為一台邏輯上的交換機（以下簡稱為堆疊交換機）
- 其餘一台是獨立交換機，通過鏈路聚合（以下簡稱為 LAG）與堆疊交換機連接
- 各種作業 PC 和伺服器等連接至各個交換機，按團隊進行裝置
看著構成圖我心裡想「嗯嗯…原來如此」，但其實我完全不懂，哈哈。
這時，來自前輩的提問。
「為什麼會選擇這樣的架構？」
「這些設定有什麼必要？」
「這個機制是怎麼運作的？」
「對整體環境有什麼影響？」
每當被問的時候，我的思維都快要崩潰了。
設定過程幾乎是純粹的抄錄。
在這種狀態下開始的裝置作業，成為了我後來出錯的伏筆...
3. 事件當天
那天的早上，我正在微調 L2 / L3 交換機的設定。
突然，其他團隊傳來了文章標題中的言辭。
「今天的網路是不是特別慢？」
那天，前輩說「今天是裝置環境，沒有太多工作，所以你一個人就可以了」，我獨自在現場負責網路。
我試圖確認狀況，但完全不知道發生了什麼...
一開始我還以為「只是剛好有點慢？」但狀況迅速惡化。
- ping 不通
- 遠端畫面停頓
- 網頁畫面沒有回應
回過神來，我才發現整個專案的工作已經停止了。
各種情況不斷湧來，但我完全無法思考。
最終，我的行動是...
只是坐在椅子上無所事事地發呆...
4. 網路延遲的原因
下午時，值得信賴的前輩來到了現場。
在大致了解情況後，檢查了實機。來到現場不久，前輩便拔掉了圖片中的 LAN 線，結果...網路延遲瞬間解決。
接著，他快速確定了原因（真帥…）。
網路延遲的直接原因是廣播風暴。
例如，這種情境會發生：
- 多條 LAN 線將交換機連接在一起
↪在這種情況下，網路就形成了「可以繞一圈的循環結構」 - 在此狀態下，ARP 等廣播幀開始傳送
↪廣播幀將轉發到除接收端口外的所有端口 - 由於循環結構，散播的幀會通過其他路徑回到原交換機
↪交換機會將其認為是新的幀，再次向所有端口發送 - 如此不斷重複，廣播幀不斷增殖
↪網路帶寬及交換機、連接設備的處理能力被廣播佔用，
原本必要的通信數據被無法處理而捨棄
↪最終導致整個網路變得緩慢，無法通信（即廣播風暴）
雖然我本來想寫一篇更詳細的廣播風暴解釋，但我找到了一篇我當時讀過的文章，如果有興趣請參考。
至於為什麼會發生廣播風暴...
真正的原因（即罪魁禍首）是我的設定錯誤。本來應該在圖片中標示的目標端口進行 LAG 設定。
那天我只是微調了交換機的設定，並沒有改變電纜的配線。
也就是說，堆疊交換機和獨立交換機之間原本連接了兩條 LAN 線，但為什麼整個網路並沒有出現延遲呢（這，為什麼？根據前面的解釋不應該會慢...？）。
整理原因如下：
- 作業前啟用了生成樹協定（以後簡稱 STP），一條 LAN 線已經被阻塞
↪在這種情況下，循環不會發生，網路保持穩定
- 我依照設計書將 STP 停用
- 停用的話必須進行替代的 LAG 設定，但我忘記進行設定
- 最終導致廣播風暴的發生
LAG 是一種可以防止循環，同時實現冗餘和帶寬擴展的技術。
簡單來說，它可以將多條電纜聚合起來，
「從交換機的角度，看起來只有一條 LAN 線」這樣的技術。
因此，即使存在多條電纜，也不會形成循環
（即不會發生廣播風暴）。
- 好處①：若任一條線斷掉，通信仍然正常（冗餘）
- 好處②：由於使用多條線，通信帶寬也會擴大（帶寬擴展）
這樣一整理就覺得「這是理所當然的」了，但當時的我完全超出承受範圍。
在前輩來之前，我根本無法掌握整個原因。
最後，在前輩的幫忙下確定了原因，並如圖片所示進行了 LAG 設定，這一天的作業得以順利完成...
↓
5. 深刻的體會
這次的失誤讓我深刻體會到，光有技術能力並不能讓團隊作業順利進行。
在多個人配合時，理清思路並表達出來的能力非常重要。
例如，
- 不知道自己剛才做了什麼
- 現在發生了什麼事無法描述
- 影響範圍自己也無法掌握
在這種狀態下，確定原因會變得更加拖延。
現在想起來，當時我根本無法進入「首先整理自己的思路並用言語表達」的階段，距離「用容易讓對方理解的表達方式進行傳達的能力＝語言化能力」還相距甚遠。
雖然如此，如果我現在要給當時的自己提個醒，「比起那些說明，身為裝置環境的情況下，首先應該拔掉電纜解決循環！影響到其他團隊的作業，真的很麻煩...」
先行採取行動・確認，即使只是這樣，也能大幅減少整個團隊的損失。
作為菜鳥的我焦慮地僵住了，只能坐那裡發呆。
雖然多虧有前輩的幫助，但如果是我一個人，肯定會浪費相當多的時間...
在這裡整理的，是事故後我個人的行動。
關於忘記 LAG 設定的原因、審核體系等等，還有很多我感到痛心的事，但這次重點在「網路變慢事件後」的學習。
6. 自那天以來的經驗
那天我充滿了焦慮和懊悔，但回顧起來，我認為這是一個塑造我現在的重大經歷。
簡單總結來說，我從那天學到了以下三個「重要性」。
順便一提，現在主要的負責領域是混合雲，但那天的經驗至今仍然對我非常有幫助。
① 技術理解與整體把握的重要性
- 深刻體會到小的設定也會對整體環境產生影響
- L2 / L3、STP、LAG 等「使用技術的基礎理解」非常重要，從那天開始開始了基礎學習
- 有了這些技術基礎的問題，能更容易望遠整體，也能找到解決的線索
成為我現在的「對事物先把握全體形象」的風格的契機！
我在網路基礎學習中實際使用的教材這裡
「5-2. 學習網路的推薦教材」
② 情況整理與傳達方式的重要性
- 在發生故障時，只需大致列出「最近的作業 → 發生的現象 → 影響範圍」即可清晰思考
- 雖然當時沒有意識到，但如果頭腦混亂是什麼都無法開始的
- 在團隊協作中，理清思路並用語言表達的能力非常重要
成為我現在的「以能讓對方理解的形式進行解釋的能力（＝語言化能力）」提升的契機！
我在培養語言化能力時實際上意識到的事項這裡
「3. 在 Qiita 發文中獲得的三個價值（優勢）」
③ 自我理解與改善迴圈的重要性
- 知道「焦慮 → 崩潰 → 僵住 → 發呆...」這樣的自我習慣能更容易找到應對的方法
- 進行「事件發生後的現象與原因整理 → 預防措施 → 加強不足的技能 → 在類似事件中的應用」的迴圈會使理解迅速深化
- 失敗固然痛苦，但採取適合自己的改善方式會真的降低再發率
成為我現在的「在了解自身特性（性格）後來推進事情的風格的契機！
7. 結語
那天網路變慢的經歷，坦白說讓我非常痛苦，光想起來就讓胃不適。
但是，正因為那次的失敗，才造就了今天的我。
就我而言，技術的學習比起成功經驗，從搞砸的經歷中學到的似乎更多。
希望這篇文章能引起同樣因焦慮而迷惘的某些人「好吧，冷靜點，還是可以應對的」的感想。
謝謝您看完這篇文章。
原文出處：https://qiita.com/KoheiKushida/items/2e4d3a0466c3c8a8f744
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
