我們很習慣於用it思維顛覆傳統行業，可很少有人談怎麼借鑑傳統行業思維來看it環境的問題。
在為什麼我們永遠疲於奔命？
一文中我提到了
project phoenix
。該書裡把理想的it環境比成乙個流水線。作為多年來摸爬滾打的it老兵，我開始在情感上接受不了這個概念。心裡覺得不是滋味。可靜下來想想，雖然不能武斷的一刀切，但的確流水線思想有很多我們可以借鑑的地方。
一 賽車的速度和激情
大家知道賽車行業的科技含量是非常高的，作為門外看熱鬧的我，個人覺得有幾個突出的特點
部件多，質量要求極高
其中一部賽車的部件可能會有幾千上萬個，每個部件的質量要求直接影響到車的效能。
環節多
每個部件可能會在不同的地方生產、組裝和測試等等。
迭代快
很多最新的技術都是先在賽車上應用的。而且要求最短的時間內應用最新的技術。
二 it文化需要一場變革
如果拿it行業的工作和賽車工業比較，可能不太恰當。可賽車行業對質量和工作流的管理，很值得我們借鑑。為什麼人家能做的那麼好？那麼複雜的技術怎麼這麼快就能用上？要知道賽車的風險可是人命關天的大事啊。
回頭看看我們熟悉的一些it專案，尤其是infrastructure方面的，在談起一些devops的概念和方法時，有的人可能會不屑一顧。我們it是高技術含量，it人又不是生產線的工人，我們沒辦法提高效率，因為太複雜了，有很多不確定的因素。我對此觀點深不以為然。
多年的it經驗和直覺告訴我，it的開發、產品化和運維的思想需要一場變革。這也是我對devops有興趣的原因。這種變革不僅僅是採用新的流程和工具，人的觀念和文化上的改變更為重要。
想想我十多年前搭建linux伺服器的時候，從購買、佈線，配置系統、測試等等，少則幾天，多則幾周。可如今在amazon或者vmware混合雲上申請打包好的服務，幾分鐘內全部搞定。這種公有雲服務讓人覺得不需要關心那麼多細節，你要的應用隨時就可以就緒。
那麼在我們提供it產品給內部或者外部客戶的時候，能不能做到像amazon一樣快速、高效和可靠呢？你會說人家大企業有錢、有技術，我們不行。可仔細想想，這藉口經不起推敲。amazon、google等巨頭的it環境比你的複雜多少倍，風險和效能要求高多少，技術和資金投入固然必不可少，最關鍵的是他們有為客戶服務的精神，有做到極致的精神，有干預改變傳統的精神。
三用流水線的眼光看it
it環境的開發，產品管理不容易，因為每個環節都可能有不確定因素，可能對整體有系列的影響。
那麼怎麼入手呢？我覺得要循序漸進三個步驟：
標準化
如果我們能把每個環節都像生產線一樣，盡可能採用標準化的方式，就能最大程度上減少不確定性。
從而提高效率。
自動化
標準化之後，要嘗試盡可能自動化，避免人工干預。最大程度上保證了一致性和準確性。
一體化
打破設計、開發和運維的壁壘，充分融合，快速應用，快速反饋，從而實現產品或者服務的快速迭代
四 it人怎麼辦？
看到這裡，作為it人的我們怎麼辦？既然你都說像管流水線一樣管it，那麼我們不就成為流水線上的螺絲釘了？我們的價值如何體現呢？
我對此沒有答案。作為乙個it老兵，我也一直在努力的尋找答案。我也在
什麼是你的核心競爭力
？系列文中**了一些在雲時代it人需要積累的能力。
DevOps 用流水線的眼光看IT
我們很習慣於用it思維顛覆傳統行業，可很少有人談怎麼借鑑傳統行業思維來看it環境的問題。在為什麼我們永遠疲於奔命？一文中我提到了 project phoenix 該書裡把理想的it環境比成乙個流水線。作為多年來摸爬滾打的it老兵，我開始在情感上接受不了這個概念。心裡覺得不是滋味。可靜下來想想，雖然不...
流水線的幾個指標總結
在流水線這部分的理解中，需要再腦海中繪製一幅圖 橫軸是時間在流動，縱向表達的是指令的階段。這樣，斜著往右上角的同色的顏色塊是一條指令的執行。用一條平行於縱軸的線從0時開始往右移動，切到的塊數就是同一時刻在並行的段。如圖，分為四個階段，那麼前面四個階梯就是在效能爬坡階段，直到四個段可以同時並行，這樣以...
指令流水線的畫法
指令流水線的畫法 解題想法 流水線有五段，分別為s1，s2，s3，s4，s5.其中s4的執行時間為2 t,其他都是 t，乘法使用的是s1，s2，s5，加法使用的是s1，s3，s4，s5。利用吞吐率加速比和效率公式可不可以計算？對於此類題目，最好畫出指令流水線，因為公式法有一定的侷限性。畫好了！這樣畫...