在中小型企業或 ISP 工作

1. 在中小型企業或ISP工作 Chapter 2 支援中心 CCNA Discovery S2

6. 2.1.1 ISP支援中心組織 • 大多數企業的業務運作都需要連線區域網路或網際網路。 • 對於企業而言，排除網路故障極為重要。 • 企業的網際網路連線是 ISP 提供的，因此在發生連接故障時，ISP 也提供相應的技術支援。 • 此類支援通常包括協助客戶解決設備故障。ISP 支援一般透過 ISP 支援中心提供。 • ISP 支援中心技術人員擁有精深的知識和豐富的經驗，能夠協助使用者修正問題，幫助他們接入網路。 • 這些技術人員為客戶提供故障解決方案，一方面是為了最佳化網路效能，另一方面也是維繫客戶的需要。 • ISP 支援中心往往都是使用者或企業尋求幫助的第一站。

7. 2.1.1 ISP支援中心組織 • 優秀的支援中心團隊可確保問題得到快速解決，同時使客戶感到滿意。 • 提供網際網路服務是一個競爭極為激烈的行業，糟糕的服務會導致 ISP 的客戶流失到競爭對手。

8. 2.1.1 ISP支援中心組織 • ISP 通常提供三級客戶支援： • 第 1 級：由初級支援中心技術人員提供即時支援。 • 第 2 級：由經驗更為豐富的電話支援人員處理呈報的客戶來電。 • 第 3 級：處理電話支援人員無法解決的問題，一般需要派遣技術人員到客戶現場進行處理。 • 除了 ISP ，許多大中型企業也建立了自己的支援中心或客戶支援團隊。 • 技術人員的職位可能不同，但上述的三級架構是最為常見的方式。 • 根據組織的規模，支援中心的人員組成也會有所不同。 • 有的支援中心可能只有一個負責處理所有三級支援的人員，有的則可能是完整的客服中心，有著詳盡的來電轉接和逐層呈報機制。 • 某些 ISP 和企業將其支援中心業務外包給第三方客服中心公司，由它們來負責第 1 級和第 2 級支援服務。

10. 2.1.2 ISP技術人員的角色 • 使用者初次向支援中心求助時，他們的來電或信件通常會直接轉給第 1 級支援技術人員。] • 第 1 級支援一般是一種入門級的職位，初級技術人員可利用該工作積累寶貴經驗。 • 第 1 級技術人員的工作和職責包括： • 診斷基本的網路連線問題 • 診斷並記錄硬體、軟體和系統問題的症狀 • 解決並記錄任何基本的使用者問題 • 幫助要購買各種系統、服務、硬體、軟體、報告和授權的客戶完成線上訂購表單 • 將自己無法解決的問題呈報給上一級

12. 2.1.2 ISP技術人員的角色 • 許多客戶問題都可透過第 1 級支援技術人員得到解決。 • 第 2 級支援所配備的人員通常數量較少，但專業水準較高。 • 第 2 級技術人員的工作和職責與第 1 級的類似 • 但需要解決的問題比一般的使用者問題更為複雜，需要更強的解決問題的能力。 • 較小的 ISP 和企業將第 1 級和第 2 級支援合併為一級，這就要求所有技術人員都具有較高的技術水準。

13. 2.1.2 ISP技術人員的角色 • 許多較大的服務供應商拓寬了自己的業務範圍，開始為客戶網路提供代管服務或現場支援。 • 對於提供代管服務的 ISP，通常需要派遣技術人員到客戶所在地進行安裝工作或提供支援服務。這也就是第 3 級支援。 • 現場安裝和支援技術人員的工作和職責包括： • 診斷並解決由第 1 級和第 2 級技術人員呈報的問題 • 針對較複雜的問題調查網路情況，以供高級網路技術人員分析 • 根據需要安裝和設定新設備，包括用戶端設備升級。 • 第 3 級支援通常是根據 SLA（服務等級協定, Service Level Agreement ）進行的。 • SLA 類似於保險單，其中規定了在電腦或網路發生故障時 ISP 的責任範圍或服務範圍。

