最近碰到了一个比较奇怪的问题,一个用rewrite实现的Wordpress分页功能在测试和开发服务器上都没有问题,但是上线以后在生产环境上有问题。而且时有时无,很难找出规律,确定不了到底是什么地方出了问题。

已经采取的一些尝试,但是没有解决问题:

  • 查看生产环境错误日志
  • 同步生产环境上的数据库、各类配置,在测试服务器上试图重现
  • 让IT配合,修复生产服务器上的一些可能的潜在问题
  • 添加一些额外的运行日志

但是这些过程,由于要经过公司开发、PM、测试、IT等几个部门,效率非常低。反复几次大家之后没有结果,大家的情绪也都比较失落。最终也没有找到问题的所在,两周之后PM决定放弃解决这个问题,尝试别的实现方式。

虽然问题没解决,但是感觉以下几点以后还是要注意的。

1.争取在线调试的权限

虽说平常,开发人员不应该直接接触生产环境(应该通过工具,自动提交、测试、发布、验证)。但是在出现一些棘手问题时,开发人员有环境能重现问题是必要的,即使是在生产环境。在遵循一定的规范,谨慎小心的前提下,对生产环境有一定的访问处理权限,将有利于尽快找出问题所在,在以后的代码或者环境中避免类似问题。

2.开发发布流程有没有有缺失什么?

现在比较流行的开发部署模式是CI(持续集成开发),很多公司能做到每天向生产环境发布部署多次代码(有的甚至是几十次上百次)。

现在我们公司离这个水平还很远。我们现在的流程是QA和IT在配合部署更新,通常是一周为单位的。

即使我们不提CI,我们实际上还缺少一个staging server环境。简而言之,staging = production – users 。staging上应该能重现生产上能出现的问题,staging更重要的意义在于可以在部署更新到生产之前拦截可能出现的问题,在问题出现在生产环境之前暴露并解决。

我们没有一个几乎等同于生产环境的调试环境,测试和开发服务器跟生产环境有这样那样的差别。
当然更重要的是,我们的发布更新过程有还有很多手工过程,这不但易出错,而且也是造成环境差别的来源之一。

只有不断的把手工过程变成脚步,变成每个人随时都能使用的工具,才能提高发布效率,向CI看齐。不过这需要一个工程师主导的企业文化环境,在我们公司现在还很难。

3.换种方法实现,或者放弃吧。

当在一个问题上纠结太久时,也许该放下来想一想。这个功能必须这样做吗?换种方法行不行?这个功能真的有必要吗?不做行不行?
虽然有时候这些问题也不是我们能决定的,但是建议建议,也许会有意想不到的有好处。

参考

  1. Different methodologies for solving bugs that only occur in production
  2. Staging Servers, Source Control & Deploy Workflows, And Other Stuff Nobody Teaches You

看看我的其他文章

    共享到: