一、背景介紹

圖片

技術(shù)治理結(jié)果的好壞往往體現(xiàn)在系統(tǒng)穩(wěn)定性、研發(fā)效率、IT成本這三個方面，過去3年時間里，我和我的團(tuán)隊一直在做這三方面的事情，從現(xiàn)在的結(jié)果看：

• 系統(tǒng)穩(wěn)定性從早期的故障頻發(fā)到如今故障收斂，并已經(jīng)接近2年都未發(fā)生過嚴(yán)重故障；
• IT單均（每筆訂單的IT花費(fèi)）過去一年也下降了50%以上，看起來是挺有效果的。

接下來我會介紹我們的實(shí)踐路徑，以及遇到的關(guān)鍵挑戰(zhàn)和應(yīng)對措施，希望本次分享可以給正在從事這項領(lǐng)域事情的朋友帶來一些參考價值。

圖片

從20年開始到現(xiàn)在，我們的業(yè)務(wù)訂單規(guī)模從大約50w/天發(fā)展到現(xiàn)在遠(yuǎn)遠(yuǎn)超過100w/天，技術(shù)團(tuán)隊規(guī)模也從300+人增長到現(xiàn)如今的1000+人，在這3～4年時間里，技術(shù)治理在不同時間階段也采取了不同的處理方式：

• 早期我們會更側(cè)重于對研發(fā)效率的提升，盡最大可能提升研發(fā)項目的迭代效率，支撐業(yè)務(wù)快速的發(fā)展。長期未得到妥善解決的技術(shù)債會加劇系統(tǒng)穩(wěn)定性風(fēng)險，我們就會切換治理重點(diǎn)，通過演進(jìn)和改造基礎(chǔ)架構(gòu)來提升系統(tǒng)高可用性，復(fù)雜的基礎(chǔ)架構(gòu)勢，必會引入更多的架構(gòu)規(guī)則約束，也會影響到研發(fā)效率，這個我們是可以接受的；

• 早期業(yè)務(wù)高速發(fā)展時期，更傾向于通過疊加IT資源，來加速技術(shù)迭代效率和守護(hù)技術(shù)穩(wěn)定性，一般中后期我們就會遇到IT成本的壓力，所以也需要更多的關(guān)注IT資源的使用效率，技術(shù)治理中提高IT資源優(yōu)化的權(quán)重。長期的技術(shù)治理過程中，我們很難同時滿足三個方面，以最大化支持公司業(yè)務(wù)發(fā)展考慮，在一些“平衡點(diǎn)”前后需要做一些側(cè)重點(diǎn)的切換。

接下來，我會從基礎(chǔ)架構(gòu)演進(jìn)、穩(wěn)定性保障和IT成本治理這三個方面分享下團(tuán)隊過去幾年里的實(shí)踐總結(jié)，尤其是關(guān)鍵技術(shù)方案選型、取舍的背后思考邏輯，和一些建議。

二、基礎(chǔ)架構(gòu)的演進(jìn)

圖片

基礎(chǔ)架構(gòu)的演進(jìn)需要遵循最優(yōu)滿足業(yè)務(wù)核心訴求原則，隨著互聯(lián)網(wǎng)行業(yè)技術(shù)的發(fā)展沉淀，現(xiàn)在技術(shù)架構(gòu)的實(shí)現(xiàn)與落地的門檻越來越低，架構(gòu)師比較容易設(shè)計和交付出先進(jìn)的技術(shù)架構(gòu)方案和方案落地規(guī)劃，但先進(jìn)的技術(shù)架構(gòu)不一定是業(yè)務(wù)核心訴求的最優(yōu)解。我們演進(jìn)基礎(chǔ)架構(gòu)主要遵循兩個思考點(diǎn)，作為背后的驅(qū)動力：

• 技術(shù)支撐業(yè)務(wù)快速發(fā)展，對研發(fā)效率和穩(wěn)定性的訴求，即技術(shù)要快又穩(wěn)
• 研發(fā)效率和穩(wěn)定性對基礎(chǔ)架構(gòu)的要求

