注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

逍遥子 曰:

得失失得 何必患得患失 舍得得舍 不妨不舍不得

 
 
 

日志

 
 

[原]生产环境的变更管理  

2016-12-06 20:09:10|  分类: 团队管理 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
本文是对《架构即未来》第10章的总结; 1. 变更包含广阔的范围,它不仅包括软件的升级还包括对当前环境的任何软、硬件改动,包括配置、操作系统、数据库、防火墙、网络设备等等,对于研发来说,变更最主要的还是版本升级; 2. 生产环境的变更是事故发生的主要原因,经验指出,生产环境中的事故,有很大一部分是由于软、硬件的变更而引起;这也与我们的实际工作场景相似,我们在实际工作中,一旦遇到生产环境的问题,首先要问的就是最近有没有谁对系统做过任何改动?例如版本升级、配置更改、数据库修改、网络修改等等; 3. 由于变更时生产环境发生事故的主要原因,因此我们要对生产环境的变更进行管理,来限制事故发生的机会; 4. 版本升级要坚持小步快跑的方式进行持续交付,改动的越小,就越容易测试,一旦出现问题也更容易定位; 5. 版本升级流程 版本升级是最主要的变更,因此,制定一个好的流程来规范版本升级能有效降低生产环境发生故障的概率;下面是书中建议版本升级流程: (1) 变更请求,修改为版本升级申请更合适,我们在每次发布新版本之前需要先提申请,说明我们本次升级要解决那些问题?怎么修改的?可能带来那些问题?如果升级需要申请新的资源,则要一并提出,将版本升级申请发送给相关的负责领导和运维同事,由其根据情况来决定是否进行升级; (2) 变更审批,修改为升级申请审批更贴近实际,如果升级有一定风险的时候相关的负责领导要进行把控,例如需要进行签字等,如果是正常升级,则有运维来审批,运维审批时会查看升级是否需要新资源,如果需要,则要进行相关资源的分配; (3) 变更调度,修改为版本升级管理更合适,在团队变大时,同一套代码可能会有很多人进行修改,这时如果不对升级进行管控,可能导致升级矛盾,这时就需要一个机构或者负责人来协调和管理升级,管理升级时应该考虑以下几个因素: ? 确定升级时间,如果需要暂停服务,则要考虑在业务最少的时候进行升级; ? 当有一套代码有多个升级相冲突时,要分析每个升级的风险和回报来确定优先级; ? 分析多个升级之间的依赖关系,被依赖的一定要先升级; ? 对每个时间段内的升级数量进行控制,即版本升级之间要拉开时间间隔,短时间内不应该升级多个版本,这样每个版本的验证都不充分,一旦出现问题,很难定位是哪个版本的修改引起的; (4) 变更执行与日志,也即执行升级和记录升级,在版本升级的时候要做好相关的记录,记录的内容包括:什么时候开始升级的?什么时候升级完的?谁升级的? (5) 变更验证,升级完成之后需要通知相关测试人员进行功能验证,验证内部不仅包括新需求是否实现?bug是否修改成功?还包括升级对原有的功能是否造成了影响?一旦发现任何问题都要进行版本回滚;因此,我们会要求升级的每个版本都是可回滚的; (6) 变更回顾,也就是定期开会回顾一下最近升级了哪些版本?升级的时候有没有造成事故?等等,温故而知新,通过回顾过去版本升级引起的问题可以防止未来升级时再次发生类似问题。

  评论这张
 
阅读(23)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017