如何做好数据中心里大本大宗的割接工作

简介:

割接是对正在使用的线路、设备进行操作,将会直接影响到上面承载的业务。割接是数据中心工作的重要部分,由于涉及到业务变更、软件升级、设备上下线等操作,可能会对现有业务造成影响,甚至中断,所以割接也是数据中心工作中最具挑战的部分。一次割接任务完成的是否漂亮,对数据中心未来的运营效果有很大影响,一般在割接之前都要做缜密计划,确保割接顺利。我们知道,数据中心里的故障80%都是人为失误造成的,而割接必然涉及到人为操作,出错是必然的,哪个数据中心割接没出过几次小问题,只要能够及时补救,一般不会产生过多负面影响,这缘于数据中心内部是一个非常庞大的信息系统,成千上万台协同运转,哪里配合不好,都可能影响业务,达不到割接之前制定预期的效果。尤其是现在各种新技术不断在数据中心里落地,虽然提升了数据中心的运行效率,减少了人力成本,可一旦出了问题,排查起来非常困难,就算是顶尖的技术专家也难于对整个数据中心的系统技术都掌握,这都增加了割接难度,使得每次割接都像过鬼门关一样。那么,我们来看看数据中心业务割接有哪些需要注意的地方,避免犯错误,从而提升业务割接的成功率。

首先,要对割接方案进行评估,多大风险,尤其是对正在运行业务的系统是否有影响。根据评估,确定可能影响业务中断的时长,然后提前向数据中心用户发公告,对于重要大客户要单独沟通,得到大客户许可之后,再发布割接公告,公告里明确说明本次割接的目的,比如为了提升客户访问数据中心的速度、业务系统软件升级、设备更换等等,让客户一看就知道割接做哪些事情。公告里还要讲明割接操作开始和结束时间(基本都是夜里两点到五点的时间段),期间可能引起的业务中断时长,具体访问哪些业务会有影响。数据中心在割接之前,有主动告知的义务,让客户提前有准备,做好各种数据备份。

其次,要制定详细的割接方案。包括割接的整体方案介绍、详细的操作技术方案、回退方案、人力部署和分工安排、预期效果、割接过程中的信息采集和数据监控等等。所以割接前,需要做大量的准备工作,准备得越充分,割接时越顺利,也许割接时就几分钟甚至只是一个设备操作命令,但准备工作也许要花费几天甚至数月来准备,这就像嫦娥奔月工程,从嫦娥发射到飞到月球轨道,只有两三天时间,但我们却需要花费一两年的时间来设计和准备工作,前期工作是海量的。要考虑到割接的过程中可能出现异常情况,针对出现不同情况有相应应对的方案,如果在割接前没有考虑清楚,一旦出现预知之外的情况,将没有应对方案,在短时间内很难想到很好的解决方案,这时如果处理经验不足,往往就是执行回退方案,割接出现失败。还有,割接的所有方案和技术操作都要符合数据中心规章制度和相关标准,不允许违规操作。比如:在重大节日封网期间操作,将高级别的设备操作权限交由低级别工程师,有低级别工程师代替操作,割接时要严格按照预定步骤,有条不紊地执行。对于特别重大的割接,还要搭建模拟环境,进行演练,有条件的话还需要在数据中心现网的业务环境中进行割接预演,根据模拟演练的情况,对割接方案进行完善,对不足的地方进行改进。

第三,要做好数据业务备份。不少数据中心的业务是不允许中断的,数据更是不同于出现错误或者丢失的情况。这时就要启动冗余备份方案,比如可以在割接前将业务平滑切换到备份系统中,割接完再将业务切换回来,保持业务不受影响,有时还可以将数据备份起来,让业务停转,割接完成后,再启动业务运转,继续使用备份数据,千万不可出现无备份,业务裸奔的危险情况。最近,广西移动在进行扩容割接时,就出现了误操作导致用户数据丢失的故障,影响了几十万用户,十几个小时手机无法通话,这就是一例明显割接的准备工作不足,数据备份没有做好的例子。无论在任何情况下,数据是数据中心最宝贵的资产,其中有太多千万用户账户信息,一旦出现丢失或者错误,造成的影响都很恶劣,这比业务一时无法访问还严重,就好比我们正在用电脑写文章,突然电脑断电,之前辛苦写的文章因没保存全丢了一样,害的自己还得重新写,浪费不少时间,这比电脑断电但之前写的文章还在要严重地多,这样我大不了等来电时继续写就行了。

