一、FinOps平臺(tái)初期問題

新東方成立至今已有30年，但基于IT和運(yùn)維平臺(tái)的基礎(chǔ)設(shè)施建設(shè)，近些年才逐漸形成規(guī)模。

1.面臨困境

圖片

• 煙囪效應(yīng)：早期發(fā)展過程中，各個(gè)業(yè)務(wù)平臺(tái)都有專門的研發(fā)方向，比如服務(wù)器部門專攻服務(wù)研發(fā)，網(wǎng)絡(luò)部門專攻網(wǎng)絡(luò)研發(fā)，安全部門專攻安全研發(fā)。這種“各個(gè)團(tuán)隊(duì)深挖自己擅長領(lǐng)域”的研發(fā)模式，導(dǎo)致內(nèi)部系統(tǒng)煙囪林立，難以進(jìn)行數(shù)據(jù)互聯(lián)互通。
• 數(shù)據(jù)孤島：新業(yè)務(wù)新市場的拓展過程中各內(nèi)部系統(tǒng)沒法直接復(fù)用和迭代，產(chǎn)生的新數(shù)據(jù)無法與原有的數(shù)據(jù)互通，加劇了數(shù)據(jù)孤島的問題。
• 組織熵增：各個(gè)平臺(tái)功能單一化，平臺(tái)與平臺(tái)之間的協(xié)調(diào)配合、數(shù)據(jù)交互異?；靵y，隨著企業(yè)核心業(yè)務(wù)增長，卻帶來了效率低下的問題。

基于以上三方面問題，產(chǎn)生了建立統(tǒng)一化對(duì)外平臺(tái)的需求。

2.初期構(gòu)想

問題1：哪些獨(dú)立功能需要集成？

下圖展示了平臺(tái)初期的7項(xiàng)業(yè)務(wù)重點(diǎn)。

圖片

• 資源申請(qǐng)：這是開發(fā)平臺(tái)時(shí)設(shè)想的新功能，研發(fā)人員通過平臺(tái)自助申請(qǐng)資源，同時(shí)資源支持自動(dòng)納管。
• 信息檢索：當(dāng)同業(yè)務(wù)線的人員檢索服務(wù)器、PaaS類內(nèi)容等信息，可獲得精確數(shù)據(jù)。
• 流程操作：規(guī)劃流程模式，用于資源申請(qǐng)、業(yè)務(wù)流程創(chuàng)建。
• 業(yè)務(wù)上線：即大家熟知的CI/CD。
• 成本控制：將在后文詳述。
• 數(shù)據(jù)安全
• 高效穩(wěn)定

問題2：集成后如何方便地進(jìn)行資源成本分?jǐn)偅?/p>

圖片

根據(jù)上述概念，如何針對(duì)云教室、東方甄選、小課堂等應(yīng)用項(xiàng)目，進(jìn)行資源的成本分?jǐn)偰兀?/p>

第一，申請(qǐng)流程。目前已經(jīng)搭建起平臺(tái)，就通過云主機(jī)、云盤或數(shù)據(jù)庫資源等進(jìn)行申請(qǐng)。流程創(chuàng)建的同時(shí)，這些資源掛載到對(duì)應(yīng)的服務(wù)樹上，相當(dāng)于在數(shù)據(jù)庫層面進(jìn)行關(guān)聯(lián)。

第二，通過平臺(tái)分?jǐn)傎Y源成本。

平臺(tái)搭建前已有的數(shù)據(jù)，如何轉(zhuǎn)移到平臺(tái)呢？

• 資源獲?。何锢韺用?，通過數(shù)據(jù)納管腳本，將物理層的數(shù)據(jù)中心、機(jī)架、服務(wù)器的物理機(jī)，以及硬件配置納管；混合云層面，阿里云、騰訊云和微軟云等公有云，以及VMware的VSphere和OpenStack等私有云的數(shù)據(jù)，通過API進(jìn)行同步或官方SDK拉取。
• 資源位置：物理機(jī)是IDC，VSphere屬于私有云，微軟、阿里、騰訊屬于公有云。
• 資源類型：目前支持通過平臺(tái)（阿里ECS和RDS，騰訊CVM和CDB等），申請(qǐng)?jiān)浦鳈C(jī)、數(shù)據(jù)庫、對(duì)象存儲(chǔ)等資源類型。

