01-综合架构开篇

下面给出一个典型大型网站的架构图示例，并对各模块的作用和运维关注点进行简单说明。此图仅供参考，不同业务场景下可能会有差异。

【大型网站架构图示例】

                         ┌─────────────────────────────────────────┐
                         │                用户请求                │
                         └─────────────────────────────────────────┘
                                        │
                                        ▼
                         ┌─────────────────────────────────────────┐
                         │                CDN/加速层              │
                         │  （缓存静态资源、全局分发、DDoS防护等）  │
                         └─────────────────────────────────────────┘
                                        │
                                        ▼
                         ┌─────────────────────────────────────────┐
                         │             全局负载均衡层             │
                         │ （DNS调度、GSLB、多活数据中心调度）       │
                         └─────────────────────────────────────────┘
                                        │
                                        ▼
             ┌──────────────────────────┴────────────────────────────┐
             │                                                       │
             ▼                                                       ▼
┌─────────────────────────┐                              ┌─────────────────────────┐
│    数据中心 / IDC A     │                              │    数据中心 / IDC B     │
└─────────────────────────┘                              └─────────────────────────┘
             │                                                       │
             ▼                                                       ▼
┌───────────────────────────────┐                      ┌───────────────────────────────┐
│         本地负载均衡层         │                      │         本地负载均衡层         │
│  （反向代理、SSL卸载、健康检查） │                      │  （反向代理、SSL卸载、健康检查） │
└───────────────────────────────┘                      └───────────────────────────────┘
             │                                                       │
             ▼                                                       ▼
┌──────────────────────────────────────────────┐    ┌──────────────────────────────────────────────┐
│         应用层（Web/API服务器群）            │    │         应用层（Web/API服务器群）            │
│  ────────────────────────────────────────────  │    │  ────────────────────────────────────────────  │
│  1. Web服务器         2. 应用服务器         │    │  1. Web服务器         2. 应用服务器         │
│  （前端渲染、静态资源）  （业务逻辑处理）       │    │  （前端渲染、静态资源）  （业务逻辑处理）       │
└──────────────────────────────────────────────┘    └──────────────────────────────────────────────┘
             │                                                       │
             ▼                                                       ▼
┌──────────────────────────────────────────────┐    ┌──────────────────────────────────────────────┐
│                缓存层/中间件                │    │                缓存层/中间件                │
│  （Redis/Memcached、消息队列、服务治理等）    │    │  （Redis/Memcached、消息队列、服务治理等）    │
└──────────────────────────────────────────────┘    └──────────────────────────────────────────────┘
             │                                                       │
             ▼                                                       ▼
┌──────────────────────────────────────────────┐    ┌──────────────────────────────────────────────┐
│                数据存储层                   │    │                数据存储层                   │
│  ────────────────────────────────────────────  │    │  ────────────────────────────────────────────  │
│  1. 关系型数据库（MySQL/PostgreSQL）         │    │  1. 关系型数据库（主从/集群部署）             │
│  2. NoSQL数据库（MongoDB/Redis/ES）            │    │  2. NoSQL数据库（MongoDB/Redis/ES）            │
│  3. 文件存储/对象存储（NFS/S3等）               │    │  3. 文件存储/对象存储（NFS/S3等）               │
└──────────────────────────────────────────────┘
             │                                                       │
             └──────────────────────────┬────────────────────────────┘
                                        ▼
                         ┌─────────────────────────────────────────┐
                         │         监控、日志与告警系统            │
                         │  （ELK、Prometheus、Grafana、Zabbix）    │
                         └─────────────────────────────────────────┘
                                        │
                                        ▼
                         ┌─────────────────────────────────────────┐
                         │              运维管理平台               │
                         │    （自动化部署、配置管理、备份恢复）      │
                         └─────────────────────────────────────────┘

各模块说明及运维关注点

1. CDN/加速层

   • 功能： 加速静态资源分发、减轻源站压力、防御DDoS攻击。
   • 运维注意： 定期监控缓存命中率、流量分布和安全事件。

2. 全局负载均衡层

   • 功能： 根据用户地理位置、业务状态调度请求，支持跨数据中心调度。
   • 运维注意： 配置健康检查、定期测试容灾切换，确保调度策略的合理性。

3. 本地负载均衡层

   • 功能： 在数据中心内部对流量进行均衡分发，支持SSL终端卸载、请求转发等。
   • 运维注意： 监控后端服务器的健康状态，及时发现并处理故障。

4. 应用层（Web/API服务器群）

   • 功能： 处理前端渲染、业务逻辑、API接口等核心功能。
   • 运维注意： 定期更新应用补丁，监控请求响应时间和错误率；支持自动化扩容和滚动升级。

5. 缓存层/中间件

   • 功能： 减轻数据库压力，支持异步处理、队列化任务、分布式锁等。
   • 运维注意： 监控缓存命中率、队列长度、延时情况，并设置合理的过期策略；确保中间件的高可用部署。

