免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 20765 | 回复: 15

黑与白之间的平滑过渡,要如何规避风险? [复制链接]

论坛徽章:
4
戌狗
日期:2014-10-12 21:48:202015年辞旧岁徽章
日期:2015-03-03 16:54:15IT运维版块每日发帖之星
日期:2015-06-09 22:20:002016猴年福章徽章
日期:2016-02-18 15:30:34
发表于 2015-05-28 09:26 |显示全部楼层
获奖名单已公布http://bbs.chinaunix.net/thread-4181550-1-1.html

话题背景

最近,看过网上一篇文章,稍微上规模的互联网企业,每月的更新都是上百次。最为一线运维人员,怎样快速高效无误的完成更新,影响的范围和时间降到最低,避免夜晚更新带来的加班疲劳,是摆在成长企业面前需要解决的问题。

互联网产品有一个特点,就是不停的升级,升级,再升级。有些项目可以需要保证每周一次的发布频率。系统升级总是伴随着风险,比如:新旧版本兼容的风险,用户使用习惯突然改变而造成用户流失的风险,系统down机的风险等等……为了避免这些风险,很多产品都采用了灰度发布的策略,其主要思想就是把影响集中到一个点,然后再发散到一个面,出现意外情况后很容易就回退。

所以该话题设计到了灰度发布的概念,所谓灰度发布就是指:在黑与白之间,能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式,让一部分用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。




讨论话题

1、你的工作中应用更新是否有固定的时间点?如何应付紧急更新。

2、你工作中更新流程。

3、为了解决夜晚加班疲劳和人员不足的问题,如果需要白天也要更新应用,怎样进行安全高效的更新?

4、你工作中是否采用了灰度发布,如何解决灰度发布中遇到的问题,比如数据一致性,应用测试。或者你谈谈对灰度发布的理解。




讨论时间
2015年6月4日--2015年6月28日



活动奖励
要言之有物,不能低于20个字。活动结束后将选取4名讨论精彩的童鞋,每人赠送技术图书(书单)一本作为奖励。






关注CU官方微信“ChinaUnix”微博“ChinaUnix官方微博

forum.jpg forum (1).jpg

我们会及时为您公布最近活动的获奖名单以及最新的活动资讯,更多精彩内容,敬请期待。

论坛徽章:
0
发表于 2015-06-04 16:36 |显示全部楼层
首先占个沙发,歇凉快了逗。
1、你的工作中应用更新是否有固定的时间点?如何应付紧急更新。
一般是夜深人静的时候23:00,对于紧急更新,要针对具体情况采取具体的更新措施(保证基本的备份恢复流程)
2、你工作中更新流程。
研发人员提前准备oa,通知运维人员,运维人员定时做好程序备份,按照要求完成程序更新。
3、为了解决夜晚加班疲劳和人员不足的问题,如果需要白天也要更新应用,怎样进行安全高效的更新?
复制一套生产环境,有得放矢。
4、你工作中是否采用了灰度发布,如何解决灰度发布中遇到的问题,比如数据一致性,应用测试。或者你谈谈对灰度发布的理解。
才用服务器集群方案,一个节点一个节点的更新

哎呀,终于歇凉快了,出去耍叻。

论坛徽章:
4
白银圣斗士
日期:2015-11-24 10:40:40技术图书徽章
日期:2015-11-26 13:47:47平安夜徽章
日期:2015-12-26 00:06:30技术图书徽章
日期:2016-07-19 13:54:03
发表于 2015-06-04 17:11 |显示全部楼层
1、你的工作中应用更新是否有固定的时间点?如何应付紧急更新

我们一般固定在每周一与周四进行发布,避免周末仓促发布出现问题无人维护的问题,
对于紧急更新,如果是小范围修改则不经过平时的发布流程,直接上传版本库后修改线上代码,大范围修改仍然必须经过测试完毕后进行发布。

2、你工作中更新流程。
目前使用开源发布系统自动从版本库中进行读取代码发布到服务器,线上保留15个版本,代码有问题可以马上回滚代码。