圖片

Redis、ES、Kafka、RocketMQ等中間件的資源，用于實(shí)現(xiàn)緩存或服務(wù)隊(duì)列等輔助功能。

3.解決辦法——服務(wù)樹

如何將這些資源分配到各個(gè)業(yè)務(wù)線呢？這涉及到服務(wù)樹的概念（前文介紹業(yè)務(wù)的成本分?jǐn)倳r(shí)亦有提及）。服務(wù)樹與人力資源樹不同，人力資源樹更關(guān)注公司的部門關(guān)系和組織架構(gòu)，而服務(wù)樹更關(guān)注企業(yè)的業(yè)務(wù)應(yīng)用。

經(jīng)過長時(shí)間的整理工作，我們形成了新東方集團(tuán)的服務(wù)樹，共分為5個(gè)層級(jí)。

圖片

• 第一級(jí)-集團(tuán)：即新東方集團(tuán)，它是所有業(yè)務(wù)的根節(jié)點(diǎn)；
• 第二級(jí)-業(yè)務(wù)線：包含地方校、機(jī)構(gòu)和子公司等；
• 第三級(jí)-項(xiàng)目集：一類高度關(guān)聯(lián)項(xiàng)目的集合；
• 第四級(jí)-項(xiàng)目：各類業(yè)務(wù)研發(fā)的立項(xiàng)；
• 第五級(jí)-應(yīng)用：包含開發(fā)模塊、 App組件、各種微服務(wù)等內(nèi)容，這是服務(wù)樹的最小粒度。

4.通過服務(wù)樹關(guān)聯(lián)集成業(yè)務(wù)功能

圖片

根據(jù)上述5個(gè)層級(jí)，可以通過服務(wù)樹數(shù)據(jù)，關(guān)聯(lián)具體的應(yīng)用功能，并為用戶角色分配服務(wù)樹節(jié)點(diǎn)。同時(shí)，服務(wù)樹節(jié)點(diǎn)對(duì)應(yīng)服務(wù)API，通過賦予角色不同的action權(quán)限，達(dá)成集中授權(quán)的功能。這是服務(wù)樹結(jié)合應(yīng)用的案例之一。

二、數(shù)據(jù)和安全建設(shè)

1.案例：實(shí)時(shí)計(jì)算平臺(tái)

1）大數(shù)據(jù)實(shí)時(shí)計(jì)算架構(gòu)

圖片

第一個(gè)案例是數(shù)據(jù)平臺(tái)中比較重點(diǎn)的項(xiàng)目——實(shí)時(shí)計(jì)算平臺(tái)。實(shí)時(shí)計(jì)算，與在離線數(shù)據(jù)分析的概念相似。

如上圖所示，左邊是RDBMS和分布式數(shù)據(jù)庫，基于CDC進(jìn)行數(shù)據(jù)采集，中間是類似于Kafka的數(shù)據(jù)通道，右邊是一個(gè)存算分離的架構(gòu)、一個(gè)實(shí)時(shí)數(shù)倉，以及在離線計(jì)算的任務(wù)和存儲(chǔ)。最終，數(shù)據(jù)到達(dá)數(shù)據(jù)分析平臺(tái)，用于BI統(tǒng)計(jì)和計(jì)算。

我們負(fù)責(zé)研發(fā)實(shí)時(shí)計(jì)算平臺(tái)的中間部分，其功能包括SQL任務(wù)和JAR包任務(wù)。

2）上下游通過流程串聯(lián)

圖片

我們希望業(yè)務(wù)用戶進(jìn)入平臺(tái)之后，能夠以一種簡單的方式，發(fā)現(xiàn)、實(shí)時(shí)Job計(jì)算，故目前提供2種選擇：

• 第一種方式：將Java程序打包后，用提交Jar包任務(wù)來提供計(jì)算服務(wù)。由于大數(shù)據(jù)和數(shù)分Java工程師比較多，他們會(huì)寫基于Flink的Job；
• 第二種方式：直接在平臺(tái)的在線Web IDE中，用SQL語句寫DDL或DML語句，生成Source表或Sink表功能，用于處理實(shí)時(shí)計(jì)算的過程數(shù)據(jù)。這是整體的上下游關(guān)聯(lián)流程架構(gòu)，任務(wù)提交前通常由 DBA來審核。

