「ベンダー丸投げ」をやめた東証、どうやって運用部門の地位を上げたのか
コメント
注目のコメント
MTBFだけでなく、MTTRも。
回復力については、体制やリスクアセスメントも重要ですが、将来DXを推し進めるに当たっては、システムアーキテクチャ、設計ポリシーも大きな役割を担う様になると思います。
今回のケースとは異なりますが、以前輸送系サービスの開発時に、設計ポリシーにTPS(トヨタ生産方式)のJIT(ジャストインタイム)追求からヒントをもらい、回復力を上げるアイデアを設けて運用ストレスを低減させたことがあります。
システムでは、物事のステータス、運用パラメータなど、刻々と変化する情報をどう扱うか決めなければなりません。よくあるのが、固定的なマスターデータと、刻々と更新されるトランザクションデータの種別を設け、トラブル後はそれぞれの完全性が確保されるまで起動できないルールに仕立てる案です。 この完全性をデータにだけ期待するのが、設計ポリシーで、このせいで復旧時間が短縮できなくなります。
JITの追求例では、ワンサイクル回ると自動的にステータスがリセットされその後は正常復帰したものとみなせるオペレーションがあります。ワンサイクルを30分とすれば、現場の異常処置で30分フォローすれば、あとは優先すべきことを心配できる様になります。機能疎結合と結果整合によって、ロバスト性とフレキシビリティーの両立、いわばレジリエンスを高くする知恵です。
それが実現できる様にするためには、アーキテクチャと設計ポリシーが活きてきます。運用で刻々と変わる"マスター"データを撲滅させ、自動プロビジョニングで資源表現ができるでしょう。更新削除の概念が無くなればストレスは激減です。ステータスデータではなく、センサーからのリアルで駆動させます。
その上で、資産や命に関わる重要なものを最小限になるまで分離して、上のオペレーションと ごちゃ混ぜにしません。この中には、プライバシーの様な機微な情報を徹底的に必要工程まで 持ち出さず隔離して、システム内に流さない工夫も含まれます。
DXを推し進めるなら、体制に加えてアーキテクチャや設計ポリシーからのリファクタリングか、ゼロベースからのモダン開発が有用だと、強く感じています。むかしの話。
ネットワークの拡張と更新の話があり、何度かニーズやゴール感の確認に行ったが、言われたのは。
絶対に止めないこと。無限責任を取ること。
止まらない様に（確率を限りなく下げる）する設計は理論上出来るが、無限責任ってナニ？世界の負の遺産を背負ってことか。
むかしの話です。