6. 数据存储层

   • 功能： 存储业务数据、日志、用户文件等；支持分库分表、读写分离等架构。
   • 运维注意： 定期备份、灾备演练、性能调优；实时监控数据库状态，防止单点故障。

7. 监控、日志与告警系统

   • 功能： 收集各层日志和指标，实现实时监控和告警，便于快速响应故障。
   • 运维注意： 制定告警策略，定期检查系统日志，设定自动化脚本进行初步响应；配置容量规划和日志归档。

8. 运维管理平台

   • 功能： 自动化部署、配置管理、补丁升级、故障恢复和回滚管理。
   • 运维注意： 确保自动化工具的稳定性，记录每次部署操作；建立详细的运维手册和应急预案。

总结：

• 高可用与容灾： 建议各层均采用冗余设计，重要模块（如负载均衡、数据库）配置集群和备份节点，确保单点故障不影响整体服务。
• 安全性： 通过CDN防御、WAF、SSL加密、权限管理和日志审计等手段构建全方位安全防护体系。
• 可扩展性： 支持业务量增长的水平扩展和垂直扩展，定期进行性能压力测试和容量规划。
• 自动化运维： 利用CI/CD工具、自动化监控和告警平台，实现快速部署和问题定位。

该架构图和说明旨在帮助运维人员了解大型网站的整体部署和关键技术点。根据实际业务和技术栈，可以在此基础上进行调整和优化。

https://excalidraw.com/

绘制

轻松理解网站架构

运维内网维护架构

https://excalidraw.com/

绘制

https://www.processon.com/

绘制

网站上线流程架构

运维网站上线流程架构是一个涉及多环节、多角色协同工作的复杂体系，旨在确保网站能够安全、稳定、高效地从开发环境过渡到生产环境并正式面向用户提供服务。以下是详细的流程架构介绍：

上线前准备

需求与设计评审

• 业务需求确认：产品经理或业务方明确网站的功能需求、性能指标、用户体验要求等，并与开发、测试、运维团队进行详细沟通，确保各方对业务目标有清晰的理解。
• 架构设计评审：架构师展示网站的整体架构设计，包括技术选型、系统模块划分、数据库设计、网络拓扑等，评估架构的合理性、可扩展性和性能瓶颈，确保能够满足业务需求和未来发展。

代码开发与测试

• 代码编写：开发团队按照需求和设计文档进行代码编写，遵循统一的编码规范和最佳实践，确保代码的可读性、可维护性和可测试性。
• 单元测试：开发人员对自己编写的代码进行单元测试，验证代码的基本功能是否正确，尽早发现和修复代码中的缺陷。
• 集成测试：将各个模块的代码集成在一起进行测试，检查模块之间的接口是否正常工作，确保系统的整体功能完整性。
• 系统测试：测试团队在模拟生产环境的测试环境中对整个网站进行全面测试，包括功能测试、性能测试、安全测试、兼容性测试等，发现并记录系统中存在的问题，反馈给开发团队进行修复。

环境搭建与配置

• 生产环境准备：运维团队根据网站的架构设计和性能需求，搭建生产环境的服务器、网络设备、存储设备等基础设施，安装操作系统、数据库、中间件等软件，并进行必要的配置和优化。
• 配置管理：使用配置管理工具（如 Ansible、Puppet 等）对生产环境的配置信息进行统一管理和版本控制，确保不同服务器之间的配置一致性，方便后续的部署和维护。

上线计划制定

• 时间安排：确定网站上线的具体时间，考虑业务需求、用户流量低谷期等因素，尽量减少对用户的影响。
• 回滚策略：制定详细的回滚计划，明确在上线过程中出现问题时如何快速恢复到上一个稳定版本，降低风险。
• 应急方案：针对可能出现的各种异常情况（如服务器故障、网络中断、数据丢失等）制定应急处理方案，确保在出现问题时能够迅速响应和解决。

上线过程

代码部署

• 代码打包：开发团队将经过测试的代码进行打包，生成可部署的软件包，包含网站的所有代码文件、配置文件、依赖库等。
• 部署到预发布环境：首先将软件包部署到预发布环境进行最后的验证，预发布环境的配置与生产环境尽量保持一致，检查网站在接近生产环境的条件下是否能够正常运行。
• 灰度发布（可选）：如果网站规模较大或变更风险较高，可以采用灰度发布的方式，先将新版本的网站发布给一小部分用户进行试用，收集用户反馈和监控系统性能，根据反馈情况逐步扩大发布范围，降低上线风险。
• 全量发布：在预发布环境验证通过或灰度发布效果良好后，将新版本的网站全量部署到生产环境，替换旧版本的代码。

数据迁移与同步

• 数据备份：在进行数据迁移之前，对生产环境中的数据进行全面备份，以防数据丢失或损坏。
• 数据迁移：根据业务需求，将旧系统中的数据迁移到新系统中，确保数据的完整性和一致性。迁移过程中可能需要进行数据清洗、转换和映射等操作。
• 数据同步：在上线过程中，确保新旧系统之间的数据同步，避免出现数据不一致的问题。可以采用实时同步或定时同步的方式进行数据同步。

