企业中项目需要完成 需求理解 → 数据建模 → 接口设计 → 权限控制 → 代码分层 → 错误处理 → 日志监控 → 测试 → 部署 → 维护 → 迭代开发 链路的闭环
其主要保证产品的功能稳定（测试），项目可维护与可拓展（开发）
网络上的一些课程其实缺少了对真实需求的把控，而是从设计与编码角度来进行。而没有从产品，测试，运维视角进行展开。

前期：

• 前期产品需求分析
• UI设计
  中期：
• 数据库设计，接口设计（错误码规范：对内/对外）
• 编码实现（日志记录，埋点统计）
• 测试
  后期：
• 项目部署：多环境部署
• 项目维护：日志、监控和排障能力
  后后期：
• 产生Bug反馈/新功能需求->重新进入产品需求调整完成闭环，最终实现迭代开发

实战分析

需求分析

产品提出了一个登陆的需求，要求用户通过邮箱，密码，验证码登录
从开发角度我们就可以延伸出很多系统功能需求：
比如：
前端参数校验？密码加密方式？用户id生成方式？邮箱服务器是自建还是用第三方？如何防止用户重复登录注册？防止机器人批量登陆注册是否需要图形验证码等方案？恶意登录是否限制次数？安全风控异地登陆？
这其中就产生了一大堆隐藏性的非功能需求，而显然如今大部分教程中预设较死（考虑到学习坡度），与企业真实场景脱节。
ps：其中产品提出天马行空的需求，开发进行技术可行性分析，与之进行博弈也是属于真实企业开发的一部分

数据建模

为什么对于一个简单的注册登录功能设计一个用户表需要的字段要比实际功能需求要多
可能对于一个用户表，在当前只有登陆注册需求下，只需要用到用户id，用户名，邮箱，密码字段，但是在建模前我们还需要考虑到未来潜在的业务需求，提前进行预测，比如说用户个人资料的展示，是否还需要头像，昵称等？对于 后期 数据的审计是否还需要增加注册时间，登录时间字段，便于后面运营查看用户的活跃度？是否还需要新增封禁字段，最近登录ip字段，以便于后期账号风控的需求拓展？

规范接口

对于团队来说，特别是前后端分离开发，接口规范十分重要。不过对于线上教程，因为都是一人团队很多自己都是想到哪写到哪。
什么是规范的接口？就是团队指定一个接口规则文档，所有人按其办事，不专断独行。

异常处理与恢复

我们可以将异常分为下面两种情况

• 业务异常：业务规则不满足，系统预期内可处理（密码不正确）
• 程序异常：系统自身运行出现问题，偏非预期

任何事情不能保证十全十美，程序在运行是也是一样，在任何时候都要保持对异常的敏锐。
即使你写程序能保证100%不会出现Bug，也不能保证异常不会发生，因为异常不仅有Bug等内部原因，还有例如网络等外部原因。所以将失败后流程处理做到尽善尽美也是达成“企业级”开发的必经之路

案例：
以视频平台转码功能为例，现在一个视频多达几百兆字节，不可能同步处理，需要将他专门的放入处理线程处理/处理服务器进行处理。在数据建模阶段，我们就需要专门设计一张转码任务表来保存视频处理的流转状态字段，设计等待中、处理中、成功、失败、可重试等状态

视频失败可能是因为下面几种原因

1. 用户上传的文件本身有问题（文件损坏）
2. 系统资源问题（系统压力太大）
3. 网络原因（消息队列问题）
4. 代码或配置问题
   上面情况都有可能发生，因此我们需要建立一个日志/告警机制来让我们提前发现/事后补救

如果视频转码失败，肯定需要进入异常处理流程，系统需要进行如下操作

• 更新转码任务状态为失败。
• 记录失败原因。
• 保留原始视频文件。
• 通知用户或前端。
• 提供重试机制。
• 区分“用户文件问题”和“系统临时问题”。
• 必要时通知管理员或运维。
• 避免任务无限重试。

当然对于不同原因，我们需要进行的操作也不同，我们将失败分为下面两类

• 可重试失败：系统资源、网络、对象存储、临时进程失败
• 不可重试失败：文件损坏、格式不支持（上传阶段可解决）

有了上面这一套流程，我们就会发现对于视频转码功能的建模就不能仅局限于设计一个视频表这么简单了，还需要设计转码表记录转码状态，失败原因以及重试次数等字段
我们可以考虑使用状态机来进行设计整套流转流程

而对于错误码设计，需要提供一套对内的错误码和对外的错误码，将内部错误反馈给内部团队，对外错误返回给给用户

