开发DBA如何有效地保障数据库应用的质量

作为一个开发DBA，要保障数据库应用的质量，很重要的一点就是必须在项目的每个阶段都参与到项目组的工做中。下面就各个阶段说一下我我的认为该作的一些工做吧：

1、需求阶段       要想能在整个项目周期中可以更早的了解项目所涉及到的内容，把握项目范围，而在后面的工做中取得更多的主动权使质量可以获得有效的控制，开发DBA就须要在需求被确认以前就开始参与。       一、项目孕育阶段：       在公司目前的项目流程中，需求阶段其实是在项目尚未确认是否要作的时候就开始了。在这个时候，通常状况下PD（或者运营）部门可能不会和咱们沟通，而 是和技术部门的RA或者架构师们沟通，描绘对该项目的一个大概的轮廓和需求，让技术部的同事提出一些对该项目的见解。一个项目最后是否须要作也正是在这个 阶段来肯定的。因此，这个时候若是RA或者架构对该项目在数据库方面的影响把握的不是很准确的话，可能就会形成后面项目的需求分析和确认的过程当中DBA和 PD部门之间可能会出现较多分歧。       要解决这个问题通常只有两种办法：一是经过沟通交流或者培训增强RA和架构对咱们数据库的了解和把握能力；二是经过各类途径使咱们本身能参与到这个阶段。 对于第一种办法，好处是能够减小咱们的工做量，而坏处就是架构和RA到底能对数据库方面的影响把握到什么程度是没办法很好地控制的。第二种方法的好处是我 们可以彻底由咱们本身把握到项目对数据库的影响，给出更准确的评估，而坏处一是增长了咱们的工做量，再就是比较难得到这个阶段的项目相关信息。考虑到这两 种方法各自的优劣，在国际站这边我如今其实是二者一块儿使用的。平时常经过沟通交流来增强RA和架构对数据库方面的一些了解，偶尔作一点培训。同时也和他 们约定，若是有较大动做（或项目）的时候都提早和咱们沟通。而后也增强和pd以及运营部门沟通，多了解一些他们的想法和打算，同时也常和他们聊聊网站哪些 地方的内容对数据库影响比较大哪些地方比较小，哪些核心内容的调整会影响较大哪些较小，让他们头脑中有一个大概的轮廓，也和他们约定有什么大动做或者想法 的时候提早和咱们打声招呼。那么，如何让架构师、RA以及PD和运营真正会提早和咱们沟通呢？就要靠咱们增强和他们的沟通，增强他们对咱们的信任程度。我 们这边也时常和他们沟通，主动去了解一些他们最近的想法，了解他们的一些困惑。并且经过沟通还能够消除运营或更前端的需求部门认为咱们不够配合的误会。其 实总的一点来讲就是像大师所说的，加强他们对咱们的信任感,让他们在有什么想法或者需求的时候就主动想和咱们聊聊征求一下咱们的意见，这才是最根本的目的 和咱们的目标。要达到这个目标，最基本也是最有效的方法就是有效的沟通，经过实际行动尽咱们的能力去帮助他们解决性能上面的问题，评估项目的影响和风险。 在刚开始工做的时候Jacky就和我说过，开发DBA的工做中有一项很是重要的内容，就是须要和不少不一样部门不一样角色去沟通，因此，沟通技巧也是咱们须要 很好掌握的。       二、需求分析和确认阶段：       在项目肯定了开始要作的时候，通常都会有一个项目kick off会议，也就是项目启动会议，这个时候通常都会叫上咱们DBA参加。会议通常主要是公布一个项目的大概时间计划和项目组成员的组成，这个时候就是一个 项目真正的开始了。以后接下来就是很是关键的需求分析工做了。这项工做主要由RA来主导，同时PD（或运营）一块儿参与进行。这个过程当中，通常来讲RA都会 常征求架构师的意见，有时候也会征求咱们DBA的意见（主要是RA以他们对数据库的把握能力来判断是否须要咱们参与需求分析过程）。通常项目在需求分析过 程中都会有两次需求确认会议：商业需求确认会和最终需求确认会，也就是咱们常说的BRD确认会合FRD确认会。在项目流程中，咱们的开发DBA都是须要参 与到这两次会议的。可是有些时候，确认会议上只是向项目开发人员，架构师以及DBA介绍一些商业需求以及在系统中大概的实现逻辑，到这时候，大部分需求其 实都已经定下来了。因此，有些时候若是在项目启动前咱们没有获取到关于项目足够的信息，在需求分析的过程当中又没有任何的状况下，可能会遇到在这个时候才发 现该项目某些地方对数据库影响很大，风险较高。而这个时候才提出，极可能就会形成以前的需求分析工做不少都须要返工从新分析从新设计，甚至某些需求根本就 没法实现，形成整个项目进度延后，严重的时候还会形成和PD等部门之间误会。因此，在项目启动以后需求确认以前，必定要常和RA沟通，跟进项目进度和相关 细节。有任何问题疑问都要尽早提出，表名观点。对于比较重要的问题，必定要和RA以及PD等部门的人坐在一块儿当面沟通，说明问题的所在，并给出咱们的建议 （若是有）。 2、开发阶段       一、系统设计阶段       当需求彻底肯定下来后，开发人员就会开始进行系统设计的工做了。通常来讲开发人员都会首先设计数据库schema（若是有建新表的需求），而后才是程序的 设计。这个时候咱们的重点沟通对象就从RA转移到开发工程师了。有些开发工程师可能会主动来找咱们，沟通schema设计方面的一些内容，而有些开发工程 师可能就不会和咱们沟通，而是本身直接本身完成schema设计，而后就交给咱们直接要求建表了。而每每那些不会主动找咱们的开发工程师大多都是一些新 手，更容易出问题，相对来讲一些较为资深和能力较强的开发工程师反而都会和咱们沟通一下，即便是一些很简单的表，也至少会先和咱们说一下。因此，在项目启 动会议的时候咱们就该注意一下项目中负责开发的工程师状况。经过咱们对他们的了解来判断对哪些人须要多花一点精力去跟进，哪些人是能够放心少花一些精力去 跟进。当交道打的多了之后，确定对每一个人的工做习惯，作事态度等都有一个大体了解。       实际上不只仅表结构的设计咱们须要关注，有些时候他们程序的实现方法也须要了解一些，尤为是在实现一些咱们认为比较重要或影响比较大的功能点 需求的时候，咱们最好是去了解一下他们是怎么来设计实现的。不一样的实现会给数据库带来不同的压力，一个好的实现所须要的数据库资源和一个较差的设计实现 相比，有些时候的差异甚至都不是一个数量级的。当遇到较差的实现的时候，咱们能够适当的提出一些咱们的建议，若是遇到困难，也能够向架构师来寻求帮助。这 也是咱们要求开发DBA最好要有必定开发经验，对开发有必定的了解的缘由之一。由于若是彻底不懂开发，可能就没法在设计实现上面发现问题了。并且在这个过 程中，经过不断的去和他们沟通，也可让咱们本身学习到更多的系统设计方面的知识和并积累相关经验，为从此更好的处理问题以及对项目影响的把握是有很大帮 助的。并且在系统设计层面的关注，对于自身能力的提升也是很是有帮助的。对于一个DBA来讲，最关注的就是系统的质量，系统的性能。而对于一个开发人员或 者项目经理来讲，可能更关注如何快速的实现需求，完成一个可交付使用的产品。一个DBA关注较多的系统设计和架构方面的内容之后，才能有更开阔的视野，才 可能从更高的层面来掌控项目的质量和性能。不管是对于自身的能力仍是之后的发展，不管是开发DBA仍是产品DBA抑或是之后转型架构师，都会有很大的帮 助。       二、开发编码阶段       当系统设计结束后，开发工程师就开始进行编码工做了。在这个过程当中，有些开发工程师可能会随时主动的将本身认为比较重要或把握不许是否有性能问题的sql 发给咱们，征求咱们的建议，但有些开发工程师是不会的，需求咱们主动去找他们要。可能你们会说，咱们能够等项目开发完成，提交测试的时候控制他们测试库的 变动的时候让他们一次性的提交sql给咱们，而后咱们再集中review全部的sql。在项目周期不长范围较小，同时并行的项目也比较少的时候这样作确实 是没有太多问题的，可是一旦同时有多个项目并行，或者项目比较大的话，就会出现问题了。最大的一个问题就是sql review的时间问题。若是一次性提交了不少的sql过来，极可能最后sql review过程就会成为项目的瓶颈，咱们本身也会压力比较大，没办法尽量的对一些sql进行较好的优化。再一个就是有些在review过程当中发现的有 些问题比较严重的sql的调整可能涉及到程序逻辑的改动，若是改动涉及到程序的变更比较大的话，开发工程师的返工工做量就会较大，不是很情愿配合，也会影 响项目的进度。像我这边国际站，并行项目很是多，有些项目周期拉的也比较长，我通常都是在项目边开发的时候就边和他们沟通，即便有些时候并非正式的让他 们提交sql，也会和他们沟通一下他们有没有遇到数据库方面的问题或者困惑。常常这样和他们沟通后，不少人慢慢就会有了一个习惯，只要是本身以为稍微有点 拿捏不许的sql，都会直接拿来问我一下。虽然这个时候他们的判断可能并不必定准确，可是对于稍微较为复杂的sql他们确定都会先发给咱们看看，若是 sql有什么问题咱们就能立刻开始优化，或者调整程序实现逻辑来解决掉，而不用等到全部代码都开发好了才开始作这件事情。这样在项目最后的sql review的工做其实是在项目进行过程当中就已经在慢慢进行了，咱们本身最后的review工做时间也就更宽裕一些了，同时也可让他们养成一个好的习 惯。固然，即便是这种方法，咱们在最后也应该让他们整理一遍用到的全部sql并发给咱们。 3、测试和最后发布阶段       一个项目进入测试阶段后也是如今项目流程中所规定的开始review sql的时间，若是在以前的开发阶段咱们就已经作了较多的工做，那么在这个阶段的时候可能就会比较容易控制了，可是若是以前没有作什么工做，全部sql都 在这个时候才开始review，就须要把握好review的进度了。同时，在测试过程当中，可能会由于修改某些bug，开发工程师改写某些sql，而这也是 开发工程师最容易忘记将sql提交给咱们的时候。因此在测试阶段咱们在review开发工程师以前提交的全部sql的时候，同时也要不断的和测试沟通 bug出现状况，和开发沟通有没有改动过什么sql。随时掌握sql的变更，才能随时掌控项目的性能质量。       在最后咱们手上应该有一个文件，里面保存着这个项目中新增或者修改的全部sql，由于咱们须要根据这份完整的sql文件来完善索引，以前sql没有彻底定下来的时候你所建立的索引有些可能到这个时候有些已经不适用了。       项目测试结束了，咱们也review完开发工程师给咱们的sql了，这个时候咱们最好再加一道保险，那就是从发布人员那边了解一下发布的文件列表，看看有 没有咱们没有看过的sql mapping文件的发布。像如今，国际站这边我就和配置管理员约定好了，项目发布的时候，她记下发布中须要更新哪些sql mapping文件并告诉我，随便什么方式都行，无论是mail仍是贸易通均可以，这样我至少能够控制不要某个mapping文件里面的sql有变更我这 边都彻底不知道。固然这个工做自己并非配置管理员的本职工做，她是否愿意帮这个忙就得靠咱们本身了，呵呵。 4、发布后阶段       项目发布了，RA可能开始了一个新项目的需求分析，开发工程师可能又开始作其余项目去了，这个时候咱们并不能立刻就彻底不去理会这个项目了，由于这个时候 才是真正考验咱们以前所作的工做成果的开始。咱们须要多看看产品数据库上面总体压力状况，看看这个项目所涉及到的那些sql有没有冒出来成为top sql。若是一切正常，那至少说明咱们以前的工做没有太多问题。若是发现里面有sql冒出来了，应该立刻分析为何会冒出来？执行计划和咱们当初预想的是 否一致？执行频率是否正常？以前准备的索引是否合理？而后着手优化，解决掉冒出来的sql。这个时候的优化工做必需要谨慎，对于已有系统上对象的任何改动 都须要三思：是否会引发某些sql语句执行计划的改变，是否会让某些对象失效等等。       有些项目发布一段时间后会有一个项目总结会，总结项目过程当中的一些经验教训，这个时候咱们也应该从咱们的角度提出对项目的见解，无论是好的仍是很差的，这样作同时也可让你们对数据库有更多一点的了解，更多一点的关注。       其实总的来讲，要想控制好一个项目中数据库应用的质量，就必须让本身在项目的整个阶段随时了解项目当前状况，分析清楚情况，让本身处于主动的状态处理各类事情，而不是仅仅在最后看看开发工程师写出并提交给咱们的sql，这只是最咱们最基本的工做之一而已。