系统监控与验证

• 监控系统启动：在网站上线后，立即启动监控系统，对服务器的性能指标（如 CPU 使用率、内存使用率、磁盘 I/O 等）、应用程序的运行状态（如响应时间、吞吐量、错误率等）进行实时监控。
• 功能验证：运维人员和测试人员对网站的各项功能进行再次验证，确保网站在生产环境中能够正常运行，没有出现新的问题。

上线后维护

性能优化

• 数据分析：根据监控系统收集到的数据，对网站的性能进行深入分析，找出性能瓶颈和问题所在。
• 优化措施：针对性能问题采取相应的优化措施，如调整服务器配置、优化数据库查询语句、采用缓存技术等，提高网站的响应速度和吞吐量。

故障处理

• 问题发现：监控系统实时监测网站的运行状态，一旦发现异常情况（如服务器崩溃、应用程序报错、网络中断等）及时发出警报。
• 故障排查：运维团队根据警报信息迅速进行故障排查，定位问题的根源，确定解决方案。
• 问题修复：按照既定的应急方案或解决方案对故障进行修复，尽快恢复网站的正常运行。

用户反馈处理

• 反馈收集：通过各种渠道（如用户反馈表单、在线客服、社交媒体等）收集用户对网站的反馈和意见。
• 问题处理：对用户反馈的问题进行分类整理，分析问题的严重程度和影响范围，及时安排开发团队进行修复和优化。

版本迭代与更新

• 需求收集与分析：持续收集业务方和用户的新需求，对需求进行分析和评估，确定是否需要进行版本迭代和更新。
• 开发与测试：根据需求进行代码开发和测试，重复上线前的准备流程，确保新版本的质量和稳定性。
• 上线发布：按照上线流程将新版本的网站发布到生产环境，实现网站的持续改进和升级。

正式开始学习网站架构后，最终目的是确保公司的产品能上线，例如淘宝网开发完毕后，能正确的让老百姓通过访问域名

www.taobao.com
www.yuchaoit.cn

即可正确的看到网站提供的功能服务，这是运维的工作职责。

那么你就得对互联网产品的开发生命周期有足够的认识，也就是这个网站是经过了什么样的流水线，从诞生、到最终上线的。

软件生命周期

软件生命周期是指从软件项目的构思开始，经过开发、使用和维护，直到最终退役的整个过程。

它为软件开发和管理提供了一个结构化的框架，有助于提高软件质量、控制成本和进度。

常见的软件生命周期模型有瀑布模型、敏捷模型、迭代模型等，下面将详细介绍软件生命周期包含的各个阶段。

可行性研究与计划

• 定义：这是软件项目的起始阶段，主要对软件项目的可行性进行全面分析和评估，并制定项目计划。
• 具体工作
  • 初步调研：收集与软件项目相关的信息，了解业务需求、市场情况、技术现状等。
  • 可行性分析：从技术可行性、经济可行性、操作可行性等方面进行分析，判断项目是否值得开展以及是否具备开展的条件。例如，评估现有的技术水平能否实现软件的功能要求，项目的成本预算是否在可承受范围内，用户是否能够方便地使用该软件等。
  • 制定项目计划：确定项目的目标、范围、进度安排、资源需求等，制定详细的项目计划，为后续的开发工作提供指导。

需求分析

• 定义：准确理解用户和业务对软件系统的功能、性能、可靠性等方面的具体要求，并将其转化为软件需求规格说明书。
• 具体工作
  • 需求收集：通过与用户、业务人员、领域专家等进行沟通和交流，采用访谈、问卷调查、观察等方法收集软件需求。
  • 需求分析与建模：对收集到的需求进行分析和整理，去除模糊、矛盾的需求，建立需求模型，如功能模型、数据模型、行为模型等，以清晰地描述软件的需求。
  • 需求规格说明：编写软件需求规格说明书，明确软件的功能需求、非功能需求、输入输出要求等，作为软件开发和测试的依据。

设计阶段

• 定义：根据需求规格说明书，设计软件的体系结构、模块划分、数据库设计等，为软件的实现提供蓝图。
• 具体工作
  • 架构设计：确定软件的整体架构，选择合适的架构模式，如分层架构、微服务架构等，定义各个模块之间的关系和接口。
  • 详细设计：对每个模块进行详细设计，包括算法设计、数据结构设计、界面设计等，确定模块的内部实现细节。
  • 数据库设计：设计数据库的结构，包括表结构、索引、关系等，确保数据库能够高效地存储和管理数据。

编码实现

• 定义：开发人员根据设计文档，使用合适的编程语言和开发工具，将软件设计转化为可执行的代码。
• 具体工作
  • 代码编写：按照编码规范和设计要求编写代码，实现软件的各项功能。
  • 代码审查：对编写好的代码进行审查，检查代码的质量、可读性、可维护性等，发现并纠正代码中的错误和问题。
  • 单元测试：开发人员对自己编写的代码进行单元测试，验证代码的基本功能是否正确，尽早发现和修复代码中的缺陷。

