生产环境上线程序导致服务故障案例解析

生产环境上线发布程序导致服务故障案例解析

（老男孩郑重声明：本文不针对任何公司和个人，仅供大家学习交流之用）

1 由生产操作失误引起的故障.......................................................................................... 2

1.1该公司项目的上线流程回顾................................................................................. 2

1.2生产误操作事发经过描述.................................................................................... 2

1.3老男孩老师评价上线导致业务故障事件............................................................... 3

1.4从操作者那得到的其他信息................................................................................. 4

1.5给操作者的建议.................................................................................................. 4

1.6老男孩老师推荐的上线解决方案结构图............................................................... 6

1.7老男孩给企业的一些业务更新流程制度建议........................................................ 6

1.7.1制度与流程控制........................................................................................ 6

1.7.1.1项目开发制度流程............................................................................ 6

1.7.1.2数据库更新流程................................................................................ 7

1.7.1.3 DBA参与项目数据库设计.................................................................. 7

1.7.1.4各种操作申请流程............................................................................ 7

1.7.1.5定期对内部人员培训......................................................................... 7

 

1 由生产操作失误引起的故障

1.1该公司项目的上线流程回顾

以下来自【操作人】的总结：

对于我司项目一次上线数据库误操作故障的总结：

我司相关人员在前天开过上线会议后，定于过后一天进行生产系统发布：

事情是这样的

首先呢，我先说下我司项目的上线流程：

1，开发人员进行开发，在UAT环境(测试环境)中进行测试，测试通过后，由测试人员整理文档，准备上线

2，开上线会议（会议中定演练时间，上生产时间），时间都是定于晚上

3，开发人员将项目打包

4，我司产品部门发起wiki，在wiki中再次说明演练时间和上线时间，然后开发人员回wiki(将项目放入wiki，并说明一些注意点)

5，然后项目经理，经理，再回wiki，表示同意发布

6，系统部(运维部)人员登录wiki，将项目下载下来

7，然后就是准备演练，演练再次通过后正式上生产

8，上线完后，测试人员测试，测试没问题，回wiki。然后wiki的发起人关闭wiki。

老男孩老师评价：该公司的上线流程还是不错的，赞下，还有很多公司FTP直接上线的，不可取，堵住后门，监控好前门，是我一直给大家讲的。

1.2生产误操作事发经过描述

话说那天测试通过后，项目上演练环境和生产都是由我【操作人】来负责：

那次的上线首先是开发人员让我执行了几条sql，前几条没问题，到了后一条，我执行当中，我公司网络断了，这个时候我不知道那条有没有执行成功，然后等网络修复后我就回滚，（想回滚后都重新执行下），这一回滚，唉呀，出问题了。当时我在执行sql的时候我们连数据库的web服务没有停，在我执行前几条sql的时候是有交易的，但当我回滚后，马上运行客服人员就跑到我那说数据没了，说刚刚看到明明有交易，一刷新忽然就没了，这个时候我刷一下明白了怎么回事，但当时我没说，已经出现了这种情况。我说让他等会。我那还在进行回滚（一个多G的数据库回滚了半个小时。。。）。

然后我给我主管打电话了，说明了问题，他说让我别急，先保证生产服务正常运行。。。

由于我的这个误操作，开发的项目经理都疯了。。。然后立马惊动了公司技术部老总，然后老板

然后老板立马又召开紧急会议，说数据现在找不回来，后台查不到，一旦有用户投诉，说多少钱立马退多少钱

唉呀，我的这个脑子啊……

当天的上线取消了。。。

 

其实后来想我当时急着回滚是错误的，应该先问下开发的那边是否执行成功了，或者我查下进程。开发的后来也是这么给我说。

还有一点当时公司网络中断也是个事。。。网络不稳定不应该上线（那天供应商那边网络有问题，没有给及时通知）

有的会问只有一台数据库吗，问的好，我们是有主备两台数据库的，问题是在国庆假期期间机房切电源的时候，宕机了，然后启动后进主数据库找不到库了，当时那个急啊，然后就立马切换到备份的服务器上了，主的没有起，后来找到了主的为什么找不到库的原因（是因为机器启动后分区没有自动挂载上，手动挂载上后进数据库立马找到了），但由于这个时候从数据库和主的已经不同步了，就暂时用的从的，想等下次上线的时候在处理下，所以这次上线的时候就一个数据库。这是我们系统部没有做到位。

