IT服務管理手冊之11個實用技術總結

内蒙古快3历史开奖号码 www.scvddt.com.cn 日期:2017-06-13 09:47

對于IT服務管理手冊,包含了IT服務方方面面的事情,以不遺漏任何一處,保證IT運維正常運轉。為了方便于查看,E客通篇整理了11個實用技術。如下:


  

為變化而設計


  

1、Google的秘訣是正確的——“為變化而設計”?!氨浠本褪遣壞貌徊渴鸚碌娜砑?,升級現有的軟件,進行擴展,設備損壞,以及人員流動等。


  

2、每一件事情都是在尋找平衡點。你也許會認為把你的系統和某個操作系統或某個Linux發行版牢牢地綁定在一起是一個好主意,但事實上這跟把它們完全隔離一樣糟。如果實在有必要,你可以進行分層,并使用一點間接性。


  

3、這并不意味著你的系統必須是平臺無關的。其實我們的目的很簡單:一變二,二變二十,一個系統必須可以應對各種突發事件。也就是說,如果一個系統管理 員被公共汽車撞了,你有應對的方案!如果掛載的硬盤出現故障了,你有應對的方案!如果某些人運行了rm -rf /,你也有應對的方案!增量的進行變更。記得安全更新,以及保持內容更新。


  

使用自動的,可重復的構建過程


  

1、不要手動構建任何東西。如果你一定需要手動構建,那么就做兩遍,在做第二遍的時候把用到所有的命令都提取出來。


  

2、下面這一點十分重要:將新硬件上線到生產環境的過程不應該超過15分鐘,而且這個過程必須足夠簡單。否則,當一個服務器出現故障,而沒有人知道如何更換它的時候,你就該倒霉了。


  

3、下面這一條是普世真理:這個世界上不存在“一次性”的服務器構建。即使你的服務器只需要構建一次,但只要你構建過一次,就一定會有第二次。比如,當它損壞的時候,或者你必須進行一次重大的升級才能讓它在在接下來的兩年時間里更加穩定的時候。


  

4、測試,檢查新構建好的服務器。這應該是比較容易的,因為你的構建過程都是自動化的,對吧!


  

5、腳本化的構建,意味著從某個Linux發行版的V3升級到V4應該是很快的。安裝V4,對腳本進行測試。如果有問題,參考文檔并修復它,直到它可以再次正常工作。這最多應該是一個星期的工作,而不是一個長達一年的浩大工程(因為那時,剛剛完成的V5已經發布了!)


  

使用冗余


  

1、容易重新構建,并不意味著你可以忽視冗余。跳轉盒,郵件服務器,計費網關,等等。如果其中的一半掛掉了卻并不造成客戶的宕機,生活將會變得更加簡單。


  

2、按照以上方針來做的話,當某個設備在凌晨3點出現故障的時候,你可以“以后再處理那個出現故障的設備!”,把冗余的機器先替換上去。


  

3、下面這一條是個聊勝于無的解決方案:Rsync。DRBD也許也不是一個完美的解決方案,但是它可以提供令人稱奇的服務。


  

使用備份


  

1、備份是個嚴肅的話題。使用硬盤,燒錄磁帶。壓縮它們,移動它們,并行地運行。對每一樣東西進行備份!


  

2、如果你的構建過程是自動的,整個過程都可以被備份。如果到目前為止的幾條你都做到了,那么一個真正的“災難恢復”計劃也許并不是那么遙不可及的。


  

監控正確的東西


  

1、監控你能監控的所有東西,而且要用正確的方法來進行監控。如果你的NFS服務器掛掉了,不要讓你的監控工具發送1000條警報。如果對你的系統來 說,超時的警報沒有什么實際意義,那就別讓它發。要針對各種具體的情況進行成功性測試:是的,這個服務可以進行一個新的TCP連接,它甚至可以響應,但是 它還記得它要做什么工作嗎?


  

2、如果你有500個Web服務器,其中一個掛掉了,你可能不必馬上知道這個情況。但是,如果負載均衡器沒有把這臺機子踢出去,導致錯誤報告出現在了用戶的屏幕上,那么你必須知道這個情況!


  

有關數據圖形化,歷史數據


  

1、圖形的作用是讓趨勢可視化。歷史數據的作用是讓你對數據進行精確的分析。不要把這兩者混為一談!對圖形進行目測,很容易獲得錯誤的數值。許多站點都 使用rrd類型的系統或其他的數據聚合系統,此類系統按照時間對數據進行平均化處理,然后保存在存儲空間中。這不僅僅是難以閱讀的問題:這根本是錯誤的!


  

2、如果你要瀏覽數百張圖才能精確地對一個問題進行定位,那真是糟透了。想要找出極值?請使用腳本提取數據。


  