3、为了解决夜晚加班疲劳和人员不足的问题,如果需要白天也要更新应用,怎样进行安全高效的更新?
目前来说绝大多数发布还是在白天进行发布,这跟业务有关,我们的业务晚上和周末是高峰期,所以白天反而不是业务高峰,最主要的还是要有合适的发布管理工具。

4、你工作中是否采用了灰度发布,如何解决灰度发布中遇到的问题,比如数据一致性,应用测试。或者你谈谈对灰度发布的理解。
目前还没有使用灰度发布,但是已经在规划,灰度发布的关键在于如何进行AB组的划分,以及可以监控AB组用户的使用效果和得到反馈,
对于APP来说还比较好办,可以通过邀请方式邀请用户体验新版,但是对于网站等应用则一般需要按照地域或者用户的cookie划分AB组。

评分

参与人数 1信誉积分 +6 收起 理由
typuc + 6 赞一个!

查看全部评分

论坛徽章:
0
发表于 2015-06-04 17:17 |显示全部楼层
本帖最后由 十年有多少日 于 2015-06-04 17:30 编辑

1、你的工作中应用更新是否有固定的时间点?如何应付紧急更新。
一般是周二,周四进行升级更新,这样做主要考虑更新之前需要一个准备的时间,更新之后需要有一个观察有问题及时处理的时间,所以周二和周四比较合适;紧急更新时间短、风险大,需要制定特别的流程,比如需要更高级别的领导授权,需要高阶的工程师、运维师、DBA进行审核和监控。更新完成后,做关键部分做严密的测试,以及实时观察生产系统指标,观测时间比常规时间要长。

2、你工作中更新流程。
1、申请在何时何地何人进行升级更新
2、相关主管或领导审批此次更新;
3、进行测试流程,测试通过后,测试主管批复测试通过,可以进入准生产环境(和生产环境系统参数、数据都一致,只是不是真正的生产环境);
4、测试人员再次对准生产环境进行测试,测试通过,主管批复准生产环境测试通过,可按计划时间进行上线更新;
5、相关运维、开发、测试相关人在计划时间地点进行升级更新;
6、更新完成,测试用户开始测试,运维、dba开始观测生产系统、数据指标;
7、如测试、系统、数据指标都无问题,即上线成功;
8、如测试、系统、数据指标等存在异常,则记录下相关日志、操作流程等,然后执行回退。
9、后续根据相关日志、操作流程分析问题,并解决再计划二次升级更新。


3、为了解决夜晚加班疲劳和人员不足的问题,如果需要白天也要更新应用,怎样进行安全高效的更新?
1、首先保证测试环境、准生产环境上更新内容都无问题;
2、采用灰度发布方式,在小范围执行更新,并且此范围最好就是本公司测试人员
3、测试人员开始进行测试,因为此时发布范围仅对本公司测试人员开放所以对外几乎无风险。
4、测试人员测试通过后,再次扩大更新范围,使一部分用户开始进入更新后的版本。
5、监控相关系统、数据指标,客服开始记录此阶段有无大量用户进行咨询和投诉,如果有则即时回退,如果无则进一步扩大发布范围,以此类推,发布范围和次数由你的产品规模和用户量而定。


4、你工作中是否采用了灰度发布,如何解决灰度发布中遇到的问题,比如数据一致性,应用测试。或者你谈谈对灰度发布的理解。
灰度发布主要的问题在小部分的用户情况并不代表所有用户的情况,也就是说小范围的发布测试结果,可能是不准确的,当你扩展部分范围时可能会出现意想不到的问题,针对这种情况,我们可以采用多点采样的方式,比如举个例子QQ升级,会在全国各省重点地区都进行小范围更新,这样采样的结果就比较丰富,测试的结果也可以代表各地区的更新情况;另外的问题就是数据一致性,比如在执行小范围更新时,出现了严重的问题,但因为是生产环境,数据其实已经被更新污染过了,针对这样的问题,我们需要做好更新前记录好可能影响到的数据范围,做好备份。以便出现严重问题时,及时修复。

评分

参与人数 1信誉积分 +8 收起 理由
typuc + 8 很给力!

查看全部评分

