運維項目經驗示例(參考)

一,期中項目經驗示例

  • 1.1 新服務器上線搭建系統環境
    1,根據現有結構部署工具(PXE+kickstart)
    2,結合應用系統需求定製部署模版
    3,製作系統優化等一鍵執行腳本
    4,自動化部署實施
    5,根據定製的優化內容對自動化部署效果進行檢驗

  • 1.2 新服務器上線搭建軟件環境
    1,在新批量部署的服務器上部署LNMP環境;
    2,對批量化部署的環境進行效果檢驗;
    3,編制Nginx配置文件並批量化部署;
    4,根據需求做Nginx服務相關的優化(expires/gizp等)

  • 1.3 web服務器架構調整(從單點到集羣的設計)
    需求:
    解決網站web服務器單點故障的問題
    職責:
    1,研究多種負載均衡方案
    主要針對lvs+keepalived及nginx+keepalived進行研究
    2,編寫新架構方案實施項目書與實施日程
    3,新系統部署與日常維護
    把公司原來的多數單點服務器變成了集羣,提升了網站的穩定性與高併發的應用場景

  • 1.4 服務器用戶權限管理改造方案與實施項目
    需求:
    解決公司root權限氾濫問題
    職責:
    1,提出權限整改解決方案,改進公司root權限氾濫的現狀
    2,召集大家開會商討並確定方案後推進實施
    3,實施後使得公司的權限管理更加清晰了(總結維護),從根本上降低了內部操作等不規範及安全隱患的發生。

問題1:你們公司是如何來管理用戶權限的?
答:我們是通過sudo來管理權限的,不論是運維還是開發,一般都不會給root權限,只有核心級開發或者研發總監或以上級別的我們纔可能給相應服務器級別的權限;對核心運維或者運維總監纔會給root權限

問題2:在規劃服務器的時候,在服務器上都跑幾個普通用戶?
答:我們的普通用戶是根據項目來的,在不同公司它的項目產品線不一樣。我們公司只有十幾個產品線,我們爲每一個項目建立一個普通用戶,因此不論nginx還是tomcat都是跑在普通用戶下。

