黑与白之间的平滑过渡，要如何规避风险？

typuc

获奖名单已公布：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官方微博”



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

Anonymity124

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

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

虫虫猫

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

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

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

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

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

十年有多少日

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

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

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

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

action08

将帅无能，累死三军

stay_sun

1、你的工作中应用更新是否有固定的时间点？如何应付紧急更新。
目前公司正在做自动化更新。作为初创公司，新的软件bug很多，更新也很繁琐，容易出错。
座椅做了自动化更新软件。目前使用 bash java 做的更新  不过我觉得  还是python 写比较好
2、你工作中更新流程。
研发团队提出更新后 程序 自动从svn  打包代码 发布到测试服务器上 进行测试，测试通过后 直接发布生产环境
3、为了解决夜晚加班疲劳和人员不足的问题，如果需要白天也要更新应用，怎样进行安全高效的更新？
自动化发布  控制好流程 就没有问题了  哈哈
4、你工作中是否采用了灰度发布，如何解决灰度发布中遇到的问题，比如数据一致性，应用测试。或者你谈谈对灰度发布的理解。
自动化发布 有测试环节  ，混滚方案  直接 出问题 自动回滚 老版本

typuc

我也来谈谈。
1、你的工作中应用更新是否有固定的时间点？如何应付紧急更新。
    之前公司每周二和周四晚上有更新，这样保证万一有突发情况，开发和运维都有人在；如果有紧急更新，需要开发，运营领导同意，然后运维立即更新。
2、你工作中更新流程。
    开发环境测试开发人员负责；然后交由测试人员测试环境部署测试；然后在预上线环境部署测试；最后确定生产更新时间，运营发布公告，客户做好解释工作，运维 DBA晚上业务低峰时段进行更新。
3、为了解决夜晚加班疲劳和人员不足的问题，如果需要白天也要更新应用，怎样进行安全高效的更新？
   多节点情况下，先把后端一个节点从负载设备上摘下，然后进行更新，确认无误后再挂载到负载上；然后观察业务日志，是否有异常，如果无异常再更新其他节点。这种方式有以下不足：
          A,通过观察业务日志比较费时，而且不准确；适合10个以下的节点；
          B,无法准确的将生产测试请求转发到最先更新的那个节点，无法准确的测试应用；
          C,如果涉及到数据修改，要保证修改后的数据库对未更新的节点依然可用；
4、你工作中是否采用了灰度发布，如何解决灰度发布中遇到的问题，比如数据一致性，应用测试。或者你谈谈对灰度发布的理解。
    暂时未采用，处于前期调研。以下是个人理解：
     灰度发布流程：由点到面，到全局，在不中断用户使用情况下进行日常更新；最大程度提高服务可用性，实现应用快速部署。
     发布通过用户流量牵引（通过配置负载可以测试人员IP发起的请求，转发到已经更新的节点），实现快速准确的测试，用户仍旧访问未更新的版本，实际工作中还会更加复杂。
         点：单个节点 ； 面：区域集群 ； 全局：所有区域
         
        
         单节点更新流程：
         
         
          数据库注意事项：
                为了保证测试的真实和正确，需要将首先部署的节点连接到生产数据库。如果此次更新，对数据库表进行了增加字段操作，那么首先要保证当前
          运行的版本中插入数据SQL中插入值和字段一一对应。INSERT INTO table_name (列1, 列2,...) VALUES (值1, 值2,....)

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

typuc

回复 4# 十年有多少日
条理清晰，步骤完善，学习了。