「領(lǐng)先業(yè)務(wù)“半步”，不過度演進(jìn)」是我們對演進(jìn)節(jié)奏的把控，從2019年以“多個大單體服務(wù)架構(gòu)”演進(jìn)到2023年的“多泳道架構(gòu)”，每一次的架構(gòu)升級都是做增量設(shè)計，對現(xiàn)有運(yùn)行時環(huán)境、中間件進(jìn)行改造，幾乎不會對業(yè)務(wù)研發(fā)產(chǎn)生影響，也不需要業(yè)務(wù)研發(fā)投入大量時間配合改造。同時，每一次架構(gòu)升級都很好的解決了當(dāng)期的核心痛點(diǎn)：

• 2020年，基礎(chǔ)架構(gòu)由PHP單體大服務(wù)升級到泛服務(wù)化架構(gòu)，解決了業(yè)務(wù)研發(fā)對服務(wù)化治理的訴求，也無需進(jìn)行大規(guī)模的老代碼重構(gòu)；

• 2021年，在微服務(wù)架構(gòu)基礎(chǔ)上支持全鏈路灰度能力，支持全鏈路灰度高峰期發(fā)布，一個物理環(huán)境輕易就能快速構(gòu)建出多個獨(dú)立的邏輯鏈路環(huán)境，解決了研發(fā)和測試同學(xué)當(dāng)期的工作效率問題；

• 2023年，在全鏈路灰度架構(gòu)基礎(chǔ)上對流量標(biāo)識、網(wǎng)關(guān)、數(shù)據(jù)存儲等進(jìn)行改造，演進(jìn)到多泳道架構(gòu)，單個泳道對應(yīng)單個物理AZ，一個請求的后端事務(wù)處理盡可能在單泳道內(nèi)閉環(huán)，支持AZ機(jī)房容災(zāi)容錯能力。

圖片

依據(jù)實(shí)踐經(jīng)歷，有三個方面是我們格外注意的：

• 盡可能對上層服務(wù)、應(yīng)用架構(gòu)不侵入
• 盡可能不造成業(yè)務(wù)研發(fā)大面積的配合改造
• 團(tuán)隊熟悉的技術(shù)

因?yàn)榛A(chǔ)技術(shù)架構(gòu)本質(zhì)是由一組技術(shù)規(guī)則構(gòu)成，規(guī)則從流量調(diào)度、請求路由、服務(wù)調(diào)用、數(shù)據(jù)讀寫等多方面進(jìn)行了約束，且不能被打破，它天生就造成對業(yè)務(wù)技術(shù)架構(gòu)的侵入，影響了靈活性，所以好的基礎(chǔ)架構(gòu)盡可能減少對上層應(yīng)用的侵入是非常重要的；此外，選擇團(tuán)隊和業(yè)務(wù)研發(fā)同學(xué)他們最熟悉的技術(shù)通常是最優(yōu)的選擇，不要過于追求先進(jìn)技術(shù)。

我們早期的系統(tǒng)是由多個內(nèi)部PHP服務(wù)（服務(wù)臃腫，單個core服務(wù)包含幾百個接口很常見）組成，內(nèi)部服務(wù)之間主要通過域名+HTTP方式相互通訊，服務(wù)間通訊沒有標(biāo)準(zhǔn)的數(shù)據(jù)協(xié)議規(guī)范、缺乏基本的服務(wù)治理能力。隨著業(yè)務(wù)規(guī)模增長和系統(tǒng)整體復(fù)雜度上升，我們決定向微服務(wù)架構(gòu)演進(jìn)，就遇到了要么一刀切大規(guī)模改造、要么緩慢治理的選擇問題：

• 一刀切：采取成熟的開源SOA框架（像SpringCloud或dubbo），直接把我們的PHP服務(wù)按照SOA規(guī)范改造成標(biāo)準(zhǔn)SOA服務(wù)。這個思路的最大問題是影響面廣，涉及到每一個團(tuán)隊，改造工作量巨大，改造周期會比較長，可能會影響正常業(yè)務(wù)需求的日常交付上線，對處于高速發(fā)展期的業(yè)務(wù)來說難以接受；

