開發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，這只是最咱們最基本的工做之一而已。