Stability and governance are among the hottest topics that should be handled in any software development process. Both topics need to be addressed from the development stage to the deployment and running stages in the production environment.

在任何软件开发过程中，稳定性和治理都是最热门的主题。 从开发阶段到生产环境中的部署和运行阶段，都需要解决这两个主题。

One of the processes or techniques that can help in mastering software development, deployment, and running of the services is the production readiness process. This process is a bunch of tasks and verification of items that need to be checked during the software development process to ensure that the services:

生产准备过程是有助于掌握软件开发，部署和服务运行的过程或技术之一。 此过程是一堆任务，需要对项目进行验证，以确保在软件开发过程中需要检查以下各项：

• have proper documentation有适当的文件
• are prepared for running in production environments准备在生产环境中运行
• are compliant with all adopted standards and non-functional features符合所有采用的标准和非功能性功能

Having the above information checked for each of the developed services will help in

为每个开发的服务检查以上信息将有助于

• providing transparent information regarding the internals of the service提供有关服务内部的透明信息
• the smooth handover between development and SRE/deployment teams开发和SRE /部署团队之间的顺利交接
• giving SRE/deployment teams confidence in running and supporting the services in production使SRE /部署团队对运行和支持生产中的服务充满信心

In this article, I will illustrate how to define a basic production readiness process and I will explain each of the items that should be addressed by this process.

在本文中，我将说明如何定义基本的生产准备过程，并说明该过程应解决的每个项目。

The production readiness process/checklist consist of two main sections:

生产准备过程/清单包括两个主要部分：

• Service description: These are the items that will describe the service and provide services identity. Most of these items are considered as service documentation and always need to be updated, in case of changes.服务描述：这些是描述服务并提供服务标识的项目。 这些项目中的大多数都被视为服务文档，并且在发生更改时始终需要进行更新。
• Standards: These are the items that need to be implemented to make the service compliant with the adopted standards and supported non-functional features.标准：这些是为了使服务符合所采用的标准和受支持的非功能性功能而需要实施的项目。

服务描述项目 (Service Description Items)

Below are a list and a brief description of the items that can be included in the service description section:

以下是服务描述部分中可以包括的项目的列表和简要说明：

• Owners: List the service owners and contributors (engineers, business owners) with their roles and responsibilities. This information can be very helpful when there is a need to take a decision regarding the service or in case of incidents on the production environment.

  所有者 ：列出服务所有者和贡献者(工程师，企业所有者)及其角色和职责。 当需要就服务做出决定时或在生产环境中发生事件时，此信息可能非常有用。

• Business Logic: Describe the service use case and business logic. This will help other teams to learn how the service works internally and will make handover between teams smoother.

  业务逻辑 ：描述服务用例和业务逻辑。 这将帮助其他团队了解服务内部的工作方式，并使团队之间的移交更加顺畅。

• Responsibilities: Describe the service main responsibilities and features to be able to understand the service role and need.

  职责 ：描述服务的主要职责和功能，以便能够了解服务的角色和需求。

• Components and systems: Describe the service architecture and internal components or services.

  组件和系统 ：描述服务体系结构和内部组件或服务。

• Technical specifications: Provide the service technical specifications and requirements such as

  技术规格 ：提供服务技术规格和要求，例如

→ Infrastructure hardware and software requirements (OS, RAM, CPU)

→基础架构硬件和软件要求(OS，RAM，CPU)

→ Technologies used (programming language, libraries, third-party tools)

→使用的技术(编程语言，库，第三方工具)

• Sequence diagrams and flows: Describe all the dependencies for the service and explain the flows and communications between the service and other microservices. This information is very helpful, especially when incidents occur and there is a need to investigate the issue. These diagrams should cover at least the two cases below.

  序列图和流程 ：描述服务的所有依赖关系，并说明服务与其他微服务之间的流程和通信。 此信息非常有帮助，尤其是在发生事件且需要调查此问题时。 这些图应至少涵盖以下两种情况。

→ Service dependencies on third parties

→服务对第三方的依赖

→ Service communications with other services in the stack

→与堆栈中其他服务的服务通信