3）數(shù)據(jù)處理能力升級(jí)-實(shí)時(shí)數(shù)據(jù)研發(fā)平臺(tái)

下圖呈現(xiàn)了實(shí)時(shí)計(jì)算平臺(tái)中，任務(wù)SQL語句生成的表結(jié)構(gòu)、Job實(shí)時(shí)任務(wù)的操作（可以進(jìn)行Job暫停、重啟、拉起、停止等操作，以及類似的模板功能等）、Source表和Sink表結(jié)構(gòu)等。

圖片

開發(fā)實(shí)時(shí)計(jì)算平臺(tái)的預(yù)想目標(biāo)是，建立一個(gè)自動(dòng)化的研發(fā)的數(shù)據(jù)模型，集成原有割裂的實(shí)時(shí)計(jì)算存儲(chǔ)和計(jì)算，通過服務(wù)樹與業(yè)務(wù)庫表關(guān)聯(lián)，提升整體研發(fā)效率。

2.案例：安全項(xiàng)目驅(qū)動(dòng)開發(fā)

第二個(gè)案例是安全類項(xiàng)目，我們?cè)鴧⑴c6項(xiàng)安全類研發(fā)項(xiàng)目。

圖片

• 紅藍(lán)對(duì)抗：并非內(nèi)部人員組成紅軍藍(lán)軍，而是邀請(qǐng)外部安全公司，進(jìn)行安全打擊測試。
• 滲透測試：基于單個(gè)項(xiàng)目，針對(duì)某些平臺(tái)進(jìn)行安全類檢測，用于輸出和修復(fù)未處理的漏洞、事件和風(fēng)險(xiǎn)。
• 敏感數(shù)據(jù)檢測：針對(duì)可能涉及到敏感數(shù)據(jù)的項(xiàng)目進(jìn)行檢測，比如用戶真實(shí)姓名、身份證號(hào)、電話號(hào)碼等等，利用定期掃描任務(wù)，通過敏感數(shù)據(jù)識(shí)別模板進(jìn)行識(shí)別，來協(xié)調(diào)開發(fā)人員對(duì)敏感數(shù)據(jù)進(jìn)行加密存儲(chǔ)和傳輸。
• 安全中心：內(nèi)部提供一些功能，比如說像安全管理、內(nèi)部政策法規(guī)類的平臺(tái)。

接下來我將重點(diǎn)說明后兩個(gè)項(xiàng)目：安全 APP合規(guī)平臺(tái)、內(nèi)部CA認(rèn)證。

1）案例：安全APP合規(guī)平臺(tái)

圖片

APP合規(guī)檢測，是針對(duì)新東方自研APP，從管理和技術(shù)兩方面，進(jìn)行安全合規(guī)檢測，以減少風(fēng)險(xiǎn)。我們對(duì)這些APP進(jìn)行安全左移的第三方檢測，并評(píng)分。如果未達(dá)到安全評(píng)分，比如檢測到安全風(fēng)險(xiǎn)或漏洞，安全團(tuán)隊(duì)會(huì)在平臺(tái)上提交APP漏洞，提示業(yè)務(wù)線安全加固，否則不能上架。

圖片

安全合規(guī)檢測項(xiàng)目對(duì)APP業(yè)務(wù)非常重要。針對(duì)東方甄選、托福等重點(diǎn)項(xiàng)目，我們會(huì)進(jìn)行APP合規(guī)檢測，并列出高危風(fēng)險(xiǎn)、低危風(fēng)險(xiǎn)等詳細(xì)信息。

2）案例：CA認(rèn)證中心

為什么要構(gòu)建內(nèi)部的CA中心？

平臺(tái)具有在線終端功能，在瀏覽器頁面通過調(diào)用web socket自動(dòng)登錄到服務(wù)器黑屏操作上（類似xshell和crt），自動(dòng)登錄需要進(jìn)行登錄認(rèn)證。

圖片

初期為了方便，使用了第一種方案：傳統(tǒng)的密碼認(rèn)證，但由于密碼非常容易拷貝和背誦，風(fēng)險(xiǎn)系數(shù)非常高。

