DBRE Summit 2023の登壇資料です https://kinto-technologies.connpass.com/event/292402/
# 参考資料
https://soudai.hatenablog.com/entry/2017/06/03/183508
DBREを役割ではなく、文化にしたリンケージの取り組みDBRE Summit 2023
View Slide
Database Reliability Engineering || DBRE What is it?
DBREは役割ではなく 哲学であり、文化 What is it?
普段のプロダクト開発の営みの中で データベースをメンテナンスする文化 What is it?
これをどうやって チームで実現したか話をします What is it?
1. 自己紹介 2. 風土と文化とDBRE 3. 作る人が最も答えに近い 4. 信頼を勝ち取る 5. まとめ あじぇんだ
自己紹介 曽根 壮大（38歳） Have Fun Tech LLC 代表社員 株式会社リンケージ CTO そ ね たけ とも ● 日本PostgreSQLユーザ会 勉強会分科会 担当 ● 3人の子供がいます（長女、次女、長男） ● 技術的にはWeb/LL言語/RDBMSが好きです ● コミュニティが好き
突然の宣伝 予防医療のリンケージ ● リモートワークの不安を数値にするストレスチェック● 女性の健康課題をサポートする● リモートワーク、ちょっとした心配を相談できる安心をご提供
Database Reliability Engineering 風土と文化とDBRE
DBREは役割ではなく データベースを中心とした運用の哲学 風土と文化とDBRE
データベースの死は サービスの死 風土と文化とDBRE
だからこそデータベースの問題を 解決できる人は英雄 風土と文化とDBRE
自分自身が、チームが、 英雄になる日常 風土と文化とDBRE
安定したサービス運営 平和な日々 風土と文化とDBRE
そういう文化を作っていく 風土と文化とDBRE
そういう文化を作っていく ↓ Database Reliability Engineering 風土と文化とDBRE
しかし、文化は 突然は生まれない 風土と文化とDBRE
そこで風土が必要 風土と文化とDBRE
そこで風土が必要 ↓ 何をつくる？ 風土と文化とDBRE
障壁を無くす インセンティブを作る 風土と文化とDBRE
● 風土 = そこで働く人の気質や文化に影響を及ぼす、 その企業特有の環境こと ● データベースは複数の事業やチームに影響を与えることが多いため、横断的なコミュニケーションを可能にする ○ 例えば専門職を用意する（役割としてのDBRE) ● データベースの管理を特権とするのではなく、開発者が直接に “安全に” 利用できる状態にする ● 問題を治療することよりも予防することを評価する DBREを促すために必要な風土の例
個人の適性や熱意は必要だけど それだけでは文化にならない 風土と文化とDBRE
個人の適性や熱意は必要だけど それだけでは文化にならない 風土と文化とDBRE特定の人物に依存すると DBAと変わらないまたその人物が燃え尽きたときに文化が途絶え、ロストテクノロジーと神話が生まれる
DBREを文化にしていくためには まずは風土を整えることが大事 風土と文化とDBRE
なぜ、開発者がDBREを 実践する文化が必要か 作る人が最も答えに近い
データベースは実装された データモデルに強く影響を受ける 作る人が最も答えに近い
データモデリングは ビジネスのドメインの影響を強く受ける 作る人が最も答えに近い
データは積み木 時間と共に積み上げていく 作る人が最も答えに近い
データは積み木しっかりと練られた初期設計
データは積み木しっかりと練られた初期設計ちゃんと検討された仕様追加 1ちゃんと検討された仕様追加 2正しく仕様追加を積み上げていける
データは積み木しっかりと練られた初期設計ちゃんと検討された仕様追加 1ちゃんと検討された仕様追加 2土台がしっかりしているので、運用も安定している突然のなにか突然のなにかグラ...グラ...グラ...グラ...
データは積み木初期設計
データは積み木初期設計マジカルな設計をすると仕様変更も運用も難しい
データは積み木初期設計仕様追加仕様追加もできないし、運用もできない
では誰が積み木を積むか 作る人が最も答えに近い
では誰が積み木を積むか ↓ ソフトウェア開発者 作る人が最も答えに近い
自分たちがデータベースを守るために 開発者自身がDBREを体現するのが最も早い 作る人が最も答えに近い
● レビューをするのではなく、レビューのやり方を教える ○ 実行計画の見方、RDBMSの仕組みを教え、実践させる ● テーブル設計に必要な知識を適宜提供する ○ 輪読会やドキュメントを用意し、一緒に学ぶ ○ 必要なツールの導入を検討し、一緒に活用する ● 自分たちに必要な仕組みを自分たちで設定し、運用する ○ デプロイ、マイグレーション、開発環境を自分たちで作る 開発者がデータベースを運用する
開発者に主体的に データベースに関わってもらう 作る人が最も答えに近い
Database Reliability Engineering || データベースにオーナーシップを持つ 作る人が最も答えに近い
Database Reliability Engineeringを 実践していく 信頼を勝ち取る
ドキュメントを作る Design Docを残す 信頼を勝ち取るリンケージではArchitecture Decision Recordsを採用し、Github リポジトリに設計思想の履歴を残している
設計思想、運用の哲学を伝えれば 再現性が上がる 信頼を勝ち取る
設計思想、運用の哲学を伝えれば 再現性が上がる 信頼を勝ち取る再現できれば、特定の人に依存しない
一部を実際にお見せします ※イベント参加者だけ 信頼を勝ち取る
自分たちが使うツールを自分で選ぶ 選んだ責任を全うする 信頼を勝ち取る
LaravelのEloquentではなく、 Doctrine 2を使う 信頼を勝ち取るリンケージの例
LaravelのEloquentではなく、 Doctrine 2を使う 信頼を勝ち取るLaravelのバージョンアップの追従は誰がやるの？リンケージの例
信頼を勝ち取る
Database Reliability Engineeringを 全員が実践していく 信頼を勝ち取る
Database Reliability Engineeringを 全員が実践していく 信頼を勝ち取るそうは言っても、行動してくれないんだよな …
DBREを実践するためには チームの信頼を勝ち取る必要がある 信頼を勝ち取る
エンジニアの信頼を勝ち取ることはなぜ必要か？そもそもなぜ、エンジニアの信用を高め、信頼を勝ち取る必要があるのだろうか。それは一人で出来ることは限界があり、● やりたいことを実現する● 問題を解決する● これらをするためにはとても必要な事だからだ。例えば自分が1を100にするのが得意な場合、0から1を作るのが得意な人が必ず必要だ。逆も然りでプロダクトを大きく、サービスが成長すればするほど一人で出来ることの限界とぶつかる。我々エンジニアは世の中の問題を解決するために何かを生み出し、成長させて問題を解決してその報酬として対価を得ている。つまり大きな問題を解決するためには一人では限界がある。だからこそみんなの力を借りるためにも信頼されたエンジニアで有る必要があるのだ。https://soudai.hatenablog.com/entry/2017/06/03/183508
信頼を勝ち取るために 良質なアウトプットが必要 信頼を勝ち取る
結果、データベースの信頼性が上がり サービスの全体の信頼性が上がる 信頼を勝ち取る
Database Reliability Engineering は哲学であり、運用のスタイル まとめ
職人芸ではなく 仕組みで問題を解決していく まとめ
問題を対処するのではなく 予防することで解決する まとめ
誰かがやってくれる ではなく、自分たちがやる まとめ
その先に、DBREがある まとめ
データベースの寿命は アプリケーションよりも長い まとめ
今の自分の行動が 未来の誰かを救うことになる まとめ
まとめ
ご清聴ありがとうございました まとめ
soudai
oracle4engineer
sugawani
lwug
keiko713
hokaccha
lmi
minorun365
h1kita
chloe463
peisuke
hakubishin3
smt7174
revolveconf
lara
jlugia
lynnandtonic
tmm1
chrislema
addyosmani
destraynor
edds
yeseniaperezcruz
brettharned
carmenintech