Запуск DevOps в 1С с точки зрения не техники, но людей и процессов

Меня зовут Андрей Овсянкин. В сфере 1С я уже больше 20 лет. И так получилось, что последние лет 10 я занимаюсь разработкой инструментов для DevOps в сфере 1С. И вообще развиваю различные инструменты для разработчиков 1С. Вы могли видеть в интернете мой ник EvilBeaver или знать меня по проекту OneScript.

 

 

Начну с формулировки того, что такое вообще DevOps и для чего он нужен.

DevOps – это подход, обеспечивающий быструю обратную связь между разработчиками и системными администраторами – теми, кто эксплуатирует систему. Причем это подход с высокой степенью автоматизации процедур выпуска и эксплуатации.

Ключевые слова в этом определении – это «обратная связь» и «автоматизация». То есть DevOps – это не Kubernetes, не Docker, не сервер сборок и даже не тесты. Это способ организации процессов в разработке.

 

Чек-лист шпаргалка, чтобы ничего не упустить при аудите и внедрении DevOps в 1С

 

Стоит сказать, что современные практики разработки в 1С уже давно стали нормой. Это не какое-то ноу-хау. И вот если их нет, это уже не норма, и их требуется внедрять, как минимум, чтобы банально не терять деньги.

И сегодня мы поговорим о том, как подойти к этому вопросу и структурировать у себя методику запуска тех или иных DevOps-практик разработки.

Представьте, что вас пригласили в компанию или попросили сделать такое внедрение внутри. И вам, в первую очередь, нужно провести аудит ИТ-процессов разработки в 1С. Поскольку задача в значительной мере типовая, то можно создать типовой чек-лист: как внедрять, что спрашивать, что делать и так далее. Об этом сегодня и поговорим.

 

 

И хочу подчеркнуть, что технологии в этом вопросе – совсем не главное. У нас в 1С из технологий все, что нужно для DevOps, было вообще уже с самых первых версий восьмерки. Еще слова такого «DevOps» в мире не было, а в 1С уже все необходимые технологии для этого уже были.

• Групповая разработка была – не хуже, чем у всех на тот момент времени. Еще не существовало, ни Git, ни SVN, а в 1С уже была групповая разработка – вполне себе нормальная на тот момент времени.

• Автоматизированное управление конфигуратором было – через командную строку можно было автоматически собирать и разворачивать релизы.

• Даже тестовый фреймворк можно было написать – никаких проблем. Код есть – бери, пиши.

Ничего из техники не мешало нам создать DevOps в 1С еще в нулевые. И вообще технологии – это вторично. Главное – это люди, которые построят на базе этих технологий что-то полезное. И вот людей и методик о том, как это делать, в те времена не было.

 

 

Поэтому все модные технологические слова (Git, Jenkins и т.д.) нужно сразу отодвинуть на третий план. Технологии – вообще не главное.

Нас в первую очередь интересует конкретная польза для бизнеса, которая появится, если мы будем разрабатывать «правильно». Слово «правильно» я беру в кавычки, потому что метрика правильности ровно одна – мы помогаем бизнесу или не помогаем. Как минимум, мы не должны плодить лишних затрат.

Вообще весь бизнес-процесс предприятия можно условно представить как появление некоей идеи у предпринимателя, превращение этой идеи в продукт и получение за него прибыли.

И вот ИТ – оно где-то здесь посередине. Мы помогаем бизнесу получить профит или, как минимум, не плодим избыточных затрат при преобразовании идеи в продукт. От этой концепции и стоит отталкиваться.

Нас позвали внедрять DevOps именно потому, что есть ощущение, что с его помощью можно в чем-то снизить трение и уменьшить накладные расходы.

 

Внедрение DevOps не спасет. Но поможет сократить хаос

 

Таким образом, мы подходим к несложной мысли, что волшебной таблетки нет. И само по себе внедрение DevOps – это только на 20% техника и на 80% – люди и процессы.

Внедрение DevOps не спасет, если в процессах и в головах хаос. Но запуск этих практик – это отличный способ критически посмотреть на свои процессы со стороны и, возможно, уменьшить этот хаос, структурировать и стабилизировать процессы.

 

 

Перво-наперво я предлагаю определиться с целями всей дальнейшей работы: зачем нас вообще позвали и что необходимо починить?

