一条推文询问为什么取消订阅可能“需要几天时间”。 系紧安全带，我要告诉你 极好的 在 Enterprise Development™ 中如何实现这一点的故事...
有一家银行。 您可能听说过，如果您住在英国，那么有 10% 的可能性是 ваш 银行。 我在那里担任“顾问”，薪水很高。
银行发出营销信函。 每封电子邮件的页脚都有一个小的“取消订阅”链接。 人们有时会点击这些链接。
单击链接会导致一台史前网络服务器旋转 某处 在银行里。 老实说，我花了三个星期才找到他。
每次单击链接时，此服务都会向您的内部收件箱发送一封电子邮件。 这种情况每天会发生数百次。
此前，这些信件是发送给特定员工的，但他五年前离开了。
现在这封信已转发给通讯组。 他们无法更改收件人的地址，因为它是硬编码的，并且他们无法从服务中找到源代码。 该服务是用 Java 6 编写的。
邮寄组中的信件由该银行位于海得拉巴（印度）的离岸中心的两名员工进行检查。 他们努力工作并完成任务 很棒但该死的，这工作实在是难以忍受。
我通过视频会议与他们沟通，他们具有企业创伤后综合症的所有迹象。 他们与这种无意义的行为作斗争 多年来 并在这段时间里 没什么 没有改变。
当一封信到达时，他们必须执行一个 SQL 脚本来确定取消订阅的地址是否属于银行客户端（那么协议就是一个）或不属于（那么协议就是另一个）。
如果接收者是客户，他们需要运行另一个 SQL 脚本来更新 ETL 前环境中的客户记录。 所有更改均由苏格兰的独立团队于伦敦时间 16:00 进行审核。 如果更改通过验证，则会应用到真实数据库 改天 在16中：00。
如果收件人不是客户，他们会将其添加到 Excel 电子表格中，并在回家之前将其发送给斯温顿的营销团队。
营销团队使用茶叶和其他神秘实践来确定客户是否“具有潜在重要性”（根据内部规定，“长达 48 小时”）。 如果不是，则将该地址添加到另一个表中并发送回印度以执行另一个 SQL 查询。
如果营销人员将客户识别为“重要”，则会手动向他们发送一封类似“您确定真的要取消订阅吗？”的信件。 看起来像是自动生成的，但实际上并不是。
如果他们回答“是”（最初需要用大写字母写“是”），那么斯温顿的团队就会将他们送往印度 第三 表中，下一个脚本将被郑重执行。
如果我没记错的话，平均需要 四个工作日。 平均每天约有 700 人取消订阅，其中 70% 是“潜在重要的”。
顺便说一句，这两个印度人调到了我们的开发团队，并成为了系统的 PM，取代了所有这些废话。 他们是我有幸共事过的最善良、最富有同情心和最勤奋的人。 多亏了他们，这个噩梦般的公司流程这些年来才运转得如此“顺利”。 后来他们搬到了英国，其中一人现在管理着一个拥有 40 多名员工的部门。
译者注：KDPV 上的猫头鹰 - .
来源： habr.com