DBA、神権はもうありません

公開: 2017-03-07

注：このエンジニアリング投稿は、DBAのSilvia Botrosによって作成され、2016年12月にSysadventブログに最初に掲載されました。

企業は何年もの間、データベース管理者を必要としてきました。データは、企業の最も重要な資産の1つです。つまり、多くの企業は、急速に拡張できるようになると、資産が適切に管理され、製品のニーズに対応し、災害時に復元できるようにするための誰かが必要になります。

従来の意味では、DBAの仕事は、データをホストするサーバーにアクセスできる唯一の人物、新しい機能用の新しいデータベースクラスターを作成する頼りになる人物、新しいスキーマを設計する人物、そして唯一の人物であることを意味します。実稼働環境でデータベース関連のものが壊れたときに連絡する人。

DBAは伝統的にそのような独特の役割を持っているため、その時間は貴重であるため、日常のタスクが圧倒されると全体像を考えることが難しくなります。 DBAランドでのあらゆる種類の運用タスクには、bashなどの脆弱なツールを使用するのが一般的です。クリーンなOSインストールからの新しいDBセットアップが必要ですか？バックアップを作成、検証、または復元しますか？パーティションまたは古いデータをローテーションしますか？最も一般的に使用されるツールがbashスクリプトである場合、すべてが釘のように見えます。多くの読者がbashの強力さを教えてくれるツイートを準備していると思いますが、私の推論を評価するまでコメントを残してください。

これはすべて、DBAとしての職務記述書のように聞こえますか？職務記述書には、サーバーのアップグレード、バックアップの作成とテスト、および監視について詳しく説明されていますか？最も一般的なDBAの求人情報では、「複数の」データベースサーバーを構成およびセットアップする必要があり（DBAがそれらを手作りすることが期待されるため）、（手作りの）スクリプトを使用してデータベース管理タスクを自動化する必要があります。

これは、成長しているペースの速い組織の1つのチームであることが多いため、本当にスケーラブルなアプローチですか？

私はあなたの仕事がバックアップの実行と管理、データベースの作成と管理、またはクエリの最適化ではないと主張するためにここにいます。これらすべてのことを仕事の範囲内で行いますが、主な目標は、ビジネスのデータにアクセス可能でスケーラブルにすることです。これは、企業が現在の製品を実行するためだけでなく、新しい機能を構築して顧客に価値を提供するためでもあります。

どうして

あなたは尋ねたいかもしれません、なぜ私はこれのいずれかをするのですか？従来、DBAロールの実行を継続することには議論があります。それは、ジョブのセキュリティですよね？最近の多くの技術組織は、次の1つ以上を実行しています。

彼らは多くの小さなチームで構成されています
これらは、1つまたはいくつかのより大きなサービスの代わりに多くのマイクロサービスを作成することによって機能を提供します
アジャイル手法を採用して、機能の提供をスピードアップします
これらは、1つのリーダーシップの下で運用とエンジニアリングを組み合わせます
設計プロセスのできるだけ早い段階で、運用エンジニアと開発者を組み込みます。
運用内のDBAサイロは、運用チームが自身のスタックで本番環境の問題をデバッグするのを支援する権限が少なく、支援なしでは問題に対応して修正できない場合があり、エンジニアリングチームがいない場合はエンジニアリングチームとのより緊密で早期のコラボレーションを要求することについて率直に言って信頼性が低いことを意味しますTechOps内で彼らが説教していることを実践していません。

では、そのサイロを破り、他の人々がデバッグしやすくし、データベースレイヤーの拡張を支援し、エンジニアが拡張可能なサービスを設計できるようにするために何ができるでしょうか。ほとんどの新進気鋭の店には、多くても1つの社内DBAがあります。 1つのDBAがすべての設計会議に「出席」し、すべてのスキーマ変更を承認し、広大で増え続けるデータベースフットプリントを要求することができますか？

DBAはもはやゲートキーパーやマジシャンになることはできません。 DBAは、組織内のエンジニアの知識と専門知識のソースになることができ、またそうあるべきです。彼女は、配信チームが機能を配信するだけでなく、データベースを恐れないように拡張および権限を与える製品を配信するのを支援する必要があります。しかし、DBAは、データレイヤーを管理するという日常業務を行いながら、どのようにそれを達成できるでしょうか。 DBAであるあなたが卓越性のために自分自身を設定することができるいくつかの方法があります。

