可观测性
可观测性是通过观察系统的外部信号来理解其内部正在发生什么的能力。它是一种在因果关系演变为症状之前就看见它们的习惯。它是工程实践中将「有什么东西坏了」转化为「我们确切知道是什么坏了以及为什么」的那一部分。 我们做自己的项目，对我们而言，比用户更早察觉问题很重要。理想情况是在它仍然只是一个小小的指标偏差的时刻，远在它演变成半夜电话响起的事故之前。
我们眼中好的可观测性
好的可观测性回答「为什么以及在哪里」这个问题。它照亮用户路径，显示退化，发现发布后的回归，给出从容回滚的机会。它对琐事保持沉默，在真正需要的时候大声说话。 糟糕的可观测性是十条无人查看的告警，是有三十个图表却找不到任何东西的仪表板，是无法进行过滤的纯文本日志。好的是三个真正描述系统健康的指标，以及搜索只需几秒的结构化日志。 我们喜欢「三大支柱」方法——指标、日志、跟踪。指标回答「平均情况下在发生什么」，日志回答「在特定时刻发生了什么」，跟踪回答「请求如何穿过系统」。每一根支柱自身都有用。当它们彼此关联时，魔法才开始：从指标告警跳到日志，从日志跳到跟踪，从跟踪跳到代码。
私有前端监控
我们另有一份偏爱：私有前端监控。你看到浏览器中真实的错误和性能，数据留在你的基础设施内部。无需传送给第三方服务，无需额外依赖，无需让你的用户沦为他人广告模型的流量。 我们基于 Grafana Faro、OpenTelemetry 和自己的事件接收后端来组装技术栈。这样的方案比在五分钟内接入一个 SaaS 要贵。一年之后，你拥有一套不依赖外部、没有事件上限、拥有成本可预测的基础设施。
当后端和前端的信号住在一起时，你将停止手动拼接数据，开始一次性看见整个系统。
告警作为一种工程实践
配置告警很容易。把它调到只在真正需要行动时才触发，很难。我们遵循一条规则：一个触发了却什么都不需要做的告警，是糟糕的告警。也许阈值偏了。也许指标选得不好。也许问题已经自动解决了，而人白白收到一条通知。 因此在我们这里，每一条告警都要过一遍筛子：究竟什么被打破，为什么重要，期望采取何种行动，应当去哪里查看。对这些问题有清晰的答案时，告警留下。这样的告警触发得很少，却总是有理有据。
这些在我们的项目中如何体现
我们收集信号是为了帮助做出决策：应当进行哪些实验，优化什么，瓶颈在哪里，一次错误的代价是多少。在有益的地方，我们加入快速标记事件和实验的方式，以用知识替换信念。 在拥有用户流量的产品中，我们默认放上一个带 Core Web Vitals 的面板，按国家和设备拆分，并为分布的「尾部」准备一个单独的视图——因为平均值几乎总是撒谎。在后端服务中，我们沿整条链路进行跟踪，离开它就无法理解一次具体请求为什么走了七秒钟。 如果你想从「好像变糟了」走向「这是指标，这是原因，这是回归发生的时刻」——这恰好就是我们的风格。
状态
该能力处于活跃状态，并随我们的项目一起成长——因为没有可观测性，任何复杂系统都会很快变成漫无目的的游荡。我们愿意从零开始接手项目（搭建技术栈、配置告警、培训团队），也愿意接手梳理现有仪表板动物园的任务：保留什么，去掉什么，替换什么。 用于搜索和学习圣经文本的东正教工具。快速搜索、翻译比较、解释和儿童模式。
圣经搜索