而我们做运维的,必须先要谈论的一个问题,就是业务连续性. 一谈到这个问题,就出来了很多关于数字9的话题. 如3个9,4个9,5个9的.每增加一个9，那可都是钱啊.成几何倍数增长的软妹币啊.
业务连续性,业务恢复时间,故障恢复时间. 注意,根据不同的架构,这2个时间是不一样的噢. 如NLB的, 一台服务器坏掉,另一台服务器同时接管所有业务响应. 业务中断时间可以忽略,但是故障还没有恢复,坏掉的还是坏的.要一直到修好了,才能确定了故障恢复时间. 而这2个时间,取决于3个因素. 第一个因素,是架构. 第二个因素,是故障处置与应急预案文档. 第三个因素,个人业务技能与服务商.
实现业务连续性之架构设计,对于这种,我们可以参照讨论的有NLB, Cluster, 主要思路是指,当一台服务器出现故障时,不影响业务的运行. 当然,也可以考虑使用一台应用备机,平时放着,当运行主机故障时用以替换的方式,这种方式是,不要使用Cluster,比较省钱吧.但是业务中断时间肯定会多一点. 这就要根据你的业务重要性来判断了.
业务连续性与厂商服务. 嗯,服务商提供各种产品和技术服务,也与我们的业务连续性看上去没有直接关系,只是 ,服务商的服务质量确实影响着我们. 购买产品时,有他们. 部署和架构设计时,有他们. 故障处置时,还有他们. 如何找对服务商和使用服务商.
业务连续性与预案. 这里介绍一个很多IT人员和管理人员都喜欢用的一个词,troubleshooting. 如何理解这个词呢? 直接翻译的话是” 故障排除”,而这个状态,我的理解时,当遇到一个未知故障发生时,需要进行的一些列活动.如检查日志,检查主机状态,查找资料,进行一些操作的尝试等等.主要就是从未知开始,到解决问题的一系列活动. 但是,这对于业务连续性来说,是一个讨厌的事情.因为你无法预知故障解决时间,也无法预知业务恢复时间. 因此,非常重要的用于实现最短业务恢复时间的方法,建立故障处置和应急预案. 要是你说你现在没有这种东西,那么,你只是个入门的技术人员,而不是一个合格的运维人员.
业务连续性与个人技能,这个问题嘛, 如果你做好上述3点了.那么在运维过程中,你的技能也就足以应对你现有环境中能遇到的问题了.