問題3:那一些公用服務呢?比如memcached或者redis。
答:這些公共服務也可以跑在普通用戶下,總的來說是這樣的,我對運維的理解是,運維做運維的事情,開發做開發的事情。運維負責網絡系統,只要系統沒有故障,只要網絡沒有故障,只要系統資源還夠用,那麼我們運維的職責就到位了。而我們公司的理念是項目負責制,也就是說每個項目的責任人是開發,我們運維大概佔30%-40%的責任。我們的開發佔60%的責任。當進程上線的時候,這個服務是由普通用戶跑的。它的每個站點目錄都是普通用戶的權限,也就是700的權限普通用戶,這個是最安全的。無論是項目的啓動,停止,以及代碼上線,日誌收集,日誌分析都是通過我們進程跑的普通用戶實現的。我們在管理這個項目的時候,我們可以把開發的用戶加到這個項目組裏面,這樣負責相應項目的開發人員就有對應項目的所有權限。

  • 1.5 服務器日誌審計項目提出與實施
    1,權限控制後進一步實施對所有用戶日誌記錄方案
    2,通過sudo和rsyslog配合實現對所有用戶進行日誌審計並將記錄集中管理
    3,實施後讓所有運維和開發的所有執行的命令都有記錄可查,杜絕了內部人員的操作安全隱患

  • 1.6 全網服務器數據批量分發與批量管理
    需求:
    公司服務器逐漸增多,因此管理起來很麻煩,於是提出解決批量分發管理解決方案,進行全網服務器數據分發與管理
    職責:
    1,針對ansible分發工具及ssh key+rsync兩套分發管理方案研究,最終選擇簡單易於維護並且強大的ssh key+rsync方案
    2,找一臺IDC內網服務器,作爲分發機器,對固定普通用戶做sshkey認證(注意不是root),需要root權限,通過sudo來控制,減少安全隱患。
    3,對於分發機進行安全配置,例如,去掉外部IP,開啓防火牆。實施完畢,運維管理的效率提高了很多,因此得到了公司的嘉獎。

  • 1.7 全網服務器數據備份方案提出及負責實施
    需求:
    爲公司數據做一個完整的備份系統
    職責:
    1,針對公司重要數據備份混亂狀態和領導提出備份全網數據解決方案
    2,通過本地打包備份,然後rsync結合inotify應用把全網數據統一備份到一個固定存儲服務器,然後在存儲服務器上通過腳本檢查並報警管理員備份結果
    3,定期將IDC機房的數據備份公司的內部服務器,防止地震火災等問題導致的數據丟失。

  • 1.8 MySQL數據庫實現主從同步,及完整備份解決方案
    1,在進入公司之前前任運維丟失數據,因此老大很重視數據安全這方面
    2,我提出並上線了MySQL數據庫備份方案和MySQL架構方案
    3,方案主要是在從庫上開啓binlog及按天分庫分表全備,推送到備份服務器
    4,將備份的數據定期恢復到測試庫給開發使用
    5,制定人工更新數據庫的流程及制度

  • 1.9 LNMP架構優化方案
    1,公司使用LNMP架構,優化較少,運行效果不佳
    2,我提出了LNMP架構的優化方案
    3,方案主要是Linux系統優化,nginx服務優化,php服務優化,MySQL優化
    4,優化完成後,LNMP架構性能有很大提高。

  • 1.10 全網服務器監控解決方案實施
    需求:
    到公司後,沒有任何監控系統,每次故障無法報警,每次故障對公司的網站都造成了很大的影響,因此我用自己已經掌握的監控技術,以及查詢資料撰寫解決方案,提交給公司領導,以改善服務器報警不及時的問題,最大限度的保證公司網站故障及時處理
    職責:
    1,根據需求選定最流行的監控軟件zabbix進行研究。
    2,根據不同服務器具體需求定製模版進行監控實時報警
    實施完畢後,做到了大部分的故障報警都能及時有效的彙報給管理員,爲網站的穩定爭取了時間

  • 1.11 搭建jumpserver跳板機管理混亂賬戶
    起止時間: 2016/03-2016/04
    軟件環境: CentOS6.5
    開發工具: jumpserver
    項目描述:在投入工作的幾個月裏,我發現公司的服務器運維管理中對於服務器賬號的管理十分混亂,有的運維甚至有好幾個工作賬號,而且能隨時登陸root賬戶。因此,每當有運維工作人員調崗或離職,服務器的所有賬戶密碼都會被重新改變一次,不僅費時費力,密碼也不好記憶,十分的麻煩。於是,幾經思考,我向領導建議啓用開源型的跳板機jumpserver來改善目前混亂的狀況。
    職責:
    部署一臺服務器爲jumpserver跳板機
    用xshell登陸跳板機進行授權測試

  • 1.12 改善服務器存儲問題
    需求:
    減輕訪問高峯階段存儲壓力
    職責:
    1,Web前端存儲使用NFS主備結構
    2,用戶寫入數據,如圖片,附件等,存儲到NFS主上面,用戶的讀訪問NFS備
    3,NFS主備,使用rsync+inotify進行數據同步
    4,NFS存儲數據量不大,採用sersync把數據推送到web前端,儘量較少前端服務訪問後端服務器的請求,減輕NFS存儲壓力
    5,數據備份的安全有了保障,不用擔心數據的丟失。