Все текущие проблемы нам необходимо сформулировать в виде твердого текста. Идеально, если в виде цифр.

• Сколько у нас в среднем ошибок на продакшене в месяц вылезает?

• Сколько времени мы тратим на раскатывание релиза? И так далее.

Нужно обязательно проговорить и записать текущую ситуацию словами – какие жалобы у больного.

 

 

Как правило, жалобы у всех больных в среднем похожи: хаос задач; мы не укладываемся в сроки; непонятно, чем занимается команда; постоянные баги.

Причем еще раз вспоминаем, что DevOps сам по себе эти проблемы не решает. Потому что нет прямой корреляции между наличием сервера сборок и количеством ошибок в продакшене, но наличие практик DevOps помогает снизить трение и тем самым разгружает команду или дает ей полезную информацию о том, что вообще происходит – например, благодаря проактивному мониторингу в продакшене.

 

 

Многие из вас видели эту избитую картинку про DevOps. Тем не менее, эта картинка – это и есть наш план действий.

В конечном счете, DevOps – это методология, в которой мы получаем обратную связь от того, как живут наши задачи в продакшене. А на прод, соответственно, попадают задачи, которые мы осознанно спланировали, разработали, протестировали и передали в эксплуатацию.

Чтобы получать эту обратную связь, все сегменты этой змейки – и планирование, и тестирование, и разработка, и мониторинг – должны быть покрыты конкретными процессами и инструментами. Когда на проде что-то идет не так, мы в разработке должны об этом быстро узнавать. Это и есть DevOps.

Поэтому каждый сегмент этой змейки – это, по сути, шаг нашего плана действий. Что на картинке, то мы и будем внедрять.

 

От процессов будет зависеть то, что мы будем воплощать

 

Кроме этого, важно понимать, что каждая организация уже имеет какую-то устоявшуюся организационную структуру, и эта структура сама диктует нам бизнес-процессы – то, как они складываются.

Причем эту структуру мы, скорее всего, поменять не сможем – например, отделы нам реорганизовать не дадут – поэтому текущие процессы разработки будут определять то, что мы будем воплощать.

Как только мы определились с запросом клиента, нам сразу необходимо узнать, как сейчас в компании построен процесс разработки: как задача формулируется, как она попадает к программистам, как они ее разрабатывают и так далее. Мы должны получить представление о том, как вообще выглядит путь задачи по этой восьмерке: от формулирования до попадания в продакшен.

• Например, у команды уже ведется версионирование исходников в гите – отлично, значит это нам делать не нужно.

• Или, например, есть выделенная команда тестирования – тоже хорошо, значит уже есть какие-то тесты.

• Настроен мониторинг – замечательно. И так далее.

Причем для каждой активности необходимо выяснить бизнес-процесс и ответственных – какие люди или подразделения в этом участвуют. Не просто есть мониторинг, а за этим мониторингом следит конкретный человек. Не просто выпуск релиза, а выпуск релиза конкретным человеком. Потому что процессы и люди главнее технологий.

 

 

Разворачиваем эту восьмерку жизненного цикла задачи в плоский список и получаем список активностей, для каждой из которых всегда существует роль – человек или отдел, которые ее выполняют. И в процессе нашего аудита мы должны выяснить и зафиксировать – кто в ситуации AS-IS выполняет каждый из этапов пути задачи от постановки до эксплуатации:

• Как появляется задача – кто ее ставит?

• Как задача попадает разработчику? Ее присылает бухгалтер по почте? Или есть централизованный service desk?

• Как задачи уходят в работу? Кто принимает решение, какая задача важнее?

• И так далее.

Выявляем роли и обязательно рисуем бизнес-процесс о том, как эти роли взаимодействуют, потому что каждой такой активности обязательно соответствует тот или иной бизнес-процесс.

 

 

Наверное, это и так понятно, но код, в том числе код на 1С – это актив компании. И за него, вообще-то говоря, уплачено. А значит, о нем нужно заботиться так же, как и о любом другом активе.

Все хранилища кода 1С должны стоять «на балансе» у большого айти. С них нужно делать резервные копии, контролировать наличие свободного места на диске и мониторить доступность самих хранилищ. И если хранилище недоступно, то админ должен увидеть красную лампочку и срочно побежать его поднимать. И вообще, админы должны хотя бы знать, что у них в хозяйстве существуют эти самые сервера хранилищ 1С.

 

