状態の管理

インフラストラクチャの状態管理の設計上の決定は、初期メカニズムの設計とスコープ設定中に見落とされることがあります。ただし、開発チームのツールやパターンの区別など、設計に必要な柔軟性を考慮しないと、大量のポストメカニズムの手直しが発生する可能性があります。状態管理アプローチを評価するときは、次の質問を考慮してください。

• インフラストラクチャとアプリケーションの状態を管理するのは誰ですか？

• 状態が壊れるとどうなりますか？

• 状態の問題を修正するのは誰ですか？

• 修復が中央チームによって処理された場合、そのアプローチは開発の遅延とダウンタイムを引き起こしますか？ この中断を最小限に抑えるにはどうすればよいですか？

例えば、中央状態管理ソリューションを提供する組織を想像してみてください。これにより、デベロッパーがプロジェクトごとにホイールを再考案する必要がなくなるため、ソリューションの市場投入までの速度が大幅に向上します。ただし、何でも壊れることがあります。状態も例外ではありません。状態が壊れたら、次の点を考慮してください。

• 明確な連絡先 (POC) を設定する必要があります。

• POC は、問題を修復するためにすぐに対応できる必要があります。例えば、POC に、後述として状態管理に関する作業の完全なJIRAリストを負担しないでください。

• アクセス可能なメカニズムが既に導入されており、問題が解決されています。