上个月帮一个刚做后端开发的朋友排错，他在自己笔记本上把服务调通了，按照步骤传到云上之后，怎么都访问不了。折腾了快三个小时，他一直怀疑是自己写的代码有bug，改了好几次版本都不行，最后发现只是云服务器的端口放行规则没加。这是我碰到的很多次类似情况里很普通的一个，我自己最开始做云服务器软件部署的时候，也踩过差不多的坑，那时候以为只要把软件上传解压，跑起来就算完，结果不到一周出了三个问题，不是磁盘满了就是进程被kill了，折腾了好久才理清楚里面的逻辑，所以对这些坑印象比较深。很多初次做云服务器软件部署的开发者，都会把本地开发的经验直接搬过来，忽略了云环境和本地环境的差异。
云服务器软件部署看起来只是把软件装到服务器上的简单操作，实际上涉及到网络、权限、资源、环境等多个层面的配置，任何一个环节出问题，都会导致服务不可用，很多新手就是因为不了解这一点，才会踩很多本来可以避免的坑。某种意义上来说，本地开发环境和云服务器的运行环境，本质目标不一样，默认配置的方向也不一样。本地是给开发者调试用的，默认开放所有权限，不会做太多访问限制，资源分配也跟着本地机器走。但云服务器大多用来跑对外提供服务的环境，默认配置偏向安全和稳定，很多规则会挡住正常的服务访问，这就是大部分坑的来源。
端口访问异常
这是初次做云服务器软件部署最常碰到的问题，服务启动后外部怎么都访问不到。很多人排查的第一步就是改代码和软件配置，改监听地址、换端口，折腾半天没结果。其实大部分时候，软件本身已经正常启动了，问题出在云环境的网络访问控制上。
现在云服务器默认都会有一层基础设施层面的网络访问控制，也就是常说的安全组，这个规则优先级比系统内部的防火墙还要高。很多人不知道有这个配置，装好软件就直接去访问，当然连不通。还有些人知道安全组，但是忘了配置系统内部的防火墙，同样会挡住访问。
判断这个问题其实很简单，先登录到云服务器上，测试本地端口是否正常监听，如果能拿到正常的响应，就说明软件本身没问题，问题一定出在网络层面。接下来先查系统防火墙的放行规则，再查外层的安全组配置，两步就能定位，不用乱改配置。
权限配置错误
这是云服务器软件部署里隐蔽性比较强的一类问题，报错信息往往不直观，很难快速定位。
很多人图方便，全程用最高权限用户操作，装软件跑服务都没问题，但是后续维护很容易出奇怪的问题。从安全的角度来说，用普通用户跑服务也更安全，就算服务出现漏洞被入侵，攻击者也拿不到最高权限，能减少很多损失，这也是为什么不要用最高权限跑服务的另一个原因。还有一些人知道不能用最高权限跑服务，新建了普通用户，但是代码和软件都放在最高权限用户的目录下，普通用户根本没有读取执行权限，进程一启动就报错，找半天找不到原因。
还有更细节的问题，比如上传压缩包的时候保留了原来的权限信息，解压之后文件权限是乱的，执行文件没有可执行权限，配置文件不给读写，这种情况也很常见，很多人解压完直接启动，不会特意检查权限。更隐蔽的是文件系统权限问题，有些云服务器默认对临时目录加上了禁止执行二进制的标记，如果你把程序放在这个目录下，就会莫名其妙启动失败，很多人会卡在这里很久。
我自己做云服务器软件部署的时候，习惯一开始就规划好用户和目录结构。专门新建一个用来跑对应服务的普通用户，软件装在系统级的统一目录，代码和数据放在专门的位置，日志单独放在另一个目录，只给跑服务的用户开放刚好需要的权限，不多开也不少开。解压完代码或者软件包，也会习惯性检查一遍权限，不对就及时改。这样刚开始会多花十几分钟，但是后续出问题的概率低很多，排查也方便。
资源配置不匹配
很多开发者直接把本地开发环境的配置参数原封不动搬到云服务器上，忽略了两者可用资源的差异，这也是很常见的问题。
我之前碰到过一个案例，一个Java应用部署上去之后，每隔几天就莫名其妙死掉，重启之后又能正常跑几天，然后再死。排查了很久才发现，开发者本地机器有16G内存，给应用设了8G的堆内存，但是云服务器总共才4G可用内存，应用启动的时候内存占用超过限制，就会被系统主动杀掉。因为不是每次启动都刚好占满内存，所以隔一段时间出一次问题，很难定位。还有一些开发者，为了优化性能，给应用开了太多的缓存，缓存占的内存没有算进去，导致实际内存占用远超预期，最后触发系统的内存限制，这个也是比较常见的情况。
还有一种情况，就是很多人同时在一台云服务器上跑多个服务，没有做资源规划，某个服务高峰期占了太多内存或者CPU，导致其他服务资源不够被干掉，这种情况在配置不高的服务器上特别常见。
这种因为资源不足导致的问题，大部分时候系统日志里都会留下记录，排查的时候先看系统日志，能省很多时间。做云服务器软件部署的时候，一定要先确认当前服务器的可用资源，再根据资源调整软件的配置参数，不要直接照搬本地的配置。内存小的服务器，就调小应用的内存占用，CPU核心少的，就控制好进程线程的数量，多服务部署就要提前预留足够的剩余空间，不要把资源占满，不然高峰期很容易出问题。
依赖环境不一致
本地开发环境用了很久，开发者会安装各种各样的基础依赖，很多依赖是系统自带的，或者开发过程中慢慢装上的，开发者自己都记不清。等到做云服务器软件部署的时候，只传了自己写的代码或者编译好的程序，漏掉了系统级的基础依赖，运行的时候就会报找不到动态库，或者找不到命令的错。
有些开发者会忽略这个步骤，觉得自己写的代码只有几个文件，不需要什么依赖，实际上很多功能都依赖系统的基础组件，稍微复杂一点的应用都会用到，所以依赖检查不能少。还有一些开发者用了比较偏门的依赖，或者自己编译的自定义依赖，没有把这些放到部署包里，到了云上根本找不到，这种情况也很多。还有一种情况，不同发行版的系统，基础库的版本不一样，比如有些新编译的二进制程序需要较高版本的glibc，在新系统上能跑，在旧系统版本上就跑不起来，报错信息也不直观，很多新手不知道怎么处理。
如果不用容器管理依赖，我自己的做法是，打包部署之前，先列好所有需要的依赖，包括系统层面的基础库和应用层面的第三方包，部署的时候逐一核对安装，确认每个依赖的版本都对，再启动服务。如果是跨系统部署，最好在目标系统上重新编译一遍程序，或者把需要的依赖一起打包进去，避免版本不兼容的问题。
容易忽略的后续配置
很多人觉得，云服务器软件部署只要软件能正常启动、能访问就算完成了，其实还有两个很容易忽略的配置，没做的话后续大概率出问题。我自己之前就碰到过日志占满磁盘的问题，那时候刚做云服务器软件部署，不懂这些，跑了快四个月，服务突然停了，上去一看磁盘利用率100%，清理了半天才能恢复，从那之后我每次部署都会先配好日志轮转。
第一个是开机自启和异常重启配置。很多人部署完测试没问题就不管了，等到服务器因为维护重启之后，发现服务没起来，整个服务都断了，才想起没配开机自启。还有些人配了开机自启，但是没设置异常退出自动重启，服务因为意外掉了就一直停着，直到有人发现才会处理。现在大部分系统都有统一的服务管理工具，只要写一个简单的配置，就能实现开机自启和异常自动重启，花不了十分钟，能避免很多大问题。
第二个是日志轮转配置。很多服务默认会把所有日志都打在同一个文件里，不会自动切割清理，跑的时间长了，日志文件会越来越大，最后把整个磁盘占满，服务没法写日志就直接停掉了。这种问题潜伏期很长，可能三五个月都没事，一发作就是大问题，只要部署的时候开一下日志轮转，设置好按天切割，自动删除过期旧日志，就能解决。
最近几年很多人开始用容器做云服务器软件部署，确实解决了很多环境不一致和依赖的问题，简化了部署流程。但是容器化部署也有新的常见问题，最常见的就是数据持久化的问题，很多新手把需要持久存储的数据放在容器内部的目录里，容器重启或者重新部署之后，数据就丢了，造成很大的麻烦。还有容器的网络默认和宿主机不是同一个网段，配置不对也会出现访问不了的问题，这些都是用容器做云服务器软件部署的时候需要额外注意的点。容器是解决问题的工具，解决了旧问题也带来了新的注意点，不能因为用了容器就放松对配置的检查。
我自己多次做云服务器软件部署之后，感觉到比较重要的一点，就是排查问题要按顺序来，不要上来就乱试。碰到问题先分清楚属于哪一层，先查服务有没有正常启动，再查权限对不对，再查网络连通性，最后再查代码本身，一步步排除，大部分问题都能很快找到。很多人碰到问题就乱改配置，试各种网上的解决方案，最后原来正确的配置也被改错了，排查难度反而更高。
还有一个关于版本选择的小经验，对于跑稳定服务的云服务器软件部署来说，优先选官方的稳定版更合适。很多人喜欢装最新的开发版，觉得功能多，但是最新版本往往会有一些没被发现的问题，出了问题也找不到太多现成的解决方案，排查成本很高。当然如果是测试环境，或者确实需要用到新功能，那另当别论，生产环境还是稳定优先，这一点我觉得是比较重要的取舍。