Linux就業技術指導(二):簡歷項目經驗示例

一,期中項目經驗示例

1.1 新服務器上線搭建系統環境

1,根據現有結構部署工具(PXE+kickstart)
2,結合應用系統需求定製部署模版
3,製做系統優化等一鍵執行腳本
4,自動化部署實施
5,根據定製的優化內容對自動化部署效果進行檢驗php

1.2 新服務器上線搭建軟件環境

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

1.3 web服務器架構調整(從單點到集羣的設計)

需求:解決網站web服務器單點故障的問題mysql

職責:
1,研究多種負載均衡方案
主要針對lvs+keepalived及nginx+keepalived進行研究
2,編寫新架構方案實施項目書與實施日程
3,新系統部署與平常維護
把公司原來的多數單點服務器變成了集羣,提高了網站的穩定性與高併發的應用場景nginx

1.4 服務器用戶權限管理改造方案與實施項目

需求:解決公司root權限氾濫問題web

職責:redis

1,提出權限整改解決方案,改進公司root權限氾濫的現狀
2,召集你們開會商討並肯定方案後推動實施
3,實施後使得公司的權限管理更加清晰了(總結維護),從根本上下降了內部操做等不規範及安全隱患的發生。sql

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

問題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來改善目前混亂的情況。
項目職責:

  1. 部署一臺服務器爲jumpserver跳板機
  2. 用xshell登錄跳板機進行受權測試

1.12 NFS+keepalived高可用架構

如期中架構圖

1.13 MySQL多實例及主從複製

如期中架構圖

1.14 改善服務器存儲問題

需求:減輕訪問高峯階段存儲壓力
職責:
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集羣升級改造

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

2.3 MySQL集羣讀寫分離及高可用方案

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

2.4 NFS+DRBD+heartbeat高可用解決方案

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

2.5 移動端部署調優及上線

 運行環境:CentOS-6.六、DELL R730
 主要功能:分離移動端與PC業務
 運用技術:Nginx七層負載、tomcat8+jdk1.八、MHA實現mysql高可用(mysql--5.6.17)、
php-5.6.30、shell腳本發送數據檢測信息
 技術要點:

  1. 利用Nginx七層調度實現PC端與移動端業務分離、動靜分離
  2. 七層調度+Keepalived高可用方案
  3. Nginx整合淘寶健康檢測模塊
  4. 代碼讀寫分離+數據庫mha成熟高可用方案
  5. 定時+腳本mysql數據備份及檢測、發送檢測結果信息到管理員手機
  6. web服務優化,php優化,tomcat優化

2.6 squid 透明代理

一、系統環境:CentOS6.5
二、軟件工具:squid-3.0
三、項目描述:
以前公司使用的是SNAT上網,形成員工在工做期間利用公司網絡帶寬瀏覽與工做無
關的網站視頻,致使工做效率下降;迅雷、P2P等應用的泛濫,致使網絡擁堵,企業
網帶寬資源緊張。
四、職責:

a) 使用squid代理服務對公司員工的上網行爲進行管控;

b) 擬定企業上網行爲管控方案;

c) 實現對內網的安全防控功能,過濾惡意網頁,防範惡意攻擊;

d) 限制網絡行爲,對迅雷、P2P等下載軟件進行智能控制;

e) 對上網行爲進行精細智能管理。 五、項目成果: 項目實施完畢後,員工工做效率明顯提高,保障了企業網帶寬資源。

相關文章
相關標籤/搜索