作者： baiyuzhong分類：選題策劃[, , , ]新增評論
文/餘沛
時代變化所引起的運維視角不同
在計算機應用的發展歷史中，運維工作一直是必不可少的重要環節。無論在什麼年代、什麼場景，保證服務的正常可持續執行都是運維的最終目標。但在不同時期，運維實施的手段、關注的重點卻有所不同。
在計算機應用的早期，計算機仍然是一台昂貴且嬌氣的裝置，那時非但應用場景遠沒有今天這樣廣泛，網路體系也沒有今天這樣的複雜和敏感，電子技術也遠不如今天成熟。在那個時期，運維關注的重點通常以硬體為主。除了計算機本身的硬體，與之相關的電力及其他配套裝置也在範疇之內。
到了中期，計算機由大、中型轉向微型化，區域網路發展迅猛，金融、通訊、電力、航空、學校等各類商用、民用場景的快速跟進，不但使得計算機的總體使用量大增，而且單位範圍內需要管理的計算機規模也在不斷加大和複雜化。在這個過程中，形成了以裝置管理（包括網路裝置、作業系統管理）、資料儲存與容災、目錄與內容管理、資產管理和資訊保安管理為主的、一體化的早期運維體系。
再到後來，網際網路模式佔據了最新潮流且至今未衰，科技和業務模式帶來的變化，也催生整個運維體系的轉變。早期一體化的運維系統被更加明確與細緻的分工所拆散。idc代替了自建的區域網小機房，使得通訊主幹的運維工作從原有體系中剝離；規模的**式擴大也使得即使同一idc內的區域網管理也更加複雜；安全的挑戰越來越嚴重，使得傳統基於區域網粗暴隔離思想的安全管理無法滿足開放網際網路時代的要求。
同時，人們也發現一些運維事務簡單地隨規模增長而線性增加（如資產管理、自動裝機等），本身不具有複雜度的變化，而另一些與業務相關的事務，則隨著規模增長複雜度成倍增加。
由於這些原因，使得運維工作開始明確分工，逐項剝離。系統、硬體、網路衍生出專職的系統管理員（sys）職位，安全也開始從運維獨立，資產管理、自動裝機等工作不再是運維工程師關注的重點。相反，與業務可用性緊密關聯的排程、監控、關係管理變得更加上層。
規模變化所引起的運維手段不同
在網際網路時代以運維的角度來看，對於不同規模、場景的應用，運維所處的位置、發展的歷程也有一定差異。
百台以下規模的運維
一般來說，小公司有幾台到數十台機器的規模，運維主要關注的點還是在系統及應用服務的穩定性上，不一定有專門的運維人員，通常是rd自行維護所開發的系統。不會去系統化地梳理各項運維指標，而是以人的經驗為主，來判斷和設定系統正常與否的標準。
在這種場景下，運維工作通常扮演的是「救火隊員」角色，一旦出故障，運維人員才開始跟進、解決。故障解決也基本是case by case的形式，不太會有流程化的總結和問題庫、知識庫。其運維方式無非是靠手工，輔以一些自行編寫的小指令碼。
這種方式雖較為原始，但對許多初創公司來說，也算是一種低成本下可靈活實施的手法了。
在這個階段，一些小巧的工具顯得很有特色，例如在系統管理方面，能夠同時對多台機器進行操作的pssh、omnitty等，在資料庫管理方面，phpmyadmin等足以應付平時的工作。
千台規模的運維
當規模增長到一定程度，依賴手工管理自然已無力應對。許多網際網路公司的伺服器早已跨入幾百甚至千台規模，指令碼化、批量化管理佔據非常大的比例。
同時，在這種規模下，按垂直劃分的運維工具也開始大量應用，無論是自行開發的還是利用現有開源軟體，針對某一特定領域的管理系統顯得尤為重要。
在這個階段，運維主要精力放在監控（採集、報警、展現圖表）、部署上線（配置管理）、資料備份方面，因為機器數量龐大，所以集中式的操作平台是必備的，針對不同的領域，也有相當成熟的開源軟體可以直接使用。
在監控方面，nagois和catci應用最為廣泛。
作為一款開源的免費網路監視工具，nagios能有效監控windows、linux和unix的主機狀態、交換機路由器等網路設定。在系統或服務狀態異常時發出郵件或簡訊報警，在狀態恢復後發出正常的郵件或簡訊通知（如圖1所示）。
圖1 nagios報警通知介面
nagios的特點包括以下幾方面。
可以通過多種協議對目標伺服器進行資訊採集（smtp、pop3、http、nntp、ping等），避免在目標伺服器安裝客戶端帶來的風險。
本身體系非常開放，可以自定義編寫採集指令碼以監控系統、應用的狀態。簡單的外掛程式設計使得使用者可以方便地擴充套件自己服務的檢測方法。
具有並行服務檢查機制，同時具備定義網路分層結構的能力，用「parent」主機定義來表達網路主機間的關係，這種關係可被用來發現和明晰主機宕機或不可達狀態。
當服務或主機問題產生與解決時將告警傳送給聯絡人（通過email、簡訊、使用者定義方式）。
可以定義一些處理程式，使之能夠在服務或者主機發生故障時起到預防作用。
自動的日誌滾動功能。
可以支援並實現對主機的冗餘監控。
友好的web介面用於檢視當前的網路狀態、通知和故障歷史、日誌檔案等。
nagios 和cacti是經常配合在一起使用的監控系統，nagios適合監視大量伺服器上的大批服務是否正常，重點並不在圖形化的監控，其整合的很多功能例如報警都是cacti沒有或者很弱的；cacti主要用途還是用來收集歷史資料和畫圖，因此介面比nagios漂亮很多。
而在部署方面，puppet是用於大規模集群管理的神器。其本身使用ruby語言開發，基於c/s架構（如圖2所示）。在每台機器上部署的客戶端每隔乙個指定的時間會連線到master檢查資源變化情況，若資源發生變化，將按配置動作進行相應的操作。
puppet將所有可操作物件抽象為資源，目前涵蓋了40多種，如：file、user、group、host、package、service、cron、exec等。
puppet 通過抽象資源的方式，使得每台機器能夠「清楚」其本身「應該」是什麼「狀態」，而客戶端根據當前是否達到這個狀態決定採取指定的動作。這使得puppet 不僅可用於傳統的應用部署，而且通過合理的手段，也能夠將比應用部署更頻繁的配置管理一併解決。甚至可以在master端外接自己開發的平台，通過集中配置方式管理各項「資源」，實現高度靈活的自動化管理體系。
圖2 puppet master-agent結構圖
這類垂直管理系統的使用及活躍，極大減輕了運維人員在重複性、批量化操作方面的負擔，能夠非常有效地在各自領域完成既定的運維子目標。但其缺陷在於只能針對某一垂直領域的特定問題進行高效處理，對於它們之間的關聯性很難應對。因為運維的本質是保證服務的可用性，而自動化運維則是在完全保證這一前提下，盡可能將需要人干涉的部分處理掉，所以判斷其優劣的標準則是——與人工處理比，對服務的保證有沒有提高。
如果僅是解決報警、部署這些單一動作，後續仍然需要人去處理、去關注、去判斷的話，就離這個目標還有距離，談不上真正的自動化，只能算是工具化。
上萬台規模的運維
對於規模已達到上萬台、十萬台的各網際網路巨頭來說，其業務間交織縱橫，甚至某一單一業務內部可能也已非常複雜。傳統的開源軟體大多已無法覆蓋這樣場景下的運維工作。另外，在這個階段，除了各服務自身的監控資訊、部署資訊等需要運維外，服務與服務間的關聯關係、 上下游變更所帶來的影響、業務的串聯也顯得尤為重要，它們經常是牽一髮而動全身。
網際網路巨頭都在根據自身的業務特點，紛紛自行研發成體系的自動化運維平台。在這個階段，各公司更關注各平台之間的聯動性，更關注運維的本質——即真正的自動化：不僅是自動發現問題，更要能自動協助解決問題，以保證服務的穩定。
各大公司自主研發的歷程，是由單一的任務解決向平台化過渡，運維關注的重點也由可用性發展到易用性、靈活性，最終實現自動容災，以及資源可伸縮程序。
以 google為例，能夠將url（統一資源定位）的概念用於運維體系，將每一種服務（無論對內、對外）都抽象為一種資源，提供這種資源的服務將自身資訊寫入，使用方通過url來得到資源的實際位置，當資源發生變化時，使用資源的一方能夠感知，並根據自身業務做出相應的動作。
國內的網際網路公司也有不少家正在往這個方向追趕。這些自主研發的智慧型運維平台，除了像開源軟體那樣能滿足常規的監控、部署備份等需求外，更能站在「服務」的角度關注其最終狀態。
例如，某項服務有n臺機器提供負載均衡，會向某個狀態池集中寫入其狀態，相關的監控通過收集這些狀態，按照指定的配置規則進行動態監控。一旦發現狀態異常， 如負載過高時，能夠觸發部署動作，從資源池中再拉幾台機器進行部署。部署資訊都在狀態池中，該安裝什麼軟體、什麼版本、如何部署都由系統自動完成。
完成部署後，新機器上的服務被啟動，啟動時再向狀態池中註冊自身，負責負載均衡的裝置感知到關注的狀態資訊變化（有新機器加入）後，重新整理配置將新機器的服務納入對外服務列表。
自動化運維與基礎架構之間的關係
隨著運維技術的進步以及運維體系的完善， 自動化運維作為乙個既不算嶄新卻又充滿活力的方向，也隨著規模、場景的變遷迎來新的挑戰和變化。運維的活動範圍，更多介於硬體與作業系統之上、應用之下。 其與基礎架構之間也像是人的兩條腿，相輔相成，總是一前一後交替往前推進。
基礎架構決定運維方向，同樣運維體系又使得基礎架構發揮最大收益。
故而自動化運維平台的根本，不是說僅僅去把操作介面化、oa化，讓人們簡單地在web上點選按鈕就能管理系統。而是在底層的基礎架構與上層的業務系統之間搭建乙個良好的橋梁，使得業務系統能夠充分、穩定卻又不必過度關注底層架構特性。
這時的運維，已不再僅是消除故障、打掃裝置的後置服務，而是能夠在業務開發時期介入、伴隨整個業務共同執行的一種特殊服務。以google的borg為例， 通過引入一套標準庫，按照指定的規範編寫應用，使得編寫出來的應用本身就能滿足對應基礎架構下的可靠運維，無論是統一的運維狀態介面，還是災備、自動縮擴容，以及變更時的關係調整，都能夠很好地應對。
雲計算帶來的變革與挑戰
虛擬化、雲計算的發展，又使得運維工作產生了進一步的變化。中小公司不必再考慮諸如容災、備份方面的事宜，資源的按需交易不僅使得資源不再浪費，也使得業務調整時的伸縮變得更加容易且經濟上更加划算，的確大大簡化了傳統意義上的運維工作，是未來中小網際網路公司發展的重要趨勢。這時，運維工作的重點將轉移到平台架構的選型與優化上來，運維需要更關注業務特性及與之相關的技術體系，幫助研發決定各類雲服務的選型、評估其對業務的適用性。
從可口可樂廣告語的變化談品牌定位
品牌定位是指企業在市場定位和產品定位的基礎上，對特定的品牌在文化取向及個性差異上的商業性決策，它是建立乙個與目標市場有關的品牌形象的過程和結果。換言之，即指為某個特定品牌確定乙個適當的市場位置，使商品在消費者的心中占領乙個特殊的位置，當某種需要突然產生時，比如在炎熱的夏天突然口渴時，人們會立刻想到 ...
市場調研從可口可樂廣告語的變化談品牌定位
中國快速消費品流通網 1188031981 作者 systemmaster 文字大小 大 中 小 在世界各地大行其道的可口可樂在其百年的發展程序中，廣告發揮了至觀重要的重用，緊貼市場的廣告策略為其建立最有價值品牌地位功不可抹。而作為廣告核心內容的廣告語則是品牌定位的一種明確表達方式，通過各種傳播媒介...
從本案談預期違約與不安抗辯權
孫建平 案情 2004年4月27日，山東省東營市某化工公司與阜新某裝飾公司簽訂了購銷合同。合同約定 購銷貨物為60噸，單價12500元 接需方 通知送貨 結算方式為5噸鋪底，滾動付款 化工公司的解釋為第二次貨物到達驗收時付第一次的貨款，第三次貨物到達驗收時付第二次的貨款，以此類推 貨到兩月內結算所有...