谈谈变更过程中的运维意识

2021-02-24    分类: 网站建设

运维,或许是一个在 IT 技术岗中很尴尬的职位。其一,许多应届生都未曾接触过,对工作的职能界定非常模糊;其二,很多其他技术岗的往届生会觉得,『卧槽,这么 low 逼,只会重启推配置做发布』;其三,正在从事运维岗的往届生会觉得自己在公司的 KPI 很难体现。我在从事运维工作的前 2 年,也总是问自己:WTF,到底我的存在有啥意义?

这一点上,A同学是可以回答的上来的,但是对于接到任务之后,就不假思索的去做,是很可怕的,因为你并不知道做这件事情的意义。每一次变更就和开车并道一样,并一次就多一分产生车祸的风险,需要清楚衡量变更的意义和价值,权衡风险和价值的轻重,才可以对此次变更进行有效的精力投入评估。BTW,我们必须要问自己一句:这个变更一定要做吗,是否值得对需求方提出挑战?

假设每次变更都有产生故障的可能性,那么就必须要确认清楚好变更时间。有几个原则:a. 避开本产品线业务高峰期、关键期;b. 和同产品线的其他变更互斥;c. 和相关产品线的其他变更互斥。这一点上,同学A由于信息渠道窄,并没有接到业务部门对产品演示的通告,违反了原则a。怎么规避掉这个风险呢?就是把变更看成一个项目进行推进,每个环节的进展需要同步告知干系人,干系人负责进行风险评估。

运维需要成为【变更的项目经理】

打个比方,消防员在冲进火场的时候,需要确认是否仍有可能的爆炸源,否则被炸因公殉职也是自己的责任。运维在职能上和消防员类似,出现故障(火灾)的时候去歼灭故障源(火源),在执行变更的时候也需要多留一个心眼,反复确认上下游干系业务,才能进行变更规划(其实故障处理也是一次紧急变更)。任何一次变更都要当做一个项目进行运作,清楚干系人,把控风险,制定合理的步骤和时间节点,我们要把他看成一个持续若干天的项目推进,也就是说变更其实在接到需求的那一刻就开始了。

运维就如消防员

运维需要【遵循变更流程】

变更的大致流程是:需求确认 -> 干系业务/人确定 -> 方案探讨 -> 方案确立&时间确立 -> 变更单撰写 -> 变更单 review -> 审批报备 -> 变更通告 -> 方案实施 -> 方案效果反馈 (-> 回滚方案),可酌情进行步骤删减。遵循变更流程的主要好处是,首先,你可以在整理变更步骤的时候仔细思考每一处风险点,多次变更之后可以固化下来风险相对较小的标准化文档,后续可以把重复操作自动化。其次,风险均摊及最小化,方案是大家探讨后确定的,时间是大家商量后认可的,流程是经过审批报备的。真的,如果把类似的流程贯彻下去,因为变更产生故障的概率会大大降低。现在成熟的公司运维团队,都已经把类似的流程固化到运维平台里了,但是又有多少团队的负责人真正在遵循,而不是随便审批了事呢?不要和我谈业务压力有多大,不要和我谈缺人手,原则是不能却步的,否则捡了芝麻丢了西瓜。

一句真理

这么小的一个变更事件,我们可从中总结出那么多的经验,可见运维是一个全局操盘手,心不细真的不行。有一句话是之前我在阿里一直铭记在心的,双手奉上给各位同行:对生产环境要有敬畏之心。

本文标题:谈谈变更过程中的运维意识
网页路径:https://www.cdcxhl.com/news22/102622.html

成都网站建设公司_创新互联,为您提供电子商务外贸网站建设定制网站关键词优化网站改版搜索引擎优化

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

成都app开发公司