论坛徽章:: 4

电梯直达

1楼 [收藏(0)] [报告]

发表于 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官方微博”

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

文库|博客

typuc

稍有积蓄

论坛徽章:: 4

2楼 [报告]

发表于 2015-06-06 00:42 |显示全部楼层

本帖最后由 typuc 于 2015-06-06 00:45 编辑

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

   单节点更新流程：

   数据库注意事项：
为了保证测试的真实和正确，需要将首先部署的节点连接到生产数据库。如果此次更新，对数据库表进行了增加字段操作，那么首先要保证当前
   运行的版本中插入数据SQL中插入值和字段一一对应。INSERT INTO table_name (列1, 列2,...) VALUES (值1, 值2,....)

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