最近在和研发同学聊天的时候发现他们有一套数据库开发环境，严格的说这是一套混合环境，算是开发和测试环境的合体。其中负责管理这套环境的研发同学已经受不了了，不禁发出了感叹：什么事情都找我，我又不是DBA.
因为研发侧的数据库连接池满了也找他，数据库连不上了也找他，跑了这些年，数据库还从来没有备份过。 我们一般涉及测试环境，预发布环境和线上等环境的管理，而开发环境的管理相对松散，为此我整理了一下开发环境的使用现状。
整体而言，开发环境主要是为了提升开发效率，更方便的使用，主要是对于办公机开放，对权限的管理是相对松散的，为此这些年我看到过很多特殊的情况：
1）有的研发部门会自购服务器安装数据库，有些情况下安装部署不上，还会找我们友情支持
2）有的研发部门会在一台服务器上面ALL IN ONE的部署，各种服务堆在一个服务器上面，一荣俱荣，一损俱损。
3）很多开发环境数据库是安装在Windows上面的，有的还是32位的，而我们在Windows平台的MySQL数据库运维经验几乎为0
而测试环境的管理是相对会谨慎一些，尽可能只开放测试服务器的权限，部分权限的使用是需要审批机制的。
开发环境到测试环境需要贯穿表结构的同步和数据同步，这样一来一去，就能够实现更快速的发布和管理。
为此，我整理了下当前的情况，整个数据库的情况比想象的还要乱一些，比如数据库只用了一个root账号是对所有业务开通的，数据库连接池配置了150个连接，也难怪很多业务反馈时常连不上数据库，而更多的运维管理操作更是无从说起。
为此，做了如下的方案设计：目前有些研发侧同学对于开发环境，测试环境的概念是比较模糊的，那么我们就需要做一些前置的工作，把这个概念解释清楚，然后对一些业务做拆分，有些是开发业务，那么就完全可以通过自助化的开发环境交付来实现，如下图中的开发环境管理区域，而测试环境我们可以单独分配一台服务器，可以根据业务大类来做一些拆分。
从访问层面，测试服务器是不能访问开发数据库的，这也是我们整体设计的一个边界。
尤其是开发环境的管理，是我们需要着力改进的目标，有三个层面的实现难点，一个是对于虚拟化资源的管理，第二个是对于数据库权限的管控，比如收到不少业务的需求，希望能够在一个共同的数据库实现开发，也就意味着权限的设计方面需要做一定程度的共享设置。第三个是数据的双向同步，比如开发环境和测试环境的表结构映射，数据同步等。
最近在做的数据库环境标准化管理，仔细想想还是一步大棋，要涉及的层面也很多，需要做中长期的规划和推进。