还有要说的一点就是我前面提到了演练环境，我为什么会动到了生产，事情是这样的，没有演练环境我部门也多次给领导提了，但领导不批买设备，然后就是每次演练的时候其实我动的也是生产（只是针对的这个项目没演练环境，其他的有），演练，什么是演练，表演练习嘛，肯定不能动到生产，但演练环境必须和生产一样。

由于这次上线失败暴露出很多问题。我们部门没有做到位的是：主备数据库，在那几天运行的只有一台。供应商网络那天有问题没有及时通知，如果及时通知上线我们会取消。还有我们提了多次买设备，领导没批，终于没演练环境动生产动坏了。还有一点就是那天其实我是没有看到wiki，而且不到上线时间，开发人员就和我QQ说让我操作，我当时也就操作了，这个说明的是我没有严格的按照公司的项目上线流程来走，否则出了问题是有人担待的，这没有证据什么的出问题只能找到我头上。

最终我写了检讨书。唉，苦逼啊！

1.3老男孩老师评价上线导致业务故障事件

1）根据操作者的描述，应该说出现这个问题是必然的，只是频率多少的问题而已。

2）该公司的上线流程也还是不错的。但老男孩认为和标准还是有差距，例如：上线流程的步骤缺失,没IDC测试环境，上线前出现问题的，回滚方案不完善。

3）上线前，比较好的方法是开发和运维参与人，一起开个会说明需要注意的事项，在WIKI上说还是不够的，起不到很好提醒的目的。

4）上线人员对开发给的SQL语句一无所知，如果是新项目新表，而且是插入的数据，那可以不用回滚的。直接删了库表，重新导入就好了。

5）主库挂了启用从库后，应该立刻开启binlog日志，并尽快做一次全备，然后做好新从库，否则，用出问题老的数据回滚一定会丢数据。这里运维及领导有侥幸心理了。

6）本地分区启动应该放在FSTAB里，并且事先重启测试好，一般来说是会挂载的，对于NFS、MFS等挂载可以放入rc.local，并且使用nagios做好挂载的监控。

7）执行SQL出问题后，回滚方案要设计好，比如假如SQL执行出问题，如何回滚，显然，操作者没思考过这个问题（领导们也没想到）。

8）DB数据量太大，回滚时间太长了，实际工作中可以考虑分库分表备份，恢复时有针对性的恢复会更快（需要考虑表关联问题）。

9）长时间执行任务时，可以使得脚本后台执行或者通过存储过程，不要再SSH客户端执行。

10）领导不批购买设备也是有责任的，这块运维人员应该争取，否则就要以邮件或者会议的形式明确说清楚厉害关系，按照老男孩的理解，能拿生产测试的，都是不会重要的业务，就像很多公司还在用139和飞信报警一样，都是运维自找麻烦，报警报不出来个人都要承担责任（王八钻灶坑，憋气又窝火，被人当炮灰）。

11）适当花钱把事做好是基本原则；不花钱，事还要办的漂亮，就好比让公鸡下蛋，让尼姑生孩子。

12）运维人员要确保质量和工期满足需求（底线），然后申请预算成本解决问题。不能压缩质量和工期，然后，少花钱，解决事没达到老板要求，老板看的是做事的结果，不是你省的那几个钱，到时你只有哑巴吃黄连了。

13）说服老大购买设备，要用数据说话，切记口头，写方案写文档，最差也要邮件说明，论点明确，论据充分。

14）项目负责制，上线，日常网站出问题，开发有责任，不能只责问运维，运维是开发商，开发是住户，基础系统和网络没故障，一般来说运维就无能为力了。

1.4从操作者那得到的其他信息 SQL语句都是新表，有建表，插入，更新等语句。这样的话出问题整个数据库回滚就没必要了。 1.5给操作者的建议 老男孩 17:58:28
在不
操作者网友 17:58:37
在，还没下班呢
老男孩 17:58:48
事情过去了，好好汲取教训就好了，别难过了。
操作者网友 17:58:55
嗯，
老男孩 17:58:58
谁都会犯错，老师曾经也犯过错误。 以后亡羊补牢改正就好。
操作者网友 17:59:19
嗯，明白了，记住了
老男孩 17:59:24
我执行了几条sql 那几个SQL能给我么，可以把表名替换了。
操作者网友 17:59:31
在不犯这样的错了
老男孩 17:59:38
框架留给我。 操作者网友 18:00:01
我执行的sql吗？
老男孩 18:00:02
我写个分析文档给你，对
如果都是INSERT 那没必要回滚的
语句的内容决定如何回滚
操作者网友 18:01:47
已经那样了，现在程序员通过程序日志找订单呢
老男孩 18:04:11
要学会重视错误，才能更好地进步
操作者网友 18:04:07

