Category: 主機

Posted on

辦公室和機房要整個搬遷，找我們去規劃機房

前幾天有個XX單位找我們聯絡，說辦公室和機房要整個搬遷，找我們去規劃機房、Wifi、Server，
問了一下，機房很小，三個機櫃，沒關係這簡單。
Server 要買什麼？沒概念，也不知道他們現在用的 Server 是什麼。
Wifi 需求很簡單，辦公室全區都要有訊號覆蓋。
.
看起來好像都很簡單？
.
錯了，到現場看他的 AutoCAD 圖(新址)，辦公室至少300坪，
Wifi AP 隨便抓都超過30 台，水平佈線是弱電廠商做的，
「那你 Wifi AP 後面還要佈有線喔」「這樣啊」
「水平佈線工程已經執行了嗎？」「不知道欸」
「有機會追加佈線嗎？」「要問問看欸」
「那你們裝修進場了嗎？還有機會埋管嗎？」「不知道欸」
「你有水平佈線的設計圖嗎？」「沒有欸」
「那你們什麼時候要搬家？」「1月」
.
.
.
那你完蛋了吧我想….
.
.
.
1月搬家，現在才找我們，資訊人員一問三不知，網路將來不是你們管的嗎？為什麼不從設計階段就插手管網路，而是等別人做爛了再丟給你管呢？
.
.
.
查了一下這個單位的組織架構圖，答案很清楚了，沒有資訊處，
資訊人員編制在行政或打雜部門下，難怪講話沒份量，執行沒權力，
搬家是總務處(or 祕書處)的事情，沒人在乎你資訊人員的專業，
網路和電話隨便發包給弱電做，設計圖也沒跟資訊人員討論過，
資訊人員收到的永遠都是過時和二手資料，等到總務不會做的時候(例如Wifi 不曉得怎麼買) 才想到要找資訊，
等到找資訊的時候都太遲了….
至於上面提到的 Server 和機房都是一樣的慘劇，就不多說了。
.
.
.
所以說很多時候資訊基礎建設會做得爛，從組織架構開始就有問題了，
至於資訊人員該做的事情呢？上面說過答案了，
「為什麼不從設計階段就插手管網路，而是等別人做爛了再丟給你管呢？」
.
.
.
所以我雞婆/機車不是沒原因的，因為我不想等到事情爛掉才叫我接手。

Posted on

桌電的M.2 SSD散熱，要注意M.2的位置

桌電的M.2 SSD散熱，已經買的早期M.2 SSD已經來不及了．未來要買要注意M.2的位置
文書機沒顯卡的沒關係.有顯卡的注意下列
不論桌機還是筆電，都要了解一下內置的配置位置．這樣電腦使用起來才容易達到高效能，省電，少故障．

例如 ASUS TUF-H310-PLUS-GAMING 這個M.2就是在處理器和顯示卡和記憶體中間，裸裝．如果處理器和顯示卡效能好一點．那m.2就容易過熱故障

例如微星MPG-Z490-GAMING-PLUS 雖然在同個位置.但他有內附散熱片,不過上述兩張板子價格差很多.建議還是自備散熱片
比較後來研發的位置就會改放置到顯示卡的另一邊

例如ASUS TUF-GAMING-B460M-PLUS 不再記憶體和處理器和顯示卡中間，同時具備散熱片
這樣就不容易發生m.2過熱故障

不論桌機還是筆電，都要了解一下內置的配置位置．這樣電腦使用起來才容易達到高效能，省電，少故障

Koji Yang
感謝分享說明，前些天自組了一台新電腦，首次使用了m.2 ssd，買了才發現技嘉的b550m-ds3h安裝位置也是在顯卡與cpu中間
當時也是有到底需不需要安裝散熱片的疑問，後面看網上資料表示還是安裝比較好

Posted on

中、小企業外購ERP，是上策。

大企業則通常相反。

例如：人壽保險、產物保險、鐵路局、航空公司、銀行、船公司、臺電、臺肥、臺積電、漢宇彩晶、美國天然氣公司National Grid、德國連鎖量販店Lidl、荷蘭汽車出租商Leaseplan、美國前第一大藥商FoxMeyer、美國前珠寶商Shane Co.、普利司通輪胎……務必由自己的IT人員開發自己的資訊系統。

如果硬要迷信外來「國際級」軟件商或「頂級」顧問，放棄自己的現有信息系統，購買「來自德國，全球最強的」DVD，硬套用在自己的大型企業的話，其通常下場是：

1、體質強的，長年在「高薪急徵MM、FI……模組顧問與人員」。

2、體質差的，直接倒閉。

3、斷尾求生，報廢DVD，回頭運轉自己開發的系統。———大企業必須自行從事資訊建設，而非外購或委託軟體商（或顧問）開發（或所謂的「輔導、導入」），

其理由是：

※ 無現成可用的ERP軟體。

※ 全世界最瞭解自己業務的人，是任職於該企業的職員，不是外來「無敵」軟體商導入團隊，不是外來「超級」顧問團。

※ 自己開發，無須交接，無縫永續維護、擴張。

Posted on

Telltale

蔡宗城

【#Monitoring】#Netflix 推出包山包海監測系統 #Telltale半夜被 On Call 電話叫了起床，心中雖然還在納悶到底是真的系統有問題，還是只需要調整一下監測的閥值，就在思考的過程中一邊查看訊息跟 Dashboard，時間也一分一秒正在消逝中，這應該是所有 On Call 工程師都有遇過的情況，太多的 Alert，太多的 Dashboard，太多要維護的服務；Netflix 內部的串流團隊需要一個可以快速分析和發現問題的監控系統，也就是說內部的 Node 團隊需要開發一個系統，讓一小群人可以透過它來駕馭一整個大系統，就在這樣的時空環境之下 Telltale 被開發了出來！Telltale 想要解決上面提到的問題，所以著重在於使用鮮明的顏色來讓人可以一眼看出有沒有問題發生，而且只顯示出最相關的上下游資訊，利用之前已經提過的眾多開源工具來幫忙 Telltale 有效地發揮作用，例如 Atlas (Telemetry Platform)，Mantis, Nimble…等；利用通知工具時除了單純地發出訊息之外，也會把後續資訊提供在通知內，並且將處理狀況更新在其中，同時也會做到事件管理 (Incident Management) 跟 部署監控 (Deployment Monitoring)，看來 Telltale 什麼都做到了，只是其實這篇文章提到的架構相當的龐大，感覺不是單純把 Telltale 拿來用就可以了…▍ 原文：https://netflixtechblog.com/telltale-netflix-application-monitoring-simplified-5c08bfa780ba