本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 状态管理
<a name="state"></a>

在最初的机制设计和范围界定过程中，基础设施状态管理的设计决策有时会被忽视。但是，不考虑设计中所需的灵活性，例如开发团队的工具和模式的区别，可能会导致大量的机制后期返工。在评估您的州管理方法时，请考虑以下问题：
+ 谁来管理基础架构和应用程序状态？
+ 当某件事与国家发生冲突时会发生什么？
+ 谁来补救州问题？
+ 如果补救措施由中央团队处理，这种方法会导致开发延迟和停机吗？ 您将如何最大限度地减少这种干扰？

举个例子，想象一下提供中央州管理解决方案的组织。这极大地提高了解决方案的上市速度，因为开发人员无需为每个项目重新设计轮子。但是，有时任何东西都可能损坏。州也不例外。当状态中断时，请考虑以下几点：
+ 应有一个明确的联系点 (POC)。
+ POC 应立即可以修复问题。例如，不要事后才想到州管理的完整工作JIRA清单给 POC 带来负担。
+ 已经有一个可以访问的机制来起作用和解决问题。