帶你一窺網管員日常聊天實錄：信息編碼之“你說我說”

文/陶春

帶你一窺網管員日常聊天實錄：信息編碼之“你說我說”

文/陶春

網上有網友發帖問：“做校園網絡管理員，需要具備哪些專業知識？”網友答：“了解TCP/IP協議，懂得局域網環境管理,熟練掌握路由器操作技術，懂得ARP防御等。”在許多人的印象中，高校網管員的工作和安全、維修維護，聯系到一起，認為是一個清閑的工作，只要機器不壞，沒機器要維修，就是一杯茶到下班的節奏。然而，在小編和某高校網管主任聊天后發現，用“累成狗”形容毫不夸張，該主任的原話是這樣的，“我們每更新一個東西、錄入數據需要協調的是多個部門，任何時候哪個部門出現網絡問題，我們都得去現場解決問題，加班是家常便飯，怕苦怕煩的干不了我們這一行。”

那么，退一萬步，理想的假設，如果機器、網絡很給力，不經常壞的情況下，網管員們是不是很空閑呢？好奇的小編以“狗仔隊”的責任心，進入網管員們的聊天群。結果，發現他們幾乎沒有張家長李家短的閑碎話題，倒不是他們不懂情趣，而是他們忙得沒有時間去討論網管以外的話題。每天需要應接不暇地面對各種網管中碰到的棘手且需馬上解決的狀況，而每個網管員技術再高超也不是萬能的，所以，誰碰到難題就在群里第一時間提問，大家群策群力地互助，小編將其取名為“網管員互助抱抱團”。比如，信息系統建設的編碼、整理學校的學生和老師編號是一件麻煩的事情。一起看看高手們湊到一起，有什么好辦法應對。

編碼的痛點，你懂嗎？

提問一

我們學校現在正在做數據標準，大家的本科生學號和研究生學號都是怎么編的啊？

回答

方法一：你可以協調好本科和研究生，統一編或者分開編。我們沒協調好，所以分開編。

方法二：我覺得統一編比較好，能區分出來。但是，難題是，學號里邊加不加學院代碼？加了更詳細，可是以后要是轉專業很麻煩，比如，學院就對不上了。但是，不加則看不出學生管理歸口。

方法三：統一編。學號可以不變，代碼不能解決所有問題，編碼起到唯一性好了，對于變不變可以自行考慮，也可以在其他字段體現。至于編碼的處理，以年份加順序號最好，最多加個學歷層次。

方法四：具體如圖1所示。

方法五：我們準備簡單點，年份2位，身份2位，4位流水。主要今年本科生按流水排了，所以其他的隨大流了。換一句話，我們的原則是，怎么變都是要惟一性。惟一性保障好了，幾位都一樣。

對此，大多數老師們評論，支持年份四位的方法。

圖1

爭議：對于方法四的方法，大家的觀點不一。

“碩士分得太細了哇。”

“教職工不轉崗啊？”

“教師也這么編？”

“如果以前有這個的話，對應其他會花費一些

工作量的。要考慮歷史遺留問題。”

提問二

關于編碼，全國教育信息化有沒有指導性的方法？

回答

回答：具體如圖2所示。

圖2

提問三

編碼統一還是不統一呢？

回答

支持統一型

“學校不同部門，如果亂

編，一會兒字母，一會兒數字的，看著鬧心，你就統一吧。”

認為統一困難型

“現在是好幾個部門協調的問題，讓教務處改教務系統那很難啊。”

“統一不統一，你說了不算。如果學生4年后畢業就走了，那就都好了，如果學生4年后考上本校的研究生，不與檔案沖突即可。”

身份字段的痛點，你懂嗎？

提問一

統一編碼的時候，用不用身份的分類編碼？

回答

支持簡單編碼型

“我們編碼的時候，年份