所以改用第二種方案：公私鑰的密鑰對(duì)認(rèn)證。它解決了密碼易于拷貝和背誦的問題（公私鑰包括好幾百個(gè)字節(jié)，數(shù)據(jù)串很長，一般人難以背誦），但是這個(gè)方案忽略了一個(gè)問題——公私鑰依然是可以傳遞的。

后來我們調(diào)研了第三種方案：CA認(rèn)證，搭建了內(nèi)部CA認(rèn)證中心，實(shí)現(xiàn)了平臺(tái)端的三方認(rèn)證，即平臺(tái)-用戶-CA憑證。用戶操作具體頁面時(shí)，需要上傳CA憑證（內(nèi)含針對(duì)用戶的算法哈希值）。

CA認(rèn)證有效且通過用戶hash驗(yàn)證后，下一步需判斷CA憑證是否超期、與服務(wù)端憑證是否相符等，如有一項(xiàng)不滿足，則判定為非法請(qǐng)求，拒絕后續(xù)操作。

圖片

上圖為我們開發(fā)的CA認(rèn)證流程圖。調(diào)研 CA認(rèn)證時(shí)，曾考慮過采購商業(yè)版本的，但很多安全公司尚未具備CA認(rèn)證的完整流程，所以只能自行搭建。

CA認(rèn)證的詳細(xì)流程：

• 第一步：用戶登錄之后，操作CA關(guān)聯(lián)的應(yīng)用時(shí)，判斷用戶憑證是否處于認(rèn)證有效期內(nèi)，有效期內(nèi)（例如7天）則不用重復(fù)認(rèn)證，否則需要重新認(rèn)證。這種邏輯對(duì)關(guān)聯(lián)的功能模塊非常友好，用戶不必反復(fù)登錄認(rèn)證，體驗(yàn)類似SSO。
• 第二步：判斷服務(wù)端是否真實(shí)存在認(rèn)證證書，如認(rèn)證證書不存在，用戶需申請(qǐng)并重新下載。
• 第三步：判斷證書在服務(wù)端是否已經(jīng)被吊銷，如被吊銷或刪除，需重新認(rèn)證。

圖片

完成以上三步，用戶即通過認(rèn)證，可以進(jìn)行下一步工作。由此可以理解為，我們將CA認(rèn)證功能集成于一個(gè)請(qǐng)求的中間件。

三、成本中心一體化

1.FinOps的概念和本質(zhì)

圖片

FinOps基金會(huì)對(duì)FinOps的定義是，讓研發(fā)、財(cái)務(wù)、業(yè)務(wù)等各個(gè)團(tuán)隊(duì)共同配合，從數(shù)據(jù)和資源層面，放大業(yè)務(wù)利用價(jià)值，實(shí)現(xiàn)降本增效。

圖片

上圖是我們目前的FinOps框架圖，上面部分包括多云賬單管理、預(yù)算管理、成本優(yōu)化分析，報(bào)警等迭代功能；中間部分是云單元管理、云CMDB、權(quán)限管理等平臺(tái)；下面部分是使用的混合公有云的基礎(chǔ)設(shè)施（阿里、騰訊、微軟）。

2.FinOps一體化平臺(tái)組成

圖片

DevOps平臺(tái)和FinOps平臺(tái)，通過服務(wù)樹（節(jié)點(diǎn)）進(jìn)行連接，由此判斷服務(wù)樹內(nèi)存在哪些應(yīng)用、資源，這些資源關(guān)聯(lián)哪些賬單，甚至細(xì)分到具體服務(wù)器的粒度層面。

3.FinOps云成本優(yōu)化業(yè)務(wù)組成

圖片

以上是業(yè)務(wù)圖，上方是云課堂、東方甄選類似的業(yè)務(wù)應(yīng)用，我們?yōu)槠涮峁﹫?bào)表和業(yè)務(wù)賬單；中間部分是成本中心和運(yùn)維門戶；下方是依賴，使用公有云官方的API，私有云就是各個(gè)廠商（比如VMware、OpenStack等）提供的SDK組件。

4.案例

1）案例：FinOps月賬單

圖片

上圖是項(xiàng)目月度賬單報(bào)表（已脫敏），包括現(xiàn)金賬單和攤銷賬單。

• 現(xiàn)金賬單：企業(yè)單位實(shí)際支出費(fèi)用，財(cái)務(wù)與商務(wù)比較關(guān)心這部分內(nèi)容。
• 攤銷賬單：多租戶使用、不方便直接生成賬單的部分，比如MySQL、Redis或存儲(chǔ)，就按照主機(jī)使用率百分比，將使用支出分散到各個(gè)業(yè)務(wù)線上，以便業(yè)務(wù)通過使用率和攤銷情況進(jìn)行對(duì)賬。

2）案例：阿里云RDS報(bào)表

圖片

如上圖所示，這份阿里云RDS報(bào)表（通過阿里公有云API獲?。┌瑤讉€(gè)重要指標(biāo)，比如涉及服務(wù)器的高開支項(xiàng)目集中于哪些部分，哪些是實(shí)例，實(shí)例規(guī)格配置如何（比如2C4G、4C8G等），實(shí)例規(guī)格花銷如何，花銷分?jǐn)倢?duì)應(yīng)項(xiàng)目的具體數(shù)目。

3）案例：移課通報(bào)表賬單

圖片

由于涉及課程的營銷推廣，所以新東方具有客服業(yè)務(wù)，分為短信和會(huì)話兩種套餐。

新東方具有多個(gè)子公司和地方校，各個(gè)學(xué)校的通信費(fèi)用、使用個(gè)數(shù)和開銷構(gòu)成了其套餐費(fèi)用。我們重點(diǎn)關(guān)注移課通賬單開銷，使用逐步優(yōu)化的FinOps分賬算法，形成各地方校和子公司的賬單優(yōu)化閉環(huán)。

5.FinOps成本優(yōu)化閉環(huán)

圖片

賬單閉環(huán)優(yōu)化的邏輯如上圖。

• 付費(fèi)合理性預(yù)測：基于IT賬單，判斷目前消費(fèi)環(huán)節(jié)的有效性、合理性，是否符合預(yù)期，是否存在超預(yù)算的必要支出。
• 降本節(jié)約性建議：基于合理性預(yù)測，結(jié)合算法檢查付費(fèi)方式（RDS 按月/按量、移課通 套餐一/套餐二）在不影響業(yè)務(wù)的前提下，選擇更有助于優(yōu)化成本的付費(fèi)方式。
• 成本結(jié)果集觀測：基于降本節(jié)約性建議，優(yōu)化付費(fèi)方式，生成業(yè)務(wù)月賬單現(xiàn)金成本的結(jié)果集，實(shí)現(xiàn)成本支出的可觀測性，作為預(yù)算參考。

具備預(yù)算參考后，需要基于生成的結(jié)果集賬單，再次判斷合理性預(yù)算，整體形成云成本優(yōu)化的閉環(huán)。

1）案例：業(yè)務(wù)線月度費(fèi)用報(bào)表-費(fèi)用預(yù)算和最終賬單參考

圖片

上圖是費(fèi)用預(yù)算和最終賬單的參考（已脫敏），內(nèi)容包含具體日期、負(fù)責(zé)人部分花銷、各項(xiàng)目和主機(jī)的分?jǐn)傎M(fèi)用。云成本方面，內(nèi)容則包括涉及的公有云類型，比如阿里 ECS、RDS、CDN的詳細(xì)賬單，以及服務(wù)器運(yùn)行時(shí)長等。

2）案例：云實(shí)例規(guī)格配置管理

圖片

因?yàn)椴煌浦鳈C(jī)的規(guī)格配置有多個(gè)版本，一條配置可能包含幾十條規(guī)格名稱。用戶在平臺(tái)申請(qǐng)?jiān)浦鳈C(jī)或RDS數(shù)據(jù)庫時(shí)，可能面對(duì)上千條規(guī)格配置，導(dǎo)致選擇困難。

基于以上問題，我們?cè)O(shè)計(jì)了云實(shí)例規(guī)格的收斂方案，通過資源實(shí)例配置管理，進(jìn)行自定義規(guī)格列表，同時(shí)支持配置優(yōu)先級(jí)。處理人為錯(cuò)選或配置冗余的情況，優(yōu)先提供更具性價(jià)比、目前線上應(yīng)用更多的實(shí)例配置。