Наша основная задача – привести контур 1С к стандартам компании

 

Таким образом, мы обозначаем себе целевую архитектуру: разработка на 1С должна вестись так же, как и любая другая. А именно:

• Если в компании есть сервер сборок, то 1С-ные сборки должны крутиться на нем же.

• Если есть версионирование кода, то версии кода 1С должны лежать там же, поскольку код – это актив компании и не должен валяться непонятно где, неучтенный.

• Мониторинг точно так же должен быть централизован. У 1С-ников не должно быть отдельного Zabbix, который они подпольно настроили где-то для себя. Базы 1С должны мониториться там же, где и все остальное в компании. И админ должен следить за алертами 1С так же, как за всеми остальными.

• Кроме того, процедура принятия изменений в коде 1С должна быть такой же, как и для других систем: заявки, планирование релизов, технологические окна – все это должно быть согласовано с остальными ИТ-процессами в компании.

1С-разработка не должна быть бедным родственником. Это цель, к которой стоит стремиться. Не обязательно всего из этого удастся достичь, но мы должны постоянно двигаться в этом направлении.

 

 

Заметка на полях: ваша активность должна быть официальной.

Если мы внедряем DevOps подпольно, мы, скорее всего, обречены на провал. В лучшем случае мы получим опыт поднятия серверов сборки руками, но прироста эффективности это нам не даст.

Если у нас официальный проект, то мы сразу, до начала всех работ должны получить себе в союзники человека с правом принятия решений. Потому что без этого, если мы построим себе красивый воздушный замок с пайплайном автоматической сборки и тестами, мы обязательно упремся в вопрос «а где все это будет крутиться?»

Ответ на вопрос «кто будет выдавать железо» должен быть у вас до начала всех работ. И этот человек должен быть на вашей стороне. Потому что в противном случае вы утонете в бюрократических вопросах «А почему вам надо виртуалку на два гигабайта, а не на один?» «А как вы так посчитали требуемую память?» Если люди начинают буквоедство за один гигабайт ОЗУ, работу лучше даже не начинать. Потому что без союзника, который вам поможет продавить это все и получить мощности, скорее всего, у вас проект провалится.

Понятно, что ответы на эти вопросы хорошо бы знать и погуглить вообще минимальные требования к серверам, чтобы быть наготове. Но если чувствуете сопротивление на грани абсурда, лучше сходу накиньте на свой ценник какой-то повышающий коэффициент за работу с козлами.

Также, если ваш проект официальный (а он должен быть официальным), то на сопровождение всей кухни у вас должен быть выделен как минимум один 1С-ник на фуллтайм. Он не должен прерываться на срочные бизнес-задачи, а должен настраивать пайплайн для сборки и запуска тестов.

 

Начинаем проектировать

 

На этом мы вводную часть, пожалуй, закончим и начнем строить наш контур DevOps.

 

 

Во многих умных книжках предлагается выстраивать архитектуру по трем слоям:

• бизнес-архитектура (или оргструктура);

• сервисы, которые ее обеспечивают;

• и железо.

В целом это довольно здравый подход, и его стоит придерживаться. Но если начать применять такие идеальные слои архитектуры на практике, это становится больше похоже не на слои, а на трехмерную головоломку. Задача построения общего контура DevOps превращается в кубик Рубика с измерениями: люди (или роли), инструменты (сервисы) и обеспечение (железо). И все эти аспекты взаимосвязаны, когда начинаешь анализировать одно, обязательно задевается другое.

• С одной стороны, мы проектируем, как задача должна двигаться по оси оргструктуры – кто ставит задачу, кто планирует, кто реализует.

• С другой стороны, мы должны эту же задачу разложить по сервисам – потому что у разработчиков используется одна Jira, у админов – другая Jira, они между собой не интегрированы, и так далее.

• То же самое с железом, потому что развертывание должно быть выполнено на каком-то железе, и тут тоже есть что попроектировать – какие-то сервисы можно объединить на одной машине, какие-то разнести, какой-то сервер попросить у других людей и так далее.

 

 

Поэтому я предлагаю более простой подход, а точнее, фреймворк, который основан не на слоях архитектуры, а на компетенциях – они же ценности.

Под компетенциями я понимаю то, что мы должны уметь делать, и какую полезность это несет. Это верхний слой, и он – самый главный, поскольку описывает, что мы вообще можем: работать с задачами, писать код, тестировать его, деплоить и сопровождать.

Причем эти наши компетенции и то, что мы с их помощью можем делать – не зависят от оргструктуры отделов компаний вообще. Они универсальны и вечны.

Так рассматривать гораздо проще, поскольку мы абстрагируемся от людей и подразделений. Мы просто анализируем поток неких ценностей/компетенций, каждая из которых как-то работает и чем-то обеспечивается.

 

 

В качестве примера попробуем рассмотреть, как планируются наши задачи.

 

 

В результате выясняем, что компетенция «Планирование» поддерживается каким-то таск-трекером – например, Jira. А если у нас нет таск-трекера, значит, нам его в архитектуре нужно завести.

 

 

В любом случае, этот трекер будет запущен на каком-то железе. Выясняем это. Или решаем вопрос – чем этот сервис будет обеспечен.

 

 

И так с каждой из компетенций.

Если мы берем компетенцию «Разработка», то она тоже использует какие-то сервисы и обеспечивается какими-то ресурсами.

 

 

Например, в качестве сервисов для разработки мы используем хранилище 1С и Git.

И для обеспечения разработки у нас есть:

• определенные люди, которые это сопровождают;

• серверы, где это все вращается;

• а главное – у вас должны быть полномочия приходить и нарезать этим людям задачи по обеспечению разработки, чтобы не было такого, как в том видео с дедушкой, когда вам человек скажет: «Вы кто такие? Я вас не звал». Когда вы приходите к человеку с задачей, он должен понимать, что у вас есть полномочия ставить ему задачу.

 

 

Действуя таким образом, структурировать проект намного проще.

• У нас есть аспект, над которым мы работаем.

• Для запуска этого аспекта требуются определенные сервисы.

• И нам нужно эти сервисы запустить, обеспечить их функционирование.

Необязательно запускать все компетенции сразу именно в таком порядке. Компетенции достаточно автономны. Зависимости между ними хоть и есть, но они не очень прочные.

Мы можем дробить работы – сфокусироваться на какой-то определенной компетенции, которая позволяет быстрее всего получить выгоду и добиться позитивного эффекта.

Например, у нас хаос задач, с разработкой все плохо, с планированием все плохо, никаких тестов нет. Но у нас в любом случае есть продакшн, а значит, над компетенцией эксплуатации мы можем работать, не пытаясь починить предыдущие. Что нам нужно, чтобы хотя бы в проде все было хорошо?

• Мы можем поднять там мониторинг, реализовать авторегистрацию ошибок, собрать логи и положить это все в Elasticsearch.

• А где мы это развернем?

• А кто у нас здесь будет союзником с правом принятия решений?

Отталкиваясь от компетенций гораздо проще распутать клубок зависимостей между видами деятельности.

 

Компетенции, шмопетенции, а делать что?

 

Замечательно, у нас есть фреймворк, который поможет не потеряться и структурировать работу. Но как это все применить на практике?

В каждой из компетенций есть набор мероприятий, которые необходимо провести, чтобы обеспечить определенный уровень зрелости процессов или убедиться, что состояние процессов уже соответствует критериям зрелости.

На основе этого набора мероприятий мы можем составить чек-лист для каждой компетенции.

 

 

Если мы говорим про планирование, то с постановкой задач, например, уже не так все плохо, как было 10 лет назад. Я уверен, что большинство команд уже так или иначе переняли практики Agile и больше не берут в работу задачи из почты, а используют приоритезацию, коммуникации с заказчиками и т.п. Вряд ли где-то еще осталось такое, что бухгалтер написал программисту: «Вася, сделай мне галочку», и программист все бросил, побежал делать эту галочку. Но вам в любом случае стоит убедиться, что разработка ведется по заранее оговоренному плану, поэтому ваша задача – отсечь спонтанные изменения.

