某一天上班的時間，我正在規劃新的網路架構與DNS安全性的議題報告時，突然有一種很深的感慨…
在近十年的工作資歷當中，IT相關的部份一直佔得很重，當然台灣企業來說不太像國外一樣分的那麼清楚，所以當IT的同時也兼著開發ERP系統，可以說是「IT為主 程式為輔」的界定吧^^b！之前在鈊象電子任職軟體設計師的時候，就一直覺得很吃力，雖然說寫程式是我的興趣，也算是專長之一，但跟極專業的軟體設計師比我當然還是差多了。有鑑於此在感觸的當下我把 MSN 的暱稱改為「當 IT 比當程式設計師有成就感多了！」~
後來 Maduka 敲我的 MSN 時看到我的暱稱，只發出了一陣陰險的笑聲(XD)，莫約十秒後他的暱稱變成「當程式設計師 比當 IT 有成就感多了！」。好吧~我被嗆了~哇哈~由於當下我沒想太多，看了笑一下之後我就繼續我的工作了。
下班騎機車回來途中，腦袋一直運轉著下午的話題，分析到底是 IT 好還是 Program 好，後來發現…
現在是網際網路發達的年代，如果今天程式寫的再好，那沒有好的 IT 架構也沒有用啊！舉個例子：
================================================
今天公司有發送大量電子報的需求，RD部門已經將程式的效能、執行續、網路 I/O 相關的部份寫的非常好了！測試 1000 封發送速度極快，已經可以上線了！但正式運作時則經常發生以下情形 —
01.退信率高
02.發信時部門網路幾乎癱瘓
03.發送到某個數量時 SMTP Server 主機會產生死當
04.超過 10000 封以後寄信速度會只剩下 1 / 6
從以上的情形看來是程式設計的問題嗎？為什麼在測試的時候很ok，一上線就變成這個樣子呢？
會以電子報作為例子是因為這是個很典型的 程式 + IT 一起運作的例子 (我在某機公司就遇到這樣的情況)，問題其實是出在 —
01.DNS 無 MX 紀錄或是反解不正確
02.網路架構層級太深，電子報的 Server 位於網路底層，但 SMTP Server 在網路的上層
03.沒有調整 SMTP 工作階段的數量，大量發送的情況下 MTA 程式更是一個關鍵點
讓我們來針對每一個問題作處理 (以下為 IT 部門的負責範圍) —
- DNS 的 MX 紀錄設定好，PTR紀錄設反解，如果要成功機率更高則加入 SPF Record 與 CallerID Record
- 可將 SMTP 放置到 DMZ 中，減少封包經由 NAT 轉換的損失，並將電子報主機移至跟 SMTP Server 同一個 Switch ( 視情況是否加入 DMZ)
- MTA來說，可以使用 Linux Base 的 Postfix，並參閱官方的設定說明 (建議發送 eDM 不要使用 IIS 的 SMTP)。
================================================
由以上的例子可以看得出來，程式寫的好但是 IT 架構設計不良，程式的好無法顯現出來
IT 架構設計優良，但是沒有好的程式來執行測試，那其價值也無法發揮
最後，我的 MSN 參照「食神」中的撒尿牛丸改成「IT 與 Program 有什麼好爭的！混在一起搞個 ERP 不就得了！」
最後我的朋友也很欣然同意了我的說法了 ^^
現在是團隊合作的時候，單兵作戰的時代已經過去了，唯有多方面的配合才能讓企業更加快速的成長
願我的朋友們每一位都可以擔任團隊中的關鍵角色，你們一定可以的！GO~