由此，提供給用戶幾個(gè)不同配置的定制化選項(xiàng)，并且使用人性化規(guī)格名稱，用戶可以根據(jù)需求選擇，既節(jié)約時(shí)間，又避免了晦澀難懂的規(guī)格名稱混淆用戶選擇。

3）案例：閑置率報(bào)表及成本黑名單

圖片

2021年頒布的雙減政策對(duì)教育業(yè)務(wù)打擊很大，各大公司均收緊業(yè)務(wù)、裁員降本。以往未曾注意的資源浪費(fèi)問題，如今越發(fā)凸顯，加之裁撤業(yè)務(wù)和項(xiàng)目，作為運(yùn)維重要開銷的云成本問題較為棘手。

所以，我們利用長期運(yùn)行但資源利用率閑置的主機(jī)，額外采集系統(tǒng)監(jiān)控?cái)?shù)據(jù)，列出由高到低排名前五的業(yè)務(wù)線黑名單，向每條業(yè)務(wù)線的負(fù)責(zé)人發(fā)送郵件報(bào)表，敦促業(yè)務(wù)負(fù)責(zé)人盡快處理。處理方式推薦以下三種：

• 退租：即機(jī)器無人使用、業(yè)務(wù)無人接手；
• 混布：CPU密集但內(nèi)存消耗少的服務(wù)，可以與內(nèi)存密集但CPU消耗少的服務(wù)進(jìn)行混布，提高資源利用率；
• 遷移：將閑置資源轉(zhuǎn)移給其他業(yè)務(wù)，變更機(jī)器所屬服務(wù)樹，盤活閑置資源。關(guān)于閑置率，并非關(guān)注節(jié)約多少成本，而是關(guān)注每種資源都實(shí)現(xiàn)其應(yīng)用價(jià)值。

6.優(yōu)化步驟與成本考核

圖片

前文提到，根據(jù)業(yè)務(wù)成本分?jǐn)偨Y(jié)果，統(tǒng)計(jì)并處理閑置率主機(jī)，優(yōu)化云資源規(guī)格的優(yōu)先級(jí)、包年或流量套餐選擇。最終，結(jié)合業(yè)務(wù)線成本輸出，形成一種考核模式，目的是提高利用率，確保各個(gè)業(yè)務(wù)線ROI處于較高的水平。

1）案例：年度IT各類費(fèi)用趨勢

圖片

通過FinOps優(yōu)化成本后，整體開銷的趨勢走向如上圖（已脫敏）。相比以往總體成本最高的時(shí)期，當(dāng)前成本下降近一半，這是FinOps平臺(tái)最顯著的效果。

四、經(jīng)驗(yàn)沉淀

1.降本增效的經(jīng)驗(yàn)：聚焦和成本控制

• 業(yè)務(wù)板塊聚焦：和同行業(yè)公司一樣，修剪業(yè)務(wù)線，甚至大比例裁員?？车粢郧暗倪吘墭I(yè)務(wù)，將更多的精力、資源、開支投入核心的業(yè)務(wù)板塊，和新興的、著力發(fā)展的業(yè)務(wù)板塊，比如東方甄選。
• 精簡申請(qǐng)流程：精簡過往流程中的郵件往來、人為復(fù)雜操作或冗余選項(xiàng)等配置，提高工單流轉(zhuǎn)效率。
• 上云及容器化：與傳統(tǒng)的IDC服務(wù)器相比，上云的優(yōu)勢是無需關(guān)心物理服務(wù)器的采購環(huán)節(jié)、機(jī)架費(fèi)用、電力費(fèi)用、帶寬費(fèi)用、異地多活架構(gòu)方案等，且能夠提供更好的伸縮性，支持動(dòng)態(tài)擴(kuò)容、多副本和快照，具有自動(dòng)災(zāi)難恢復(fù)、故障轉(zhuǎn)移，避免供應(yīng)商綁定等優(yōu)勢，所以整體來說是有降本和容災(zāi)的好處。
• 閑置資源回收
• 超額資源審核：用戶申請(qǐng)資源時(shí)，無論是云主機(jī)、PaaS資源，還是對(duì)象存儲(chǔ)類資源，在超過一定金額的話，會(huì)交由云管理員進(jìn)行審核，這對(duì)于大環(huán)境非常不好情況下，是一個(gè)非常重要的成本卡口。

