出场人物：

08：10

小H，是巨杉数据库引擎研发的一名工程师。7：20 天还蒙蒙亮，小H就起床了，点亮了心爱的光剑，开始了新的一天。

在08:10时候，他已经洗漱完，锻炼好身体，倒好了咖啡。

整个春节由于疫情防控，他为国家做出了贡献，基本都宅在家里了。但是他觉得，宅在家里，也是一个挺好的春节。

小H查看了手机，发现一封未读邮件，显示是公司 Jenkins 系统发出。

小H打开邮箱，查看了未读邮件，是昨天新提交的优化代码 PR，导致了昨晚自动化测试系统中一个测试用例没有通过。

09:15

在平时，大家 9 点上班回到公司，各个小组都会在09:15自发地开一个简短的站立会，组内成员分别大致介绍一下昨天完成的工作内容还有今天的工作计划，然后大家开始了一天的工作。

现在，只是面对面的站立会，变成了“线上站立会“，大家依然按时登入小鱼易联的会议号。

小H在会上介绍了一下昨天提交引擎里 analyze 优化的代码，以及发现新代码会导致一些测试用例失败的情况。他打算今天将这个问题解决。

09：25

小N，是巨杉数据库的测试工程师。

早上刚刚拿出“小黄鸭“准备开始工作，她也收到了昨晚自动化测试系统用例失败的邮件。昨晚失败的测试用例，是她负责的。在刚才的站立会上，她计划今天和小H一起跟进这个失败用例。

开完了早上站立会，她通过 VPN 远程连接公司内部的云桌面。

她通过自动化测试系统获取了昨晚测试用例失败的环境信息，然后通过 SSH 进入测试环境。

根据测试用例的错误信息，小N判断，应该是最新的数据库引擎中存在隐患，导致在特定的场景中会使得数据库执行命令不符合预期。

小N按照测试发现问题的流程，在 jira 系统中，给该引擎模块的研发小组组长提了一个问题单。

09:43

小X，是数据库引擎 analyze 模块的开发组长。他看到了 jira 系统给他发了一封关于昨天新合并的 PR 导致测试用例失败的问题单。

他打开 jira 网页，浏览了一下测试的具体情况，明白应该是昨天优化的代码引入了新的问题，他将问题单转交给了小H，让负责模块的小H来负责解决。

09:45

实际上小H在09:31开完早上的站立会，就已经通过 VPN 连接了公司内部的云桌面。他希望尽快弄明白昨晚测试用例失败的问题。

新版本的 analyze 模块优化涉及很多 class 文件的修改，代码编写和调整持续了几周，从早上看到失败邮件通知起，他就一直在回想可能是哪个方法忽略了调用，还是在哪个错误的地方错误地进行了调用？他不禁发出灵魂的拷问：“我究竟错哪了？”

这个时候，邮箱里收到了一条新的记录，是关于昨晚测试用例失败的信息，以及重现问题的步骤。他看着 jira 上的测试步骤以及错误输出，突然间，他好像明白了什么，又一头钻入了代码里。

11:28

小H通过 jira 问题单上的重现步骤，他发现了问题的导致，是因为原来的优化代码中，对一些特殊事件的处理得并不完整，所以才导致了问题。

他心里已经知道了如何 fix 问题，他希望下午能够和测试人员沟通一下他的解决方案。

小H在IM软件时组织了一个群，成员包括：小Z-该模块测试组长、小N-测试人员、小L-测试人员。小H希望能够在下午开一个讨论会，介绍昨晚测试用例失败的原因，以及希望测试人员构造更多的特殊场景进行验证测试。

13:00

在中午时，小H为了能够更好地向测试人员介绍问题的原因以及解决方法，他自己先在画图工具上画了一个简单的程序逻辑图。

到了约定时间，小H在IM上发了一条会议号信息，方便测试人员直接登入。

大家都陆陆续续拨入进来，小H向大家分享了自己的电脑桌面，开始为测试人员介绍昨晚测试用例失败的原因，以及接下来如何解决。

在会议上，小H提出，应该就这个 analyze 模块，增加一些新的特殊测试场景，以便验证在更多极限的、特殊的场景里，该模块依然能够正常工作。小H向测试人员提出了2个他认为值得添加的特殊场景。大家在会议上讨论了一番，提出了更多的验证场景，以便更加全面地验证 analyze 模块的健壮性。

在会议上，测试经理小Z让小N负责完整新的测试用例设计与开发，小L负责后续的测试验视工作。

15:54

小N从会议结束后，就开始了新的测试用例设计与开发。由于刚才已经在群里充分地讨论了新的测试场景，所以新测试程序的设计和编码都很快。

