这是描述如何提高Citymobil的服务可用性的系列文章的最后一部分（您可以在
此处阅读上一部分）。 现在，我将讨论另一种中断类型，以及我们对这些中断所得出的结论，我们如何修改开发流程以及所引入的自动化。
1.错误发布：错误
这是最令人不愉快的中断和事件。 除了最终用户或企业用户的投诉外，唯一没有任何明显症状的类型。 这就是为什么这样的事件（尤其是很小的事件）在生产中可能会被暂时忽略。
所有其他类型的中断都或多或少类似于“不良版本：500个内部服务器错误”。 唯一的事情是它们不是由版本触发的，而是工作负载，手动操作或外部服务问题引起的。
为了描述处理此类中断的方法，我们应该回想起一个老笑话：
给数学家和物理学家提供相同的任务：烧开水。 为他们提供了一些辅助工具：火炉，水壶，带水的龙头和火柴。 他们俩轮流向水壶中注水，打开燃气并开始加热水壶。 然后简化了任务：为他们提供一个装满水的水壶和一个已经打开的炉子。 任务是一样的-烧开水。 物理学家把水壶放在火炉上。 数学家倒空了水壶，关掉了煤气，说：“问题已经解决了。” ©anekdotov.net
必须不计一切代价将这种中断减少为“错误发布：500个内部服务器错误”。 理想情况下，错误的记录方式应与500个错误的记录方式相同。 但是，当然，您不能记录错误事件，因为如果可以的话，您一开始就不会犯错误。
跟踪错误的想法之一是在数据库中搜索跟踪。 这些跟踪使我们能够看到存在错误并发出警报。 我们如何对此提供帮助？ 我们开始研究每个大错误并提出解决方案：可以创建什么样的监视/ SMS警报以使该错误立即显示为500错误？ 这里有一些例子。
1.1。 错误导致的中断示例
突然，我们收到了来自用户的大量投诉：无法关闭通过Apple Pay支付的订单。 我们开始调查； 问题是在测试环境中重现的。 找到了根本原因：我们更新了信用卡的到期日期格式，因为它被付款处理服务更改了，但是对于通过Apple Pay付款，我们没有正确执行； 因此，所有Apple Pay付款均被拒绝。 我们一知道问题就将其修复，部署并解决了问题。 但是，此问题已存在45分钟。
发生此问题后，我们监控了许多Apple Pay付款失败的情况，并创建了一些非零阈值的SMS和IVR警报（因为该服务认为某些未成功付款是正常的；例如，如果客户的账户中没有钱）或她的信用卡被屏蔽）。 从那一刻起，我们将立即发现阈值交叉点。 如果新版本对Apple Pay的处理造成任何问题，我们将通过监控立即发现该问题，并在3分钟内回滚该版本（手动回滚的过程在前面的一篇文章中进行了介绍）。 因此过去曾经是45分钟的部分停机时间，而现在是3分钟。 赢利！
1.2。 其他例子
订单列表中的错误。 我们在驱动程序应用程序中优化了订单列表。 该代码有一个错误。 结果，有时驾驶员看到空订单列表。 我们偶然发现了这个错误：一位工程师正在使用驱动程序，并遇到了这个问题。 我们很快发现了不良版本，并立即将其回滚。 因此，我们根据数据库中的信息创建了列表中平均订单数的图表。 然后，我们逐月回顾了该图。 我们注意到由该错误引起的最近一次山沟，并通过SQL查询创建了SMS警报。 当列表中的平均订单数超过根据当前月份的最小值设置的下限阈值时，它将构建此图。
Cachback中的错误。 我们正在更改用户的现金返还赠与逻辑。 除其他外，我们将其发送给错误的客户群。 问题已解决，创建了现金返还图表； 我们看到它急剧增加，并且还注意到这从未发生过，并创建了具有适当阈值的SMS警报。
再次是付款错误。 新版本导致了该错误-订单需要花很长时间，卡付款无效，司机要求客户以现金付款。 我们通过呼叫中心投诉发现了问题所在。 我们部署了一个修复程序，并通过历史图表分析发现了带有阈值的订单的关闭时间警报。
如您所知，我们正在使用相同的方法来处理所有此类事件：
- 我们发现一个问题。
- 我们对其进行故障排除并找到代码中的错误。
- 我们修复它。
- 我们找出数据库中的痕迹（也可以在Web服务器日志或Kibana中找到痕迹），这些痕迹可以指出问题的征兆。
- 我们建立这些痕迹的图形。
- 我们回到过去，看看图表中的起伏。
- 我们为警报选择了一个好的阈值。
- 当问题再次出现时，我们立即通过SMS警报找到有关问题。
这种方法的优点是：一张图表和一个警报可以解决整个大问题（问题组的示例：无法结清订单，额外奖金，Apple Pay付款不通过等）
最终，我们将每一个大错误实施了警报和监视，作为我们工程文化的一部分。 为了不丢失这种文化，我们将其正式化。 我们开始强迫自己为每次故障创建报告。 该报告的表格填写了以下问题的答案：根本原因，我们如何解决，业务影响，要点。 所有字段均为必填项。 因此，我们必须得出结论，我们是否喜欢它。 显然，此过程更改已记录为“做”和“不做”。
2. Kotan
我们的流程自动化水平正在提高，我们认为是时候创建一个可以显示当前开发流程状态的Web界面了。 我们将此网络界面称为“ Kotan”（俄语单词“ roll”，“ roll out” :-）
“ Kotan”具有以下功能：
事件清单 。 它包含过去警报中触发的所有事件的列表-要求立即做出人为反应的事件。 对于每个事件，我们都会记录它的开始时间，结束时间（如果已经结束），链接到报告（如果事件结束并且有报告）和警报指南链接，以查看此事件的警报类型属于。
警报目录 。 这实际上是所有警报的列表。 更清楚地说，警报和事件之间的区别如下：警报就像一个类，而事件-是一个对象。 例如，警报为“ 500个错误的数量大于1”。 并且“ 500个错误的数量大于1，并且在这个日期发生了，此时，持续了这么长时间”-是一个事件。 在解决了某些从未由警报系统检测到的特定问题之后，通过上述过程将每个警报手动添加到系统中。 这种迭代方法保证了误报的风险低（不需要采取任何措施）。 该目录包含每种警报类型的完整报告历史记录。 可以帮助您更快地诊断问题：您会收到警报，转到“ Kotan”，单击“目录”，查看所有历史记录并获得有关在何处潜水的想法。 成功进行故障排除的关键是掌握所有信息。 警报源代码的链接（以确保知道此警报在什么情况下向您发出信号）。 对抗此警报的最佳最新方法的书面说明。
报告书 这些都是历史上的所有报告。 每个报告都有与之关联的所有事件的链接（有时这些事件按组分组；根本原因是相同的，并且我们为整个组创建了一个报告），该报告的撰写日期，问题解决方案确认标志以及大多数重要的是：根本原因，解决方法，对业务的影响和收益。
外卖清单 。 每个外卖都有注释，说明是否已实施，是否仍要实施或不需要（说明为什么不这样做）。
3.软件开发过程中发生了什么变化？
可用性改进的关键组成部分是软件开发过程。 这个过程在不断变化。 此类更改的目标是减少发生事故的机会。 修改流程的决定不应抽象地做出，而应基于经验，事实和数字。 整个过程绝不能从总监的角度进行，而应由下而上地在所有团队成员的积极参与下进行，因为整个团队的许多负责人要胜过经理的一个主管。 该过程必须得到遵循和监控； 否则，没有意义。 团队成员必须相互纠正以防出现分歧：还有谁会为他们做这些呢？ 必须要有最大程度的自动化来照顾主要功能，因为人类会不断犯错，尤其是在创造性工作中。
为了确保每个事件都能解决，我们做了以下工作：
- 每个警报都会自动阻止发布。
- 当我们收到关闭警报（一条短信指出事件已结束）时，我们不会立即取消阻止发布，而是为我们提供了一份事故报告。
- 报告必须包含以下信息：事故的根本原因，如何解决，业务影响，要点。
- 该报告由对事故进行故障排除的团队撰写。 那些掌握有关事故的完整信息的人。
- 在创建和批准此类报告之前，发布会被自动阻止。 这激励团队在事故修复后立即集中精力并创建报告。
- 该报告必须得到非团队成员的批准，以确保该报告包含理解该报告所需的所有信息。
这样，我们一方面在保存每个事件的历史记录方面实现了自律，另一方面，我们提供了自动控制功能。 现在不可能不得出结论或不写报告。
4.代替结尾
代替结尾，让我快速总结一下我们在软件开发过程中所做的更改，以减少丢失的行程。
感谢您阅读到最后。 祝您生意兴隆！ 希望您能少丢失订单，交易，购买，旅行以及对您而言至关重要的一切！