人生就是一段充滿苦與樂的旅程，在人生當中有痛苦也有歡樂，痛苦不一定是負面的，有的時候還會使你進步，增強應變能力。對一般人而言，人生一定要是快樂的才是有意義的，可是你仔細想想，有誰不是因為挫折而更加的堅強呢？走過運維的風風雨雨，與大家一起回憶其中的苦樂甘甜，那何嘗不是一段段激情燃燒的歲月呢，記載著你我成長的故事。。。。。
一、不要輕易地放棄
運維中時常會面臨各種各樣的挑戰和難題，很多時候感覺自己快陷入絕境了，很多時候靜下心來思考問題又能出現偉大的轉機。任何時候都不要輕易地放棄，也許你只要再深入一步看到問題的某個細節，事情並沒有你想象的那麼複雜。
一台aix生產伺服器上裝有db2資料庫，由於開發人員的誤操作，造成乙個重要表的被刪除，需要進行恢復。為了安全，不能在生產環境的資料庫上進行操作，需要放到測試環境進行恢復。問了一下開發人員，表被刪除的時間為5月31日下午8點35分左右，現在已是晚間9點05分了，距離事故發生時間點已過去半個小時，根據安全等級規定需要在兩個小時內進行恢復。這種狀況的恢復是典型的前滾恢復，需要使用完整的資料庫備份和日誌相結合，然後將資料庫或者被選擇的表空間恢復到某個特定時間點。如果從備份時刻起到發生故障時的所有日誌檔案都可以獲得的話，則可以恢復到日誌上涵蓋到的任意時間點。
首先檢查了一下資料庫的備份情況，上週日有乙個完整備份，從完整備份到故障點的所有日誌都完好的存在，心裡總算松了一口氣，看來問題似乎很好恢復。
接下來在測試環境找一台與生產環境db2資料庫版本一致的aix小機，把完整資料庫備份和相應日誌傳輸過來。（注：不同的資料庫版本，物理日誌格式不一樣，在做恢復的時候容易報sql2547錯誤，從而不能前滾日誌）從生產環境傳輸到測試環境的完整備份和日誌，大家還要注意修改檔案的屬主和許可權，以避免無法讀取的錯誤。
緊接著，進行完整備份恢復，並前滾日誌到指定時間點，一切都很正常順利。然後告知開發人員進行檢查，過了一會，開發人員反饋說沒有查到資料，仍然是刪除後的狀態。這回有點納悶了，怎麼可能會沒有，時間已過去了半個小時，真是讓人著急啊。旁邊的**響個不停，聽的人腦袋都要炸了。接著又將前滾日誌的時間點提前了半小時再恢復，還是沒有資料，這時有開發說可以手工錄入丟失的283條資料，難道要放棄資料恢復麼？心裡糾結的七上八下，但是我腦中閃過乙個念頭，不能輕易放棄，也許是我們遺漏了某個細節。於是靜下心來思考了幾分鐘，心裡突然有點懷疑，會不會是兩個小機的時間不一致啊，因為前滾時用的是local time
立即檢查兩個小機的時間
sun jun 4 15:43:47 beist 2013 （生產機時間）
sun jun 4 15:44:01 cdt 2013 （測試機時間）
注意紅色部分，beist和cdt並不是同乙個時區，beist與cdt之間相差8個小時。因為時區的不一致導致時間不統一，所以出現了問題。立即修改了測試機的時區並同步了一下時間，再來一次恢復，果然資料有了，表也恢復了，一切ok
細節決定成敗，遇事一定要冷靜沉著，問題面前不要輕易的說放棄。
二、直面問題---解決與發現
運維當中，我們通常會面臨解決不完的問題，身為救火隊員的你可能天天吃力不討好，被無數投訴和報表弄得疲憊不堪……面對問題關鍵的是我們的心態，是積極應對還是消極拖延，這關乎到我們的工作和存在的價值。
大多數時候，運維人員都在進行著簡單重複的工作，且很難得到終端使用者的肯定。曾有人用「窮忙族」形容運維工程師，工位上不見人影，一坐下**不斷，是不是你該解決的問題都有人來找你。這樣的場景，大家應該都有體會。不管你接手的問題是複雜還是簡單，我們首要的心態就是面對問題解決問題，而不是抱怨與逃避。做運維時，有時候很怕接到自己搞不定的問題，害怕客戶投訴也擔心自己出醜丟面子。一次接到一任務，要求幫客戶排除一新上資料庫伺服器網絡卡不穩定的問題，這類問題大家一般都往網路上想，但經過網路部工程師檢測網路裝置、網絡卡和千兆網線都說沒問題，最後就推到系統部，讓查到底是什麼原因。其他人都覺得這問題不好辦，索性推脫了。當經理最後問到我時，我知道不能再推了，硬著頭皮說讓我看看，我覺得不是什麼大問題。心裡雖然打著鼓，但知道只能直面問題往前衝了，管他呢拼一把，大不了就是出回醜丟回面子。問明事情的緣由「原來是近期新上的db server伺服器，在壓測中發現網絡卡很不穩定，壓力測試剛剛進行十幾分鐘後，伺服器反應就變得非常慢，ping的時候經常丟包而且ssh連線也時斷時續」，剛開始我以為是高併發時導致的db server無響應，可是看了一下cpu、記憶體和硬碟io，發現都沒有達到較高值，甚至比我們的預警值低很多，而且監測也表明db伺服器剩餘資源很充裕！真是比較奇怪，那麼引起網絡卡不穩定的原因到底是什麼呢？
接著我又向相關工程師了解了一下情況，知道這台db伺服器是雙機熱備中的一台伺服器，前幾天剛做的2組千兆網絡卡繫結。據工程師說繫結前也做過壓測，沒有出現這樣的問題。難道是繫結設定的哪個環節出問題了？於是我決定從千兆網絡卡繫結進行詳細檢查。依次檢查了「ifcfg-bond0、ifcfg-bond1檔案沒有問題，又檢查了ifcfg-eth0、ifcfg-eth1、ifcfg-eth2、ifcfg-eth3檔案還是沒有問題，再接著檢查modprobe.conf配置檔案也很正常，最後檢查了rc.local檔案，發現bond0和bond1檔案中繫結的網絡卡有誤，造成乙個ip位址對應兩個不同的mac位址，顯然會造成網路的延遲和不穩定，這就跟以往的arp***比較像。最後終於發現了問題的癥結，成功解決了問題，為自己也為團隊贏得了好評和榮譽。
在一次次的解決問題當中，我們不僅在積累處理不同問題的經驗，更重要的是我們在得到客戶的認可和好的工作評價。所以不要怕問題，每個問題正是你的機會，發現並善於解決問題，我們也會得到客戶的肯定和個人的成長。
要記住，老闆需要的，是會解決問題的人。成功青睞的，也是勇於解決問題的人。
三、唯有學習，才能不斷提公升自己
作為一名運維工程師，通常需要掌握的知識比較雜,學習起來也感覺比較苦與累。
首先熟悉網路，對網路常用的負載均衡技術和分層架構要熟悉，結合**的內容發布、管理及靜態化技術、動靜分離方案，對主流網路裝置的配置和冗餘應用比較熟悉，並熟悉高併發下的網路壓力管理和流量控制。
其次熟悉伺服器的批量部署。相信許多企業裡都有自動化運維的需求，如批量安裝伺服器、批量裝應用、批量傳檔案、批量監控等等，網上也有n多相關的管理軟體，開源的如nagios、cacti、zabbix、zenoss監控，cfengine、cobbler、puppet統一部署管理軟體，商業的就更多。它們都很強大，當然也各有利弊，需要結合自己企業的業務應用去具體調整和配置。
再次就是熟悉資料庫的集群和後端儲存架構。通常資料庫和儲存都是整個it架構中比較核心的東西，資料庫的效能和高併發下的穩定對企業來講是非常重要的，它直接關係到使用者的體驗和價值轉化。還有儲存的效能將直接影響io，影響讀寫的速度。作為乙個運維工程師尤其需要對系統的效能、容錯、併發等有獨到的認識與解決辦法。還有就是需要對技術發展趨勢有很高的敏感性和預見能力，能不斷推進運維管理水平的進步並提公升運維的價值。
作為運維工程師，要想有更大的發展，不僅要懂技術也更需要懂管理，建立流程規範的it服務和支援，並實現行之有效的持續改善和對機制進行監控。運維上，好的管理制度和方法需要貫徹和堅持，如果不善於管理和監督，很難保證好的運維體系能運作下去，這對運維工作也會產生波動和影響。當然運維工程師也需要具有領導能力與團隊協作技能，能在關鍵時候對技術的選擇作出及時、有效的決定，來把握問題解決的方向。
學習中的苦與樂都是相對的。以苦為苦，只能使我們消沉；不以苦為苦，就會使我們無視自己的不足；化苦為樂，則可能使我們在學習和工作中取得超常的成就。
苦盡甘來，耕耘時的苦是為了收穫時的樂。運維的路上，有風有雨，更有我們的堅持，讓我們苦樂相隨！
【部落格話題】 人在囧途之「運維囧」
詳情檢視：
運維囧事 之重啟 重灌 換電腦
俗話說，運維工程師三件寶，重啟，重灌，換電腦。這三件百試不爽的法寶有時候也手背不靈光的時候，那個時候呀真是欲哭無淚。以下分別談一談我或我身份同事發生的事。這三件事有的並不是直接發生在我身份的，但確實我親眼所見或同事親述，但是為了保護同事的隱私，以下全部用第一人稱講述，有人不甘不擠兌胖胖不爽的人會說，...
運維囧事 之重啟 重灌 換電腦
俗話說，運維工程師三件寶，重啟，重灌，換電腦。這三件百試不爽的法寶有時候也手背不靈光的時候，那個時候呀真是欲哭無淚。以下分別談一談我或我身份同事發生的事。這三件事有的並不是直接發生在我身份的，但確實我親眼所見或同事親述，但是為了保護同事的隱私，以下全部用第一人稱講述，有人不甘不擠兌胖胖不爽的人會說，...
運維（1）什麼是運維
運維，這裡指網際網路運維，通常屬於技術部門，與研發 測試 系統管理同為網際網路產品技術支撐的4大部門，這個劃分在國內和國外以及大小公司間都會多少有一些不同。乙個網際網路產品的生成一般經歷的過程是 產品經理 需求分析 研發部門開發 測試部門測試 運維部門部署發布以及長期的執行維護。對於初創公司，運維部...