测试阶段

• 定义：对软件进行全面的测试，以发现软件中存在的缺陷和问题，确保软件的质量符合需求规格说明书的要求。
• 具体工作
  • 测试计划制定：根据软件需求规格说明书和设计文档，制定测试计划，确定测试的范围、方法、策略、进度安排等。
  • 测试用例设计：根据测试计划，设计详细的测试用例，覆盖软件的各种功能和场景，确保测试的全面性和有效性。
  • 测试执行：按照测试用例对软件进行测试，记录测试结果，发现并报告软件中的缺陷和问题。
  • 缺陷修复与回归测试：开发人员对测试中发现的缺陷进行修复，然后进行回归测试，确保修复后的软件没有引入新的问题。

部署与维护

• 定义：将软件部署到实际的运行环境中，供用户使用，并对软件进行持续的维护和优化。
• 具体工作
  • 部署：将开发和测试完成的软件部署到生产环境中，包括安装软件、配置服务器、迁移数据等工作。
  • 维护：对软件进行日常维护，包括故障排除、性能优化、功能扩展、安全补丁更新等，确保软件的稳定运行和不断改进。
  • 用户支持：为用户提供技术支持和培训，帮助用户解决使用过程中遇到的问题，提高用户的满意度。

退役阶段

• 定义：当软件无法满足业务需求、技术过时或维护成本过高时，决定终止软件的使用和维护，对软件进行退役处理。
• 具体工作
  • 数据迁移与保存：将软件中的重要数据迁移到其他系统或进行妥善保存，确保数据的安全性和可用性。
  • 资源回收与清理：回收软件使用的硬件资源、软件许可证等，清理相关的配置和数据，释放系统资源。
  • 经验总结：对软件项目的整个生命周期进行总结，分析项目的成功经验和不足之处，为后续的项目提供参考和借鉴。

软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。

整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。

既然我们学习的是运维，要知道，你维护的项目，这个产品，如何诞生的，你又处于哪一个环节。

wordpress博客产品分析

以一个经典的网站产品举例，我们来看看，我们学的运维，它在公司里到底是为谁服务的

产品分析

该公司决定开发一款产品，主要以提供网站功能为主

用户使用该产品，特色是可以在任何地方、发布任何内容

这也就是在表述，一个网站的基本功能

而wordpress这个软件，就是一个网站模板，你使用它就可以轻松部署一个网站，包括其中所需要的

产品核心特色

前端功能

前端功能（提供了大量美观的前端模板，主题）

不仅仅是为了美观、而是该网站架构，适用于N种业务

让你无须有自己的设计师，就可以搭建一个属于你的网站，如

咖啡馆官网

花店官网

旅游网

摄影网

交友网

这些业务都只需要更换网站数据，模板都同一套即可，你要做的就是去准备图片、文案等素材，关于你想要维护的网站数据，例如你爱好音乐、摩托等。

后端功能

后端功能，提供如

• 数据统计，阅读数、点赞数、粉丝数
• 搜索引擎、博客搜索、文章搜索
• 数据存储、提供数据库服务
• 安全性，网站前后端源码高质量，没有常见漏洞，放心使用
• 分享功能，wordpress的文章，可以一键分享到如微信、qq等平台。
• 文本编辑器，在线的编辑文章，支持普通文本、markdown、图片大小裁剪等功能。👿

运维功能

php程序部署的方案。

轻松部署，提供LNMP环境即可搭建、自适应PC端、移动端页面，均可以通过修改前端主题，实现自适应的美观页面。

自己获取源码部署

在该公司的角度看待运维

1.在上述软件需求明确后，根据功能，开发源代码

2.提供软件源码

3.交付给运维部署

4.网站运行后，进行后续的业务配置。

看在我们个人角度，使用该产品

1.下载wordpress源码
2.自己准备好linux机器环境，部署LNMP，可以用于运行该wordpress
3.后续的网站维护，linux后台维护

官网提供了云产品

该功能也就是人家官网提供的，针对于非IT，不懂软件技术的人群，也能轻松部署自己的网站，人家提供域名、服务器、云存储等一些列功能，你只需要鼠标点点点，选择好所有的模板，最后付钱就行。

wordpress在全球有N个用户，那这巨大的用户群体，支付的费用，养活自己的IT团队，也就是小菜一碟了。

关于wordpress的官网上线

上线

是指项目发布到服务器，正式给用户提供访问。

如淘宝网源代码以部署到服务器上，此时你可以通过浏览器访问www.taobao.com开始购物了。

生产环境

如网站源码运行在该环境中，正式对互联网的用户提供访问，受到整个运维团队的全力维护。

https://wordpress.com/

关于软件开发完毕后要进行多环境的测试运行，以检查代码可以正确的运行。

• 开发环境
  • 根据软件运行要求，部署程序可以运行的最低环境，确保功能性。
  • 如在集群、单节点的选择。
