DBAからDBREになろうと思ったきっかけ

今日も書くよ、エッセイみたいなもの

DBREに対する自己認識

まぁそれは本を読んでほしい。今日はここでこの本の内容をあれこれ言いたいわけではない。

データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用

システムの安全性や稼働率を定量的に測って目標値を決めて、その目標に向かって改善を積み重ねていく。
そうゆう手法を教えてくれるのがこの本で、自分の肩書がDBAなのかDBREなのかは、実はどうでもいいことなんだよね、とは思っています。
昔は、DBREとはDBAのその先の進化、みたいなイメージを持っていました。それは確かこの本の冒頭にも書いてあります。
けれど今の私が思うDBREは「疲れ切ったDBAが取った、最後の手段」と思っています。

何故DBREにシフトしようとしたのか

きっかけは、先日書いたこの本でした。

学びを結果に変えるアウトプット大全

しかもこの本の内容ではなく、この本に挟まれていたこのメッセージから。
これすごく大事な内容なのだけれど、電子版にもあるのだろうか？

この本、実は精神科の先生（つまりお医者さん）が書かれた本なのですが。
先生がアウトプットの大切さを何故重要だと思ったのか？の経緯がここに書かれていました。

治療しても治療しても、また同じような症状の患者さんがやってくる。きりがない。

私が転職してからずっと、ひたすら忙しいのには訳がありました。
前提として、うちの会社は何故か「リリース前のSQLチューニングもSREのDBA」という謎ルールがあります。
ちなみにそのSQLの要件がなにかの説明はない…という闇はここで言うのは割愛。つまり開発者がSQLチューニングすることは非常に稀なので、DBAはSREとアプリ開発に片足入った状態。当然、日々のタスク量は多い方だと思います。（あと契約とか予実管理もしているので、実質死にそうです）
そんな状態なのに「急にこの処理が遅くなりました！DBAなんとかしてください！！」という問い合わせが、平均月一回以上あります。
多いときは、週に3回。大体が重要な処理で「今すぐ何とかしてもらわないと、XXXXX業務が回らないんです！！」と分単位でリカバリを求められる障害対応をしています。
同時に、高負荷なSQLをどうにかチューニングしてというプロジェクトも立ち上がり、毎週長文SQLをにらめつける日々。
原因は一目瞭然で、その理由を簡単にですがSlackで書いては皆さんに伝える、大分雑なアウトプットはしていました。けれどその内容は局所的で、正しく理解して頂ける内容だったかというと、とても足りる内容にはなっていませんでした。

とにかく、治らない。
チューニングしてもチューニングしても、また同じようなJOINがいっぱいのSQLが作成され、似たような実行計画を惑わすINDEXが作られ、DBA何とかして！がくる。
きりがない。もう辛い。

半年以上これを続け、モチベーションもですが絶望感も感じていました。
GW初日の祝日に呼び出されたときは、一緒に出かけようと言っていた娘に「ごめん行けない」と伝えたときの、娘の涙目を見て「もう辞めよう」と本気で思いました。
でも私が辞めても、改善はされない。ならせめて、何かしら食らいついて結果を出してから、辞めたい。
そんな中でこの本のレターを見て、アウトプットの重要性に気づきました。

「治療」より「予防」をしないと、この先ずっとこの状況が続くということ。

JOIN一杯の数百行SQLがなぜ作られるのか
INDEXを追加することで、なぜ実行計画の変動するのか
なんてことはDBAだったりSQLチューニングしている人であれば分かりますし、開発者の人でも分かっている人は分かっています。
けれどそれが開発に関わる人すべてがそうかというと、そうでもない。
であれば、「何故それがだめなのか」を正しく伝えることが必要なんだと思うんです。
それもDBREがすることの一つではないかなと、そう思っています。

同時に、コストベースのオプティマイザを利用しているRDBMSであれば、コストの指標を算出も改めてすることにしました。
なんとなく「コスト下げて！！」では、説得力がありません。
CPUの数がこれ、それに対して毎秒アクセス数はこれ、例えばOracleDBであればそれに対しDB TimeはXXXXでないと、CPUを食いつぶすよ。といった定量的な説得力を提示することです。
そうすれば開発者の方々も、作成したSQLのOK/NGがわかりやすい。同時に私たちも、その閾値を超えたものができた場合、どうしたらいいのかを相談する場を設けられ、アンチパターンのアウトプットを出すことが出来ます。
よし、こうすればWin-Winだな。そう思ったのが先日のことでした。

次にやらないといけないこと

さてDBREもどきに舵を切ることを選択した訳ですが、このとき同時にしないといけないことは「効果を定量的に出す」ということ。
日々の問い合わせ、実行計画変動の問い合わせ等、これまで行ってきた業務がどのように変化をしたのか、この効果を出さないといけません。
数はここでは言えないと思うのですが、どのくらい減った、という辺りはアウトプットできればいいなと思っています。

猫の手でも借りたい。でも猫がいたら、多分仕事しなくなると思います。
だって猫はかわいいもの。