HyperAIHyperAI

Command Palette

Search for a command to run...

云项目中削减日志记录:如何避免增加MTTR和团队焦虑

自1992年进入科技行业以来,我一直在各种情境中被期望“用更少的资源做更多的事情”。不论是团队人数减少,还是硬件资源受限,这种心态在科技行业中屡见不鲜。一次特别的经历让我深有体会,当时作为后端架构师参与一个云现代化项目时,为了降低成本,我们被要求大量减少或取消服务级别的日志记录——这些日志是我们调试和分析事故的重要依据。 起初,这一举措确实减少了成本。然而,当问题突然出现时,缺少日志成为了一个巨大的挑战。那些简单的结构化错误日志(例如:2025年3月21日下午2点05分03秒,偏好引擎服务出现无法派遣任务到工作池的错误)是我们定位问题的关键。没有日志,时间一分一秒过去,问题依旧悬而未决,不确定性不断增加,整个团队变得焦虑不堪。 在这个项目中,我们的目标是在浏览器弃用日期之前完成迁移到云端的工作。这意味着需要重写服务,与客户团队协调,并在高压下按时交付。虽然我们在内部测试中表现良好,但一旦进入生产环境,各种难以预料的边缘情况开始浮现。由于缺乏详细的日志和足够的可观测性,我们无法准确定位问题所在。尽管尝试重新启用部分日志记录,但这又回到了高摄入成本的问题,同时并未提供有效的解决方案。 在事后分析中,我们发现平均故障恢复时间(MTTR)经常被视为一个重要指标,但实际上它更多是一个症状而非根本原因。行业基准显示,顶级团队通常能够在一小时内恢复故障。然而,我们意识到速度不仅仅是自动化问题,高保真信号同样重要。低质量的信号,如通用的500错误或延迟的聚合指标警报,只会增加模糊性和浪费资源。相比之下,详细且上下文明确的信号,如包含用户ID、请求ID和服务跟踪的结构化日志,能够直接揭示问题的根源。只有当你摄取的数据具有实际操作价值时,可观测性平台才能真正降低MTTR。 那么,如何解决这个问题?我希望能有一个更好的日志分析和应用性能监控(APM)系统。除了APM,还需要日志管理、服务监控、警报和与功能成功或失败紧密关联的定义指标。每个新功能都应该有一个与其成功相关的度量标准。幸运的是,Sumo Logic提供了一种按需付费的模型,可以持续摄取日志,但在你需要查询或分析时才收费。这样不仅可以避免无谓的成本,还能在关键时刻获取关键数据进行彻底的调查。 现代可观测性不仅仅是拥有大量漂亮的日志数据,还包括知道在哪里查找数据。无限摄取会产生大量数据,而当你需要查找信息时,需要有一个起点。Sumo Logic提供的机器辅助分诊工具自动将异常行为分组,检测离群值,并在你编写任何查询之前跨服务展示相关信号。背后的统计算法和机器学习帮助将冗余日志数据聚类为可操作的类别,例如: 错误:工作队列溢出 错误:用户认证令牌过期 错误:服务超时 通过这种方式,团队可以更快地找到问题所在,并进行深入分析,从而减少盲目搜索的时间,加快决策路径,减轻事故期间的焦虑感。 总结而言,“用更少的资源做更多的事情”不必让工程团队处于劣势,但必须配备合适的工具。没有这些工具,再强大的团队也可能在问题排查中感到无助和沮丧。我的个人使命是专注于提供增值的功能和功能,利用现有的框架、产品和服务来处理其他事务。Sumo Logic的零成本摄入模型正是与这一使命相契合的解决方案,它能帮助团队快速识别根本原因,减少停机时间,降低压力水平,而不会超预算。保持这些日志吧! 业内专家认为,这种方法不仅提高了团队的响应效率,还显著提升了项目的整体稳定性和可靠性。特别是在资源有限的情况下,合理的日志管理和数据分析工具可以成为团队的救命稻草。Sumo Logic凭借其创新的技术和灵活的支付模式,为众多中小企业和初创公司提供了强有力的支持。

相关链接