这样的几条
应该就是创建，插入之类的

老男孩 18:04:28
都是新表吧

应该和老数据没关系吧
操作者网友 18:04:38
嗯，

老男孩 18:04:56
那断了一点事没有

操作者网友 18:04:57
我当时没有看他们sql是什么语句

老男孩 18:05:08
删了表重新导入就好

1.6老男孩老师推荐的上线解决方案结构图

提示：有关大规模集群上线的门户完整解决方案见老男孩linux培训课程细节教案及讲解。在实际上线中因代码的不同会导致上线的方式有区别，如PHP,JAVA上线方式就大不一样。另外，上线整个过程应该确保业务时平滑的。这对系统架构及负载均衡器及各个业务上线都提出高的要求。

最后，上线的业务重要级别及上线频繁度也决定着上线方案的不一样。 1.7老男孩给企业的一些业务更新流程制度建议 以下内容摘录《老男孩linux运维实战培训-MySQL数据库安全权限控制管理思想》教案部分 1.7.1制度与流程控制 1.7.1.1项目开发制度流程 办公开发环境--->办公测试环境--->IDC测试环境--->IDC正式环境。通过这种较完善的项目开发制度及流程控制，尽可能的防止潜在的问题隐患发生。 1.7.1.2数据库更新流程 开发人员提交需求--->开发主管审核--->部门领导审核--->DBA(运维)审核---> DBA(运维)执行项目开发制度及流程控制的数据库更新步骤（每个步骤都要测试），最后在IDC正式环境执行。 需要说明的是，在开发人员一开始提交需求时，就可以同时抄给以上的领导及审核人员，然后，审核人员依次审核。对于特殊紧急需求，可以根据紧急程度特殊处理，这里可以制定个紧急需求处理流程，比如:开发人员提交需求--->DBA(运维)审核,然后操作完在汇报给其它审核人员。 通过完善的数据库更新流程控制，可以防止很多潜在的数据丢失、破坏等问题发生。其实比较好的管理方案是，所有的需求变更都有管理平台，类似OA系统一样，有审批有历史可查。 1.7.1.3 DBA参与项目数据库设计 在项目开发环节上， DBA或资深运维人员最好参与数据库设计与审核工作，这样可以从源头上减少降低不良的数据库设计及不良SQL语句的发生，还可以做所有语句的审核工作，包括select，但这个需要评估工作量是否允许，一般的互联网公司实施全审核比较困难。 1.7.1.4各种操作申请流程 1）开发等人员权限申请流程。 2）数据库更新执行流程。 3）烂SQL语句计入KPI考核。 1.7.1.5定期对内部人员培训 定期给开发及相关人员培训，目的还是从源头上降低不良数据库设计及不良SQL语句的发生，并通过培训让大家知晓大家数据库性能的重要性，让他大家提升开发时照顾数据库性能的意识。 1）数据库设计规范及制度。 2）SQL语句执行优化，性能优化技巧等。 3）数据库架构设计等内容。 更多核心内容，可参考老男孩培训教案：

1.8事后和操作者沟通花絮： 老男孩 21:35:50
看下啊，对了，看看方便我给其他人分享么
这个经验可能对大家都有用。
操作者网友21:37:13
老师，你下面的分析太好了，太有用了，受益匪浅啊
可以分享，对大家可能会有帮助，以免犯同样的错误
操作者网友21:40:17
我负责的这个项目是增值项目，还是很重要的，公司其他项目都得访问它的接口，由于这次事故，公司老总服务器给批了
但这次的教训我是记住了，说实话我们运维人员是做的是有些地方不到位 老男-孩 21:45:49
我回头发博客上你可以把地址分享下给大家你们共同进步吧
操作者网友 21:46:05
嗯，谢谢老师给的分析及建议
老-男孩 21:48:02
客气了，不过写了几个小时，写个文档很耗时啊。
操作者网友 21:48:33
嗯，这个明白，辛苦了，老师
老男|孩 21:49:00
你能认识到问题，也是很难能宝贵的。赞，知错能改就是好同志。
(over) 阅读更多