HuckOps

emmm，2025年又这么过去了。第一次写年度总结，好像应该写得正式一点，但又不知道从哪开始。随便写写吧，反正也没人看，就当是对自己这一年的碎碎念。 感情的一波三折和她认识到现在已经两年多了，分手也已经一年多了。分手后的这一年，我过得真有点不人不鬼。其实到现在我也没搞明白，自己为什么会变成现在这个样子。有时候连我自己都讨厌自己，一直想着改变，却又好像被捆住手脚一样，浑身无力。 今年年初开始，每天眼睛一睁，脑子里就忍不住想：我还能不能把她找回来？她还会不会接受我？直到后来我真的试着去联系她、挽回她，才发现我们之间的感情好像已经变了味——不再像互相喜欢，反而更像一种建立在金钱或物质上的关系。所以我一直在想，到底是什么导致了这样的变化？如果那些事没发生，我们是不是永远不会变成这样？还是一直维持着这段畸形的关系？如果没有那些事，我现在是不是已经结婚了？ 了解我的人都知道，我是个十足的I人，很多事都喜欢放在心里反复琢磨。不知不觉，这些念头完全占据了我的大脑，到最后甚至影响了我的工作和生活。我总觉得自己做什么都不如以前有干劲了，就算这份工作是我喜欢的，也提不起一点动力去认真对待。再后来，我越来越难 ...

Cloudflare 是什么对于运维同学来说，cloudflare 并不是一个陌生的名词，我们会经常把 cloudflare 称为赛博活佛（因为它提供了免费的全球代理等功能，在其他云上那边都要只能上全球 CDN，收费还不便宜，但是 cloudflare 只需要把域名托管到 cloudflare 平台上就可以免费使用全球加速了）。正如最近网上盛传的一个梗图 cloudflare 已经算是互联网的最根本的基石了，可以说 cloudflare 撑起了一整个互联网。cloudflare 在海外提供了多种云服务，比如权威 DNS（one.one.one.one）、全球 CDN、DDoS 防护、SSL/TLS 加密等，可以说只要目前咱们叫得上名字的大部分海外大厂都在用他们家的服务，比如 Netflix、Spotify、Twitter 等，可以说 cloudflare 在海外已经是举足轻重的地位了。但是因为一些合规原因，cloudflare 在国内业务是代理给国内一家叫科赋锐的公司（名字这么像，估计是为了合规在国内搞的全资子公司），而且经过代理之后，海外 cloudflare 有的优势以及特性在国 ...

加密货币和稳定币加密货币（Cryptocurrency）又经常被称为加密资产（Crypto Asset），是指在区块链技术上运行的数字资产，如比特币（Bitcoin）、以太坊（Ethereum）等，同时也衍生出其他类型的加密资产，如 NFT（非同质化代币）等。此类货币相对于现实世界无固定的锚点，其价值由市场供需决定，且由于区块出块难度调整、市场流动性等因素，价格会有较大波动。为了解决这一问题，市场衍生出了稳定币（Stablecoin）。 稳定币（Stablecoin）是指通过特定机制保持价值相对稳定的加密货币，通常与法定货币（如美元、欧元）挂钩。目前市场上常见的稳定币包括 USDT（Tether）、USDC（USD Coin）等。根据发行机制不同，稳定币主要可分为三类：法币抵押型、加密资产抵押型和算法稳定币。以 USDT 为例，它属于法币抵押型稳定币，由 Tether 公司发行，理论上每发行 1 枚 USDT，Tether 应持有价值 1 美元的储备资产（包括现金、债券等），形成 1:1 的锚定关系，用户理论上可以随时用 1 USDT 兑换 1 美元。 多链问题解决了解区块链的玩家都知 ...

最近经常和一些朋友聊到区块链相关内容，很多人对区块链的理解只停留在数字货币，对整个区块链及其相关衍生物的了解程度都比较低，我来整理一下最基本的区块链工作原理及知识，以做科普。 区块链？区块链概念最早可以追溯到中本聪时间。2008年中本聪提出了加密数字货币和相关加密算法的概念，从这个时间起，区块链就逐渐的开始在互联网上生根发芽。最早期大部分人都认为比特币是一个骗局，因为这种货币既没有实体，也没有实际价值（注意区分价值和价格，最早期价格也许有，但是价值是确实没有的），所以在最早期持有持有比特币的那一群人在领到mint后的不久都分分出售了手中的BTC，所以现在币圈很难见到手上有上千个BTC的投资者，如果从2012年持续持有BTC的话，现在的收益已经会有几千倍了，从BTC的市值就不难看出，web3在近些年的发展有多迅速了。 那么，现在有一个现实的问题，区块链就是加密货币吗？加密货币是否就是区块链的全部？ 区块链原理（基于Ethereum 主网）先从区块链这三个字进行解读，这个词可以拆分为区块和链两部分，区块顾名思义，就是一个一个的数据块，链就是一个链条，组合起来就可以把区块链解释为数据块组成的 ...

前叙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: ...

背景这个问题出自一个线上故障。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协议。 平台化对于变更或者运维操作具象成平台上操作的一个对象，对象可以是单机，也可以是集群，也可以是自定的群组。平台化是自 ...