• Configuration description: Provide and describe all the possible configurations of the service that are needed to install and deploy it to an environment. The set of supported configurations can belong to one or more of the following configuration categories:

  配置说明 ：提供并描述将服务安装和部署到环境所需的所有可能的服务配置。 支持的配置集可以属于以下一个或多个配置类别：

→ Build time configurations: Configurations that are provided when building the service package, for instance, supported operating systems.

→构建时间配置：构建服务包时提供的配置，例如，受支持的操作系统。

→ Deploy time configurations: These are the configurations that can be passed to the service process at the deployment time as environment variables. An example of such configuration is the database connection string.

→部署时间配置：这些是可以在部署时作为环境变量传递给服务流程的配置。 这样的配置示例是数据库连接字符串。

→ Runtime configurations: These are the configurations that are persisted and can be loaded and changed while the service is running (i.e., no need to restart the service), for instance, the main language supported by the service.

→运行时配置：这些是持久配置，可以在服务运行时加载和更改(即，无需重新启动服务)，例如，服务支持的主要语言。

→ Secrets: These are the sensitive pieces of information that should not be stored or shared in plain text, such as database passwords, private keys, and third-party API secrets.

→机密：这些敏感信息不应该以纯文本形式存储或共享，例如数据库密码，私钥和第三方API机密。

• Installation: Describe the steps needed for the installation and deployment of the service. This should be described in detail and cover all the areas and steps needed for deploying the service and troubleshooting the running instances, in cases of issues.

  安装 ：描述安装和部署服务所需的步骤。 在出现问题时，应对此进行详细描述，并涵盖部署服务和对运行中的实例进行故障排除所需的所有领域和步骤。

• E2E automation: Describe the end-to-end test use cases influenced by the service.

  端到端自动化 ：描述受服务影响的端到端测试用例。

• API specifications: Define and document the API specification in case the service is providing an API that should be consumed by other services.

  API规范 ：定义并记录API规范，以防服务提供其他服务应使用的API。

标准和非功能性特征 (Standards and Non-Functional Features)

• Code Style: The service should be compatible with the adopted code style. There are several tools that can be integrated with the CI/CD pipelines to ensure that integrated code is compatible with the code style. For instance, for Ruby applications, Rubocop can be used to achieve this task easily.

  代码样式 ：服务应与采用的代码样式兼容。 有几种工具可以与CI / CD管道集成，以确保集成的代码与代码样式兼容。 例如，对于Ruby应用程序，可以使用Rubocop轻松完成此任务。

• Security: Service security is one of the most important and sensitive topics. Therefore service source code, Docker images, and other packages need to be scanned and verified against known vulnerabilities.

  安全性 ：服务安全性是最重要和敏感​​的主题之一。 因此，需要对服务源代码，Docker映像和其他软件包进行扫描并针对已知漏洞进行验证。

→ Use static analysis libraries such as Brakeman for Ruby applications.

→使用静态分析库，例如用于Ruby应用程序的Brakeman 。

→ Scan Docker images for OS vulnerabilities.

→扫描Docker映像以查找操作系统漏洞。

• Application logging: Production services need to support a consistent way for production logs by services. Below are some recommended points to be considered when defining the logging system and method.

  应用程序日志记录 ：生产服务需要支持一种统一的方法来按服务记录生产日志。 以下是定义日志记录系统和方法时应考虑的一些建议点。

→ Log level is configurable via an environment variable. (On production, the level should be INFO.)

→日志级别可通过环境变量进行配置。 (在生产中，级别应为INFO。)

→ Support single-line logs (only one logline for each web request or event).

→支持单行日志(每个Web请求或事件仅一个日志行)。

→ Support key-value/JSON log format. This will make it easier to parse and ship the logs.

→支持键值/ JSON日志格式。 这将使解析和发送日志变得更加容易。

• Health check endpoints integrations

  健康检查端点集成

Every service deployed to production environments must support health check endpoints to be able to verify the status and the health of the service. These endpoints can be used by the monitoring systems or by the container orchestrator solutions (Swarm or Kubernetes). The health check endpoints are a requirement for supporting high availability and zero-downtime deployment.

部署到生产环境的每个服务都必须支持运行状况检查端点，以便能够验证服务的状态和运行状况。 监视系统或容器协调程序解决方案(Swarm或Kubernetes)都可以使用这些端点。 运行状况检查端点是支持高可用性和零停机时间部署的要求。

