【正文】 程，統(tǒng)一需求提交頁面，同時盡量為用戶提供選項，而不是隨意填寫，盡量減少溝通成本，同時為完全自動化打好基礎?；ヂ?lián)網精神唯快不破，要圍繞“快”找痛點。但勾畫的平臺功 能大而全，需求都是我們替用戶假想的，這樣做的后果就是進展緩慢，但做出的功能沒人用。而開發(fā)工程師是與運維工程師合作最緊密的兄弟，“兄弟有難得拔刀相助”，因此我們明確了開發(fā)工程師就是運維平臺的用戶，運維工程師在平臺的建設 中扮演了多重角色，是建設者也是使用者，但目標是為用戶解決問題，讓我們的用戶有極致的用戶體驗。想到做這個平臺，源于對實際工作需求的觀察。有了這個想法，就需要將無形的技術轉變?yōu)橛行蔚漠a品形態(tài)，同時要賦予它好的寓意。也有人說，你是在偷換概念，不就是做自動化運維平臺嘛。工具化是運維的必經之路，是向更高層發(fā)展的基礎，面對運維這樣復雜的學科，這樣一個極其磨煉人意志的工種，運維工程師需要用聰明的方式解決復雜的問題，節(jié)省時間，去做更有意義的事情。第二天的負責 人要針對第一天的報警找出根本原因，并盡力解決，因為如果無法根治，困擾將持續(xù)發(fā)生。有了監(jiān)控工具和分級機制，還需要有好的制度。以磁盤空間監(jiān)控為例：每天下午6點，統(tǒng)計 磁盤使用率超過80%的機器，發(fā)出郵件預警，下班前解決；在預警的基礎上，超過85%觸發(fā)短信報警；超過90%就要持續(xù)報警，避免事故的發(fā)生。我們用過的工具很多，開源工具有Nagios、Cacti、Ganglia、Zabbix等，同時自己也開發(fā)了一些針對項目場景的監(jiān)控工具，但萬變不離其宗，都是圍繞上述幾個維度進行監(jiān)控，然后再進行分級預警和報警。我們的監(jiān)控大概分為系統(tǒng)級、應用級、項目邏輯和用戶體驗四部分。另外，運維工作離不開監(jiān)控報警，這是一件讓無數(shù)運維人苦不堪言的事情。配置文件管理利用Puppet完成，服務器批量操控依賴SaltStack。初期，我們只圍繞開源軟件做周邊腳本開發(fā)，不動核心代碼，在實踐中總結經驗。大勢所趨，我們必須進行工具化升級，將重復的事情自動化。第一次升級：運維工具化運維工作中有很多瑣碎的、重復的事情，初期我們只有兩個IDC，服務器數(shù)量有限，項目數(shù)量也較少，靠純手工勞作還可以應付。理想很豐滿，現(xiàn)實很骨感，從最初服務少量項目、幾十臺服務器，發(fā)展到大量具有數(shù)億用戶的項目，我們也在不斷摸索，在試錯中成長。在360，運維團隊由基礎運維團隊、網絡運維團隊和應用運維團隊三部分組成。當今互聯(lián)網行業(yè)的發(fā)展日新月異，新技術層出不窮。第一篇：IT運維心得分享范文360公司運維心得分享在很多“外人”的眼中，運維工程師的工作不過是搬機器、調網絡、裝軟件、處理故障、724小時值班，簡單而又枯燥至極。但事實并非如此，運維工作涵蓋很多技術領域，運維工程師要掌握硬件、軟件、操作系統(tǒng)、開發(fā)等多方面的知識，核心目標是為億萬用戶使用的產品保駕護航。為了適應發(fā)展趨勢，運維工程師只有提升技術能力才能更好地完成艱巨的運維任務，必須要對傳統(tǒng)運維發(fā)出自我挑戰(zhàn)。我們將運維從技術支持領域升級，進行產品化改進，核心目標是為了降低運維成本、縮短研發(fā)周期、讓產品試錯更廉價。在這個過程中，我們經歷了兩次重要的升級。但隨著時間的推移，項目暴增，隨之IDC和服務器的數(shù)量也成倍增長，同時360各項目都是小團隊在做，開發(fā)風格不同、習慣各異，但極致要求響應速度，如果運維工作按照之前方式進行，很難滿足需求。在工具化過程中，我們秉著低成本、拿來即用的原則，借鑒業(yè)界成型的方案，同時將精力用在對開源軟件的研究中，有開源工具就絕不自己憑空創(chuàng)造。例如，在最基礎的部署軟件環(huán)境中，我們基于YUM搭建了自己的包管理系統(tǒng)，將常用軟件打包，同時根據(jù)項目做成模板，這樣無論是初始安裝還是擴容都能在分分鐘完成。就這樣 我們的運維兵器譜在不斷地豐富。而會休息才會工作，監(jiān)控體系必須優(yōu)化。系統(tǒng)級主要監(jiān)控硬件和網絡等；應用級主要監(jiān)控常用軟件的健康狀況；項目邏輯監(jiān)控主要模擬用戶行為探測項目功能點是否運行正常；用戶體驗監(jiān)控主要聯(lián)動博睿和基調等第三方監(jiān)控一起優(yōu)化用戶體驗。為了減少報警騷擾，我們分級處理，將報警分為郵件預警、短信報警和瘋狂短信報警。此外，隨著 服務器數(shù)量的增多，硬件故障在所難免，架構設計需要考慮高可用方案，冗余范圍內的服務器故障會以郵件預警的方式發(fā)出，避免對運維工程師的騷擾。為了大部分人可以安心休息，我們每天有專人負責處理常規(guī)報警，遇到無法解決的問題才要求他人協(xié)助。所謂線上無小事，實際工作中復雜場景引發(fā)的問題數(shù)不勝數(shù)，所以可以寬 容第一次錯誤，但不能接受同樣問題發(fā)生第二次，要不斷地總結和完善。第二次升級：運維產品化我剛提出運維產品化時，有朋友開玩笑說，你做后端運維吃苦受罪這么多年，看著產品經理吃香的喝辣的，羨慕嫉妒也想轉行做產品吧。其實提出這個概念，一方面是源于有了足夠的工具化積累；另一方面是想換一種思路做運維，培養(yǎng)產品觀，站在用戶的角度思考問題，讓處于后端的運維工程師主動挖掘需求，圍繞運維做更多的探索，提升團隊技術能力，解決海量用戶帶來的問題。我們的產品取名為HULK——綠巨人，意在讓小伙伴們借助巨人的肩膀成長，輕點鼠標，運籌帷幄。產品經理有了創(chuàng)新點之后，開發(fā)工程師就想以最快的速度上線，但又會很痛苦，因為產品就好比寶塔明珠，塔基需要一 層層地蓋?；谶@些想法，我們勾畫出了宏偉藍圖，提供一個塔基，第一層提供核心基礎服務，如Web、RDB、NoSQL等；第二層提供通用基礎服務，構造一個完美的平臺，讓開發(fā)工程師受益。我們在失敗中反思，意識到需求還得從日常工作中去挖掘，平臺上每個功能模塊都必須解決用戶的痛點。早期開發(fā)和運維的合作中，更多的是郵件、IM及當面溝通，跨團隊的溝通成本是第 一個痛點。由于完整的自動化流程開發(fā)成本比較高，初期我們還“投機取巧”，用戶提交需求以后，只是把格式 化的郵件發(fā)送給運維工程師。就 用這種方式，我們的平臺積累了不少用戶和口碑。再攻克技術難點將一個個需求實現(xiàn)完全自動化，點點鼠標解決問題。但這個流程太死板，例如用戶提交的一個需求，在審核的過程中有待商榷，運維工程師會和開發(fā)工程師 溝通，最終達成一致意見即可，而如果按標準流程需要駁回再提交。有些同事反對這樣做，覺得不符合常 理。近期為了進一步提升項目試錯階段的速度，我們在平臺上推出了一個新功能：“項目孵化器”。使用“項目孵化器”可以最大限度解決這個痛點，只需在平臺上進 行兩個步驟：第一步填寫業(yè)務名稱，預估峰值QPS；第二步選用MySQL、MongoDB、Redis等相關數(shù)據(jù)庫資源。與之前的模式相比，效率和規(guī)范化都有明顯提高。在孵化器的設計階段，我們聽到了很多不同的聲音。經過過往項目 分析及用戶調研，發(fā)現(xiàn)項目尚處于試錯階段，快速試錯是首要需求。當利用孵化器建立一個試錯項目之后，用戶進入平臺想看見什么？展現(xiàn)形式如何？還能做什么？這些問題隨之而來。為了解決此問題，首先我們確定平臺各功能模塊以項目名為主鍵，將項目的域名、負載均衡、Web Server、數(shù)據(jù)庫、通用基礎服務等相關聯(lián)。例如增加一臺Web Server，即可自動部署軟件環(huán)境，完成相關節(jié)點授權、上傳代碼、測試上線。做到信息清晰可見，操控簡單易用。所謂極致，就是要超出用戶的預期，但只有挖掘用戶潛在的需求，才能做出超出預期的功能。360的文化中有很重要的一點是Ownership，一個項目的成功與失敗，運維工程師是有責任的，因此需要在日常工作中時刻提醒自己“這個項目是我的，為了讓項目變得更好，我們需要主動思考，為開發(fā)工程師提供更多的增值服務”。同時基于訪問日志狀態(tài)碼做進一步的頁面分析，然后以日、周、月維度生成一份體檢報告，以及應對方案推送給開發(fā)工程師。結束語運維工作在一家公司中至關重要，但傳統(tǒng)的運維模式一定程度上限制了運維工程師的技術發(fā)展，更抑制了創(chuàng)新思維，我們需要利用運維“寬泛技術”定位的優(yōu)勢開拓思路。也可以根據(jù)項目的需要，主動做技術研究，將基礎服務做成一個個小產品，提供給開發(fā)團隊使用