论坛徽章:
211
2022北京冬奥会纪念版徽章
日期:2015-08-10 16:30:322015亚冠之全北现代
日期:2016-05-11 17:05:27操作系统版块每日发帖之星
日期:2016-05-10 19:23:04操作系统版块每日发帖之星
日期:2016-05-10 19:23:04操作系统版块每日发帖之星
日期:2016-05-10 19:23:04操作系统版块每日发帖之星
日期:2016-05-10 19:23:04操作系统版块每日发帖之星
日期:2016-05-10 19:22:58数据库技术版块每日发帖之星
日期:2016-05-10 19:23:04数据库技术版块每日发帖之星
日期:2016-05-10 19:23:04操作系统版块每日发帖之星
日期:2016-05-10 19:22:58操作系统版块每日发帖之星
日期:2016-05-10 19:22:58操作系统版块每日发帖之星
日期:2016-05-10 19:22:58
发表于 2015-06-05 10:17 来自手机 |显示全部楼层
将帅无能,累死三军

论坛徽章:
18
2015亚冠之阿尔希拉尔
日期:2015-06-02 09:56:10数据库技术版块每日发帖之星
日期:2016-08-13 06:20:00数据库技术版块每日发帖之星
日期:2016-04-24 06:20:00数据库技术版块每日发帖之星
日期:2016-03-19 06:20:00数据库技术版块每日发帖之星
日期:2015-12-25 06:20:35数据库技术版块每日发帖之星
日期:2015-12-25 06:20:35数据库技术版块每日发帖之星
日期:2015-12-25 06:20:35数据库技术版块每日发帖之星
日期:2015-09-12 06:20:00数据库技术版块每日发帖之星
日期:2015-09-11 06:20:00ChinaUnix专家徽章
日期:2015-06-30 16:29:48ChinaUnix专家徽章
日期:2015-06-30 16:29:342015年中国系统架构师大会
日期:2015-06-29 16:11:28
发表于 2015-06-05 14:51 |显示全部楼层
1、你的工作中应用更新是否有固定的时间点?如何应付紧急更新。
目前公司正在做自动化更新。作为初创公司,新的软件bug很多,更新也很繁琐,容易出错。
座椅做了自动化更新软件。目前使用 bash java 做的更新  不过我觉得  还是python 写比较好
2、你工作中更新流程。
研发团队提出更新后 程序 自动从svn  打包代码 发布到测试服务器上 进行测试,测试通过后 直接发布生产环境
3、为了解决夜晚加班疲劳和人员不足的问题,如果需要白天也要更新应用,怎样进行安全高效的更新?
自动化发布  控制好流程 就没有问题了  哈哈
4、你工作中是否采用了灰度发布,如何解决灰度发布中遇到的问题,比如数据一致性,应用测试。或者你谈谈对灰度发布的理解。
自动化发布 有测试环节  ,混滚方案  直接 出问题 自动回滚 老版本

论坛徽章:
71
子鼠
日期:2015-06-10 14:07:09丑牛
日期:2015-06-10 14:07:10寅虎
日期:2015-06-10 14:07:40卯兔
日期:2015-06-10 14:07:44辰龙
日期:2015-06-10 14:07:44巳蛇
日期:2015-06-10 14:07:46午马
日期:2015-06-10 14:07:47未羊
日期:2015-06-10 14:07:48申猴
日期:2015-06-10 14:07:50酉鸡
日期:2015-06-10 14:07:54戌狗
日期:2015-06-10 14:07:55亥猪
日期:2015-06-10 14:07:57
发表于 2015-06-05 15:16 |显示全部楼层
支持一个,顶!!!

论坛徽章:
71
子鼠
日期:2015-06-10 14:07:09丑牛
日期:2015-06-10 14:07:10寅虎
日期:2015-06-10 14:07:40卯兔
日期:2015-06-10 14:07:44辰龙
日期:2015-06-10 14:07:44巳蛇
日期:2015-06-10 14:07:46午马
日期:2015-06-10 14:07:47未羊
日期:2015-06-10 14:07:48申猴
日期:2015-06-10 14:07:50酉鸡
日期:2015-06-10 14:07:54戌狗
日期:2015-06-10 14:07:55亥猪
日期:2015-06-10 14:07:57
发表于 2015-06-05 15:21 |显示全部楼层
1、你的工作中应用更新是否有固定的时间点?如何应付紧急更新。
   一般都是晚上或者周末。紧急更新就是要approval,然后发邮件通知受到影响的用户