二,期末項目經驗示例

  • 2.1 航天一院第三產業部–院綜合服務集羣
    需求:
    該項目主要實現的是航天一院內部服務平臺搭建 目標是搭建一個安全、高效、穩定服務器羣集架構。提供航天各院的服務綜合平臺。
    項目實施:
    前段採用負載均衡搭配Squid集羣、搭配硬件防火牆,隔離內網與外網,並且能提供監控網絡和記錄傳輸信息的功能,加強局域網的安全性等.實現前端調度服務器的高可用、中間web服務器的負載均衡、後端數據庫服務器的高可用、監控服務器監控集羣中的每一臺服務器的私有數據和公有數據前端調度服務器採用的軟件是Keepalived和Nginx,中間Web服務器採用的軟件是Nginx,併發數高,而且相對穩定
    後端數據庫服務器採用的是讀寫分離,寫庫MySQL+MHA 雙主互爲主從模式。讀從庫使用負載均衡LVS+Keepalived+MySQL , 並使用Memcached緩存集羣緩存從數據庫.Web服務器採用Nginx來搭建網站服務器,並結合Inotify+Rsync實現網站數據同步.
    監控服務器採用的是Zabbix,監控各服務器的運行狀態及服務狀態。
    職責
     本人在此項目中主要負責服務器服務平臺的搭建,爲了實現統一性,特編寫了shell腳本,使得服務器部署更加標準化

  • 2.2 NFS集羣升級改造
    需求分析:
    1、 原共享存儲服務器NFS的方式、存在性能瓶頸和單點故障的問題
    2、 主NFS存儲系統宕機後,報警管理員來人爲手工根據同步的日誌記錄選擇最快的NFS存儲系統改爲主,方案簡單可行,但是需要人工處理.難免操作失誤或者時間過長。
    解決方案:
    1、 使用分佈式文件存儲管理系統MFS替換NFS
    2、 目前MFS元數據服務器存在單點問題,因此我們通過DRBD提供磁盤及時同步,通過HeartBeat提供Failover,來達到高可用
    3、採用MFS+DRBD+Heartbeat高可用服務解決方案,這個解決方案可以有效解決主MFS存儲系統單點的問題,當主MFS存儲宕機後,可以實現把主MFS存儲系統從一個主節點切換到另外一個備節點,而新的主MFS存儲系統還會自動和所有其他的從MFS存儲系統進行同步,且新主MFS存儲系統的數據和宕機瞬間的主MFS存儲系統幾乎完全一致,這個切換過程完全是自動進行的,從而實現了MFS存儲系統的熱備方案. 快速故障恢復,提高業務可靠性.
    職責
    本人在此項目中主要負責,項目現場協調,所有服務器服務平臺的搭建,編寫了shell腳本,使得服務器部署更加標準化

  • 2.3 MySQL集羣讀寫分離及高可用方案
    需求分析:
    1、 新方案保證服務性能和I/O滿足企業多臺終端的快速響應需求。
    2、 保證系統長期不間斷的穩定運行。保證成本合理性。
    3、 滿足數據庫系統的高可用性和可靠性。
    解決方案:
    1、 底層5臺MySQL 數據庫,一主四從. 開啓半同步複製.提高數據安全
    2、 使用中間件Atlas 實現讀寫分離與讀負載均衡,提高與程序端解耦。
    3、 在使用兩臺服務器搭建LVS+Keepalived 對Atlas 服務器做負載均衡與高可用
    4、 搭建一臺主MHA服務器管理數據庫主庫熱備問題.
    5、 該方案極大減少服務器資源浪費,實現故障30秒切換,極大保證數據庫一致性
    責任描述:
    主要負責所有服務器服務平臺的搭建,方案設計,編寫腳本。

  • 2.4 NFS+DRBD+heartbeat高可用解決方案
    軟件環境:Centos6.8
    硬件環境:DELL R710
    實施時間:2015年3月
    剛進公司不久,後端的NFS服務器在網絡請求的高峯期,偶爾會宕機,使WEB服務器的掛載請求無法自動切換到備份服務器,導致web服務器無法正常使用,造成網絡服務中止。公司領導爲了避免以後出現類似的情況要求我做一個解決方案。通過對NFS服務器CPU和內存的負載情況進行觀察,以及對NFS服務器之前的主要硬件的負載數據進行查詢,並進行仔細分析,我提交了一份以DRBD+heartbeat+NFS的方案來解決現有問題,得到領導的批准由我來實施這個方案。
    職責:
    1、負責項目的整體規劃和部署;
    2、負責heartbeat自動切換腳本的編寫;
    3、負責NFS服務搭架的主要框架的搭架;
    4、通過對故障的模擬,和對元數據服務器、數據存儲服務器運行數據的觀察,和之前的情況進行數據比較,形成報告;
    5、項目實施報告的撰寫。
    後期改善:
    通過配置多條獨立的物理連接,以避免Heartbeat通信線路本身存在的單點故障,儘量地減少“腦裂”的發生機會。通過對ha.cf配置文件中,keepalive等選項的設置,來縮短主從服務器的切換時間。在DRBD中,對replication進程進行調整。處理Master端的壞塊問題。

  • 2.5 移動端部署調優及上線
    運行環境:CentOS-6.6、DELL R730
    主要功能:分離移動端與PC業務
    運用技術:Nginx七層負載、tomcat8+jdk1.8、MHA實現mysql高可用(mysql–5.6.17)、
    php-5.6.30、shell腳本發送數據檢測信息
    技術要點:
    利用Nginx七層調度實現PC端與移動端業務分離、動靜分離
    七層調度+Keepalived高可用方案
    Nginx整合淘寶健康檢測模塊
    代碼讀寫分離+數據庫mha成熟高可用方案
    定時+腳本mysql數據備份及檢測、發送檢測結果信息到管理員手機
    web服務優化,php優化,tomcat優化
    2.6 squid 透明代理
    1、系統環境:CentOS6.5
    2、軟件工具:squid-3.0
    3、項目描述:
    之前公司使用的是SNAT上網,造成員工在工作期間利用公司網絡帶寬瀏覽與工作無
    關的網站視頻,導致工作效率降低;迅雷、P2P等應用的泛濫,導致網絡擁堵,企業
    網帶寬資源緊張。
    職責:
    a) 使用squid代理服務對公司員工的上網行爲進行管控;
    b) 擬定企業上網行爲管控方案;
    c) 實現對內網的安全防控功能,過濾惡意網頁,防範惡意攻擊;
    d) 限制網絡行爲,對迅雷、P2P等下載軟件進行智能控制;
    e) 對上網行爲進行精細智能管理。
    5、項目成果:
    項目實施完畢後,員工工作效率明顯提升,保障了企業網帶寬資源。

參考文章

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章