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

[url][/url]生产环境上线发布程序导致服务故障案例解析
（老男孩郑重声明：本文不针对任何公司和个人，仅供大家学习交流之用）
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语句都是新表，有建表，插入，更新等语句。这样的话出问题整个数据库回滚就没必要了。[url]生产环境上线发布程序导致服务故障案例解析
（老男孩郑重声明：本文不针对任何公司和个人，仅供大家学习交流之用）
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语句都是新表，有建表，插入，更新等语句。这样的话出问题整个数据库回滚就没必要了。[img][/img]生产环境上线发布程序导致服务故障案例解析
（老男孩郑重声明：本文不针对任何公司和个人，仅供大家学习交流之用）
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语句都是新表，有建表，插入，更新等语句。这样的话出问题整个数据库回滚就没必要了。
原文连接： http://oldboy.blog.51cto.com/2561410/1034871