DBA，不再是聖職

注意：這篇工程文章由我們的 DBA Silvia Botros 撰寫，最初於 2016 年 12 月出現在 Sysadvent 博客上。

公司多年來一直擁有並需要數據庫管理員。 數據是企業最重要的資產之一。 這意味著許多企業一旦發展到必須能夠快速擴展的地步，就需要有人來確保資產得到妥善管理、性能滿足產品需求，並且可以在發生災難時進行恢復。

在傳統意義上，DBA 的工作意味著她是唯一有權訪問託管數據的服務器的人，是為新特性創建新數據庫集群的人，是設計新模式的人，也是唯一在生產環境中發生與數據庫相關的任何問題時聯繫的人。

由於 DBA 傳統上具有如此獨特的角色，因此他們的時間非常寶貴，因此當日常任務不堪重負時，就很難從全局考慮。 在 DBA 領域，通常會使用 bash 之類的脆弱工具來執行各種操作任務。 需要從乾淨的操作系統安裝中進行新的數據庫設置？ 獲取、驗證或恢復備份？ 輪換分區或陳舊數據？ 當您最常用的工具是 bash 腳本時，一切看起來都像釘子。 我相信很多讀者都在準備推文來告訴我 bash 有多麼強大，但請在評估我的推理之後再發表評論。

這一切聽起來像你作為 DBA 的工作描述嗎？ 職位描述是否詳細討論了升級服務器、創建和測試備份以及監控？ 大多數典型的 DBA 職位發布都會確保您必須配置和設置“多個”數據庫服務器（因為期望 DBA 手工製作它們），並使用（手工製作的）腳本自動執行數據庫管理任務。

對於成長中、快節奏的組織中通常由一個人組成的團隊來說，這真的是一種可擴展的方法嗎？

我在這裡爭辯說，您的工作不是執行和管理備份、創建和管理數據庫或優化查詢。 您將在您的工作範圍內完成所有這些事情，但主要目標是使您的業務數據可訪問和可擴展。 這不僅是為了讓企業運行當前的產品，而且是為了構建新功能並為客戶提供價值。

為什麼

你可能想問，我為什麼要這樣做？ 傳統上繼續執行 DBA 角色有一個論點：工作安全，對嗎？ 如今，許多技術組織都在執行以下一項或多項操作：

• 他們由許多較小的團隊組成
• 它們通過創建許多微服務來代替一個或幾個更大的服務來提供功能
• 他們採用敏捷方法來加速功能的交付
• 他們將運營和工程結合在一個領導下
• 他們在設計過程中儘早將運營工程師與開發人員一起嵌入
• 運營中的 DBA 孤島意味著運營團隊在自己的堆棧中幫助調試生產問題的能力較低，有時在沒有幫助的情況下無法響應和修復問題，而且坦率地說，如果他們需要與工程團隊進行更密切和更早的合作，則更不可信不要實踐他們在 Tech Ops 中宣揚的內容。

那麼可以做些什麼來打破這個孤島，讓其他人更容易調試，幫助擴展數據庫層，讓工程師能夠設計可擴展的服務呢？ 大多數嶄露頭角的商店最多只有一名內部 DBA。 一個 DBA 能否“出席”所有設計會議，批准每一次架構更改，並隨時待命應對龐大且不斷增長的數據庫足跡？

DBA 不再是守門人或魔術師。 DBA 可以而且應該成為組織中工程師的知識和專業知識的來源。 她不僅應該幫助交付團隊交付功能，還應該交付可擴展的產品，讓他們不必擔心數據庫。 但是，DBA 如何在管理數據層的日常工作中實現這一目標呢？ 作為 DBA，您可以通過多種方式讓自己變得卓越。

配置管理

這是一個非常重要的。 DBA 傾向於使用 bash 等老式工具來設置數據庫。 我之前提到過這一點，我並不反對使用 bash 本身。 實際上，我經常使用它。 但它不是集群設置的正確工具。 特別是如果其餘的操作不使用 Bash 來管理架構的其餘部分。 確實，運維工程師也知道 Bash，但是如果他們使用 Chef 或 Puppet 之類的工具來管理基礎架構的其餘部分，並且數據庫主要由 DBA 編寫的手工腳本來管理，那麼你就是在給他們提供一個障礙在需要緊急更改時提供幫助。

更重要的是，幫助工程團隊自助服務並擁有他們為新功能“foo”所需的新集群的創建變得更加困難。你成為完成工作的“阻礙者”。 熟悉貴公司的配置管理也是一個雙向的好處。 隨著您熟悉基礎架構的管理方式，您將了解團隊的標準，更加熟悉堆棧，並能夠就最終影響產品規模的變更進行協作。

將工程組織的產品和基礎設施作為一個整體進行調整的 DBA 是非常寶貴的。

操作手冊

從技術上講，這是您必須編寫的文檔的一個子集，但根據我的經驗，這證明它更有用，我覺得必須單獨指出它。 當我說運行手冊時，我特別指的是為非 DBA 的受眾編寫的文檔。 作為 DBA，我們可能會遇到很多生產 DB 問題，這些問題對我們來說很容易調試和解決。 我們往往低估了肌肉記憶，我們陷入了“只給我發送頁面”的模式，我們“照顧好事情”。

