查日志不该每次都找平台组写脚本

结论先行：日志平台的查询能力落到组织里，会被三类人用到：平台组、值班的人、业务方。他们需要的不是同一套技能——平台组写查询模板，值班的人改参数，业务方提单。把培训目标定成"人人会写查询"，通常两头都不落地。

自建或采购日志平台时，容易把"支持可编程查询语言"当成一项能力指标。它确实是能力，但它同时是一道门槛：会写的人和不会写的人，用同一个平台得到的价值差得很远。真正决定平台被不被用起来的，不是语言有多强，而是有没有人把查询预先做成别人能直接用的东西。

为什么"人人学查询语言"讲不动

一次培训能教会语法，教不会数据长什么样。同样的字段，在不同来源的日志里含义可能不同；同一个指标，换一种写法就可能得到另一个数。让人人都自己写，结果是同一件事在不同人手里算出不同结论，事后还得花时间解释差异从哪来。

另一个问题是性能。查询语言给的是自由度，自由度用错方向就是全表扫描。一个人写错，拖慢的是所有人的检索体验。

三类人，三层能力

模板层：平台组写什么

把高频问题做成模板，而不是让人每次从零写。值得先做模板的通常是这几类：某个业务近一段时间的错误量走势、某个账号的登录与操作轨迹、某个接口的耗时分布、某类事件的来源分布。

模板要满足两个条件。一是输出列固定，使用者不用自己拼结果，几个人看到的是同一张表。二是带参数且有默认值，默认值对应最常见的问法，改参数就能换对象与时间范围。

参数层：值班的人改什么

值班的人只改参数，不改语法。这在界面上就是把查询语言藏在表单后面：选业务、选时间、填关键字，点查询。所谓低代码的实际落点就在这里——不是让每个人都变成开发者，而是让常见问题不需要开发就能回答。

这样做还有两个副产品：结果口径统一了，因为模板是同一份；性能可控了，因为执行的是预先审过的语句，不会有人临时写出全表扫描。

业务方那一层，只给结果

业务方要的通常不是查询，是结论：这个月有没有异常、哪一类问题在增加。给他们固定看板与定期报表就够了，报表按周期自动推送，比开账号让他们自己查更省事，也更容易管住数据范围。

培训教到哪一层为止

培训交付里通常包含查询语言的基础语法与事件处置流程两部分，这两部分的对象不同，不宜合并。给值班的人讲参数怎么改、结果怎么读；给平台组讲语法、模板维护与字段口径；给业务方只讲报表怎么看。合成一场讲，平台组嫌浅，业务方听不懂，两边都不满意。

边界与前提

其一，模板不是越多越好。长期没人用的模板会成为负担，应当定期清理，清理依据是调用次数而不是谁建的。

其二，自助查询要配合权限边界。能看到什么范围、能不能导出，是另一套规则，不能因为"查询方便"就放开。

其三，高频的临时需求说明模板缺项。一段时间里反复被问的同一类问题，应当沉淀成新模板，而不是每次手工查一遍。

• 按三类角色划分能力边界，明确谁写模板、谁改参数、谁只看报表。
• 先做十来个高频模板，输出列固定、参数带默认值。
• 在模板页面上限制可改项，语法层只对平台组开放。
• 把查询性能纳入平台组的日常指标，定期清理低效模板与无人调用的模板。
• 培训分三场，对象与内容分开，不合并成一场。
• 业务方的出口以固定看板与定期报表为主，按需开只读账号。
• 定期收集反复出现的临时查询需求，沉淀成模板。

奇摩在日志与可观测平台交付中，通常把查询模板与字段清单作为交付物之一，让平台在建设期结束之后仍然被人用起来。需要梳理查询分层与模板口径，欢迎预约咨询。