• 测试环境
  • 根据软件运行要求，部署单节点、多节点的多套测试环境，且完成自动化发布。
• 预生产环境
  • 根据软件运行要求，部署单节点、多节点的多套运行环境，实现自动化发布、程序运行监控。
• 生产环境
  • 根据软件运行最高要求，部署最高配置的服务器，完成集群部署
  • 且完成后续的自动化发布、更新、监控，以及后续技术支持。

bilibili.com 网站技术角度分析

从技术角度分析哔哩哔哩（bilibili.com）网站，可以从架构设计、前端技术、后端技术、存储与缓存、视频处理与分发、安全与性能优化等多个方面进行探讨：

架构设计

• 微服务架构：B站作为一个大型的综合性视频网站，业务复杂且功能众多。采用微服务架构将不同的业务功能拆分成多个独立的服务，如视频服务、用户服务、评论服务等。每个微服务可以独立开发、部署和扩展，提高了开发效率和系统的可维护性。例如，当视频业务需要进行性能优化或功能升级时，可以只对视频服务进行调整，而不会影响其他服务的正常运行。
• 分布式架构：为了应对海量的用户请求和高并发流量，B站使用分布式架构将系统的各个组件分布在多个服务器上。通过负载均衡器将用户请求均匀地分配到不同的服务器上，避免单点故障，提高了系统的可用性和性能。例如，在B站的跨年晚会等大型活动期间，分布式架构能够有效地处理大量用户的同时访问。

前端技术

• 响应式设计：B站的网站需要在各种设备上提供良好的用户体验，因此采用了响应式设计技术。通过使用HTML5、CSS3和JavaScript等前端技术，根据设备的屏幕尺寸和分辨率自动调整页面布局和元素大小，确保在PC端、移动端等不同设备上都能呈现出合适的界面。
• 前端框架与库：可能使用了Vue.js或React等前端框架来构建用户界面。这些框架提供了组件化开发、虚拟DOM等特性，提高了前端开发的效率和代码的可维护性。同时，还会使用一些第三方库，如Axios进行网络请求、Lottie实现动画效果等。
• WebAssembly：对于一些对性能要求较高的功能，如视频解码、弹幕渲染等，B站可能会采用WebAssembly技术。WebAssembly可以在浏览器中以接近原生代码的速度运行，提高了这些功能的性能和响应速度。

后端技术

• 编程语言与框架：后端开发可能使用Python、Go等编程语言。Python具有丰富的库和框架，如Django、Flask等，适合快速开发和实现业务逻辑；Go语言则具有高性能、高并发的特点，适合处理大量的网络请求。B站可能会根据不同的业务场景选择合适的语言和框架。
• API设计：提供统一的API接口供前端和其他第三方应用调用。API设计遵循RESTful风格，具有良好的可读性和可维护性，同时使用JSON作为数据传输格式，方便数据的交互和处理。
• 消息队列：使用消息队列（如Kafka、RabbitMQ等）来实现异步通信和解耦。例如，当用户上传视频时，将视频上传任务放入消息队列中，由专门的处理程序异步处理，避免阻塞主线程，提高系统的响应速度和吞吐量。

存储与缓存

• 数据库：使用关系型数据库（如MySQL）来存储用户信息、视频元数据、评论等结构化数据。对于一些对读写性能要求较高的场景，可能会采用数据库集群和读写分离技术。同时，也会使用非关系型数据库（如Redis、MongoDB等）来存储缓存数据、用户会话信息等。Redis作为内存数据库，具有极高的读写速度，可以用于缓存热门视频的信息、用户的点赞和收藏记录等，减少对数据库的访问压力。
• 对象存储：B站的视频和图片等非结构化数据量巨大，采用对象存储（如阿里云OSS、腾讯云COS等）来存储这些数据。对象存储具有高可扩展性、低成本、高可靠性等优点，能够满足B站海量数据存储的需求。

视频处理与分发

• 视频编码与转码：为了提供多种清晰度的视频播放选项，B站需要对上传的视频进行编码和转码处理。使用FFmpeg等开源工具将视频转换为不同的格式和分辨率，如MP4、HLS等，以适应不同网络环境和设备的播放需求。
• 内容分发网络（CDN）：CDN是B站视频分发的关键技术之一。通过在全球各地部署CDN节点，将视频内容缓存到离用户最近的节点上，当用户请求视频时，直接从离用户最近的CDN节点获取视频数据，减少了网络延迟，提高了视频播放的流畅性。

安全与性能优化

• 安全防护：B站面临着各种安全威胁，如DDoS攻击、SQL注入、XSS攻击等。采用多种安全防护措施，如防火墙、入侵检测系统（IDS）、Web应用防火墙（WAF）等，对网站进行实时监控和防护。同时，对用户的登录和交易等敏感操作进行加密处理，保障用户信息的安全。
• 性能优化：通过前端性能优化（如压缩代码、合并文件、优化图片等）、后端性能优化（如缓存技术、异步处理、数据库优化等）和网络性能优化（如CDN加速、负载均衡等）等多种手段，提高网站的响应速度和性能，为用户提供流畅的浏览体验。

