这是“ Citymobil-在初创企业业务增长中提高可用性的手册”系列的第二篇文章。 您可以在
这里阅读第一部分。 让我们继续谈论我们设法改善Citymobil服务可用性的方式。 在第一篇文章中，我们学习了如何计算丢失的行程。 好的，我们在数他们。 现在怎么办 既然我们已经配备了可以衡量损失行程的易于理解的工具，那么我们可以转到最有趣的部分-我们如何减少损失？ 在不减慢我们目前的增长速度的情况下！ 由于在我们看来，造成旅行损失的大部分技术问题与后端有关，因此我们决定首先将注意力转向后端开发过程。 超越我自己，我要说的是我们是对的-后端成为丢失行程之战的主要地点。
1.开发过程如何进行
这些问题通常是由代码部署和其他手动操作引起的。 从未更改和用手触摸的服务有时也会发生故障，但是，这是一个例外，仅证明了规则。
以我的经验，最有趣和最不寻常的例外是以下情况。 早在2006年，当我在一家小型Webmail服务公司工作时，就有一个网关代理所有流量，并确保IP地址不在黑名单中。 该服务在FreeBSD上运行良好，并且运行良好。 但是有一天它刚刚停止工作。 猜猜为什么？ 该计算机中的磁盘发生了故障（坏块已经形成了一段时间，这是不可避免的），并且发生在服务故障之前的三年。 发生故障的磁盘一切都正常。 然后，FreeBSD出于自身已知的原因，突然决定解决发生故障的磁盘并因此暂停。
当我10岁至12岁的孩子时，我和父亲一起去树林远足，听到他的一句话我从未忘记：“保持篝火燃烧所要做的就是不要碰它”。 我相信我们大多数人都可以记住一种情况，那就是当我们向已经燃烧的火中倒入一些木头时，木头会无缘无故熄灭。
最重要的是，问题是由人类的手动操作造成的； 例如，当您将木头喂入已经燃烧良好的篝火时，从而减少了氧气并杀死了火，或者将带有错误的代码部署到了生产中。 因此，为了了解导致服务问题的原因，我们需要了解部署和开发过程的工作方式。
在Citymobil，该过程完全以快速发展为导向，并通过以下方式进行组织：
- 每天20-30个发行版本。
- 开发人员自己执行部署。
- 开发人员在测试环境中进行快速测试。
- 最少的自动化/单元测试，最少的审查。
开发人员在没有质量保证支持的恶劣条件下工作，产品团队和实验承担了大量重要任务。 他们尽可能专心，始终如一地工作，以简单的方式解决艰巨的任务，确保代码不会变成意大利面条，他们了解业务问题，负责任地处理更改，并迅速回滚不起作用的东西。 这里没有新内容。 我八年前开始在Mail.Ru服务中遇到过类似情况。 我们快速，轻松地启动了
Mail.ru Cloud，没有序幕。 我们将不断改变流程，以实现更高的可用性。
我敢打赌，您已经注意到了自己：当没有任何限制时，只有您和生产时，当您承担着沉重的责任时，您就在创造奇迹。 我曾经有过这样的经历。 很久以前，我几乎是Newmail.Ru Webmail服务的唯一开发人员（它是在不久前收购的，然后又被删除了）。 我自己进行了部署，并通过
if (!strcmp(username, "danikin")) { … some code… }对自己进行了生产测试。 因此，我对这种情况很熟悉。
我发现这样的“快速而肮脏的”方法被成功的和没有成功的许多初创公司所使用，我不会感到惊讶，但是所有这些都是出于一种激情-对快速业务增长和市场份额的渴望。
为什么Citymobil会有这样的过程？ 开始的开发人员很少。 他们已经为公司工作了一段时间，并且非常了解代码和业务。 该过程理想地在这些条件下工作。
2.为什么出现可用性威胁？
由于我们的产品计划变得更加积极，导致产品开发投资的增长，并且我们开始雇用更多的开发人员。 每天的部署数量在增加，但是自然而然，由于新员工不得不在现场条件下投入系统和业务，其质量下降了。 开发人员数量的增加不仅导致线性增长，而且可用性出现二次下降（部署数量呈线性增长，平均部署质量呈线性下降，因此“ linear” *“ linear” =“ quadratic”）。
显然，我们不能那样做。 该过程并非针对这些新条件而构建。 但是，我们必须对其进行修改，而不能缩短产品上市时间。 也就是说，每天保留20到30个发布版本（考虑到它们的数量会随着团队的增长而增长）。 我们发展迅速，我们进行了许多实验，迅速评估了结果并进行了新的实验。 我们快速测试了产品和业务假设，并从中吸取了教训，并提出了新的假设，我们又迅速对其进行了测试，依此类推。 我们决不会放慢脚步。 此外，我们希望加快速度并更快地雇用开发人员。 因此，我们针对业务增长的行动造成了可用性威胁，但是我们绝对无意修改这些行动。
3.确定任务已设置，过程已清除。 接下来是什么？
拥有在Mail.Ru电子邮件服务和Mail.Ru Cloud上工作的经验，其中在某些时候已将可用性设置为第一要务，每周进行一次部署，所有内容都由自动化和单元测试以及代码至少被审查了一次，但有时甚至是三遍，我都面临着完全不同的情况。
您会认为一切都非常简单：我们可以在Citymobil复制Mail.Ru电子邮件/云过程，从而提高服务可用性。 但是，正如他们所说-细节在于：
- Mail.Ru电子邮件/云中的部署每周进行一次，而不是每天进行30次； 在Citymobil，我们不想牺牲排放量。
- 在Mail.Ru电子邮件/云中，代码已被自动/单元测试覆盖，在Citymobil，我们既没有时间也没有资源； 我们将所有后端开发工作投入到假设和产品改进测试中。
就是说，尽管后端开发人员被迅速雇用，但我们还是人手不足（特别感谢Citymobil招聘人员-世界上最好的招聘人员！我认为关于我们的招聘流程将另作文章） ，因此我们无法解决测试和审查问题而不降低速度。
4.当你不知道该怎么做时，从错误中学习
那么，我们在Citymobil所做的神奇的事情是什么？ 我们决定从错误中学习。 从错误中学习服务改进方法与时俱进。 如果系统运行良好，那就很好。 如果系统运行不正常，那也很好，因为我们可以从错误中学习。 说起来容易。。。实际上，它也可以轻松完成。 关键是要设定目标。
我们如何学习？ 首先，我们开始认真地记录每笔大，小故障的信息。 老实说，起初我真的不想这样做，因为我希望能创造奇迹，并认为断电只会自己停止。 显然，什么都没有停止。 新现实无情地要求做出一些改变。
我们开始在Google Docs表中记录所有中断。 对于每次中断，都有以下简短信息：
- 日期，时间，持续时间；
- 根本原因
- 解决此问题的措施；
- 业务影响（旅行损失次数，其他结果）；
- 外卖。
对于每次大故障，我们将创建一个单独的大文件，其中包含从中断开始到结束的每一分钟的详细描述：我们做了什么，做了什么决定。 通常称为验尸。 我们会将这些事后评估的链接添加到常规表中。
创建这样一个文件的一个原因是：得出旨在减少旅行损失次数的结论。 明确什么是“根本原因”和什么是“要点”非常重要。 这些词的意思很清楚。 但是，每个人都能以不同的方式理解它们。
5.我们从中了解到的停机示例
根本原因是需要解决的问题，以避免将来再次发生此类事故。 和结论-消除根本原因或减少其复活的可能性的方法。
根本原因总是比看起来更深。 外卖总是比看起来更复杂。 您应该永远不要对所谓的根本原因感到满意，也不要对所谓的陈述感到满意，这样您就不会放松并停在看起来正确的地方。 这种不满产生了进一步分析的火花。
让我给你一个真实的例子：我们部署了代码，一切都崩溃了，我们回滚了，一切都重新开始了。 问题的根本原因是什么？ 您会说：
部署。 如果您没有部署代码，那么就不会发生意外。 那么，收获是什么：没有更多的部署了？ 这不是一个很好的外卖。 因此，这很可能不是根本原因，我们需要更深入地研究。
有错误的部署。 那是根本原因吗？ 好吧 我们该如何解决？ 你会通过测试说。 什么样的测试？ 例如-所有功能的完整回归测试。 这是一个很好的外卖，让我们记住它。 但是在实施完整回归测试之前，我们需要在此时此地提高可用性。 我们需要更深入地挖掘。
部署时由于数据库表中的调试打印而导致的错误； 我们使数据库超载，并且在负载下崩溃了。 听起来更好。 现在很明显，即使是完整的回归测试也无法使我们摆脱这个问题。 由于测试数据库上不会有类似于生产工作负载的工作负载。
如果我们进行更深入的研究，此问题的根本原因是什么？ 我们必须与工程师交谈才能找到答案。 原来，工程师习惯了数据库能够处理任何工作负载。 但是，由于工作负载的快速增长，当时的数据库无法处理前一天的工作。 我们中很少有人有机会为每月增长50％的项目工作。 例如，对我来说，那是第一个这样的项目。 投入这样的项目后，您便开始理解新的现实。 遇到它之前，您永远不会知道它的存在。
工程师提出了解决问题的正确方法：调试打印必须在一个文件中完成，该文件应通过cron脚本在一个线程中写入数据库。 如果调试打印过多，数据库将不会崩溃； 调试数据只会早晚出现。 显然，该工程师已从他的错误中吸取了教训，不会再犯了。 但是其他工程师也应该知道这一点。 怎么了 需要告诉他们。 如何让他们听？ 通过从头到尾告诉他们整个故事，列出后果并提出正确的做法； 以及通过听和回答他们的问题。
6.从这个错误或“做与不做”中，我们还能学到什么？
好的，让我们继续分析这种中断。 公司发展迅速，新工程师不断涌入。 他们将如何从这个错误中学习？ 我们应该告诉每个新工程师吗？ 显然，会有越来越多的错误-我们如何使每个人都从错误中学习？ 答案几乎很明确：创建一个“做”和“不做”文件。 我们将把所有要点写入此文件。 每次更新“做与不做”时，我们都会在工作组聊天中向所有新工程师和所有现任工程师显示此文件，强烈敦促大家再次阅读该文件（以重新阅读旧信息并查看新的）。
您可能会说，并非每个人都会仔细阅读。 您可能会说大多数人会在阅读后立即忘记它。 而且您在两个帐户上都将是正确的。 但是，您不能否认某些东西会粘在某人的脑海这一事实。 这样就足够了。 根据Citymobil的经验，工程师非常重视此文件，而很少忘记一些课程的情况很少发生。 忘记这一课这一事实可以看作是一个问题。 我们应该得出一个结论并分析细节，以找出将来改变某些事物的方式。 这种挖掘导致“做与不做”中的措词更加准确。
从上述中断中得出的结论：创建一个“做”和“不做”文件； 写下我们从中学到的一切，向整个团队展示文件，要求每个新手学习它，并鼓励人们提出问题。
我们从停运审查中得出的一般建议：我们不应该使用单词“ shit事件”的组合。 只要您大声说出来，每个人都认为不需要做任何事情，也不需要结论，因为人类总是会犯错误，现在正在犯错误，将来还会犯错误。 因此，您应该做出
一个具体的结论 ，而不是说那句话
。 结论-也许只是很小的一步，但仍然朝着改进开发过程，监控系统和自动化工具的方向迈出了一步。 如此小的步骤可以使服务更稳定！
7.代替结尾
在其他部分，我将讨论Citymobil体验中的中断类型，并详细介绍每种中断类型。 我还将告诉您有关断电的结论，如何修改开发流程以及引入了哪些自动化。 敬请期待！