早上 8 ：34 

睡眼惺忪的我打开手机，便看到群里已经热闹起来

“又有线上问题了”

“服务器连不上去了”

…..

我心里虽然有些波澜，但却并没有很担心。想想从第一次遇到类似上线问题时的提心吊胆，到如今碰到类似问题的”越发淡定“也就仅仅过去了几个月的时间。

8:45

客户在微信群里反映，“登不上故事卡墙了 😭, 没法测uat了“。

我边刷牙边想，”客户太勤奋了吧，还要在9点会议前争分夺秒测试。“

“jira之前也有这种暂时登录不了的情况，您别着急，稍等一会儿” 在群里安抚完客户之后，我打开电脑，连vpn，输入验证码，一系列熟练的操作后，刷新之前打开的jira板子，果然也遇到了和客户一样的404报错的现象。为了多试几次，我还细(shou) 心（can)的把之前我所有已经缓存的页面都刷新试试，结果当然是一片报错。

此时的我，还天真的以为，这次只是像之前多次类似系统不稳定一样的暂时现象，也从没想过jira板子的消失和早晨的线上问题是同源。

9:30

机智的同组小伙伴，没有像我一样手残的刷新板子。站会依旧可以有条不紊的进行。

直到站会结束，处理完一些琐碎的事情之后；jira依旧打不开，此时的我才意识到，可能不是暂时的系统问题了。从群里得知，起码今天恢复没有期望的结果之后，我突然有些手足无措。

“没有了板子，我们还能正常开卡和DC吗？QA同学的测试会不会受到影响啊；我在进行的业务沉淀还能顺利继续吗？“

仿佛是本来信心满满的开卷考试，突然被没收了小抄。连本身早应烂熟于心的知识点，都有些不确定。

9:45

在又抱着侥幸刷新了几次无果之后，我定了定神，想到了几条不幸中的万幸：

1. 团队在项目开始之初，就建立了共同维护test case的Trello板子，需要dev同学在卡开前先拟写case，再在开卡和测试期间，由BA和QA同学一起补充。Trello 上的case 往往不仅会比jira上的AC更全，同时还有TL拆的工序，开卡结卡注意事项等重要信息。所以，对于QA和已经开卡的dev小伙伴来说，Trello其实已经作为他们工作期间的主要工具，jira的消失影响不大。

2. 对于BA来说，

    首先，关于需求沟通和澄清的工作。庆幸的是，项目已经接近尾声，大部分和客户需要确认的内容已经完成。即使有少量的细节需要和客户再次确认，使用邮件或微信沟通的方式即可。对于jira板子的依赖不大。

  其次，关于项目迭代规划的工作。得益于刚上项目时，受到Senior BA的启发，除jira卡墙外，我自己还维护了一个虽然凌乱但是比较完整的迭代计划在google sheet上。虽然只有卡号和卡的标题，但是剩余一个半迭代的卡已经按照优先级准备就绪，可以随时拿出来当临时的卡墙。

    最为感恩的是，测试系统的大部分功能并未受到影响，可以通过系统操作，唤起大部分的记忆。

3. 对于客户来说：虽然现在即将到了uat测试比较密集的阶段，但还好我们的项目不是by迭代上线。距离最后真正上线还有一定的时间。即使勤奋的客户被迫需要“休息”两天，jira的临时罢工，不会严重影响到上线前客户uat测试的进度。

综合以上几点，我有些烦躁的心，满满放松下来，开始工作。微信群里也少有因为jira打不开的问题而产生的抱怨，

“看来小伙伴们和我一样，都有各自的backup法宝呀“ 我高兴地想

虽然工作都在看似有条不紊的进行，但是到了快中午的时候，我发现，jira的出走，还是给我们带了一些困难。

毫无疑问，开卡成为了最大挑战。之前流程是，dev小伙伴会在开卡前，根据AC维护test case在Trello上，并且列出对于业务的”puzzle”，在开卡的时候和BA求证。现在这套流程已经不再成立。

其次，由于项目是属于遗留系统改造，除了增加新的功能外，保证原有系统逻辑不受影响也是项目成功的重要标准之一。但部分原有功能背后计算逻辑复杂，页面信息较少，且属于早期确认的需求；导致记忆比较模糊，有些细节我不能完全确认。