• semi-SOA：避免一刀切，研發(fā)可以根據(jù)自身情況按需擇時重構(gòu)，先初步具備服務(wù)治理能力。

最終，我們選擇了semi-SOA的方案（一種類似于半服務(wù)化思路、內(nèi)部我們稱呼為泛服務(wù)調(diào)用），通過semi-SOA讓新老PHP服務(wù)、以及新老Java服務(wù)之間可以方面的互通互聯(lián)，同時整體系統(tǒng)又具備服務(wù)化治理能力，最重要的是所有業(yè)務(wù)研發(fā)團(tuán)隊不需要立即參入大規(guī)模改造，這種“過渡型技術(shù)方案”給研發(fā)團(tuán)隊預(yù)留了充足的按需改造時間，有條件的業(yè)務(wù)研發(fā)團(tuán)隊可以先行改造，去PHP化，新的Java服務(wù)與現(xiàn)存PHP服務(wù)之間又可以很好的兼容。

圖片

我們大約每間隔1年時間都會進(jìn)行一輪基礎(chǔ)架構(gòu)的演進(jìn)迭代，一方面是為長期大方向做一些儲備，另一方面是僅解決短期即將遇見的需求問題，2023年進(jìn)入多泳道架構(gòu)（一種跨AZ的高可用架構(gòu)），驅(qū)動我們做這件事情主要有兩個方面：

• 業(yè)務(wù)發(fā)展訴求，即是系統(tǒng)穩(wěn)定性要求，2022.4我們就發(fā)生過因底層硬件變更引發(fā)150臺機(jī)架宕機(jī)故障，我們業(yè)務(wù)系統(tǒng)癱瘓且無法恢復(fù)，只能等廠商修復(fù)；

• 業(yè)務(wù)對系統(tǒng)故障容忍度降低了，系統(tǒng)不可用導(dǎo)致的業(yè)務(wù)損失比較大了，需要我們考慮為這種低頻事件買一份“保險”，做更多的投入。

并未將基礎(chǔ)架構(gòu)直接演進(jìn)到同城雙活，主要是考慮成本，一方面IT資源成本，另一方面是研發(fā)改造成本；另外就是單AZ機(jī)房環(huán)境下系統(tǒng)穩(wěn)定性還有很多提升的空間，我們認(rèn)為這樣的“保險”程度目前是最合宜的。

三、技術(shù)保障的取舍

圖片

做好技術(shù)保障，防范系統(tǒng)穩(wěn)定性風(fēng)險的發(fā)生是技術(shù)治理過程中一個重要目標(biāo)，過去4年時間里，我們的穩(wěn)定性保障經(jīng)歷了三個階段，每個階段都制定了差異化的核心建設(shè)，通過階段性的迭代達(dá)到目前的體系化，系統(tǒng)故障數(shù)量從階段一時期的不理想狀態(tài)慢慢穩(wěn)定下來，到目前達(dá)到了健康狀態(tài)。

階段一：活下來

早期階段，我們更重視基本能力的建設(shè)，也就是守住關(guān)鍵戰(zhàn)場的基本盤能穩(wěn)定性下來，早期的監(jiān)控告警平臺、限流降級工具、生產(chǎn)環(huán)境變更規(guī)范都是需要重視的戰(zhàn)場。

階段二：規(guī)范、工具建設(shè)

當(dāng)整體穩(wěn)定下來后，所有工程師在日常系統(tǒng)變更、服務(wù)上線都有了穩(wěn)定性意識，大家都在按照統(tǒng)一的規(guī)范進(jìn)行操作，遇到問題都會按照規(guī)范進(jìn)行應(yīng)急處理了。接下來階段二我們會更關(guān)注效率和精細(xì)化的提升，我們成立了全職NOC團(tuán)隊專門對系統(tǒng)進(jìn)行盯盤和檢測、第一時間啟動應(yīng)急，也補(bǔ)齊了像容量壓測等工具平臺的建設(shè)，進(jìn)行深度的業(yè)務(wù)服務(wù)鏈路風(fēng)險的治理。這個階段，應(yīng)急處理效率、故障止損時效都有了具體的提升。