如果您的運營團隊像我的一樣，您是唯一的 DBA，則可能意味著團隊中的其他人是 DB 相關事件頁面時的第一道防線。 一些關於如何進行初始調試和數據收集的簡單文檔可以大大幫助運營團隊的其他成員熟悉數據庫層並更熟悉我們如何監控和調試它。 即使該事件仍然導致分頁 DBA，緩慢但肯定地，運行手冊成為每個人添加所學知識的地方。

此外，我將指向相關 Runbook 部分的鏈接（使用錨點！）添加到轉到尋呼機的頁面描述中。 這對於凌晨 3 點被數據庫主機尋呼以找到開始的地方的人非常有幫助。 這些東西可能看起來很小，但根據我的經驗，它們在為我的運營團隊在必要時在數據庫層工作時打破了心理障礙方面已經走了很長一段路。

作為個人喜好，我將這些作為降價文檔寫在我的廚師食譜存儲庫中。 這無縫地融入了拉取請求、審查和合併模式，並成為數據庫食譜模式不可或缺的一部分。 隨著工程團隊開始創建自己的，運行手冊成為一個熟悉的模板，因為新的數據庫集群在各地湧現。

能見度

我們喜歡我們的終端屏幕。 我們愛他們。 MySQL 領域最流行的工具仍然是直接存在於 db 主機上的終端工具，需要事先了解它們以及如何使用它們。 我說的是innotop 和MySQL shell 之類的東西。 這些很好並且仍然有用，但它們是為 DBA 創建的。 如果您不想成為諸如“現在是否存在復制延遲？”之類的問題的看門人。 您需要有更好的工具來讓所有團隊成員現在和歷史上的任何集群運行狀況都可用且易於消化。 我在這個領域有幾個例子：

編排器

我們使用只讀副本將負載從主服務器分散開，這意味著一旦延遲達到某個閾值，它就會成為客戶支持事件。 重要的是讓公司中的任何人在任何給定時間都更容易了解是否有任何集群出現延遲、該集群中的服務器是什麼以及是否有任何主機出現故障。 在這方面，Orchestrator 是一個很棒的工具，因為它使集群及其運行狀況可視化只需一個瀏覽器窗口即可。

格拉法納/石墨

數據庫層的指標需要與基礎設施其餘部分的指標位於同一位置。 對於團隊來說，能夠將這些指標並列並列是很重要的。 有一種簡單的方法可以查看任何數據庫集群的歷史指標，這一點很重要。 雖然您可能對 cacti 或 munin 或您多年來編寫的手工模板有個人偏好，但如果您用於調查問題的指標與其他基礎設施指標不在同一個位置，則它會設置障礙其他忙碌的工程師——他們將不太願意使用您的工具而不是其他地方正在使用的工具。 Graphite 在現代基礎設施團隊中被廣泛用於獲取指標，而 Grafana 是一個廣泛使用的用於指標和分析的儀表板前端。

查詢性能

我們使用 VividCortex 來跟踪我們在關鍵集群上的查詢，雖然本文並不是為付費服務做廣告，但我會說您需要能夠檢查部署和代碼更改對運行查詢和查詢性能不需要特殊訪問日誌並手動處理它們的東西。 如果 VividCortex 不可能（儘管說真的，它們太棒了！），還有其他產品和開源工具甚至可以捕獲緩慢的日誌並將其放在易於閱讀的網頁中供非 DBA 檢查並查看他們的代碼的效果。 這裡重要的一點是，如果您提供查看數據的方法，工程師將使用這些數據並儘最大努力保持工作效率。 但讓訪問可用而不是特殊的 DBA 技巧是您工作的一部分。

對抗尋呼機疲勞

許多組織沒有將數據庫層擴展作為其堆棧設計中的一項非常早期的必要條件——而且他們不應該這樣做。 在公司的早期，如果還沒有人使用 API，您不應該擔心如何限制 API 調用。 但考慮幾年後的情況是合適的，當產品獲得關注時，少數客戶訪問幾千行表的 API 調用現在是數百萬行表，以及幾個客戶已經構建了 cron 作業，每天早上 6 點在您的時區淹沒該 API。

更改任何產品的應用層以保護基礎設施都需要做大量工作，在此期間，允許虛假的數據庫活動導致尋呼機疲勞對您和運營組織的其他成員都是一個很大的危險。 熟悉諸如 pt-kill 之類的工具，這些工具可以輕鬆使用，以防止數據庫主機因計劃外捲而出現重大停機。 使該工具的使用為人所知，並將操作及其效果傳達給持股工程團隊，但嘗試從您無法直接改變的事情中吸收痛苦是不健康的，並且最終對幫助工程團隊無益' 學習如何應對成長的痛苦。

與運營團隊的其他成員相比，DBA 的工作有很多獨特之處，但這並不意味著它必須是一個沒有人可以接近的神奇神職人員。 這些步驟在使您的工作透明化方面大有幫助，但最重要的是，您的工作不是作為數據庫主機黃金花園的守門人，而是作為可以提供建議並幫助您合作的工程師成長並提供更多服務的主題專家對業務的價值比備份和查詢調優（但這些也很有趣！）。

特別感謝 Sendgrid 出色的運營團隊，他們繼續教給我很多東西，也感謝 Charity Majors 創造了這篇文章的標題。 並在此處查看有關 DBA 的更多帖子。