DBREJPはじめてみました
この記事は JPOUG Advent Calendar 2020の12/11の記事となります。
昨日の記事はNakaieさんの「Oracle Databaseへの言語別アクセスドライバのまとめ - Qiita」でしたね。言語別のドライバがすごくわかりやすくまとまっていて、改めて学びになりました。
一日遅刻しちゃいました…遅くなりました!!
前に書いた記事から随分間が空いて、気がついたら年末になっていました…2020年、色々なことがありすぎてあっという間…でしたが!
さて気を取り直して、今日は最近はじめた活動について宣伝をさせていただこうと思いますっ( ˙꒳˙ᐢ )
はい!DBREJPはじめてみました(꜆꜄•ω•)꜆꜄꜆
まず、DBREってなんぞやというお話ですが…
SREという言葉をご存知でしょうか。
Site Reliability Engineering. サイト、システムの信頼性を向上していくエンジニアリングのことですね。
でもサイトやシステムの信頼性は、NWやOSレイヤ、サービスを提供ソフトウェアだけでは成り立ちません。
そうですよね。大抵そこには、RDBMSだろうがKey-ValueだろうがNoSQLだろうが…データを保存し、それを利用するDataBaseが存在します。
そんなDBの信頼性を上げるエンジニアリングが、 Database Reliability Engineers.
それが、DBREです。
でもここで紹介するDBREは、ちょっと違うかもしれません。
そもそも何故始めたいかと思ったかというと、以下のようなことを最近感じているからです。
- DBAの人口はエンジニア全体から見ても多くないので、どこでも人手不足
- 人手不足なのに、トラブルが発生するとシステム影響が多いシングルポイントであることが多く、メンテナンスやチューニング等でDBAの日々の仕事が多い
- こうしてDBAが今携わっているDB以外のやりたいことが何も出来ない!(別のDB製品触りたいとかも、これに含まれます)
- そんな悲しげなDBAをみて、よりDBA目指したい人が増えない!そして最初に戻る負のスパイラル!
※個人の見解です。
私自身、k8sとかコンテナとかにも興味は大いにありますし、RustやKotlinなどの開発言語にも非常に興味があります。あ、もちろんAnsible大好きです!
が、日々の業務の99.9%はDBのタスクです。
毎日まいにち、sqlplusを連打してます。ていていてい(꜆꜄•ω•)꜆꜄꜆
そりゃDBAだからそうでしょうと言われるとそうなのかもですが、ずっととあるDB製品ばかり触っていても、つまらない。DB以外のことだって学びたい。携わってみたい。
そのためにDBAがしないといけないことは、大きく2つあると考えました。
(細かいことを言い始めるとたくさんあると思うので、ここでは割愛)
- とにかくDBを安定稼働させる。トラブルやチューニング等の想定外運用タスクをなるべく防ぐ
- DBAを孤独にしない。DBを使う人達にもっとDBを理解いただき、本番サービス導入前に未然にリスクを防ぐように、一緒に考える
この2つの課題のために、DBREJPの活動をはじめたいと思いました。
とは言ったものの、いきなり「さぁ、DBをDBA以外の人に理解してもらうにはどうしたらどうしたらいいか、考えましょう!!」なんて言われても、DBAそれぞれの抱える課題は人それぞれ。
同じ製品であれどどの業種のシステムなのか、ミッションクリティカル度の違いや、セキュリティ要件、利用方法によって全く異なります。
その他にも、プロダクトそれぞれの特異な作業、開発から運用までの業務フローの違いなど…挙げ始めるときりがありません。
だから最初にすることは1つ目の「DBAが抱えている課題は何か?」を洗い出すことと考えました。
非常に広範囲な課題です。範囲も粒度もみんなバラバラです。
でもだからこそ、議論することは楽しいんじゃないかなと考えました。
例えば先日挙げられた課題は「みんなどうやってスロークエリを防止してるの?監視してても、見つけた時点でもう既に影響が出てしまっているよね?」という話がありました。
その課題に対し、色んな人が意見を出してくれます。
それはシステムもプロダクトもまたいで、「DBAと言う輪の中で」様々な角度や経験からの意見があり、それは見ているだけでも非常に興味をワクワクを与えてくれるものでした。(詳しくはDBREJPのSlackまで)
あぁみんな、こんなことに悩んだり課題に感じてるんだね。
プロダクトや技術で対応出来ることかな?技術でどうしようもできないことかな?
DBAが頑張ったら良いのかな?DBA以外の人にも協力してもらったら良いのかな?
じゃぁどうしたら良いか、一緒にアプローチを考えようよ!
そうして、みんなで課題を挙げて考え、課題が解決されてシステムが安定化して、DBAもっといろんな事ができる。
そうして溜まったナレッジは、誰もが見れるようにしたい。そうすれば、DBAでなくてもDBを安定稼働することになるのではないか。
まず直近は、そんな事ができるきっかけの場になれば、と考えています。
課題を解決していくことは、よりよいシステムを、より高速に、より安定したシステムを実現していく。
そしてそれはいつか、「システムの信頼性をあげていく」ことに繋がる。
そんな場となるよう、これから頑張っていきたいなと思っています。
この活動に、プロダクトの制限は一切ありません。
Oracleでも、Oracle以外でもなんでもいいのです。
様々なプロダクトに詳しい方が参加してくださっていますし、DBAじゃない方もいます。
プロダクト固有の話、例えば「MySQLのここが知りたい!」は、MySQLのコミュニティで会話したほうが良いです。
でも、「PostgreSQL使ってて暗号化に悩んでるんだけど、他のプロダクトだとみんなどうしてるの…?」を、話せる範囲で(守秘義務の範囲で)話をする。
そんな、DBAのみんなが抱えてる悩みや課題を、気軽に集まって話をする場になることが、直近の目標です。
お、そんな場所があるの?と思っていただいた方。
是非気軽に、Slackに参加してみてください♪
ログインはこちらまで♪
コチラ
無料アカウントなので、URLの有効期限が切れていれば、tomoのTwitterに気軽にお声がけくださいね₍ ᐢ. ̫ .ᐢ ₎
@tomomo1015 ←
それでは!明日は(というか今日なんですけどね…ぐすんぐすん)木村さんの「OCIといえばOracle Call Interface | キムラデービーブログ」ですね!
なになに気になる!という方は、ぜひ( ¯꒳¯ )b✧