• Request tracing over multiple services

  请求跟踪多个服务

In case the software is following a microservice architecture and serving one request may result in multiple calls to several services, we must ensure that the logs for these services are correlated together and can be identified as a single request. This collection of logs should apply not only for synchronous communications between services but also for asynchronous communication such as background jobs, RabbitMQ subscribers, Kafka consumers, and others.

如果软件遵循微服务架构，并且服务一个请求可能导致对多个服务的多次调用，那么我们必须确保将这些服务的日志关联在一起，并且可以将其标识为单个请求。 日志的收集不仅应适用于服务之间的同步通信，还应适用于异步通信，例如后台作业，RabbitMQ订户，Kafka使用者等。

• Docker support and Kubernetes support

  Docker支持和Kubernetes支持

Hosting applications in containers on-premise or in the cloud is a necessity to be able to support a better, smoother, portable deployment, and easy scalability. Therefore there is a need to make sure that the service can run on these systems. It is a good idea is to provide some standards and documentation for the development teams to be able to dockerize services in the early stage of the development. Below are some of the areas that need to be covered for this topic.

必须将应用程序托管在本地容器或云中，才能支持更好，更平滑，可移植的部署以及易于扩展的功能。 因此，需要确保该服务可以在这些系统上运行。 一个好主意是为开发团队提供一些标准和文档，以使其能够在开发的早期阶段对服务进行docker化。 以下是此主题需要涵盖的一些领域。

→ Dockerize the service and create docker files.

→对服务进行Docker化并创建docker文件。

→ Create Makefile for building a unified interface for building Docker images.

→创建Makefile以构建用于构建Docker映像的统一接口。

→ Create Kubernetes resources.

→创建Kubernetes资源。

→ Create a Helm chart for the service.

→为该服务创建Helm图表。

→ Create a Jenkins pipeline for building the Docker images.

→创建用于构建Docker映像的Jenkins管道。

• Performance testing: Performance testing needs to be implemented to be able to verify and understand the performance and limits of the new service and the complete stack.

  性能测试 ：需要执行性能测试，以便能够验证和了解新服务和整个堆栈的性能和限制。

• CI/CD: Ensure that all the needed CI/CD pipelines are implemented and created in Jenkins.

  CI / CD ：确保在Jenkins中实现并创建了所有需要的CI / CD管道。

→ Run unit tests.

→运行单元测试。

→ Build Docker images.

→构建Docker映像。

→ Build Helm charts.

→建立头盔图。

→ Deploy to all supported env.

→部署到所有受支持的环境。

→ etc. — The above list of items is just an example of the items that can be included in the production readiness checklist. The items depend on the nature of the service, the programming language, and the software architecture for which the checklist of items will be created. For instance, in the case of having Rails applications, you may need to add an item to control and collect logs from the Rails console.

→等。—上面的项目列表只是生产准备清单中可以包括的项目的示例。 项目取决于服务的性质，编程语言以及将为其创建项目清单的软件体系结构。 例如，在具有Rails应用程序的情况下，您可能需要添加一个项目以控制和收集来自Rails控制台的日志。

On the other hand, in the case of mobile applications, some of the items on the above list do not apply at all, and new items need to be considered, such as:

另一方面，对于移动应用程序，上面列表中的某些项根本不适用，因此需要考虑新的项，例如：

• Compliance with Google and Apple Developer Programs and app stores T&C.符合Google和Apple开发人员计划以及应用商店的条款与条件。
• Force update强制性升级
• Remote feature flags远程功能标志
• Supported versions and devices支持的版本和设备
• Others …其他 …

结论 (Conclusion)

The production readiness process is a great idea to start controlling the development process and maintain service stability in production systems. It also helps in gaining confidence to run and support the services on production. The process presented in the article is not solid stone. In fact, it is highly recommended to customize and build a process that suits the needs of the project and software services.

生产就绪过程是开始控制开发过程并维持生产系统中服务稳定性的好主意。 它还有助于建立运行和支持生产服务的信心。 本文介绍的过程并非一成不变。 实际上，强烈建议定制和构建适合项目和软件服务需求的流程。