Garbage In Garbage Out

        今年三月底，為了挽救公司的新產品，我臨危受命飛往馬來西雅。也是第一次我才一下飛機，透過越洋國際電話，就決定放生一位團隊同事。         下令放生之前，我寫了封信，跟團隊談談我心中認為『成功的系統』的關鍵要素：

        這一年多來，帶著團隊參與一間新創公司的產品開發，近一年的努力成果終於推向市場營運後，才幾個月不到，結束了。         如今還在收拾一些殘局的過程，看著這潮起潮落，我有些領悟。         當然結束營運背後有諸多複雜的原因混雜，有些也不是我這種技術層級的黑手工頭可以知道的。但是針對 IT 開發這塊，我有個代價挺高的領悟：         產品的系統特性，應交給市場幫你決定，而不是交給 系統架構師 來決定。

        繼 上次才寫到開頭的歷險記 ，第一週我先跟團隊達成『工作完成』定義的共識，避免錯誤的資訊混淆對實際狀況的掌握與判斷。         但是，即使掌握正確的專案進度，避免浮報無知的樂觀，卻 沒辦法讓實際的開發速度加快 。採用了每週一輪的 spring，前兩週都無法達成目標，以當時的 deadline 來看，團隊的開發效率若沒有改善， 肯定無法對上有所交代。

        上次『 大禹治水 』提到，對於採用 Windows＋ASP.NET＋MSSQL 技術的網站服務，找出網站系統變慢、效能不佳的原因其實有一簡易 SOP 可以起手，減少無頭蒼蠅盲目亂撞的時間成本浪費，這篇就簡單介紹一下這簡易的 SOP。         符合 “簡易” 的這個特徵有 兩個 條件： 不用額外安裝任何第三方軟件或工具 ，只使用作業系統內建的基本工具即可。 與系統特性無關 ，不需要先理解遇到麻煩的系統任何內部原理與商業邏輯。         所以任何任何人，都可依照這個 SOP，花個半天時間迅速判斷 80% 以上的網站效能瓶頸點。

（圖片源自 ”log4net面面觀之工作原理“ ）         一個系統是否容易追蹤與維護？出了問題容不容易快速查閱、釐清問題癥結？系統日誌（ System logging ）絕對佔著舉足輕重的角色。.NET 寫系統日誌的方案，最出名的大致上只有兩種： log4net 和 NLog 。兩者之間沒什麼優劣比較，這種東西，精通其中之一就很夠用。

        楚狂人 的『 玩股網 』前陣子發文公告系統不穩的情形，這兩天他寫了篇『 玩股網驚魂記 』說明了前因後果，看完後覺得可以當作一個個案解析的案例。         先談談文章所說最後發現玩股網無法正常運作的結論：被大量的 Crawler（ 網路爬蟲 ） 抓資料導致伺服器過於忙碌。開頭原本說判斷這應該不是駭客攻擊，其實就結果來看，這也算是一種攻擊手法： 分散式服務阻斷式攻擊 （ DDoS ） 。

        今年四月，正徘徊在職涯下一步的十字路口，當時剛好接到前同事電話力邀我加入一個剛成立半年的新創公司團隊，一起打造一個全新的新產品而努力。         當時被原公司既有的營運系統基於管理上風險的考量，而搞得拳腳難伸的我，在與灰心喪志之下，很受 眼前這個可以盡情嘗試各種全新技術與各種假設的創業機會所吸引，毅然訣然地揮別前公司 。         由於要能盡情試驗新技術、開發流程與團隊合作的模式，我加入的條件就是我必須擔任掌握這些權力的  Team Lead（這篇） 。         然而真正置身此處，才發現事情也沒有想像中那般美好。