3、如果你必須使用圖形來解決問題,盡量把各種高級的概念整合到一個單一的頁面中,然后讓這個頁面鏈接到擁有具體信息的子頁面中。如果你在數據庫負載中 可以看到一個峰值,你可以點擊這個頁面對那些數據庫進行概覽,然后找到那一兩臺可疑的機器?;鏡睦砟釷薔】斕廝跣》段?,盡可能的減少猜測。


  

日志記錄,使用多個數據流


  

1、無論是獨立工作還是與開發部門合作,都要把盡可能多的有用的信息記錄到日志中。無論是分析之后再保存,還是直接扔進數據庫中生成報告,這些都無所謂。信息終歸是有用的。


  

2、有用的例子:頁面呈現時間(哪個頁面?哪個設備?),面向用戶的錯誤,數據庫和內部服務錯誤,帶寬使用率等。


  

3、建立圖表,報告,并對產生的歷史數據進行比較。


  

4、報告是十分重要的。每周或每天對你的基礎設施變更進行匯總。


  

數據存儲方式,數據庫


  

1、誠然,數據庫運維是一套完整而獨立的知識體系。但是有時,你不能把一切都丟給你的DBA。


  

2、擁有多個冗余的數據庫會給你帶來很多好處。對于一個龐大的Oracle實例來說,從前,很多運維工作需要好幾個小時的關機維護時間;而現在,完全可以在服務運行的同時進行。MySQL和數據庫復制功能是一件奇妙的事情。


  

3、和DBA們一起努力,盡量為可能會發生問題的數據庫爭取到最好的硬件。RAID 10,大量的RAM,高速硬盤,乃至于強悍的RAM磁盤和SSD。運維人員對提供商要貨比三家,這樣可以減輕DBA對硬件的恐懼。從長遠來看,找出哪個品 牌的硬件更加優秀會節省大量的資金。


  

4、數據庫配置一直在改變。現在出現了HiveDB,MySQL Proxy,DPM這些軟件。我們絕對應該對巨大的數據集進行分割。我們也可以考慮一下像starling和Gearman這樣具有一定創新性的軟件。了 解一下這些軟件的用途,同時,了解一下并不是一切東西都要保存在一個數據庫中的。


  

5、善用你的過濾器!如果這些數據很重要,應該對它們進行備份!單片的NFS服務器的快照很奇妙,它并不是一個備份!


  

6、可以慮一下替代的解決方案。MogileFS現在變得越來越好了(參考閱讀:分布式文件系統試用比較)。實際上,還有其他類似的項目可以免費(或廉 價)地維護大量的存儲文件。類似的系統基本上都是是為youtube.com、archive.org等站點而開發的。我們最終會讓廉價的NFS過濾器成 為標準!


  

多一些橫向擴展,少一些縱向擴展


  

1、橫向擴展是我們應該走的路。應該使用常規的(即:可用的,價格適中的,標準的。而不是特便宜的!)硬件,然后和大家一起努力,確保各方面都可以進行橫向擴展。


  

2、橫向擴展從兩臺機子開始。另外,進行冗余的時候也會涉及到橫向擴展。


  

3、盡可能的橫向擴展,但是不要傻乎乎的擴展。在MySQL復制中有一個經典的白癡擴展的例子:使用一個master對很多個slave。所有的 slave必須完成全部的寫入,而寫入次數是與讀取次數成比例增加的(大多數應用都是這樣)。也就是說,你添加的slave越多,通過添加slave擴展 的資源就越少。


  

4、留意一下替代的解決方案。按照用戶或區域對多個數據庫進行劃分,同時避免增加過多的slave。實際上,有許多種方法可以達到這個目的。


  

5、一切都可能擴展!路由器,交換機,負載均衡器,Web服務器,數據庫,等等。


  

6、記得縱向擴展嗎?以前那些邪惡的大型機們有很多核,很多IO板,配備了非常昂貴的存儲設備。而現在,多核這個概念開始蔓延了。


  

7、RAM是廉價的。


  

8、將以上兩點合并起來,這意味著你只需要再次合并服務就可以了。這兒有一個負載均衡器,那兒有一個Web服務器……如果一個應用程序可以使用許多個 CPU(比如apache),那么這是完美的。如果它不能(比如memcached),那么你最終可能會由于離散的服務太多而浪費掉大量的可用資源。


  

9、作業系統(job systems)也許可以填補這個鴻溝。哪里的核心的越多,哪里的工作線程就越多。


  

緩存


  

1、對于開發者和系統運維人員來說,緩存可是個好東西,值得大力發展!的確,它是不可思議的。它是與眾不同的。有時你可能必須要為它做一個權衡。有效地 使用緩存可以讓系統的整體性能提升10倍之多。對于你當前的系統來說,這是一個巨大的“放大鏡”,并且,它的成本在總成本中只占很小的一部分。


  

2、Memcached。它可以為服務提供緩存,讓數據庫結構非標準化(這可以提升性能!),對squid緩存進行優化,甚至可以提高操作系統緩存的利用率。


  

