双11的高可用性
双11创造了千亿奇迹，这不仅是商品消费的盛宴，同时也是金融的盛宴。且不说消费金融在其中扮演的重要角色，互联网化的理财、保险等业务也是双十一活动的重要组成。在双11中，阿里金融云的高可用性，为双11保驾护航做出了重要的贡献。而不仅仅是双11这个场景，在金融业务中也经常遇到7*24的不间断业务的要求，突发流量带来的迅速扩容要求，以及发现应用系统软硬件故障时需要应急响应，那么如何的正取使用金融云，让自己能够平稳而有信心说：“我们已经做好的周全的准备”呢？
烧香解决不了问题
如果网络、硬件、软件各自的可靠性均在99.5%的情况下，系统的整体可靠性只有98.5%；而这意味着一年有多达5天以上的不可用时间，而这一切不是靠在社交媒体上发上一副图片可以解决的。
技术保障才是正道
在这种情况下，已经通过公安部云计算等级保护四级的阿里金融云作为为金融行业提供量身定制的云计算服务，提供了低成本、高弹性、高可用、安全合规的特性。她为金融系统提供了可用性99.95%，可靠性99.9999%的云计算服务器；和可用性99.97%，可靠性99.999999%的云计算数据库。配合服务可用性高达99.99%的负载均衡产品，即使应用软件的可用性没有任何改善，也将大大提升互联网环境下金融系统的可用性。
不仅正道，还要周到
除去这些，云平台还给金融系统们提供了更加周到的服务，我们来举几个例子：快速迭代下的互联网金融系统，不断发布。一旦发生软件缺陷，首先要做的不是回退；而是保留现场环境。在云平台上，每一次发布后构建云服务器镜像，一旦需要回退，过程仅仅是拉起上一个版本的镜像，并在负载均衡中调整一下参数，而原始问题环境保留在那里。
如果错误已经“秘密地”发生了若干天，那DBA和程序员们将痛苦地面对将错误业务一一恢复的漫长过程。而借助阿里金融云数据库默认提供的30天数据备份，可以立即在临时实例上恢复到错误发生之前的数据库状态，通过与当前数据的各种比对及处理，高效地完成错误数据修复。我们当然不希望出现错误会“秘密发生”这种情况。那么，不需要人工搭建监控平台，云平台上的各类自带的监控机制，会在第一时刻，通过短信、邮件、APP等方式告知到我们。
其实，这还不够
因为对于金融机构而言，哪怕是几个小时的不可用，都可能带来严重的后果。这就是为何监管机构纷纷要求金融机构必须建立“两地三中心”的数据中心，构建完善的灾备体系。对于中小互联网金融服务机构，虽然并没有这样的强制要求，但是想象一下，当一个理财平台的APP几个小时无法正常使用的时候，漫（zao）天（yao）飞（shen）舞（shi）的小道消息开始流传，那将是怎样的结果？那么是否需要用3年、5年的技术攻关，用大量的财力物力来构建自己的同城双活、异地灾备环境呢？显然现在已经有了相当完善而且成本低廉的替代解决方案。
因为同城双活、灾备是阿里金融云的缺省特性，用户可以在30分钟内轻松搭建高可用的同城双活架构。金融云在一个地域提供多个可用区，是电力和网络互相独立的物理区域，但是内网互通。通过负载均衡服务，将同一个应用发布在不同可用区的多台云服务器上，可以避免因为单个可用区的故障而导致对外服务的不可用。而阿里云的RDS，采用热备架构，出现故障后服务秒级完成切换，整个切换过程对应用透明。
不仅如此，因为阿里金融云在国内多个地域均有数据中心，配合阿里云提供的数据同步工具和文件复制工具，可以在异地搭建同构的应用环境并保持数据同步；当出现主数据中心软硬件故障的情况下，只需修改DNS，即可将互联网业务切换到异地灾备环境下。
只想要做灾备呢
当然我们一时无法抛弃已经陪伴我们许久的目前的数据中心，但是再造一个异地的数据中心确实有相当昂贵的成本和漫长的时间，外加各类合规、安全检查，以及雇佣和培训更多的人员（然后由一位资深的同事去到另一个城市工作，带着他们一起，只为最好永远也不要发生的灾备切换动作）。因此我们提出了“云下业务，云上容灾”的解决途径。在这个方案下，通过专线互联将金融企业的数据、文件等同步到云上的服务环境，并在云上构建灾备应用系统，当需要的时候，仍然只是做一下DNS切换而已。
哦，忘记说了，阿里云已经与Docker达成了战略合作，将成为Docker官方支持的云服务提供商。这就意味着，已经拥抱了Docker的金融机构，将可以通过金融云上的容器服务，构建容器化的混合云系统。于是，在不同地域，云上云下，可以构建一体化的应用环境，高可用、高可靠、异地容灾等等这染白了上一代运维人员头发的困扰，将不再成为问题。
