DBRE 横断組織を組成する v0.1(カモ)

DBRE 本が発売されたことで、一時的に DBRE 組織の組成について相談をしたい、というお話をいただくことがあったので僕の視点、つまり 横断組織としての DBRE　だったらどうしたい、ということについて書いてみます。

そもそも DBRE って何？

個人的にもその答えってまだ出ていないのが現状なんですよね、DBA と何が違うの？って言われるとうーん、ってなるし、誰もが納得できるような答えなんて持ってません。まぁそれでもいいのかな、という割り切りはあります。

今それぞれ持っている課題を横断的、かつ下記観点で解決できるか、という時には僕の知見は少しは役に立つかもしれませんし、企業や立場によって様々なフェーズがあってそれにマッチすることは現実的ではないため、役に立たないこともあると思います。

なのでこの質問をいただいた時には僕が DBRE　をやるならこの視点を忘れないでいたい、という思いをお伝えするようにしています。

基本的な考え方は今も昔もあまり変わっていないので以前発表した資料から抜粋してみます。

1. Database が起因となって事業の成長を妨げる要因にならない
   • 事業の成長戦略を Database が要因になって諦めさせないためにはどのように振る舞うべきか
2. 事業に対するリスクを最小化する
   • 内部/外部要因によるリスクを減らすためには何が必要なのか
   • 人材流動性を可能にさせるためにはどうしたらいいか

DBRE 横断組織の責任

個人的に　DBRE が横断組織として活動する上で、最も大切だと思うことは 事業の自立性を尊重 しつつ 事業の守るべきガバナンスを正しく守れる 状態を作ることだと考えています。
「この範囲の中であれば好きに使ってもらっていいよ」と自信を持って言えることと「何かあったらすぐに駆けつけるよ」というアジリティを兼ね備える必要があるということです。

DBRE 横断組織は

• 事業が正しく活動していく上で必要なガバナンスを定義し、それを自然と守ってもらう仕組みを考える
• 特定のヒトでなければできないオペレーションを作らない
• 事業が使用している Database の特性を知ることを諦めない

ことが大切になります。

事業が正しく活動していく上で必要なガバナンスを定義し、それを自然と守ってもらう仕組みを考える

細かくガバナンスを定義し、それを守ってもらい続けることは DBRE 横断組織、サービスを提供する事業双方にとって大変ストレスです。

アプローチとしてはいくつかあるのですが下記を組み合わせて行くことでお互いのストレスを軽減できることはあると思います。

• 予防的ガードレール
  • 絶対にやって欲しくないことのみできないようにする仕組み
    • port 3306 が全開放されている
    • DB の Root　password を デフォルトのまま利用している, etc.
• 発見的ガードレール
  • 好ましくない設定がされた場合に気づける仕組み
    • SlowQuery が設定されていない
    • SlowQuery　の閾値が 0 または 10　以上, etc.
• 訂正的ガードレール
  • 好ましくない設定がされた場合にそれを自動的に直す仕組み

予防的ガードレールや訂正的ガードレールは事業の思惑などもある可能性もあるので最低限にしつつ、最初は発見的ガードレールを重点的に考えるといいと思います。最初は確かに様々なアラートがなって煩わしさを生むかもしれませんが、なぜそれをやっているのか、の説明とその改善方法を提示し、理解を得た上で進めると気づいた時には自然とそれが出来ている状態を作れるかもしれません。

特定のヒトでなければできないオペレーションを作らない

DBA はエンジニア全体から見たら希少だと思いますし、実際専属の DBA　のないサービスも多いと思います。そう言った場合に Database　オペレーションを特定の人にのみやってもらえる権限を与え実施するようなことも多いでしょう。ただ、その人に対する責任は増え、またその人が辞めてしまった場合に組織全体のアジリティが下がってしまうことになりかねせん。

少しづつこう言った作業を自動化していき、そのサービスに責任を持つエンジニアが誰でも理解できる状態にし、更にそれを会社全体で使えるようにできたらそのオペレーションに関しては誰でもできる、例えば隣の部署から一時的に手伝ってもらって実行することもできる状態を作れます。

そうして人材流動性を高めていく活動も大切だと考えます。

事業が使用している Database の特性を知ることを諦めない

僕自身が横断組織を立ち上げた際にその当時のサービス側のマネージャーに言われた言葉でとても心に残っている言葉があります。

• 横断組織は事業運営によって成り立っている、なので事業に寄与できなければただの税金だからそれを意識して活動してほしい

まさにそうだなと刺さりました。DBRE 横断組織は事業特性を知ることを諦めるべきではありません。ただ来た依頼を黙々とこなすだけであればわざわざ横断組織でワンクッション置かなくとも、事業の中でやってもらった方がよっぽど早いと思います。

だからこそ

• なぜそのオペレーションが必要なのか
• この機能によってユーザーにどんな価値がもたらされるのか
• 事業の成長戦略としていつまでに必要なのか

をしっかりヒアリングし、一緒に検証し、そして個人的に大切にしたいこととしては最終的に
その DB オペレーション自体が方向性として間違っていない、と事業が安心できる状態にして返してあげる
ことです。

そしてオペレーション当日には何かあったらいつでも呼んでね、一緒に最速で解決できる方法を考えよう、という姿勢を示すようにしています。

僕がこれまで経験した中で一番大きかったのは MySQL　における文字コード変更だと思います。

おわりに

自分が改めて DBRE 組織を作るならこんなふうに作りたい、ということの触りを記載してみました。最近は DBRE 活動がてきていないのでここには実際にやり切れていないことも記載しており、大きなことを言える立場でもないのですが少しでも誰かの役に立てたなら嬉しいです。