基础设施代码故障排除与修复指南
在现代的系统环境中,当面临应用程序无法恢复的情况时,如促销应用程序出现问题,我们可以采用金丝雀部署(Canary Deployment)的方法,将流量切换到新实例以恢复系统。基础设施即代码(Infrastructure as Code)能让我们更轻松地重现环境,并且遵循不可变性原则意味着我们已经有了为变更创建新环境的模式。这两个原则的结合有助于缓解具有较大影响范围的高风险变更。
1. 故障排除
当我们对系统进行临时修复,让促销团队仍能为“Cool Caps for Keys”发送促销优惠时,还需要确保应用程序的身份和访问管理安全。若移除了促销服务不应有的管理权限后服务失败,该从何处着手排查呢?
基础设施即代码的故障排除通常遵循特定模式。在复杂的基础设施系统中,许多由基础设施即代码导致的变更失败往往源于三个原因:配置漂移(Drift)、依赖关系(Dependencies)或环境差异(Differences)。检查配置是否存在这些问题有助于识别问题并找到潜在的解决方案。
1.1 检查配置漂移
许多基础设施变更失败源于配置与资源状态之间的配置漂移。我们首先要检查代码与实际状态之间是否存在漂移,确保服务账户的基础设施代码与Google Cloud Platform(GCP)中的服务账户状态相匹配。
例如,在“Cool Caps for Keys”的案例中,我们审查基础设施代码中定义的促销服务账户权限。以下是定义服务和角色的基础设施代码示例:
from os import environ
import databa