鉴于2015年4月9日，逸创云客服的服务故障问题，下面我们对我们服务的基础设施服务进行一定陈述
服务构架
功能 | 备份计划 | 灾备 | |
功能和服务层 | 作为逸创云客服的程序交互功能 | 每周2次快照与备份，最近一次备份为4月7日 | 遇到灾难性故障可完全恢复配置数据，需要耗费10-15分钟，本次故障属于例外，本来完全可以避免，请见下面描述 |
数据库存储层 | 作为企业数据存储层，作为服务的数据存储和数据展示 | 每周3次快照与备份 最近一次备份为4月7日 | 遇到灾难性故障可完全恢复存储数据，需要耗费5-10分钟 |
静态文件存储层 | 作为静态文件存储，网页静态文件，如图片、文档、样式表、压缩包等静态文件 | 每周2次快照与备份 | 遇到灾难性故障可完全恢复存储数据，需要耗费5-10分钟 |
应用服务层 | 作为第三方附属功能，如邮件、推送PUSH、IM等 | 每2周快照与备份 | 遇到灾难性故障可完全恢复存储数据，需要耗费<5分钟 |
本次问题故障描述和排查进程
从今早9点开始，显示功能和服务层就开始连接缓慢，其他层服务都是正常的。功能和服务层是服务的入口，入口出问题了，其他层即使都是正常的，服务也无法正常访问，但这次是例外，我们以往对功能和服务层进行的单点故障架构也失效了。我们在之前没有对配置文件、程序文件等进行任何改动，在早上9点，网络自动就变得很缓慢。
我们开始对各种可能的情形进行排查，先后进行了：网络排查、漏洞排查、负载排查、安全排查、内存泄露排查、程序自身排查、APACHE配置排查、PHP服务排查、MYSQL结构和数据库连接配置排查等等，把可能想到的可能都排查一遍。
通过近4个小时的排查，故障依然不能解决。后来我们请来了全国知名的网络尖刀小组高级运维工程师协助排查和解决问题。
问题结论与修复方法
通过偶然的测试发现，是我们的IaaS服务商 (U****k) 给我方提供的功能和服务层的入口IP地址出现了故障，具体是通过他们同网段的云服务器来CURL服务层的网站地址，访问速度是正常的，外网访问就很慢很慢；他们提出的解释是说我们的程序有问题，导致APACHE故障，一启动APACHE就会让PING值飙升很高而导致网络就变得无比卡顿，我们重启服务依然无济于事，以至于我们一直在我们的程序和配置上找问题耽误时间。
后来我们紧急的更换了一个新的IP地址，将所有域名绑定迁入新IP地址，在下午2点左右陆续恢复正常。
SLA
逸创云客服承诺的SLA服务目标控制在每年99.5%以上，但经历了4月9日事件后，本年的SLA不能达标，后续将加强此类问题的预测和做好预先防护，避免此次问题再次发生。