SLA（Service-Level Agreement）作為 IT 人你一定有接觸過，例如我們想租用某個數據中心又或者使用不同的 SI 服務，那我們便會留意 SLA 的百分比；不過大家又有沒有詳細計算過，例如是 99.998％ 的 SLA 代表了實際停機的總時數呢？我相信大家都沒有時間做這些計算。
今天筆者正在打量著數據中心的 SLA 有沒有「水份」，於是便決定在網絡上找尋一下計算 SLA 的工具，竟然發現了一個專門用來計算 SLA 的網站。該網站雖然設計上十分一般，然而卻提供十分詳細的 SLA 計算功能。
例如筆者在上方的「Change SLA level: 」一欄輸入 99.98 的話，下方便會即時顯示出每天、每星期、每月以及每年所代表的停機時間，通過此工具我們便大約可知不同 SLA 百分比背後代表的真正意義，有興趣的話不妨到以下網址一試。
以上資訊由www.hkitblog.com提供
最近 Facebook 上發起關注肌萎縮性脊髓側索硬化症（ Amyotrophic lateral sclerosis, ALS）的自發運動，Facebook 數據組分析這項全球火熱、在港稱為「冰淋城下」的慈善挑戰，發現原來香港亦開始有 IT 人互相挑機；由六月初到八月十七日的 Facebook 貼文之中，已有超過 2800 萬人參與討論這項冰桶挑戰，包括近況更新、評論及讚好挑戰人的貼文。
這項挑戰幾乎傳遍每個國家；而 Facebook 創辦人、微軟創辦人都已參與了有關活動；至於香港呢？原來都有很多 IT 人參與這項活動，其中大家較為熟悉的 Innopage CEO Keith Li 亦被人挑機。被挑機的朋友需於 24 小時內完成冰桶挑戰又或者選擇捐出 100 美元；當然你亦可同時捐錢又濕身啦。
以上資訊由www.hkitblog.com提供
【本報訊】主要為商業客戶提供寬頻及電話服務的九倉電訊網絡昨午「突然」跪低，連累不少商戶無法上網及打電話。有公司負責人批評，曾致電九倉電訊客戶服務熱線達兩小時仍無人接聽，擔心事件會影響其公司的商譽，甚至造成損失。九倉電訊昨回覆指，由於荃灣機樓在昨午四時出現故障，令部分客戶的話音服務受到影響，事故發生後約一小時已恢復正常，但未有回應寬頻服務的故障時間。而截至昨晚八時，仍有部分用戶指無法上網，相信寬頻服務曾停頓近四小時。
本報昨午接獲多名九倉電訊的用戶報料，指該公司網絡突然癱瘓，無法上網及通話。其中，公司位於太子的羅先生指，昨午三時許，其固網電話服務突然中斷，致電客戶熱線近兩小時又無人接聽，令他十分氣憤。「咁啲客打唔到畀我，以為公司有咩事，有咩損失係咪你負責先！」他又指，固網電話曾於下午約六時一度恢復，但不夠十分鐘再次失靈，令他感到十分無奈。
通訊事務管理局辦公室指，據九倉電訊提供初步資料顯示，該公司部分話音系統於昨午四時許出現故障，致部分用戶的話音服務受到影響，正搶修有關系統，會繼續與該公司跟進事件。當局已要求該公司匯報網絡和服務事故的指引，並於三個工作天內提交初步報告。
另一則有關報導:
Brace for the BGPocalypse: Big disruptions loom as internet overgrowth continues
現時商業應用，不論是手機又或是傳統在 Linux 或 Windows 之中的應用，都講求優化以希望提升流暢度；假如應用本身並不需經網絡傳輸的話，那應用出現緩慢情況便很大機會與應用本身的編程設計有關；然而假如應用本身需連到互聯網存取資料，例如是需要導入一些第三方的服務呢？
很多開發者都必定面對過此問題，此時你會認為「可能」是第三方的服務出現問題導致你所開發的應用出現時延；由於沒有方案能告知你正確原因，所以作為開發者很多時會靠經驗，憑感覺自行判斷；雖然無可否認，只要你能細心分析，的確能揪出導致時延的真正成因，但對於現今事事講求效率的商業世界，又豈會有這麼多時間讓你慢慢玩？！
一直以來，網管團隊總是將問題歸咎於應用程式。部分原因是目前的網絡是依據提供接入規則且定義明確的通訊協定構建的，而其他基礎設施及軟件組件則未遵循該協定。網絡封包數據是絕佳的資訊來源，可據其了解行為異常組件、效能標準及其他洞察來源。即使出現所謂的『推卸責任』，網絡亦能提供寶貴的明鏡，用以檢視應用程式的行為及效能。
而對於辦公室的員工，更甚者是程式員本身，他們總是將一切問題歸咎於網絡。如果應用程式執行緩慢，人們立即開始指責網絡，現在坊間已有方案提供所謂的應用程式感知功能，在出現問題的幾秒鐘內，我們便知道是否確實是網絡問題還是應用程式導致問題的發生，而不用深入檢測兩條路徑；最終令相關人士只需專注於一個方面即可，因此能夠減少解決問題的時間。
SolarWinds Network Performance Monitor（NPM）
而今次介紹的 SolarWinds Network Performance Monitor（NPM）便是其中之一。此方案可幫助網絡工程師解決了上述提及的業務關鍵性難題；有關方案加入了企業級深度封包檢測（DPI）和分析技術，解決了關於應用程式時延的網絡效能問題。最終讓任何規模機構的網絡工程師都可快速、輕鬆地識別網絡和應用程式回應時間問題，從而改善最終用戶的體驗品質及確保業務持續運營。
其實 DPI 技術並非甚麼新奇事，只是以往的 DPI 分析技術十分複雜，而各家廠商要將這些複雜的 DPI 技術加入到自家方案之中，自不然條件反射，對支援 DPI 技術的方案瘋狂定價，最終令尋常公司難以應付，導致 DPI 技術雖有但卻甚少被採用；而今次 SolarWinds 除了將此技術加入到今次介紹的方案之中，更打破傳統並繼續以較為合理的價錢銷售。根據官方指出現時方案不用 3000 美元即可，對比傳統 DPI 方案平得多！
通過 DPI 技術和分析感應器，SolarWinds NPM 能夠監測網絡故障、效能、可用性、流量和時延，讓網絡工程師能夠在問題影響應用程式效能、最終用戶和業務之前，透過持續監測線路中的封包又或者對 1,200 多個應用程式（例如 Skype、YouTube 及 Microsoft Lync）的應用流量進行檢測、識別和分類，及後更提供圖表和圖形檢視模式，讓你從中輕鬆檢視網絡和應用程式回應時間等相關資料。
以上資訊由www.hkitblog.com提供
從傳統轉到虛擬化的過程，有時候的確需要適應，虛擬化方便但虛無飄渺，要針對虛擬化作有效率的管理絕對是一門學問；然而虛擬化的確能節省一部份成本，而且虛擬化帶來的高效、靈活等，亦令數據庫虛擬化正在崛起；雖然就我們所知，各大數據庫方案廠商對於用戶自行將傳統數據庫放到其他品牌的虛擬化平台之中有一定保留，更甚者可能連支援都會失效，不過虛擬化所帶來的優勢，著實令企業不得不考慮將傳統數據庫虛擬化。
可能大家仍然就數據庫是否應虛擬化頭痛不已，不過今天便有一份針對此情況而進行的調查，或許可成為大家將傳統數據庫虛擬化的推動力。該調查由 Solar Winds 進行，並成功訪問了接近 500 位 IT 專業人士，其中大部份受訪者（76%）表示已將其數據庫虛擬化，並／或正在使用虛擬與物理數據庫混合的方式支持其工作環境。
撇開虛擬化的主要優勢，由於有著須維持高峰期的可靠度、擴展性、速度的關鍵業務性質，數據庫本質上已經十分複雜。一旦推出虛擬化就必須要考慮另一組複雜性。每個數據庫管理員雷達都應執行以下五個最佳方法，以確保數據庫虛擬化項目不僅能順利進行，而且可在虛擬化後保持最佳效能。
1. 不用害怕把一個具有較高事務負載的大型數據庫虛擬化。現代的虛擬化技術十分可靠、穩定，而且能提供接近在裸金屬伺服器上運行數據庫的效能。
2. 與虛擬化管理員發展良好的合作關係。如果不能對虛擬機 (VM) 資源作出修改，數據庫管理員便會缺少虛擬化最大的好處——靈活性。與在物理伺服器上作出人手改動的過程不同，在虛擬數據庫伺務器中，只需要按幾下，額外的 CPU、RAM 和存儲資源就可以被添加到其中。
3. 運用共享的指標，提高 IT 部門之間的相互合作。如能使數據庫團隊、開發人員、系統和虛擬化管理員間的理解一致，便能避免混亂和相互指責的問題。這些團隊可以合作，在考慮如伺服器資源競爭及 I/O 瓶頸等事宜時處於主動地位。
4. 將物理主機及 VM 資源指標與 SQL 查詢效能互相關聯。由於作業系統在 VM 上運行時不能準確報告資源指標，VM 指標可能帶有誤導成份。將指標放到查詢效能，便能快速鑑定由鄰近噪音、VM 事件及資源配置等所導致問題的影響。
5. 監測虛擬化前後的 SQL 反應時間。要看到反應時間，必須擁有合適的工具。該數據為數據庫效能能否得以保持及提升提供證據，並在發生效能問題時，分析歷史能快速找出問題然後解決問題。
每個 IT 專業人士及機構的數據庫效能管理
由於更多的數據庫都正在進行虛擬化，軟件授權的方法亦須演變。傳統上，企業軟件一直依核心授權。然而，在虛擬世界，因為核心數量很容易便可以被改變，所以會產生影響部署及擴展兩方面的授權問題。現時坊間便有一些方案能協助大家全面了解 VMware 上的數據庫效能問題，並實現這種全新的授權。現在，由於定價以實例為基礎單位，任何規模機構的數據庫管理員都能夠有效和高效地監控、測試及優化所有數據庫實例的效能。
以上資訊由www.hkitblog.com提供
