共计 1166 个字符，预计需要花费 3 分钟才能阅读完成。
一、前言
夜晚十点钟的时候源自拉群狂魔老板的问候：
今天下班前我自己都还登陆过的，咋突然间就不行了捏？怀着郁闷的心情，首先看了下为什么不能登陆，打开 了 F12 看了下：
json 错误? 再接着看到控制台打印的信息：
二、问题追踪
1. 因为先看到的是红色的 json 报错，所以第一反应是先检查了 json。首先先用 postman 确定了远程服务端可以登陆且返回的 json 没有问题：
2. 确定了服务端没有问题，就想会不会是前端 php 解析 json 错误，排查了一次 php 代码：
但是一想到近来并没有修改这些代码，怎么就出现无法登陆呢？服务端接口又可以正常访问？
然后又看了看上面的信息：
<b>Warning</b>：Unknown：write failed: No space left on device (28) in <b>Unknown</b>
Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct ()
也怪我没有细心看，只注重看了下面一段报错无法写 session 文件：Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct ()
于是乎又开始了一次百度老师的拜访：找到的无外乎都是关于无法写 session 文件的问题：修改 php.ini 中的 session.save_path = “/tmp” 目录，然后增加文件夹权限，再不行就将 session.auto_start = 0 改为 session.auto_start =1 重启了 php，但是还是无法解决问题，其实在这里我再细心点就可以察觉出问题了
如果我再仔细点看这句话就好了：Warning：Unknown：write failed: No space left on device (28) in Unknown
设备没有空间写入失败？怀着好奇的心情我看了下服务器的空间。。。：df -hl
看到这里的我已经是泪流满面。。。如果早点看下磁盘空间就好了。并没有想到服务器的磁盘不够，一直觉得磁盘是够的，但是服务所在的磁盘只有 40g，大半夜的问候了一下自家兄弟：
为啥其他服务都放在其他磁盘上，非得专门留下这个服务。。
三、总结
1. 这次磁盘很快就满是因为数据平台的日志打印太多，应该调整一下日志级别，只记录异常信息。2. 应该定时对服务器日志进行一个清理 3. 将服务放在大一些的磁盘中
最好的方法就是严格执行 1 和 2。
想起了之前开会的时候跟老板提过要一个运维，老板说等我们公司壮大了一定会增加人手的，现在不加他是考虑过的。然后会后偷偷的问我：运维是什么岗位？你能不能先干着？。。。都是泪 T T