做了快十年DevOps我發(fā)現(xiàn)自己有個(gè)職業(yè)病遇到重復(fù)性人工流程第一反應(yīng)不是怎么優(yōu)化而是“這流程要是能變成一條流水線就好了”。這個(gè)職業(yè)病在上一家公司被徹底放大——我們是一個(gè)技術(shù)驅(qū)動(dòng)的媒體團(tuán)隊(duì)每天要往官網(wǎng)、公眾號(hào)、知乎、頭條、行業(yè)媒體等各種渠道分發(fā)內(nèi)容高峰期一天要發(fā)二十篇以上而整套流程居然還停留在Excel表加聊天群的人工編排時(shí)代。運(yùn)營(yíng)同事每天早上第一件事就是打開(kāi)幾十個(gè)后臺(tái)粘文案、傳封面、設(shè)定時(shí)、再重復(fù)一遍晚上還要調(diào)鬧鐘爬起來(lái)看定時(shí)發(fā)布有沒(méi)有翻車。這種狀態(tài)明擺著就是一套沒(méi)有CI/CD的“發(fā)布系統(tǒng)”。后來(lái)我牽頭把宣發(fā)鏈路徹底重構(gòu)了一遍做完以后回頭看這種工作方式本質(zhì)上是把媒體發(fā)布當(dāng)成了軟件部署來(lái)治理稿件是版本渠道是環(huán)境發(fā)稿動(dòng)作是流水線任務(wù)發(fā)布后的反饋是監(jiān)控?cái)?shù)據(jù)。這篇文章就聊聊我們?cè)趺从肈evOps的思路把這套流程做出來(lái)包含整體架構(gòu)、關(guān)鍵代碼實(shí)現(xiàn)、質(zhì)量門禁設(shè)計(jì)和避坑清單適合正在被手動(dòng)發(fā)稿折磨的內(nèi)容/市場(chǎng)同學(xué)也適合想幫團(tuán)隊(duì)寫自動(dòng)化工具但不知道從哪下手的工程師。1. 把宣發(fā)當(dāng)“發(fā)布”而不是“發(fā)稿”1.1 手動(dòng)發(fā)稿的真實(shí)成本先說(shuō)說(shuō)最原始的痛點(diǎn)。很多團(tuán)隊(duì)會(huì)覺(jué)得“不就發(fā)個(gè)稿嗎”只有真正干過(guò)才知道手動(dòng)發(fā)稿的隱性成本高得嚇人。我們當(dāng)時(shí)的流程是作者寫完稿丟進(jìn)共享文檔校對(duì)改完再導(dǎo)出成Word或Markdown市場(chǎng)同學(xué)拿去復(fù)制到官網(wǎng)CMS里排版再?gòu)?fù)制到公眾號(hào)后臺(tái)設(shè)置封面和摘要再?gòu)?fù)制到頭條、百家號(hào)、知乎等等。每多一個(gè)渠道就多一次重復(fù)勞動(dòng)也多個(gè)一次出錯(cuò)的概率。渠道一多“已發(fā)/未發(fā)/改過(guò)/待撤”完全靠Excel打勾版本永遠(yuǎn)對(duì)不上。后臺(tái)字段還不一樣有的要封面圖比例5:2有的要16:9有的限制摘要字?jǐn)?shù)稍不注意就會(huì)提交失敗然后就卡在那里等人救援。這些看起來(lái)都是小事但出現(xiàn)在發(fā)布高峰期就是大事故。我記得有次晚上十點(diǎn)要發(fā)一篇行業(yè)稿運(yùn)營(yíng)在六個(gè)平臺(tái)都設(shè)好了定時(shí)結(jié)果第二天早上發(fā)現(xiàn)其中一個(gè)平臺(tái)因?yàn)榉饷鎴D被平臺(tái)壓縮后文字截?cái)嘈枰匦滦薷牡渌脚_(tái)早就發(fā)出去了。最后只能緊急撤稿重發(fā)好不容易攢的曝光窗口全浪費(fèi)了。這種問(wèn)題技術(shù)上一點(diǎn)不復(fù)雜根因是人工操作的隨機(jī)性太大缺少自動(dòng)化校驗(yàn)和統(tǒng)一編排。另外一個(gè)經(jīng)常被忽略的是審批鏈。廣告法、素材版權(quán)、內(nèi)容合規(guī)這些在宣發(fā)場(chǎng)景里是硬要求。但當(dāng)時(shí)的審批記錄散落在聊天記錄里有人口頭說(shuō)“沒(méi)問(wèn)題”有人點(diǎn)贊就算通過(guò)出了事根本追不到誰(shuí)拍的板。這些都是做軟件交付時(shí)早就解決過(guò)的問(wèn)題——版本、審批、審計(jì)軌跡、回滾DevOps體系里全是現(xiàn)成的方案只是沒(méi)人往發(fā)稿這件事上想。1.2 為什么DevOps正好能解決這些問(wèn)題DevOps解決的是軟件從代碼到運(yùn)行環(huán)境的交付問(wèn)題。傳統(tǒng)發(fā)布依賴運(yùn)維手工操作DevOps則把構(gòu)建、測(cè)試、部署、監(jiān)控全部流水線化讓每一次變更都可追溯、可驗(yàn)證、可回滾。媒體發(fā)布本質(zhì)上是一樣的內(nèi)容從作者手里產(chǎn)生經(jīng)過(guò)校驗(yàn)、審批、渲染成不同渠道需要的格式最終部署到各個(gè)媒體平臺(tái)部署完成后還要持續(xù)觀測(cè)曝光情況。這套類比不是硬蹭概念。我們可以把每個(gè)環(huán)節(jié)對(duì)應(yīng)起來(lái)理解稿件倉(cāng)庫(kù)相當(dāng)于代碼倉(cāng)庫(kù)用來(lái)管理內(nèi)容版本和變更記錄。渠道模板相當(dāng)于構(gòu)建產(chǎn)物同一個(gè)源稿渲染成網(wǎng)頁(yè)版、公眾號(hào)版、頭條版。人工審批相當(dāng)于測(cè)試環(huán)境里的QA門禁不通過(guò)就不允許進(jìn)入發(fā)布階段。定時(shí)發(fā)布相當(dāng)于定時(shí)任務(wù)部署灰度試發(fā)相當(dāng)于金絲雀發(fā)布。發(fā)布后的數(shù)據(jù)監(jiān)測(cè)相當(dāng)于線上監(jiān)控告警異常流量和鏈接失效就是P0故障。這樣一映射很多成熟的工具和流程就能直接復(fù)用。第一個(gè)明顯收益是效率我們?cè)瓉?lái)發(fā)一個(gè)渠道平均要2分鐘加上排版和檢查一篇稿發(fā)全渠道要40分鐘到1小時(shí)改造后從代碼提交到全渠道發(fā)布成功批量任務(wù)平均只需要10分鐘人工只是做審批和異常確認(rèn)。第二個(gè)收益是確定性發(fā)布狀態(tài)不再是“我覺(jué)得發(fā)出去了”而是流水線里的明確狀態(tài)失敗在哪一步、重試多少次全部有日志可查。第三個(gè)收益是組織協(xié)作方式的變化——大家不用再天天追問(wèn)“發(fā)了沒(méi)”而是像看CI狀態(tài)一樣看發(fā)布進(jìn)度。當(dāng)然這條路不是沒(méi)有坑。我剛提出想法時(shí)很多人第一反應(yīng)是“我們又不是科技公司搞這么復(fù)雜沒(méi)必要”。實(shí)際落地后我才發(fā)現(xiàn)真正的復(fù)雜度不在于技術(shù)而在于怎么把非技術(shù)角色的習(xí)慣融入一套工程化流程中。后面的章節(jié)會(huì)重點(diǎn)展開(kāi)。2. 流水線整體設(shè)計(jì)從素材提交到發(fā)布反饋2.1 一條標(biāo)準(zhǔn)宣發(fā)流水線應(yīng)該長(zhǎng)什么樣我們最后落地的流水線分為六個(gè)階段校驗(yàn)、構(gòu)建、預(yù)覽、審批、發(fā)布、驗(yàn)證。這六個(gè)階段和軟件交付流水線幾乎一一對(duì)應(yīng)每個(gè)階段有明確的產(chǎn)物和退出條件。校驗(yàn)階段負(fù)責(zé)對(duì)稿件本身做靜態(tài)檢查包括Markdown格式、錯(cuò)別字、鏈接可用性、圖片尺寸、渠道字段完整性。構(gòu)建階段把一份源稿渲染成各個(gè)渠道需要的HTML、Markdown或JSON格式并生成渠道對(duì)應(yīng)的發(fā)布參數(shù)。預(yù)覽階段生成一個(gè)可視化的預(yù)覽頁(yè)面供作者、編輯和市場(chǎng)同學(xué)在瀏覽器里確認(rèn)而不是靠腦補(bǔ)“粘貼之后長(zhǎng)什么樣”。審批階段設(shè)置必要的checklist只有指定角色點(diǎn)通過(guò)任務(wù)才會(huì)繼續(xù)。發(fā)布階段按照配置的渠道列表和發(fā)布方式執(zhí)行推送支持定時(shí)、分批和灰度。驗(yàn)證階段則是發(fā)布后自動(dòng)檢查鏈接是否可訪問(wèn)、實(shí)際頁(yè)面內(nèi)容是否正常、返回碼是否符合預(yù)期并把結(jié)果匯總回流水線。這六個(gè)階段看起來(lái)簡(jiǎn)單但真正落地時(shí)需要解決兩個(gè)前置問(wèn)題一是內(nèi)容如何入庫(kù)二是發(fā)布配置如何管理。我們把稿件統(tǒng)一收到Git倉(cāng)庫(kù)用Markdown寫在content/articles/下封面圖和素材圖統(tǒng)一放在assets/images/下發(fā)布渠道和模板配置則放到config/channels.yaml里。這樣內(nèi)容也能享受到代碼管理的所有好處提交記錄、分支評(píng)審、標(biāo)簽版本、回滾。下面是一個(gè)簡(jiǎn)化后的倉(cāng)庫(kù)結(jié)構(gòu)我們實(shí)際項(xiàng)目基本就是這個(gè)形態(tài)content/ articles/ 2024/Q3-industry-trend.md ai-series/01-intro.md assets/ images/ cover-16x9.png qr-code.png config/ channels.yaml approval-matrix.yaml scripts/ validate.sh build.py publish.py verify.py用Git管理內(nèi)容還有個(gè)隱藏收益評(píng)審記錄是自然生成的。作者發(fā)起Merge Request編輯在MR里逐行評(píng)論修改歷史留痕再也不用“把第五版發(fā)我一下”。2.2 選型在現(xiàn)有工具上改而不是從零造輪子剛開(kāi)始考慮是要自建一套系統(tǒng)還是用現(xiàn)成的CI/CD工具。我們團(tuán)隊(duì)有兩位后端同學(xué)自建當(dāng)然能做但仔細(xì)一評(píng)估發(fā)現(xiàn)完全沒(méi)必要。CI/CD工具本身已經(jīng)把最難的調(diào)度、重試、權(quán)限、日志、狀態(tài)機(jī)都解決了。我們用的是GitLab CI它天然支持分支、MR、Tag、受保護(hù)環(huán)境protected environment和Manual Job正好對(duì)應(yīng)用來(lái)治理稿件提交、內(nèi)容審批和發(fā)布授權(quán)。Jenkins也能做但插件和權(quán)限模型要額外折騰GitHub Actions也可以只是如果團(tuán)隊(duì)已經(jīng)用GitLab管理代碼直接用現(xiàn)有平臺(tái)最省事。選型上我的建議是不要因?yàn)椤鞍l(fā)稿工具”這個(gè)標(biāo)簽就去找一堆Martech工具優(yōu)先評(píng)估團(tuán)隊(duì)已經(jīng)有的研發(fā)基礎(chǔ)設(shè)施。復(fù)用GitLab CI能省掉服務(wù)部署、賬號(hào)體系、權(quán)限模型、日志采集這一整套麻煩。只有一種情況值得自建——渠道非常多且每個(gè)渠道都有復(fù)雜的自定義策略時(shí)才考慮用獨(dú)立的任務(wù)編排器比如內(nèi)部輕量worker加消息隊(duì)列但這也應(yīng)該掛在CI工具后面而不是替代CI工具。2.3 分支策略和發(fā)布配置管理分支策略沿用常規(guī)開(kāi)發(fā)流程main分支存放已審核通過(guò)的內(nèi)容基線作者從main拉出feature/xxx分支寫稿完成后提MR給編輯和市場(chǎng)負(fù)責(zé)人審閱。審閱通過(guò)并合并后如果再需要發(fā)一個(gè)批次的稿就打一個(gè)tag格式是v1.2.0對(duì)應(yīng)“第2周的第三批發(fā)稿”。這個(gè)分支策略最大的好處是讓“發(fā)布批次”變得具體。發(fā)布一個(gè)批次不再是人肉記“這些稿今天要發(fā)”而是Git里一個(gè)明確的tag。流水線拿到tag后才知道該構(gòu)建哪些內(nèi)容也能記錄下這次發(fā)布對(duì)應(yīng)的代碼版本后續(xù)出了問(wèn)題直接回滾到上一個(gè)tag。發(fā)布渠道配置用YAML管理這里有一個(gè)關(guān)鍵設(shè)計(jì)每個(gè)渠道都要有獨(dú)立的審批級(jí)別和發(fā)布時(shí)間窗口。比如官網(wǎng)允許工作時(shí)間隨時(shí)發(fā)公眾號(hào)因?yàn)橐惶熘荒苋喊l(fā)一次必須設(shè)置最晚提交時(shí)間郵件渠道涉及大批用戶觸達(dá)必須要有市場(chǎng)負(fù)責(zé)人和合規(guī)審核雙重審批。配置大致長(zhǎng)這樣channels: official_site: type: cms api: https://cms.internal/v2/articles publish_window: 09:00-23:00 approvals: - role: content_owner wechat_official: type: wechat app_id: wx123456 publish_window: 09:00-20:00 max_articles_per_day: 1 approvals: - role: content_owner - role: legal_reviewer email_digest: type: email_api template: weekly-digest.html publish_window: 10:00-18:00 approvals: - role: marketing_owner - role: legal_reviewer渠道配置獨(dú)立后新增一個(gè)渠道只需要加一段配置和一個(gè)適配器代碼完全不用改流水線主體。這也是過(guò)程中最值得的一筆投入后面半年內(nèi)我們新增了4個(gè)發(fā)布渠道改的全部是配置文件主流程一行沒(méi)動(dòng)。2.4 角色權(quán)限與審批編排很多團(tuán)隊(duì)做自動(dòng)化時(shí)第一反應(yīng)是“把人都去掉”實(shí)際做出來(lái)往往會(huì)反彈。宣發(fā)場(chǎng)景里人工審批不是負(fù)擔(dān)而是風(fēng)險(xiǎn)控制的一部分。我們保留審批但把審批過(guò)程變成流水線的一個(gè)顯式節(jié)點(diǎn)。角色分四類內(nèi)容作者、內(nèi)容編輯/校對(duì)、市場(chǎng)負(fù)責(zé)人、合規(guī)審核。每個(gè)角色在審批環(huán)節(jié)看到的上下文完全不一樣作者只確認(rèn)稿子是不是最終版編輯確認(rèn)文字和素材市場(chǎng)確認(rèn)渠道策略合規(guī)確認(rèn)廣告法詞條。用一個(gè)矩陣表可以描述這組關(guān)系角色可操作內(nèi)容審批范圍作者提交/修改稿件不參與審批編輯合并MR修改稿件內(nèi)容質(zhì)量、格式、圖片市場(chǎng)負(fù)責(zé)人配置渠道和發(fā)布時(shí)間選稿策略、渠道覆蓋合規(guī)審核只做checklist確認(rèn)禁用詞、素材授權(quán)、引用來(lái)源審批動(dòng)作就兩種通過(guò)或者駁回。駁回時(shí)必須在流水線里填寫原因系統(tǒng)自動(dòng)創(chuàng)建一條修改任務(wù)并通知作者。因?yàn)閷徟涗浐桶l(fā)布記錄都沉淀在流水線日志里所以事后審計(jì)不再需要翻聊天記錄。這里有個(gè)小教訓(xùn)審批節(jié)點(diǎn)不要設(shè)置太多層級(jí)。我們最初設(shè)置了六類審批人結(jié)果一個(gè)稿子要等四五個(gè)小時(shí)后才有人點(diǎn)按鈕發(fā)布延遲比手動(dòng)時(shí)代還嚴(yán)重。后來(lái)壓縮到最多兩道強(qiáng)制審批其他環(huán)節(jié)只抄送不阻塞流程立刻順暢了。3. 實(shí)操?gòu)奶峤桓寮桨l(fā)布成功的完整實(shí)現(xiàn)3.1 把稿件當(dāng)成代碼管起來(lái)稿件進(jìn)入倉(cāng)庫(kù)后所有撰寫、修訂、評(píng)審都在Git里完成。我們約定的提交信息格式是類型加內(nèi)容描述例如docs: 新增Q3行業(yè)趨勢(shì)稿發(fā)布至官網(wǎng)/公眾號(hào)/頭條 fix: 修正Q3趨勢(shì)稿中的行業(yè)數(shù)據(jù)來(lái)源這個(gè)格式無(wú)所謂標(biāo)準(zhǔn)關(guān)鍵是讓作者養(yǎng)成提交Note的習(xí)慣。發(fā)布后再回看每個(gè)渠道的每個(gè)內(nèi)容版本都能定位到具體提交和具體MR再配合流水線的job日志基本可以回答“這個(gè)頁(yè)面上的這句話是誰(shuí)在什么時(shí)候改的”這類問(wèn)題。Markdown是稿件的最佳載體因?yàn)榇蟛糠智蓝寄軓腗arkdown生成對(duì)應(yīng)的樣式。少數(shù)渠道對(duì)排版要求高比如官網(wǎng)的首頁(yè)banner或者郵件模板我們會(huì)用固定的HTML模板配合Jinja2/Markdown混合渲染。圖片素材則統(tǒng)一命名在構(gòu)建階段由腳本檢查每個(gè)渠道需要的尺寸規(guī)格尺寸不對(duì)直接失敗。這里推薦在提交MR前先用本地腳本跑一遍校驗(yàn)否則CI里失敗一次得等一輪構(gòu)建很浪費(fèi)時(shí)間。3.2 定義流水線一個(gè)GitLab CI示例直接用GitLab CI定義六個(gè)階段下面是一個(gè)可運(yùn)行的簡(jiǎn)化版本真實(shí)項(xiàng)目里還需要掛上環(huán)境、Secret和審批人映射。stages: - validate - build - preview - approval - publish - verify validate: stage: validate script: - markdownlint content/articles/ - check-links --src content/articles/ - check-images --asset-dir assets/images/ - check-channel-fields --config config/channels.yaml rules: - if: $CI_PIPELINE_SOURCE merge_request_event build: stage: build script: - python scripts/build.py --config config/channels.yaml --output dist/ artifacts: paths: - dist/ preview: stage: preview environment: preview script: - python scripts/preview.py --config dist/config.json artifacts: paths: - dist/preview/ expire_in: 7 days approval: stage: approval when: manual timeout: 8h script: - python scripts/approval.py --roles content_owner,legal_reviewer --timeout 8h publish: stage: publish script: - python scripts/publish.py --targets $PUBLISH_TARGETS --version $CI_COMMIT_TAG environment: production rules: - if: $CI_COMMIT_TAG $PUBLISH_TARGETS retry: max: 2 when: - runner_system_failure - stuck_or_timeout - api_failure verify: stage: verify script: - python scripts/verify.py --task-ids dist/task-ids.json --urls dist/urls.json after_script: - python scripts/notify.py --level alert --channel oncall關(guān)鍵點(diǎn)在于validate和build是自動(dòng)的approval是手動(dòng)門檻publish只針對(duì)帶tag的提交觸發(fā)verify是發(fā)完后的系統(tǒng)復(fù)檢。每個(gè)階段失敗都有明確日志運(yùn)營(yíng)不再需要問(wèn)“發(fā)到哪一步了”直接看Pipeline頁(yè)面就知道。這個(gè)設(shè)計(jì)也解決了一個(gè)長(zhǎng)期痛點(diǎn)夜間定時(shí)發(fā)布。我們把發(fā)布腳本抽象成任務(wù)隊(duì)列定時(shí)觸發(fā)器到點(diǎn)調(diào)用publish job執(zhí)行完成后自動(dòng)進(jìn)入verify。一旦失敗自動(dòng)重試兩次仍然失敗就告警到值班群。因?yàn)槲覀儼寻l(fā)布任務(wù)真正做成了異步任務(wù)不會(huì)再出現(xiàn)“電腦關(guān)了導(dǎo)致定時(shí)發(fā)布沒(méi)跑”的問(wèn)題。3.3 渠道適配器不同類型的媒體怎么接流水線主體穩(wěn)定后剩下最核心的工程就是渠道接入。每個(gè)渠道的接口不同我們抽象出一個(gè)統(tǒng)一的適配器接口讓主流程只依賴這個(gè)協(xié)議不關(guān)心具體平臺(tái)。class ChannelAdapter(ABC): abstractmethod def publish(self, payload: PublishPayload) - TaskResult: 把渲染好的內(nèi)容發(fā)布到目標(biāo)渠道 pass abstractmethod def verify(self, task_id: str) - VerifyResult: 查詢發(fā)布結(jié)果并檢查線上狀態(tài) pass abstractmethod def rollback(self, task_id: str, version: str) - bool: 把內(nèi)容下線或切回歷史版本 pass以官網(wǎng)為例適配器調(diào)用內(nèi)部CMS接口創(chuàng)建文章成功后拿到task_idverify時(shí)根據(jù)task_id調(diào)用CMS查詢文章?tīng)顟B(tài)rollback時(shí)調(diào)用CMS刪除或下架文章。公眾號(hào)這類平臺(tái)有素材和群發(fā)接口但限制比較多我們就在適配器里做字段校驗(yàn)和頻控處理。沒(méi)有開(kāi)放API的渠道也能接入——適配器把發(fā)布任務(wù)轉(zhuǎn)換成一個(gè)待確認(rèn)卡片推送到運(yùn)營(yíng)的工作臺(tái)或企業(yè)微信群里運(yùn)營(yíng)點(diǎn)一下“已手動(dòng)發(fā)布”再手動(dòng)填上線上鏈接verify階段會(huì)用這個(gè)鏈接做可用性探測(cè)。這個(gè)“人工兜底模式”很重要。很多自動(dòng)化項(xiàng)目死在渠道沒(méi)有API這個(gè)理由上但實(shí)際根本不需要全套自動(dòng)化只需要把人工操作變成流水線中的一個(gè)明確狀態(tài)。半自動(dòng)化也是自動(dòng)化關(guān)鍵是人的動(dòng)作能被追蹤。3.4 定時(shí)、灰度與回滾實(shí)戰(zhàn)灰度發(fā)布在這個(gè)場(chǎng)景里同樣適用。我們的默認(rèn)策略是重點(diǎn)稿先發(fā)官網(wǎng)一個(gè)渠道confirm沒(méi)有問(wèn)題后再把PUBLISH_TARGETS設(shè)為公眾號(hào)、頭條、知乎等全量渠道觸發(fā)下一步j(luò)ob。這就是金絲雀發(fā)布在內(nèi)容領(lǐng)域的最簡(jiǎn)形態(tài)。執(zhí)行方式是通過(guò)流水線的變量控制。開(kāi)發(fā)者或者市場(chǎng)負(fù)責(zé)人在觸發(fā)publish時(shí)選擇目標(biāo)渠道例如# 只發(fā)官網(wǎng)快速驗(yàn)證 PUBLISH_TARGETSofficial_site # 全渠道發(fā)布 PUBLISH_TARGETSofficial_site,wechat_official,toutiao,zhihu,email_digest回滾是我們體感最差、也是最有價(jià)值的設(shè)計(jì)。內(nèi)容發(fā)布有幾秒鐘的延遲所以如果在verify階段發(fā)現(xiàn)線上鏈接404、頁(yè)面亂碼或者內(nèi)容被平臺(tái)攔截我們立刻觸發(fā)rollback腳本。對(duì)于支持API刪除的平臺(tái)比如官網(wǎng)CMS回滾會(huì)自動(dòng)執(zhí)行對(duì)于不支持刪除的平臺(tái)rollback會(huì)生成一張緊急撤稿單并給對(duì)應(yīng)渠道管理員發(fā)送高優(yōu)通知平臺(tái)本身無(wú)法做到的事至少流程上能保證不遺漏。這里有個(gè)容易被忽略的認(rèn)知回滾不是“刪掉重發(fā)”而是“讓線上回到上一個(gè)可接受狀態(tài)”。對(duì)內(nèi)容平臺(tái)來(lái)說(shuō)舊版本往往比空白頁(yè)更合理。所以我們的rollback優(yōu)先切回上一版本再跑一次verify確認(rèn)舊版本正常后才算完成。4. 質(zhì)量門禁和合規(guī)閘門別讓壞稿上線4.1 自動(dòng)化靜態(tài)檢查清單發(fā)布前能自動(dòng)檢查的內(nèi)容盡量不留給人工。我們的校驗(yàn)?zāi)_本包含五類檢查Markdown語(yǔ)法和結(jié)構(gòu)超鏈接可用性圖片尺寸和格式渠道字段完整性以及文本規(guī)范。Markdown語(yǔ)法檢查會(huì)攔截明顯的格式錯(cuò)誤比如列表嵌套不對(duì)、鏈接語(yǔ)法不合法、引用塊未閉合。超鏈接檢查會(huì)請(qǐng)求每個(gè)外部鏈接的響應(yīng)狀態(tài)發(fā)現(xiàn)404就報(bào)錯(cuò)。圖片檢查會(huì)讀取圖片尺寸確認(rèn)每個(gè)渠道所需封面比例是否存在比如官網(wǎng)要16:9公眾號(hào)要2.35:1郵件最好用900px等寬尺寸不對(duì)直接fail。文本規(guī)范檢查不討論復(fù)雜邊界只做兩部分一是自定義禁用詞庫(kù)比如一些違反廣告法的絕對(duì)化用語(yǔ)我們做成一個(gè)詞表文件持續(xù)維護(hù)二是調(diào)用文本審核接口做內(nèi)容安全檢測(cè)檢測(cè)結(jié)果包含風(fēng)險(xiǎn)等級(jí)高風(fēng)險(xiǎn)自動(dòng)阻止中風(fēng)險(xiǎn)進(jìn)入人工確認(rèn)。這個(gè)環(huán)節(jié)的價(jià)值是把以前靠人肉檢查幾十遍的內(nèi)容變成確認(rèn)一次就夠。為了減少無(wú)效構(gòu)建同樣的校驗(yàn)?zāi)_本也應(yīng)該本地可跑。我們?cè)趥}(cāng)庫(kù)根目錄提供了一個(gè)make lint命令作者提交前先本地跑一遍CI再跑一遍。這樣雖然增加了一點(diǎn)作者負(fù)擔(dān)但大量減少了CI排隊(duì)時(shí)間。4.2 人工審批的取舍自動(dòng)化永遠(yuǎn)替代不了最終人眼確認(rèn)或者說(shuō)在媒體發(fā)布場(chǎng)景里審批人消除的不是自動(dòng)化的需求而是對(duì)風(fēng)險(xiǎn)的責(zé)任。所以我們把審批做成了流水線上的一個(gè)“Manual Gate”。具體操作是這樣的build完成后流水線自動(dòng)生成一個(gè)預(yù)覽環(huán)境展示每個(gè)渠道最終的渲染效果。審批人收到通知后打開(kāi)預(yù)覽頁(yè)看到的是線上即將展示的樣子不是原始Markdown。確認(rèn)無(wú)誤后在審批系統(tǒng)里點(diǎn)擊通過(guò)任務(wù)才會(huì)進(jìn)入發(fā)布階段。如果發(fā)現(xiàn)問(wèn)題一鍵駁回系統(tǒng)自動(dòng)把駁回原因和MR關(guān)聯(lián)通知作者去修改。這里有個(gè)很現(xiàn)實(shí)的經(jīng)驗(yàn)審批節(jié)點(diǎn)要有超時(shí)策略。我們?cè)缙谠试S審批人無(wú)限期掛起結(jié)果一個(gè)季度出現(xiàn)了三篇稿子停在審批環(huán)節(jié)超過(guò)一周。后來(lái)加了8小時(shí)超時(shí)提醒超時(shí)后每2小時(shí)提醒一次超過(guò)24小時(shí)仍未處理則自動(dòng)升級(jí)給部門負(fù)責(zé)人。上線這個(gè)機(jī)制后平均審批時(shí)長(zhǎng)從12小時(shí)降到3小時(shí)以內(nèi)。4.3 發(fā)布后的可觀測(cè)性不是發(fā)完就結(jié)束發(fā)布成功和用戶真的看到內(nèi)容是兩回事。verify階段除了檢查鏈接返回200之外我們還會(huì)從各渠道后臺(tái)拉取發(fā)布結(jié)果和初步的曝光數(shù)據(jù)。公眾號(hào)通過(guò)接口能拿到文章的閱讀數(shù)和分享數(shù)有延遲官網(wǎng)CMS能拿到UV/PV第三方平臺(tái)可以用后臺(tái)導(dǎo)出API混合方式。把數(shù)據(jù)回流到流水線后我們會(huì)設(shè)置一些極簡(jiǎn)告警規(guī)則發(fā)布30分鐘后如果核心渠道曝光量為0自動(dòng)發(fā)告警給運(yùn)營(yíng)發(fā)布2小時(shí)后如果閱讀轉(zhuǎn)化明顯低于歷史同類型稿件的1/10也觸發(fā)提示。目標(biāo)不是代替分析師而是讓異常能第一時(shí)間被發(fā)現(xiàn)避免“稿子發(fā)了三天才發(fā)現(xiàn)沒(méi)被收錄”的尷尬。可觀測(cè)性還有一層價(jià)值它讓流水線的優(yōu)化有了依據(jù)。我們后來(lái)用發(fā)布數(shù)據(jù)反推渠道選擇比如某個(gè)渠道閱讀量長(zhǎng)期接近零就把它移出默認(rèn)渠道或者調(diào)整發(fā)布時(shí)間窗口。這種決策以前靠感覺(jué)現(xiàn)在可以直接看數(shù)據(jù)運(yùn)營(yíng)和市場(chǎng)也更容易達(dá)成共識(shí)。5. 常見(jiàn)問(wèn)題與排錯(cuò)實(shí)錄5.1 高頻問(wèn)題速查表先整理一個(gè)速查表都是我們實(shí)際運(yùn)行中踩過(guò)的坑按概率排序列出來(lái)現(xiàn)象常見(jiàn)原因排查建議某渠道發(fā)布成功但線上沒(méi)有平臺(tái)異步上線有緩存延遲擴(kuò)大verify等待時(shí)間到5~10分鐘同一篇稿子出現(xiàn)重復(fù)內(nèi)容渠道接口沒(méi)有冪等任務(wù)重試導(dǎo)致重復(fù)創(chuàng)建在適配器里持久化外部task_id發(fā)布前查重定時(shí)發(fā)布到點(diǎn)沒(méi)執(zhí)行worker進(jìn)程重啟丟任務(wù)任務(wù)狀態(tài)寫入數(shù)據(jù)庫(kù)不要再依賴內(nèi)存隊(duì)列審批已通過(guò)但publish沒(méi)觸發(fā)配置了tag規(guī)則但本次沒(méi)有打tag在發(fā)布文檔里明確打tag的流程公眾號(hào)群發(fā)失敗當(dāng)天已群發(fā)過(guò)或者觸發(fā)了平臺(tái)頻控通過(guò)配置max_articles_per_day在構(gòu)建時(shí)提前校驗(yàn)鏈接檢查誤報(bào)部分平臺(tái)有反爬請(qǐng)求返回403在check-links中配置合法的UA和請(qǐng)求頭回滾后頁(yè)面反而空白平臺(tái)刪除內(nèi)容后返回404verify誤判舊版本在線回滾操作后必須重新跑verify不能只看刪除成功這表里的問(wèn)題大多不是技術(shù)難題很多是“沒(méi)有把平臺(tái)特性納入設(shè)計(jì)”。我們?cè)缙谧顟K的一次事故就是重復(fù)發(fā)布平臺(tái)接口偶發(fā)超時(shí)我們?cè)谀_本里加了重試結(jié)果接口其實(shí)已經(jīng)創(chuàng)建成功重試又把內(nèi)容發(fā)了一遍線上出現(xiàn)兩篇一模一樣的文章。從那之后適配器里第一件事就是寫冪等邏輯——發(fā)布前查一下是否已有同一個(gè)version的引用有就直接返回已有task_id。5.2 三個(gè)讓我印象深刻的坑第一個(gè)坑是“定時(shí)任務(wù)睡死了”。我們最初把定時(shí)發(fā)布和主流程放在同一個(gè)進(jìn)程里結(jié)果某次發(fā)布節(jié)點(diǎn)正好趕上服務(wù)器發(fā)布升級(jí)進(jìn)程重啟后所有定時(shí)任務(wù)全部丟失作者半夜發(fā)的稿子第二天才發(fā)現(xiàn)根本沒(méi)人發(fā)。后來(lái)改成把任務(wù)持久化到數(shù)據(jù)庫(kù)worker啟動(dòng)時(shí)重新加載未完成任務(wù)并用分布式鎖保證不會(huì)重復(fù)執(zhí)行。這是直接套用調(diào)度系統(tǒng)經(jīng)驗(yàn)的地方效果立竿見(jiàn)影。第二個(gè)坑是“為了讓流水線通過(guò)反而寫了更多代碼”。最初我們把所有校驗(yàn)都往流水線里塞結(jié)果渠道字段幾十個(gè)每加一個(gè)新渠道就要改一大通校驗(yàn)邏輯。后來(lái)我們換個(gè)思路把校驗(yàn)拆成通用校驗(yàn)和渠道擴(kuò)展校驗(yàn)。通用校驗(yàn)只管所有渠道都需要的字段擴(kuò)展校驗(yàn)寫到各個(gè)渠道適配器內(nèi)部?，F(xiàn)在新渠道接入只需要關(guān)注自己的特殊性不再影響全局構(gòu)建。第三個(gè)坑更偏組織協(xié)作有一些運(yùn)營(yíng)同事完全不適應(yīng)看流水線看到紅色狀態(tài)就慌。我們做了一次很大的簡(jiǎn)化業(yè)務(wù)人員不需要看懂整條流水線只需要關(guān)注企業(yè)微信里收到的“待審批”“發(fā)布成功”“發(fā)布失敗”三條通知。把工具層面的專業(yè)性和業(yè)務(wù)層面的易用性隔離開(kāi)系統(tǒng)才真正被用起來(lái)。5.3 效果評(píng)估不要只講自動(dòng)化率說(shuō)到成果我傾向于用幾個(gè)直觀指標(biāo)來(lái)說(shuō)明指標(biāo)改造前改造后單篇稿全渠道發(fā)布耗時(shí)40~60分鐘8~12分鐘發(fā)布失敗需要人工處理的比例約15%約3%平均審批時(shí)長(zhǎng)12小時(shí)3小時(shí)以內(nèi)因重復(fù)發(fā)布/錯(cuò)誤發(fā)布導(dǎo)致的事故每月穩(wěn)定2~3次上線后半年1次夜間定時(shí)發(fā)布人工盯守每天需要不需要這些數(shù)字看起來(lái)漂亮但我的感受是真正的價(jià)值不在于“省了多少人”而在于把團(tuán)隊(duì)從救火狀態(tài)中解放出來(lái)。以前大家每天都在問(wèn)“哪個(gè)平臺(tái)沒(méi)發(fā)哪篇稿子要改”現(xiàn)在這些信息會(huì)自動(dòng)出現(xiàn)在通知里有異常直接告警團(tuán)隊(duì)的注意力終于可以放在內(nèi)容質(zhì)量和渠道策略上。5.4 關(guān)于投入產(chǎn)出比的真心話最后說(shuō)點(diǎn)實(shí)在的。做這類系統(tǒng)投入最大的不是寫代碼而是和各個(gè)渠道的接口、審核策略、業(yè)務(wù)規(guī)則做對(duì)齊。我的建議是第一個(gè)版本只做一條核心渠道加一個(gè)輔助渠道跑通后再擴(kuò)。我們當(dāng)時(shí)貪多一上來(lái)就接了六個(gè)渠道結(jié)果第一個(gè)月全部在調(diào)各平臺(tái)的圖片比例和字段校驗(yàn)主流程反而遲遲沒(méi)穩(wěn)定。共建的時(shí)候一定要把市場(chǎng)同事拉進(jìn)來(lái)當(dāng)需求方而不是直接扔一個(gè)自動(dòng)化工具給他們。整個(gè)項(xiàng)目做完最有成就感的時(shí)刻不是流水線變綠而是運(yùn)營(yíng)同學(xué)第一次跟我說(shuō)“今晚我可以準(zhǔn)點(diǎn)下班了?！毙l(fā)這塊事DevOps化不是要讓誰(shuí)失業(yè)是讓所有人把時(shí)間花在更值得的事情上。