AI 时代,开源项目的技术 Support 正在被重写
AI 正在重写开源项目的技术 support 流程:先让 AI 读文档、源码、配置、日志和运行环境完成第一轮排障,再把收敛后的问题带到社区。
汇总 Flashcat 博客中归属于 Flashcat方法 分类的文章,方便按内容类型连续阅读产品实践、客户案例和可观测性方法。
AI 正在重写开源项目的技术 support 流程:先让 AI 读文档、源码、配置、日志和运行环境完成第一轮排障,再把收敛后的问题带到社区。
监控系统本身也会失效。本文介绍如何用 catpaw 给 Prometheus、Nightingale、Alertmanager 增加独立外部哨兵,从 systemd、进程、HTTP、磁盘、日志、时间同步和 MCP 等角度降低监控失声与值班盲飞风险。
AI 短期不会直接替代运维岗位,但会优先替代依赖个人经验、上下文记忆和人工协同的工作方式。本文从调查型 Agent、协同控制台、自动化护栏、平台工程和组织记忆系统五类产品形态,分析 AI 时代运维体系的演进方向。
AI Agent 和 LLM 应用进入生产后,可观测性不再只是排障工具,而会成为可靠性、治理、审计、成本控制和 Agent 自动化的运行时控制平面。本文梳理最近 3 个月的行业信号和企业落地建议。
非 Google 公司如何采用 SRE 实践:从 SRE 团队组建、成熟度模型、SLI/SLO/SLA 实践到监控自动化,一步步落地站点可靠性工程,提升系统性能和可靠性。
连锁门店企业的可观测性有什么特点和建设中的挑战和难点?本文将总结分享Flashcat为多家大型连锁门店企业建设可观测性平台的经验。
Prometheus 告警事件中的 `$value` 表示当前告警触发时的值,但是在告警恢复时,Resolved 事件中的 `$value` 仍然是最新告警时的值,并非是恢复时的值,这是什么原因和原理?是否有办法来解决呢?
在第二届 CCF 夜莺创新论坛上,知乎基础架构研发工程师邱天罡分享了知乎的可观测性体系实践和经验,以及如何利用 SLO 持续的度量、追踪和改进系统可用性。
中国企业出海,考虑到数据保护规则的要求以及跨大洲的网络传输条件受限,服务往往部署在全球多个 Region 或者多云上,这给系统的运行维护带来了一定的挑战,特别的聚焦在可观测性体系的建设上:1)需要在每个region独立部署一套可观测性工具,很多维护性和配置性的工作,需要重复搞多次;2)某些场景下,需要跨区域进行数据分析、制作报表的时候,力不从心;有的企业干脆选择把所有区域的可观测性数据,实时的汇聚到中心机房,集中维护和处理,也存在不小的隐患。
围绕阿里巴巴 1-5-10 故障目标,说明如何用北极星指标、灭火图、事件墙和多维分析缩短发现、处置与恢复时间,帮助团队建立更快的应急响应机制。
本文将结合实战经验,介绍一种日志分析的实现,分析如何在稳定性保障中用好日志这个维度,以及日志如何与指标、链路相互配合形成故障定位的最佳实践。
笔者从 14 年开始做监控,到现在接近 10 年,认知在持续迭代,最近又有一些新想法,跟大家分享一下我眼中的理想的监控系统到底是什么样的
什么是可观测性?相比传统监控,可观测性是“新瓶装旧酒”吗?他们有哪些区别和联系,从传统监控到可观测性,Gap 到底有多大?
稳定性保障,是一切技术工作的出发点和落脚点,也是 IT 工作最核心的价值体现,当然也是技术人员最容易“翻车”的阴沟。8个稳定性保障锦囊,分享给各位技术人员择机使用。
如果您之前对可观测性重要性,益处,以及组成不甚了解,本文是一个合适的指南手册
可观测性不能只关注 metrics、logging、tracing 这些 raw data,还要能够从数据中提取特征,进而推导出观点,最终辅助洞察定位故障。能够辅助定位故障才是可观测性的核心目标,构建数据只是建设底座,离目标还差的很远,千万不要觉得有了数据,就完活了。
什么是可观测性?从传统监控到可观测性,Gap 到底有多大?构建和完善可观测性体系,有哪些最佳实践,应该从哪些维度入手和进阶?
日志,指标和分布式链路追踪这三个可观测性的传统支柱,已经是过时的,过于关注数据采集和底层数据格式,而不去关注结果(我们建设可观测性的初心和目标),这个做法实在是滑天下之大稽
可观测性(Observability)是一种软件开发和系统构建的哲学,是对系统内部状态及行为的度量和推断能力,通常包括日志、指标、链路追踪等多个度量维度。也就是说,在软件开发和运维领域中,可观测性是指对于一个复杂的系统,能够通过监控、日志、指标、追踪等手段,快速地发现、诊断、解决问题的能力。
SRE 是 Site Reliability Engineering,网站稳定性工程,具体怎么做这个网站稳定性工程?有没有什么方法论?有没有什么工具?白皮书来了