其实提起此问题，做系统运维的人都会觉得这个问题很弱，也很low，但是在系统用户管理上，确是经常会遇到的问题，但是此问题也是可以进行有效的规避的。

     先说所遇到的问题现象吧，生产上的用户在创建过程中，没有经过统一的uid\gid规划，结果多台服务器上存在了相同的用户有不同的uid\gid。而且这些应用用户都有一个相同的NAS挂载点，且应用启动也是由此用户启停。由于相同用户是不同的uid\gid，所以等于是两个不同的用户间的访问，所以相互间肯定存在互相读写的权限拒绝问题。

     解决方案：

     1、梳理出受影响的主机列表。

     2、找出对应主机列表中的应用负责人。

     3、协商停机操作窗口。

     4、停掉所有与此用户相关的应用。

     5、统一用户的uid\gid。

     6、NAS上重新统一一遍uid\gid。

     7、重启受影响主机的操作系统。

     说到这里，看来一个应用用户的uid\gid修改，如此细小的问题，并不是说直接用usermod -u uid 用户名直接修改那么简单，也不是直接vi /etc/passwd /etc/group 那么简单。一旦这个错误的用户负责了应用的启停，它的uid是会被进程号占用的。所以稍有不慎，会中断业务的连续性，对公司的收入产生影响。

    规避的方法，可以通过CMDB的用户管理信息列表来对生产的用户进行统一的uid\gid规划。在用户分类上，可以分为实名用户、网络用户、系统维护用户、应用用户、ftp用户，不同的用户间gid也不相同。创建维护者可以在用户管理界面中知道所建立的用户是属于什么类别，当中的uid号已经对应的下一位是什么。这样很方便的就能进行用户创建；即使在操作过程中，存在误操作，回滚和追溯都是很容易的。但切忌创建的时候随心所欲、天马行空，这样对生产系统是毁灭性的灾难。