階段三：體系化建設(shè)

最終，我們的焦點(diǎn)是如何保障長期不出故障，盡可能防范黑天鵝和灰犀牛事件的發(fā)生。這個時期，除了工具能力、規(guī)范體系的不斷完善外，會更加重視穩(wěn)定性保障項目的日常運(yùn)營，一些簡單的事情會重復(fù)反復(fù)的去做，堅持高質(zhì)量的去做（譬如：每天都會對當(dāng)日發(fā)生的隱患事件進(jìn)行復(fù)盤，渴望發(fā)生共性問題，從而反哺回進(jìn)一步優(yōu)化工具和體系）

圖片

回顧我們整個穩(wěn)定性保障的經(jīng)歷，無論是早期的搭建工具能力、完善規(guī)范，還是中后期建制度和保障體系，都不是一帆風(fēng)順，也經(jīng)常遇到因服務(wù)雪崩導(dǎo)致故障止血不及時、忘記設(shè)置告警導(dǎo)致不能早起發(fā)現(xiàn)問題、共性的隱患在服務(wù)鏈路上未治理徹底或重新滋生導(dǎo)致故障等等，我們總結(jié)有三個關(guān)鍵地方需要格外做好：

1）保持極大的耐心，持續(xù)的高質(zhì)量做好日?！爸貜?fù)性”的事情，譬如鏈路服務(wù)的梳理和治理我們會間隔半年時間就會重復(fù)做一次，除了維護(hù)業(yè)務(wù)鏈路架構(gòu)和理性外，也解決過去半年新引入的問題；在日常發(fā)生的穩(wěn)定性隱患事件（非故障或冒煙）后，也會在當(dāng)日就閉環(huán)復(fù)盤，找出隱患發(fā)生的根因，舉一反三；

2）穩(wěn)定性保障最大的挑戰(zhàn)之一就是效率，長期始終如一的投入很多研發(fā)時間到穩(wěn)定性上是很難的，所以凡事能提升研發(fā)在穩(wěn)定性保障上的效率非常重要。模板告警是我們過去設(shè)計的一種智能告警的工具功能，它非常有用，我們將服務(wù)運(yùn)行時狀態(tài)中通用的地方（譬如：服務(wù)某種類型的異常數(shù)量同環(huán)比波動超過30%）都支持了模板告警，無需研發(fā)主動配置告警，即節(jié)省了研發(fā)大量時間，也避免了研發(fā)漏配或錯配；

3）如何長期獲得一個好結(jié)果（不發(fā)生故障）是我們追求的終極目標(biāo)，除了在技術(shù)上、人員素質(zhì)上要持續(xù)提升外，我們認(rèn)為有2個理念非常重要：

• 規(guī)范體系需要具備自我迭代能力，過去定義的規(guī)范不一定最適配當(dāng)下，所以我們每次在事件復(fù)盤中都渴望發(fā)現(xiàn)一些整改代辦項，完善當(dāng)前的規(guī)范體系；

• 不僅僅要做應(yīng)急預(yù)案的技術(shù)功能性演練，其他任何預(yù)期性質(zhì)的SOP都盡可能開展演練，把演練變成日常的一種習(xí)慣，這樣才能盡可能保證當(dāng)發(fā)生非預(yù)期事件（故障、冒煙）時你的所有預(yù)期內(nèi)的工具、SOP都能正常表現(xiàn)

穩(wěn)定性日常運(yùn)營

圖片

最后想和大家聊一下「穩(wěn)定性日常運(yùn)營」在我們的實(shí)踐中起到的巨大作用。

穩(wěn)定性規(guī)范和應(yīng)急能力隨著規(guī)模增長、系統(tǒng)復(fù)雜度上升后是需要重新迭代的，迭代的方向和內(nèi)容是依靠日常運(yùn)營中不斷的收集和統(tǒng)計，譬如NOC團(tuán)隊會收集每一天發(fā)生的所有隱患事件并給事件打上各種標(biāo)簽，每個月都會分析它們，會嘗試發(fā)現(xiàn)是否有異常的標(biāo)簽類型，并反饋給工具團(tuán)隊或者SOP規(guī)范定義團(tuán)隊進(jìn)行優(yōu)化。

