我们崩溃并丢失了所有基本数据日志。 我们哪里错了？

放松，没有人迷失森林。

他们失去的是大量必要的数据日志。

此处的主题公司称为TheCompany。 发现问题的开发人员是Bob。

在本文中，我想讨论软件开发中的人为错误以及针对这些错误的预防措施。

从开发到生产

公司流程 部署代码库更改的过程总结如下：

1. 开发人员测试自己的更改（在列表中被归类为常识项，因此未强制执行）
2. 代码审查（仅需要一名审查员，他们通常花很少时间在机票上）
3. 推向预生产
4. 试生产中的测试
5. 在进行生产之前先检查清单
6. 在推向生产过程中检查清单
7. 进入生产后再检查清单

该清单与飞行员的起飞前清单进行比较。 如链接文章中所述：

[…]实用测试标准明确指出，飞行员必须使用适当的书面检查表

您不会争论是否需要在飞机起飞前对所有系统进行检查，对吗？ 如果机场工作人员会说飞行员跳过了一些检查以便能够更快起飞，那么您会登机吗？

我知道我不会。

然而，事故记录表明，一些飞行员没有[遵循清单]。 这样的动作会产生可怕的结果。

该公司不是航空公司，他们犯错的代价很可能不是生命。 但是，它们确实影响了公司的底线，在最坏的情况下，这会使人们被放开。

在TheCompany中 ，共有3个清单-1）制作前，2）制作中和3）制作后

试生产清单：

