跟踪产品和业务的状况，对整体情况，有一个客观的判断，才能支持下述决策：
1、发现风险：哪个地方，出现风险之前，细微的指标，都有反映，有的剧烈、有的微弱；
2、业务预测：预判业务的增长规模，以及需要提前准备的资源（人力、资金）等
支撑决策：发现业务的客观规律，获取客户/用户的反馈，支持科学决策。
上面所有的决策，都需要客观的跟踪产品和业务状况，都需要进行量化，也就需要指标，指标分为：
1、核心指标：真正的直接反应核心的供给、需求、利润、品质等情况；
2、关联指标：其他关联的周边指标，方便发掘潜在问题、增长点、改进策略等情况。
本文列出了 IT 运维的 20 个关键指标，如响应时间、错误率、吞吐量、可用性等。这些指标涵盖系统性能和稳定性监测，帮助运维人员全面评估并优化系统表现。此外，还包括 CPU 使用率、内存利用、数据库响应时间和安全事件率等，提供了具体参考值和优化建议，是运维工作的重要参考。
本文深入复盘了一次完整的产品重构过程，明确了重构的时机和阶段性目标。重构中主要解决了架构混乱、性能瓶颈和用户体验不佳等问题。具体操作包括重构代码模块、优化数据库查询、引入缓存机制，并通过用户行为数据来调整功能细节。作者还提出了应对重构风险的方法，如建立测试闭环、逐步发布和快速响应用户反馈，以确保重构效果和产品稳定性。
本文总结了OpenTelemetry中指标的概念与使用。作者介绍了OpenTelemetry如何收集和处理应用程序的性能指标，包括计数器、仪表和直方图等核心概念。文章还讨论了如何在应用中实现这些指标的监控，并通过代码示例展示如何使用OpenTelemetry SDK进行集成。此外，作者分享了将指标数据导出到Prometheus和Grafana进行可视化的步骤。
给某大厂的技术新人做了一个关于产品思维的分享，提前收集了一些困惑，贴几条提及最多的，稍微聊一下。
哦对了，先帮产品说句话——技术同学，千万别简单地用“那个产品是傻X”来回答以下问题。这是因为，作为技术，如果你总觉得和你配合的产品都是傻X，那大概率，别人会觉得你也是——要不然，为什么选择与傻X共事？所谓 “若，我看周围皆傻X，料，世人看我亦如是”。
在当今数字时代，软件系统在我们的生活和工作中发挥着越来越重要的作用。我们需要确保这些系统能够在高负载、高并发的情况下稳定运行，为用户提供良好的体验。为了实现这一目标，我们需要关注系统性能监控指标，洞察系统运行的关键脉搏。本文将从指标分类、指标详细说明等方面介绍系统性能监控指标的相关知识，帮助你更好地理解和应用这些关键数据。
日志成本控制主要有如下几个维度：- 减量：去掉没有意义的无效日志，只打印关键日志。- 减周期：尽可能减少日志存储的时长。- 转低频：低频相较于标准存储，可降低 6 0%--70%的成本。- 慎开全文索引：全文索引将会把所有日志全部索引一遍，并且这个存储是未压缩的存储，如果开启全文索引，则存储往往会比不开的存储高出 4--10 倍。
我观察到对于大部分前端工程师又或者曾经的自己而言，做性能监控是一个被“喂”的过程，即会惯性的收集已有指标和利用已有工具。又因为性能优化工作过程前置结果后置的关系，等到我们有需求发生时才会发现当下收集的数据并非是我们想要的。