По этой же причине стоит отобрать у 1С-ников доступ к продакшену. В команде разработки не должно быть людей, которые неконтролируемо ходят на продакшен и что-то там делают, и вообще в принципе видят эту базу. Ни в одном другом стеке – ни в Java, ни в C# – у разработчиков даже мысли нет о том, чтобы им дали доступ в боевую базу. Это вообще не их зона ответственности. Они код пишут и релизы выпускают, а за эксплуатацию отвечают специальные люди с соответствующим доступом. В 1С почему-то такого нет, а стоит сделать. Поэтому отбираем у 1С-ников доступ к проду и ставим галочку, что отсекли спонтанные изменения.

 

 

Версионирование кода должно быть там же, где и весь остальной код компании.

Код 1С – это актив, он не должен быть бесхозным. Если кода нет в Git, вы теряете аудиторский след и вообще контроль за изменениями. Вы не видите, кто, зачем, когда и почему поменял эту строчку. Это можно найти через хранилище, но в хранилище можно версии удалить. А в Git у вас есть четкий аудиторский след, поэтому код 1С обязательно так или иначе должен быть в Git – либо сразу вы в Git разрабатываете, либо зеркалируете хранилище.

Код должен лежать в Git – по-другому быть не должно.

 

 

Теперь то, что касается самого процесса и компетенции разработки.

Тут вариантов слишком много и нет какого-то единственного правильного. Но у вас в чек-листе в любом случае должна быть галочка-цель – обеспечить фича-бранчинг, версионирование с ветками. Это означает, что вы в любой момент должны быть готовы к выпуску релиза, при этом не бояться незавершенных изменений.

Я встречал команды, где разработчикам запрещается помещать в хранилище неготовые изменения, и объект лежит захваченным несколько недель. Это тупиковый путь. Неготовые задачи должны вестись в отдельном хранилище, как минимум.

Разработчик не должен бояться потерять свои незавершенные изменения из-за поломки жесткого диска или неприятностей с компьютером. Все незавершенные изменения – это точно такой же актив, и они должны защищаться системой хранения версий, а не сгорать вместе с машиной разработчика.

Всю свою работу разработчик должен спокойно коммитить в отдельную ветку, чтобы она там дальше уже бэкапилась вместе со всем репозиторием. Благодаря веткам вы всегда сможете быть готовым к выпуску стабильного кода. Это нужно обязательно обеспечить.

 

 

Про тестирование долго говорить не буду.

• Это отдельный навык. Без выделенного человека, который владеет этим навыком, запустить тестирование будет очень тяжело.

• Вам обязательно потребуется выделить человека на фуллтайм, который захочет заниматься тестированием, будет в этом разбираться, либо уже умеет это делать, либо захочет научиться это делать.

• Подходов к тестированию очень много, просто будьте готовы к тому, что если у вас компетенции тестирования вообще нет, ее придется где-то получать, и это недешево.

• И еще для запуска тестов на 1С вам потребуется дополнительное железо. Причем достаточно мощное, иначе тесты будут проходить слишком долго.

 

 

И еще один момент.

DevOps – это про необходимое взаимодействие админов и разработчиков. И 1С здесь не исключение, потому что обычно админы говорят: «Ой, это ваше 1С, вы там сами в ней что-то делаете, я даже знать сюда не хочу, в это лезть не хочу». Такого быть не должно.

Понятно, что админы все равно будут отбрыкиваться от 1С, поэтому вы должны им помочь. Нужно прийти к ним и сказать: «Ребята, вы текстовые логи с других систем складываете в Elasticsearch, а мы вам туда тоже можем текстовые логи из 1С положить. Смотрите, как хорошо, удобно получается. Давайте мы вам поможем какие-то метрики с сервера 1С в ваш Zabbix или Grafana повесить. Вот смотрите, как хорошо получается».

Нужно ходить к ним и настраивать с ними дружбу, чтобы получить от них тот самый проактивный мониторинг – обратную связь о том, что происходит с нашими задачами в продакшене.

 

Сервисы

 

 

Теперь пару слов о сервисах.

Напомню, что все компетенции так или иначе поддерживаются сервисами. Этих сервисов много, и вам нужно какие-то выбрать. Но как это сделать?

 

 

Начнем с компетенции «Разработка». Она требует хранения кода. И я уже сказал, что Git – это обязательно. В зависимости от вашего процесса вы можете зеркалировать в Git хранилище 1С или разрабатывать сразу в EDT, чтобы исходники сохранялись в Git.

Для зеркалирования в Git хранилища 1С можно использовать:

• Gitsync

• Oproxy

• GitConverter

