在上文中，我们已经梳理好了外部影响条件，即系统将面对一个什么环境，会处于一个什么境况。接下来，我们的目标自然是由外到内，梳理内部现状。
同样，此次我们也将依照如下要点梳理：
- 对系统自身情况的梳理
- 对系统的依赖方、服务方、基础服务和后台服务分别梳理
- 对各方健康状况的检查
- 构建核心路径流量模型
对系统自身情况的梳理
大家肯定发现我每次都喜欢先把要点大纲罗列出来，其实我的目的在于强调大促保障是一个很复杂且很重要的系统工程，如果没有一个计划、大纲，想到什么就做什么，那这个大促，必然要不漏这，要不忘那。因此，就如同设计一个系统一样，代码未动，设计先行。
首先，我们需要对系统自身做一个全面的梳理，目的在于了解系统的现状，知己知彼才百战不殆。我们将从两个方面开始，
一是受影响系统的梳理。我们根据上面梳理的活动影响业务，就能知道哪些业务线会受到影响。比如，最简单的支付业务，就会影响如收银台、收单服务和支付服务等，同时也会涉及到安全风控等。梳理一定要全面，最好是按照业务线来梳理，这样才能保证不遗漏。这个环节一定要细心，如果遗漏了某个系统，它极有可能会成为雪崩效应的一个突破点。
此时我还要强调一点，作为系统的负责人，一定要有全局观，任何系统负责人，都不能只考虑到自己系统的影响。如果抱着这点小影响，对自己系统的影响不大，但没有站到整个第三方支付平台的角度去看待是否还是小风险、小影响，则极有可能埋下很大的安全隐患。双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等。 -
监控层
主要是一些监控的系统。说到这里，顺便提一下关于监控的话题。读者可以依据下面去整理，有条理就不容易遗漏
任何一个系统的运行，都离不开监控，我们需要依赖它们来了解我们系统的现状，那么一个立体的监控需要哪些系统呢？
通常来说，监控方面包括业务层面的监控、系统层面的监控以及一些基础设施的监控。业务监控负责提供系统实时或者历史的业务指标相关的信息，比如订单量，各个渠道支付占比等，同时也是我们事后数据分析的依据。系统层面的监控主要是用来观察系统是否健康，包括成功率、耗时等，主要是侧重于业务应用方面。基础设施的监控则侧重于基础服务的监控，如数据库，交换机等。
监控类型主要有黑盒监控，用于效果的监控，提供宏观方面的指标，描述整体系统的运营现状，但并不能回答为什么是这样，这个时候我们需要依赖白盒监控了。白盒监控是用于细化问题追查的。很多时候我们往往只有黑盒，这导致系统一出问题，但我们却不知道是什么问题。
用一副图总结如下
监控图 -
其他
还有一些笔者不知道怎么归类的，比如第三方支付平台用到的加密机、前置机或者代理服务器等。
以上整理的这些类似于一个检查列表，依据上面一个方面一个方面检查就不容易遗漏了。
后台服务
有些时候我们可能没重视这个环节，但其实，我们很多系统配置，流控阀值、开关都是依赖于此的，如果后台服务有问题，我们很多的保障措施将无法施行，因此，对于它们的检查也是很重要的，尽管不一定有很多要检查，但心中一定要有它的位置。
由于篇幅关系，今天就介绍到这里，下一篇将具体介绍各方健康状况的检查和构建核心路径流量模型，敬请期待。