前言： 人蠢没办法，用不惯 iteye的编辑器。
细节管理，才是管理。
管理需要持久，不断完善，才能出效果。
管理不要怕麻烦，
管理不能得过且过，差不多，
管理需要严格执行。
一下是我发现的运维问题。都是对技术不理解。只是为了自己的方便。
不仅仅是运维的问题。也是管理层，架构师的问题。
观察，问题了很多人：
方便，没时间，没什么区别，能用就好，
自定义安装搞不定。一旦离开官方安装手册与博客，安装不成功。
没有对技术追求的心，没有对工作负责。
关于root用户，是团队沟通与管理有问题。
1，yum安装，或者rmp包安装
yum方式安装的都是yum默认软件。比如安装 java虚拟机是按照的 open-jdk。而开发用的官网的jdk，可能出现不兼容的情况。
血案： 开发与测试环境什么问题都没有。到了正式环境就报错，就Ingeter与int不兼容（大概就是这样）等等小问题，最后发现正式环境的jdk是 open-jdk，开发与测试都是官网的jdk。造成了通宵发布。最后把正式环境的jdk替换成 官网的jdk。替换过程比较麻烦（分析现有服务资源等，在另外一台部署，调试部署成功之后，修改nginx配置，关闭第一个服务器所有资源，修改jdk版本，重新启动服务，测试是否运行正常）。浪费了3 4个小时。整体浪费了一个团队差不多2天的时间。
血案：主从复制延迟，配置没问题，没有异常，就是延迟，最后一看尽然是 MariaDB。yum默认安装MySQL是MariaDB，MariaDB的innodb近期才提升到MySQL官方的5.7版本。以前一直是5.5.或者5.6。
yum方式安装版本，不可控。
血案：运维使用yum安装了redis，安装版本是2.8.0 有个复制bug（[FIX] Fixed a critical replication bug, see issue #1221.）。已经告诉运维了注意这个bug，不要yum安装，还是使用yum安装，造成正式环境，复制问题。服务紧急停止十分钟，把读写分离的代码，修改成读写master。
yum与rpm，安装不可控，目录不可控与配置不可控。
1，yum 与rpm安装默认都会解决依赖关系。
血案： 安装了多个java 软件。他们之前的依赖版本区别大。解决造成一些软件运行不正常。
无意卸载了 某个软件所有依赖，不小心删除其他软件的依赖。也是自己贱。
2，安装流程未知，安装目录未知。有问会说 看rpm执行代码。很复杂，你真得有那么多精力看代码。你需要那么复杂吗？
问题： MySQL rmp安装，会版本。做很多事情。同事，也会默认初始化MySQL。造成所有文件，都在默认模式，时间长了。或者 需要处理问题。造成很大的麻烦。
2，默认安装目录和一切都放到用户目录
直接按照官网或者博客的流程安装，usr目录下。
容易出问题。不方便管理。有时候。找东西真的找不到。很费时间。磁盘挂载，版本替换等等十分麻烦。
鄙人目前的软件与服务都是固定三个目录一个data，一个software，一个server。
血案：一台MySQL实例运行缓慢，进服务一看磁盘爆满，MySQL的binlog 与 undo日志十分庞大，因为软件是安装在usr目录下，/ 的挂载量不大，运维与DBA说。直接删除 binlog 与 undo，我说：找死吗？ 应用在执行批量update操作。谁知道binlog里面的情况怎么样？。解决这个事情的流程花了一周时间。数据量相对我们来说。处理由点麻烦。
在正式环境中，一般一台主机一般就只有一个数据库实例或者多个应用实例。软件也就两三个。真得没有必要安装到usr目录下。
usr目录的确是用户软件与bin安装目录。注意是 user，user。这个user是使用者或者开发者。一个正式环境是没有开发者的。
自定义目录可以有多个用户管理。这里十分方便。
这个系统十分简洁，干净。
管理十分简单，直接复制目录，压缩 scp，解压，安装环境变量，启动，OK。如果安装在usr目录用户用户目录，你还真的不敢这样做。
5，不管理软件版本
开发要什么就是什么。没有考虑，开发要这些对运维有什么影响。
6，不了解软件
直接安装，不也管。配置如何处理，里面的细节是什么。
7，没有运维管理。
完全手动安装，没有shell安装。更加没有自动化安装。