15. 2.1.3 與客戶溝通 • 支援中心技術人員可能需要提供電話支援、電子郵件支援、基於 Web 的支援、線上聊天支援以及現場支援。 • 在問題解決之前，支援中心技術人員會不斷地接到客戶的電話和信件，詢問進展情況和所需時間。 • 必須能在易受干擾的環境中保持專注，而且要能準確有效地同時執行多項工作。 • 需具有出色的人際交往技巧和溝通技巧，無論是口頭還是書面。他們既需具備獨立工作的能力，還需具備團隊合作的精神。 • 必須能夠以專業的方式快速、有效地處理客戶問題。 • 支援中心技術人員接到客戶來電並開始排查問題時，必須按照基本的事件管理程序來處理。 • 事件管理包含諸如填寫問題追蹤單、遵循問題解決政策之類的工作。 • 問題解決技巧則包括使用故障排除流程圖、以模式化方式分析問題以及維護適當的問題追蹤單呈報程序等。

17. 2.1.3 與客戶溝通 • 除了技術能力外，支援中心技術人員還需具備其他技能才能勝任工作 • 遇到比較難對付的客戶和事件時，客戶服務和人際交往技能非常重要 • 維持一種專業、禮貌的態度，直到客戶的問題得到解決或將問題呈報給上一級為止。 • 緩解客戶的情緒，對出言不遜的客戶作出回應，必備的一些技能包括： • 準備 • 禮貌的問候 • 開啟問題追蹤單 • 聆聽客戶陳述 • 配合客戶的情緒 • 正確診斷簡單的問題 • 記錄來電

18. 2.1.3 與客戶溝通 • 開啟問題追蹤單並記錄資訊非常關鍵。 • 如果有許多來電都是與同一個問題或症狀有關的，那麼之前如何解決該問題的有關資訊將起到很好的幫助作用。 • 將正在執行的一些解決問題的作業告知客戶也非常重要。 • 問題追蹤單上的資訊記錄得當，可有效促進技術人員與客戶以及其他 ISP 人員之間的準確溝通。

20. 2.2.1 使用OSI模型 • 支援中心收到網路連線問題報告時，可透過多種方法診斷問題 • 較常用的是利用分層方法來排除故障。 • 要使用分層式方法，網路技術人員必須熟悉其原理，瞭解網路中的網路裝置和主機如何建立、傳遞和解譯訊息。 • 資料在網路上的傳輸過程具有高度結構化的特點。 • OSI 模型（開放式系統互連模型）的七個層次清晰直觀地闡釋了這一點。 • OSI 模型將網路通訊細分為多個程序，每個程序都是大型工作的一個組成部份。

21. 2.2.1 使用OSI模型

22. 2.2.1 使用OSI模型 • OSI 模型的七個層次可分為兩個部份：上層和下層(pper layers and lower layers)。 • 有時使用「上層」來指代任何位於 OSI 模型傳輸層以上的層。OSI 模型的上層處理應用程式功能，一般僅在軟體中實作。 • 最高的一層也是最接近使用者的一層為應用層 。 • OSI 模型的下層處理資料傳輸功能。 • 實體層和資料鏈結層透過硬體和軟體實作。 • 實體層最靠近實體網路媒體（即網路佈線），將資訊交給媒體傳輸。 • 終端電腦(例如用戶端電腦和伺服器)通常會用到所有七個層次 • 網路裝置則只關心下層。 • 集線器工作在第 1 層上，交換器位於第 1 和第 2 層，路由器位於第 1 至第 3 層，防火牆則涉及第1、2、3、4 層。

