将故障响应周期从【6.0天】缩短至【0.8天】——向matsuri technologies株式会社学习如何打造强大的开发团队 

采访协助：matsuri technologies 股份有限公司 开发部 开发课 课长 花田觉 先生 / SIC团队 大岛朋也 先生

本文要点

• 将响应周期从2个月缩短至1/7（6.0天 → 0.8天）

• 关键在于“与其追求自动化，不如先做好记录”这一决策

• 支撑成功的三大因素：产品负责人的支持、团队协作文化、以及关键人员调动带来的危机感

• 改进措施：以Notion为核心的知识管理 × 以Datadog MCP为核心的AI技术栈

• 启示：正是这些不起眼的一小步，才能带来重大的组织变革

在本系列《向具有韧性的企业学习：如何打造强大的开发组织》中，我们将介绍一些在应对安全事件时，针对“处理工作依赖个人”及“检测工作依赖人力”等常见问题，采取先进应对措施的企业案例。本系列旨在通过决策逻辑和组织变革的实际案例，为勇于改革各位读者提供可复制的实践经验。

本期将介绍的是开发并运营省人化住宿及短期租赁平台的 matsuri technologies 股份有限公司。该公司以 m2m 系列为核心，同时支撑着自身的住宿业务和面向外部的引流平台（如 Sumyca、一時帰国.com 等），是一家在过去 9 年里持续实现业务增长的技术企业。

该开发团队在短短2个月的时间内，将咨询响应周期从6.0天缩短至0.8天，缩短至原来的约1/7。

关键所在既不是最新的AI工具，也不是新设立的专职SRE团队，而是“与其追求自动化，不如先做好记录”这一根本性的决策。本文基于对matsuri technologies开发负责人花田先生和SIC团队负责人大岛先生的采访，将为您介绍这一决策背后的逻辑以及组织变革的轨迹。

从个人能力到组织机制——变革前夜的matsuri technologies

在进入成果故事之前，让我们先梳理一下matsuri technologies的业务特点和面临的挑战。

这一运行了9年的产品系列，与Airbnb等在线旅行社（OTA）保持着异步对接。由于业务具有“节省人力”的特性，系统故障绝非仅仅是“程序错误”那么简单——一个系统故障就可能导致“客人今晚无法入住”，这让我们深切体会到系统故障对服务提供和客户满意度产生的直接影响，以及由此带来的巨大压力和紧张感。此外，matsuri technologies的产品不仅服务于外部客户，公司内部的各个事业部也日常使用这些产品。这形成了一种独特的结构，即工程师的用户群体同时涵盖公司外部和内部。

鉴于该项目的特点，开发团队主要面临两大挑战。

课题①：个人化

matsuri technologies的开发体制，追溯其源头，最初是从“一人负责一个产品”的负责制开始的。随着业务的扩大，“毕竟照这样下去，大家都没法休息，确实有些勉强。正因如此，我们才逐渐转向团队化运作，”负责TS团队的花田先生如是说。

组建团队后，虽然知识和文档的整理工作稳步推进，但还不能说已经足够完善。尽管如此，之所以能够顺利应对而未出现重大问题，正是因为每位工程师的技能都很高超。

“实际上，在现场，‘系统越是老旧，就越需要向特定成员确认才能弄清楚’的情况并不少见，”领导SIC团队的大岛先生表示。

属人化是影响组织稳定性的因素之一。更何况对于像matsuri technologies这样将服务与技术相结合的公司而言，其影响更是难以估量。

课题②：检测工作对人力的依赖

另一个结构性问题在于检测工作对人力的依赖。如前所述，产品开发人员与作为用户的业务部门均位于同一公司内部，因此故障的第一手报告往往由业务部门通过Slack发送过来。虽然距离的接近能带来快速响应，但反过来说，这也意味着一种风险，即“如果业务部门没有察觉，就无法检测到故障”。

“是否在某个地方发生了我们开发团队尚未察觉的故障？”（花田先生）

花田先生表示，这种不安一直笼罩着整个团队。

针对此前一直存在的难题，关键人物花田先生调往其他团队成为了一个转折点。“照这样下去，业务将无法运转下去”——这一认识促使整个组织产生了强烈的主人翁意识。

促成变革的三个因素

面对像matsuri technologies这样的挑战，不少组织都试图从“基于AI的自动化”入手。然而，matsuri technologies选择的却是相反的做法——回归基本，从“完善记录机制”开始。

2026年入职的大岛先生，其初衷十分单纯。

“每当接到咨询时，我们往往都会先问‘这是什么？’。如果不向前任或关键人员确认该如何应对，我们自己也无从知晓。我意识到这确实是个问题，因此‘至少，先把做过的事情好好记录下来吧！’就成了我们的出发点。”（大岛先生）

