背景
之前公司内部沟通使用的是企业微信，今年以来迁移到了飞书，在使用这两个工具的时候感觉机器人通知的功能还是很不错的，可以起到提醒和快速引导的功能。
基于机器人，公司已经做了各种待办通知、流程通知，在此基础上，团队也思考着结合机器人通知机制做了一些工具和平台。
问题跟踪平台
项目需求阶段经常会遇到待确认事项，目前都是通过在群里，或者口头找人确认，导致问题结果很难公开，仅有小部分人知道，同时部分问题会没及时答复容易跟丢现象。所以就想到了做一个平台去沉淀项目中待确认的问题，然后通知对应的人进行确认，进行状态流转。更长远看，这些问题数据可以沉淀下来用作问题分析和左移分析。
基本的功能模块首先就是项目的登记，需要填入项目信息或者问题名称
通过配置的机器人key以及设置的时间，可以按指定时间对于未关闭的问题进行提醒
目前这个工具已有几十个项目使用，总体反馈还不错。
失败用例通知到人
公司的持续集成流程里，集成测试跑的是基于testNg的自动化工程，订阅了集成测试结果通知，运行完成后会通知你成功或者失败
点开链接就会看到自动化工程的执行结果
这样似乎能够满足我们感知和修复集成测试的需求。但当自动化用例由多个人编写和维护的时候，如何划分维护范围以及找到用例维护人就是个很头痛的问题，之前的做法就是使用表格维护或者打开工程看下是谁写的代码，比较麻烦。用例及时维护一直是个痛点，如何快速找到责任人是用例快速修复的基础。
现在的做法，通过testNg的listener监听用例失败的消息，通过git blame命令找到失败用例的提交人，精准的进行通知，这样集成测试的发起者也知道失败找哪些人确认失败的原因。
日志告警通知到开发
既然失败用例可以通知到人，自然而然的想到，线上的错误日志，也能通过类似的方法找到代码行最近修改的开发，根据日志中的错误信息和打印出的异常栈。
线上问题通知的玩法和维度可以更多一些，比如针对错误类型进行分类展示和通知（如NPE），根据提交时间判断是否是最近项目发布造成的进行区别提醒等
不得不说，飞书的话题群很适合这种类型信息的同步，对于错误信息相关开发定位排查后可以回复错误的原因。
最后
以上都是团队在工作过程中思考想出的一些提高效率的方式，不算很难，很多都是一些小点的优化，但效果还是很OK的。如果大家都能不断优化和改进自己的工作，那么个人能力就会得到成长，团队效能就能得到提高。