遇到技术问题搞不定，怎么办？

somenzz

发布于 2020-12-10 11:12:23

8410

发布于 2020-12-10 11:12:23

最近在学习一个开源的 cmdb 系统 (配置管理系统) ，仓库链接：https://github.com/open-cmdb/cmdb，学习的这个开源项目有以下两原因：一是 cmdb 不仅在运维领域中有很强的实用价值，也可以用做资产管理系统。二是它用到的技术栈

前端：Vue.js + Element-UI + Vue Router + Vuex + Axios + Webpack
后端：Python3 + Django + Django REST framework + Elasticsearch + Mysql + LDAP + uwsgi + Nginx + Docker

都是当前最流行的技术，也是我比较感兴趣的，掌握之后可以自己写前端，写小程序，是今后一段时间的学习方向。前后端分离已经是业界所共识的一种开发/部署模式了，程序员还是专人做专事，这样的整体的效率才是最高的，有人可能会说了，现在全栈工程师特别火热，全栈往往被认为是全能型人才，比如前后端都精通，但是一个人精力有限、时间有限、生命也有限，怎么可能样样技术都精通呢，样样精通其实等于样样都不精通。全栈工程师应该在精通某一领域的前提下，有余力时再学习其他领域的知识，这样才能对项目有全局的思考就，做为运维工程师也可以解决更多技术领域的问题，出了问题可以很快定位是哪里出了问题。解决技术问题的类型越多，离全栈工程师的距离也就越来越近，所发挥的价值也就更大。

这里用的的技术中，我对 Python3 较熟悉一些，其次是 Django ，再其次是 Django REST framework、 uwsgi 、 Nginx，其他都听说过，但从来没有用过。因此在部署项目过程种，遇到了各种错误，虽然解决的问题千差万别，但方法相通的，因此我记录下来，希望这些方法对你有用。

解决问题的过程

我 git clone 一下项目源码，安装完 mysql、Elasticsearch、及一些依赖的 Python 库，修改了数据库连接的配置，满怀期待地执行了

python manage.py makemigrations

结果却报错了，弄了半天，一运行就报错了，程序就是这样，不过不报错，怎么能体现程序员的水平呢？于是看报错内容。报错内容如下：

django.db.utils.OperationalError: no such table: mgmt_permission

这个错误提示非常明显，就是数据库中不存在这个表 mgmt_permission，我用过 django，修改模型层中的类时，django 会自动修改对应的物理表，有时候由于在数据库手工删除或修改表就会导致报表不存在的错误，根据网上的方法，我删除了每个 app 下的 migrations 文件夹，让其重新建表，于是又期待地执行了

python manage.py makemigrations

失望的是，问题依旧，bing 和 google 上搜索到的方法都看了一遍，仍不适用。也请教过大神，说要仔细检查 settings 文件，我于一行一行代码地去看，没发现任何问题，将数据库删除，重新建立，错误依旧，简直被虐残了。这时，内心是崩溃的，气得去睡了一觉。

一觉醒来，清醒了许多，我在想，django 在 python manage.py makemigrations 时就失败了，根据打印信息，根本没有走到建表那一步，所有的表一个都没建，这就报了表不存在的错误，没建表，当然不会存在表了，那问题一定出在建表之前，是不是有代码先用了这个表，导致报表不存在的错误，于是在 mgmt 目录下搜索了所有用含有 Permission 的代码，结果发现一个初始化的脚本 initialize.py 中引用了，并在 view.py 中被导入，估计就是它了，注意掉 view.py 中的

from . import initialize

再次执行

python manage.py makemigrations
python manage.py migrate

成功，这时小兴奋了一把，然后再把恢复那步注释操作，执行

python manage.py runserver

成功地启动了 cmdb 后端。这里不得不说，如果作者在 readme.md 中加个小提示，我想他得到的星应该更多，不过我还是给这个仓库点了个星。

遇到技术问题搞不定，有什么方法？

首先，技术问题都是可以解决掉的，这里说的技术问题是是已经成熟的技术，由于编码错误或配置错误导致程序报错、系统故障等问题。遇到问题，不必惊慌，想应对办法，技术能力是一个人执行力的体现，因此不要害怕遇到错误，解决错误的过程就是提高执行力的过程。

其次，遇到问题先思考是哪一步出错了，通过日志打印，或调试确定是哪个环节，而不是直接将错误日志粘贴搜索引擎。定位后，如仍不能解决，再根据相关的关键字+报错信息去搜索引擎解决方法，推荐 bing 或 google ，搜索的第一页基本就够了。如果对于完全不熟悉的项目，建议先看文档，对着文档一步一步操作。

如果仍不能解决，看看这个项目\代码有没有运行成功的情况，如果有，运行成功的环境是怎样的，配置信息是怎样，是不是与操作系统有关，对成功案例的环境、依赖、配置、逐一对比，精确定位问题。还有些奇怪的问题是不是可以通过重启服务，或重启操作系统来解决。

如果还是无法解决，这个代码是谁写的，发邮件请教他，或者在 github 上提交 issue，或者直接在知乎上、stackoverflow上提问，提问时提供详细的配置信息和错误日志信息。

如果最后未解决，听我劝一句，放弃解决这个问题吧，可能它从一开始是就错的。

最后，做记录，不管解决还是未解决，都要做记录，后面你的同伴遇到同类的问题，可以做重要参考，他们定会感谢你的付出。

学习 cmdb 的小收获

之前没有部署过前后端分离的项目，这次算是学到了。前后端分离是指 web 前段的服务与 api 接口的服务不在同一域上。

本项目中：

web 前端：vue 编写的静态页面、js脚本等。提供给用户的服务地址为：http://127.0.0.1:8080。
后端：供前段使用的 api 接口，服务地址为: http://127.0.0.1:8080。
nginx 连接前端和后端。

web 前端可以使用 npm run dev 来启动服务，也可以使用 nginx 来启动，推荐使用 nginx ，简单快速，而且支持负载均衡，及各种优化配置。这里附上本例中的 ngnix 配置。

server {
        listen 8080;
        server_name localhost;

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
        root html;
        }

        root E:\github\cmdb-web\dist;
        index index.html;

        location / {
        try_files $uri $uri/ @router;
        index index.html;
        }

        location @router {
        rewrite ^.*$ /index.html last;
        }
        location ~ /api {
        proxy_pass http://127.0.0.1:8000;
       }
}