每个人都在谈论开发和测试、培训员工、提高积极性的流程，但当一分钟的服务停机会花费大量资金时，这些流程还不够。 当您在严格的 SLA 下进行金融交易时该怎么办？ 如何提高系统的可靠性和容错能力，将开发和测试排除在外？
下一次 HighLoad++ 会议将于 6 年 7 月 2020 日至 XNUMX 日在圣彼得堡举行。 详情及门票 。 9 月 18 日 00:2018。 HighLoad++ 莫斯科 XNUMX、德里 + 加尔各答大厅。 论文和 .
叶夫根尼·库佐夫列夫（Evgeniy Kuzovlev，以下简称“EC”）： - 朋友们，你们好！ 我的名字是库佐夫列夫·叶夫根尼。 我来自 EcommPay 公司，具体部门是 EcommPay IT，该集团公司的 IT 部门。 今天我们将讨论停机 - 如何避免停机，如何在无法避免的情况下尽量减少其后果。 主题如下：“当一分钟的停机成本为 100 美元时该怎么办”？ 展望未来，我们的数字具有可比性。
EcommPay IT 是做什么的？
我们是谁？ 我为什么站在你面前？ 为什么我有权利在这里告诉你一些事情？ 我们将在这里更详细地讨论什么？
EcommPay 集团公司是一家国际收单机构。 我们在世界各地处理付款——俄罗斯、欧洲、东南亚（世界各地）。 我们设有 9 个办事处，共有 500 名员工，其中大约不到一半是 IT 专家。 我们所做的一切，我们从中赚钱的一切，都是我们自己做的。
我们自己编写了所有产品（我们有相当多的产品 - 在我们的大型 IT 产品系列中，我们有大约 16 个不同的组件）； 我们自己写作，我们自己发展。 目前，我们每天进行大约一百万笔交易（数百万可能是正确的说法）。 我们是一家相当年轻的公司——我们只有大约六年的历史。
6年前，当这些人加入到这家公司时，这还是一家初创公司。 他们因一个想法而团结在一起（除了一个想法，别无他物），然后我们就跑了。 像任何初创公司一样，我们跑得更快……对我们来说，速度比质量更重要。
在某个时刻，我们停了下来：我们意识到我们无法再以那样的速度和质量生活，我们需要首先关注质量。 此时此刻，我们决定编写一个正确、可扩展且可靠的新平台。 他们开始编写这个平台（他们开始投资、开发开发、测试），但在某些时候他们意识到开发和测试并不能让我们的服务质量达到新的水平。
你制造了一种新产品，并将其投入生产，但仍然会在某个地方出现问题。 今天我们将讨论如何达到新的质量水平（我们是如何做到的，关于我们的经验），将开发和测试排除在外； 我们将讨论操作可用的内容 - 操作本身可以做什么，它可以为测试提供什么以影响质量。
停机时间。 操作戒律。
始终是主要基石，我们今天实际上要讨论的是停机时间。 一个可怕的词。 如果我们有停机时间，一切都会对我们不利。 我们正在跑去举起它，管理员正在控制服务器 - 上帝保佑它不会掉落，正如他们在那首歌中所说的那样。 这就是我们今天要讲的内容。
当我们开始改变我们的方法时，我们制定了 4 条戒律。 我将它们呈现在幻灯片上：
这些诫命非常简单：
- 快速找出问题所在。
- 更快地摆脱它。
- 帮助理解原因（稍后为开发人员提供）。
- 并标准化方法。
我想提请您注意第二点。我们正在消除问题，而不是解决问题。 决定是次要的。 对于我们来说，首要的是保护用户免受此问题的影响。 它会存在于某个孤立的环境中，但是这个环境不会和它有任何的联系。 其实我们会过一遍这四组问题（有的比较详细，有的不太详细），我会告诉你我们用了什么，我们在解决方案方面有哪些相关经验。
故障排除：它们何时发生以及如何处理？
但我们会乱序开始，我们将从第二点开始——如何快速解决问题？ 有一个问题——我们需要解决它。 “这件事我们该怎么办？” - 主要问题。 当我们开始考虑如何解决问题时，我们为自己制定了一些故障排除必须遵循的要求。
为了制定这些要求，我们决定问自己一个问题：“我们什么时候会遇到问题”？ 事实证明，问题出现在四种情况下：
- 硬件故障。
- 外部服务失败。
- 更改软件版本（相同部署）。
- 爆炸性负载增长。
我们不会谈论前两个。 硬件故障的解决方法非常简单：必须复制所有内容。 如果这些是磁盘，则这些磁盘必须组装在 RAID 中；如果这是服务器，则必须复制该服务器；如果您有网络基础设施，则必须提供网络基础设施的第二个副本，即，您将它并复制它。 如果出现故障，您可以切换到备用电源。 这里很难再说什么了。
二是外部服务失效。 对于大多数人来说，系统根本不是问题，但对于我们来说却不是。 由于我们处理支付，因此我们是一个位于用户（输入卡数据）和银行、支付系统（Visa、MasterCard、Mira 等）之间的聚合器。 我们的外部服务（支付系统、银行）往往会失败。 我们和您（如果您有此类服务）都无法影响这一点。
那该怎么办呢？ 这里有两个选择。 首先，如果可以的话，您应该以某种方式复制此服务。 例如，如果可以的话，我们将流量从一项服务转移到另一项服务：例如，卡是通过 Sberbank 处理的，Sberbank 遇到问题 - 我们[有条件]将流量转移到 Raiffeisen。 我们可以做的第二件事是非常快速地注意到外部服务的故障，因此我们将在报告的下一部分中讨论响应速度。
事实上，在这四个方面，我们可以具体影响软件版本的变化 - 采取行动，改善部署环境和负载爆炸性增长的情况。 事实上，我们就是这么做的。 在这里，再次，一个小注释......
在这四个问题中，如果有云，其中有几个问题可以立即得到解决。 如果您使用 Microsoft Azhur、Ozone 云，或者使用我们的 Yandex 或 Mail 云，那么至少硬件故障会成为他们的问题，并且在硬件故障的情况下，一切都会立即变得正常。
我们是一家有点不传统的公司。 这里每个人都在谈论“Kubernets”，谈论云——我们既没有“Kubernets”，也没有云。 但我们在许多数据中心都有硬件机架，我们被迫依赖这些硬件生活，我们被迫对这一切负责。 因此，我们将在这个背景下进行讨论。 那么，关于问题。 前两项已从括号中取出。
更改软件版本。 基地
我们的开发人员无法进入生产环境。 这是为什么？ 只是我们是通过了PCI DSS认证的，我们的开发者根本就没有进入“产品”的权利。 就是这样，期间。 完全没有。 因此，开发责任恰好在开发提交构建版本时结束。
我们拥有的第二个基础，这也对我们有很大帮助，是缺乏独特的未记录的知识。 我希望你也一样。 因为如果不是这样的话，你就会遇到问题。 当这种独特的、未记录的知识没有在正确的时间、正确的地点出现时，就会出现问题。 假设您有一个人知道如何部署特定组件 - 该人不在，他正在度假或生病 - 就是这样，您遇到了问题。
这是我们所达到的第三个基础。 我们经历了痛苦、血和泪水才得出这个结论——我们得出的结论是，我们的任何构建都包含错误，即使它是没有错误的。 我们自己决定了这一点：当我们部署某些东西时，当我们将某些东西投入生产时，我们的构建会出现错误。 我们已经形成了我们的系统必须满足的要求。
更改软件版本的要求
有三个要求：
- 我们必须迅速回滚部署。
- 我们必须尽量减少部署不成功的影响。
- 而且我们必须能够快速并行部署。
完全按照这个顺序！ 为什么？ 因为，首先，在部署新版本时，速度并不重要，重要的是对你来说，如果出现问题，能够快速回滚并把影响降到最低。 但是，如果您在生产中有一组版本，结果发现存在错误（突然没有部署，但存在错误） - 后续部署的速度对您很重要。 为了满足这些需求，我们做了什么？ 我们采用了以下方法：
这是众所周知的，我们从未发明过它 - 这是蓝/绿部署。 这是什么？ 您必须为安装了应用程序的每组服务器拥有一份副本。 该副本是“热”的：其上没有流量，但任何时候该流量都可以发送到该副本。 该副本包含以前的版本。 在部署时，您将代码部署到非活动副本。 然后将部分（或全部）流量切换到新版本。 因此，为了将流量从旧版本更改为新版本，您只需要执行一项操作：您需要更改上游的平衡器，更改方向 - 从一个上游到另一个上游。 这样非常方便，解决了快速切换和快速回滚的问题。这里第二个问题的解决方案是最小化：您可以仅将部分流量发送到新线路，即具有新代码的线路（例如，2％）。 而这2%并不是100%！ 如果你因为部署不成功而损失了 100% 的流量，那很可怕；如果你损失了 2% 的流量，那虽然令人不快，但并不可怕。 此外，用户很可能甚至不会注意到这一点，因为在某些情况下（并非全部），同一用户按 F5 将被带到另一个工作版本。
蓝/绿部署。 路由
然而，并非一切都那么简单“蓝/绿部署”......我们所有的组件都可以分为三组：
- 这是前端（我们的客户看到的付款页面）；
- 处理核心；
- 用于支付系统（银行、MasterCard、Visa...）的适配器。
这里有一个细微差别 - 细微差别在于线路之间的路由。 如果你只是切换 100% 的流量，就不会有这些问题。 但如果你想转换 2%，你就会开始问问题：“如何做到这一点？” 最简单的事情很简单：你可以通过随机选择在nginx中设置循环，你有2%在左边，98%在右边。 但这并不总是合适的。
例如，在我们的示例中，用户通过多个请求与系统进行交互。 这是正常的：2、3、4、5 个请求 - 您的系统可能相同。 如果对您来说重要的是所有用户的请求都到达第一个请求所在的同一行，或者（第二点）所有用户的请求都到达切换后的新行（他可以更早地开始使用系统，切换之前），-那么这个随机分布不适合你。 然后有以下选项：
第一个选项是最简单的，基于客户端的基本参数（IP 哈希）。 你有一个IP，你把它从右到左除以IP地址。 那么我描述的第二种情况将适合您，当部署发生时，用户已经可以开始使用您的系统，并且从部署那一刻起，所有请求都将转到一个新行（例如，到同一行）。如果由于某种原因这不适合您，并且您必须将请求发送到用户最初的初始请求所在的行，那么您有两个选择......
第一个选择：你可以购买付费的 nginx+。 有一种粘性会话机制，根据用户的初始请求，为用户分配一个会话并将其绑定到一个或另一个上游。 会话生命周期内的所有后续用户请求都将发送到会话发布的同一上游。这不适合我们，因为我们已经有了常规的 nginx。 切换到 nginx+ 并不是因为它很贵，而是它对我们来说有点痛苦，而且不太对劲。 例如，“Sticks Sessions”对我们不起作用，原因很简单，“Sticks Sessions”不允许基于“非此即彼”的路由。 在那里，您可以指定我们“Sticks Sessions”做什么，例如，通过 IP 地址或通过 IP 地址和 cookie 或通过后参数，但“非此即彼”在那里更复杂。
因此，我们来到了第四种选择。 我们对 nginx 进行了升级（这是 openresty）——这是同一个 nginx，它还支持包含最后的脚本。 你可以编写最后一个脚本，给它一个“开放休息”，当用户请求到来时，最后一个脚本将被执行。
事实上，我们编写了这样一个脚本，将自己设置为“openresti”，在这个脚本中我们通过连接“Or”对 6 个不同的参数进行排序。 根据一个或另一个参数的存在，我们知道用户来到了一页或另一页、一行或另一行。
蓝/绿部署。 的优点和缺点
当然，可能可以让它变得更简单（使用相同的“粘性会话”），但我们也有这样的细微差别，即不仅用户在一笔交易的一次处理的框架内与我们交互......但支付系统也会与我们交互：在我们处理交易（通过向支付系统发送请求）后，我们会收到一个冷却。
比方说，如果在我们的电路内部，我们可以在所有请求中转发用户的 IP 地址，并根据 IP 地址划分用户，那么我们就不会告诉相同的“Visa”：“伙计，我们是一家如此复古的公司，我们似乎为了国际化（在网站上和在俄罗斯）...请在附加字段中向我们提供用户的 IP 地址，您的协议是标准化的”！ 很明显，他们不会同意。
因此，这对我们不起作用——我们做了 openresty。 因此，通过路由，我们得到了这样的结果：因此，蓝/绿部署具有我提到的优点和缺点。
两个缺点：
- 你需要费心去处理路由；
- 第二个主要缺点是费用。
你需要两倍的服务器，你需要两倍的运营资源，你需要花费两倍的精力来维护整个动物园。
顺便说一句，在这些优点中，还有一件事是我之前没有提到的：您可以为负载增长做好准备。 如果您的负载呈爆炸性增长，您拥有大量用户，那么您只需将第二行包含在 50 到 50 的分布中 - 您的集群中就会立即拥有 x2 服务器，直到您解决拥有更多服务器的问题。
如何快速部署？
我们讨论了如何解决最小化和快速回滚的问题，但问题仍然是：“如何快速部署？”
这里简短而简单。- 您必须有一个 CD 系统（持续交付）——没有它您就无法生存。 如果您有一台服务器，则可以手动部署。 我们有大约一千个半千个服务器和一个半千个手柄，当然 - 我们可以建立一个像这个房间大小的部门来部署。
- 部署必须是并行的。 如果您的部署是顺序的，那么一切都会很糟糕。 一台服务器很正常，你一整天都会部署一千台服务器。
- 同样，对于加速来说，这可能不再是必要的。 在部署期间，通常会构建项目。 你有一个 web 项目，有一个前端部分（你在那里做一个 web pack，你编译 npm - 类似的东西），这个过程原则上是短暂的 - 5 分钟，但这 5 分钟可以保持批判性。 例如，这就是为什么我们不这样做：我们删除了这 5 分钟，我们部署了工件。
什么是神器？ 工件是一个组装的构建，其中所有组装部件都已完成。 我们将此工件存储在工件存储中。 我们曾经使用过两个这样的存储——它是Nexus，现在是jFrog Artifactory。我们最初使用“Nexus”是因为我们开始在java应用程序中实践这种方法（它非常适合）。 然后他们把一些用PHP写的应用程序放在那里； 而“Nexus”已经不合适了，因此我们选择了jFrog Artefactory，它几乎可以人工化所有东西。 我们甚至已经达到这样的程度：在这个工件存储库中，我们存储我们为服务器收集的自己的二进制包。
爆炸性负载增长
我们讨论了更改软件版本。 接下来我们面临的是负载的爆炸性增加。 在这里，我的意思可能是负载的爆炸性增长并不完全正确......
我们写了一个新系统——它是面向服务的、时尚的、漂亮的、到处都是工人、到处排队、到处异步。 在这样的系统中，数据可以流经不同的流。 对于第一个事务，可以使用第 1 个、第 3 个、第 10 个工作人员，对于第二个事务，可以使用第 2 个、第 4 个、第 5 个工作人员。 今天，假设早上你有一个使用前三个工作人员的数据流，到了晚上它发生了巨大的变化，一切都使用了其他三个工作人员。
事实证明，您需要以某种方式扩展工作人员，您需要以某种方式扩展您的服务，但同时防止资源膨胀。
我们已经定义了我们的要求。 这些要求非常简单：服务发现、参数化——构建这种可扩展系统的一切都是标准的，除了一点——资源折旧。 我们说过，我们还没有准备好摊销资源，以便服务器加热空气。 我们选择了“Consul”，我们选择了“Nomad”，它管理我们的工人。为什么这对我们来说是一个问题？ 让我们回顾一下。 我们现在拥有大约 70 个支付系统。 例如，早上，流量通过 Sberbank，然后 Sberbank 崩溃了，我们将其切换到另一个支付系统。 在 Sberbank 之前我们有 100 名员工，之后我们需要为另一个支付系统大幅增加 100 名员工。 所有这一切都希望在没有人类参与的情况下发生。 因为如果有人参与，就应该有一名工程师 24/7 坐在那儿，他只应该做这件事，因为当你身后有 70 个系统时，这种故障会经常发生。
因此，我们研究了具有开放IP的Nomad，并编写了我们自己的东西，Scale-Nomad - ScaleNo，它大致执行以下操作：它监视队列的增长并根据动态减少或增加工作人员的数量队列的。 当我们这样做时，我们想：“也许我们可以开源它？” 然后他们看着她——她就像两个戈比一样简单。
到目前为止我们还没有开源它，但是如果在报告之后突然意识到你需要这样的东西，你需要它，我的联系方式在最后一张幻灯片中 - 请写信给我。 如果有至少3-5人，我们将赞助。
怎么运行的？ 我们来看看吧！ 展望未来：左边有一块我们的监控：这是一行，上面是事件处理的时间，中间是交易数量，下面是worker数量。如果你看一下，这张照片有一个小问题。 在最上面的图表中，其中一张图表在 45 秒内崩溃了——其中一个支付系统出现故障。 立即，流量在 2 分钟内引入，队列开始在另一个支付系统上增长，那里没有工作人员（我们没有利用资源 - 相反，我们正确地处置了资源）。 我们不想供暖——人数很少，大约 5-10 名工人，但他们无法应付。
最后一张图显示了一个“驼峰”，这意味着“Skaleno”使这个数量增加了一倍。 然后，当图表下降一点时，他就减少一点——工人的数量会自动改变。 这就是这个东西的工作原理。 我们讨论了第二点——“如何快速摆脱原因”。
监控。 如何快速找出问题所在？
现在第一点是“如何快速识别问题？” 监控！ 我们必须快速了解某些事情。 哪些事情我们应该快速理解？
三件事！- 我们必须快速了解并了解我们自身资源的表现。
- 我们必须快速了解故障并监控外部系统的性能。
- 第三点是识别逻辑错误。 这是当系统为您工作时，根据所有指标一切正常，但出现问题。
我可能不会在这里告诉你任何很酷的事情。 我将成为明显队长。 我们寻找市场上有什么。 我们有一个“有趣的动物园”。 这就是我们现在拥有的动物园：
我们使用Zabbix来监控硬件，监控服务器的主要指标。 我们使用 Okmeter 作为数据库。 我们将“Grafana”和“Prometheus”用于所有不适合前两个的其他指标，有些使用“Grafana”和“Prometheus”，有些使用“Grafana”与“Influx”和Telegraf。一年前我们想使用 New Relic。 很酷的东西，它可以做一切。 但尽管她能做一切，她却是如此昂贵。 当我们的服务器数量增长到 1,5 台时，一家供应商找到我们说：“让我们签订明年的协议吧。” 我们看了价格，说不，我们不会这样做。 现在我们正在放弃New Relic，我们还有大约15台服务器处于New Relic的监控之下。 结果证明这个价格绝对是疯狂的。
我们自己实现了一个工具 - 这就是调试器。 起初我们叫它“Bagger”，但后来一位英语老师路过，哈哈大笑，把它改名为“Debagger”。 这是什么？ 事实上，这个工具可以在 15-30 秒内对每个组件进行测试，就像系统的“黑匣子”一样，对组件的整体性能进行测试。
例如，如果有一个外部页面（支付页面），他只需打开它并查看它应该是什么样子。 如果正在处理，他会发送一个测试“交易”并确保该“交易”到达。 如果这是与支付系统的连接，我们会在可能的情况下相应地发出测试请求，并确保一切正常。
哪些指标对于监控很重要？
我们主要监控什么？ 哪些指标对我们来说很重要？
- 前端的响应时间/RPS是一个非常重要的指标。 他立即回答说你有问题。
- 所有队列中已处理的消息数。
- 工人数量。
- 基本正确性指标。
最后一点是“业务”，“业务”指标。 如果你想监控同样的事情，你需要定义一两个指标作为你的主要指标。 我们的指标是吞吐量（这是成功交易数量与总交易流量的比率）。 如果它每隔 5-10-15 分钟发生变化，就意味着我们遇到了问题（如果变化剧烈）。
对我们来说，这是我们的一个董事会的示例：
左侧有 6 个图表，这是根据线条排列的 - 工作人员数量和队列中的消息数量。 右侧——RPS、RTS。 以下是相同的“业务”指标。 在“业务”指标中，我们可以立即看到中间的两个图表出了问题……这只是我们身后另一个已经崩溃的系统。我们要做的第二件事是监控外部支付系统的崩溃。 在这里，我们采用了 OpenTracing——一种允许您跟踪分布式系统的机制、标准、范例； 它被改变了一点。 标准 OpenTracing 范例表示，我们为每个单独的请求构建跟踪。 我们不需要这个，我们将它包装在摘要、聚合跟踪中。 我们制作了一个工具，可以让我们跟踪我们身后系统的速度。
该图向我们显示，其中一个支付系统在 3 秒内开始响应 - 我们遇到了问题。 而且，这个东西在出现问题的时候就会做出反应，间隔20-30秒。存在的第三类监控错误是逻辑监控。
说实话，我不知道在这张幻灯片上画什么，因为我们长期以来一直在市场上寻找适合我们的东西。 我们没有找到任何东西，所以我们必须自己做。
逻辑监控是什么意思？ 好吧，想象一下：您为自己创建了一个系统（例如，Tinder 克隆）； 你成功了，启动了它。 成功的经理 Vasya Pupkin 将其放在手机上，看到那里有一个女孩，喜欢她......但喜欢的人不会发给那个女孩 - 喜欢的人会发给来自同一商务中心的保安 Mikhalych。 经理下楼，然后纳闷：“为什么这个保安米哈雷奇对他笑得那么愉快？”在这种情况下……对我们来说，这种情况听起来有点不同，因为（我写道）这是一种声誉损失，间接导致经济损失。 我们的情况恰恰相反：我们可能会遭受直接的经济损失——例如，如果我们进行了一笔交易，本来是成功的，但实际上却不成功（反之亦然）。 我必须编写自己的工具，使用业务指标跟踪一段时间内成功交易的数量。 市场上没找到什么东西！ 这正是我想要传达的想法。 市场上没有任何东西可以解决此类问题。
这是关于如何快速识别问题的问题。
如何确定部署原因
我们解决的第三组问题是当我们发现问题之后，解决掉它之后，最好了解一下原因，然后去开发，去测试，然后做一些事情。 因此，我们需要调查，我们需要提出日志。
如果我们谈论日志（主要原因是日志），我们的大部分日志都在 ELK Stack 中 - 几乎每个人都有相同的日志。 对于某些人来说，可能不在ELK中，但如果你写千兆字节的日志，那么迟早你会来到ELK。 我们以 TB 为单位编写它们。
这里有问题。 我们修复了它，为用户纠正了错误，开始挖掘那里的东西，爬进 Kibana，在那里输入交易 ID，并得到像这样的脚布（显示了很多）。 这块脚布中绝对没有任何东西是透明的。 为什么？ 是的，因为不清楚哪个部分属于哪个worker，哪个部分属于哪个组件。 在那一刻，我们意识到我们需要跟踪 - 就是我谈到的 OpenTracing。一年前我们就想到了这一点，把注意力转向市场，那里有两个工具——“Zipkin”和“Jaeger”。 “Jager”实际上就是这样一个思想继承者，“Zipkin”的思想继承者。 Zipkin 中的一切都很好，除了它不知道如何聚合，它不知道如何在跟踪中包含日志，只有时间跟踪。 “Jager”也支持这一点。
我们研究了“Jager”：你可以检测应用程序，你可以用 Api 编写（然而，当时 PHP 的 Api 标准尚未获得批准 - 这是一年前的事，但现在它已经获得批准），但是有绝对没有客户。 “好吧，”我们想，并写信给我们自己的客户。 我们得到了什么？ 大概是这样的：
在 Jaeger 中，为每条消息创建 Span。 也就是说，当用户打开系统时，对于每个传入请求，他会看到一两个块（1-2-3 - 来自用户的传入请求数，块数）。 为了方便用户，我们在日志和时间跟踪中添加了标签。 因此，如果出现错误，我们的应用程序将使用适当的错误标签来标记日志。 您可以按错误标签进行过滤，并且仅显示包含此错误块的范围。 如果我们扩大跨度，就会是这样的：
跨度内有一组痕迹。 在本例中，这是三个测试跟踪，第三个跟踪告诉我们发生了错误。 同时，这里我们看到一个时间轨迹：顶部有一个时间刻度，我们可以看到这个或那个日志被记录的时间间隔。因此，我们的一切进展顺利。 我们编写了自己的扩展并将其开源。 如果你想使用跟踪，如果你想在 PHP 中使用“Jager”，有我们的扩展，欢迎使用，正如他们所说：
我们有这个扩展 - 它是 OpenTracing Api 的客户端，它是作为 php 扩展制作的，也就是说，您需要组装它并将其安装在系统上。 一年前没有什么不同。 现在还有其他类似组件的客户端。 这取决于你：要么你用作曲家抽出组件，要么你使用扩展。企业标准
我们讨论了三诫。 第四条诫命是标准化方法。 这是关于什么的？ 是关于这个的：
为什么这里要用“公司”这个词呢？ 不是因为我们是一家大公司或官僚公司，不！ 我想在这里使用“公司”这个词，因为每个公司、每个产品都应该有自己的标准，包括你。 我们有什么标准？
- 我们有部署规定。 没有他，我们哪儿也去不了，我们不能。 我们每周部署大约 60 次，也就是说，我们几乎不间断地进行部署。 同时，例如，我们在部署法规中对周五部署有一个禁忌 - 原则上我们不进行部署。
- 我们需要文件。 如果没有相关文档，任何新组件都不会投入生产，即使它是在我们的研发专家的笔下诞生的。 我们需要他们提供部署说明、监控图以及该组件如何工作以及如何对其进行故障排除的粗略描述（好吧，正如程序员可以编写的那样）。
- 我们解决的不是问题的原因，而是问题本身——我已经说过了。 对我们来说，保护用户免受问题困扰非常重要。
- 我们有许可。 例如，如果我们在两分钟内丢失了 2% 的流量，我们不会将其视为停机。 这基本上不包含在我们的统计中。 如果百分比更高或者是暂时的，我们已经算了。
- 我们总是写事后分析。 无论我们发生什么，任何人在生产中表现异常的情况都会反映在事后分析中。 事后剖析是一份文件，其中写下发生在您身上的事情、详细的时间安排、您采取的纠正措施以及（这是强制性的！）您将采取哪些措施来防止将来发生这种情况。 这是强制性的，也是后续分析所必需的。
什么被视为停机？
这一切导致了什么？这导致了这样一个事实：（我们在稳定性方面遇到了一些问题，这对客户和我们都不适合）在过去的 6 个月里我们的稳定性指标是 99,97。 可以说，这并不是很多。 是的，我们有一些值得努力的事情。 这个指标中，大约有一半是稳定性，可以说，不是我们的稳定性，而是我们的Web应用防火墙的稳定性，它站在我们面前，作为服务使用，但客户并不关心这一点。
我们学会了晚上睡觉。 最后！ 六个月前我们还不能。 在这篇带有结果的注释上，我想做一个注释。 昨晚有一篇关于核反应堆控制系统的精彩报道。 如果编写这个系统的人能听到我的话，请忘记我所说的“2% 不是停机时间”。 对于您来说，2% 是停机时间，即使是两分钟！
就这样！ 你的问题。
关于平衡器和数据库迁移
观众提问（以下简称 - B）： - 晚上好。 非常感谢您提供这样的管理报告！ 关于平衡器的一个简短问题。 你提到你有一个WAF，也就是说，据我了解，你使用某种外部平衡器......
知识库： – 不，我们将我们的服务用作平衡器。 在这种情况下，WAF对我们来说只是一个DDoS防护工具。
在： – 您能简单介绍一下平衡器吗？
知识库： – 正如我已经说过的，这是 openresty 中的一组服务器。 我们现在有 5 个专门响应的保留组...也就是说，专门运行 openresty 的服务器，它只代理流量。 因此，要了解我们持有多少：我们现在有数百兆比特的常规流量。 他们应付自如，感觉良好，甚至不给自己太大压力。
在： ——也是一个简单的问题。 这是蓝/绿部署。 例如，您如何进行数据库迁移？
知识库： - 好问题！ 看，在蓝/绿部署中，我们为每条线路都有单独的队列。 也就是说，如果我们谈论从工作程序传输到工作程序的事件队列，则蓝线和绿线有单独的队列。 如果我们谈论的是数据库本身，那么我们故意尽可能地缩小范围，将所有内容实际上移到队列中；在数据库中，我们只存储一堆事务。 我们的事务堆栈对于所有行都是相同的。 对于这种情况下的数据库：我们不会将其分为蓝色和绿色，因为两个版本的代码都必须知道事务发生了什么。
朋友们，我还有一个小奖品可以激励你们——一本书。 我应该获得最佳问题奖。
在： - 你好。 感谢您的报告。 问题是这样的。 您可以监控付款，可以监控与之通信的服务...但是，如何进行监控，以便某人以某种方式来到您的付款页面，进行付款，并且该项目将钱记入他的贷方？ 也就是说，您如何监控营销人员是否有空并已接受您的回电？
知识库： – 在这种情况下，“商家”对我们来说是与支付系统完全相同的外部服务。 我们监控商家的响应速度。
关于数据库加密
在： - 你好。 我有一个稍微相关的问题。 您拥有 PCI DSS 敏感数据。 我想知道如何将 PAN 存储在需要传输到的队列中？ 你使用任何加密吗？ 这就引出了第二个问题：根据 PCI DSS，有必要在发生变化（管理员被解雇等）时定期重新加密数据库 - 在这种情况下，可访问性会发生什么？
知识库： - 好问题！ 首先，我们不将 PAN 存储在队列中。 原则上，我们无权以明确的形式将 PAN 存储在任何地方，因此我们使用一种特殊的服务（我们称之为“Kademon”）——该服务只做一件事：接收消息作为输入并发送输出一条加密消息。 我们用这个加密消息存储所有内容。 因此，我们的密钥长度低于千字节，因此这是严肃可靠的。在： – 您现在需要 2 KB 吗？
知识库： – 好像就在昨天，还是 256...那么，还有哪里？！
因此，这是第一个。 其次，现有的解决方案支持重新加密过程 - 有两对“keks”（密钥），它们提供了加密的“decks”（key 是密钥，dek 是加密密钥的派生物） 。 如果启动该程序（定期发生，从 3 个月到±一些），我们会下载一对新的“蛋糕”，并重新加密数据。 我们有单独的服务，可以删除所有数据并以新的方式对其进行加密； 数据存储在加密密钥的标识符旁边。 因此，一旦我们使用新密钥加密数据，我们就会删除旧密钥。
有时需要手动付款...
在： – 也就是说，如果某些操作退款到了，你还会用旧密钥解密吗？
知识库： - 是的。
在： ——然后还有一个小问题。 当发生某种故障、跌倒或事件时，需要手动推送事务。 有这样一种情况。
知识库： - 是的，有时。
在： – 您从哪里获得这些数据？ 或者你自己去这个存储设施吗？
知识库： – 不，当然，我们有某种后台系统，其中包含支持我们的界面。 如果我们不知道交易处于什么状态（例如，直到支付系统响应超时），我们就无法知道先验，也就是说，我们只能完全放心地分配最终状态。 在这种情况下，我们将事务分配到特殊状态以进行手动处理。 第二天早上，一旦支持人员收到支付系统中保留此类交易的信息，他们就会在此界面中手动处理它们。
在： - 我有一些问题。 其中之一是 PCI DSS 区域的延续：如何记录他们的电路？ 这个问题是因为开发人员可以在日志中放入任何内容！ 第二个问题：如何推出修补程序？ 在数据库中使用句柄是一种选择，但可能有免费的修补程序 - 那里的过程是什么？ 而第三个问题可能与RTO、RPO有关。 您的可用性是 99,97，几乎是四个 XNUMX，但据我了解，您有第二个数据中心、第三个数据中心和第五个数据中心...您如何同步它们、复制它们以及其他所有内容？知识库： - 让我们从第一个开始。 第一个问题是关于日志的吗？ 当我们写入日志时，我们有一个屏蔽所有敏感数据的层。 她看着面具和附加字段。 因此，我们的日志中包含已屏蔽的数据和 PCI DSS 电路。 这是分配给测试部门的常规任务之一。 他们需要检查每项任务，包括他们编写的日志，这是代码审查期间的常规任务之一，以控制开发人员没有写下任何内容。 信息安全部门大约每周定期进行一次后续检查：有选择地获取最后一天的日志，并通过测试服务器上的特殊扫描分析仪运行这些日志来检查所有内容。
关于热修复。 这包含在我们的部署法规中。 我们有一个关于修补程序的单独条款。 我们相信，我们会在需要时全天候部署修补程序。 一旦版本组装完毕，一旦运行，一旦我们有了工件，我们就会有一名系统管理员在接到支持电话后值班，他会在需要时部署它。关于“四个九”。 我们现在的这个数字已经真正达到了，我们在另一个数据中心争取到了。 现在我们有了第二个数据中心，我们开始在它们之间进行路由，跨数据中心复制的问题确实是一个不小的问题。 我们曾经尝试使用不同的方法来解决这个问题：我们尝试使用相同的“狼蛛” - 它对我们来说没有成功，我会立即告诉你。 这就是为什么我们最终手动订购“sens”。 事实上，我们系统中的每个应用程序都在数据中心之间异步运行必要的“更改完成”同步。
在： – 如果你得到了第二个，为什么不得到第三个？ 因为还没人有裂脑……
知识库： – 但我们没有裂脑。 由于每个应用程序都是由多主机驱动的，因此请求来自哪个中心对我们来说并不重要。 我们已经准备好接受这样一个事实：如果我们的一个数据中心发生故障（我们依赖于此）并且在用户请求切换到第二个数据中心的过程中，我们实际上已经准备好失去该用户； 但这些将是单位，绝对单位。
在： - 晚上好。 感谢您的报告。 您谈到了调试器，它在生产中运行一些测试事务。 但请告诉我们有关测试交易的信息！ 它有多深？
知识库： – 它经历整个组件的完整周期。 对于组件来说，测试事务和生产事务之间没有区别。 但从逻辑角度来看，这只是系统中的一个单独项目，仅运行测试事务。
在： -你在哪里把它剪掉？ 这里核心发送...
知识库： – 在这种情况下，我们落后于“Kor”进行测试交易...我们有一个路由这样的东西：“Kor”知道要发送到哪个支付系统 - 我们发送到一个假支付系统，该系统只是提供一个http信号并且就这样。
在： – 请告诉我，您的应用程序是用一个巨大的整体编写的，还是将其分割成一些服务甚至微服务？
知识库： – 我们没有一个整体，当然，我们有一个面向服务的应用程序。 我们开玩笑说我们的服务是由单体组成的——它们确实非常大。 很难将其称为微服务，但这些是分布式机器的工作人员在其中运行的服务。
如果服务器上的服务受到损害...
在： – 那么我有下一个问题。 即使它是一个整体，您仍然说您拥有许多这样的即时服务器，它们基本上都处理数据，问题是：“如果其中一个即时服务器或应用程序遭到破坏，任何单独的链接，他们有某种访问控制吗？ 他们谁能做什么？ 我应该联系谁以获取什么信息？
知识库： - 当然是。 安全要求相当严格。 首先，我们有开放的数据流动，而端口只是我们提前预测流量流动的端口。 如果组件通过 5-4-3-2 与数据库（例如与 Muskul）通信，则只有 5-4-3-2 对其开放，其他端口和其他流量方向将不可用。 此外，您需要了解，在我们的生产中大约有 10 个不同的安全环路。 即使应用程序以某种方式受到损害（上帝保佑），攻击者也将无法访问服务器管理控制台，因为这是一个不同的网络安全区域。在： – 在这种情况下，对我来说更有趣的是，你与服务签订了某些合同 - 他们可以做什么，通过什么“行动”他们可以相互联系......并且在正常流程中，一些特定的服务需要一些行，另一行是“操作”列表。 在正常情况下，他们似乎不会求助于其他人，而且他们还有其他职责。 如果其中一个受到损害，是否能够破坏该服务的“操作”？...
知识库： - 我明白。 如果在正常情况下完全允许与另一台服务器进行通信，那么是的。 根据 SLA 合同，我们不会监控您仅被允许前 3 个“操作”，并且不允许您执行后 4 个“操作”。 这对我们来说可能是多余的，因为原则上我们已经有一个四级电路保护系统。 我们更喜欢用轮廓来保护自己，而不是在内部。
Visa、MasterCard 和 Sberbank 如何运作
在： – 我想澄清有关将用户从一个数据中心切换到另一个数据中心的一点。 据我所知，Visa和MasterCard使用8583二进制同步协议进行操作，并且有混合的情况。 我想知道，现在我们的意思是转换 - 是直接“Visa”和“MasterCard”还是在支付系统之前、处理之前？
知识库： - 这是混音之前的情况。 我们的混音位于同一个数据中心。
在： – 粗略地说，你们有一个连接点吗？
知识库： – “Visa” 和 “MasterCard” – 是的。 原因很简单，例如，维萨卡和万事达卡需要对基础设施进行大量投资才能签订单独的合同以获得第二对混合卡。 它们被保留在一个数据中心内，但如果上帝保佑，我们的混合连接 Visa 和 MasterCard 的数据中心死掉了，那么我们将失去与 Visa 和 MasterCard 的连接......
在： – 如何保留？ 我知道Visa原则上只允许一次转接！
知识库： – 他们自己提供设备。 无论如何，我们收到的设备内部完全冗余。
在： – 所以这个展台是他们的 Connects Orange 的？..
知识库： - 是的。
在： – 但是这个案例呢：如果你的数据中心消失了，你如何继续使用它？ 或者交通就停止了？
知识库： - 不。 在这种情况下，我们只需将流量切换到另一个渠道，这自然对我们来说会更贵，对我们的客户来说也会更贵。 但是流量不会通过我们直接连接Visa、MasterCard，而是通过有条件的Sberbank（很夸张）。
如果我冒犯了俄罗斯联邦储蓄银行的员工，我深表歉意。 但根据我们的统计，在俄罗斯银行中，俄罗斯联邦储蓄银行跌幅最大。 俄罗斯联邦储蓄银行每个月都会出事。
一些广告🙂
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的内容？ 通过下订单或推荐给朋友来支持我们， , 我们为您发明的入门级服务器的独特模拟： （适用于 RAID1 和 RAID10，最多 24 个内核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 数据中心便宜 2 倍？ 只有这里 在荷兰！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 阅读
来源： habr.com