小N完成了程序编码后，看了一眼时间，15:54。

“嗯，不错不错，效率可以”小N心想。

16:13

小H修改完代码，长长地伸了一个懒腰，心想：“终于写完了”。

小H对调整的代码本地编译了一个测试版本，根据昨天失败的测试步骤模拟了一遍，测试通过。“太好了，果然是这块出现了问题”，小H心想。

代码测试通过，就可以往下走提交流程了，小H将代码上传 gitlab，并且向组长提交了一个PR请求。

同时小H在 jira 上，将本次遇到的问题详细的记录下来，包括：问题分析诊断，修改方案和后续验证方案。小H在 jira 上重新将问题单转交给组长小X。

16:21

小X留意到了 jira 的推送消息，他登陆 jira 查看了小H对问题的分析，感到非常满意。他在 jira 上将问题单移交给了测试组长，希望他能够分配测试人员完成回归测试。

同时，小X在 gitlab 上通过了本次代码的PR 合并。

在小X通过了本次 PR 后，Jenkins 系统自动触发了更新编译动作，开始为后面的回归测试提供测试版本。

17:20

在16:23 时候，测试经理小Z已经将 jira 问题单的回归测试分给了小N。

在16:51 时候，Jenkins 对最新的代码编译完成，小N从 Jenkins 系统中，拿到最新编译的测试版本，开始进行回归测试。

小N执行刚才写好的新增测试用例对新版本进行验证。

新增测试程序全部通过，测试的结果也和下午开会时小H介绍的情况一致。昨天出现的问题已经得到了解决，并且新版本引擎在更加特殊的场景里也能够保持正确。

小N使用新增测试用例对新版本引擎测试都通过后，在 gitlab 上向测试经理提交了一个新增测试用例 PR 请求，并且在 jira 上也将问题单重新发回给测试经理。

17:52

小Z在17:23时候留意到 jira 的邮件提醒，打开 jira 页面查看了一下问题单进度，发现进展还是挺迅速的，看来这个问题单，可以在今天完成，小Z在 jira 上将问题单移交给小L，希望她对新增的测试用例进行重新验视，还是再次对新版本进行验视确认。

小L看到小Z发给她的测试单时候，已经17:30了。她快速浏览了一下 jira 问题单的流程，也开始对新引擎进行正确性再次验视。下午的讨论会，小L也参加了，所以测试进展顺利，17:52就完成了所有新版本引擎的验视，新增测试用例也符合下午开会的讨论场景。

她快速地在 jira 上提交了再次验视的说明，将问题单重新发回给测试经理。

17:55

小Z再次打开 jira 的问题单页面，小L已经完成了再次验视工作，看起来一切都非常顺利。

小Z再次检查了一下 jira 上整个问题单的始末，看起来问题确实得到了很好的解决。

他关闭了问题单，也在 gitlab 上通过了新增测试用例的 PR。

小Z心想：“这个问题单就这样结束了，从 Begin 到 Close，一天的时间，时间过得真快“。

20:17

小H登上了公司的分享平台 Confluence，他希望记录下来这段时间来对引擎 analyze 模块的优化想法。

不断地整理想法，不断地思考优化，这个习惯小H已经保持很久了。他觉得这样很充实。一点一点的记录下来自己的优化心得，梳理数据库引擎中的逻辑处理，他觉得很有意思，也希望将这个感受分享给公司的其他兄弟。

21:00

Jenkins 系统自动开始每日构建，对所有新PR 进行编译。

22:37

多伦多时间 09:37。

小D是巨杉多伦多实验室的一名研发工程师。在早上的09:15，他们多伦多的团队也如常地开了一个简短的站立会。其实在上班路上，小D已经从邮箱里看到了关于 analyze 模块新PR合并的消息，他打算今天先 review 一下小H新提交的代码。

在 SequoiaDB 核心的引擎开发流程里，一般安排两个研发人员组队负责项目，小H是 analyze 模块的主要开发者，小D则负责代码 review。这种开发模式，既能够保证每次 PR 合并的代码质量，也能够在突发情况时，由 plan B 人员快速接管该模块的开发和维护工作。

小D通过 VPN 连接到公司内部的云桌面，从 gitlab 上查看最新的代码。

小D知道小H有在 Confluence 记录分享的习惯，看了小H对 analyze模块的分析和修改建议，结合着代码里的注释，小D明白了之前的代码里确实缺少了对特殊场景的处理。

小D在 Confluence 上给小H 点了一个赞，并且留言：“Nice work ! May the force be with you :) ”。

0:00

