Over the years, network operations have relied on direct human interaction with network devices. Commonly using text editors, network engineers build one device configuration at a time. Engineers may copy an existing configuration into a file and search their way through updating it for each new device. Once this archaic method of building configurations is complete, network engineers connect to devices using either the console, Telnet, or SSH, to copy and paste the configurations onto the devices.
多年來，網路維運一直仰賴人員直接與網路裝置互動。網路工程師通常使用文字編輯器，一次建立一台裝置的設定。工程師可能會將現有設定複製到檔案中，再逐一搜尋修改以套用到每台新裝置。完成這種老舊的設定建立方式後，網路工程師會透過主控台、Telnet 或 SSH 連線至裝置，將設定複製貼上到裝置上。
This process poses several problems when working with networks of any shape and size. As you look back at how networks have been managed, consider the following:
無論網路規模與型態為何，這種流程都會帶來一些問題。回顧網路過去的管理方式，請思考以下幾點：
- First, the CLI was designed for human interaction and limits the speed of configuration to the speed at which the user can work.首先，CLI 是為人機互動而設計，設定速度受限於使用者的操作速度。
- Second, manual configuration and common copying and pasting methods are extremely prone to error, especially when configuring multiple devices.其次，手動設定與常見的複製貼上方式極易出錯，尤其是在設定多台裝置時。
- Third, tasks are not easily repeatable and result in suboptimal workflows.第三，工作不易重複執行，導致工作流程效率不佳。
In the late 1980s, the industry developed an interface that was built for machine-to-machine communications to manage and monitor large networks in a standardized fashion. It was called the Simple Network Management Protocol (SNMP). Instead of an engineer connecting to each device and obtaining necessary information, a server, part of a network management system (NMS), performed this function through SNMP polling. The interface had another benefit: if something went wrong or an event occurred, the device notified the server using SNMP traps. Although SNMP can also configure devices to a certain degree, it is rarely used in that manner in production. SNMP has its issues as well, but it was a move in the right direction.
1980 年代末，業界開發出一種以標準化方式管理與監控大型網路的介面，專為機器對機器通訊而設計，稱為簡易網路管理協定（Simple Network Management Protocol，SNMP）。伺服器（屬於網路管理系統，NMS，的一部分）透過 SNMP 輪詢執行這項功能，而不需工程師逐一連線裝置取得所需資訊。這種介面還有另一項優點：若發生問題或事件，裝置會使用 SNMP trap 通知伺服器。雖然 SNMP 在某種程度上也能設定裝置，但在正式環境中很少這樣使用。SNMP 本身也有其問題，但它是朝正確方向邁出的一步。
Although SNMP has different properties, it is best known and used today to simply poll network devices for operational statuses such as interface up, interface down, memory utilization, CPU utilization, bandwidth utilization, and many other basic properties.
雖然 SNMP 具有多種特性，但如今最廣為人知且最常用的用途，是單純輪詢網路裝置以取得作業狀態，例如介面啟用、介面停用、記憶體使用率、CPU 使用率、頻寬使用率等許多基本屬性。
Scaling Network Management
擴展網路管理規模
With the CLI and SNMP as the dominant methods of network management, here is an example of how teams typically would scale: What do they do and how do they operate as the network continues to evolve? Even if networks are not expanding based on the number of routers and switches, in the past several years, additional devices and services have been increasing the size and complexity of the network: security, wireless, network fabric controllers, network overlays, and IPv6, to list just a few.
在 CLI 與 SNMP 作為主要網路管理方式的情況下，以下說明團隊通常如何擴展規模：隨著網路持續演進，他們該怎麼做、又是如何運作的？即使網路在路由器與交換器數量上並未擴張，過去幾年間，額外的裝置與服務也持續增加網路的規模與複雜度：安全性、無線、網路架構控制器、網路覆蓋層與 IPv6，僅是其中幾例。
Imagine a company that has a small network with only a few network engineers. They can easily manage all nodes by just using CLI access. Over the course of a few years, the company has some growth and experiences more challenges in network operations. Now the network has more devices, which require more staff to support them. As the network scales, the major response historically has been to hire more network engineers.
設想一間擁有小型網路、只有幾位網路工程師的公司。他們僅靠 CLI 存取即可輕鬆管理所有節點。經過幾年成長後，公司在網路維運上面臨更多挑戰。此時網路擁有更多裝置，需要更多人力來支援。隨著網路規模擴大，過去業界的主要因應方式一直是聘用更多網路工程師。
Although using the CLI should not be justifiable anymore, it has been the customary approach in the industry. However, there is a benefit of hiring more engineers—it creates skill-set diversity, which further highlights the issue. One new engineer might learn Python and another one learns Ansible. Although both of these tools help manage many devices at the same time, they also offer the ability to standardize and reduce human error. Each of these engineers improved their performance individually.
雖然如今使用 CLI 已不再合理，但這一直是業界慣用的做法。不過，聘用更多工程師也有好處，那就是帶來技能多樣性，這也進一步凸顯了問題所在。可能有位新進工程師學習 Python，另一位則學習 Ansible。雖然這兩種工具都能協助同時管理多台裝置，也能提供標準化並減少人為錯誤的能力，但每位工程師都是各自提升了自己的表現。
As time continues to go by, the network continues to expand and configurations are gradually added, which makes manual configuration management more difficult. Although it is more difficult to manage manually, each team member continues to do what they think is right for network automation. Some engineers use their own databases, some use Bash scripts, some use Perl scripts, some execute scripts from a server and store them in a git repository.
隨著時間過去，網路持續擴張，設定也逐漸增加，使得手動設定管理愈發困難。儘管手動管理日益困難，每位團隊成員仍持續採用他們自認為正確的方式進行網路自動化。有些工程師使用自己的資料庫，有些使用 Bash 腳本，有些使用 Perl 腳本，有些則從伺服器執行腳本並儲存在 git 儲存庫中。
Although this is common, it does not benefit the network engineers and business. These tools are more than capable of managing the network, but there is no overall automation strategy. This mode of operation shows the value of automation and allows for some learned skills, but it should only be executed as a proof of concept (POC). Automating in production requires proper controls as part of a cohesive network management strategy.
雖然這種情況很常見，但對網路工程師和企業並無益處。這些工具完全有能力管理網路，但缺乏整體的自動化策略。這種運作模式雖能展現自動化的價值並累積一些學到的技能，但只應作為概念驗證（proof of concept，POC）來執行。要在正式環境中實施自動化，需要有適當的控管機制，並納入一套完整的網路管理策略之中。