+類別+流水號，類別是指高職、本科、研究生。教工的類別太細了有麻煩，萬一他轉崗了，這個號就要變，不符合統一編碼的原則了。我們教工比較簡單，每個教工8位編號。前四位入職年份，后4位流水順序號。沒有必要帶什么部門院系之類的編碼。流水號最好。”

“我們編碼方式和你們的基本相似，因為流動比較頻繁。身份，其實我認為也沒有必要，因為身份可能會發生變化。編號一旦確定，終身不變。”

“我們的編碼8位，前兩位身份，3-4位年份，后四位流水。有變化的就用流水號吧。”

“如果覺得編碼不方便，可以通過附加屬性來區分呢。”

質疑編碼型

“我們以前設計的時候也考慮過身份，后來想想還是算了，一個工號，沒有必要把人分成幾類，萬一別人身份發生變化，你又不能改，別人還不高興。”

“兩位年份的話還是有些問題，最明顯的就是下一個千禧年問題。”

“我們現在適用的編號就有身份字段，后來就牽涉到人員身份變化，我們說不修改，但人家不愿意，很難弄。”“確實，會得罪人。有的人很在意這個的。”

提問二

有沒有完整的信息化代碼規范可以提供？

回答

方法一：“大家登錄業務系統統一到門戶。認證系統有多個——SSO、LDAP、RADIUS、MAIL，每個子系統，可以選擇性地接入某一認證系統，在賬號系統（ID）中修改密碼時，可選擇寫入到哪個認證系統。修改密碼可以只修改MAIL的，也可以修改除MAIL外所有的。”

“對于用哪個統一認證系統的話題，畢竟不是所有系統都能做集成修改，只能通過某種方式，將密碼刷進去。這東西只能自己建。LDAP 稍大點的系統都認，如果你等開發商來建就是很被動的。現在我們的LDAP用于門戶，郵件云盤敏感的類型還是獨立密碼。統一身份認證的帳號與業務系統的帳號只是一個對應關系，直接通過SSO接入。如果用戶名相同的系統，那直接通過業務系統提供的單點入口SSO登錄系統。如果用戶名不同的系統，通過用戶對照表映射后單點登錄業務系統。”

“業務系統也可以通過LDAP、WebService等，調用統一身份進行用戶認證，所以分不同系統用不同的方案。業務系統可保留自己的登錄入口。IDMS是一個專門管賬號的系統，在其上修改密碼后，可以選擇性地將密碼信息寫入到外圍認證系統。用LDAP多次發生宕機，門戶進就了就算了，如果郵件和云盤進不了，會很麻煩呢。SSO，這最省事，有錢就短信二次驗證。所以郵件和云盤使用中繼LDAP,不是實時去LDAP認證。這樣需要一個統一身份與郵件地址的用戶映射表。”

方法二：“不一定非要集中登錄嘛，可以由各系統繼續分管帳號，但是只由IDMS去寫入。IDMS去寫入也是一種方案。確保各系統的開戶、修改密碼功能僅對IDMS開放就是了。用戶只能在IDMS去操作密碼，看上去就像是統一認證了。”

方法三：“統一身份認證表的密碼改了自動更新教務用戶表，因為剛好是相同的MD5加密方式。”

方法四：“采用城市熱點的方案，直接把密碼刷到RAIDUS設備里，用戶登錄成功后把密碼同步到SAM中。”

方法五：“直接用雙因子認證，雙因子是指的密碼和設備，設備是指的手機、ipad、用戶私有設備，還有令牌、key等等。銀行的U盾、key等等就是雙因子認證。如果認為應用系統不支持的時候，用手機來做而增加工作量，可以開發個學校的密保中心的APP。或者密碼＋手機app ，當然，開發成本高。這個校方的保密中心的功能可以考慮做到微信公眾號里。從價格來講的話，密碼+郵件，成本低，但是不方便。密碼＋手機動態密碼認證，需要一個短信貓池。另外，MTA成本低。”

（以上內容根據“高校校園網絡交流”QQ群整理）