最后,要做好监控和总结。因为割接几乎都在后半夜进行,这时数据中心业务量最低,此时割接完可能看不出业务状态,需要观察一两日业务的运行状态,直到确认完全没有问题割接执行部分才算基本结束。接下来就是要对这次的割接工作进行总结。数据中心里的割接工作是比较频繁的,有的数据中心甚至天天晚上都有割接安排。每次割接完后,都要针对割接过程中出现的问题进行分析,及时改进,并在下一次割接中避免。如果割接失败,更是要总结失败原因,对整个割接的过程进行详细分析,调整后面的割接方案,避免同样的错不犯第二次。除了对发现的问题及时改进,也要总结经验,将割接的过程中所见所得记录下来,这些割接的经验可以保留下来,供其它人员在割接时学习使用,从而提升整个数据中心运维人员的技能水平。往往在这种割接业务的关键工作中,才是最锻炼人的,也是很好的学习真本领的机会。
本文转自d1net(原创)

相关文章
|
1月前
|
运维 Prometheus 监控
运维中的自动化实践每月一次的系统维护曾经是许多企业的噩梦。不仅因为停机时间长,更因为手动操作容易出错。然而,随着自动化工具的引入,这一切正在悄然改变。本文将探讨自动化在IT运维中的重要性及其具体应用。
在当今信息技术飞速发展的时代,企业对系统的稳定性和效率要求越来越高。传统的手动运维方式已经无法满足现代企业的需求。自动化技术的引入不仅提高了运维效率,还显著降低了出错风险。本文通过几个实际案例,展示了自动化在IT运维中的具体应用,包括自动化部署、监控告警和故障排除等方面,旨在为读者提供一些实用的参考。
|
6月前
|
消息中间件 监控 前端开发
研发人员如何做好日常工作的稳定性保障
本文介绍了一些研发人员如何做好稳定性建设的工作事项
224 0
|
存储 运维 负载均衡
网络运维主要做什么,日常工作有哪些?
网络运维主要做什么,日常工作有哪些?
849 0
|
算法 BI
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
378 0
|
消息中间件 缓存 监控
四个步骤,教你落地稳定性保障工作
本文将稳定性保障工作归纳为 梳理异常情况->配置监控告警->评估影响面->预定解决方案 四个步骤。从四个步骤详细介绍稳定性保障工作的落地方法。
49797 1
四个步骤,教你落地稳定性保障工作
|
负载均衡 API 数据库
【韧性架构设计】软件韧性:从意外中恢复的 7 个必备因素
【韧性架构设计】软件韧性:从意外中恢复的 7 个必备因素
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.4 故障复盘
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.4 故障复盘
308 0
|
运维 监控 数据库
面对平台间业务的迁移,你该做些什么?
面对平台间业务的迁移,你该做些什么?
277 0
面对平台间业务的迁移,你该做些什么?
|
运维 监控 前端开发
开发人员该如何应对线上故障
开发人员该如何应对线上故障
467 0
开发人员该如何应对线上故障
|
运维 人工智能 Cloud Native
如何构建一个拖垮整个公司的运维系统
人肉运维,不在 DevOps 中转型,就在自动化中消亡。云化时代的运维,需要的是高铁,而不是“跑的更快的马车”。6月25日,数智创新行上海站·智能运维专场,期待您的参与。
1380 0
如何构建一个拖垮整个公司的运维系统
下一篇
无影云桌面