shell Firefox Android 编程 开源 Ubuntu java mysql 云计算 nginx 程序员 wordpress centos 微软 Python google Windows php linux apache

中小企業乙方運維經驗分享

image

      

  這次是我第一次在阿裏雲給大家做分享,分享的主題是乙方運維。在座的各位大多是甲方的,對乙方運維了解的不多。有的認為乙方做事和技術都很專業,有的人為乙方就是賣人力,技術水平很低。最近3年我都在乙方工作,將真實的乙方情況分享給大家。

雲服務外包行業介紹——IT服務市場情況

image

       

 雲服務外包是最近幾年跟隨國內雲計算一同興起的行業,由於是新興起的行業,競爭較小沒有壟斷,市場也相對分散,一二三線城市都有。
雲服務外包由於和雲計算發展是同步的,前景很廣闊而穩定。再加上其初期投入成本較低,與客戶收費是按年的,先有盈利再投入人力,資金風險較小。這也是把雙刃劍,同時也造成了很多水平較低的外包公司很難被淘汰,而且對外界造成不好的影響,整個雲服務外包行業的資源很難被整合。

        再看一看雲服務外包的各行各業客戶,銀行證券、制造、通信、政府的市場規模已經很大,說明得到了高端行業客戶的市場認可。
接下來的較為廣闊的市場可能是教育行業,2017年全球教育行業規模排名末尾,但增長率居首位。


运维外包行业介绍——阿里云Vs自建机房

image

        這是一個老生常談的問題了,相信經歷過傳統運維的人都對上面這些深有感觸,還沒有上雲的朋友抓緊上雲吧。在國內,上雲就上阿裏雲,這點無需爭辯了,其他雲的產品數量和服務質量都和阿裏雲存在不少差距。
大家對於上雲還有什麽疑問擔憂嗎?


云服务外包行业介绍——自建 Or 外包

image

      這裏是站在客觀角度評判,並不針對哪一方。從圖上可以看到綜合來看,小規模的情況下,除了團隊可控性,外包是個不錯的選擇。當然,也有人說外包用來背鍋也是個不錯的選擇。


云服务外包行业介绍——运维规范性

image

      

  乙方最大的優勢就在於這些規範的沈澱,中小企業的甲方通常是沒有這些規範的,有的事各種命名規範、安裝路徑規範、防火墻策略等,這些屬於最基礎的規範。

比如監控規範:監控的維度都有哪些?

網絡層:ip之間、線下交換機設備網口的丟包率、延遲。
服務器層:CPU、內存、網卡流量、磁盤IO
系統層:進程數、打開文件數、系統運行時間
中間件層:
Nginx:活動連接數、qps、讀取、響應、等待的連接數
mysql:QPS、TPS、每秒select、insert數量、慢查詢數量

應用層:
比較簡單的:登錄接口是否異常、返回時間是否超過1秒
復雜的:模擬用戶從登陸到選擇商品、下單、付款整個業務鏈路是否正常,可以從外部發請求模擬,最好是開發預留好內部監控接口,否則會產生很多臟數據。

比如故障規範:故障發生後如何通知?

        首先為了避免告警風暴,需要對同一項目同一段時間內的告警進行合並。
        其次判斷告警的項目的負責人是誰,每個項目都有第一運維聯系人、第二運維聯系人、運維經理、運維總監。
        故障信息先發已友好的方式推送出來,友好的方式包括(郵件、短信、微信、釘釘等),若超過3分鐘無響應則開始依次電話通知,直到有人響應。為了保證SLA,若半小時後故障還未解決,則通知運維經理負責處理,若1小時後故障還未解決,則通知運維總監負責處理。
        故障解決後,填寫故障的原因、解決方式、影響範圍,以便每周對故障進行分析,將可以自動化處理的編寫成自動化腳本,比如清理磁盤,將人為引起的重點關註,總之避免之後再次出現。
        若故障影響非常嚴重,則需要寫事故報告發給客戶或者領導,報告內容就不多說了,與前面說的差不多。
        其他的規範就不一一說明了。


用工具构建运维体系——整体运维工作