24. 2.2.2 OSI模型協定和技術 • 使用 OSI 模型排除故障時，必須瞭解每一層執行的功能，以及瞭解執行這些功能的裝置和軟體程式涉及的網路資訊。 • 以電子郵件為例，郵件從用戶端成功傳送到伺服器的過程便涉及多個環節。 • 步驟 1：上層生成資料。 • 使用者傳送電子郵件時，郵件中的英數字元需要轉換為能夠在網路上傳輸的資料。 • 第 7、第 6 和第 5 層負責確保郵件的格式能夠為目的主機上執行的應用程式所理解，此過程稱為編碼。然後，上層將編碼後的郵件傳送給下層，並透過網路將郵件傳送出去。 • 電子郵件能否傳送到正確的伺服器取決於使用者提供的設定資訊，在應用層出現的故障通常是因為使用者軟體程式設定錯誤而引起。

26. 2.2.2 OSI模型協定和技術 • 步驟 2：第 4 層封裝資料以進行端對端傳輸(end-to-end transport.)。 • 構成電子郵件訊息的資料在第 4 層被封裝後供網路傳輸。 • 第 4 層將郵件劃分為較小的資料段(segments) • 每個資料段都新增一個標頭，指示與正確應用層應用程式對應的 TCP 或 UDP 連接埠號。 • 傳輸層中的功能指示傳送服務的類型。 • 電子郵件採用 TCP 資料段，因而目的主機會對收到的封包加以確認。 • 第 4 層的功能由來源主機和目的主機上執行的軟體執行。 • 防火牆通常使用 TCP 和 UDP 連接埠號來過濾流量。 • 發生在第 4 層上的問題可能是由於防火牆過濾清單設定錯誤所導致的。

27. 2.2.2 OSI模型協定和技術 • 步驟 3：第 3 層新增網路 IP 位址資訊。 • 從傳輸層收到的電子郵件資料會被放入封包中，封包(packet)的標頭包含來源和目的地邏輯 IP 位址。 • 路由器按照目的位址，沿著正確的路徑將封包透過網路傳送出去。 • 如果來源或目的地系統上的 IP 位址資訊設定錯誤，則可能導致第 3 層上發生故障。 • 由於路由器也會用到 IP 位址資訊，因此路由器設定錯誤也會導致這一層發生故障。

29. 2.2.2 OSI模型協定和技術 • 步驟 4：第 2 層新增資料鏈結層標頭和標尾(header and trailer)。 • 從來源裝置到目的裝置的路徑中，每台網路裝置（包括傳送端主機）都會將封包封裝為訊框(frame)。 • 訊框包含鏈路中下一台直接相連網路裝置的實體位址。 • 選定網路路徑中的每台裝置都需要使用訊框來連接到下一台裝置。 • 交換器和網路介面卡 (NIC) 借助訊框中的資訊將訊息傳送到正確的目的裝置。 • 網路介面卡驅動程式錯誤、介面卡本身的故障或交換器的硬體故障都可導致第 2 層出錯。

30. 2.2.2 OSI模型協定和技術 • 步驟 5：第 1 層將資料轉換為可以傳輸的位元。 • 為了在媒體上傳輸，訊框被轉換為只包含 1 和 0 的位元流。 • 在這些位元資料沿著媒體傳輸時，裝置透過時脈功能來進行區分。 • 來源裝置與目的裝置之間可能包括多種類型的傳輸媒體。 • 例如，電子郵件可能來自乙太網路 LAN，然後穿過光纖校園主幹和序列 WAN 鏈路，最後到達另一個遠端乙太網路 LAN 上的目的地。 • 導致第 1 層故障的原因包括：電纜鬆脫、電纜類型錯誤、介面卡故障或電子干擾等。 • 在接收端主機處，步驟 1 至 5 的過程與上述過程剛好相反，因為訊息是從下層開始逐層向上傳輸，最後抵達適當的應用程式。

32. 2.2.3 使用OSI模型排除故障 • 作為一種理論模型，OSI 模型定義了在七個層上工作的通訊協定、硬體和其他規範。 • 此外，OSI 模型也為排除網路故障提供了系統化基礎。 • 無論排除哪種故障，其基本的故障解決程序都包括以下方面： • 1. 確定問題 • 2. 鑑別出問題原因 • 3. 解決問題 • 確定候選的解決方案及其優先順序 • 選擇一個解決方案 • 實作解決方案 • 評估解決方案

