20年前，我们的网络可能只有路由器/交换机/防火墙，而应用系统的架构也极其简单，可能一台主机就搞定了所有问题。假如这时业务系统不能访问，简单，服务器重启，所有的问题很快就能解决，如果不能解决，没问题，再重启一次！

但是随着IT技术的发展，整个数据中心变得越来越复杂，以银行为例，绝大部分银行的数据中心都会根据业务系统的属性或重要程度采用分区部署的架构，几十套、上百套、甚至数百套的业务系统都部署在这样的数据中心里，最可怕的是应用系统之间还有极其复杂的应用逻辑访问关系。如果一个系统不能访问了，会发生什么?灾难！

更可怕的是，据国内某大数据厂商发布的数据显示，73%的IT问题是由最终客户发现的。而在200w客户的大数据统计下，当客户体验遭受影响时，只有2%的用户会选择投诉。这也正是为什么当我们收到客户投诉的时候，事态已经非常严重的根本原因之所在。

但此时我们能做什么呢？向20年前一样重启服务器吗？请问我应该重启哪一台?

幸运的是，现在客户数据中心中有很多的BIGIP设备，比如GTM/SSL OFFLOAD/LTM/AWAF等

当真实客户想访问数据中心业务时，标准动作是输入URL，向DNS服务器发送一个DNS请求，收到请求后DNS服务器响应A或AAAA记录返回给客户端，客户端向主机建立连接，进行SSL握手（考虑到传输安全，银行客户都会采用https进行访问），最后，客户端和服务器之间进行交互。

而F5在整个过程中是控制器，所有的流量都会经过F5，由于F5全代理架构的优势，F5可以识别和获取客户端和服务器之间所有OSI 2-7层的信息（只要是定置+定长，F5均可以识别和获取）。同时，F5可以通过HSL（高速日志引擎）功能将识别和获取的信息以log的方式发布到任意的数据监控平台，如ncompass、elk、Splunk等。

在第三方平台的帮助下，我们可以绘制一个完整的应用逻辑访问拓扑，所有的业务访问关系一目了然。就好像人体的经络，所有的数据流量好像人体的血液。当我们生病的时候，到医院验个血，看看那个指标高了，就能轻松判断身体是感染了还是哪个器官出了什么问题。数据中心也是一个道理，通过对整个应用逻辑访问中的流量进行“关键指标”的“验血”操作，我们也同样能快速的发现并定位问题。

如图，您只需要看一下地图，如果有一个数据值上升，必然代表着出现了问题，需要做的就是解决问题。标准动作如下：点击IP，选择分析，查看地图

客户端发送一个syn到服务器端，服务器响应syn和ack到客户端，到目前为止没有问题，但是客户端没有响应，所以问题在客户端，ok，找到问题。而这正是一个真实客户的整个troubleshooting的过程，您觉得怎么样?

而对于我们的客户而言，他所得到的实际价值是：

1. 在客户投诉前更快地发现问题

2. 在造成大范围影响前，解决这个问题

好了，这本期的解决方案，如果你有任何问题或者对这个话题感兴趣，我们可以下次再深入讨论，谢谢