起因:公司一生產裝置需要通過電腦作業,電腦和裝置之間通過串列埠或其它介面連線,並通過特定的軟體使用.
一般來說,這種特定生產裝置的安裝設定及維護會由專業廠商提供服務,但為節省費用這件事情就落到it的身上.
it為了能保證更好的完成服務,節省時間,減少出錯.提出由使用單位協助提供所有此類裝置現在所用的連線卡驅動/埠&裝置的連線順序以及軟體版本.
現在問題出來,該部門主管認為 如果手下的員工能提供以上資訊的話,那就不會在本公司了,早就去更好的公司了...
自這位主管的表達,我們能看到以下幾點隱藏的訊息:
1.我們公司很爛,有點技能的都去其它公司了.
2.能搞定這些的it人員應該早就去更好的公司了
進而可以推斷出,現在還在這個公司的都是些平庸的人,it都是sb,能去更好的公司還不去.
it作為服務單位,it配合生產單位,那是必須配合的,不管是否合理.
當it需要其它
單位配合時,那是能推就推的,更不用管是否合理.
出現上面這種認識差異的根源在哪裡?如何才能改變冏境是每個it主管應該考慮的問題.
根源就是it的服務價值不清,將it獨立出來作為乙個營收單位或許是個不錯的方法.
管理伺服器和受管伺服器
1.首先根據主機的相同與不同，上面的ip位址一樣就可以啟動管理伺服器好之後啟動受管伺服器連線即使主機不同，但是ip相同會自動間隔10秒去連線。有個檔案代表設定10秒自動連線ip位址 2.如果不同主機不同ip，如果是在windows，先啟動管理伺服器再啟動受管伺服器 在windows上建立乙個base...
受保護的Hyper V環境和受保護的虛擬機器
無論是企業內部還是託管在idc或雲服務商的虛擬機器，如何保障執行的環境是安全的，虛擬機器是安全的 虛擬機器檔案裡的資料以及看到的監視器畫面 成為此篇文章和大家 研究的。比如您正在執行的虛擬機器，管理員是可以通過虛擬化平台通過監視器看到您的系統並操作的，比如關機，開啟，重啟等等操作，其次如果有別有用心...
Kafka和mq的差異
其實，作為訊息佇列來說，企業中選擇mq的還是多數，因為像rabbit，rocket等mq中介軟體都屬於很成熟的產品，效能一般但可靠性較強，而kafka原本設計的初衷是日誌統計分析，現在基於大資料的背景下也可以做運營資料的分析統計，而redis的主要場景是記憶體資料庫，作為訊息佇列來說可靠性太差，而且...