图解Dev、QA、staging、prod四大环境

这部分内容，也紧密练习到于超老师要讲解的持续集成、CI/CD篇知识点。

软件应用开发的经典模型有这样几个环境：开发环境(development)、集成环境(integration)、测试环境(testing)、QA验证，模拟环境(staging)、生产环境(production)

在软件开发和运维过程中，Dev、QA、Staging、Prod 分别代表不同的环境，它们在软件生命周期的不同阶段发挥着重要作用，以下为你详细介绍：

Dev（开发环境，Development Environment）

• 定义：开发环境是开发人员进行代码编写、调试和测试自己代码的地方。它主要用于支持开发人员进行日常的开发工作，允许他们自由地修改代码、尝试新功能和特性。
• 特点
  • 配置灵活：开发环境通常由开发人员根据自己的需求进行配置，可以安装各种开发工具和依赖库，以便于代码的编写和调试。
  • 数据模拟：为了方便开发和测试，开发环境中的数据往往是模拟数据，不需要与真实业务数据一致。
  • 独立性：开发环境相对独立，不同开发人员的开发环境可以存在差异，不会影响其他环境和整个项目的运行。
• 用途：开发人员在该环境中进行新功能的开发、代码的修改和单元测试等工作，及时发现和解决代码中的语法错误和逻辑问题。

QA（测试环境，Quality Assurance Environment）

• 定义：测试环境是专门用于软件测试的环境，由质量保证（QA）团队使用。其目的是尽可能模拟生产环境的条件，对软件进行全面的测试，以发现软件中的缺陷和问题。
• 特点
  • 接近生产环境：测试环境的硬件配置、软件版本、网络环境等尽可能与生产环境保持一致，以便更准确地发现软件在实际运行中可能出现的问题。
  • 数据真实或半真实：测试环境中使用的数据通常是经过处理的真实数据或模拟的接近真实业务场景的数据，以确保测试的有效性。
  • 严格管理：对测试环境的访问和操作进行严格管理，确保测试过程的规范性和测试结果的准确性。
• 用途：QA 团队在该环境中进行功能测试、性能测试、安全测试等各种类型的测试，验证软件是否满足需求规格说明书的要求，发现并记录软件中的缺陷，反馈给开发团队进行修复。

Staging（预发布环境，预生产环境，Staging Environment）

• 定义：预发布环境是在将软件部署到生产环境之前的最后一个测试环境，用于进行最终的系统级测试和验证。它是生产环境的一个副本，尽可能模拟生产环境的所有方面。
• 特点
  • 高度仿真：预发布环境的配置和生产环境几乎完全相同，包括服务器硬件、软件版本、网络拓扑、数据库配置等，以确保软件在预发布环境中的运行情况与生产环境一致。
  • 全面验证：在预发布环境中进行全面的系统级测试，包括功能集成测试、兼容性测试、用户验收测试等，确保软件在正式上线前没有重大问题。
  • 数据同步：预发布环境中的数据通常与生产环境的数据保持同步或使用真实数据的副本，以便进行更真实的测试。
• 用途：通过在预发布环境中进行最后的测试和验证，发现并解决可能在生产环境中出现的问题，降低软件上线的风险。同时，也可以让相关人员（如业务用户、运维人员等）提前熟悉软件的操作和使用，为正式上线做好准备。

Prod（生产环境，Production Environment）

• 定义：生产环境是软件正式运行并为用户提供服务的环境，是软件生命周期的最终阶段。它直接面向最终用户，对软件的稳定性、可靠性和性能要求极高。
• 特点
  • 稳定性优先：生产环境的首要目标是确保软件的稳定运行，任何对生产环境的更改都需要经过严格的审批和测试流程，以避免引入新的问题。
  • 数据真实：生产环境中使用的是真实的业务数据，这些数据的安全性和完整性至关重要。
  • 高可用性：采用各种技术手段（如负载均衡、集群化、备份恢复等）来保证生产环境的高可用性，减少系统停机时间，确保用户能够随时访问软件服务。
• 用途：生产环境为最终用户提供软件服务，处理用户的各种业务请求，是软件产生价值的地方。运维团队负责监控生产环境的运行状态，及时处理系统故障和问题，保障软件的正常运行。

development

development【开发环境】是程序的开发环境，一般是个人或者小团队的工作环境，目的是让项目在开发者本地运行，跟其他的团队区分，并且允许开发人员任意修改程序而不用担心会修改其他团队成员的工作。

testing

Test 环境、Staging 环境、Prod 环境，这三个环境，都有其独特的属性。只有通过对其特性的分析，确定测试人员的关注点和侧重点，才能更好地利用它们。

测试环境（Test）

测试环境也叫 Test 环境，这是测试人员进行新功能测试的主要环境，一般由测试人员自己部署、管理和使用。

测试环境特点

