ID:81922さん

基幹系・業務システムにおいて、DBAとしてデータの整合性・性能・再現性をマネージメントしていました。DB設計・制約、ETLやCSV取込、性能劣化や障害リスク、運用手順まで含め、データが壊れず説明可能な状態を維持する責務を担っていました。

私の責務は、 業務・データ・システムを「止めず・壊さず・説明できる状態」に保つことでした。 具体的には、 業務が属人化せず、誰が対応しても回る状態 データが正確で、再現性・追跡性が取れる状態 障害やトラブルが起きても、原因を特定し、復旧・説明ができる状態 を維持することです。 特に基幹系・業務系システムでは、 「動いているように見える」では不十分で、 例外処理・帳票・承認フロー・大量データ処理まで含めて安定している状態が求められました。 私は、 パフォーマンス劣化を事前に潰す 運用で事故が起きない設計にする 現場が判断できる情報を残す ことで、長期間安心して使い続けられる状態を責務として担っていました。

私はまず、 「システムが壊れる原因は技術よりも運用にある」 という前提で考えました。 そのため、 正常系だけでなく例外系・失敗時の挙動 データの再現性・追跡性 人が介在したときの判断ミス まで含めて「どうすれば事故が起きないか」を逆算して設計しました。 途中で直面した問題は、 CSVや外部データが仕様通りに来ない データ量増加による性能劣化 業務都合による仕様変更や例外追加 など、技術だけでは解決できない課題でした。 そこで私は、 厳密な入力チェックとエラーの早期検出 ETL処理の段階分離とログ・原本保持 DB制約による最終防御 といった「二重・三重の防御」を設けました。 また、問題が起きた際に **「誰が見ても原因を追える状態」**を重視し、 ログ設計やデータの履歴管理にも注力しました。 その結果、 障害が起きにくく、 起きても影響範囲を限定でき、 さらに説明責任を果たせる状態を維持できました。 「正しく動く」よりも「壊れても回復できる」状態を目標に考えました。 特に基幹系では、 完璧な入力は来ない 仕様は必ず変わる 人の運用ミスは前提 という現実を受け入れたうえで、 どこで止め、どこで守り、どこで保証するかを明確にしました。 ETLとDBの責任境界を分離し、 DB制約は最後の砦として必ず残し、 ETLでは「意味の正しさ」を担保する設計にしました。 これにより、 技術・業務・運用のどれかが揺れても、 システム全体は安定して回り続ける状態を作ることができました。