image

        下面來說一說乙方運維具體都用到了哪些開源工具,後面沒有高端的東西,比較偏向中小企業的實際生產環境。
        大多數人對雲計算的定位就是高端,回顧一下你每天看的各種高端文章,再看看自己真正用起來了多少就明白了,就像IT版的心靈雞湯。這類文章缺少實際的成長經驗上的指導,也是為什麽市面上很少有成功的雲服務乙方的原因之一。
        目前業內規模比較大的也只有二三百人,如雲絡、駐雲、數夢。做雲計算服務的公司非常多,大部分都跟隨整個行業一起發展了三年左右,但公司規模仍不到50人。
        由於運維體系是一個很復雜的東西,工具也很多,我們今天只針對中小企業,挑其中比較重要的幾個方面講講。


用工具构建运维体系——服务器安全

image

        談到運維體系,最重要的就是保障服務器的安全。
        對於內部,主機安全主要通過jumpserver來管控,包含操作審計、權限分配、危險命令管控等功能,可以滿足中小企業運維使用,比市面上一些商業版的堡壘機還要好用。關鍵是開源,包含了主機資源管理和作業執行兩大功能,可將其作為基礎改造成CMDB。
        對於外部,落實好每一臺服務器的安全組規則、重視每一條安騎士爆出來的異常,即可防範大部分風險。


用工具构建运维体系——监控报警

image

        僅次於服務器安全的,應是服務器監控,保障服務的可用性主要依賴它。而且監控是自動化的觸發器,是數據的源頭,對自動化來說是可以大做文章的一塊。
        監控工具最實用的當屬zabbix,對服務器監控支持較好,且不需要太多的開發,網上現成的監控方案非常多,基本上可以說能滿足中小企業所有的監控需求。
        對於監控,僅僅有一套監控工具是不夠的,現在所有的監控工具都只註重監控,而不註重通知。如果你的監控只用短信、郵件來通知的話,那麽運維人員很容易麻痹,而且晚上更沒有響應保障,起碼要有電話通知。
關於監控報警,剛剛在運維規範中講了很多。


用工具构建运维体系——日志分析

image

        日誌平臺我們使用的是graylog,為什麽不是elk呢,因為我們是乙方需要做權限劃分,elk需要購買x-pack來實現權限劃分的功能。而且我們處理的基本都是訪問日誌數據,不需要太強的查詢功能。
        建議甲方還是選擇elk,以便將來業務增加後仍可以滿足日誌分析的需求,日誌平臺的權限劃分對甲方來說不是那麽重要,當業務發展到需要更強的查詢功能不得不購買x-pack時,權限劃分的功能自然也有了。
日誌對乙方來說很重要,是做數據分析的主要數據源,畢竟沒有客戶業務數據的讀取分析權利,有權限無權利。

用工具构建运维体系——监控数据展示

image

       前面講的監控、日誌等都有很多數據,自帶的數據展示頁面是很粗糙的,通常我們是用grafana來做展示。其對各種開源應用的支持插件很多,界面簡約美觀、配置靈活,也支持告警、權限劃分等功能。


运维开发和自动化——开发流程和工具

image

运维开发的基本流程:开发-测试-上生产

這三個階段會用到很多工具:

開發:

開發語言我們使用python、PHP,主要考慮的是開發效率而不是性能。python主要做後端數據采集腳本,運維操作執行,php主要做前端的web操作展示相關。
版本控制使用gitlab毫無疑問。
開發文檔管理用confluence,與公司的文檔管理方式統一。
項目管理和推進用jira,這算是業內最成熟的項目管理工具了,也可以用類似的國產的,叫禪道。
測試:

        測試階段主要包括環境搭建、功能測試、漏洞測試,環境搭建就不多說了,只說最重要的一點:一定要保證和開發環境各軟件版本一致,避免以後因為版本問題+溝通問題浪費很多不必要的時間,這種事已經在各種客戶那裏遇到很多次了。

        功能測試很簡單,根據開發文檔對功能點一一測試即可,建議找其他使用者配合測試,自己測試往往達不到很好的效果,就像自己檢查自己做的數學題一樣,存在一種思維慣性在裏面。

        測試工具有很多,我們只列舉了三種:

性能壓力測試:Jmeter
Sql註入測試:SQLMap
Web漏洞測試:AppScan
        具體的工具使用比較簡單,無非是鼠標點點、命令行敲幾下,百度一下即可。通過這三種工具的測試,我們的運維系統就可以上線了,畢竟運維系統只對內使用,不需要太專業的安全滲透測試。

上線:

        主要是發布和以後的常規運維工具:

發布工具jenkins
規模較大的話集成ansible,這已經是業內普遍的做法
Rundeck主要提供頁面化代替命令行操作
        需要註意的是:比如晚上某個服務掛了需要重啟,那麽只需拿出手機連上公司的vpn,打開已經配置好的rundeck平臺,選中某臺服務器點擊重啟xx服務即可。當然,重啟服務的腳本是自己根據實際情況提前寫好的。說到這裏,關於運維工具的使用有一點很重要,所有的運維工具一定要做IP白名單,即使公司沒有固定IP,也應該搭建一套VPN服務,只允許VPN的IP可以訪問,操作前先連上VPN。運維工具的權限太大,暴露在公網的話,萬一某人賬號密碼泄露或者工具本身有漏洞,所有服務器權限都到了黑客手中。


运维开发和自动化——对小团队的几点建议

image

     

   這裏的建議針對小團隊的,土豪團隊怎麽做都可以。

落實是重中之重,小團隊通常只有研發和運維,太偏重於開發階段而忽略了落實階段。從一個產品開發時間段上來講,三分之一做規劃調研、三分之一編碼、三分之一落實。
落實包括:
產品的適用性,即大家的反饋是否滿意。這是一個需要持續一段時間的過程,而不是開發完成扔出去就給別人用了,規劃和編碼再完美,也少不了大量的優化改良。
產品的使用人群範圍是否與預期一致。比如一個CMDB,也就是配置管理平臺,是不是所有運維人員都在使用,很多公司的CMDB也就個別管理人員在使用,這樣很容易導致平臺只為個別人服務,功能上越走越偏。
產品的使用頻率是否與預期一致。一個落實的比較好的平臺,必然每個人每天都在使用。為什麽有的平臺使用頻率很低呢,那可能是當初規劃時就沒有把日常工作需要用到的功能規劃進去,或者別人覺得用你的平臺還不如他用原來的方式更方便,這時就應該反思了。
初始階段先搭架子,保持規範性,以由面到點的順序進行開發。細節是做不完的,尤其是外行人提出來的細節,比如領導或者客戶本身不參與運維工作,但他提了一個細節上的功能,那麽你就要有自己的判斷了,並且學會拒絕。
我經歷過兩個公司的運維平臺開發,都是什麽功能都往運維平臺裏塞,畢竟提需求的是運維,當然什麽工作想讓平臺來做。而每個功能又包括很多細節,頁面、表結構、接口調用等等,越多就會越亂越雜,可能平臺還沒開發完人都換了幾波了。最好是將平臺定位為XX平臺,比如發布、資產管理、故障事件管理等等。這些平臺只需遵守相同的規範,整合起來使用也比開發一個大平臺容易得多,如都使用LDAP作為用戶認證和分組、都使用jumpserver中的主機作為主機數據源。
產品化雖是人人都希望的,拿著產品賣錢比做運維賣苦力賺錢容易,但所投入的成本會是成倍的增長。產品設計、美工、用戶體驗、運營推廣、售後客服、銷售等等都是很大的成本,而且作為一個運維團隊,在這方面與外面專業的產品團隊比起來,確實差距不是一般的大。
產品需要的源頭要遵守一個核心條件,那就是真實,切記不可走偏,開發過程中經常回顧回顧自己做這個產品的初衷。


提升人效的解决方案——被动工作流程化

image

       

 下面來說一說關於人效,大公司和乙方比較關註這個。大公司有完整的人力資源體系,乙方則人效直接等於公司運營成本。有人說所有公司的人效都等於公司的運營成本,但中小公司同一個崗位可能只有兩三個人,且崗位繁多,衡量和解決人效問題花費的成本可能會大於收益,也就沒有什麽價值。而乙方基本上除了工程師就是銷售,提升人效帶來的收益很大。在座的各位大多是中小公司負責運維相關工作的,不妨借鑒一下乙方是如何做的,也為以後團隊擴大做好準備。

        首先,運維工作分成被動和主動兩部分,我們需要將其流程化,先談談被動。
        被動工作通常是由自動化程序觸發的,這裏拿監控故障告警舉個例子,整個流程是與故障規範相關。在這一個故障處理的事件中,下到一線運維,上到運維總監,每個人該在什麽時間被叫起來該做什麽事,都已經被程序安排好了。對於這個故障事件所屬什麽分類、影響範圍、產生的原因、如何處理的、是誰處理的都已經標準化,方便以後做事故匯總分析。


