在上文中，我們已經梳理好了外部影響條件，即系統將面對一個什么環境，會處於一個什么境況。接下來，我們的目標自然是由外到內，梳理內部現狀。
同樣，此次我們也將依照如下要點梳理：
- 對系統自身情況的梳理
- 對系統的依賴方、服務方、基礎服務和后台服務分別梳理
- 對各方健康狀況的檢查
- 構建核心路徑流量模型
對系統自身情況的梳理
大家肯定發現我每次都喜歡先把要點大綱羅列出來，其實我的目的在於強調大促保障是一個很復雜且很重要的系統工程，如果沒有一個計划、大綱，想到什么就做什么，那這個大促，必然要不漏這，要不忘那。因此，就如同設計一個系統一樣，代碼未動，設計先行。
首先，我們需要對系統自身做一個全面的梳理，目的在於了解系統的現狀，知己知彼才百戰不殆。我們將從兩個方面開始，
一是受影響系統的梳理。我們根據上面梳理的活動影響業務，就能知道哪些業務線會受到影響。比如，最簡單的支付業務，就會影響如收銀台、收單服務和支付服務等，同時也會涉及到安全風控等。梳理一定要全面，最好是按照業務線來梳理，這樣才能保證不遺漏。這個環節一定要細心，如果遺漏了某個系統，它極有可能會成為雪崩效應的一個突破點。
此時我還要強調一點，作為系統的負責人，一定要有全局觀，任何系統負責人，都不能只考慮到自己系統的影響。如果抱着這點小影響，對自己系統的影響不大，但沒有站到整個第三方支付平台的角度去看待是否還是小風險、小影響，則極有可能埋下很大的安全隱患。雙11，只有整個干系系統都正常運轉，支付平台才能正常運轉。所以，再我們進行大促准備時，千萬不能有漏一點、馬虎一點影響不大，反正這是一個小系統的想法。
二是受影響的接口的梳理。所有服務最終還是由接口提供，因此這個環節也必須有。
三是梳理應用和接口的重要性。包括應用是核心應用還是非核心應用；接口是核心接口還是非核心接口。
對系統的依賴方、服務方、基礎服務和后台服務分別梳理
自身+依賴方+服務方+基礎服務+后台服務，這5個角度也是我們梳理系統的一個基礎，這樣才能全面，不遺漏，立體。因為任何一個系統要提供一個完整的服務必須需要上面5個部分參與。
依賴方。依賴方決定了我們系統是否可用、服務質量高低。比如會員系統提供會員相關信息，合同系統提供商戶合同相關信息，風控提供安全相關服務，各大銀行提供銀行卡支付服務等等
服務方。由於系統的最終目的是提供服務，因此服務需求方的信息自然需要清楚。第三方支付平台的服務方通常有電商平台，理財、第三方商戶和眾籌等。
基礎服務。這是系統的根基，沒有它們，整個系統將限於癱瘓。基礎服務通常分為六大類。
-
網絡層
需要考慮是否使用了，(1)CDN，通常有靜態資源的需要使用它；(2)負載均衡軟硬件，如F5，nginx，HAproxy，apache等；(3)網絡設備，如交換機，防火牆，路由器等；(4)web容器，如http服務器，apache,nginx; web服務器, WAS, Tomcat, jboss。 -
通信層
主要是一些消息中間件，如DUBBO、MQ、Zookeeper以及ESB等。 -
應用層
-
數據層
有數據庫和緩存。數據庫分關系型數據庫，如mysql, db2和oracle，和非關系數據庫，如mongodb,redis，hbase等。 -
監控層
主要是一些監控的系統。說到這里，順便提一下關於監控的話題。讀者可以依據下面去整理，有條理就不容易遺漏
任何一個系統的運行，都離不開監控，我們需要依賴它們來了解我們系統的現狀，那么一個立體的監控需要哪些系統呢？
通常來說，監控方面包括業務層面的監控、系統層面的監控以及一些基礎設施的監控。業務監控負責提供系統實時或者歷史的業務指標相關的信息，比如訂單量，各個渠道支付占比等，同時也是我們事后數據分析的依據。系統層面的監控主要是用來觀察系統是否健康，包括成功率、耗時等，主要是側重於業務應用方面。基礎設施的監控則側重於基礎服務的監控，如數據庫，交換機等。
監控類型主要有黑盒監控，用於效果的監控，提供宏觀方面的指標，描述整體系統的運營現狀，但並不能回答為什么是這樣，這個時候我們需要依賴白盒監控了。白盒監控是用於細化問題追查的。很多時候我們往往只有黑盒，這導致系統一出問題，但我們卻不知道是什么問題。
用一副圖總結如下
監控圖 -
其他
還有一些筆者不知道怎么歸類的，比如第三方支付平台用到的加密機、前置機或者代理服務器等。
以上整理的這些類似於一個檢查列表，依據上面一個方面一個方面檢查就不容易遺漏了。
后台服務
有些時候我們可能沒重視這個環節，但其實，我們很多系統配置，流控閥值、開關都是依賴於此的，如果后台服務有問題，我們很多的保障措施將無法施行，因此，對於它們的檢查也是很重要的，盡管不一定有很多要檢查，但心中一定要有它的位置。
由於篇幅關系，今天就介紹到這里，下一篇將具體介紹各方健康狀況的檢查和構建核心路徑流量模型，敬請期待。