設(shè)計(jì)系統(tǒng)的組織，最終產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。"--Conway'sLaw.
傳統(tǒng)企業(yè)之殤
運(yùn)維之痛1：人肉vs平臺(tái)
人肉不是傳統(tǒng)運(yùn)維的當(dāng)下過失，是過去的延續(xù)。在早期，運(yùn)維的很多能力建立在少量的高可用硬件對(duì)象之上，平臺(tái)化的需求很弱。另外，閉源的軟件生態(tài)，給平臺(tái)化的建設(shè)增加難度，而這些歷史債務(wù)，并不是一下就能丟下的。留給傳統(tǒng)企業(yè)的時(shí)間并不是那么充足，開放平臺(tái)和業(yè)務(wù)的互聯(lián)網(wǎng)化帶來的沖擊是非常大的，時(shí)間非常的短。這是一個(gè)多維沖擊能力，從思維、技術(shù)、能力等多個(gè)維度。
不過很開心的是，傳統(tǒng)企業(yè)運(yùn)維人對(duì)運(yùn)維平臺(tái)擁抱非常強(qiáng)烈，從運(yùn)維自身能力自動(dòng)化到全流程的持續(xù)交付自動(dòng)化。我也經(jīng)過和傳統(tǒng)企業(yè)的IT部門深入廣泛接觸，大家對(duì)運(yùn)維自動(dòng)化作為突破口非常認(rèn)可，更愿意以此為原點(diǎn)，單點(diǎn)突破，再全面覆蓋。
運(yùn)維之痛2：流程vs創(chuàng)新
很多人會(huì)告訴我，在傳統(tǒng)企業(yè)中沒辦法，我們必須通過流程來驅(qū)動(dòng)各個(gè)組織角色，確保協(xié)同工作。真的如此么?我們?cè)隍v訊維護(hù)那么多產(chǎn)品線，沒有流程怎么做到的?然后真的會(huì)混亂不堪么?我和我之前的運(yùn)維團(tuán)隊(duì)來說，如果你不能保持一個(gè)對(duì)外的簡(jiǎn)單清晰運(yùn)維界面，那就是我們工作的失職。
流程是我們找不到解決方案的時(shí)候，添加的累贅！很榮幸，我了解的傳統(tǒng)企業(yè)中，給我上了一趟生動(dòng)的流程課，此處和大家分享一下。
場(chǎng)景1：服務(wù)上線申請(qǐng)
我們都知道根據(jù)TOGAF框架，企業(yè)中分業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)、技術(shù)架構(gòu)和基礎(chǔ)架構(gòu)中，你仔細(xì)去看看定義，非常的完美。但我覺得這種集中式的垂直劃分，就是問題所在，誰能做到全局的架構(gòu)設(shè)計(jì)，特別是面向應(yīng)用端的系統(tǒng)設(shè)計(jì)。這個(gè)時(shí)候問題來了，一個(gè)研發(fā)有個(gè)業(yè)務(wù)上線，首先找到了基礎(chǔ)架構(gòu)組要服務(wù)資源，基礎(chǔ)架構(gòu)組和研發(fā)說，你要和業(yè)務(wù)、數(shù)據(jù)架構(gòu)組先評(píng)估一下數(shù)據(jù)需要，和技術(shù)架構(gòu)評(píng)估一下技術(shù)架構(gòu)要求才能確定基礎(chǔ)的資源需求。真要如此復(fù)雜么?其實(shí)就是一個(gè)業(yè)務(wù)上線而已，我們?cè)u(píng)估了那么多的業(yè)務(wù)容量，就那么幾個(gè)指標(biāo)而已，訪問量、讀寫、熱點(diǎn)集中度、數(shù)據(jù)量大小等等，基本上能評(píng)估一個(gè)業(yè)務(wù)完整資源需求。這是一個(gè)繞圈式的流程設(shè)計(jì)。
場(chǎng)景2：附加角色
環(huán)境搭建太痛苦了，增加一個(gè)環(huán)境管理組吧；各部門的目標(biāo)不一致，KPI無法協(xié)調(diào)，成立一個(gè)目標(biāo)管理組吧；流程沒法協(xié)調(diào)，成立一個(gè)流程組吧；質(zhì)量不行，成立一個(gè)質(zhì)量管理組吧。我覺得這些都是附加角色，所謂的附加角色，就是在沒有找到實(shí)質(zhì)解決方案的情況下，不斷的添加一些check角色來改進(jìn)現(xiàn)狀。真的改進(jìn)了么?沒有，附加角色只會(huì)是增加了事務(wù)的復(fù)雜度和后續(xù)的執(zhí)行難度。
那怎么辦?這類問題要不斷的問自己，為什么環(huán)境搭建痛苦?環(huán)境太多，太復(fù)雜了，為什么復(fù)雜?每個(gè)業(yè)務(wù)不一樣?為什么不一樣?是因?yàn)榧軜?gòu)不統(tǒng)一，為什么不統(tǒng)一?....問題的改進(jìn)，其實(shí)就是工具和最佳實(shí)踐的不斷組合迭代。
運(yùn)維之痛3：責(zé)任分離vs持續(xù)改進(jìn)
沒有比責(zé)任分離更糟糕的事情了。在一個(gè)問題產(chǎn)生的時(shí)候，大家首先不是想著如何尋求更好的解決方案，而是在找這個(gè)問題應(yīng)該由哪個(gè)團(tuán)隊(duì)的責(zé)任。責(zé)任分離可以說是過度流程化的結(jié)果，流程設(shè)計(jì)者們很多都在精心設(shè)計(jì)責(zé)任應(yīng)該由誰來背。當(dāng)責(zé)任被清晰的界定之后，而后的解決方案也只能落到該團(tuán)隊(duì)上了，自然而然，思維就局限了。
其實(shí)應(yīng)該換個(gè)視角，當(dāng)業(yè)務(wù)的質(zhì)量出問題了，持續(xù)交付這個(gè)鏈條上的所有人都有責(zé)任，而基于責(zé)任的分析范圍應(yīng)該更廣泛一些，需要思維上的突破。我們總是怪測(cè)試不夠充分，你給到足夠的時(shí)間給測(cè)試了么?你讓測(cè)試早期參與了么?你建立了穩(wěn)定的技術(shù)框架，讓自動(dòng)化測(cè)試更好的覆蓋了么?怪運(yùn)維的環(huán)境部署有問題，你有降低運(yùn)維部署的復(fù)雜度么?怪運(yùn)維定位問題慢，你有把運(yùn)維定位故障的復(fù)雜度降低么，消除了菜鳥和專家的區(qū)別么?反之亦然。
更糟糕的是，當(dāng)問題變得越來越嚴(yán)重的時(shí)候，還在想著流程設(shè)計(jì)得不夠完美。
運(yùn)維之痛4：組織設(shè)計(jì)
"設(shè)計(jì)系統(tǒng)的組織，最終產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。"--Conway'sLaw.
不得不說，傳統(tǒng)的職能式的IT組織架構(gòu)越來越不能滿足互聯(lián)網(wǎng)化的業(yè)務(wù)需要了。基于持續(xù)交付打造的全鏈條整合鏈條打破的就是職能邊界，提供的就是面向產(chǎn)品化的服務(wù)能力。如果組織不能給新產(chǎn)品上線和老產(chǎn)品快速迭代提供足夠的能力支撐，那么這個(gè)組織一定是冗余設(shè)計(jì)的。架構(gòu)組提供的架構(gòu)能力只能是一個(gè)意向參考，沒有真正的落地實(shí)現(xiàn)，這個(gè)架構(gòu)組就是冗余的；流程組提供的流程能力是減慢了交付速度，這個(gè)流程組就應(yīng)該去思考是否把流程讓位于更優(yōu)的技術(shù)實(shí)現(xiàn)。
很容易觀察到的一個(gè)效果，復(fù)雜的組織設(shè)計(jì)，最終讓設(shè)計(jì)出來的軟件復(fù)雜，導(dǎo)致問題重重，隨后便不斷的增加附加角色，讓軟件的交付過程主次不分。其實(shí)附加角色增加的檢查點(diǎn)并不能起到服務(wù)改善的作用，“越早發(fā)現(xiàn)缺陷，越早修復(fù)成本越低”這個(gè)準(zhǔn)則需要深刻體會(huì)，check機(jī)制都是事后的機(jī)制，是人肉機(jī)制，而自動(dòng)化的機(jī)制必須早期介入。
糟糕的情況，組織設(shè)計(jì)完全面向問題，而非面向用戶。誰能代替用戶來對(duì)IT組織的考核?沒有。但我們的方式恰恰相反，認(rèn)為考核組就可以，針對(duì)每個(gè)小組，設(shè)計(jì)了一些指標(biāo)。說實(shí)話考核組離一線現(xiàn)場(chǎng)太遠(yuǎn)了，數(shù)據(jù)的是非判斷準(zhǔn)則都很難建立。
運(yùn)維之痛5：架構(gòu)設(shè)計(jì)
架構(gòu)設(shè)計(jì)的問題是一直是核心的技術(shù)問題所在。架構(gòu)設(shè)計(jì)問題體現(xiàn)在很多方面：
1、不能建立統(tǒng)一的架構(gòu)標(biāo)準(zhǔn)
架構(gòu)師在傳統(tǒng)企業(yè)中是普遍的存在，而架構(gòu)規(guī)范恰恰不是普遍的存在。很多時(shí)候都讓位于業(yè)務(wù)的復(fù)雜需求，認(rèn)為技術(shù)架構(gòu)標(biāo)準(zhǔn)可以放低。技術(shù)架構(gòu)標(biāo)準(zhǔn)絕不是架構(gòu)師的呼聲，應(yīng)該是產(chǎn)品線的統(tǒng)一技術(shù)要求。合理的技術(shù)架構(gòu)，會(huì)大大提升后續(xù)的產(chǎn)品推出速度和演進(jìn)速度。
2、從代碼依賴到二進(jìn)制依賴到服務(wù)依賴
很多傳統(tǒng)企業(yè)的大型軟件之間采用的還是代碼依賴，當(dāng)一個(gè)組件發(fā)生變化的時(shí)候，這個(gè)時(shí)候需要整個(gè)系統(tǒng)的全量更新。久而久之，更新的代碼影響哪些外部系統(tǒng)，都不知道。這是深度耦合，給后續(xù)的測(cè)試和運(yùn)維都帶來了很大的難度。到服務(wù)依賴，才能真正的實(shí)現(xiàn)架構(gòu)自治。
|