3、測試它,玩弄它,并打破它。使用緩存會帶來新的問題。要做好準備。


  

4、可以使用Starling, Gearman, The Schwartz等工具。作業系統可以給應用程序提供更多的靈活性。工作線程可以一次性地產生出來,也可以是持久的(載入緩存數據,準備數據等)。它們可 以在不同的硬件上,它們的地理位置也可以不同。它們既可以是同步的,也可以是異步的。


  

5、維護這些東西是一個運維人員的問題。使用它們既是開發者的問題也是運維人員的問題。


  

6、當用戶點擊“給我所有的朋友發送郵件”的時候,把這個工作列入計劃,然后馬上說:“OK,已經完成了!你的朋友馬上會收到你的郵件!”——通過異步化的方式來處理這個工作。


  

7、作業系統是銜接各個服務的一個場所。博客投遞-〉IM通知,定期計費-〉收費服務,網關認證等。


  

8、容易擴展。在請求進入的地方會有一些瓶頸,所有的工作線程必須要做的事情就是“拉”。這個是相對于HTTP中大量推/拉的狀態而言的。


  

安全和巡查


  

1、一定要安裝安全更新!這十分重要!有很多瘋狂的網絡專家致力于在盡可能短的時間內給你提供這些更新。不要因為你害怕改變而讓他們白白地付出勞動。


  

2、安全性也是分層的。明白你能確保什么,以及不能做什么。MySQL有密碼訪問機制,并不意味著可以允許直接通過互聯網來訪問它。


  

3、在SSH上禁用密碼。使用經過加密的passphrase密鑰來進行身份驗證。遠程的用戶無法猜出你的私有密鑰。他們必須從你這里才能得到它。把它保管好。做好這點,就沒必要在防火墻中關閉你的SSH端口了。


  

4、搞清楚你的應用程序是如何工作的,它具體需要做些什么,并相應的進行調整。比如說,如果你的應用當中,只有付費頁面和Twitter投遞服務是需要 連接外部互聯網的,那么就把它們做成工作線程。將這部分工作線程放在特定的設備中,讓它們只能訪問特定的主機。這可以神不知鬼不覺地把你的網絡的其余部分 ?;て鵠?。


  

5、對于PHP站點來說,以上這些建議尤其重要,但是在其他地方,它們也可以發揮作用。如果有人要入侵,那么多半是通過你的應用。即使有人從前門入侵了系統,也要讓他們花費很大精力才能進入保險箱。你需要確保的是他們無法將數據帶走或上傳至別的什么服務器上。


  

6、除了這些具體的建議之外,你還應該多讀一些資料。自己判斷,自己動手測試。如果你不知道一個安全模型是如何工作的,一時半會兒可能問題不大,但是這就會導致你不知道它的限制在哪里,甚至于無法判斷它是否在工作。


  

7、基于測試,理論,攻擊樹的安全機制是不會在背后給你一刀的。當人們構想出模糊的安全模型的時候我也很喜歡它,但是像我這樣的普通人都可以把它弄的支離破碎。


  

8、盡可能地進行巡查!登錄,退出,以及使用的命令都要進行審查。對面向外部服務的所有訪問,包括所有在請求中指定的參數,都要進行審查。對于你的應用程序來說,找出極值,然后徹底禁止輸入超出范圍的值。做你能做的所有事情,讓數據以可追溯的方式工作。


  

9、如果你懷疑某些東西可能會被破壞,應該采取適當的預防措施,最好懂得一點計算機取證方面的知識(或者聘請一個專門從事這項業務的公司)。通過移除可 疑的網絡訪問來做出響應,通過一系列的控制臺或直接通過終端來檢查整個系統。在已經被破壞的機器上,避免使用任何的服務,配置文件,或數據。很多人都是 “清除了一個木馬”,但是不知道它是怎么進來的——這樣并不算真正地清除了這個木馬。


  

10、安全實際上是一種權衡。如果你做錯了,開發者和用戶們都會“揭竿而起”:他們會找到一些方法來繞過安全機制。如果他們可以繞過它,那說明你的工作并沒有做好。如果他們不能繞過它,那么他們也許會放棄,然后離開。


  

11、緊抓訪問控制。這意味著IT運維人員必須要為已經鎖上門的“房間”提供一些窗戶。不讓開發人員進入生產環境,意味著他們必須抹黑解決難題。你的確不能讓開發者們直接對服務進行修改,但是你可以提供日志工具和調試工具等等。對于各種產品來說,這些都是成功的秘訣。


  

12、如果你有安全團隊,取證專家,或其他人手,那么你盡量不要接觸那臺機器,把它隔離起來。這意味著不要重新啟動它來“清除一些奇怪的進程”。他們需要這些 證據。如果你必須這么做,就去做吧,但是要記得把系統徹底地清理干凈,打上所有的安全更新,盡量搞清楚他們是否已經破壞了重要的數據。做你能做的所有事情。