1. 在团队日历中安排推送到生产的时间
2. P ULL [R eQUEST的已审查和批准
3. 受影响的团队测试并批准更改
4. 指定的测试人员确保所有测试用例均通过并满足要求
5. 票证与测试或生产环境没有冲突
6. 在台式机和移动设备上运行冒烟/回归测试

生产期间检查清单：

1. 发布管道中没有当前事件（构建失败）
2. 没有同时发出当前的票证
3. 在Slack中宣布催动已经开始
4. 按下红色按钮即可开始生产

后期制作清单：

1. 检查部署脚本日志以查看探测是否成功
2. 在台式机和移动设备上运行冒烟/回归测试
3. 监视所有日志和图形1小时
4. 通知受影响的团队
5. 如果没有问题，请在Slack中宣布部署成功

显然，有很多事情可能出问题，而将责任归咎于特定原因是看不到整体情况。 因此，让我们解开一些上述要点，

1. 为什么出问题了
2. 如何预防
3. 什么 TheCompany做善后。

灾难食谱

这就是问题发生并导致大量日志丢失的原因。

1. P ULL [R eQUEST的载有轻微改变的代码行可能被视为一个黑客也有一个模糊的描述
2. 在同一PR中 ， Bob并未测试程序流的1/3，因为他认为程序流与其他流程相同
3. 代码审阅者没有注意到黑客行的变化
4. 测试案例来检查即将被破，日志没有被添加鲍勃（注：有 质量 一 ssurance人 短缺 的公司）
5. 也是代码审查者的测试者没有注意到未发送日志请求（注意：如果没有 质量检查 ，代码审查者将成为测试者）
6. 在投入生产和监视期间，未注意到丢失的日志，因为与其他日志相比，图表中的下降幅度太小
7. 每天没有日志和图形监视。 因此，没有人注意到这个问题
8. 下一个投入生产的PR要么不遵循清单，并且/或者没有注意到图表中的下降，即与步骤6相同。

如何避免损失

应该执行7天时间日志检查

在发布期间，开发人员通常只检查最近1-4个小时的日志。 这意味着，如果任何早于4个小时的生产版本的日志中都有异常，它将再次被忽略。 这个循环理论上可以永远持续下去。

实际上， Bob通过进行为期7天的时间日志检查已经发现了多个错误。 到目前为止，没有人-无论是管理层还是开发人员-都认为7天的期限是必要的。

时间也不是问题，因为开发人员可以快速切换日志以显示7天1天1小时。

日常监控

当前没有适当的每日日志监视。 它们是在清单的范围内完成的，仅此而已。 一种解决方案是在一天结束时实施日志强制检查。

当我在拉脱维亚的Evolution Gaming工作时，我的团队担任轮换角色，负责人员检查Sentry错误日志，将待处理的Pull Request审核通知团队，进行日常维护等等。 在整个冲刺（2周）中 ，每天都有角色和分配给一个人的角色。

为了确保所有这些操作都正确无误地执行，我们还在这些流程中添加了一种博弈机制，例如每次拉动请求审核的要点。

我们都可以谈论应该如何进行审查，但是现实是，人们经常忘记或被其他任务所淹没，只是不想进行代码审查或其他许多原因。 激励是管理其中一些摩擦点的好方法。

TheCompany可以在监视方面采用相同的方法。 除非您是一家刚刚在A轮融资中筹集了1亿美元的初创公司，否则您肯定有时间投资这些有价值的活动，从长远来看，这对所有人都有利。

2个批准者或更多

我所参与的每个团队都有一个有效的代码审核流程，每个PR至少要获得2个批准。 事实证明，这样做非常有益，以至于我什至在我的自由职业合同中都尝试执行这种方法。

一个批准人常常不够的主要原因与为什么需要至少两名飞行员驾驶飞机相同。 如果一个人忘记拨动面板上的开关，则另一位飞行员在那里纠正错误。

更好的测试

无论其单元测试还是集成测试。 它们是您的安全网。

集成测试未涵盖代码的hack部分。 实际上， TheCompany没有Bobs团队的集成测试，要引入它们的斗争异常艰巨。 不是因为技术上的困难，而是因为缺乏连贯性，动机和（也许）无知。

从主观上讲，大多数开发人员不进行测试的第一原因是因为“为什么要打扰它是否已经可以工作，而我却可以更快地将某些东西一起破解，而不必考虑测试的麻烦” 。

＃2的原因是截止日期短。

如果我们谈论单元测试，有时人们很难看到它们的好处，因为很难量化它们实际上可以阻止多少个错误。

事实是，单元测试可以防止开发期间的错误。 您的项目很可能在投产之前已经运行了测试。 因此，即使1个测试失败，合并也会中止。 这使您有机会解决问题并再次推送。

更好的是，以观察模式运行测试。 我看到开发人员在后台运行没有进行测试的程序，却发现自己花费太多时间试图回溯其更改。

即使在观看模式下，您也可能陷入工作中而走得太远。 这可以通过采用重构方法来防止。 在Martin Fowlers撰写的有关重构的书中，他建议在保持绿色的同时进行精心的重构，即，如果测试失败，请还原最后的更改并以不破坏测试的方式实施。 他采用的方法是“一次只更改1行”。 当然，根据情况的琐碎程度，您可以调整此方法。

然后是TDD。 一些研究表明，TDD可将您的项目从40％的bug节省到90％的bug 。 尽管从长远来看，这种方法已被证明是有益的，但开发人员更反对这种方法。 如果您不打算很快破产，那是您要考虑的问题。 高测试标准还赋予了与其他公司竞争的优势。

实施集成测试

当然，某些代码流可能难以用单元测试覆盖，甚至看起来像是在进行集成/单元测试混合。 这是一个棘手的问题。 在这种情况下，我想记住桑迪·梅斯的建议：

• 桑迪·梅斯（Sandy Metz）在Rails Conf 2013上的演讲— https://www.youtube.com/watch?v=URSWYvyc42M

我可能会考虑使用充当集成测试的单元测试来涵盖黑客。 使其尽可能地小。 引入大量文档，并创建票证以在引入适当的集成测试后立即删除测试。

另外，我不是集成测试的专家，但是在这种情况下，它们可以防止丢失数据日志。

极端所有权

我想提到的最后一点是关于Jocko Willinks的书“极端所有权”的教训。 我坚信，未能理解遵循清单的重要性部分在于团队的主管（技术主管或项目经理）以及开发人员本身。

开发人员和质量保证人员未严格遵循检查清单的事实意味着，对于它们的重要性以及在缺少一个步骤的情况下可能会出现什么问题的了解并不十分清楚。 当然，这也可能是因为主管不了解流程的某些部分。 在这种情况下，“报告命令链”是开发人员和QA的工作。

后果是什么

在将PR推入生产环境7天后，用于比较服务器和客户端日志的提示机制就已开发出来。 它会通知服务器和客户端日志之间的任何差异。

Bobs团队开始引入每周监视日志的过程。 但是，主管人员对此没有任何后续行动。

幸运的是，已经开始进行对话以解决诸如此类的未来问题。

可以采取大量行动来改善公司的流程。 防止代码外部或内部失败的活动。 但是，不幸的是，有一件事肯定是我们人类需要一场灾难才能说服我们做好准备的重要性。

From: https://hackernoon.com/how-to-lose-14m-logs-because-of-ec7f32c9