構成管理

これは非常に重要なものです。 DBAは、データベースのセットアップにbashなどの古いツールを好む傾向があります。私は以前にこれをほのめかしました、そして私はbash自体を使うことに何の反対もありません。実はよく使っています。ただし、クラスターのセットアップには適切なツールではありません。特に、残りのオペレーションが残りのアーキテクチャを管理するためにBashを使用していない場合。運用エンジニアもBashを知っているのは事実ですが、ChefやPuppetなどのツールを使用してインフラストラクチャの残りの部分を管理していて、データベースが主にDBAによって作成された手作りのスクリプトによって管理されている場合、提供するのに障害があります。緊急の変更が必要な場合に役立ちます。

さらに、エンジニアリングチームがセルフサービスを行い、新機能「foo」に必要な新しいクラスターの作成を所有するのを支援することが難しくなります。あなたは作業を完了するための「ブロッカー」になります。会社の構成管理に精通することも、双方向のメリットです。インフラストラクチャの管理方法に精通するにつれて、チームの標準を理解し、スタックに精通し、最終的に製品の規模に影響を与える変更に協力できるようになります。

エンジニアリング組織の製品とインフラストラクチャ全体に精通しているDBAは非常に貴重です。

Runbooks

これは技術的には作成する必要のあるドキュメントのサブセットですが、私の経験では、個別に指摘する必要があると感じているため、はるかに有用であることが証明されています。私がRunbookと言うとき、私はDBAではない聴衆のために書かれた文書を具体的に言っています。デバッグと解決が簡単なDBAとして発生する可能性のある本番DBの問題はたくさんあります。私たちはその筋肉の記憶を過小評価する傾向があり、「ページを送ってください」というパターンに陥り、「物事を処理します」。

あなたの運用チームがあなたが唯一のDBAである私のようなものである場合、それはおそらく、DB関連のイベントページでチームの他の誰かが最初の防衛線であることを意味します。初期デバッグ、データ収集を行う方法に関するいくつかの簡単なドキュメントは、残りの運用チームがデータベースレイヤーに慣れ、データベースレイヤーの監視とデバッグの方法に慣れるために大いに役立ちます。そのイベントがDBAのページングにつながる場合でも、ゆっくりと、しかし確実に、Runbookはすべての人が習得した知識を追加する場所になります。

さらに、関連するRunbookセクションへのリンク（アンカーを使用してください！）を、ページャーに移動するページの説明に追加します。これは、午前3時にデータベースホストによってページングされている人が開始する場所を見つけるのに非常に役立ちます。これらは小さいように見えるかもしれませんが、私の経験では、必要に応じてデータベース層で作業する運用チームの精神的な障壁を打ち破るのに大いに役立ちました。

個人的な好みとして、私はこれらをシェフのクックブックリポジトリ内のマークダウンドキュメントとして記述しています。これは、プルリクエスト、レビュー、マージパターンにシームレスに分類され、データベースのクックブックパターンの不可欠な部分になります。エンジニアリングチームが独自の作成を開始すると、新しいデータベースクラスタがいたるところに出現するため、Runbookはおなじみのテンプレートになります。

可視性

私たちはターミナルスクリーンが好きです。私たちは彼らが大好きです。 MySQLランドで最も人気のあるツールは、dbホスト上に直接存在し、それらとその使用方法に関する事前の知識が必要なターミナルツールです。私はinnotopやMySQLシェルのようなものについて話している。これらは問題なく、それでも役立ちますが、DBA用に作成されています。「現在、レプリケーションの遅れはありますか？」などの質問のゲートキーパーになりたくない場合。すべてのチームメンバーがクラスターの状態を現在および過去に利用可能で簡単に消化できるようにするための、より優れたツールが必要です。この分野でいくつかの例があります：

オーケストレーター

