为了防止上线出现错误，我们的项目准备了A，B，两套环境。两套环境依次进行上线，如果上线出现问题的话，第一时间进行环境切换以免造成问题。但是初期的时候，使用两个环境的过程中由于人为的原因出现了很多问题。
其实上文所述，前四个问题都是可以从流程上进行避免的。虽然人做事一定会出错，但是我们可以通过制度进行管理。
例如：上线流程清单
通过统一的流程清单，对整个过程做好管理，尽量避免发生上述所说问题。
做事的时候，必须从全局出发，有了全局去指导微观才能避免出现低级错误。人+制度+机器，更好的管理我们的流程
问题描述： 发版后回归测试，不定时出现token失效，导致自动退出到登录界面。 如果操作的人员较多，token失效的就比较快，操作的人员较少token失效的相对
一、问题 昨天生产redis缩容，3主3从模式，重启了服务器，重启了redis； 结果今天发现生产服务报错了，连接不上redis。 排查发现，由于生产后台只配置了一个
事情原由 今天测试忽然在群里发了一个看似非常简单的线上问题，具体是：在后台通过订单编号(orderId)修改订单信息时，修改不成功 ，修改前后的订单数据完全没有发生变
背景 为了防止上线出现错误，我们的项目准备了A，B，两套环境。两套环境依次进行上线，如果上线出现问题的话，第一时间进行环境切换以免造成问题。但是初期的时候，使用两个环境的
故事背景 故事背景很简单。 1. 在我们的官网上，发布了我们的ar产品的学生端的安装包，供用户下载。 2. 这个安装包的下载是通过我们另外一个产品，上传到我们公司的
一：背景介绍 1：上午9:23，老师没有进行上课，但是却又很多的在线人员，并且在线人员的时间也不正确。 2：开发人员及时练习用户，查看用户上课情况。 3：10点整
事件背景 作者所在的公司核心业务是做政府信息化软件的，就是为政府部门开发信息化系统。其中有一款信息化软件是客户每天需要使用的，并且他们面向的客户就是老百姓。 某
场景： 查看当前时间是否在某一时间内 例如当前是 `周一上午10`点，就要去数据库查是否有`每周一上午9-11点`的数据 关键sql片段： AND bw.w
背景 线上应用需要进行一个涉及600W数据的操作，之前我们应用从来没有一次性应对这么大量的数据，最多就一次数十万而已。结果，这次600W的数据操作引起了生产事故，直接导致
电玩女神
小灰灰
亦凉
分手后的思念是犯贱
迷南。
还没有评论，来说两句吧...