据说正是基于这一想法，才开始了按照指定格式收集信息的工作。

当然，支撑这种“自然选择”的还有公司文化。无论是在实体办公室还是虚拟办公室，一直以来都存在着遇到困难时能立即聚集在一起的“同桌”文化。此次，我们将这一文化应用到了事件应对中。

组织层面的支持也是让这一前所未有的举措得以落实的关键因素。其中，产品负责人的态度起到了尤为重要的作用。

通常情况下，产品负责人会因业务压力而倾向于要求“团队成员在推进项目的同时，也要并行处理各自的本职工作”。但在matsuri technologies，情况并非如此。

“我们团队的产品负责人曾表示，在故障排查和处理方面，即使有一人只是旁观也没关系。他希望团队能齐心协力解决棘手的问题。在有些产品负责人会要求大家继续推进各自负责的任务的情况下，这对我来说无疑是一个巨大的支持。”（大岛先生）

这是一种被称为“群攻”（Swarming）的工作方式，即全团队共同致力于完成最高优先级的任务。

产品负责人的组织层面的支持、"一个团队"的企业文化，以及关键人员调动带来的危机感。这三个因素相互作用，使得“从记录开始”这一脚踏实地的举措，逐渐演变为改变团队和组织的重大变革。

如何构建解决问题的运营基础架构——知识运营与AI技术栈

针对面临的课题，我们主要从两个方面采取了措施。一是知识文档的管理，二是AI工具和自动化。

以Notion为核心的知识管理与运营

我们将此前分散在Slack、Google文档、Notion等各处的调查结果整合到一个数据库中。大岛先生解释道：“我们首先建立了一种机制，即‘关于该事件的调查结果，只需查看此页面即可了解’。”我们将所有咨询都以工单形式录入Notion，并对概要、处理内容及调查记录进行统一管理。

为确保制度落实，我们采取了具体的措施。利用Notion的模板功能，预先准备好模板。通过引导用户填写必填项，并确保格式统一，逐步将积累的数据信息标准化。在部分团队中，我们率先引入了Claude Cowork等自主型AI代理来收集咨询信息，目前已实现“自动收集Slack上的咨询并存储至Notion，全程无需人工干预”的状态。

该设计的核心理念是：“当收到相同的咨询时，希望能通过参考过往案例立即予以处理。”大岛先生补充道：“如果将来能利用这些信息让AI自动处理，那就太好了。”

AI与自动化技术栈

改变以往依赖业务部门反馈来进行故障检测的方式的，正是故障检测与响应的AI管道。

matsuri technologies原本分别使用系统监控工具“Datadog”、自主型AI代理“Devin”以及AI开发助手“Claude Code”和“Codex”，而随着Datadog MCP的推出，这些工具得以整合，并可作为故障检测管道加以利用。

Datadog MCP 作为将 Datadog 中的日志和错误信息传递给 AI 及其他工具的桥梁，利用该功能构建的 AI 管道如下所示。

首先，我们配置了自主型AI代理Devin，使其能够定期自动检查Datadog的错误日志。一旦检测到异常，系统便会自动在GitHub的Issue（用于记录开发任务的场所）中创建工单。此外，通过构建一个能由AI提供修复建议的机制，我们搭建了一条无需人工干预、从异常检测到应对方案全程无缝衔接的处理流程。

不过，自动检测功能尚未在所有产品中全面推广，看来为了正式引入该功能，他们仍在不断进行尝试和调整。

据悉，在发生事件时，会利用Claude Code和Codex进行调查，并通过Datadog MCP将日志和APM信息直接传递给AI，从而加快原因排查的速度。

据悉，这些实践创意都是从每天下午3点举行的“咨询会”中自然产生的。公司建立了一套相互分享近期试用过的工具和所学经验的机制，将新工具融入日常工作的循环已然形成。

交货周期从6.0天缩短至0.8天。消失的是开始生产前的“等待时间”

截至2026年2月，即在引入任务化与“群攻法”后的初期阶段，客户咨询响应周期（从建单到完成）的中位数为6.0天。这一数字在3月缩短至1.0天，4月进一步缩短至0.8天。短短两个月内，响应周期就缩短至原来的约1/7，实现了显著改善。

花田先生对数字背后的机制进行了如下分析。

“以前常有‘先开个单，以后再处理’这种拖延现象。而现在则变成了‘既然单子已经开了，那就赶紧处理吧’这种想法，我认为这一点发生了巨大的变化。”（花田先生）

据悉，花田先生在重新查阅了以往的处理时间（从开始到完成）数据后，发现了以下情况。

“实际上，从开始处理到完成所需的响应时间，无论是过去还是现在，其平均值和中位数都没有太大变化。以前的特点是‘响应时间的波动幅度较大’，但经过此次改进，这种波动已经消失。不再存在因责任归属不清导致任务积压的情况，现在处理工作能够以稳定的节奏推进了。”（花田先生）

