# 了解可用性需求 人们最初会认为应用程序的可用性是整个应用程序的单一目标，这种想法很常见。但是，经过仔细检查后，我们经常发现应用程序或服务的某些方面具有不同的可用性要求。例如，比起检索现有数据，某些系统可能会优先实现接收和存储新数据的功能。又或者，比起更改系统配置或环境的操作，有些系统可能会优先执行实时操作。服务可能会在一天中的某些时段具有非常高的可用性要求，但可以容忍这些时段之外的更长时间的中断。您可以通过这些方法来将单个应用程序分解成各个组成部分，并评估每个部分的可用性要求。这样做的好处是可以根据特定需求集中投入可用性方面的精力（和费用），而不是根据最严格的要求设计整个系统。 | 建议 | | --- | | 批判性地评估应用程序的独特方面，并在适当的情况下区分可用性和灾难恢复设计目标来反映业务需求。 | 在 AWS，我们通常会将服务分为“数据面板”和“控制面板”。数据面板负责交付实时服务，控制面板则用于配置环境。例如，Amazon EC2 实例、Amazon RDS 数据库和 Amazon DynamoDB 表的读/写操作都是数据面板操作。而启动新的 EC2 实例或 RDS 数据库，或者在 DynamoDB 中添加或更改表元数据，都属于控制面板操作。虽然高水平的可用性对所有这些功能来说都很重要，但数据面板的可用性设计目标通常比控制面板更高。因此，具有高可用性需求的工作负载应该避免运行时依赖于控制面板操作。 很多 AWS 客户会采用类似的方法批判性地评估其应用程序，并识别具有不同可用性需求的子组件。然后，针对不同的方面量身定制可用性设计目标，并执行适当的工作来设计系统。AWS 拥有根据一系列可用性设计目标设计应用程序的丰富经验，包括设计具有 99.999% 或更高可用性的服务。AWS解决方案架构师（SA）可帮助您根据可用性目标进行合理设计。在设计过程中尽早让 AWS 参与进来，有助于我们更好地帮助您实现可用性目标。并不是只有在启动工作负载前才要针对可用性进行规划，还应该持续不断地进行规划，从而在获得运营经验的过程中细化设计，从实际事件中吸取经验教训，并能承受不同类型的故障。然后，您可以投入适当的工作来改进实施。 工作负载所需的可用性需求必须与业务需求和关键性相符。使用定义的 RTO、RPO 和可用性来定义业务关键性框架，然后您就可以对每个工作负载进行评估。此方法要求参与工作负载实施的人员了解该框架，了解工作负载对业务需求的影响。