關注嘉為科技，獲取運維新知
對大部分中大型的企業來說，cmdb建設對於整個it服務和it運維管理的重要性不言而喻，但是目前仍然有非常多的企業無法建設好cmdb。
我最近剛好接觸了乙個公安系統的朋友，他和我聊了關於身份證管理系統。聊完，我恍然大悟，這套思想和我們企業cmdb建設的思想幾乎一摸一樣。
只有被大量系統消費的資料才需要放到cmdb中。
在生命週期內不容易變化的資料，我們可以理解為「靜態」配置資料。
對比身份證管理系統：身份證上不會把我們個人的所有屬性放上去，比如年齡就是乙個狀態資料，而出生年月是乙個靜態資料。
配置自動發現功能對於cmdb的確重要，能有助於我們配置資料的初始化和配置資料的審計，但是我們不能依賴自動發現保障資料的準確性，更不能期望所有的屬性、關聯關係都通過自動發現來實現。
配置資料的準確性需要靠消費場景，只有通過消費場景，我們才能夠及時發現配置資料的錯誤；發現了配置資料的錯誤，我們才能夠及時對配置資料進行修正；這樣就會形成乙個正迴圈。
人員手工操作永遠是不可靠的，配置資料的準確性需要靠流程。只有靠流程和工具，才能保障配置資料的準確性。比如資源申請需要經過流程審批，資源完成交付後，工具可以將配置資料自動化註冊到cmdb中。
對比身份證管理系統：身份證管理系統目前並沒有線上自動化採集的功能，完全是依靠消費和流程保障資料的準確性。如你的身份不準確，你的駕照、社保系統都是無法使用的，甚至你入住酒店、乘坐高鐵都是不可以的；另外我們的國家制定了一套完整的身份證管理流程，包括身份證的建立、更新、過期等一整套生命週期管理流程，並且有公安局這個機構負責管理。
無論是以資源為中心的cmdb，或是以應用為中心的cmdb，都是從業務需求的角度出發，對ci物件以不同的形式進行組織，對ci和ci的關聯關係進行管理，ci的本質並沒有變。
過去，企業的應用架構大多是單體應用架構和分層應用架構，資源和應用之間的關聯關係並不複雜，一台物理伺服器可能就承載了乙個或多個應用。此時，我們採用以資源為中心的cmdb並不會給企業的運維管理帶來什麼影響。
但是，現在企業的應用架構發生了非常大的變化，分布式和微服務架構在企業中開始普及，應用和資源之間的關係變得複雜，目前更多的是乙個應用對應多個虛擬機器和容器的情形，並且應用關聯的虛擬機器和容器經常是變化的。此時，以應用為中心的cmdb建設就變得比較迫切。
對比身份證管理系統：在70年代，各省的身份證管理系統是以省為單位構建的，而且沒有實現全國聯網，公安局在追蹤人員資訊的時候經常只能獲取到人員的家庭資訊，很難獲取到人員準確的公司資訊。
到90年代後，身份證實行全國聯網，公司通過身份證為員工繳納社保和稅收。公安局通過身份證就可以追蹤到人員的公司資訊，實現更多的犯罪分析的場景。
因此，企業在建設cmdb的過程中，重心不是選擇什麼樣的cmdb工具，也不是規劃cmdb的模型及屬性。
重心是像我們的身份證管理系統一樣，先定義清cmdb在it運維管理和it流程管理中的角色和作用，定義清楚cmdb資料管理的負責人和流程，設計的其他運營工具要能夠消費cmdb資料，這樣cmdb就容易建設成功，並且很容易發揮價值。
cmdb本身不具備價值，只有產生消費，cmdb才發揮價值！
從身份證獲取年齡
8 輸入乙個身份證號碼 15位和18位 和乙個年份，計算現在的年齡 忽略非法引數 eg 610618199001020065 2011 輸出 21 package prctice01 8.輸入乙個身份證號碼 15位和18位 和乙個年份，計算現在的年齡 忽略非法引數 eg 61061819900102...
根據身份證判斷屬相 如何快速從身份證號中判斷性別？
我們有時候在整理人員資訊時，需要對人員做性別篩選，如果你現在手頭上的人員資訊有身份證號，但沒有性別資訊，可以根據身份證號快速提取人員性別資訊，特別是在人員數量較多的情況下，學會用公式篩選，1分鐘就能做完。在做篩選之前，我們要知道乙個常識，我們的身份證號一共是18位，第17位數的奇偶性就代表該員工的性...
C 開發身份證資訊管理系統之登陸
的實現 最上面using新增 using system.data.oledb namespace idmsg oledbconnection oledb new oledbconnection provider microsoft.jet.oledb.4.0 data source msg.mdb ...