无论过去还是现在，处理时间的中位数本身都约为1天。也就是说，技术处理速度并未发生剧变，而是从提交申请到开始处理的等待时间似乎得到了改善。

此外，促成3月份这一戏剧性飞跃的，还离不开产品负责人的另一项举措。

“当收到咨询时，产品负责人提议说：‘哪怕只有30分钟这样短的时间也好，先着手尝试一下吧。’他说，如果能解决自然是再好不过，即使解决不了，也可以向有相关知识的人请教。我认为，这种‘不要勉强自己承担过多’的理念，促成了3月份的重大转变。”（大岛先生）

通过2月份的细致记录，咨询的类型和趋势得以可视化，同时“30分钟提案”也恰逢其时。

花田先生所说的“既然已经提上议程了，那就赶紧做吧”这种意识转变，似乎并非凭空产生的。

• 所有咨询都在Notion上以任务的形式可视化了

• 得益于“群策群力”的文化，团队能够迅速进入协作状态

• 由于产品负责人进行了30分钟的提案，降低着手处理任务的门槛

似乎正是这些因素相互结合，才催生了“提交工单→立即着手”这种即时响应的文化。

　大岛先生表示，随着“不必独自承担”这种心理安全感的深入人心，新成员也能更早地参与到工作中来。他指出，能够参考存储在Notion中的过往案例的环境，加速了新员工成为可用之力的进程，在定性方面也发生了显著变化。

三项后续举措——深化横向拓展与外部合作

matsuri technologies在短短两个月内将响应周期缩短至原来的七分之一，而其目光已投向了下一阶段。

第一点是改革的横向推广。

此次举措最初由SIC团队（物业·客源领域）率先实施，今后计划将其推广至以异步工作方式为主的TS团队（保洁·入住登记领域）。根据各团队特点进行差异化调整，将成为我们面临的下一个挑战。

第二点是确立严重程度判定标准。

正因为与事业部的距离较近，因此不应制定千篇一律的标准，而是需要采取一种尊重各产品特性与多样性的审慎做法。花田先生对此评论道：

“关于如何从‘严重程度’和‘影响’这两个维度进行评估，目前尚无统一标准。在产品生命周期各不相同的情况下，究竟是应该强行统一标准，还是存在共通之处？我认为，在开发和业务拓展的过程中，有些问题或许会逐渐明朗。”（花田先生）

换言之，花田先生认为，判断标准的正确答案并非在纸上设计出来的，而是会从日常实践和业务增长中自然而然地浮现出来。

第三点是深化与外部服务的联动。

虽然与OTA等外部服务的对接属于公司无法完全掌控的领域，但matsuri technologies并不将其视为“难题”。

“我认为，不应将外部服务中的故障简单归咎于外部因素，而应秉持相互促进的态度。如果我们将公司发现的问题与对方分享，对方也能积累相关知识，从而推动自动检测协作的进展。我不认为应该将故障责任推给对方，而是应该采取一种促进整个行业成熟发展的态度。”（花田先生）

SIGQ洞察——从案例中学习：构建记录与自动化机制

从matsuri technologies的案例中可以看出，只有先完善“记录机制”，才能真正衡量自动化的效果，这是一种普遍的规律。

根据SIGQ对250名VPoE、EM和SRE负责人进行的调查显示，在致力于改革事件响应的组织中，回答“未见改善”的比例高达32.4%。在许多组织虽已着手改革却未能取得成效的情况下，像matsuri technologies这样按照“记录→自动化”顺序推进的案例，对整个行业具有重要的启示意义。

花田先生提出的今后工作重点是

• 各团队对事件严重程度的认识尚未达成一致

• 希望实现错误日志的自动分类和严重程度判定

这两点也是许多企业共同面临的课题。

像matsuri technologies这样奠定了“记录”基础的组织，接下来要面对的正是这两点。我们SIGQ也是基于同样的问题意识，设计了Incident Lake。

SIGQ提供的Incident Lake通过基于历史响应记录进行学习的AI自动判定事件严重程度，并针对正在处理的事件实时提供类似案例的解决方案。该设计通过与存储在Notion等平台中的调查记录相结合，能够将matsuri technologies积累的“记录”自动关联到“下一次初始响应”中。

致所有抱有相同问题意识的读者。matsuri technologies的发展历程告诉我们，改革并非始于最前沿的工具，而是始于“先留下记录”这一看似平凡的一步。一个 Notion 模板、引入“群智”文化、产品负责人的“30 分钟就好”这一鼓励——这些都是从今天起就能在自己组织中尝试的行动。在您的组织中，也一定有这样“第一步”。

采访·撰文：BtoB株式会社的匠人 鸭田崇司