背景Code Review 是大家日常开发过程中很常见的流程，当然也不排除一些团队为了快速上线，只要功能测试没问题就直接省去了 Code Review。 我个人觉得再忙的团队 Code Review 还是很有必要的（甚至可以事后再 Review），好处很多： 跳出个人开发的思维误区，更容易发现问题 增进团队交流，提高整体的技术氛围 团队水平检测器，不管是审核者还是被审核的，review 几次后

最近我们在使用 StarRocks 的时候碰到了一些小问题： 重启物化视图的时候会导致视图全量刷新，大量消耗资源。 - 修复 PR：https://github.com/StarRocks/starrocks/pull/57371 excluded_refresh_tables 参数与 MV 不在一个数据库的时候，无法生效。 修复 PR：https://github.com/StarRocks

前段时间申请成为了 OpenTelemetry 的 Member 通过了，算是完成了一个阶段性目标；从 24 年的 2 月份的第一个 issue 到现在刚好一年的时间。

前段时间升级了生产环境的 StarRocks，从 3.3.3 升级到了 3.3.9，期间还是踩了不少坑所以在这里记录下。 因为我们的集群使用的是存算分离的版本，也是使用官方提供的 operator 部署在 kubernetes 里的，所以没法按照官方的流程进入虚拟机手动启停对应的服务。 只能使用 operator 提供的方案手动修改对应组件的镜像版本，后续的升级操作交给 operator 去完

这些年我一直都是按照农历新年来写年终总结的，都说不出正月都是年，前些年一直都比较规律，今年确实是时间超了一些。 主要原因还是年末接了个活，需要在年初上线，导致这段时间都没太多时间写内容。 最近事情终于告一段落后才开始码字。

前段时间碰到一个 StarRocks 物化视图的 bug: https://github.com/StarRocks/starrocks/issues/55301 但是这个问题只能在存算分离的场景下才能复现，为了找到问题原因我便尝试在本地搭建一个可以 Debug 的存算分离版本。 之前也分享过在本地 Debug StarRocks，不过那是存算一体的版本，而存算分离稍微要复杂一些。 这里提到的本

前段时间有朋友问我如何在 kubernetes 里搭建监控系统，恰好在公司也在维护内部的可观测平台，正好借这个机会整理下目前常见的自建监控方案。 一个完整的监控系统通常包含以下的内容： 指标暴露：将系统内部需要关注的指标暴露出去 指标采集：收集并存储暴露出来的指标 指标展示：以各种图表展示和分析收集到的数据 监控告警：当某些关键指标在一定时间周期内出现异常时，可以及时通知相关人员 对于 k8