同时，由于正处于项目尾声。我还在对负责的模块进行业务沉淀的工作。主要的流程已经有很多成熟的文档，我就想对当时一些比较细节和tricky的逻辑进行总结，帮助后人避坑。然而，由于我一直拖延，很多在2月/3月聊的需求的细节场景单凭记忆很难回忆起来….

最后，对于QA测试，即使我们有Trello神器，但遇到需要参考流程图，计算案例，导入文件样例，跨squad卡的链接等需求时，只有干巴巴简单文字的Trello就显得有些爱莫能助。增加了QA小伙伴再去重新找这些资料的时间成本。

为了尽可能降低jira事件对我们的影响，我做了如下尝试：

1. 根据之前自己维护的迭代计划，迅速重新将正在开发和还未开发的卡维护到一个新的Google Doc上，同时让大家也“挂自己的的名字”上去，建立了一个简陋的新卡墙。同时，卡的进度也同样标在上面，供qa小伙伴参考.

2. 通知dev同学，在开卡前先找我熟悉该卡业务流程和知识，共同pair写test cases. 先明确可以确认开发的部分，少量我回忆不起来的细节逻辑先标注，等我确认之后再补充。

3. 同时，针对以上记忆模糊的部分，我通过系统还原，寻找历史文档，会议纪要等方式尝试努力回忆。

4. 关于我正在进行的业务沉淀，庆幸QA团队一直都在Cucumber上按照feature 维护了完整且详尽的test case; 在google drive的各处也留存着我当时梳理的流程图、会议纪要，甚至成为了比jira卡更加完美的backup.

于是，dev小伙伴们，从之前问我 “ yiying, 有时间开卡吗？“ 到如今，变成 ”yiying, 这个卡你还记得多少？“

总而言之，即使我们暂时失去了这一之前视为团队第二个大脑的核心资源库，同学们依旧用各自的方式，群策群力继续项目的进度。

第二天早上, 

8 : 45 

那位勤奋的客户依旧因为测不了uat在群里的”哀嚎”：

“Early birds have no feed😩"

jira的恢复还遥遥无期，而我们却没有了第一天的慌乱。

至今，时间早已过去了24小时，心心念念的板子还没恢复，

但通过这次小意外，我想我们都有了一些收获：

1. 团队之初维护的Trello板子无疑立了大功。虽然不知这种方式是否是交付项目的常规操作，但是有一个成员们共同维护的“备份看板”，避免了给我们本就有些落后的测试和开发进度雪上加霜。至今还很佩服PM和TL当年的英明决策 👍。

2. 作为BA，在一个除正式看板之外的固定地方，实时维护和更新一个比较完整的迭代计划。不仅可以在此类问题发生时，作为backup。同时，还可以在这个“非正式看板”上track 签卡进度，团队开发进度，开发真实时长和估点之间的gap，相关问题记录等其他信息；也是每次我和TL过迭代计划时最主要的沟通工具。

3. 及时维护的test cases 在此次“jira消失“事件中也起到了非常关键的作用。无论是我们Trello板子上的case，还是QA小伙伴自己的一套xmind，或者是在Cucumber上非常完善的版本，都为不同的场景给予了support.  （虽然有些是得益于客户的强烈要求😂）

4. 关于业务沉淀，一定要及时整理！！对于我这种大学期间，最擅长考前突击的选手，本次意外，就好像，临考前ppt和笔记都丢了，由于平时也没有及时复习的习惯，一定会手忙脚乱。重要的流程图，会议纪要，场景分析的文档也要及时在过程中归类整理，有助于之后迅速定位，也方便后人参考。

    其实，即使没有这次的事件，今年1、2月份那些更多涉及到实际业务场景，用户使用习惯等偏“WHY“的知识也多少有些淡忘。如果当时及时总结，也可以很好地避免我最近再去和客户请教时，却被反问 ”你是要准备出书？“的尴尬场面🙈。

写到此，好像到了每篇文章应该的”升华“之处，

其实，工作生活中，类似强依赖于单一设备/渠道储存重要信息和文件的现象屡见不鲜。本人也经历过，电脑进水、系统重装、账号无法找回，手机丢失等各色情况，但还是一直在懒于备份和怀揣侥幸的心态中度过。

相信经历了”jira消失的第 72 小时“后，会给我一些新的启示。

最后，祝福jira早日康复。