用“开源”一词，许多人似乎要么是在晚上致力于自己喜欢的项目的热心者，要么是通过支持开放产品来赚钱的小公司。 但是，如果仅考虑它们，那么您将错过社区中重要而有趣的部分。 一旦“企业”和“开源”这两个词似乎成为反义词，但是现在，大公司不仅积极使用OSS项目，而且它们本身也会对此做出贡献。
随着时间的流逝，Sbertech在OSS社区中变得越来越活跃，我们决定向他们询问。 严格的银行业务特殊性如何与开源的自由精神相结合？ 其他公司可能对开放源代码有什么要求？ Sbertech中是否有任何将开源作为主要工作任务的员工？ 您对未来有什么计划和期望？ 负责免费和开源的
Anton Churaev向我们介绍了所有这些以及更多内容。
奥列格：嗨安东。 让我们向您介绍一下哈布罗夫派。 告诉自己：您是谁，您在做什么？安东：我是一名工程师，但是只有在业余时间才能发展。 现在，我正在建立Sbertech的实践和能力，以开发和应用自由和开源产品。 您需要了解这些是稍有不同的东西。
-是的，我知道，与Stallman交谈过几次，我称其为Free as Open，然后我听了这样的演讲，使我终生难忘：-)嗯，您的立场是什么？-自由和开源开发的策展人。 和开源爱好者:)
-您能否进一步解释一下“实现开放源代码的能力”？ 这听起来像某种秘密知识。-很少有人能想到开源对公司意味着什么。 一方面，这些是创新，无需开发商品，专注于其产品的竞争优势，可重复使用并降低成本。 通常，这些项目实际上已成为行业标准。 采用相同的Hadoop-每个人都知道，每个人都知道，它长期以来一直是一个标准。 或最常见的数据库-前五名是三个开源产品-MySQL，PostgreSQL和MongoDB。
但是很少有人认为使用OpenSource会涉及很多隐性成本。 这并不是说我们找到了开源，并解决了所有问题。 例如，有关“法律卫生”的问题很大。 使用供应商软件时，一切都非常清楚：我获得了许可证，您可以使用它并使用支持。 使用开放源代码时，开发人员和用户的工作还很多。 在这种情况下，法律和法律问题是第一位的。 另外，在俄罗斯也有细微差别。 如果在全世界范围内，知识产权的概念已经相当发达，并且每个人都知道有一个特定的所有者是非常重要的，那么从历史上看，俄罗斯的情况就不同了。 尽管这是非常错误的，但在这里我们对知识产权并不那么谨慎和尊重。 而且，如果您不能确保使用开源的“卫生”，就不能保证其使用质量。
-我可以澄清一下吗？ 俄罗斯GPL许可证的法律地位是什么？ 例如，GPL不允许修改当地法律，也没有指明地区限制。 因此，这种协议与俄罗斯联邦领土上建立的法律制度不符，这是非常非常糟糕的。-我不想将许可证划分为某些区域。 Sberbank是一家跨国公司，因此该软件可以在美国和欧盟使用。 而且，据我了解（我不是律师，但据我所知），如果违反了版权所有者在美国境内的许可限制，则我们将根据美国法律负责 因此，您在确保权利和满足他人知识产权方面需要非常小心。 尊重允许我们使用我们的作品的作者，由于这些作品，我们加快了，优化了解决方案，解决了我们的问题，并最终为我们的客户提供了优质的服务。 让我们遵守权利和要求。 这是第一个任务。
-第二？-第二项任务是信息安全。 显然，大多数许可均包含免责声明，表明作者/开发者/贡献者不对使用此软件可能造成的损害负责。 没错，这是转移给消费者并要求其成熟的责任。 一切都不免费。
您必须为此承担责任，并且当然要承担这些风险。 并非所有公司都能做到这一点。 我们有一个非常强大的信息安全部门-我们很幸运。 因此，我们通常对漏洞和恶意代码的存在很认真。 计划使用开放源代码的每个人都必须考虑所有风险-不仅是法律上的风险，还包括信息安全方面的风险。
-您喜欢什么许可证？-学术。
哦！ 让我们更具体一些。 有MIT / BSD等，还有像Affero GPL这样的病毒copyleft许可证。 其中哪一个？-好，很好。 您不能爱或不喜欢许可证。 该产品是为特定任务而制造的，将以特定方式使用。 使用开放源代码时，您的任务是确保在不侵犯第三方权利的前提下提供产品或服务。 当然，在这种情况下，如果可以确保使用版权，则可以使用copyleft（例如GPL），这样它们就不会违反限制和任何其他人的权利。 当然，使用学术许可证的困难较少，这仅仅是因为它们具有较少的限制，因此更易于遵循。 简而言之，我称“学术” MIT，BSD，Apache等。
-好的，普通开发人员必须处理信息安全问题吗？ 还是分配给另一个部门？-所有开发人员都必须了解信息安全的基础知识及其系统的安全原理。 但是在我们的案例中，我们与专门研究信息安全威胁的个人开发人员合作。 此外，我们不仅将它们用于开源产品的分析，而且还将其用于算法和设计解决方案的分析。
“很明显，这些特殊的保安人员知道一切。” 普通开发人员在这方面需要了解什么？ 基本要点是什么？-威胁模型，渠道保护，数据保护。 容易受到威胁的原因：也许这是通过网络的用户界面或数据传输（一切都与我们一起分发，所以这是一个非常重要的问题）。 基本工具，如加密，SSL，TLS，身份验证，授权，令牌处理等。 您不需要了解太多。
-谣言说您与Apache Ignite有任何关系:-)-就贡献而言，这是我目前正在从事的主要项目。 参与Apache Ignite是我的第二项任务-确保在自由和开源项目上进行平衡的投资。 这意味着对产品的合理使用（很明显，使用库是一项投资，作为用户，我们增加了产品的吸引力）以及开发和贡献。
对我来说，这项任务可能更加重要。 我们向我们在公司中使用的那些产品致敬，并因此而建立了许多产品和系统。 我们试图改进它们，并确保在诸如我们这样的公司中使用的可能性：进行优化，使之进入企业状态。
Apache Ignite不是唯一的项目，但是我们将非常认真地将其走私到该项目中，因为银行的主要平台之一是基于Apache Ignite构建的。 Ignite是一个分布式计算网格，它使您可以在内存中存储和处理数据，实际上，它是我们业务的IT领域的基础。 因此，我们对其发展非常感兴趣。
-很多人都知道Sbertech使用GridGain，而您正在谈论的是Apache Ignite。 两者有什么区别？-GridGain是基于Ignite开放核构建的开放核产品。 GridGain是此核心的一组插件，可简化维护和操作程序，并提供许多重要的信息安全性和可靠性要求。 但是，实际上，核心是最重要的部分，插件使您可以在实际企业中利用所有这些。 并且该银行已经在运营GridGain。
-既然Ignite是开放的，那么可以谈谈，对吧？ 与开发人员互动时，您是只利用它还是做些事情来完成它？-我们对其进行了大量修改。 明确了任务的方向，例如，在考虑到Sberbank的细节的情况下确保性能：大规模，数据海洋，高运营活动。 因此，它应该很快而且很多。 我的意思是等待时间和吞吐量。
第二是确保可靠性，即 可用性和容错能力。
第三是运营效率，TCO管理。 鉴于Sberbank的规模，在我们的规模上，即使将磁盘等资源的使用量稍微减少一点，也可以节省大量资金。
第四是功能开发的任务。 实际上，最主要的是接口的开发以及与Sberbank技术堆栈的其他组件的集成。 就构建成熟的集成IT架构而言，这是有用且重要的。
另外，还有消除技术债务和缺陷（始终存在）的任务。 它可能可以归因于可靠性。
-让我们来看一下这些点以进行澄清。 您说您正在努力改善性能，延迟，吞吐量，仅此而已。 问题是-Ignite是否有任何问题？ 我的意思是，有什么需要修改的东西还是理想的产品？-不，该产品不能视为理想产品。 在每个版本中，我们都在特定组件上推动通用基准测试和微基准测试，我们一直在努力提高性能-我们不应该在这里停止。 这项任务很困难，因为组件和解决方案已经非常严格，性能几乎达到极限。 这增加了复杂性，但始终存在改进的空间。 我们有不同的用例，出现了新的用户任务，其中存在优化的可能性。 例如，针对数据的特定性质优化磁带机。 还有一些任务可以优化网络层，这又取决于个别情况。 因此，您始终需要将手指放在脉搏上。
“您说过您将回馈社区。” 所有有关各种情况和针对它们的优化的所有决策都是某种权衡。 当我们权衡取舍并将其带入社区时，可能会发现社区中的人们具有略微不同的条件和不同的优先级。 如何组织交互并仍然复制案例所需的代码？-其他承担其他任务的客户。 这是一个标准问题，这是绝对正确的。 这完全取决于解决方案的体系结构。 例如，如果该解决方案包括针对不同用户解决方案进行插件扩展，插件，库的功能，那么您就可以解决。 例如，如果有一个比较器，则用户始终可以开发一种解决方案，将该比较器传递给输入，这将根据特定条件解决该问题。 同样，功能非常依赖于体系结构。 只为我们的任务粗略地编码和雕刻而没有考虑其他客户是错误的-这样的拉取请求不会经过审查。
每个人都了解什么是开源项目，通常，您可以影响它。 当然，在某些社区中，显然有公司在为自己的利益影响发展，但是如果我们玩纯开放源码，那么它将与精英管理（有价值的权威）进行正确比较。 证明您的决定是正确的，然后将做出决定。 在封闭式开发中通常采取行动，即从“我是老板，我这样说”的立场行事是行不通的。
-Sbertech在公开场合告诉我们的最有趣的案例之一是“单语义层”。 大量数据分布在内存网格中。 这对Ignite的开放部分有何影响？这些发展对社区有多有趣？-是的，这种发展正在进行中，我们正在非常努力地工作以确保可伸缩性和可访问性。 我们发现当前拓扑管理方案不是最佳的情况，因为 它的时间复杂性是由节点的数量增长而来的，并不是我们想要的那样。 这在某种程度上使目标的实现复杂化。
-据我所知，集群体系结构是一个环。 就是说，当我们加入戒指时，首先要去协调员，然后沿着戒指前进直到找到尾巴。 元素越多，时间就越多，对吗？“是的，有点。” 同时，随着拓扑中节点数量的增加，沿环网传输的消息的大小和参与者之间的转换数量都增加了。 这并不是说响起是一个错误的决定，但是在某些情况下不适合。 因此，自2017年底以来，我们社区中的人们正在最终确定拓扑管理，以便用户可以选择一种拓扑管理方案：环形（有时很合适）或Zookeeper上的星星。
-戒指是从哪里来的？ 为什么呢 在哪里完美？-这是一个数据中心内100-200个节点的拓扑的绝佳解决方案。 允许您简单可靠地同步所有节点，它们只是按顺序进行。 如果我们去繁星点点，那么它们将开始以更快的速度并行工作，但是同时同步它们变得更加困难。 也就是说，环可以更稳定可靠，同意吗？
“是的，当然。” 但是可以这样做，以便通过配置中的某些参数更改此拓扑吗？设置如何？-是的，我们现在正在这样做，我们在发行版中同时包含了这两种拓扑。 可能，已经提出的实现可能无法涵盖所有用户情况，一旦出现新的实现，我们将尽力确保其有效处理。
-据我了解，这是一个相当复杂的修订。 这项修订工作是由Sbertekh的人们在工作时间还是在晚上进行娱乐？-这是由包括PBT员工在内的社区完成的，他们在工作时间内的主要任务是为该项目做出贡献。 拓扑问题影响了产品核心中的关键解决方案之一，因此主要的负担落在了DiscoverySPI维护人员身上，但我希望我们开发人员的参与也对结果产生积极的影响。
-好吧，这些人是在工作时间内解决问题的人，但同时也是社区的成员。-是的，我们开发人员最重要的工作是在社区中进行的。 但是我也从我们的家伙们那里看到了这样的承诺，它们在一小时，两，三夜之间出现。
-这些员工不会因为他们在银行，封闭系统中工作，同时致力于开放源代码而遇到问题吗？-不，不会。 所有参与者均为官方公司贡献者。 方向的确定和投资决定是在公司管理层一级进行的，是的，这组敬业的公司贡献者根据公司和TC的所有标准，为公司的利益开发开源产品。 是的-这是开发和开放源代码，是的-也在工作时间和非工作时间，但这已经是社区要求的了。
-我们刚刚谈到了社区决定的一些外部事务。 但是最有可能的是，公司需要进行自己的集成，在某些情况下进行改进……您是否编写了大量自己的书？ 还是只是一点点dopilka？-关于Apache Ignite项目，在最后一个季度中，我们对项目的贡献占所有更改的8-10％，并且我们努力提高这一百分比。 我们写了很多书，这不仅是对现有功能的开发和优化，我们还在为项目开发新功能。 这是对社区的挑战，也是对我们的责任，因为在加入社区之后，社区在一定程度上有支持它的任务。
任务不仅可以出现在社区中，而且可以出现在公司内部的用户中：架构师，开发和维护团队。 这些任务的项目开发也对产品产生重大影响。
-但是，可以说，PRPRB的Sbertekh计划有几份有关其“特殊风水”的报道。 我是否需要编写任何其他工具和管理页面来支持此操作？-操作界面在不断发展。 同一Oracle的管理控制台更易于维护并且具有更多功能。 是否需要完全复制是另一个问题。
-以开放的形式，您可以看到管理控制台吗？“是的，当然。” Web控制台发布，Visor，CLI-一切都是公开的。
-如果您从更全局的角度看待它，总体方向和目标是什么？-现在，我们更加专注于满足公司优先事项的Apache Ignite的开发。 但是我们的技术栈并没有到此结束。 Open Source , , . , , . ( ), , . . , . . .
— , . - ?— — , availability, durability, fault tolerance ..
— , .— , — . , Open Source . . , .
— - , , ? , - , ceph?— , ceph — . , , , .
— - ? ?— OpenStack.
— , OpenStack — , . - , , ?— OpenStack , , , Cloud Foundry, .
— ?— :-) , ( ) . , — , , .
— .— , - Open Source .
, . , , -.
— -?— , , , -: , .. , , , , . . , Open Source, , , .
. , . -, , . . , , , .
, , ( -, , , ) — . , , , .
— .
— , . , «», , « , » «, ». , . , , . , , , . — , .
— , ? , … , , .— . , , , , . , , ( ). , , , .
, , - .
Open Source . , . . , .
— ? ?— , . , , – . — , ROI, .., .
— , - . , : , . , - Spring Hibernate, , , , . , , , . , .— , , . , , . , , . , . , .