Conway's law：系統(tǒng)設(shè)計(jì)本質(zhì)上反映了企業(yè)的組織機(jī)構(gòu)。系統(tǒng)各個(gè)模塊間的接口也反映了企業(yè)各個(gè)部門之間的信息流動(dòng)和合作方式。

因?yàn)樗饺说脑?，我前段時(shí)間換了工作，雖然仍然是在網(wǎng)絡(luò)領(lǐng)域，仍然是做研發(fā)。但有三點(diǎn)很大的不同：1.從乙方到了甲方。2. 從一個(gè)扁平的創(chuàng)業(yè)公司進(jìn)入了一個(gè)等級(jí)森嚴(yán)的大型企業(yè)。3. 從研發(fā)驅(qū)動(dòng)的工作環(huán)境進(jìn)入了業(yè)務(wù)和運(yùn)營驅(qū)動(dòng)的工作環(huán)境。這次轉(zhuǎn)變帶給了我一些全新的視角，很有趣。之前一些困惑也變得慢慢有了自己的答案：Conway's law，這個(gè)一度被我嚴(yán)重忽視的概念竟然是解答很多問題的根源所在。

困惑一：甲方需要什么樣的SDN產(chǎn)品

甲方需要的是最符合其組織架構(gòu)的SDN產(chǎn)品而不是最好的SDN產(chǎn)品。如果幾個(gè)廠家的SDN產(chǎn)品在功能上都基本滿足需求，在價(jià)格上差別也不大，那么這個(gè)產(chǎn)品的使用和運(yùn)維方式是否能夠?qū)?yīng)到企業(yè)現(xiàn)有的組織結(jié)構(gòu)上去就成為了最關(guān)鍵的因素。也就是要盡可能的讓甲方已有的研發(fā)，測(cè)試，運(yùn)維人員從事和之前差不多的工作。這里的差不多是指：新系統(tǒng)的引入，不能讓既成事實(shí)的團(tuán)隊(duì)職責(zé)發(fā)生太大的變化。這里拿幾個(gè)常見的SDN功能舉例子。

快速部署(zero touch provisioning)：一般來說，這是一個(gè)好feature。最大的好處不僅僅是縮短了部署交付的時(shí)間，而是讓負(fù)責(zé)部署交付的部門能夠有kpi邀功：去年上線新集群用了一個(gè)月；今年在任務(wù)更重，人力不變的前提下只用了一周，效率提升了，皆大歡喜。

零接觸運(yùn)維(zero touch operation)：控制器接管了所有的交換機(jī)，所有的運(yùn)維操作全部在控制器完成。這個(gè)功能非?？?，似乎也符合自動(dòng)化運(yùn)維的愿景。但對(duì)于那些運(yùn)維主導(dǎo)的企業(yè)而言有個(gè)致命的問題：它讓運(yùn)維人員的職責(zé)大幅度減少。面對(duì)這樣的客戶，系統(tǒng)設(shè)計(jì)的原則之一就是要讓人成為系統(tǒng)使用環(huán)節(jié)當(dāng)中必不可少的一部分，系統(tǒng)的亮點(diǎn)不應(yīng)該是替代人的職責(zé)，而是輔助人的工作。更合理的做法舉例：提供puppet，chef或者rest接口，能夠讓運(yùn)維人員輕松的編寫腳本控制設(shè)備。

漂亮的前端：這是demo時(shí)最重要的feature，沒有之一。但對(duì)于絕大多數(shù)甲方，尤其是那些研發(fā)話語權(quán)比較大的甲方而言，重寫UI是必然發(fā)生的。一方面新系統(tǒng)需要和甲方已有的系統(tǒng)統(tǒng)一前端，更重要的是甲方研發(fā)也有kpi的壓力，自研前端是難度最低，曝光度最高的項(xiàng)目。面對(duì)這樣的客戶，漂亮的前端反而不如詳細(xì)的rest api文檔和靈活的可定制的前端模塊有意義。

快速故障定位：這個(gè)同樣需要因甲方而異。對(duì)于運(yùn)維主導(dǎo)的甲方，這個(gè)功能做得越完整越好。而對(duì)于研發(fā)具有相當(dāng)話語權(quán)的甲方而言，卻完全不是這樣。研發(fā)所面對(duì)的故障定位不單單是一次采購的設(shè)備，而是企業(yè)現(xiàn)網(wǎng)的所有設(shè)備。他們需要一套比較通用的故障定位方法：snmp，各種計(jì)數(shù)器，下發(fā)ACL定位包的路徑等等。如果能夠把這些基礎(chǔ)服務(wù)包裝好開放給具有相當(dāng)研發(fā)能力的客戶，其價(jià)值要遠(yuǎn)遠(yuǎn)高于自己做一個(gè)完整的故障定位feature。

這些例子還可以舉出很多。核心思想只有一條：目前這個(gè)階段，SDN的自動(dòng)化程度還真的不是越高越好，而是越符合甲方的組織結(jié)構(gòu)越好。

困惑二：為什么微服務(wù)在技術(shù)上如此不堪，卻能夠大行其道

我一直以來對(duì)微服務(wù)頗有微詞，因?yàn)樵谖铱磥砦⒎?wù)是糟糕系統(tǒng)設(shè)計(jì)的代名詞：數(shù)據(jù)庫充斥著冗余數(shù)據(jù)，一致性糟糕；代碼里充斥著冗余邏輯，根本沒有復(fù)用；系統(tǒng)間本來能夠推送信息的，卻采用輪詢...

不少人認(rèn)為解耦單體服務(wù)能夠更快的迭代編譯上線，這是微服務(wù)大行其道的根本原因。但我卻覺著這個(gè)原因太單薄，也許是必要但絕對(duì)不是充分條件。與此同時(shí)，面對(duì)微服務(wù)勢(shì)如破竹的攻占了一個(gè)又一個(gè)的系統(tǒng)高地，我知道自己一定是忽略了某些東西。現(xiàn)在我知道這個(gè)東西又是Conway's law。

出了事故，避免部門之間推卸責(zé)任最好的方法就是事先把責(zé)任界定清楚。微服務(wù)天生能夠把責(zé)任界定清楚。僅此一條，微服務(wù)想不流行都難。知乎上有一篇話糙理不糙的論述，把微服務(wù)的一些原則總結(jié)的非常到位。對(duì)于這篇文章中“讓他們來取”和”組織墻“這兩個(gè)概念，我還有很多話想說，會(huì)專門開一篇。

這段時(shí)間整個(gè)人的思維方式發(fā)生了比較大的變化，打心眼里希望擺脫之前偏執(zhí)的工程師審美，試圖從更多元的角度來審視自己一直以來形成的思維定式。相信這是一個(gè)好的轉(zhuǎn)變。