反馈体系漫谈（五）：通知策略设计——什么时候通知谁
前面四篇分别讲了邮件、短信、即时通讯三个通道的技术细节和集成方式。有了“术”之后，最后要聊的是“道”——怎么把这些通道组合起来，设计一套真正好用的通知体系。 通知体系设计的核心问题只有一个：在正确的时间，把正确的信息，通过正确的通道，送到正确的人手里。
唐莫盈
一个开发出身的DevOps工程师
反馈体系漫谈（四）：即时通讯通知——Webhook 连接一切
在 DevOps 实际工作中，即时通讯工具（IM）是最常用的通知通道。构建成功没、部署完没、Pipeline 跑到哪一步了——这些日常信息，最适合在群里说一声。相比邮件的正式和短信的重度，IM 是“刚刚好”的那个。 IM 通知背后的核心技术是 Webhook——一个简单的 HTTP 回调机制，理解了这个，飞书、企业微信、钉钉、Slack 的通法都是一...
反馈体系漫谈（三）：短信通知——紧急事态的终极兜底
短信是所有通知通道里最“重”的——成本高、信息量少、还容易被滥用。但它有一个无可替代的优势：强制触达。半夜两点线上故障，邮件进了垃圾箱、IM 消息被静音，只有短信能把人叫起来。 换句话说：短信是反馈体系的“应急按钮”，不是日常工具。
反馈体系漫谈（二）：邮件通知——最古老也最可靠的通道
在一堆即时通讯工具满天飞的今天，聊邮件通知似乎有点“过时”。但实际情况是——邮件仍然是 DevOps 中最基础、最正式的通知通道。构建报告、发布公告、定时周报，这些场景下，邮件有不可替代的优势。 更重要的是，邮件背后的 SMTP 协议，是所有通知系统中少数几个你真正需要理解协议原理的。理解了 SMTP，你就理解了“消息怎么被可靠地送出去”。
反馈体系漫谈（一）：从“看见问题”到“触发行动”
你有没有遇到过这种情况：CI 流水线挂了半小时，没有人发现，直到测试跑来问“包怎么还没出”？线上出了故障，靠用户截图才知道？发版完成了，群里吼一嗓子，结果该知道的人全错过了？ 这些问题的本质都一样——你在该知道的时候，不知道。 这背后缺的是什么？不是监控。Prometheus 搭了，Grafana 大盘亮着，日志也收着。缺的是从“看见”到“行动”之...
构建工具（十一）：构建系统全景图——从 make 到 Bazel 该怎么选
1、先讲个故事 有个人想煮一碗面。 第一次，他烧了水、切了菜、下了面、调了酱。每一步都自己动手。这像手敲 gcc 命令。 后来他把步骤写在了便签上，每次照着做。这像写了个 shell 脚本。 再后来他发现，如果菜已经切好了，就不需要重新切。于是他在便签上加了判断。这像Makefile。 再后来他请了个厨师，只需要告诉厨师「我想吃面...
构建工具（十）：Bazel 入门——Google 级别的构建系统
1、CMake 还不够好吗？ 我们已经花了五篇文章学 CMake——从入门到现代写法，从多目录组织到交叉编译。对于绝大多数 C/C++ 项目来说，CMake + Ninja 已经是一套非常成熟的方案了。 但假设你的项目是这样的： 3000 个源文件，跨越 C++、Java、Python、Go、ProtoBuf 五种语言 50 人的团队，...
构建工具（九）：Ninja——构建界的闪电侠
1、make 不够快吗？ 用了几年 make 后，你有没有发现一个现象： make -j8 你开了 8 个并行线程，CPU 跑满了，但 make 还是要在启动时「卡」几秒钟才真正开始编译。 这几秒钟里，make 在干什么？ 它在构建依赖图——从 Makefile 里解析谁依赖谁、谁先编译谁后编译。Makefile 是文本格式，make 每次...
构建工具（八）：交叉编译——在你的 x86 电脑上编译 ARM 程序
1、你会遇到这个需求 某天，你可能会遇到这样的场景： 要在树莓派（ARM 架构）上跑一个程序，但树莓派性能太弱，直接在上面编译慢得令人发指 你是做嵌入式的，目标板是 ARM 芯片，根本没操作系统，更不可能在上面装编译器 你想给 Android 或 iOS 设备编一个 native 库 这时候你就需要交叉编译（cross compi...
构建工具（七）：多目录项目的 CMake 组织——像搭积木一样管理代码
1、项目长大了怎么办？ 前面的文章里，我们写的都是单文件或单目录项目——所有代码放在一起，一个 CMakeLists.txt 搞定。 但真实的 C/C++ 项目可不是这样的。一个典型的项目结构长这样： myapp/ ├── CMakeLists.txt # 顶层 ├── src/ │ ├── CMakeLists.txt ...