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