打破Dev與Ops的高牆

今年三月微軟全球開發平臺事業部資深副總裁潘正磊訪臺，剛好有個空檔讓我跟她訪談。由於她是軟體工程師出身，在微軟總部帶領成員多達4千多位開發者的Visual Studio產品開發團隊，而且又是領導整個團隊實踐敏捷開發與DevOps流程的核心人物，有這個機會，我當然不會放過，於是，請教她當今最熱門的DevOps議題。

這幾年來，微軟的開發團隊已從傳統瀑布式開發模式轉為敏捷開發，以潘正磊帶領的Visual Studio團隊來說，開發步調從過去產品三年一次大改版的周期，加快為每三周就是一個Sprint周期，也就是一個小改版，而每個月的軟體組建（Build）次數亦高達22萬次。在這樣的規模與速度之下，潘正磊說，只有開發團隊自己做維運，也承擔維運的責任，才能交付高品質的軟體，而這就是DevOps的精神所在。

我接著問她一個問題：如果不是像微軟這麼大型的公司，特別是IT團隊成員普遍只有個位數的中小型企業，還適合做DevOps嗎？她卻回答我：就是像微軟這樣的大型企業，要推動DevOps才困難，小團隊反而容易得多。

這倒提醒了我，DevOps其實是源於新創網路公司。DevOps一詞可追溯到2009年歐萊禮Velocity大會上，網路相簿公司Flickr兩位工程師的講題：「10+ Deploys per Day：Dev and Ops Cooperation at Flickr」，他們分享如何在一天內執行10次以上的軟體部署，而其中一張簡報把Dev與Ops放在一顆愛心裏，觸動了開發者心弦，吹響DevOps的號角。（相關報導請參考：DevOps 2015大會專題報導）

一般來說，新創開發團隊的規模都不大，開發人員往往身兼多重角色，而網路服務的軟體更新又相當頻繁，在這樣的局勢下，自然而然，發展出對開發人員最方便也最快的作法：以程式做自動化測試、持續整合、自動化部署與持續交付等等，而且，他們也比其他開發團隊更早意識到，在敏捷開發的步調下，開發工程師（Dev）與維運工程師（Ops）緊密合作的必要性。

至於一般的企業，往往伴隨著公司業務成長，需要更多不同職能的人才，於是部門逐漸增加，分工日漸明細，這雖然是各司其職，卻也衍生出一些無形的阻礙，不知不覺中溝通效率變差了，本位主義作祟了，公司開始出現一道道隱形的高牆。

這種情況也會發生在IT部門，使得軟體開發的效率無法從源頭貫徹到服務上線。過去這幾年，有些企業已經開始採用敏捷開發方法，縮短開發周期，提升開發的速度與靈活度，並打掉開發團隊與需求端的高牆；不過，IT部門內還有一道立在開發與維運之間的高牆，使得在軟體開發至部署上線之間，仍有諸多障礙，大大影響軟體交付的速度與品質，而從新創網路公司濫觴的DevOps，就是打破這道牆的武器。

簡而言之，DevOps有兩大武器，分別是持續整合（Continuous Integration）與Infrastructure as Code，其中持續整合工具讓軟體開發、測試、組建（Build）等作業自動化，而如Puppet、Chef、Ansible這類自動化組態管理工具，則讓軟體部署作業自動化；兩者連貫起來，就打通了軟體開發以至上線的整串流程。

至於臺灣為數眾多的中小企業IT人員，往往也是開發與維運都得做，既要寫程式，也得架伺服器、設定網路，唯獨手上握有的資源可能不如網路新創公司。不過，中小企業的IT人員倒也不必絕望，最起碼你沒有大型企業難以處理的團隊問題，而現在又有許多如上述一流的開源工具，只要你學會善用DevOps的作法，站在巨人的肩膀上，小團隊說不定更容易出線。