12月3日消息：傳統(tǒng)數(shù)據(jù)中心指標不遵循"不讓任何人落后"的規(guī)則。IT指標的差距通常會導致一些投資性支出半被拒絕或半途而廢。
大部分IT企業(yè)的CIO已經(jīng)制定了以傳統(tǒng)數(shù)據(jù)為中心的指標，因為從歷史上看，它們服務得很好。然而，隨著移動數(shù)據(jù)與大數(shù)據(jù)的增多，歷史傳統(tǒng)的指標在IT度量系統(tǒng)發(fā)展中，差距越來越大。
這里介紹的5個新IT指標之所以好用，因為它們體現(xiàn)了IT對業(yè)務服務與成本效益的影響。聽起來有點違反直覺，但其已經(jīng)被證明為適用于分析重要數(shù)據(jù)中心性能，尤其在配合新舉措的場景下。
一、每位管理員多個數(shù)據(jù)庫實例
我在過去15年的研究發(fā)現(xiàn)，中小規(guī)模企業(yè)對數(shù)據(jù)庫的使用差異成為決定IT總擁有成本的指標。這也是許多數(shù)據(jù)中心經(jīng)理們指尖的IT標準：有多少Oracle數(shù)據(jù)庫，有多少Hadoop數(shù)據(jù)管理系統(tǒng)。
近年來，IBM System z Competitive Technology副總John Shedletsky分析了數(shù)據(jù)中心支出，顯示數(shù)據(jù)庫成本在總成本費用中占比逐漸走高，數(shù)據(jù)庫管理費用不斷上升，占比達到數(shù)據(jù)庫整體預算的50%以上。換言之，典型的大型企業(yè)每個應用程序需要花費20%的成本在數(shù)據(jù)庫管理上。
關鍵的可控變量是數(shù)據(jù)庫，很多情況下，不同廠商的數(shù)據(jù)庫是無法互相切換的。但仍然時不時有需要從Oracle遷移到IBM的需求——現(xiàn)有的工作負載可能更需要相同供應商的數(shù)據(jù)庫，不管是現(xiàn)在還是將來。然而大數(shù)據(jù)處理和其他舉措為數(shù)據(jù)庫選擇提供了有效、可擴展的企業(yè)標準，并且可以提高每管理員管理實例的數(shù)量。
數(shù)據(jù)中心經(jīng)理與CIO都驚訝于其未來的改進與行業(yè)標準會如何變化。隨著成本限制，IT組織沒有辦法再繼續(xù)高舉“沒有任何數(shù)據(jù)庫會被拋棄”的旗號。每管理員數(shù)據(jù)庫示例數(shù)量是一個能夠削減關鍵成本的有效指標，需要引起重視。
二、開發(fā)或錯誤修復項目中期的重要變更數(shù)
DevOps的問世清楚表明，數(shù)據(jù)中心是軟件開發(fā)的重要組成部分。DevOps以及靈活IT需要為這中新方法找到適合數(shù)據(jù)中心的指標。
許多敏捷專家建議，不要采取制約開發(fā)靈活性以及可能鼓勵錯誤行為的IT指標。其中一個例子就是開發(fā)成本指標，這種指標是以設計規(guī)范不會改變?yōu)榍疤帷?/p>
有效的指標可以用于測量線下與敏捷開發(fā)，協(xié)調(diào)線上bug修復，以及每個項目重大變更的次數(shù)。我使用這個指標進行調(diào)研，結果發(fā)現(xiàn)隨著時間推移，有效的敏捷開發(fā)可以提高每個項目重要變更的數(shù)量。
其他影響，如項目規(guī)�；驈碗s性，或者“明顯變更”偏差都可以測量，根據(jù)時間推移計算出平均值。相較于靈活IT流程，你會發(fā)現(xiàn)在項目中間出現(xiàn)的大幅修改數(shù)增加。
太多的“敏捷IT指標”認為變更是有負效果的，而現(xiàn)在需要將變更作為積極的影響。該指標不用于精細捕捉特定項目的問題，而是顯示平均每年這些項目的過程是否正常。采用敏捷指標的IT企業(yè)會因此提高敏捷業(yè)務范圍內(nèi)的響應。
三、不涉及中斷的性能下降
IT部門的重點通常在于防止針威脅公司的中斷故障，而沒注意到一些性能下降或性能逐步降低的情況。性能下降幾乎與服務中斷一樣重要。性能下降指標會告訴你問題有多大，而你的工作就是解決這些問題。
性能下降意味著特別難以修復的中斷將要出現(xiàn)。在IT范圍內(nèi)的性能下降通常涉及軟件層到硬件層的多種類型，使得定位原因遠比服務器被拔掉或網(wǎng)絡混亂來的難。
涉及到用戶滿意度時，性能下降無異于中斷。隨著越來越多企業(yè)依賴軟件與用戶進行交互，用戶不太可能忍受性能問題。
性能下降通常意味著成本制約已經(jīng)開始傷到快速擴張的骨頭，這對大數(shù)據(jù)項目成功的影響至關重要。外包或云主機可以延緩這種可能性，但數(shù)據(jù)中心外部的成本同樣會增加。
四、數(shù)據(jù)處理過程每個階段信息丟失的百分比
根據(jù)MIT斯隆管理學院與其他地方研究發(fā)現(xiàn)，公司合作伙伴并不認為IT能提供令人滿意的所有需求信息。
數(shù)據(jù)中心信息系統(tǒng)日積月累不斷增長，逐漸變得無法交付有效數(shù)據(jù)來滿足企業(yè)分析或作出決策，比如分析用戶的購買模式，或者其他形式大數(shù)據(jù)分析所需的數(shù)據(jù)。
答案最終指向一個指標，該指標需要能夠幫助確定IT是否已經(jīng)存在不足。原始數(shù)據(jù)需要經(jīng)過一步一步的處理，才能轉換為有用信息。數(shù)據(jù)的有用性取決于每緩解驟損失的有效數(shù)據(jù)量。
根據(jù)調(diào)查，數(shù)據(jù)輸入階段的主要問題是錯誤條目——大約會損失20%潛在有用信息。該階段通常是由于IT無法過濾輸入階段時的錯誤。
數(shù)據(jù)聚合會連接新輸入的信息和系統(tǒng)中已存在信息。不一致的數(shù)據(jù)無法與現(xiàn)有數(shù)據(jù)進行核對或修復，這樣可能導致大約15%的潛在數(shù)據(jù)不可用。
第三步是數(shù)據(jù)組合，該階段，輸入功能作為整體環(huán)境的分功能存在，例如在線交易處理，能夠處理一定的輸入操作。數(shù)據(jù)倉庫的重要功能就是數(shù)據(jù)匯總，但隨著時間推移，只有很少的信息需要進出倉庫。并不是所有信息都需要展示；只有大約20%左右的數(shù)據(jù)在數(shù)據(jù)中心或云服務中保持活躍，而這些數(shù)據(jù)可能對實際的業(yè)務分析并沒有幫助。
數(shù)據(jù)傳輸中，最常見的抱怨是及時性。這是一門藝術，確定哪些事情決策者必須迅速看到，哪些信息只需要每周或每月提交。信息損失問題十分明顯。該階段不必要的信息占比大約在15%至25%。
最后一步是數(shù)據(jù)分析，并且在該階段，決策者所關注的總數(shù)據(jù)展示工具還是存在缺陷。該階段大約有15%的信息會丟失。
IT組織報告說，大約有三分之二可能有用的信息會在數(shù)據(jù)處理的環(huán)節(jié)中丟失。設計一個指標用來指導每個階段的數(shù)據(jù)樣本，可以避免發(fā)生數(shù)據(jù)損失，IT也可以更方便地修復問題。這種監(jiān)控可以改變企業(yè)者對IT的看法，并對企業(yè)效益產(chǎn)生重大影響。
五、客戶滿意度
普適計算及其對所有用戶以及用戶與企業(yè)通過軟件進行內(nèi)部交流，意味著IT軟件對客戶以及用戶滿意度影響的占比越來越大。
即使實在今天，用戶滿意度調(diào)查與用戶調(diào)查仍然不夠靈活，不夠細致——他們會錯過發(fā)現(xiàn)用戶無法接受或者特別關鍵的部分。然而，即使是鈍器，也是有可能或獲得與正在發(fā)生的事情相關的信息或提示。此外，這個指標能提醒IT和企業(yè)利益相關者——最重要的是感知最終用戶，而不是短期內(nèi)企業(yè)或IT的意見。
