一、服務化後業務運營遇到的挑戰

1.每天千億次級的服務呼叫中出現報錯時的問題快速定位
2.執行狀態的實時監控服務
3.服務於運營團隊精準營銷的業務指標實時呈現

如何結合團隊管理？

在服務化場景下為了快速定位問題，如何管理服務開發人員？
1.影響KPI：線上服務穩定性直接影響開發人員KPI
2.服務開發人員(服務owner)需要關注的2個點
（1）我的服務在什麼鏈路下被呼叫，呼叫的場景和資料是否合理
（2）目前服務呼叫趨勢怎樣？產生的瞬間峰值有多少？是否達到服務能力的最高水位？
3.業務架構師需要關心和思考的問題
（1）在當前的業務流程設計中，我的服務依賴了哪些應用、哪些服務？
（2）整個鏈路的依賴路徑是怎樣的？哪些服務對當前業務處理來說是最為核心？這些依賴如果出錯，會有什麼影響？
（3）一次業務請求處理的時間到底花在了什麼地方？是因為某一個服務耗時很長，還是某一個數據庫的訪問操作耗時最久，需要有一個清晰直觀的定位
（4）我所負責的業務鏈路中，過去一段時間哪些服務是出錯率比較高的，哪些服務是業務鏈路的處理瓶頸？

小結一下

（1）梳理依賴和依賴間的關係
（2）鏈路耗時和出錯追蹤及瓶頸定位

二、執行狀態的實時監控服務

鷹眼——阿里基於分散式日誌引擎的分散式服務呼叫鏈跟蹤平臺

業界類似平臺

三、鷹眼日誌埋點

四、TLog中介軟體

特性

根據使用者定製的處理流程
持續不斷地對目標機器生成的日誌資料進行解析、計算、入庫等操作
“所見即所得”的視覺化配置介面（Google Blockly）
零業務侵入（預先日誌埋點）、高效能（http://jstorm.io）、強實時性

可以方便編排的日誌分析模式

這裡基於Google Blockly完成的日誌分析模式的編排比較有意思。雖然Google Blockly最初只是一個用於低齡兒童學習程式設計的圖形化程式語言，但是可能是由於它的架構本身比較利於擴充套件和二次開發；因此可以方便的定義“programming”意外領域的規則正規化。除了TLog中使用的面向日誌分析模式編排的，Blockly甚至可以用來解迷宮。

https://developers.google.cn/blockly/
我感覺Blockly是提供了一個思路；而且這個jigsaw-style的前端確實蠻有趣的。其在TLog中的應用我覺得是比較深入的借鑑了Blockly的基本想法——通過視覺化的方式靠譜的傳遞某個領域模型(domain model)下的邏輯。在Tlog的日誌分析場景下，生成的自然就是類似於awk ‘{print x,$x,$y, $z}’；而其中的“規則”在不同的領域模型下是可以被重新定義的，比如給的demo就是在“程式設計”這個domain下定義的各種if else… 那麼就生成程式碼；甚至利用這個“視覺化規則”還可以生成跑迷宮的演算法。總之，我覺得可以認為Tlog對於Blockly的應用可以認為是在形式邏輯具體化方面給出了一個有著具體HCI的建議，類似的還有Drools以及它built-in的可以直接讀取.xlsx形式定義的規則。

五、業務應用場景

1.服務實時監控

解決問題：細化到服務粒度的監控

2.服務呼叫鏈跟蹤
呼叫鏈跟蹤的詳細資訊表頭參考

服務名及巢狀呼叫關係
伺服器IP地址
服務呼叫型別：HSF-RPC、Tair快取訪問、訪庫
服務呼叫結果（按服務型別會有不同列舉值）：OK、TIMEOUT、NOTEXIST
產生資料大小
具體服務和方法
處理時間

3.服務呼叫鏈分析

根據呼叫鏈跟蹤資料定期對服務呼叫資料進行統計和分析（for 業務架構師）

呼叫鏈分析表頭參考

服務巢狀呼叫層次關係
呼叫的服務方法、所屬應用、資源（資料庫、快取、檔案系統）
QPS當前值和峰值
呼叫次數計數
平均耗時
本地耗時
依賴度
佔比
強弱依賴標記

4.業務全息排查
關鍵資訊欄位

TraceID
RpcID
(New)DataKey
業務事件發生時間
(New)業務主鍵
被查詢的業務主鍵欄位
(New)業務詳情記錄
鍵值

5.業務實時監控