测试环境一般会克隆生产环境的配置，如果一个服务在测试环境中无法按预期工作，就视为测试不通过，就不能把它发布到生产环境中。

staging/stage

staging【预发布环境】是用来在项目正式上线之前对应用进行集成、测试和预览，通常，staging环境尽可能地模拟生产环境。

一般在发布一个新版本应用程序之前，新的更新必须要在staging环境下测试，这个环境也可以用来向用户展示应用效果。

预发布环境（Staging 环境，口语表达时经常变成 Stage 环境）是和生产环境最接近的一个测试环境。

预发布环境，从名字中可以看出来，它用来进行正式发布前的预演和验证。

测试环境和生产环境之间存在着某些差异，为了避免这些差异导致的缺陷漏测，预发布环境应运而生。

stage举例，支付功能

举个最常见的例子，一般在 Test 环境，没有办法测试涉及支付相关的业务功能。

虽然可以通过 mock 的方式测试整体的业务流程，但依然不能确保支付功能是可用的。

mock测试数据环境
是指例如模拟用户基于支付宝的扫码支付，测试环境下，使用的都是支付宝的沙箱支付，完全是一个假数据的平台，来测验支付程序是否正常，而不会产生真实的金钱变动；
支付宝提供的账户，余额都是假的，仅仅是是测连续连通性的。
官网地址
https://opendocs.alipay.com/support/01razc

如果此时直接发布到生产环境却发现支付功能不可用，那将是一个业务的灾难级故障。

所以，引入预发布环境可以解决此类问题，这也是它需要高度仿真的缘由。

因此在基础环境、配置方面与生产环境一致，差别主要是性能和数据存储。

• 性能：虽然预发布环境的服务器性能与生产环境性能基本一致，但主要体现在预发布环境的服务器实例数通常只有 1 个或少数几台。
• 不同的公司预发布环境略有差异，比如预发布环境使用的是生产环境的数据库备份，或者预发布环境与生产环境使用同一数据库。

如果预发布环境使用生产环境的数据库备份，则需要进行不定期的数据库同步，保持和生产环境的设置、数据一致性。

stage和prod的区别

预发布环境连接的数据库有所不同

Staging 环境的特点

Staging 环境的特点是高度仿真，它是正式发布前的最后一个环境，数据库同生产环境。对于“数据库同生产环境”这一特点来说，需要特别注意的是，对于同一条用户数据，应避免同时在预发布环境和生产环境对其进行变更。因为数据库缓存存在这两套环境中，可能会产生数据不一致等问题，且难以定位和修复。

可见，预发布环境虽然很接近生产环境，但其区别也同样明显：

• 预发布环境中新功能为最新代码，其他功能代码和生产环境一致；
• 预发布环境和生产环境的访问域名不同；
• 预发布环境一般是研发人员和测试人员使用，而生产环境是提供给真实用户使用的。

生产环境（Prod）

运维生产环境指的是软件系统正式投入使用、面向最终用户提供服务的运行环境。它是整个软件生命周期中至关重要的阶段，以下从定义、特点、组成要素、面临的挑战以及运维工作内容等方面进行详细解释。

定义

生产环境是软件系统经过开发、测试、预发布等阶段后，正式上线并为真实用户提供服务的环境。它承载着企业的核心业务，直接影响着业务的正常运转和用户体验。

特点

• 稳定性要求高：任何系统故障或服务中断都可能导致业务受损、用户流失，因此生产环境必须具备极高的稳定性，以确保服务的持续可用性。例如，电商平台在促销活动期间，若生产环境出现故障，可能会造成大量订单丢失和用户投诉。
• 数据真实性和完整性：生产环境中处理和存储的是真实的业务数据，这些数据的真实性和完整性对于企业的决策和运营至关重要。一旦数据出现错误或丢失，可能会引发严重的后果。
• 高安全性：由于涉及大量的用户信息和业务数据，生产环境面临着各种安全威胁，如网络攻击、数据泄露等。因此，必须采取严格的安全措施来保护系统和数据的安全。
• 性能优化：为了满足大量用户的并发访问需求，生产环境需要具备良好的性能，包括快速的响应时间、高吞吐量等。这就要求对系统进行持续的性能优化。

组成要素

• 硬件设施：包括服务器、存储设备、网络设备等。服务器用于运行应用程序和服务，存储设备用于存储数据，网络设备则负责连接各个组件，确保数据的传输和通信。
• 软件系统：涵盖操作系统、数据库管理系统、中间件等。操作系统是服务器的基础软件，数据库管理系统用于存储和管理数据，中间件则提供了应用程序之间的通信和协作功能。
• 网络环境：包括内部网络和外部网络。内部网络连接着企业内部的各个服务器和设备，外部网络则用于与互联网和其他外部系统进行通信。
• 数据：生产环境中的数据是企业的核心资产，包括用户信息、业务数据、交易记录等。这些数据需要进行安全存储、备份和管理。

面临的挑战

