# LLM 大模型对软件行业影响

类似 CopilotX GitHub Next 等代码辅助或 ChatGpt 等 LLM 大模型相关产品现在主要左右还是知识平权减少普通人获取知识成本部分代码生成及辅助功能会小范围冲击基层程序员就业

但对于软件工程全流程的需求沟通需求确认妥协代码架构设计及基础设施设计等短期内别无法代替业务专家职位永远无法替代 AI 减少了软件工程最后一英里的工作量

暗知识：LLM 始终是理解人写出来的代码而想的永远比说出来的多说出来比写出来的多而理解也会比写出来的会打折扣

# B 站混部 HPA VPA 等相关落地

混部：即线上用户业务与离线业务 Job 共同部署在一个物理节点运行充分利用 CPU Memory 资源降本增效使用 kubelet 去拉取 pod agent 上报的实时指标并反馈给指标 Controller 做分析对比结合 kube-schedule 做相关副本数量调整

主要实现方式：对于内部指标做预估在线上业务低峰期时在线上集群运行部分离线计算 Job （CPU 视频转码及大数据处理）提高资源使用率并且不影响线上 SLO 稳定分优先级对业务混部做干预用 cgroup 做 Pod 业务隔离防止干扰重要线上业务

GPU 混部：CUDA API 做 GPU 资源预测将线上训练任务和 NVIDIA CUVID FFMPEG 编解码加速任务做混部训练任务预留 1-2GB 显存资源为编解码任务预留资源

HPA ：主要是会对部分实时指标做分析如上游服务的 CPU QPS 等然后做动态扩缩容

CronHPA：对阿里的 CronHPA 做了改进对于历史指标做分析而不是单独的去按照日常规则直接扩缩容防止部分不定时的业务高峰或闲时资源浪费

VPA：自己根据实时指标实现了动态资源 request 调整显著提高了资源利用率

1）路由：不使用前缀匹配方式指定到接口级别效率高在一定程度上从指标阶段能减少外界扫描干扰但存在问题需要自行开发控制台 panel 隔离部门及业务避免路由过多难以配置的问题

2）负载均衡：使用 P2C 方式依赖简单的单独的一个指标实现效率及可用性远大与 RR 及 WRR 方案

3）服务降级熔断：根据指标进行降级减少影响面服务完全不可用部分请求用会启用兜底的历史请求避免用户完全不可用 Qurota 分布式限流方案即通过有状态的一个容量池下发每一个 pod 接口的限流容量 pod 本身根据自身的限流上线去做限流熔断避免 redis 等分布式方案打爆的问题

4）grpc 管理：protobuf 文件使用统一 git 仓代理保存并使用统一的 protobuild 方式保证文件统一

整体比较简单易懂但 ELK（面向运维）和 Loki（轻量效率高面向开发）日志方案做混用各司其职减少 ELK 资源占用概念比较新颖

主要是社区宣传及介绍对于个人理解还可以 eBPF 相关 ServiceMesh 可能在未来会有巨大变革

1）测试与开发需要注重问题与开发部门挂钩在软件开发阶段及测试阶段由开发人员及测试人员共同推进问题 mapping 图多次积累在不同项目中共同使用提高测试效率及问题沟通效率

适用于当前所有的软件开发及测试以下为实例

问题描述	漏洞等级	涉及部门（多级）	修复及改进方案

2）软件质量部门监督软件开发及测试并推进内部敏捷开发定期开质量效能会议对整体软件交付有良好把控推进包括但不限于以下方案

tools：所有研发部门利用 copilot x 等代码生成工具生成自己代码的覆盖单元测试记录接口测试脚本并集中提交至指定 git 仓库进行统一维护

codereview：在 preview 由专人对 feature 及 bugfix 相关代码进行 codereview

owner 意识：质量左移即自身对软件漏洞做把控不允许完全将软件质量问题交于测试部门兜底对其他部门零信任在软件交付用户前对质量问题阻断

例如云端依赖 Devops 、多环境灰度、自动化、指标报警、相关 SRE 、对于指定问题指定人员解决（专人专办）owner 自身问题推进其他部门将软件交付测试前阻断风险的意识

3）自动化测试介入

在测试阶段，需要多部门联动自动化测试对相关 case 进行自动化覆盖包括但不限于 python 脚本 UI 脚本可以考虑由 AI 工具生成 Monkey 测试方案进行覆盖由一般测试人员录制自动化测试脚本并在多次回归测试利用脚本中提升效能

4）开源软件漏洞跟踪

各个部门对自己代码中使用的开源软件及版本进行记录梳理开源软件由软件质量监督部门跟进 CVE 相关漏洞问题避免出现类似 Log4Shell 相关零日漏洞造成的巨大影响

5）对部门及个人质量效能评分

部门将自己的质量及效能提升落地情况定时反馈拒绝低效研发及测试