生产准备清单

本文的翻译是专门为从今天开始的DevOps实践和工具课程的学生准备的!





您是否曾在生产中发布过一项新服务? 还是从事此类服务的维护? 如果是这样,您遵循了什么? 什么对生产有利,什么对不利? 您如何培训新的团队成员以发布或维护现有服务。

就工业开发实践而言,大多数公司最终都会采用“狂野西部”的方法,每个团队都通过反复试验独立地确定工具和最佳实践,但这不仅影响项目的成功,而且也影响工程师。

反复试验的方法创造了一个环境,在这种环境中,寻找犯罪者和责任转移是很普遍的。 通过这种行为,从错误中吸取教训并不再重犯变得越来越困难。

成功的组织:

  • 认识到对生产准则的需求,
  • 学习最佳做法
  • 在开发新系统或组件时开始讨论生产准备情况,
  • 确保符合生产准备规则。

生产准备工作包括审核过程。 评论可以是清单或一系列问题的形式。 审核可以手动,自动或同时进行。 代替静态的需求列表,可以制作适合特定需求的清单模板。 这样,可以为工程师提供一种在需要时继承知识和足够灵活性的方法。

何时检查服务准备就绪?


不仅要在发布之前立即进行生产的准备情况检查,而且在将其转移到另一个操作团队或新员工时进行准备检查都是很有用的。

检查时间:

  • 发布生产中的新服务。
  • 将生产服务的操作转移到另一个团队,例如SRE。
  • 将生产服务的运营转移给新员工。
  • 组织技术支持。

生产准备清单


不久前,例如,我发布了一个清单,以检查生产准备情况。 尽管此列表是在与Google Cloud客户端一起使用时出现的,但它在Google Cloud之外仍然有用且适用。

设计开发


  • 设计一个可重现的构建过程,该过程不需要访问外部服务,并且不依赖于外部系统的故障。
  • 在设计和开发期间,为您的服务定义并安装SLO。
  • 记录对您依赖的外部服务的可用性的期望。
  • 通过删除对一个全局资源的依赖关系来避免单点故障。 复制资源或在资源不可用时使用回退选项(例如,硬编码值)。

配置管理


  • 可以通过命令行选项传递静态,小型和非秘密的配置。 其余的,使用配置存储服务。
  • 动态配置必须具有备份设置,以防配置服务不可用。
  • 开发环境配置不应与生产配置相关。 否则,可能会导致从开发环境访问生产服务,从而可能导致隐私问题和数据泄漏。
  • 记录可动态配置的内容,并描述在配置交付系统不可用时的回退行为。

发布管理


  • 详细记录发布过程。 描述释放如何影响SLO(例如,由于缓存未命中而导致的延迟暂时增加)。
  • 文件金丝雀发行。
  • 制定分析金丝雀释放的计划,并在可能的情况下制定自动回滚机制。
  • 确保回滚可以使用与部署相同的过程。

监视的适用性(可观察性)


  • 确保您正在编译SLO所需的一组指标。
  • 确保可以区分客户端数据和服务器数据。 这对于故障排除很重要。
  • 设置警报以减少人工成本。 例如,删除由常规操作引起的警报。
  • 如果您使用Stackdriver,则在仪表板中包含GCP平台指标。 为GCP相关性配置警报。
  • 始终分发传入的跟踪。 即使您不参与跟踪,这也将允许较低级别的服务调试生产问题。

保护与安全


  • 确保所有外部连接均已加密。
  • 确保您的生产项目具有正确的IAM设置。
  • 使用网络隔离虚拟机实例组。
  • 使用VPN安全地连接到远程网络。
  • 记录和监视用户对数据的访问。 确保检查并记录了所有用户对数据的访问。
  • 确保调试端点受ACL限制。
  • 清理用户输入。 配置有效负载大小限制以供用户输入。
  • 确保您的服务可以选择性地阻止单个用户的传入流量。 这将阻止违规而不会影响其他用户。
  • 避免使用外部端点来启动大量内部操作。

能力计划


  • 记录您的服务扩展方式。 例如:用户数,传入有效负载的大小,传入消息的数量。
  • 记录服务的资源要求。 例如:分配的虚拟机实例数,Spanner实例数,专用设备(例如GPU或TPU)。
  • 文档资源限制:资源类型,区域等
  • 记录用于创建新资源的配额限制。 例如,如果使用API​​创建新实例,则限制GCE API请求的数量。
  • 考虑执行压力测试以分析性能下降。

仅此而已。 在教室见!

Source: https://habr.com/ru/post/zh-CN465489/


All Articles