提升人效的解决方案——被动工作量化

image
      根據之前故障告警產生的數據和處理人填寫的數據,我們可以清楚看到個故障事件花費了多少工作量,原因、結果是什麽,負責人是誰等等。從中可以較為公平得分析出每個人負責的項目故障率多少,處理情況如何,這也是績效考核的一個重要標準,而不是大家混在一起吃大鍋飯。


提升人效的解决方案——主动工作流程化

image

        接下來談談主動工作,這在整體運維工作中應該占據了大部分的工作量,與之前的被動工作加起來,幾乎可以把所有工作都流程化、量化。
        需求者通過釘釘機器人在群中創建需求,指定期望時間、問題詳情、問題難度等細節。機器人在另一端群中發送給運維工程師,並帶有超時提醒。整個事件的流轉,雙方都能清晰的看到,並對事件做出評價,幫助乙方不斷提高服務質量。


提升人效的解决方案——主动工作量化

image
        我們將之前的事件數據加以分析,可以輕松看到團隊整體的工作量有多大,都是什麽類型的工作,每個人工作量多大及其處理的事件難度、超時、客戶評分等指標,還有每個項目付出了多少工作量,對方的評價如何。這些數據是評判每個人、每個項目工作量的重要依據,也為優勝劣汰提供了數據支撐,讓混日子的暴露在數據面前,從而逐漸提升企業的人效。


转型数据运维——意义

image

  1. 數據運維是我自己定義的,更偏向對運維的運營管理工作。
    這是一條運維未來要走的必然之路,前面講到的那些都是數據運維的工作。
    這條路很艱難,牽扯到很多人的工作方式改變,僅僅靠自己是無法推動的,需要強有力的支持。

转型数据运维——技能需求

image

  1. 開發語言要輕量且適合web,目的是快速開發部署且容易上手,JAVA太重不推薦。
    開發框架有很多,這裏只列舉了每個語言最常用的,中文文檔較完善的。
    前端基礎知識懂得HTML、CSS、JS、JQ的基本語法即可,Bootstrap常用組件如何使用,如菜單、下拉框、表格。
    Echarts常用圖表如何使用,折線圖、餅圖、地圖。
    如果在前端上不想花太多時間的話,推薦使用阿裏雲的quickBI和DataV,只需連接數據庫寫SQL或者寫API對接上圖形即可。

    基本所有接口都是restful標準,post、get最常用。
    說到豐富的運維經驗,這點是最重要的,這也是能開發出實用工具的必備條件,否則就和普通的碼農沒什麽區別了。
    善於發現和梳理的人,更能做出優秀的工具,且落地起來會容易得多,實現的效果也更容易讓人滿足。如果能力達不到,那還是找一個產品經理配合吧。


转型数据运维——数据可视化

image

       

 由於時間關系,這裏只講講從入門階段的運維可視化該怎麽做。我們目前做的是給客戶看的,主要包括資源消耗、工單統計、告警分析、數據庫性能、優化記錄、訪問分析、匯總建議這幾塊內容,數據源是從各個運維平臺中采集而來。

資源消耗:主要是阿裏雲資源消費情況、資源增長情況,哪些資源使用率太低存在浪費,這個領導們比較關心。
工單統計:我們為客戶做了哪些工作,工作量多少,方便體現出我們付出的人力價值。
告警分析:哪些應用告警最頻繁,人為操作引起的多不多,告警影響持續時間最長的是哪些事故。
數據庫性能:最重要的就是數據庫了,QPS、TPS是否在合理範圍內、慢SQL數量是否太多等等,都會為數據庫優化提供參考數據。
優化記錄:是數據庫優化還是應用優化,優化方式是什麽樣的,優化前後的對比,這是體現出我們技術價值的地方。
訪問分析:主要是站點的PV、UV、訪問來源地這些通用數據,當然也可以根據自己對業務的了解,從中分析出應用的性能、Error等情況。
匯總建議:根據以上數據人工綜合分析得來,指出其中關鍵的地方並給出建議,體現出運維的價值。
        以上講的這些是數據分析、自動化、智能化等等後面幾個階段的基礎,以後有機會的話我們再逐步展開後面幾個階段。


image

延伸阅读

    评论