笨蛋!關鍵是專業度!

這篇的由來也是因為前幾天發生了一段對話, 讓我想到過去發生(在別人身上 :p)過的慘痛經驗, 就想寫成一篇來分享一下. 畢竟我不是像 Joe Chang & Bryan Yao 這麼專業的顧問, 也常自哂是個沒讀什麼書的粗人, 沒辦法很系統化的去描述大框架的概念, 也只能想到什麼寫什麼了. (這100%是硬要牽拖的友情廣告贊助, Joe/Bryan請留一支黑牌給我當廣告費)

事情是, 某公司用的MySQL Database大概是因為Loading太高, 常常出現一些靈異現象: 當機也就罷了, 常常重啟之後這個Table壞那個Table少資料, 更可怕的是有時候Table會消失. 每次碰到這種麻煩, MIS/網管只好能修則修, 不能修只好倒備份回去. 可是每次倒備份都會有一段時間的資料消失, 甚至是好幾個DB之間相互參照的部份會有資料同步問題, 所以只好讓Programmer去寫一些檢查資料同步與完整性的工具, 然後讓備份更頻繁, 去降低發生時的損傷.

剛開始也只是電話裡口頭給一些可能的解決方案跟方向, 也請他們做過分析最佳化了Schema, 但是也只是稍微改善, 並沒有完全排除這個問題. 直到他們老闆終於首肯讓我進他們系統看看時, 已經是個AQPS(avg queries per second)超過20k的超可怕DB Host了, 當下我只好建議他們往Cluster方向走, 然後有了之前那堆MySQL架構的step by step. (話說到這, Jason你欠我的大餐哩? XD)

當下他們也就從善如流花了一些錢買新設備, 做好了Cluster, 但是顧及線上服務還在走, 他們有計劃的一點一點把東西從舊的搬到新的Cluster去, 悲慘的事情於焉發生, 這時他們備份系統用的磁帶櫃掛了, 暫時沒辦法維持原本的double daily backup, 只能weekly, 而他們心想, 反正已經搬走了30%的loading, 應該不會這麼衰在修好前又掛了吧! 所以就說莫非定律一定在這種莫非的時候發生, 真的突然掛了.

他們雖然也就照以前的災難復原SOP去做, 但是這次備份的間隔有點大, 實在會被罵的太用力, 而他們的DBA也很坦白的說無能為力, 可能得去跟Oracle買MySQL的Consult Service看他們能不能從壞掉的Datafile裡頭救, 於是他們還是找上我.

當我Remote連上去, 看到那些壞的徹底的datafile也是感到很絕望, 但是卻同時看到希望: 他們還有著整整兩個月份量的Binary Log都沒Purge掉, 這真是太神奇了傑克! 所以就確認他們備份的時間, 把那個時間後的Binary Log用mybinlog工具倒出來, 再一股腦的倒回去, 系統也就順利的回到掛掉的瞬間.

這個故事要說的是, 當你覺得你很熟悉一個系統或工具或語言時, 可能還遠遠不夠, 而決定你是「物有所值」或是「物超所值」的關鍵是專業度.

我的老婆是老大(My Wife Is a Gangster)片段

韓國笑片我的老婆是老大(My Wife Is a Gangster)裡頭有個爆笑對話但是正好切題.

流氓A: 你知道小混混跟流氓的差別是什麼?
流氓B: ….(疑惑)
流氓A: 笨蛋, 是專業度!

剛剛那個案例裡, 那家公司並非草包, 技術人員們也各各身懷絕技, 但是他們敗在以為自己太熟悉系統而忘記永遠要知其所以然, 所以縱然有這麼好的身手跟技術, 卻不知道其實早就有Binary Log及解開Binary Log的工具可以幫助我們做Data Restore. 如果他們能相信自己不夠專業, 而認真的閱讀手冊, 看mailing list, 而不是自滿於管理過20k AQPS的大型(其實這種規模大概只能算中型)DBMS而覺得自己已經夠專業, 那麼他們不但可以更快更安穩的解決他們碰到的問題, 更可以提高自己在老闆眼中的身價.

我們也常常看到履歷表中, 求職者洋洋灑灑寫了一堆自己會的東西, 甚至會有人寫精通, 但是我卻總是很迷惑於「究竟是多精通?」, 每次Interview後又總是失望, 可能只是下載過幾個Linux Distro然後照著鳥哥的文件一步一步弄了一些常用的service, 就寫上精通. 或者是只是唸書上計概學過一些VB寫過「Mini-Calc」程式作業然後就寫上精通. 這又是另外一種不夠專業的典型.

身為一個技術人員, 專業是必須的, 一樣當你覺得自己夠專業了, 其實就斷絕了自己邁向專業的可能.

喔對了, 當流氓也是一樣的! XD

投資現在, 還是投資未來?