INVALID_VIDEO_FILE  
用户提示：视频文件无法解析，请重新上传  
是否重试：否  

STORAGE_UPLOAD_FAILED  
用户提示：视频处理暂时失败，系统将自动重试  
是否重试：是  

FFMPEG_TIMEOUT  
用户提示：视频处理超时，系统将自动重试  
是否重试：是

日志监控

其用途如下所示：

• 第一种是定位错误。比如转码失败、数据库报错、接口 500。
• 第二种是追踪流程。比如一次上传从开始到结束经过了哪些步骤。
• 第三种是性能分析。比如上传耗时多久、转码耗时多久、数据库查询耗时多久。
• 第四种是安全审计。比如谁在什么时候登录了、谁删除了视频、谁修改了权限。
• 第五种是线上排查。本地能复现的问题很好查，最麻烦的是线上偶发问题。日志就是你还原现场的唯一线索之一。

既然日志这么重要，那我们如何充分利用它，完成对故障的排查与系统的优化？
那就是建立一套完整的链路：应用负责产生日志，日志采集器负责搬运日志，日志平台负责存储和检索，监控告警负责发现异常

1. 首先我们要建立一套存储设施，将日志保存起来，服务器需要将日志写入到文件，文件一般按日期进行分割，并且根据类型级别区分，在linux中我们可以利用logrotate实现日志轮转
2. 服务器集群场景下，我们还需要将每台机器的日志采集起来通过管道送到日志存储库，通过进行快速搜索、按时间保留、聚合分析等
3. 最后，所有数据在可视化观测平台中呈现

现如今已经有较为成熟的日志管理系统方案，例如

• ELK（Elasticsearch、Logstash、Kibana）
• EFK（Elasticsearch + Fluentd / Fluent Bit + Kibana）
• Loki：Promtail / Fluent Bit + Loki + Grafana

当然云厂商也提供了一套解决方案，我们可以不用自己维护日志集群，虽然开箱即用，但是灵活性不高

下面是不同方案的对比：

当然上面的内容，大部分是运维需要关心的，而后端要做的是编写日志代码，设计好业务状态，并暴露健康接口给运维，协作完成整个流程

DevOps

DevOps是将开发与运维结合的思想，他需要保证开发与运维交付链路的稳定
首先来看看引入这个思想解决了什么问题。由于开发运维的职责不同，容易扯皮出现，以下情景：

开发：我代码在本地能跑，发给你了
运维：你这个依赖没写清楚，线上跑不起来
测试：这个版本到底部署的是哪一份？
产品：为什么修个小 bug 要等三天才能上线？

DevOps的核心是CI/CD，即持续集成/持续部署交付
为了更好理解，我们以前后端开发举例

在没有 DevOps 流程时，前端项目的部署通常依赖人工操作。开发者需要先在本地执行 npm run build 生成 dist 目录，然后手动压缩构建产物，登录服务器，把文件上传到指定目录，再根据情况重启或重新加载 Nginx。部署完成后，还需要自己打开线上页面检查资源是否正常、页面是否白屏、接口是否可用。整个过程虽然不复杂，但非常依赖个人操作经验，任何一个环节出错都可能导致线上问题，比如上传错目录、漏传文件、缓存没有刷新，或者部署了错误版本。

而引入DevOps后，开发者只需要把代码提交到指定分支，例如 main 分支，后续流程就可以由 GitHub Actions、GitLab CI 或 Jenkins 等工具自动完成。流水线会自动安装依赖、构建项目、运行测试，并在构建成功后把产物发布到服务器、对象存储或 CDN。如果中间某一步失败，系统会终止发布，把失败信息通知给团队。
后端则相对复杂。代码提交后，CI 会自动编译项目、运行单元测试，然后构建 Docker 镜像并推送到镜像仓库。在线上环境中，Kubernetes 可以根据新的镜像版本执行滚动更新，让服务逐步替换为新版本，而不是一次性全部重启。更新完成后，Prometheus、Grafana 等监控系统会持续观察接口响应时间、错误率、资源使用情况等指标。如果发布后错误率突然升高，系统可以及时告警，甚至配合自动回滚机制把服务恢复到上一个稳定版本。

埋点统计

埋点统计一般在产品中的一些关键地方统计用户的行为数据，以此来分析
例如我开发了一个新功能，但是根据埋点数据统计出这个功能没有人用，那么就需要分析是不是功能入口设置太深/不明显。
如果是对于一套流程走下来的工具网站，可以在各个步骤进行埋点，统计用到最后还剩多少人在使用你的产品，根据留存率进行优化。
在现在产品应用如此之多的时代，一些用户不会因为你的产品不行而给你提反馈，而是直接换一个产品使用。