建站
咨詢
售后
建站咨詢
新聞中心
一、背景介紹
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于做網(wǎng)站、網(wǎng)站建設、忻州網(wǎng)絡推廣、微信平臺小程序開發(fā)、忻州網(wǎng)絡營銷、忻州企業(yè)策劃、忻州品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供忻州建站搭建服務，24小時服務熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
圖片
技術治理結果的好壞往往體現(xiàn)在系統(tǒng)穩(wěn)定性、研發(fā)效率、IT成本這三個方面，過去3年時間里，我和我的團隊一直在做這三方面的事情，從現(xiàn)在的結果看：
- 系統(tǒng)穩(wěn)定性從早期的故障頻發(fā)到如今故障收斂，并已經(jīng)接近2年都未發(fā)生過嚴重故障；
- IT單均（每筆訂單的IT花費）過去一年也下降了50%以上，看起來是挺有效果的。
接下來我會介紹我們的實踐路徑，以及遇到的關鍵挑戰(zhàn)和應對措施，希望本次分享可以給正在從事這項領域事情的朋友帶來一些參考價值。
圖片
從20年開始到現(xiàn)在，我們的業(yè)務訂單規(guī)模從大約50w/天發(fā)展到現(xiàn)在遠遠超過100w/天，技術團隊規(guī)模也從300+人增長到現(xiàn)如今的1000+人，在這3～4年時間里，技術治理在不同時間階段也采取了不同的處理方式：
- 早期我們會更側重于對研發(fā)效率的提升，盡最大可能提升研發(fā)項目的迭代效率，支撐業(yè)務快速的發(fā)展。長期未得到妥善解決的技術債會加劇系統(tǒng)穩(wěn)定性風險，我們就會切換治理重點，通過演進和改造基礎架構來提升系統(tǒng)高可用性，復雜的基礎架構勢，必會引入更多的架構規(guī)則約束，也會影響到研發(fā)效率，這個我們是可以接受的；
- 早期業(yè)務高速發(fā)展時期，更傾向于通過疊加IT資源，來加速技術迭代效率和守護技術穩(wěn)定性，一般中后期我們就會遇到IT成本的壓力，所以也需要更多的關注IT資源的使用效率，技術治理中提高IT資源優(yōu)化的權重。長期的技術治理過程中，我們很難同時滿足三個方面，以最大化支持公司業(yè)務發(fā)展考慮，在一些“平衡點”前后需要做一些側重點的切換。
接下來，我會從基礎架構演進、穩(wěn)定性保障和IT成本治理這三個方面分享下團隊過去幾年里的實踐總結，尤其是關鍵技術方案選型、取舍的背后思考邏輯，和一些建議。
二、基礎架構的演進
圖片
基礎架構的演進需要遵循最優(yōu)滿足業(yè)務核心訴求原則，隨著互聯(lián)網(wǎng)行業(yè)技術的發(fā)展沉淀，現(xiàn)在技術架構的實現(xiàn)與落地的門檻越來越低，架構師比較容易設計和交付出先進的技術架構方案和方案落地規(guī)劃，但先進的技術架構不一定是業(yè)務核心訴求的最優(yōu)解。我們演進基礎架構主要遵循兩個思考點，作為背后的驅動力：
- 技術支撐業(yè)務快速發(fā)展，對研發(fā)效率和穩(wěn)定性的訴求，即技術要快又穩(wěn)
- 研發(fā)效率和穩(wěn)定性對基礎架構的要求
「領先業(yè)務“半步”，不過度演進」是我們對演進節(jié)奏的把控，從2019年以“多個大單體服務架構”演進到2023年的“多泳道架構”，每一次的架構升級都是做增量設計，對現(xiàn)有運行時環(huán)境、中間件進行改造，幾乎不會對業(yè)務研發(fā)產生影響，也不需要業(yè)務研發(fā)投入大量時間配合改造。同時，每一次架構升級都很好的解決了當期的核心痛點：
- 2020年，基礎架構由PHP單體大服務升級到泛服務化架構，解決了業(yè)務研發(fā)對服務化治理的訴求，也無需進行大規(guī)模的老代碼重構；
- 2021年，在微服務架構基礎上支持全鏈路灰度能力，支持全鏈路灰度高峰期發(fā)布，一個物理環(huán)境輕易就能快速構建出多個獨立的邏輯鏈路環(huán)境，解決了研發(fā)和測試同學當期的工作效率問題；
- 2023年，在全鏈路灰度架構基礎上對流量標識、網(wǎng)關、數(shù)據(jù)存儲等進行改造，演進到多泳道架構，單個泳道對應單個物理AZ，一個請求的后端事務處理盡可能在單泳道內閉環(huán)，支持AZ機房容災容錯能力。
圖片
依據(jù)實踐經(jīng)歷，有三個方面是我們格外注意的：
- 盡可能對上層服務、應用架構不侵入
- 盡可能不造成業(yè)務研發(fā)大面積的配合改造
- 團隊熟悉的技術
因為基礎技術架構本質是由一組技術規(guī)則構成，規(guī)則從流量調度、請求路由、服務調用、數(shù)據(jù)讀寫等多方面進行了約束，且不能被打破，它天生就造成對業(yè)務技術架構的侵入，影響了靈活性，所以好的基礎架構盡可能減少對上層應用的侵入是非常重要的；此外，選擇團隊和業(yè)務研發(fā)同學他們最熟悉的技術通常是最優(yōu)的選擇，不要過于追求先進技術。
我們早期的系統(tǒng)是由多個內部PHP服務（服務臃腫，單個core服務包含幾百個接口很常見）組成，內部服務之間主要通過域名+HTTP方式相互通訊，服務間通訊沒有標準的數(shù)據(jù)協(xié)議規(guī)范、缺乏基本的服務治理能力。隨著業(yè)務規(guī)模增長和系統(tǒng)整體復雜度上升，我們決定向微服務架構演進，就遇到了要么一刀切大規(guī)模改造、要么緩慢治理的選擇問題：
- 一刀切：采取成熟的開源SOA框架（像SpringCloud或dubbo），直接把我們的PHP服務按照SOA規(guī)范改造成標準SOA服務。這個思路的最大問題是影響面廣，涉及到每一個團隊，改造工作量巨大，改造周期會比較長，可能會影響正常業(yè)務需求的日常交付上線，對處于高速發(fā)展期的業(yè)務來說難以接受；
- semi-SOA：避免一刀切，研發(fā)可以根據(jù)自身情況按需擇時重構，先初步具備服務治理能力。
最終，我們選擇了semi-SOA的方案（一種類似于半服務化思路、內部我們稱呼為泛服務調用），通過semi-SOA讓新老PHP服務、以及新老Java服務之間可以方面的互通互聯(lián)，同時整體系統(tǒng)又具備服務化治理能力，最重要的是所有業(yè)務研發(fā)團隊不需要立即參入大規(guī)模改造，這種“過渡型技術方案”給研發(fā)團隊預留了充足的按需改造時間，有條件的業(yè)務研發(fā)團隊可以先行改造，去PHP化，新的Java服務與現(xiàn)存PHP服務之間又可以很好的兼容。
圖片
我們大約每間隔1年時間都會進行一輪基礎架構的演進迭代，一方面是為長期大方向做一些儲備，另一方面是僅解決短期即將遇見的需求問題，2023年進入多泳道架構（一種跨AZ的高可用架構），驅動我們做這件事情主要有兩個方面：
- 業(yè)務發(fā)展訴求，即是系統(tǒng)穩(wěn)定性要求，2022.4我們就發(fā)生過因底層硬件變更引發(fā)150臺機架宕機故障，我們業(yè)務系統(tǒng)癱瘓且無法恢復，只能等廠商修復；
- 業(yè)務對系統(tǒng)故障容忍度降低了，系統(tǒng)不可用導致的業(yè)務損失比較大了，需要我們考慮為這種低頻事件買一份“保險”，做更多的投入。
并未將基礎架構直接演進到同城雙活，主要是考慮成本，一方面IT資源成本，另一方面是研發(fā)改造成本；另外就是單AZ機房環(huán)境下系統(tǒng)穩(wěn)定性還有很多提升的空間，我們認為這樣的“保險”程度目前是最合宜的。
三、技術保障的取舍
圖片
做好技術保障，防范系統(tǒng)穩(wěn)定性風險的發(fā)生是技術治理過程中一個重要目標，過去4年時間里，我們的穩(wěn)定性保障經(jīng)歷了三個階段，每個階段都制定了差異化的核心建設，通過階段性的迭代達到目前的體系化，系統(tǒng)故障數(shù)量從階段一時期的不理想狀態(tài)慢慢穩(wěn)定下來，到目前達到了健康狀態(tài)。
階段一：活下來
早期階段，我們更重視基本能力的建設，也就是守住關鍵戰(zhàn)場的基本盤能穩(wěn)定性下來，早期的監(jiān)控告警平臺、限流降級工具、生產環(huán)境變更規(guī)范都是需要重視的戰(zhàn)場。
階段二：規(guī)范、工具建設
當整體穩(wěn)定下來后，所有工程師在日常系統(tǒng)變更、服務上線都有了穩(wěn)定性意識，大家都在按照統(tǒng)一的規(guī)范進行操作，遇到問題都會按照規(guī)范進行應急處理了。接下來階段二我們會更關注效率和精細化的提升，我們成立了全職NOC團隊專門對系統(tǒng)進行盯盤和檢測、第一時間啟動應急，也補齊了像容量壓測等工具平臺的建設，進行深度的業(yè)務服務鏈路風險的治理。這個階段，應急處理效率、故障止損時效都有了具體的提升。
階段三：體系化建設
最終，我們的焦點是如何保障長期不出故障，盡可能防范黑天鵝和灰犀牛事件的發(fā)生。這個時期，除了工具能力、規(guī)范體系的不斷完善外，會更加重視穩(wěn)定性保障項目的日常運營，一些簡單的事情會重復反復的去做，堅持高質量的去做（譬如：每天都會對當日發(fā)生的隱患事件進行復盤，渴望發(fā)生共性問題，從而反哺回進一步優(yōu)化工具和體系）
圖片
回顧我們整個穩(wěn)定性保障的經(jīng)歷，無論是早期的搭建工具能力、完善規(guī)范，還是中后期建制度和保障體系，都不是一帆風順，也經(jīng)常遇到因服務雪崩導致故障止血不及時、忘記設置告警導致不能早起發(fā)現(xiàn)問題、共性的隱患在服務鏈路上未治理徹底或重新滋生導致故障等等，我們總結有三個關鍵地方需要格外做好：
1）保持極大的耐心，持續(xù)的高質量做好日?！爸貜托浴钡氖虑椋┤珂溌贩盏氖崂砗椭卫砦覀儠g隔半年時間就會重復做一次，除了維護業(yè)務鏈路架構和理性外，也解決過去半年新引入的問題；在日常發(fā)生的穩(wěn)定性隱患事件（非故障或冒煙）后，也會在當日就閉環(huán)復盤，找出隱患發(fā)生的根因，舉一反三；
2）穩(wěn)定性保障最大的挑戰(zhàn)之一就是效率，長期始終如一的投入很多研發(fā)時間到穩(wěn)定性上是很難的，所以凡事能提升研發(fā)在穩(wěn)定性保障上的效率非常重要。模板告警是我們過去設計的一種智能告警的工具功能，它非常有用，我們將服務運行時狀態(tài)中通用的地方（譬如：服務某種類型的異常數(shù)量同環(huán)比波動超過30%）都支持了模板告警，無需研發(fā)主動配置告警，即節(jié)省了研發(fā)大量時間，也避免了研發(fā)漏配或錯配；
3）如何長期獲得一個好結果（不發(fā)生故障）是我們追求的終極目標，除了在技術上、人員素質上要持續(xù)提升外，我們認為有2個理念非常重要：
- 規(guī)范體系需要具備自我迭代能力，過去定義的規(guī)范不一定最適配當下，所以我們每次在事件復盤中都渴望發(fā)現(xiàn)一些整改代辦項，完善當前的規(guī)范體系；
- 不僅僅要做應急預案的技術功能性演練，其他任何預期性質的SOP都盡可能開展演練，把演練變成日常的一種習慣，這樣才能盡可能保證當發(fā)生非預期事件（故障、冒煙）時你的所有預期內的工具、SOP都能正常表現(xiàn)
穩(wěn)定性日常運營
圖片
最后想和大家聊一下「穩(wěn)定性日常運營」在我們的實踐中起到的巨大作用。
穩(wěn)定性規(guī)范和應急能力隨著規(guī)模增長、系統(tǒng)復雜度上升后是需要重新迭代的，迭代的方向和內容是依靠日常運營中不斷的收集和統(tǒng)計，譬如NOC團隊會收集每一天發(fā)生的所有隱患事件并給事件打上各種標簽，每個月都會分析它們，會嘗試發(fā)現(xiàn)是否有異常的標簽類型，并反饋給工具團隊或者SOP規(guī)范定義團隊進行優(yōu)化。
日常運營也有多種運營級別，當系統(tǒng)、團隊、日常趨勢狀態(tài)都比較平穩(wěn)的時候，運營級別是最低檔的，最低檔運營級別對投入的要求最小，當趨勢狀態(tài)糟糕時會調升運營級別，這是一種靈活的方式來平衡穩(wěn)定性保障與研發(fā)投入的做法，當然日常運營的方式方法非常多，這里不做詳細展開了。
總結下，日常運營可以幫助我們持續(xù)發(fā)現(xiàn)更多的瑕疵和漏洞，并反哺回規(guī)范機制與工具能力，運營內容涉及到規(guī)范、演練、技術治理、文化考試等多方面，它有效的防范了大家長期做一件事情的過程中容易導致的疏忽、犯錯風險。
四、IT成本如何管治
圖片
最近幾年，大家都在做降本增效，IT資源成本是大頭。我們過去2年把IT單均數(shù)值優(yōu)化下降了50%以上，主要有兩個原因：首先最重要是早期業(yè)務快速發(fā)展時期，我們對IT資源使用效率關注是不夠的，所以在調整使用方式、做一些基本的技術優(yōu)化后就有了明顯的提升；另外就是建立起資源使用規(guī)范（包括不限于：資源分攤、預算管理、成本可視化、成本異常檢測等等），杜絕不合理資源使用的產生。
其實，IT成本治理的關鍵點是IT資源是否做到了很高程度的科學使用，資源效率是不是達到了健康水平，唯省錢目的是不對的，這可能會對業(yè)務發(fā)展帶來損害，如果取得了IT成本治理結果而導致穩(wěn)定性風險或者研發(fā)效率大大降低，那這樣是不劃算的，大家根據(jù)自己公司業(yè)務發(fā)展情況平衡看待吧。
圖片
我們在IT成本治理過程中，也發(fā)現(xiàn)了很多有意思的地方經(jīng)驗技巧，比方說你可以聯(lián)合公司采購團隊去和供應商重新談判，嘗試爭取更優(yōu)惠的商務折扣，往往會立竿見影。
上圖，是我們進行IT成本治理優(yōu)化的方法矩陣，矩陣中的“降低價格/價”就非常管用，我們對不同業(yè)務模塊的資源采取合理的RI(1/3年)、Savingplan、Spot/Ondemand等購買方式可以極大降低資源購買成本；其余優(yōu)化方法措施不進行詳細介紹了，大家可以自行查閱。
作者介紹
陳永庭，貨拉拉 技術總監(jiān)。貨拉拉技術中心核心基礎設施部(CI)負責人，帶領CI團隊負責公司整體基礎架構的演進，填補、維護基礎技術能力（中間件、框架、工具）保障技術團隊的研發(fā)效率，負責全局穩(wěn)定性和技術保障、資源交付和IT成本治理優(yōu)化等主要工作。曾就職餓了么、騰訊、WebEx/Cisco，主要專注于中間件和基礎服務的研發(fā)、異地多活架構的設計與實施落地。（聯(lián)系郵箱：sam1.chen@huolala.cn）
本文題目：IT降本50%還賊穩(wěn)！百萬訂單規(guī)模系統(tǒng)的技術治理實踐
本文路徑：http://m.5511xx.com/article/cdghjhe.html