日常運(yùn)營也有多種運(yùn)營級別，當(dāng)系統(tǒng)、團(tuán)隊、日常趨勢狀態(tài)都比較平穩(wěn)的時候，運(yùn)營級別是最低檔的，最低檔運(yùn)營級別對投入的要求最小，當(dāng)趨勢狀態(tài)糟糕時會調(diào)升運(yùn)營級別，這是一種靈活的方式來平衡穩(wěn)定性保障與研發(fā)投入的做法，當(dāng)然日常運(yùn)營的方式方法非常多，這里不做詳細(xì)展開了。

總結(jié)下，日常運(yùn)營可以幫助我們持續(xù)發(fā)現(xiàn)更多的瑕疵和漏洞，并反哺回規(guī)范機(jī)制與工具能力，運(yùn)營內(nèi)容涉及到規(guī)范、演練、技術(shù)治理、文化考試等多方面，它有效的防范了大家長期做一件事情的過程中容易導(dǎo)致的疏忽、犯錯風(fēng)險。

四、IT成本如何管治

圖片

最近幾年，大家都在做降本增效，IT資源成本是大頭。我們過去2年把IT單均數(shù)值優(yōu)化下降了50%以上，主要有兩個原因：首先最重要是早期業(yè)務(wù)快速發(fā)展時期，我們對IT資源使用效率關(guān)注是不夠的，所以在調(diào)整使用方式、做一些基本的技術(shù)優(yōu)化后就有了明顯的提升；另外就是建立起資源使用規(guī)范（包括不限于：資源分?jǐn)?、預(yù)算管理、成本可視化、成本異常檢測等等），杜絕不合理資源使用的產(chǎn)生。

其實(shí)，IT成本治理的關(guān)鍵點(diǎn)是IT資源是否做到了很高程度的科學(xué)使用，資源效率是不是達(dá)到了健康水平，唯省錢目的是不對的，這可能會對業(yè)務(wù)發(fā)展帶來損害，如果取得了IT成本治理結(jié)果而導(dǎo)致穩(wěn)定性風(fēng)險或者研發(fā)效率大大降低，那這樣是不劃算的，大家根據(jù)自己公司業(yè)務(wù)發(fā)展情況平衡看待吧。

圖片

我們在IT成本治理過程中，也發(fā)現(xiàn)了很多有意思的地方經(jīng)驗(yàn)技巧，比方說你可以聯(lián)合公司采購團(tuán)隊去和供應(yīng)商重新談判，嘗試爭取更優(yōu)惠的商務(wù)折扣，往往會立竿見影。

上圖，是我們進(jìn)行IT成本治理優(yōu)化的方法矩陣，矩陣中的“降低價格/價”就非常管用，我們對不同業(yè)務(wù)模塊的資源采取合理的RI(1/3年)、Savingplan、Spot/Ondemand等購買方式可以極大降低資源購買成本；其余優(yōu)化方法措施不進(jìn)行詳細(xì)介紹了，大家可以自行查閱。

作者介紹

陳永庭，貨拉拉 技術(shù)總監(jiān)。貨拉拉技術(shù)中心核心基礎(chǔ)設(shè)施部(CI)負(fù)責(zé)人，帶領(lǐng)CI團(tuán)隊負(fù)責(zé)公司整體基礎(chǔ)架構(gòu)的演進(jìn)，填補(bǔ)、維護(hù)基礎(chǔ)技術(shù)能力（中間件、框架、工具）保障技術(shù)團(tuán)隊的研發(fā)效率，負(fù)責(zé)全局穩(wěn)定性和技術(shù)保障、資源交付和IT成本治理優(yōu)化等主要工作。曾就職餓了么、騰訊、WebEx/Cisco，主要專注于中間件和基礎(chǔ)服務(wù)的研發(fā)、異地多活架構(gòu)的設(shè)計與實(shí)施落地。（聯(lián)系郵箱：sam1.chen@huolala.cn）