• 高并发访问：在业务高峰期，生产环境可能会面临大量用户的并发访问，这对系统的性能和稳定性是一个巨大的挑战。例如，在线游戏在新游戏上线或举办活动时，可能会出现大量玩家同时登录的情况。
• 安全威胁：随着网络攻击技术的不断发展，生产环境面临着越来越多的安全威胁，如 DDoS 攻击、SQL 注入、数据泄露等。如何保障系统和数据的安全是运维人员面临的重要问题。
• 系统升级和变更管理：为了满足业务发展的需求，生产环境需要不断进行系统升级和功能变更。但这些操作可能会引入新的问题和风险，如何确保升级和变更的顺利进行是一个挑战。
• 故障处理和恢复：尽管采取了各种措施来保障系统的稳定性，但故障仍然可能会发生。如何快速定位和解决故障，以及在故障发生后尽快恢复服务，是运维人员必须具备的能力。

运维工作内容

• 监控与预警：通过监控工具对生产环境的各项指标进行实时监控，如服务器的 CPU 使用率、内存使用率、网络流量等，以及应用程序的响应时间、吞吐量等。一旦发现异常情况，及时发出预警，以便运维人员及时处理。
• 故障处理：当生产环境出现故障时，运维人员需要迅速响应，通过日志分析、系统排查等手段定位故障原因，并采取相应的措施进行修复。同时，要记录故障处理过程和结果，以便进行事后分析和总结。
• 系统维护：包括服务器的日常维护、软件系统的升级和更新、数据库的备份和恢复等。定期对系统进行维护和优化，确保系统的性能和稳定性。
• 安全管理：实施安全策略，如防火墙配置、入侵检测、数据加密等，保障生产环境的安全。定期进行安全审计和漏洞扫描，及时发现和修复安全隐患。
• 容量规划：根据业务发展的需求和系统的运行情况，对生产环境的硬件资源和软件资源进行合理的规划和调整，确保系统能够满足未来的业务增长。

生产环境也叫 Prod 环境，Prod 是单词 Production（生产）的简写，代表正式的对外发布服务的环境，是最终用户使用的环境。

生产环境特点

生产环境有着其独有的特点，在测试过程中应特别留意：

• 真正的用户在使用的环境，不要随意在这个环境中做测试，尤其是可能产生脏数据或可能导致服务停用的测试；
• 生产环境的系统复杂度高、存储的数据量大、服务器实例数多，大量的真实用户会产生多种多样的行为，这些都可能导致不可预期的现象，尤其是在性能或异常场景方面；

• 生产环境出现问题后，无论是定位还是解决问题都需要权限，通常需要特定的人员来操作，影响工作效率；

• 线上测试

线上测试有很多成熟的实践，比如业务逻辑灰度、A/B 测试等。

负载均衡

业务逻辑灰度发布是在新发布一项业务功能时，先只开放给一小部分（比如 5%）用户使用，使用一段时间反响较好或未出现缺陷时再逐步开放使用比例，重复这一过程，直到向所有用户开放使用。一般情况下，业务逻辑灰度适用于发布特大功能、重大的架构改造或发布容易引起用户投诉或舆情的功能等情况。

A/B 测试主要用于产品功能或算法策略的对比，版本 A 和版本 B 分别部署在不同的服务器上并开放给不同的用户使用，一般适用于收集用户反馈或行为数据来辅助产品功能设计。比如对比两种营销策略对用户留存的影响、对比两种推荐算法策略的优劣，等等。

• 线上监控

除了上述测试内容外，还需要针对生产环境进行业务和技术监控，对生产环境的数据和日志等进行分析，旨在前置发现质量风险，暴露问题。

生产运维架构图展示

终端数据上报

服务器分布、网络规划

服务器分部署、网络规划

物理机、虚拟机数量规划

咱们学习期间就属于是test测试环境

• 服务器给的配置较低
• 以学习、测试使用各软件功能为主
• 程序运行后也无用户访问，可以让你的同学当做你的客户端用户，测试网站功能

入职后的首要任务

无论是运维、开发、或是测试，入职后接到的第一个任务就是看文档，你需要先熟悉新公司的业务，以及该业务涉及的技术。

• 技术都是相通，类似的，你在前东家用centos7，新公司也一样是centos7；
• 你在前东家用LNMP技术维护零售电商系统，新公司是维护爱奇艺APP系统后台，也一样会用到nginx、mysql、python/php/java的部署，调试

• 只不过你跳槽后，工资涨了5k，你要学的东西也肯定更多了，也要对得起这多出来的每月5千块

• 前期看文档，熟悉业务，学新技术会累一点，熬过艰苦的试用期，转正后，业务熟了，技术也会了，后续就是维护、迭代更新，喝喝咖啡摸摸鱼。

• 直到你下次有了跳槽的想法， 比如参加了一次同学聚会，发现，我靠，这小子以前很菜啊，现在挣这么多？回家闷头开始学习、打开于超老师的b站，开始跟超哥学python运维开发。（哈哈，猝不及防的广告）