Jenkins 系统开始自动测试流程，同时也自动启动了混沌测试。

5:00

Jenkins 系统结束了所有的测试流程，向研发工程师/测试工程师发送测试结果邮件。

8:15

小H还是像往常一样已经起床、洗漱，他查看了一下 Jenkins 凌晨发出来的邮件，所有的测试用例都通过了。

小H打开电脑，心想：“今天该写新模块的入门使用文档了。嗯，今天又是元气满满的一天”，May the force be with you!

附录：

本文介绍研发流程

远程协作工具列表

后记

本文根据巨杉数据库远程办公期间的一个真实处理流程整理，文中的工程师和工作流程均是公司远程办公的真实流程状态。

作为自研技术公司，巨杉数据库成立9年以来，在研发体系、自动化测试、多地工作协调和用户支持服务等方面，搭建了完善体系，积累了丰富的经验。我们在非常时期将会保证提供一如既往的服务和支持，同时保证我们的技术研发进度不受影响。

在疫情期间，许多科技公司也受到影响，大部分工程师都采用远程在家办公。虽然不能和医护人员一样冲在前线，但是大家都用自己的努力，一直在后方支撑着前方所有的“战疫”，保证了技术不断档！

科技向好、科技向善，科技创新的最大价值从来不是公司的利润和市值，而是帮助用户提高生产力，改善人们的生活，促进社会的发展进步。

我们也借此，向广大努力奋斗的科技工作者致敬！

【巨杉数据库SequoiaDB】24 Hours , 数据库研发实录相关推荐

【巨杉数据库SequoiaDB】【巨杉访谈】分布式数据库如何存储管理非结构化数据？
SequoiaDB 巨杉数据库,是一款面向企业级的分布式 NewSQL 数据库,自主研发并拥有完全自主知识产权,没有基于任何其他外部的开源数据库源代码. 上周,在开源中国源创会厦门站活动中,巨杉数据库 ...
【巨杉数据库SequoiaDB】巨杉数据库荣获《金融电子化》“金融科技创新奖”
巨杉助力金融科技创新 2019年12月19日,由<金融电子化>杂志社主办.北京金融科技产业联盟协办的"2019中国金融科技年会暨第十届金融科技及服务优秀创新奖颁奖典礼" ...
【巨杉数据库SequoiaDB】点燃深秋，巨杉数据库亮相DTC数据技术嘉年华大会
2019年11月15日,第九届数据技术嘉年华大会在北京隆重召开,本次大会以 "开源 • 智能 • 云数据 - 自主驱动发展创新引领未来" 为主题,探索数据价值,共论智能未来.S ...
【巨杉数据库SequoiaDB】巨杉数据库 v5.0 Beta版正式发布
2020年疫情的出现对众多企业运营造成了严重的影响.面对突发状况,巨杉利用长期积累的远程研发协作体系,仍然坚持进行技术创新,按照已有规划推进研发工作,正式推出了巨杉数据库(SequoiaDB) v ...
【巨杉数据库SequoiaDB】巨杉 Tech | SequoiaDB SQL实例高可用负载均衡实践
1 前言在应用程序中,应用配置连接的数据库IP地址和端口号都是固定一个的,当所属IP地址的服务器宕机后,需要人为手工更改IP地址切换数据库服务器.同时当应用接收到成千上万的并发 http 请求时,会 ...
【巨杉数据库SequoiaDB】巨杉数据库与浪潮商用机器完成技术兼容互认证
近期,巨杉数据库与浪潮商用完成技术兼容性测试,正式发布了相互认证证书. 双方产品在兼容性.稳定性.安全性上表现良好,运行流畅.此次兼容性测试和认证工作,帮助双方在技术生态拓展上迈出了坚实一步,能够共同 ...
巨杉数据库SequoiaDB助力商业银行云化架构升级
转载自 https://blog.csdn.net/SequoiaDB_Official/article/details/89374120 作为一款金融级分布式关系型数据库,SequoiaDB巨杉数据 ...
检查集群状态命令_巨杉数据库SequoiaDB巨杉Tech | 四步走，快速诊断数据库集群状态...
1.背景 SequoiaDB 巨杉数据库是一款金融级分布式数据库,包括了分布式 NewSQL.分布式文件系统与对象存储.与高性能 NoSQL 三种存储模式,分别对应分布式在线交易.非结构化数据和内容管 ...
回滚机制_【巨杉数据库SequoiaDB】巨杉 Tech | 并发性与锁机制解析与实践
01 概述数据库是一个多用户使用的共享资源.当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况.若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性.加锁 ...

【巨杉数据库SequoiaDB】24 Hours , 数据库研发实录