金融システムでは、設計時の前提と運用時の実態がずれることが問題の起点になります。要件定義から本番運用までを同じチームで担当することで、そのずれを持ち込まずに済みます。工程を限定した部分的な受託も可能です。
可用性の設計では、数字を掲げるところではなく「何を停止とみなすか」の定義から入ります。業務の成否で測り、機能ごとに整合性と可用性の優先順位を分け、依存関係を必須と縮退可能に切り分ける。この順序を踏まないと、目標値が設計に接続されません。
可用性目標から逆算した構成の設計と、稼働中システムの設計レビュー。冗長化が意図どおり効いているかの検証まで含みます。
ログ・メトリクス・トレースを相関させ、障害の検知と切り分けにかかる時間を短くします。エラーバジェットの運用設計も扱います。
依存関係の棚卸しと、必須依存・縮退可能な依存の切り分け。分散トレーシングで実態の呼び出し関係を可視化します。
障害対応に必要な情報を自社でどこまで取得できるかの確認と、深刻なシナリオを想定した演習の設計を支援します。
現行構成、依存関係、運用の実態を伺います。設計図と稼働中の実態は食い違うことが多いため、観測データからの確認も行います。
何を停止とみなすか、どこまでの遅れを許容するかを数値で決めます。ここが決まらないと構成の選択肢を絞れません。
決めた定義から逆算して構成を設計し、実装します。切り戻しの手順まで含めて用意します。
復旧手順を実際に動かして所要時間を測り、手順書と実態のずれを潰したうえで引き渡します。継続的な伴走も承ります。
守秘義務のため、社名と具体的な数値は伏せています。
国内の金融機関
資産運用会社
できます。作り直しを前提にせず、どこを残してどこを変えるかの切り分けから一緒に検討します。設計レビューだけのご依頼も承ります。
可能です。要件定義だけ、設計レビューだけ、といった形でもお受けします。ただし設計と運用でチームが分かれると前提のずれが生まれやすいため、引き継ぎの方法は事前に決めておくことをお勧めします。