33. 2.2.3 使用OSI模型排除故障 • 如果實作的方案無法解決問題，則復原所有變更，並嘗試使用其他解決方案。重複上述操作，直到將問題解決。 • 除了基本的問題解決程序外，OSI 模型還可用作排除故障時的指導原則。 • 在任何故障排除情況中，最好都從最簡單的事項入手。有了 OSI 模型，支援中心技術人員在向客戶提問時便有了依據，可以更快地確定問題並找出原因。

34. 2.2.3 使用OSI模型排除故障 • 3 種不同的故障排除方法： • 自下而上(Bottom-Up Approach)： • 自下而上法在排除網路故障時從網路的實體元件開始，沿著 OSI 模型向上檢驗。 • 自下而上的故障排除方法非常適用於問題極有可能出現在實體層的情況。 • 自上而下(Top-Down Approach)： • 利用自上而下法排除網路故障時，先從使用者應用程式開始，沿著 OSI 模型向下檢驗各層。 • 自上而下方式是比較常用的方法，一般只會對一個或少數幾個使用者造成影響。這是因為下面的層（網路架構）往往會對較多的使用者造成影響。

35. 2.2.3 使用OSI模型排除故障 • 各個擊破法(Divide-and-Conquer)： • 採用各個擊破法時，人們會選擇某一層來測試其健康程度； • 根據觀測到的結果，再確定從起始層開始向上或向下檢驗。 • 如果該層工作情況正常，則應檢驗其上的層。 • 如果該層工作情況異常，則應檢驗其下的層。最終選擇作為首個排除故障物件的層應具備以下特點：該層工作異常，而其下各層則工作正常

37. 2.2.3 使用OSI模型排除故障 • 支援中心技術人員通常有一份標準的檢查清單或操作規程，在排除故障時他們便會遵照其上的內容進行操作。 • 從最低層開始往上排查，稱為自下而上法。 • 第 1 層故障排除：第 1 層負責處理網路裝置的實體連線 • 第 1 層故障通常涉及佈線和電源問題，而這兩者也正是造成大量支援中心來電的原因。 • 比較常見的第 1 層故障包括： • 裝置電源未開啟 • 裝置電源未接通 • 網路電纜鬆脫 • 纜線類型錯誤 • 網路纜線故障

38. 2.2.3 使用OSI模型排除故障 • 要排除第 1 層的故障，請檢查所有裝置的供電是否正常，裝置是否開啟。 • 如果有顯示連接狀態的 LED 指示燈，請客戶確認這些燈的顯示是否正常。 • 如果技術人員位於客戶現場，則下一步是目視檢查網路佈線並重新連接電纜，確保其正常連接。 • 如果是遠端排除故障，則指導來電者執行每個步驟，告訴他們每項操作的目的，以及找到錯誤後應該如何處理。 • 如果所有第 1 層的問題都已檢查完畢，則可沿 OSI 模型向上進入第 2 層。

39. 2.2.3 使用OSI模型排除故障 • 第 2 層故障排除： • 網路交換器和主機網路介面卡執行第 2 層的功能。 • 造成第 2 層故障的原因包括設備故障、裝置驅動程式錯誤以及交換器設定錯誤等。 • 如果是遠端排除故障，則較難確診第 2 層的故障。 • 現場技術人員可以檢查網路介面卡的安裝及運作是否正常。 • 重新安裝網路介面卡，或者用正常的網路介面卡取代懷疑有故障的網路介面卡可幫助診斷問題。 • 此方法也適用於任意類型的網路交換器。

