【文章內(nèi)容簡(jiǎn)介】 層提供核心基礎(chǔ)服務(wù)，如Web、RDB、NoSQL等；第二層提供通用基礎(chǔ)服務(wù)，構(gòu)造一個(gè)完美的平臺(tái)，讓開(kāi)發(fā)工程師受益。但勾畫的平臺(tái)功 能大而全，需求都是我們替用戶假想的，這樣做的后果就是進(jìn)展緩慢，但做出的功能沒(méi)人用。我們?cè)谑≈蟹此?，意識(shí)到需求還得從日常工作中去挖掘，平臺(tái)上每個(gè)功能模塊都必須解決用戶的痛點(diǎn)?；ヂ?lián)網(wǎng)精神唯快不破，要圍繞“快”找痛點(diǎn)。早期開(kāi)發(fā)和運(yùn)維的合作中，更多的是郵件、IM及當(dāng)面溝通，跨團(tuán)隊(duì)的溝通成本是第 一個(gè)痛點(diǎn)。初期平臺(tái)建設(shè)中，我們從加速流程開(kāi)始進(jìn)行摸索，以“需求任務(wù)流”為核心，將通用需求規(guī)范流程，統(tǒng)一需求提交頁(yè)面，同時(shí)盡量為用戶提供選項(xiàng)，而不是隨意填寫，盡量減少溝通成本，同時(shí)為完全自動(dòng)化打好基礎(chǔ)。由于完整的自動(dòng)化流程開(kāi)發(fā)成本比較高，初期我們還“投機(jī)取巧”，用戶提交需求以后，只是把格式 化的郵件發(fā)送給運(yùn)維工程師。運(yùn)維工程師使用半自動(dòng)化工具干活，完成后再通過(guò)平臺(tái)任務(wù)流告知用戶結(jié)果，手工操作的部分是隱藏在平臺(tái)后面的，用戶不得而知。就 用這種方式，我們的平臺(tái)積累了不少用戶和口碑。之后我們將日常需求分層、分類：主機(jī)類包括主機(jī)申請(qǐng)、賬號(hào)授權(quán)、軟件部署等；Web類包括配置文件管理、域名管理等；DB類包括建庫(kù)、建表、SQL審核、授權(quán)等。再攻克技術(shù)難點(diǎn)將一個(gè)個(gè)需求實(shí)現(xiàn)完全自動(dòng)化，點(diǎn)點(diǎn)鼠標(biāo)解決問(wèn)題。關(guān)于需求任務(wù)流，還有個(gè)小插曲，標(biāo)準(zhǔn)的任務(wù)流由提交、審核、駁回/通過(guò)組成。但這個(gè)流程太死板，例如用戶提交的一個(gè)需求，在審核的過(guò)程中有待商榷，運(yùn)維工程師會(huì)和開(kāi)發(fā)工程師 溝通，最終達(dá)成一致意見(jiàn)即可，而如果按標(biāo)準(zhǔn)流程需要駁回再提交。為了讓用戶少一次操作，我們?cè)黾恿斯芾韱T可編譯功能。有些同事反對(duì)這樣做，覺(jué)得不符合常 理。不過(guò)有時(shí)候常理是需要結(jié)合實(shí)際場(chǎng)景打破的，就為了讓用戶使用更簡(jiǎn)單。近期為了進(jìn)一步提升項(xiàng)目試錯(cuò)階段的速度，我們?cè)谄脚_(tái)上推出了一個(gè)新功能：“項(xiàng)目孵化器”。以典型的Web業(yè)務(wù)為例，以往，申請(qǐng)Web Server、賬號(hào)、數(shù)據(jù)庫(kù)實(shí)例、負(fù)載均衡等是提給運(yùn)維最基本的需求，每一步都是時(shí)間成本。使用“項(xiàng)目孵化器”可以最大限度解決這個(gè)痛點(diǎn)，只需在平臺(tái)上進(jìn) 行兩個(gè)步驟：第一步填寫業(yè)務(wù)名稱，預(yù)估峰值QPS；第二步選用MySQL、MongoDB、Redis等相關(guān)數(shù)據(jù)庫(kù)資源。兩步之后，Web Server、數(shù)據(jù)庫(kù)實(shí)例等所需資源會(huì)瞬間展示在用戶面前，同時(shí)包管理、配置文件管理、代碼發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)等配套輔助功能隨之開(kāi)通。與之前的模式相比，效率和規(guī)范化都有明顯提高。說(shuō)起來(lái)很神奇，但實(shí)現(xiàn)理念很簡(jiǎn)單，我們提煉日常項(xiàng)目中的通用方案，構(gòu)建資源池，在項(xiàng)目發(fā)展初期最小量匹配資源。在孵化器的設(shè)計(jì)階段，我們聽(tīng)到了很多不同的聲音。例如，讓用戶填信息不夠全面，架構(gòu)太簡(jiǎn)單不滿足全部需求，諸如此類問(wèn)題，讓人頭痛欲裂。經(jīng)過(guò)過(guò)往項(xiàng)目 分析及用戶調(diào)研，發(fā)現(xiàn)項(xiàng)目尚處于試錯(cuò)階段，快速試錯(cuò)是首要需求。至于項(xiàng)目發(fā)展中衍生出來(lái)的需求，可以再用平臺(tái)擴(kuò)展功能去解決。當(dāng)利用孵化器建立一個(gè)試錯(cuò)項(xiàng)目之后，用戶進(jìn)入平臺(tái)想看見(jiàn)什么？展現(xiàn)形式如何？還能做什么？這些問(wèn)題隨之而來(lái)。眾所周知，項(xiàng)目中的關(guān)聯(lián)關(guān)系是個(gè)復(fù)雜的問(wèn)題，解決不好，就像一盤散沙無(wú)法聯(lián)動(dòng)。為了解決此問(wèn)題，首先我們確定平臺(tái)各功能模塊以項(xiàng)目名為主鍵，將項(xiàng)目的域名、負(fù)載均衡、Web Server、數(shù)據(jù)庫(kù)、通用基礎(chǔ)服務(wù)等相關(guān)聯(lián)。項(xiàng)目后期各功能模塊的擴(kuò)容可以借助關(guān)聯(lián)關(guān)系自動(dòng)化完成。例如增加一臺(tái)Web Server，即可自動(dòng)部署軟件環(huán)境，完成相關(guān)節(jié)點(diǎn)授權(quán)、上傳代碼、測(cè)試上線。展現(xiàn)形式上我們借鑒社交網(wǎng)站的實(shí)現(xiàn)方案，以“我的項(xiàng)目”為中心，用戶進(jìn)入平臺(tái)以后默認(rèn)頁(yè)展示項(xiàng)目在平臺(tái)中用到的各功能模塊信息，例如域名、主機(jī)數(shù)量、數(shù)據(jù)庫(kù)實(shí)例和監(jiān)控指標(biāo)等。做到信息清晰可見(jiàn)，操控簡(jiǎn)單易用。在平臺(tái)建設(shè)中，我們一直遵循兩個(gè)準(zhǔn)則：第一，把事情由復(fù)雜變簡(jiǎn)單；第二，給用戶極致的用戶體驗(yàn)。所謂極致，就是要超出用戶的預(yù)期，但只有挖掘用戶潛在的需求，才能做出超出預(yù)期的功能。傳統(tǒng)的運(yùn)維模式，大多是開(kāi)發(fā)工程師提需求，運(yùn)維工程師滿足需求，運(yùn)維工程師主動(dòng)推進(jìn)的意識(shí)不夠。360的文化中有很重要的一點(diǎn)是Ownership，一個(gè)項(xiàng)目的成功與失敗，運(yùn)維工程師是有責(zé)任的，因此需要在日常工作中時(shí)刻提醒自己“這個(gè)項(xiàng)目是我的，為了讓項(xiàng)目變得更好，我們需要主動(dòng)思考，為開(kāi)發(fā)工程師提供更多的增值服務(wù)”。例如一個(gè)項(xiàng)目上線前，會(huì)默認(rèn)部署日志收集模塊，收集匯總后進(jìn)行訪問(wèn)日志自動(dòng)化分析，以時(shí)間維度展示訪問(wèn)量走勢(shì)，同時(shí)輔以IP地址分析模塊展示地域及運(yùn)營(yíng)商分布。同時(shí)基于訪問(wèn)日志狀態(tài)碼做進(jìn)一步的頁(yè)面分析，然后以日、周、月維度生成一份體檢報(bào)告，以及應(yīng)對(duì)方案推送給開(kāi)發(fā)工程師。這些增值服務(wù)是超出預(yù)期的，拉近了開(kāi)發(fā)工程師和我們的距離，一起去探討、改進(jìn)，做出更多有利于項(xiàng)目發(fā)展的功能。結(jié)束語(yǔ)運(yùn)維工作在一家公司中至關(guān)重要，但傳統(tǒng)的運(yùn)維模式一定程度上限制了運(yùn)維工程師的技術(shù)發(fā)展，更抑制了創(chuàng)新思維，我們需要利用運(yùn)維“寬泛技術(shù)”定位的優(yōu)勢(shì)開(kāi)拓思路。例如運(yùn)維工作需要和很多開(kāi)發(fā)團(tuán)隊(duì)合作，協(xié)助架