詳細は省きますが、以下のような流れでした。
① イベント発生(WEBサーバのサービス停止)を検知
② ITSMツールへの起票と同時にWEBサーバのサービスを再デプロイ&再起動
③ 復旧したらITSMツールのチケットをクローズ
復旧しなかった場合や、通信出来なかった場合は次の手順へ
④ 仮想基盤にアクセスしWEBサーバの仮想マシンを正常な時のスナップショットに戻す
⑤ 復旧を確認し、ITSMツールのチケットをクローズ
具体的には以下のような流れとなっています。
① BIG-IP(WAF)のログを監視しているツール(Elastic Stack)で基準を超えたものを検知
② Elastic Stackから自動的に、EDAに送信元IPアドレス等の情報を含めて送信(Webhook)
③ EDAがElastic Stackから渡された情報を元にBIG-IPのWAFポリシーを自動的に追加
① 1次受付時にバージョン等の環境情報を受付管理システムに入力するor入力してもらう
② 受付管理システムに入力された時点で内容をEDAに自動的に送信(Webhook)
※利用しているシステムがWebhook送信に対応していない場合は、
別途Google FormsやMicrosoft Forms等をベースにしたシステムを用意しても良いでしょう。
③ EDAが受け取った内容をもとに自動的に、検証環境用の仮想基盤やクラウド基盤に検証サーバ等を作成、
指定されたバージョンのソフトをインストール
※検証が不要だと判断された場合は、別途環境削除用のトリガーを用意してそれを動かす等も可能です。
ドイツ最大の銀行であるドイツ銀行では、自社PaaS (Platform as a Service) である「Fabric」を、複数のデータセンター内およびMicrosoft Azure上で稼働させています。
Fabricは、銀行でのコンテナ化されたマイクロサービスベースのアプリケーション開発プラットフォームです。ドイツ銀行がRed Hat Enterprise Linuxで数年間成功を重ねた後、Red Hat OpenShift Container Platform と Red Hat Ansible Towerを導入し、Fabric が構築されました。