先說一個真實故事, 這個故事我甚至不用解釋或強調真實性, 因為同樣的pattern在這個世界到處在發生.

某A公司是一個新創的IC Design House, 創辦人Peter是個在這方面學有專精又有想法的經營者, 他在辛苦經營了三年終於開始轉虧為盈, 第四年更進一步成長到50人規模的Design House, 同時也開始賺進了第一桶金: 純利1200萬.

員工們都很開心, 辛苦了這些年終於開花結果, 大家都在期待著手上擁有專利與穩定客戶的公司何時會開始增資, 何時開始準備上市上櫃, 當然還有, 這一年的年終獎金會是怎樣呢?

這時候Peter在尾牙上告訴大家, 這1200萬的純利, 他會拿出其中200萬當作額外的獎金, 當台下員工議論紛紛的同時, 他接著說, 他要將其於的1000萬投資在公司的開發, 測試, 及模擬系統上.

當時整間公司嘩然, 一個僅50人, 規模只能堪稱剛起步的公司, 不但短時間內用不到那上億的專業系統, 更不用說一千萬幾乎什麼都買不到. 所以私下討論是不是Peter要中飽私囊, 甚至開始有同事正在觀望年後是不是要跳槽到其他公司去.

第五年, Peter並沒有買進大批系統需要的設備軟硬體, 也沒有在財務報表上提示出這一千萬作為股東配息, 反而是把這一千萬直接現金增資, 並且成立了一個直屬於他的系統團隊. 他高薪挖來了一個曾在德國某S公司擔任過CIO的老外, 並且讓這個老外組織了一個平均年齡僅25歲的Programmer團隊. 這一年公司的業績大幅成長, 原先編制也上漲到接近100人, 而第五年底的財務狀況是純利2800萬 — 不算這個系統團隊的話, 算進這個系統團隊的成本之後, 只獲利了1500萬, 而這一年這個系統團隊沒有任何產出, 所以開始有些人離職了. 而Peter也同時把1500萬的純利抽出1200萬加碼投資這個系統團隊.

第六年時因為流失了一些關鍵人才, 所以人數及營收都沒有大幅成長.

第七年發生了一件事, 國外某H大廠為了他們標下了美國國防部的標案, 下了一筆極大量, 對產品品質及彈性都十分要求的大單給A公司的對手R公司, 而R公司不但跟A公司幾乎同時間成立, 產品線跟客戶群也和A公司相近, 最大的不同是R公司在第五年才損益平衡, 但是第七年時已經是比A公司大兩倍, 準備上櫃的明星公司.

悲劇來了, 由於R公司並沒有建立足夠專業及自動化的開發測試模擬系統上, 因此第一批出貨就慘遭退貨. 這時Peter趕到國外去見H大廠的高層, 然後帶著一疊文件回來.

他在關著房門跟那個神秘又燒錢的系統團隊密集開了一個禮拜的會之後, 員工們看見一車一車的硬體設備被送進公司, 系統團隊的同事們忙近忙出. 兩週後, Peter招開了一個員工大會.

他在員工大會上花了2個小時跟所有工程師解釋系統團隊三年來的成就 — 一套嶄新, 符合他們工作流程, 自行開發的模擬系統, 並且要求所有工程師要在半個月內熟悉這套系統, 因為他們要承接H大廠的超級大單了.

後頭的故事就不用我說了, A公司已經是個數千人的上市公司, 而這位國外高薪聘請回來的CIO, 說服了董事會由A公司100%轉投資另外一家軟體開發公司, 他們的模擬軟體在兩年內拿下那個專有市場的30% marketing share. 業內同質公司業績越好, 越需要他的軟體, A公司就越賺. 同時A公司可以依靠比別家公司更省的成本, 得到更多的大單. 而R公司不但成為他們轉投資軟體公司的客戶, 過了幾年也被A公司併購了. 也就是說Peter用了三年共約四千萬的投入, 省下了接近六千萬的軟體, 而且這是在他剛看到黎明曙光的第四年下的決定 — 盡管他可能在當下都不能肯定他未來需不需要這個系統.

說這個故事, 其實重點是談幾件事情.

  1. 當所有人投資現在, 他們會是現在的贏家. 但能投資未來的人才會是未來的贏家.
  2. 在天還沒亮之前, 任何長遠的投資都像買樂透一般 — 因為你有極大的機率付不出second round的投資, 而你的first round, 就成為捨不得也沒辦法的沉默成本.
  3. 信任你的領導人, 尤其是他曾經帶領著大家打過勝仗
  4. 永遠不要忘記投資自己, 因為那將是最好的回收

其實額外還想藉著這個主題談一件好像不相關的事, 但是我卻想在這選前之夜如以往一樣的呼籲….

那就是, 去投票吧! 投票, 就是對國家未來最好的投資.