devops背诵手册

什么是

  • Dev：Develop（开发）
  • Ops：Operation（运维）
  • 有什么作用：打破开发、测试、运维、壁垒；自动化；降本增效

专题1：运维与Devops方法论

背景助理解

项目名称

御姐加油站

功能

  1. 用户的登录和注册：用户使用微信扫码关注公众号登录，并且通过微信或者支付宝充值39.9元可以升级为会员。
  2. 上传御姐资料：上传每个网红或者身边的美女的照片、个人经历、获得成就、专辑名或者参演的影视剧类节目名称。
  3. 发帖跟踪御姐的事件：会员用户能够将每位御姐的事件进行发帖，登录用户能够进行点赞评论、并能回复、点踩举报评论和帖子。
  4. 模拟和御姐聊天：通过后端接入大模型，根据帖子、资料持续学习御姐的个人事迹来模拟御姐的人设、并且可以和御姐语音通话，普通用户可以每天20句对话和10min的语音通话，会员每天对话数量无限，并且可以打3小时的语音通话
  5. 管理用户：管理员通过管理后台注册，可以审核举报内容，并且能够选择将相关用户封禁

体系架构

  • 后端：基于微服务的架构：公司有三台腾讯云的服务器（每个6CPU32G内存），使用docker swarm管理由Go语言、Java、Python写的几个微服务镜像，并使用API网关统一对外服务（有公网ip，但不考虑CDN加速），现在公司还没有讨论怎么划分微服务
  • 云数据库：使用腾讯云的MySQL、Mongo和Redis作为后端的数据库（假设容量足够）
  • 对象储存：使用腾讯云COS服务（假设容量足够）
  • AI服务：假设大语言模型对话服务、RAG服务、语音转文字、语音合成服务都由另外一家公司B提供，B公司也提供了工作流定制的服务，即调用B公司的上传API，就可以将文件传输到对应客户工作空间的知识库里面，这样便可以在调用B公司的大语言模型聊天服务的同时先进行知识检索，并结合提示词一起回答，语音通话则是用户在前端打开一个webrtc通道连接到B公司的服务器，上面的服务器先将用户传输过来的音频流转化为文字，然后送入前面提到的AI chat completion服务，如果大语言模型生成一个chunck，则将其送入语音合成服务，再将合成的音频片段顺着原来的webrtc的通道传输，调用语音通话API只需要通过HTTP接口指定后端大语言模型，并获得一个加签，前端通过携带加签，则可以和B公司的语音通话服务进行信令传输并打开RTC通道
  • 管理后台服务：部署在公司内网集群中，并且通过公司内部的oauth2.0决定操作权限，仅限公司内网访问
  • 监控服务：使用gafrana大屏进行监控，部署在公司内网集群中，但是通过路由可以外网访问
  • 持续集成：代码托管和流水线运行在腾讯云coding的平台上，而构建节点采用公司内网的虚拟机
  • 前端服务：前端用vuejs写，托管在github上，提交master分支的仓库则触发关联的cloudflare pages自动构建，并部署在cloudflare pages服务商

开发方式

  • 前端代码托管在github上，如果提交master分支，就触发其部署到cloudflare pages上面，如果提交dev分支，则只触发代码质量检查
  • 后端代码托管在腾讯云coding上，每个微服务分为一个仓库，提交仓库，则触发单元测试和集成测试，然后构建对应的docker镜像，如果是dev分支，则其会触发其后续部署在公司内网的模拟测试环境（使用内网数据库和minio作为对象存储服务），如果是master分支，则会先将其推送到公有云docker仓库上，并且通过ssh命令暂停正式发布服务器的对应微服务重新拉取并更新再重启服务。
  • 团队使用钉钉进行远程会议、消息交流，并且流水线触发、代码提交情况会被发送到对应的群里面

进一步计划

  • 响应国家「西数东算」政策的号召，公司在甘肃兰州建立了一个机房，其总共服务器能够提供512核心和10T内存以及100张4090的GPU算力、并且拥有三个独立的公网ipv4，公司于是想着把服务迁移到k8s上，并且对于AI运算和推理的服务，已经通过和B公司商量好，由B公司的私有云平台提供Webrtc传输、GPU算力调度、大模型推理的服务，到时候以一个机房局域网微服务API的形式给出（格式和B公司公有云服务一样）

摩尔定律和反摩尔定律

  • 价格不变、18-24个月、性能一翻
  • 卖掉相同、18月、营业额一半

历史沿革

  • 软件的架构几个阶段：单体架构、分层架构、SOA、微服务架构、Service Mesh架构
  • 2009：Patrick、类比敏捷开发、提出Devops、第一届Devops大会
  • 2013：《凤凰项目》（什么是「凤凰商城」、遇到了什么问题、如何解决、启示是什么？）
  • 2018：中国Devops社区
  • 2023：南京大学主导的Devops国标

3 Ways

System Thinking：熟悉流水线、提高流水线流量、为了目标实现工作流优化

  • 怎么做：构建、集成、交付；限制半成品（半成品商榷后再发布）；看板

Amplify Feedback Loop：加强用户的反馈、从源头保证质量、避免问题再发生

  • 怎么做：适当停止生产线、构建自动化测试套件、Dev和Ops共享target和pain、远程监视

Culture Of Experimental and Learning：培育「试错文化」

  • 怎么做：20%非功能；鼓励强化改进；营造~的企业文化氛围

4种项目

  1. 业务项目：主要的、公司项目管理办公室管理
  2. 内部项目：改进的运维基础架构、运维项目内部改进项目、不集中跟踪管理、瓶近期投入不易估量
    1
    e.g. 为了能够更好的管理迁移到甘肃的服务，IT团队开发出了四种云原生运维套件：S***a集群管理工具、Sasablue算力调度和推理引擎、M******e消息队列、L***a服务发现，并像Kafka、Etcd一样开源成为下一代的云原生基础设施
  3. 变更：由1和2衍生出来的，问题跟踪管理、多套系统管理（一个问题影响到另外一个问题）
  4. 计划外：故障处理

精益生产和devops：传统精益和devops同原理

精益（精益求精）理论

  • 降低批量规模：对于「御姐加油站」每个功能的子功能划分多个版本逐步上线，便于发现问题
  • 减少半成品（对应Devops三种方法的第一种「控制半成品给数量」）：语音聊天功能完善了再上线而不是一下子就上线
  • 缩短并增强反馈回路（对应Devops三方法的第二种）：聊天的时候设置直接在生成内容下面设置「点踩按钮」

敏捷开发与devops：借鉴敏捷宣言

敏捷宣言

  • 个体和互动大于流程和工具：开发过程中面对面交流大于飞书钉钉看板
  • 工作的系统大于详尽的文档：演示功能使用大于写一大堆文档让你读
  • 程序员和用户的合作大于合同谈判：「加油站」会员价格和政策更多倾向于用户的感受而非用户合同
  • 响应变化大于遵循计划：响应「东数西算」政策，程序员不得不改变原来docker swarm的架构，迁移到甘肃机房的k8s上

Devops的工具（以e.coding.net为例）

  • 源代码管理：代码托管
  • 构建服务器：coding的持续集成可以选择使用构建集群或者自己接入节点
  • 基础设施、环境配置管理：coding支持接入裸机、k8s、serverless、cos等
  • 虚拟基础架构和容器：docker作为容器引擎，由腾讯云的服务器或者自接入节点提供虚拟化的基础架构
  • 测试自动化：使用ifbook可以实现api和自动化测试管理
  • 管道编排：可以定制自动化工作流

关键术语

CI/CD

  • 持续集成：开发者持续的将代码集中提交到一个中央仓库里面，并且每次提交都触发自动构建和测试，以早发现问题
  • 持续交付：快速的、少浪费的将代码部署到生产环境，便于用户和开发者建立更强的反馈（对应devops三方法第二点、精益理论第三点「缩短并加强反馈回路」）
  • 持续部署：快速的部署并将变化立即能够让用户看到（cf-pages在提交前端代码以后立刻可以部署到全球网络让使用者看到前端页面变化）

四大指标

部署频率、变更进入生产时间（t0部署-t0提交）、平均恢复时间（MTTR=AVG(t0恢复-t0-部署)）、改变失败率

A/B 测试

变更后和变更前的测试

Scrum

三个角色（不要合并Owner和Scrum Master）

  • Product Owner：唯一有权要求做事、改变列表优先级；最大化产品和团队的价值
  • Scrum Master：确保Scrum被理解和实施、充当教练
  • Team：开发团队
  • Out Of the Team：把有兴趣关心，并无利益或价值牵扯的人（其他部门、高管、「御姐」群体），排除在项目决策团队以外！

用户故事

为什么

  • 完美文档的缺陷：低共识
  • Story和task

Story是用户需求，可以共享，每个人的Task为了完成Story中提出的需求，Task是具体开发任务，不共享，每个人完成各自的（用户能够和御姐聊天是Story，而将知识库接入LLM以更好的模仿御姐的个性属于Task）

用户故事的模板

1
2
3
作为xx用户
我想xxx
以达到xxxx的价值

e.g.作为管理员，我想查看被举报的内容及其创作者，并能够决定是否封禁其账号，来维护这个网络社区的氛围

3C原则

Card（占位符）、Conversation（为了达成共识、实时交谈）、Communication（接受标准：我们知道他何时完工）

产品Backlog：Scrum的核心

用户故事重要性列表排序

Scrum的工作流程以及要素

  1. Scrum会议
  • 目标：以终为始
  1. 估算
  • 单位：Story Point；SML（T恤尺码）
  • 差异原因：对于需求的理解、对于技术的熟练度
  1. 白板

要素：Not Checked Out、Checked Out、SprintGoal、Unplanned Items、Next
4. 燃尽图

  • 需要完成、还剩多少、现在速率是否能达到
  1. 每日站会
  • 移动看板的任务、更新燃尽图
  1. Sprint演示
  • Sprint结束于演示
  1. Sprint回顾会议

看板开发核心要点

  1. 可视化工作流程，Kanban方法：提高信息辐射的作用，容易发现团队工作的状态和问题、降低沟通交流成本
  2. 限制在制品（WIP上限，超上线阻塞）：减少在制品使其快速流过整个工作流，使前置时间缩短（对应3方法中的第一点「提高流水线流量和流通效率」、与Devops指标中降低「变更进入生产时间」类似）

专题2：云原生时代的基于微服务的新型DevOps

背景助记

为了响应「乡村振兴」的号召，asynchronous公司与腾讯、字节、大疆联合推出了一款「无人机云乡村」服务。

客户和需求

  1. 乡村企业或者政府委会等：订购服务然后asynchronous公司能够将一个具有8*4090、512G RAM、256Core算力的中控AI服务器（边缘盒子）以及配套的无线电控制递送到乡村，并且由无线电装置由边缘盒子操控无人机进行作业，中控AI服务器在安装asynchronous的服务以后，就连接到asynchronous的云服务，借此可以从服务市场中拉取以docker-compose为组织的一组微服务应用如无人机农业、无人机云游等服务，连接上asynchronous的服务的边缘盒子也可以将无人机画面进行抖音或者微信视频号直播，也可以通过asynchronous的服务（底层为腾讯云的实时音视频、物联网）开启网页端异地操控，也可以将无人机的画面和控制权转移到线下体验店，让用户通过VR操控无人机，无人机将自身多模态数据由无线电传输到边缘盒子，边缘盒子进行处理调度无人机的任务，当然无人机内嵌基础小模型来操控其基础的避障、移动功能
  2. 客户可以通过微信视频号和抖音观看无人机直播，客户也可以在线下体验店操控无人机进行无人机云游。
  3. 服务开发者：asynchronous公司为服务市场开发者提供开发平台，实现持续集成、持续构建，使用腾讯云部署的NVIDIA Issac Sim模拟测试，然后进行发布

故事场景

山西省有一个山村处于深山之中，当地村委会为了更好的保障村民的安全，则决定引进系统派遣无人机定期巡查村庄，通过多模态数据来检测村庄基础设施的安全隐患并适当记录村民及外来人员的行动行为，村庄管理者可以通过web和安卓或者ios app实时查看无人机的画面，并看到大模型发现的隐患问题描述

一家位于北京的初创公司收到了上述村庄的需求，并与「无人机乡村云」平台的应用市场沟通，成为签约开发者，为山西的村庄开发一个「无人机应用」，其在开发的过程中，完全使用了asynchronous公司为服务市场开发者提供的集成代码托管、持续集成、制品仓库、持续测试、持续交付等为一体的开发者平台

云雾计算 XaaS

  1. 云雾计算
  • 云计算（腾讯云和字节的服务）：数据能力强、高延时、用户隐私难以保护、高能耗
  • 边缘计算（无人机的本地模型）：与云计算相反
  • 雾计算（边缘盒子）：解决边缘计算数据抽象、命名规则、异构问题
  1. XaaS
  • PaaS和SaaS的区别：PaaS数据和应用层由企业自己管理，反之由平台托管

e.g.视频号直播为SaaS；而腾讯音视频直播sdk属于PaaS

IT服务五标准

  • CMMI-SVC：五个等级
  • ITIL：信息技术标准库
  • ISO20000：国际标准、PDCA
  • ITSS：一套完整的

运维的转型

  • 互联网时代：快速迭代、发布、灰度发布、安全
  • 云计算时代：系统本身、基于云计算的应用、自动扩缩容
  • 大规模：标准化、智能化、智能化
  • 「提前运维」：将运维提前至产品开发阶段

运维的挑战

多层次、海量数据、异构系统、动态变化、服务数量庞大、调用复杂

什么是云原生

基于Devops、微服务、方法论

容器化

实现原理

  • 使用linux的namespace机制进行隔离
  • 使用cgroup来限制计算资源
  • 运行进程都是实打实的linux进程
  • 打包了运行所需要的一切依赖库和资源

与虚拟机的不同（相同部分省略）

  • 启动时间：容器是秒级、虚拟机是分钟级
  • 虚拟化规模不同：容器可以和宿主机共享所有资源，而虚拟机则需要宿主机模拟出一套完整的硬件操作系统
  • 占用资源量不同：容器是轻量级，一个宿主机可以运行上千容器，但是最多只能运行几十个虚拟机

Docker

  1. 引擎：Docker引擎是一个客户端服务器架构
  2. 储存：Dockerfile所构建的镜像层都是只读的，但是在运行的过程中，添加了一个读写层，则可以写入镜像（对于镜像本身没有影响）
  3. 网络：
  • bridge模式：内部ip地址，网桥联通
  • Host模式：使用主机网络
  • Container模式：一个容器有自己的网络空间，另外一个容器使用这一个容器的网络（使用网络密集型）
  1. 驱动：
    直接使用DeviceMap（思考：开发无人机应用，如果镜像要直接访问无线电设备的串口，怎么使用？答案：DeviceMap）
  2. RUN、CMD、ENTRYPOINT的区别
  • RUN：构建镜像的时候，安装环境所需要的命令
  • CMD：指定启动的时候的参数和命令，可以被docker run命令行参数来覆盖，多一个CMD，则被最后一个覆盖
  • ENTRYPOINT：指定启动的时候运行的命令，不容易被CMD修改
    1
    2
    （这题我也错了）假设a.sh运行输出A，b.sh在没有参数'arg'的时候输出B，arg为1的时候输出C，否则输出D
    根据下面的情况来判断程序的输出，如果报错则指出错误原因
    a.ENTRYPOINT不能被覆盖，CMD将作为参数传给ENTRYPOINT
    1
    2
    ENTRYPOINT["a.sh"]
    CMD["b.sh","--arg","1"]
    1
    docker run image:tag
    1
    C
    (相当于运行a.sh b.sh --arg 1)

b.多CMD覆盖，运行最后一个

1
2
CMD ["a.sh"]
CMD ["b.sh"]
1
docker run -it image b.sh --arg 1
1
C

(相当于运行b.sh --arg 1)

c.炼狱难度

1
2
ENTRYPOINT ["b.sh"]
CMD ["a.sh","--arg","1"]
1
docker run -it image b.sh --arg 2
1
D

(b.sh b.sh --arg 2)

编排和调度

docker-compose和swarm

基于compose文件和gossip

k8s

  • etcd用来干什么：储存状态数据
  • kubelete：完成容器管理
  • Pod是什么：最小调度单位，只有一个ip，包括储存和网络的紧密的容器
  • 避免Pod被调度到特定节点上：taints、tolerations
  • ingress的作用：让外部能够访问集群
  • service有哪四种类型：ClusterIp、LoadBalancer、ExternalName（指向集群外部的域名）、NodePort
  • kube-proxy的作用：负载均衡器，用于service的实现

微服务

软件架构的演化

  • 单体架构：单体、统一部署、高耦合、统一数据库（好更新、易于部署）
  • 分层：软件抽象和分层、初步MVC架构、统一数据库
  • SOA：依赖消息总线、通信开销大、重量级服务、统一数据库
  • 微服务：解耦和、去中心化（独立开发）

特点

  • 服务组件化：智能无人机治安可以分为多个服务组件：比如无人机操控、画面AI推理、权限管理、日志记录等组件

这样的话，不仅可以独立开发和维护每个微服务部分，公共组件也可以其他微服务调用，其实「Service Mesh」概念就是从这里面来的，就是形成一个网格而不是简单的依赖树形关系

  • 围绕业务组织能力：传统更关注技术（Spring比netty进步的地方）
  • 高內聚低耦合（高内聚：模块或类内部的元素紧密相关，且专注于完成单一功能或任务；低耦合：模块之间的依赖小、独立性强）
  • 去中心化：数据管理、数据储存、服务治理
  • 基础设施自动化
  • 服务设计和演进（高可用设计和演进设计）

使用原因

  • 高可伸缩
  • 每个服务相对较小好维护
  • 技术栈不受限
  • 服务可以独立拓展
  • 大型复杂程序可以持续部署交付
  • 什么适合：规模大、复杂度高、需要长期演进

微服务拆分问题

1
2
3
4
5
6
7
8
【补充问题背景】
边缘盒子里面裸机运行了一个asynchronous-worker进程，通过这个东西可以接受无人机返回的图像、给无人机发送指令，也可以直接与云端的asynchronous服务通信
边缘盒子操控无人机通过「动作序列」实现，动作序列即在无人机上运行的一系列顺序动作的循环，使用状态机的方式进行执行，提供切入状态的回调、循环执行的任务、切出状态的回调，比如跟踪某个目标、按照某个航线运行等，动作序列的计算在无人机自带的机载电脑上面计算运行
而边缘盒子可以通过无线电将「动作序列」注册到无人机上，docker应用程序通过挂载特定的socket来调用worker查询无人机状态、调用云端asynchronous的服务、通过无线电让无人机执行特定的动作序列
边缘盒子对于无人机的操控采用两个模式：
一个是事件响应模式，如果无人机发生一些状态的变化（检测到一定特征的物体、上一个动作序列执行完毕）或者系统自身状态发生变化，则触发事件，这个过程是通过在docker中的应用程序，通过device-map挂载裸机的async-api-socket来实现
另外一个是轮询模式，docker容器挂载图传虚拟设备来拉取无人机的媒体流，再进行逐帧或者抽帧处理
不考虑第二种模式，假设这个安保程序在无人机机载电脑上的小模型发现了危险的特征，通过事件触发的机制通知到对应的docker容器内，其中基于事件响应的无人机应用程序，启动的时候会开启两个线程，一个线程非阻塞的处理REST或者RPC请求，另外一个线程非阻塞的处理无人机的事件
  1. 关键：
  • 粒度：过粗无法独立运维扩展；过细增加通信开销
  • 职责：职责分配不当则增加开销
  1. 原则
  • 单一职责（低耦合）
  • 服务依赖：核心、非核心（不要依赖核心）
  • 服务自治：独立团队开发维护
  1. 拆分策略
  • 基于业务功能
  • 基于数据模型
  • 基于非功能因素（IO密集型）
  • 基于DDD
  1. 根据问题背景的微服务拆分
  • 无人机管理：获得无人机的活动数量、位置等（核心、IO密集）
  • 任务调度：控制无人机进行完成特定动作序列（核心、IO密集）
  • 事件处理：处理无人机发来的事件 （核心、IO密集）
  • 数据处理：将音视频、点云图等多模态数据放入多模态大模型进行处理（核心、IO密集）
  • 用户界面：村委会、技术人员管理系统
  • 监控日志：记录和保存安全隐患事件和系统事件
  • 认证授权：村委会、运维人员认证
  1. 开发（以事件处理微服务为例）
  • 开发模块：模块能够通过得到订阅的事件，然后通知数据处理拉取对应媒体流，得到处理结果以后，按照编写的事件处理程序，给出下一动作序列，通知任务调度微服务让无人机进入下一个动作序列
  • API文档管理：显然这个模块要设计一个tcp-socket API，接受无人机传来的事件
  • 对外暴露API：暴露上一个的事件API的格式，便于设计无人机如何传入事件进行调用
  • 整合管理端：接入无人机管理的服务，方便进行全局无人机考虑