優(yōu)化的最終結(jié)果是，集團(tuán)整體降本百分比達(dá)30%，增效40%，實(shí)現(xiàn)業(yè)務(wù)在成本降低的情況下加速投產(chǎn)。

2.技術(shù)提效思維

• 復(fù)制牛人經(jīng)驗(yàn)，提高作戰(zhàn)能力：避免重復(fù)造輪子；
• 核心模塊抽象，高內(nèi)聚低耦合：提高代碼抽象度，實(shí)現(xiàn)各研發(fā)模塊能力通用；
• 架構(gòu)微服務(wù)化，增加通用接口：使用網(wǎng)關(guān)或API接口封裝，實(shí)現(xiàn)通用網(wǎng)關(guān)的接口路由；
• 文檔定期沉淀，鼓勵(lì)知識(shí)共享：在企業(yè)內(nèi)部，通過內(nèi)部的文檔庫進(jìn)行知識(shí)沉淀；在企業(yè)外部，通過公眾號(hào)和Gdevops等大會(huì)進(jìn)行技術(shù)分享和溝通討論。

3.運(yùn)維業(yè)務(wù)研發(fā)精進(jìn)過程

• 目標(biāo)定義：溝通需求目標(biāo)、業(yè)務(wù)重點(diǎn)，了解現(xiàn)有資源，熟悉現(xiàn)有運(yùn)維流程，構(gòu)建基本的研發(fā)架構(gòu)（或體系）思路。
• 需求分析：明確需求方向，確認(rèn)優(yōu)先級(jí)和需求難度，規(guī)劃實(shí)施方針。
• 目標(biāo)拆解：基于確定的方向，按照難度和優(yōu)先級(jí)，拆解細(xì)化需求，安排并推進(jìn)團(tuán)隊(duì)的下一步開發(fā)工作。
• 階段實(shí)現(xiàn)：根據(jù)需求優(yōu)先級(jí)和產(chǎn)品目標(biāo)，為用戶提供階段性產(chǎn)出，檢驗(yàn)產(chǎn)品與用戶的目標(biāo)達(dá)成率。

Q&A

Q1：新東方戰(zhàn)略主營業(yè)務(wù)條線推進(jìn)降本增效，但I(xiàn)T費(fèi)用屬于IT基礎(chǔ)資源，業(yè)務(wù)其實(shí)無感知，請(qǐng)問IT和業(yè)務(wù)之間如何配合，促進(jìn)降本增效？

A1：服務(wù)樹里包括項(xiàng)目、應(yīng)用等維度，每個(gè)項(xiàng)目都具備對(duì)應(yīng)的研發(fā)負(fù)責(zé)人、項(xiàng)目負(fù)責(zé)人，項(xiàng)目與服務(wù)樹相關(guān)聯(lián)，服務(wù)樹同時(shí)與各項(xiàng)IT資源（比如云主機(jī)、PaaS等）關(guān)聯(lián)，所產(chǎn)生的費(fèi)用將聯(lián)動(dòng)到FinOps成本中心。由此，建立起IT成本與人的聯(lián)系。

我們可以將IT資源涉及到的各種成本，通過郵件發(fā)送給各個(gè)業(yè)務(wù)線的負(fù)責(zé)人，形成了降本增效的提醒環(huán)節(jié)。

作者介紹

鐘仕駿，首師大畢業(yè)，現(xiàn)就職于新東方教育，曾就職于搜狐、快手。搜狐大廈資深老煙民，曾在搜狗、搜狐視頻移動(dòng)端NO工作過，負(fù)責(zé)運(yùn)維及后臺(tái)數(shù)據(jù)研發(fā)。快手第一位SRE，曾負(fù)責(zé)快手「所有」運(yùn)維基礎(chǔ)化建設(shè)，規(guī)劃并參與了2020年春晚紅包項(xiàng)目?，F(xiàn)任新東方教育運(yùn)維研發(fā)高級(jí)經(jīng)理，負(fù)責(zé)企業(yè)基礎(chǔ)架構(gòu)標(biāo)準(zhǔn)化體系研究、自動(dòng)化平臺(tái)研發(fā)等。