什么是網站運維(Web operations) ？運維，絕不是某些人眼中安裝系統、做幾根網線那么簡單? 除去應用開發和業務運營之外的保障網站能運轉的事兒都可能是運維工作的職責范圍。運維的工作包括(但不限于) 軟硬件部署、網絡管理、應用程序維護、安全、容量規劃、故障修復等等。
運維，有別于”運營”。在中文的語境中，運營更多和業務結合在一起的。而運維，則是偏向技術層面。
任何一個成功的站點都離不開一只優秀的運維團隊，盡管他們更多時候隱身在網站背后不為人知。
網站可用性
所謂網站可用性(availability)也即網站正常運行時間的百分比，這是每個運營團隊最主要的 KPI (Key Performance Indicators ，關鍵業績指標)。對于 Web 站點來說，傳統的那個 24×7 的說法已經不是很適用了，現在業界更傾向用 N 個9 來量化可用性， 最常說的就是類似 “4個9(也就是99.99%)” 的可用性?？匆幌卤?1 能更為直觀一些。
| 描述 | 通俗叫法 | 可用性級別 | 年度停機時間 |
| 基本可用性 | 2個9 | 99% | 87.6小時 |
| 較高可用性 | 3個9 | 99.9% | 8.8小時 |
| 具有故障自動恢復能力的可用性 | 4個9 | 99.99% | 53分鐘 |
| 極高可用性 | 5個9 | 99.999% | 5分鐘 |
根據墨菲定理的推論，世界上沒有 100% 可靠的 Web站點(除非不運行)。業界網站的可用性都是多少？引人注目的 Web 新貴 Twitter (http://twitter.com)， 2008 年前四個月的可用性只有 98.72%，有 37小時 16分鐘不能提供服務，連2個9 都達不到，甚至還沒達到”基本可用”狀態。電子商務巨頭 eBay 2007 年的可用性是 99.94%，考慮到 eBay 站點的規模與應用的復雜程度，這是個很不錯可用性指標了。Web 應用類型決定了不同的站點對可用性的依賴性是不同的。 要知道 4 個 9 的可用性實際上是很難實現的目標。至于 5 個9 的 Web 站點，一半靠內功，另一半恐怕是要靠點運氣。
(圖1 維基百科網站的一臺數據庫服務器的可用情況報告, 由Nagios的監控得到的)
多數情況下，網站可用性會是 SLA （Service Level Agreement, 服務水平協議) 中的一個重要度量指標，也是運維團隊向自己的客戶(更多是公司老板)的正式承諾?？捎眯允悄軌虺掷m改進的東西，KPI 制定者切不可獅子大開口，企圖一步登天，拍拍腦袋提一些不太切實的指標。運維團隊對可用性的承諾也不能開些空頭支票，到頭來兩頭難看。值得強調的是，如果是做第三方托管，更需要明確 SLA，明了第三方的服務能力，否則，費盡了九牛二虎之力終于保證了軟硬件網絡等環節都沒問題了，IDC 卻頻繁斷電或者IDC 出口網絡不可用，這也絕對做不到預期的高可用性。
提高可用性的一些常規策略有消除單點，部署冗余設備(或集群)，配置帶外管理網絡等，對可用性要求不高的網站這些可能足夠了。如果要提供更高的可用性，比如 4 個 9 甚至 5 個9，就不是簡單靠硬件就能做到的事情，還需要建立完善的流程制度、建立變更機制、提升事故響應速度等。正所謂是”沒有最高可用，只有更高可用性”。
一般來說，所有的網站運維人員都在追求網站的更高級別的高可用性，但是必須注意，這是以額外的軟硬件投入、更多的人力成本為代價的。成本與可用性之間也請做到良好的平衡，盲目追求高可用性是不可取的。
(補充：Twitter 的可用性現在已經有了很大提升，但是可以看到，可用性不佳并非一個網站的殺手，只要產品對用戶足夠友好，足夠有粘度，足夠不可或缺，那么可用性并非是第一要追求的運維目標。有些運維人員被 Amazon 的某年圣誕節期間宕機所造成的影響埋下心理陰影，其實沒那么可怕，如果真的覺得可怕，那么你可能被一些廠商銷售人員洗腦了。)
