做服務而不僅僅是開發軟件

今天讀到一篇博客，標題為 DevOps – Not Good Enough ，作者 MARTY ABBOTT 的觀點大致為，DevOps 把開發、QA、運維等環節打通，解決或緩解了傳統 IT 所遇到的很多問題，然而這還不夠，我們需要認清最根本的兩個問題。第一個問題是：傳統企業的 IT 基礎設施和架構是為了支持各種各樣的第三方軟件，其目的是節省成本而不是創新；第二個問題是：傳統的軟件開發和維護是分離的，開發軟件更多的關注是把它賣 了，而不太關心軟件最終如何運行。

然而，今天行業發生了巨大的變化：

現在，客戶購買服務而不是軟件。要在這個全新的世界獲得成功，就需要改變觀點，即組成這些服務的原材料不僅包括軟件，也包括硬件 （基礎設施）。如果你的團隊沒有合理地組合這些原材料，那么最終服務也不會如預期的那么好。如果繼續“生產”軟件，然后“托管”在基礎設施上，那么最好的 結果也僅僅是次優的解決方案，最差的結果則可能是一場災難。

MARTY 又接著說，我們應該：

把團隊組織成跨職能的、實用且多樣的、自治的團隊，各個團隊擁有整個產品中獨立的一些服務。各個團隊和服務應該由集中面向業務的 KPI 驅動。這些團隊應該能夠獨立自主地開發、部署、支持自己的服務，不需要依賴其他團隊。

我們都知道，如果一件工作需要跨團隊合作，工作效率會急劇下降，各種推責扯皮的事情就會冒出來，管理成本直線上升，需要富有經驗的項目經理協 調，需要指定共同的目標，需要開很多很多的會…… 在這種背景下，快速地應對市場變化、開發創新的產品就難免變得困難重重。為什么現在很多很小的互聯網公司能那么快速地發展起來，我想一個很大的原因就是因 為他們夠快， 夠“敏捷”，現在很多基礎設施如代碼托管、服務托管、應用程序監控都有了比較成熟的市場及服務（至少在國外），它們中有我們耳熟能詳的 Github、Amazon EC2、New Relic 等等，在這些基礎設施足夠靈活、足夠穩定的情況下，小型互聯網公司能夠專注自己產品和服務，技術人才也比較容易“跨職能”，設想在傳統的大的 IT 公司內，一名開發人員要了解運維體系幾乎是不太可能的事情，但現在如果是用 Amazon EC2，則只要學習一些簡單的 API 即可，而且相關工具也更加簡單。

市場上成熟的 IAAS/PAAS 幫開發人員簡化了很多問題，也使得程序員關注 OPS 的門檻降低了。除此之外，敏捷運動在幫助開發團隊跨職能方面也功不可沒，尤其是，敏捷強調開發和測試角色的融合，事實上，現在優秀的開發人員都具備比較強 的測試意識和測試技能，而像 Google 那樣的公司，專職測試的研發能力較普通開發來說有過之而無不及（見 Google軟件測試之道 ）。也正因為如此，如果一個團隊的成員都比較優秀，再加上有比較出色的產品經理，那么擁有一支靠譜的跨職能團隊也不是那么遙不可及的事情，他們能夠每天直面用戶，以小時為單位做出響應，因此在市場中有巨大的競爭優勢。

對于一名普普通通的程序員（像我這樣），應該如何面對這樣的行業趨勢？如何才能保持自己的競爭優勢，不至于在40歲的時候被裁員、被淘汰？

首先是觀念的轉變，“程序員”或者“軟件工程師”這樣的頭銜也許已經過時了，實際上我們應該是做服務的，這一點和開餐廳、開發廊沒有本質的區 別。唯有做到吸引更多的客戶、讓客戶滿意，才能保證組織的生存和壯大，也進而是我們自己的發展和壯大。怎樣做才能吸引客戶？才能讓客戶滿意呢？那你得理解 他，例如通過運維數據去理解；你得保證服務的質量，要保證可用性，保證功能正確；你得有創新，讓客戶眼前一亮。因此，你不僅要和機器打交道，你還要學會通 過各種方法和客戶打交道。

其二，在觀念轉變的基礎上，有針對地拓展自己的技能。為什么要學習自動化測試？因為它能幫助我們提升軟件質量，讓客戶滿意；為什么要學習 DevOps 方法論和相關工具？因為它能讓我們更快發布軟件響應客戶的需要；為什么要關注性能？因為客戶是人，人的耐性是有限度的；為什么要關注可用性？因為客戶是 人，一般人如果遇到 Starbucks人滿為患，它會去對面的 Costa 買拿鐵的。

我無法想像20年后程序員后會用什么語言怎樣開發軟件，正如20年前也很少有人能想到今天移動互聯網的如火如荼，也許屆時程序員這個職業也會漸漸消失，但不論如何，我相信通過技術服務人的人性需求，這樣的一個基本事實是不大可能發生變化的。