リードレプリカを使用して、その負荷をプライマリから分散します。つまり、ラグが特定のしきい値に達すると、カスタマーサポートイベントになります。社内の誰もがいつでも、クラスターで遅延が発生しているかどうか、そのクラスター内のサーバーは何か、ホストのいずれかがダウンしているかどうかを簡単に把握できるようにすることが重要です。 Orchestratorは、クラスターとその状態をブラウザーウィンドウから離れて視覚化できるため、この点で優れたツールです。

Grafana / Graphite

DBレイヤーのメトリックは、残りのインフラストラクチャのメトリックと同じ場所に存在する必要があります。チームがこれらのメトリックを並べて並べることができることが重要です。また、DBクラスターの履歴メトリックを簡単に確認する方法を用意することが重要です。サボテンやムニン、または長年にわたって作成した職人のテンプレートを個人的に好みますが、問題の調査に使用する指標が他のインフラストラクチャ指標と同じ場所にない場合は、他の忙しいエンジニア–そして彼らは他の場所で使用されているものよりもあなたのツールを使用する傾向が少なくなります。 Graphiteは、最新のインフラストラクチャチームでメトリックを取り込むために広く使用されており、Grafanaは、メトリックと分析のために広く使用されているダッシュボードフロントエンドです。

クエリのパフォーマンス

VividCortexを使用して重要なクラスターのクエリを追跡します。この記事は有料サービスの宣伝を目的としたものではありませんが、実行中のクエリに対するデプロイとコード変更の影響を検査する機能を作成する必要があります。ログへの特別なアクセスを必要とせず、手動でログを処理する必要のないクエリパフォーマンス。 VividCortexが可能でない場合（ただし、真剣に、それらは素晴らしいです！）、遅いログだけでもキャプチャして、非DBAが検査できるように読みやすいWebページに配置できる他の製品やオープンソースツールがあります。そして彼らのコードの効果を見てください。ここで重要なのは、データを表示する手段を提供すると、エンジニアはそのデータを使用して、効率を維持するために最善を尽くすことです。しかし、そのアクセスを利用可能にすることはあなたの仕事の一部であり、特別なDBAトリックではありません。

ポケットベルの疲労と戦う

多くの組織は、スタック設計の非常に初期の必須事項としてデータベースレイヤーのスケーリングを含めていません。また、そうすべきではありません。会社の初期の頃は、まだ誰もAPIを使用していない場合に、API呼び出しをどのように調整するかについて心配する必要はありません。しかし、数年後、製品が勢いを増し、少数の顧客が数千行のテーブルにヒットしていたAPI呼び出しが、今では数百万行のテーブルになり、数人の顧客がいることを考慮するのが適切です。あなたのタイムゾーンで毎朝午前6時にそのAPIをあふれさせるcronジョブを構築しました。

インフラストラクチャを保護するために製品のアプリケーション層を変更するには多くの作業が必要です。その間、偽のデータベースアクティビティによってポケットベルの疲労を引き起こすことは、あなたと他の運用組織の両方にとって大きな危険です。計画外のボリュームによるデータベースホストの大幅なダウンタイムを防ぐために、簡単に使用できるpt-killなどのツールに慣れてください。そのツールを利用して、アクションとその効果をステーク保持エンジニアリングチームに伝えますが、直接変更できないものから痛みを吸収しようとするのは不健康であり、最終的にはエンジニアリングチームを支援するのに有益ではありません。 '成長する痛みに対処する方法を学びます。

DBAの仕事は、他の運用チームと比較して、彼女の役割に固有の方法がたくさんありますが、それは、誰も近づくことができない魔法の神権である必要があるという意味ではありません。これらの手順は、作業を透明にするのに大いに役立ちますが、最も重要なのは、データベースホストの黄金の庭への門番としてではなく、アドバイスを提供し、一緒に作業するエンジニアの成長を支援し、より多くを提供できる対象分野の専門家として作業に取り組むことです。バックアップやクエリの調整よりもビジネスにとっての価値があります（ただし、これらも楽しいです！）。

私に多くのことを教え続けてくれたSendgridの素晴らしいオペレーションチームと、この投稿のタイトルを作ってくれたチャリティメイジャーズに特に感謝します。そして、ここでDBAに関するその他の投稿をチェックしてください。