40. 2.2.3 使用OSI模型排除故障 • 第 3 層故障排除： • 在第 3 層，技術人員需要調查網路中使用的邏輯定址，例如 IP 位址方案。如果網路使用 IP 定址，技術人員便需要確認裝置的設定是否正確，例如： • IP 位址屬於所指定的網路 • 子網路遮罩正確 • 預設閘道正確 • 其他設定符合要求，如 DHCP 或 DNS • 在第 3 層，可利用許多公用程式來協助進行故障排除。 • 三種最常用的命令列工具是： • ipconfig － 顯示電腦上的 IP 設定 • ping － 測試基本網路連線 • traceroute － 確定來源與目的地之間的路由路徑是否可用 • 大多數網路問題可透過上述第 1、2 和第 3 層的故障排除得到解決。

43. 2.2.3 使用OSI模型排除故障 • 第 4 層故障排除： • 如果第 1 至 3 層看上去都執行正常，而且技術人員能成功 ping 通遠端伺服器的 IP 位址，則需要檢驗更高的層次。 • 例如，如果沿途有網路防火牆，則需要檢查應用程式的 TCP 或 UDP 連接埠是否開啟，確保沒有任何過濾清單在封鎖流經該連接埠的流量。 • 第 5 層至第 7 層故障排除 • 技術人員還應檢查應用程式設定。 • 例如，排除電子郵件故障時，需確保為應用程式設定的傳送和接收電子郵件伺服器資訊正確無誤。 • 此外，還需確保網域名稱解析服務運作正常。

45. 2.2.3 使用OSI模型排除故障 • 對於遠端技術人員，較高層次的問題可透過其他網路實用工具來檢查，例如可使用封包監聽器來檢視網路上的流量。 • 另外，也可使用 Telnet 之類的網路應用程式來檢視設定。 • 儘管自下而上的方法適用於許多情況，但也可選擇性的選擇使用自上而下的方法。 • 自上而下的方法只是逆轉了檢查順序，從應用層著手檢查。 • 另外，還可以使用各個擊破法。 • 在此方法中，技術人員可選擇從中間層（例如網路層）開始故障排除過程，然後沿著 OSI 模型向上或向下檢驗，具體取決於目前層的故障診斷結果。

47. 2.3.1 支援中心故障排除場景 • 支援中心接聽的來電不但數量多，而且類型繁多。一些最常見的來電問題通常是關於電子郵件和連接的問題。 • 電子郵件問題 • 能接收但不能傳送 • 能傳送但不能接收 • 不能傳送或接收 • 任何人都無法回覆郵件 • 導致許多電子郵件問題的一個極為常見的原因是所設定的 POP、IMAP 或 SMTP 伺服器名稱有誤。最好諮詢電子郵件管理者，瞭解電子郵件伺服器和 SMTP 伺服器的正確名稱。 • 在某些情況下，POP/IMAP 和 SMTP 使用相同的伺服器名稱。此外，還需確保使用者名稱和密碼正確無誤。

48. 2.3.1 支援中心故障排除場景 • 透過電話解決這些問題時，務必耐性細心地指導客戶檢查這些設定參數。 • 許多客戶既不熟悉術語，也不瞭解各種設定參數的值。如有可能，最好透過遠端管理軟體登入到客戶的裝置。 • 可能影響應用程式運作的另一個原因是 DNS 故障，因而無法正確解析伺服器名稱。 • 這可透過命令 ping 或 nslookup 來檢查。 • 透過簡單的 Web 瀏覽器操作來檢查 DNS 執行情況可避免一些不必要的操作。

49. 2.3.1 支援中心故障排除場景 • 客戶連線問題 • 新客戶通常是硬體和軟體設定存在問題。 • 老客戶一般是在無法開啟網頁或者無法連接即時訊息或電子郵件時，才發現自己存在連接問題。 • 引起連接問題的原因有很多，包括： • 計費帳戶問題 • 硬體故障 • 實體層故障 • 應用程式設定 • 應用程式缺少外掛程式 • 缺少應用程式 • 在許多情況下，問題是由於電纜故障，或者電纜插入了錯誤的連接埠造成。其他故障則需要搜尋 FAQ 或知識庫中的類似問題來尋求解決方法。

50. 2.3.1 支援中心故障排除場景 • Packet Tracer 練習2.3.1.3 • 排除並解決網路連線問題。