在2018年DevOps Conf俄罗斯大会前夕，我们与Uchi.ru技术总监Alexei Vakhov讨论了该平台的开发阶段，使用的工具以及DevOps ovo的数量。
Alexey Vakhov-Uchi.ru技术总监。 他曾在大型系统（数千万行代码）上担任C ++开发人员。 最受欢迎的服务器技术-Ruby on Rails是前100名贡献者。 他喜欢组织IT生产，运营，Web应用程序体系结构。
Uchi.ru是俄罗斯的教育平台，在这里，1至11年级的学生以有趣而有趣的方式学习学校的科目。 俄罗斯，美国，巴西，印度，南非和中国的250万学生和22万教师使用了该平台。 它在电子学习平台的全球排名中排名第36位。 该公司有400多名员工。-这一切是怎么开始的？ 您抵达时公司里有多少人？-2012年，也就是六年前，我被邀请加入该公司。 当时我是第五或第六名员工，也是唯一的开发人员。 我排版并进行服务器开发。 我们制作了第一个Web应用程序并将其发布在Heroku上。
“现在怎么样？” 多少支球队，什么规模？ 如何独立？ 它们如何相互影响？-今天，我们有400多人，其中大约100名工程师是大约20个独立团队的联合体。 我们有两个主要方向：生产开发和交互式任务的开发。
独立的团队拥有自己的隔离环境，特殊的构建系统，这些团队针对他们执行的任务，自己的服务器和源代码进行了优化。 它们仅在必要时相互通信。
-以公司的这种增长率，您是否可以制作自己的Wiki？ 你如何支持她？-我们有几个知识库。 有一个融合形式的Wiki，其中包含一般部分和主题部分，每个团队都有自己的部分。 在每个存储库中，我们都支持自述文件和其他白皮书。 无论如何，每个团队都会分配自己的空间，在jira中分配自己的空间，所有这些都是根据团队的意愿进行安排的。 我们对设计没有规定和标准化。
-急剧增长充满了失控。 您如何处理？ 您如何协调这么多团队的工作？-通过建立管理层次结构来实现总体协调。 我们有推荐协调员，每个团队都有自己的领导者。 这里的一切都很简单。
如果您从技术角度回答这个问题，那么团队将遵循通用规则，例如，将测试连接到每个存储库，将整个开发过程转到新分支，将其进行检查，部署到测试环境然后再进行生产。
-您为公司自己设立公司的哪个阶段？-我喜欢在一本有趣的书中所读到的方法，根据该方法，危机在于通常的价值观体系崩溃。 在我们的案例中，由于危机的迅速发展，因此发生了许多危机，每个危机都决定了进一步的发展。
第一次危机发生在我们变得狭窄的房间里，不得不扩大到两个房间时。 在这一阶段，似乎已经不再为所有人所知的信息了。 当开发人员不得不划分为产品团队时，出现了第二个及随后的危机。 同样，我们庞大而友善的团队被迫分手并以不同的角度分裂。
与我们发生的任何变化都必须得到及时和相关技术创新的支持。 DevOps方法也是如此。 可以说，我本人最近才开始了解什么是文化价值观，以及为什么它们在大型团队中很重要。 例如，有一段时间没有人问谁对站点的稳定性负责。 每个人都知道推出这项服务的人应该对他负责。 我们雇用了一个仅负责服务器的人员-“开发人员与管理员”的对抗在同一天开始。 太神奇了，就像一本书。
-告诉我更多有关每个阶段的信息。 您为自己选择了哪些工具，您必须放弃哪些工具？ 从我在DevOpsConf 2018 上的性能发布中了解到，您的所有基础架构都部署在Docker容器的云中。 你为什么做出这样的决定？ 从什么时候起您就无法没有容器？-起初什么都没有，甚至没有追踪器。 仅向Heroku推出：git push，每个人都很高兴。 但是Heroku很快就使我们不满意，因为在此之前有很多ping操作，而且他们无法承受。 我们搬到了普通的铁服务器上，并聘请了顾问。 随着时间的流逝，服务器杂乱无章。 到这个时候，我们已经大大增加了流量，生产数量，内部和外部服务。 我们通过Chef配置了服务器。 晴朗的一天，我们承受了重担，到了晚上，我们使用Ansible迁移到了云端。 切换到Ansible的感觉只是宇宙的。 事实证明这是简单且易于理解的，尤其是在如此小的基础架构中。
从大约60个应用程序开始，我们的基础架构已发展成为独立的站点，我们称之为“站点”。 这些是具有自己的子网，自己的地形和ansible配置的孤立云。
随着应用程序和服务器数量的增加，我们的配置开始浮动，因为在RoR上启动简单应用程序之前需要考虑很多因素。 另外，部分部署配置位于应用程序的存储库中，一部分位于整体配方中，开发人员开始使用秘密魔术，建立文件夹链接以及某种同步。 结果，它变得完全不可能维护。
当我们在不同的云中有大约一百个应用程序时，我们开始仔细研究docker。 那是去年夏天。 在大约10个月内，我们转移了所有应用程序，到那时，在docker-clusters上大约有150个应用程序。 这已成为我们的真正救赎。 我们免于监视服务器上的版本和环境报废。 一切都变得更加便捷和简单：该应用程序可以轻松地放置在Docker集群中，可以轻松地从该集群中删除，它具有自己的元信息，可以清楚地知道应用程序包含哪些服务，启动了哪些工作，后台作业等。
-您对原始DevOps方法的立场有多坚定？ 一切适合您还是您自己改变了一些东西？ 重建团队难吗？-我本人对什么是DevOps尚无确切答案。 在工作中，我总是从简单的常识出发。 人们说，事实证明，DevOps在这里得到了发展。 实际上，我几乎不需要DevOps的理论部分，因为该业务要求我提供结果。 换句话说，如果我对他们说得很漂亮并且什么都不做，那将是非常糟糕的；如果我做到了，但又不告诉别人美丽，那将仍然是一件好事。
我对DevOps的理解如下。 例如，有一些大公司想要生产或已经生产数字产品。 数码产品始终是市场上的快速反馈。 连续交付会自动发生，开发和支持之间的界限变得模糊，DevOps文化变得更加严格，这解释了负责推出，测试和支持的人员之间良好形式的规则。 结果，这种关系允许他们彼此达成共识以达成共同的目标，并将焦点从个人责任转移到共同的结果上。 在一家大型且信誉卓著的公司中，流程会发生变化，并且会中断。
由于我们没有一家成熟的公司，因此我们很快就发展了工作原则。 此外，业务部门不断给我们带来新的任务，因此我们主要基于常识和内部需求来构建基础架构。
DevOps这个词对我来说意义不大。 但是现在，当我们经历所有这些过程时，当我看到冲突点的出现，责任的模糊化时，我意识到DevOps就像是人与人之间为共同目标而进行交互的文化方面。 数字产品的共同目标是开发新功能并尽快推出。
-了解初学者使用如此众多的现代工具加入您的作品有多么困难。 您与人的工作如何组织？-我们有适应计划。 我们向新员工介绍我们的发展方式以及现在如何安排一切，我们会聘请一名导师。 在第一天，我们帮助他搭建环境并发起了战斗，但任务并不艰巨。 导师陪伴他几个月，帮助适应。
-告诉我们公司的计划。 您计划在哪里发展以及在哪些领域发展？ 当前的技术堆栈是否为进一步发展奠定了基础，还是您需要再次改变它？-商业计划雄心勃勃。 今天，有超过200万小学生定期上Uchi.ru，约占全国所有小学生的30％。 我们将继续在俄罗斯平台上吸引新用户并参与国际发展。
从技术上讲，我们有15个隔离的Docker集群，并且要花很多时间从一个集群切换到另一个集群，这已经变得难以维护和升级。 对变更速度和可靠性的要求仅在增长。 因此，有保留，但是我们也会更新。
朋友，如果您对Alexey的经历感兴趣，我们赶紧邀请我们参加10月1-2日在
俄罗斯举办的
DevOps Conf俄罗斯2018 。 在他的报告中，他将讨论使用云的经验，DevOps方法的应用，团队的价值观和原则。
订阅 Ontiko DevOps主题时事通讯，以在程序更新可用后立即接收它们。 我们试图使信件变得有用而不是干扰，我们发送会议新闻，报告成绩单和最新视频。
顺便说一下，可以在YouTube频道上单独监视视频-近年来收集了所有视频，并且列表会不断更新。