1. 你認為配置基線的核心是什麼(講述至少兩個點)
需求基線 設計基線 測試基線 發布基線需求基線在需求分析規格說明書通過同行評審後建立，此時客戶需求和產品需求應該是全面、清晰、准確並且文檔化的。
2. 管理員應在什麼時候建立網路基線
建立網路基線，前期准備工作包括以下幾個部份：
1) 網路拓撲結構圖：在結構圖里，要力求完整展示網路的物理結構，詳細標識出網路中路由器、交換機、防火牆、伺服器類型、管理設備的位置；甚至數據流向等；
2) 了解網路現有的管理策略，網路配置情況，對哪些服務、訪問做了優化和管理；
3) 掌握確定網路的繁忙時段、業務高峰時段、空閑時段等；
4) 將上述3點形成翔實的文檔。 確定范圍和目標 建立網路基線最重要的就是要確定基線的范圍和目標（基線參數）。網路是復雜的，我們不可能也很難將所有設備、主機或鏈路的信息全部加入到基線里來，這就需要管理者按其重要程度對網路進行劃分，然後確定建立基線的范圍； 而且不同的設備、主機或鏈路所關注的參數也不盡相同，比如伺服器更多的是關注安全和性能，網路則是流量、利用率等，這些都需要管理員在錄入基線數據之前就確定好。
3. 阿里雲基線要怎麼配置啊
打包配置有兩種類型，一種是總的配置，作為基線模版。一種是每個熱修復發布單中的配置項，成為單項配置。單項配置根據基線模版生成，單項配置可參考以下說明。
dexpatch 配置說明
代碼庫地址： 構建整包時主工程的git代碼庫地址
分支： 構建整包時的代碼分支
打包腳本：後台伺服器上運行的構建腳本
參考來源：網頁鏈接
4. H3C ER3100 路由器配置基線怎麼弄
這個主要是對網路安全方面的配置。如果啟用了網路安全，就需要配置安全基線，這個對於不同的攻擊其設置都是不同的。大概有19種安全基線，如果不知道具體情況，可以選默認參數，這個可以滿足大多數情況要求。如果安全問題不大，建議你關閉安全模式，因為這種模式影響路由器速率。
5. 基線（配置管理）
基線」是一個很常見的術語，在配置管理和項目管理裡面都能看到，而且還有很多衍生的術語，例如基線提升、基線化、基線審計，等等等等。 我個人以前對微軟的那套開發流程（就是proct cycle model）以及PSP、TSP了解比較多一些，這些流程裡面對「基線」的概念提的不多。但接觸RUP、MSF以及項目管理以後，看到到處都有baseline，就覺得迷惑了。 經過我自己的理解，以及和幾個同事的討論，現在我覺得我們通常看到的「基線」這個術語有兩個意思： 1）代表多個源代碼文件的一組版本。 比如有三個文件，aaa.c、bbb.c和ccc.h。可以對這三個文件做一個基線，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一個基線。換句話說，通常在vss和cvs裡面做label，就是在做基線。 這種基線對「構建審計」特別有用：在做build的時候，可以先對所有源文件做一個label，取名為"Build2394"，然後再編譯、集成。這樣，以後如果要找到和build 2394對應的原文件，只需要到vss或者cvs裡面把所有文件對應label Build2394的版本取回來就可以了。 2）代表文檔的一個穩定狀態。 比如有一個項目設計文檔，當設計基本完成，開發即將開始的時候，需要把這個文檔固定下來，內容不能再頻繁改變，否則開發人員就無所適從了，可能導致每個人所參照的文檔並不是同一個文檔。用一句上海這里的生活用語來說，就叫做要把這個文檔「敲定」。 一個文檔如果經過討論被通過了，被固定了，就可以說這個文檔被「基線化」了，然後所有人就可以在這個「基線」的基礎上工作。 當然，文檔不可能一成不變，所以當對文檔的修改仍然會不斷進行，但這種修改並不會隨時隨地的添加到被「基線化」了的文檔中去。因為既然是「基線」，就不能隨便動。 但是到了一定時候，修改積累到一定程度，就需要把很多修改合並到原來的文檔中去了，並生成一個新版本的文檔作為團隊中所有的人的參考標准，並把老的版本淘汰掉。這就叫做「基線提升」。 以上就是我個人對「基線」這個術語的兩種不同含義的理解，大家可以討論討論看，是不是差不多就是這個意思。