DBA/DBREしくじり先生 
 ～やっちゃったな実録集～ 
 db tech showcase 2025 
 LT資料
 ソフトバンク株式会社 
 法人ﾌﾟﾛﾀﾞｸﾄ本部 ﾌﾟﾛﾀﾞｸﾄｼｽﾃﾑ統括部 
 法人ｼｽﾃﾑｲﾉﾍﾞｰｼｮﾝ部 
 
 原 智子（tomo） 
 

自己紹介
 名前：原 智子（tomo @tomomo1015) 
 
 職歴
 ・新卒でSIerにて十数年、PM＆DBAに従事 
 ・事業会社にてSRE&DBREを3年従事 
 ・2024年2月より ソフトバンク株式会社にて事業&システム企画(CoE) 
 ・DB界隈の一般人 
 
 好き
 ・娘とカフェ巡り（最近 🚙買いました） 
 ・技術はデータベースが好き 
 この赤ずきんアイコンが 
 目印！
 

このLTでお話すること 
 過去十数年、DBのエンジニアとして 
 成功事例を生み出してきました 
 

このLTでお話すること 
 成功は氷山の一角 
 …ということは 
 
 その成功の●倍も 
 失敗してます 
 

このLTでお話すること 
 今日はこれまで話をしてこなった 
 数々の恥ずかしい失敗事例 を
 ご紹介します！ 
 

事例①
 
 確認は
 ていねいに！ 
 

事例①
 - 状況
 - SIer（DBAになる前） 
 - 背景
 - 某DBベンダーさんがお客さまに直接、とある製品を紹介 
 - 事前にDBベンダーさん側にてPoCを行い、各要件を満たしている旨を お客様同席の元、伝えられた 
 - その内容を受けて自社ではPoCはせず、そのまま当該製品を導入 
 - 何がおきたか 
 - 性能が全然でない 
 

事例①
 - 何がおきたか 
 - 性能が全然でない 
 - 何をしくじった？ 
 - DBベンダさんの性能試験では「無風状態」時に一瞬出た性能だった 
 - 無風状態：他のクエリが何も実行されていない状態での、クエリ性能 
 - よくよく聞くと、データ量やセッション数等々、色々考慮不足 
 - 対するこちらのシステム、平常時トランザクションが3桁/sec 
 

事例①
 - 教訓
 

事例①
 - 教訓
 - 自分の思う「できる」と相手の思う「できる」は、異なる 
 - 例：「オートスケールできる」と言われて、貴方は何だと思いますか？ 
 - Read Replica追加 
 - シャーディング
 - ストレージ拡張＋再パーティション 
 - ノード追加
 - 相手のせいにしない、絶対 
 - 今回の例においても、DBベンダさんの意見を受け入れた時点で自社に落ち 度がある
 - 誰かのせいにするのは簡単、自分がほんの少しでもできることがあったので あれば、自分にも責がある 
 

事例①
 - その後どうなったの？ 
 - どうにか性能が出せないか、試行錯誤を続けた 
 - 結果的に性能は出なかったが、おかげで当該製品について理解を深める ことができた 
 - 数年後、開発元のエンジニアさんとのディスカッションを経て優遇いただけるよう になったのは、今となってはいい思い出 
 1年間ずっと 
 性能試験やってました… 
 

事例②
 
 確認は
 怠らない！ 
 

事例②
 - 状況
 - SIer/DBA（DBチームリーダー） 
 - 背景
 - HWリプレイスに伴うDBバージョンアップを実施 
 - 連携製品インストール作業前、軽微なバグFIX版がRL 
 - 良かれと思ってバグFIX版をインストール 
 - 何がおきたか 
 - 製品間でサポートされておらず、メーカーさんより「サポート出来ませ ん」と言われる 
 

事例②
 - 何がおきたか 
 - 製品間でバージョンの互換性が無いと言われ、メーカーさんより　　「サ ポート出来ません」と言われる 
 - 気付いたのが、試験終了後 
 - 何をしくじった？ 
 - メーカーさんに「このバグFIX版、サポートされますか？」と一言聞くだけの 手間を怠った 
 - 過去何回もやっていたのにまたやってしまった経験 
 - どのレベルかというと、OracleDBで言うと 11.2.0.4 BP 180417 の BPレベルの 違い
 

事例②
 - 教訓
 

事例②
 - 教訓
 - 後の手戻り考えたら、その時手間でも絶対すべき 
 - 頭では「やるべき」と分かっているのに、忙しいとつい手間を省いて　しまう 
 - 言い訳をすると当時、要件定義、設計、一部構築作業を一人で実施してい て、余裕がほぼ無かった 
 - とは言え、後のことを考えれば実施すべきだった 
 

事例②
 - その後どうなったの？ 
 - 再試験です！！！！ 
 - 結果スケジュール遅延等散々ご迷惑をおかけしました 
 - その節は、再試験になったメンバー、お客様含め関係者の皆様、　　　　大変申し 訳ございませんでした 
 あの時確認しておけば…！ 
 という後悔の中で 
 一番の失態 
 

事例③
 
 確認は
 記録する！ 
 

事例③
 - 状況
 - DBRE
 - 背景
 - Amazon RDS for MySQLのバージョンアップ 
 - MySQL5.X→MySQL8へ移行 
 - Blue/Greenを使って、ほぼ無停止で移行 
 - 何がおきたか 
 - 既存のトランザクション分離レベルの設定、引継ぎ漏れ 
 

事例③
 - 何がおきたか 
 - 既存のトランザクション分離レベルの設定、引継ぎ漏れ 
 - 元々他のパラメータや設定に不備が多く、全面的に見直しが必要だった 
 - tx_isolation → transaction_isolation に変わったことは有名 
 - transaction_isolationをデフォルトの「REPEATABLE-READ」のままでもアプリ側 の試験が問題なく完了したので、問題なしと判断 
 - 設定変更したことはGitのログに一文書いた程度だった 
 - 何をしくじった？ 
 - トランザクション分離レベルの懸念を、試験で洗い出すのは難しい 
 - 当たり前だが、アプリケーション側で全パターンの試験を実施することは不可能 
 - リリース後、エラー多発。すぐここが原因と思いつかなかった 
 - 恥ずかしながら、8.0へのVerUpは3回目なのに、この醜態 
 

事例③
 - 教訓
 

事例③
 - 教訓
 - 変更ログはしっかり書きましょう 
 - 当時以下のソース、ナレッジベースは作っていたので、そこにしっかり書く 
 - DB設計書（md）：この点だけ書き漏れていた失態 
 - terraform：廃止したパラメータを書いておく 
 - GitHub：変更履歴はちゃんと書く 
 

事例④
 - その後どうなったの？ 
 - 設定変更して、エラー解消しました 
 - 気付いたのが上司という失態 
 - その節は、開発に携わったメンバー、巻き込んだSRE・DBREの皆さん、　申し訳 ございませんでした 
 「勇●ヒンメルならトランザクション分離レベ ルを間違えたりしない」という名言が生まれま した
 

他事例
 - DBサーバ側がクラスタorスケールアウトするのに、クライアント側が 追随しない 
 - JDBCやDBのClient側の設定は開発側が設定していたため、Server側 とClient側の設定が一致しなかった 
 - （自身ではないですが）間違って消した 
 - インストールディレクトリを消した 
 - TABLE・VIEWを消した 
 

総括
 

総括
 - 共通していること 
 - 「確認漏れ」が私がよくやってしまう失敗 
 - 教訓
 - 確認は…
 
 丁寧に
 する
 怠らない
 記録する
 信号機カラー 
 信号もよく確認してね 
 

ご清聴ありがとうございました！