• Еще я вам советую присмотреться к инструменту для управления хранилищами OneSwiss. Это бесплатный open-source инструмент, который как швейцарский нож предоставляет все возможные инструменты для управления серверами 1С. В частности, в него встроен сервис синхронизации хранилищ конфигураций и Git.

 

 

Что касается оркестрации процессов, однозначно лучшее, что есть для старта с нуля – Jenkins Library.

Инструмент содержит готовые шаги для всего пайплайна сборки и развертывания 1С. Плюс это все еще широко настраивается и кастомизируется. Автор, Никита Федькин, очень заботится о том, чтобы продуктом было приятно и легко пользоваться. Поэтому берем библиотеку Jenkins Library и никаких велосипедов не изобретаем. Все уже изобретено.

 

 

По поводу тестирования 1С я уже говорил, что запустить его будет непросто.

• Тестирование – это отдельная профессия. Нельзя просто взять 1С-ника, который будет между делом заниматься тестами. Это просто не взлетит. Вам потребуется отдельный человек.

• И это должен быть человек-танк. Он должен всех учить и заставлять писать тесты. Он должен иметь полномочия запрещать выкатывать реализацию задачи в релиз без тестов.

• Это прям недешево и нелегко, но баги дороже.

• И, как я уже говорил, потребуется железо.

• А в качестве инструмента можно использовать Vanessa Automation.

 

 

Ну и мониторинг – та самая обратная связь, ради которой весь DevOps и создается.

Для 1С мониторинг обязательно должен быть организован там же, где мониторятся остальные системы. Вы можете контролировать огромное количество показателей для вашего продакшена, но в минимальном чек-листе я бы выделил два обязательных пункта:

• Вы должны собирать наиболее критичные события технологического журнала – как минимум, по медленным запросам или взаимоблокировкам. Например, если у пользователя запрос выполнялся три минуты – это уже повод обратить на него внимание и оптимизировать. В идеале такие события должны автоматически попадать в систему оповещений: команда сразу видит, у какого пользователя и в каком филиале возник медленный запрос, и может начать разбираться с причиной.

• И второе, что обязательно стоит сделать – это настроить автоматическую регистрацию инцидентов. Например, если у пользователя возникает ошибка, событие о ней попадает в журнал регистрации. Его можно автоматически анализировать и находить эти ошибки, не дожидаясь, пока пользователь самостоятельно обратится в сервис-деск.

Это обязательно нужно сделать.

Основная сложность мониторинга для 1С заключается в том, что среди Open Source-решений для него практически нет готовых бесплатных инструментов. По крайней мере, я таких не знаю. Но в качестве частичного решения могу посоветовать тот же самый OneSwiss. Синхронизация хранилища с Git там сделана хорошо. И основные инструменты мониторинга тоже есть: экспорт технологического журнала и журнала регистрации в ClickHouse, а также сервис регистрации ошибок. Там есть не все, что хотелось бы, но сам инструмент имеет смысл посмотреть.

 

Подведем итоги

 

 

Давайте подведем итоги. Что нужно сделать, чтобы по-быстрому запустить в компании DevOps для 1С:

• Нужно провести исследование текущих процессов. Каждое исследование должно иметь несколько аспектов и направлений – координатных осей, по которым можно исследовать проблему. Проще всего проблематику разбирать с помощью фреймворка компетенций – когда мы берем какую-то независимую, изолированную область полезности и делаем ее хорошей, не трогая остальные, если разбираться с ними тяжело и долго. Берем ту, в которую легко пойти, и делаем ее хорошей. А потом приступаем к остальным.

• Раскладываем текущие процессы в разработке по компетенциям и ведем их к целевому состоянию. А целевое состояние у нас заключается в том, что разработка на 1С не является в ИТ бедным родственником, а существует на тех же сервисах с теми же мощностями и условиями наравне с остальными командами разработки. Это целевое состояние, к которому мы должны прийти.

• Фиксируем проблемы заказчика и думаем, что можно улучшить.

• Договариваемся о ресурсах и о бюджете.

• Выбираем сервисы автоматизации под конкретные процессы.

• И не забываем про железо, потому что в последний момент может выясниться, что железа в компании нет и крутиться нашим волшебным сервисам не на чем.

Желаю вам удачи на непростом пути внедрения DevOps в командах 1С.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.