2、你工作中更新流程。
   开发环境 部署之后没问题, 提交请求 让第三方团队帮忙移到QA环境,然后再没有问题后,再提交请求 让第三方团队帮忙移到生产环境
3、为了解决夜晚加班疲劳和人员不足的问题,如果需要白天也要更新应用,怎样进行安全高效的更新?
   挑相对的用户访问量少的时间,多测试
4、你工作中是否采用了灰度发布,如何解决灰度发布中遇到的问题,比如数据一致性,应用测试。或者你谈谈对灰度发布的理解。
   没用过。。。灰度发布可能对于分布式的系统 或者云相关的系统比较有用。。。

论坛徽章:
4
戌狗
日期:2014-10-12 21:48:202015年辞旧岁徽章
日期:2015-03-03 16:54:15IT运维版块每日发帖之星
日期:2015-06-09 22:20:002016猴年福章徽章
日期:2016-02-18 15:30:34
发表于 2015-06-06 00:42 |显示全部楼层
本帖最后由 typuc 于 2015-06-06 00:45 编辑

我也来谈谈。
1、你的工作中应用更新是否有固定的时间点?如何应付紧急更新。
    之前公司每周二和周四晚上有更新,这样保证万一有突发情况,开发和运维都有人在;如果有紧急更新,需要开发,运营领导同意,然后运维立即更新。
2、你工作中更新流程。
    开发环境测试开发人员负责;然后交由测试人员测试环境部署测试;然后在预上线环境部署测试;最后确定生产更新时间,运营发布公告,客户做好解释工作,运维 DBA晚上业务低峰时段进行更新。
3、为了解决夜晚加班疲劳和人员不足的问题,如果需要白天也要更新应用,怎样进行安全高效的更新?
   多节点情况下,先把后端一个节点从负载设备上摘下,然后进行更新,确认无误后再挂载到负载上;然后观察业务日志,是否有异常,如果无异常再更新其他节点。这种方式有以下不足:
          A,通过观察业务日志比较费时,而且不准确;适合10个以下的节点;
          B,无法准确的将生产测试请求转发到最先更新的那个节点,无法准确的测试应用;
          C,如果涉及到数据修改,要保证修改后的数据库对未更新的节点依然可用;

4、你工作中是否采用了灰度发布,如何解决灰度发布中遇到的问题,比如数据一致性,应用测试。或者你谈谈对灰度发布的理解。
    暂时未采用,处于前期调研。以下是个人理解:
     灰度发布流程:由点到面,到全局,在不中断用户使用情况下进行日常更新;最大程度提高服务可用性,实现应用快速部署。
     发布通过用户流量牵引(通过配置负载可以测试人员IP发起的请求,转发到已经更新的节点),实现快速准确的测试,用户仍旧访问未更新的版本,实际工作中还会更加复杂。

         点:单个节点 ; 面:区域集群 ; 全局:所有区域
          灰度发布.jpg
        
         单节点更新流程:
          温和下线.jpg
         
          数据库注意事项:
                为了保证测试的真实和正确,需要将首先部署的节点连接到生产数据库。如果此次更新,对数据库表进行了增加字段操作,那么首先要保证当前
          运行的版本中插入数据SQL中插入值和字段一一对应。INSERT INTO table_name (列1, 列2,...) VALUES (值1, 值2,....)

灰度发布是个好东西,如果真的实践,运维工作不用那么苦逼。希望有经验的同学分享下。

论坛徽章:
4
戌狗
日期:2014-10-12 21:48:202015年辞旧岁徽章
日期:2015-03-03 16:54:15IT运维版块每日发帖之星
日期:2015-06-09 22:20:002016猴年福章徽章
日期:2016-02-18 15:30:34
发表于 2015-06-08 14:45 |显示全部楼层
回复 4# 十年有多少日
条理清晰,步骤完善,学习了。


   
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会,7折限时优惠重磅来袭!
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。

限时七折期:2019年8月31日前


----------------------------------------

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP