docker网络转发路由模型
前叙docker是目前容器服务最常用的containerd上层构建，其docker工具链调用containerd底层实现容器调度和管理。在日常的使用环境中，docker常用四种网络模式：
1、br模式：通常dockerd在拉起时，会在linux系统中生成一个叫docker0的虚拟网卡，这个网卡的ip通常是172.19.0.x，这个网卡不被绑定到任何物理网卡上，所以也就不会进入物理冲突域。在使用br模式时，生成的容器和docker0网卡使用同段ip，以docker0作为网关，流量经过iptables后转发进入外网，或者说流量从物理网卡进入后流量经过iptables转发到docker0后转发到对应目的地址。也就是在默认情况下，出向和入向流量链路大体是对称的。
2、Host模式：容器直接复用宿主机网络，不同容器使用的是同一个ns，也就是不同的容器必须使用不通的端口，否则会冲突
3、None模式：无网络模式，这个直接就是字面意思，没有分配ip，也没有网络，用的地方比较少
4、overlay模式：跨机通信会经常用到，主要用VXLAN实现
这里还经常会用到一种特殊的网络模式：
5、MACVLAN: ...
supervisor子进程oom导致supervisord进程退出问题排查
背景这个问题出自一个线上故障。uwsgi进程查询数据库内容过大导致进程oom，同时supervisord进程接收到一个退出信号后进行优雅退出。因为supervisord进程退出所以uwsgi进程没有被重新拉起导致业务故障。
架构说明
本次故障主要涉及项目中心服，中心服用到的技术栈为python3.11+uwsgi+mysql+mongo+redis，中心服由两个进程构成。uwsgi作为中心服的api接口，也是用户访问的主业务入口，push服务是一个异步推送服务，主要为用户推送信令以及处理一些异步指令。这两个进程都由supervisor进程管理，supervisor以apt方式进行安装。
现场描述uwsgi服务发布了新的版本，新增了评论检测功能（6月4号，历史原因，说不得）导致mongodb查询量剧增，查询结果超级大，之后uwsgi服务和push服务以及supervisor服务全部异常退出（不难想到是oom导致的进程被kill），nginx仍可正常进行服务，但用户访问报错500，errorlog报找不到uwsgi.sock(nginx反向代理到uwsgi的socket文件)，服务不可用。 ...
滴滴故障猜测分析
事件背景11 月 27 日，滴滴出现多端 app/小程序服务异常，截至今天滴滴并未公布具体故障原因，网上说法众说纷纭，今天对这个问题展开讨论猜测一下可能的情况。
故障表现滴滴多端不可用（包含用户端/司机端/青桔），显示网络异常，无故障期间 http/tcp 抓包，无法故障回放。网传滴滴内网同步异常，暂无求证门路。
故障猜想
网络攻击（网传）
k8s 升级故障（网传）
以下均为猜测
中间件及 db，系统内核层面等程序爆发式 bug
白名单异常
中台重要环节故障导致调用链断裂
业务引擎 bug
故障猜想论证网络攻击网络攻击具有不确定性：不确定来源，不可预知流量，不确定攻击时间。本次故障看来从时间持续性较长，具有一定的被攻击的特征，但是在受到攻击后通常企业会做以下操作：
接入流量清洗，但是对于被攻击目标太大时使用流量清洗或者 WAF 也是无力的，会引入很大的接入成本和使用成本
直接切换入口，切换入口主要风险点在于是否有备用 ip 可以更换，链路是否冗余，域名 ttl 是否过长，但是故障收敛速度很快，不过这种方式基本只会存在于单业务故障的时候
从以上解决方案来看，故障时间都可以在较 ...
配置文件动态获取
优点服务可以做到动态更新，配置更新时不需要停服，且文件更新后不需要重启服务。
源码分析12345config.Setup( file.NewSource(file.WithPath(configYml)), database.Setup, storage.Setup,)
Options思想在python中，形参可以定义为可选参数，但是在go这种强语法的语言中形参总是不可变的，所以我们就要引入一种Options的方式来将不可变的参数转换为可变的参数，如下边一段代码：
1234567891011121314151617181920212223242526272829package mainimport "fmt"type Options struct { Test1 string Test2 string}type Option func(*Options)func WithTest1(t1 string) Option { return func(o *Options) { o.Test1 = t1 ...
发布工程
发布对于大型生产环境和复杂的业务系统来说，发布应用或者变更并不是简单的在服务器上运行二进制包或者脚本就可以了，这样很不便于服务的管理，且服务的稳定性也无法保障，所以就会有发布工程这一说法。
发布工程要素自给自足的发布对于每个研发团队来说，都需要有一个相对应的发布工程师，发布工程师指定发布策略，编写发布工具，指定发布流程。
追求速度当发布频繁时，每个版本之间的变更将减少。这样能减小新版本上线侯的测试和调试成本。对于项目可以高频次构建，然后在多次构建中选择一个构建版本进行发布（条件：需要是所有测试都通过的版本）。
密闭性每一次构建的产物，都不能因为构建环境差异导致构建差异。所有依赖在构建过程要自包含。
当构建在生产环境中出现bug时，按照之前的源码版本，加入新的改动之后生成新的构建（即向repo推送fix的commit）。构建的编译环境会被包含到repo中（显然有些不可能，所以最佳做法应该时在repo中保存编译器版本等环境信息），这样能保证每次构建环境都是相同的。
发布流程对于变更发布，一般需要遵循一下流程：
提交代码到repo，提mr，进行review
指定流程中的动作
创建新发布版
...
自动化运维
自动化运维的价值对于大型的计算集群或者线上（测试）环境，有成千上万台服务器在运行，单凭SRE进行手动变更或者运维是远不能支持平时工作的，所以这里就要讲到自动化运维的价值：
一致性大型集群在硬件层面很难做到完全统一，但是在系统层面、软件层面和服务层面是可以通过认为影响达到一致的。生产环境的一直能很大程度上标准化生产环境，以降低环境差异化带来的人力成本或者其他附加成本。比如在生产环境中，机器可以通过群组的方式进行批量管理，每个群组内的机器试用相同的环境配置，对于配置试用repo进行统一管理，由此可以把机器的管理粒度从单机提升到群组（但是同时带来一个隐患，如果对群组进行配置变更，如果配置失败影响面就会从单机上升到大批量）
硬件层面比较难做到一致化或者统一化（主要问题来源于设备供应商不同，不同设备的管理方式也不大一样），所以在设计自动化的时候尽量兼容更多的硬件平台或者指定CFI（以上两个选择一个就好，后者可能更贴合当前实际），同样在设计时也尽量使用通用管理方式，比如ipmi协议。
平台化对于变更或者运维操作具象成平台上操作的一个对象，对象可以是单机，也可以是集群，也可以是自定的群组。平台化是自 ...
密码管理中心
对于生产传环境服务器，密码一定不是固定的。对于安全起见，密码需要设计成动态的，主要防止服务器而已登录和服务器权限管理。
密码管理中心的主要功能就是对于服务器的密码进行动态修改，并对生成的密码进行存储，密码展现给指定的业务线和系统管理员。
JWT认证/Tag认证JWT认证JWT是登录鉴权认证。用户登录系统时向API发送自己的账号和密码，服务端做账号和密码校验，如果校验成功，向前端返回一个加密JWT Token，作为用户的认证标志。
12345678{ "code": 100, "tag": [ "owt.sa", "owt.mi_img" ], "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoxNjM3NDIzNjU2LCJpc3MiOiJwYXNzd29yZCJ9.2jEUJyowdtzdz13zkgS6q_iS54ES0wk37uEKj0NN3-Y ...
生产风险管理
$e^x$效应在生产环境下，所有服务的可用性都不可能是100%，大多数企业都会尽量的向100%靠近，但是在极度接近100%的过程中，成本也会成指数上涨。可以理解为可靠性每提升一个等级，就会指出更多的成本，类似于$e^x$函数。
风险管理规避风险的成本主要可以分为两部分：
计算资源成本：包括服务器成本和运维成本
机会成本：由某组织承担，构建资源分配和减少风险系统、监控。
风险度量风险度量的指标主要是服务的可用性，但是可用性通常被分为两种：
基于时间基于时间的服务可用性主要是衡量服务在整个服务时间内的可用时间，其计算公式为$\frac {T_e} {T_a}$。
基于请求基于请求的服务可用性主要是衡量正确请求在所有请求中的比例，其计算公式为$\frac {R_e} {R_a}$。
服务风险容忍可用性目标及可用性容忍可用性目标和可用性容忍通常是一个服务的最低可用性，如果低于这个可用性就可能导致用户对该服务产生负面的评价，同时也会影响服务的收入和上游甲方的评价下降。所以该部分应该更加专注于消费者。
故障类型常见的故障主要是宕机故障，但是其他种类的故障也不容忽视。比如用户信息返回错乱，A ...
生产动力环境
硬件层通常来说，目前服务器大多都使用的是本地硬件服务器或者云服务器。本地服务器常见是使用X86架构，目前华为鲲鹏在发展ARM架构服务器。云服务器通常是虚拟服务器，大部分都是基于KVM（QEMU）的。
目前企业很少会使用单种云，大部分都是使用混合云，对于涉密业务或者大量运算的业务则放在本地机房的物理服务器中，对于公网服务就放在公有云服务器。
混合云和多地多中心的机房优势在于：
多地容灾，单计算中心故障有其余中心冗余
服务隔离，涉密服务本地运行，保证数据安全
软件层管理计算资源管理构建CMDB，集中化管理线上和测试计算资源，将服务器信息和网络资源信息进行精细化管理，落实到计算实例上，有效提高资源管理效率。
对于批量运维任务，可以使用Ansible等自动化运维工具做自动化管理。
计算任务管理将计算任务批量化，使用批量部署工具进行任务提交，多机部署多计算实例，提高计算任务管理效率。
本处可以使用Google提供的Borg或者Kubernetes做计算任务管理。批量提交计算任务后，每个计算实体都是以一个（类）hostname代替。该种方式在Borg中被叫做BNS，即Borg Name S ...
SRE架构
SA和Dev/Ops的挑战通常企业会招聘很多的SA工程师（系统管理员），该部分工程师负责企业生产环境组件的运维，对于需要人工干预的操作进行人工干预。
目前在国内，各公司通常做法是SRE和SA分离，SRE负责业务侧管理和维护，SA工程师负责企业基础架构的维护，包括服务器、基础环境维护。同时Dev和Ops部门分离，所以带来两种成本。
直接成本：业务线扩展，Dev和Ops同步增加，人数共同增长。
间接成本： 消息拉通、同步问题，可能会导致各部门信息不同步，间接导致团队目标不统一。
Dev和Ops部门最大的工作分歧通常出现在新版本发布、变更期间，也可能是发布速度原因。
版本发布： Dev希望随时发布，但是Ops部门希望生产环境一成不变，避免非必要情况下的变更和发版（新版本发布、变更和动力环境割接都有可能导致系统崩溃）
发布速度： Dev部门希望发布是0秒，质量部门希望服务是没有抖动的，但通常来说是不可能的（即使使用平稳变更），可能在变更或者发布的时候会出现服务短暂不可用的情况，所以就可能出现发版或者变更速度跟不上Dev和质量部门的要求。
大型互联网企业SRE解决方案大型互联网企 ...