0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p><strong>DevOps - одно из самых обсуждаемых явлений на технологическом рынке в последние годы, а вакансии, имеющие эту приставку, стали одними из самых дорогостоящих. При этом многие компании до конца не понимают, что означает DevOps, как с этим работать и для чего вообще можно использовать. Мы подробно рассказываем о том, чем сервисный подход к IT отличается от продуктового, о практиках использования DevOps, культуре внедрения и технологиях, которые сделают взаимодействие инженеров разработки и эксплуатации намного эффективнее.</strong></p>
1
<p><strong>DevOps - одно из самых обсуждаемых явлений на технологическом рынке в последние годы, а вакансии, имеющие эту приставку, стали одними из самых дорогостоящих. При этом многие компании до конца не понимают, что означает DevOps, как с этим работать и для чего вообще можно использовать. Мы подробно рассказываем о том, чем сервисный подход к IT отличается от продуктового, о практиках использования DevOps, культуре внедрения и технологиях, которые сделают взаимодействие инженеров разработки и эксплуатации намного эффективнее.</strong></p>
2
<h2>Содержание</h2>
2
<h2>Содержание</h2>
3
<ul><li><a>Александр Титов, управляющий партнер Экспресс 42, основатель сообщества DevOps Moscow: Я живу в понимании DevOps как набора практик по организации целиком всей разработки</a></li>
3
<ul><li><a>Александр Титов, управляющий партнер Экспресс 42, основатель сообщества DevOps Moscow: Я живу в понимании DevOps как набора практик по организации целиком всей разработки</a></li>
4
<li><a>Владимир Утратенко, Head of Technology Platform в Сравни.ру, со-организатор сообщества DevOps Moscow: Многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке</a></li>
4
<li><a>Владимир Утратенко, Head of Technology Platform в Сравни.ру, со-организатор сообщества DevOps Moscow: Многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке</a></li>
5
<li><a>Виталий Рыбников, Lead Site Reliability Engineer в Tinkoff.ru: Компаниям нужен DevOps чтобы выживать, расти и развиваться в современном мире</a></li>
5
<li><a>Виталий Рыбников, Lead Site Reliability Engineer в Tinkoff.ru: Компаниям нужен DevOps чтобы выживать, расти и развиваться в современном мире</a></li>
6
</ul><h2>Александр Титов, управляющий партнер Экспресс 42, основатель сообщества DevOps Moscow: Я живу в понимании DevOps как набора практик по организации целиком всей разработки</h2>
6
</ul><h2>Александр Титов, управляющий партнер Экспресс 42, основатель сообщества DevOps Moscow: Я живу в понимании DevOps как набора практик по организации целиком всей разработки</h2>
7
<p><strong>У термина DevOps довольно много определений - что же это такое и какую проблему решает DevOps?</strong></p>
7
<p><strong>У термина DevOps довольно много определений - что же это такое и какую проблему решает DevOps?</strong></p>
8
<p>- Я бы обратился тут к основам - откуда вообще появился DevOps. Он появился в 2009 году - когда компании, которые занимаются продуктовой IT-разработкой, поняли, что они не могут это делать в рамках сервисных подходов к IT, которые были сформированы в индустрии на тот момент. Стало понятно, что в бизнес-процессах не работает эта сервисная история - когда разработчики работают отдельно от администраторов, которые поддерживают системы в классическом их понимании.</p>
8
<p>- Я бы обратился тут к основам - откуда вообще появился DevOps. Он появился в 2009 году - когда компании, которые занимаются продуктовой IT-разработкой, поняли, что они не могут это делать в рамках сервисных подходов к IT, которые были сформированы в индустрии на тот момент. Стало понятно, что в бизнес-процессах не работает эта сервисная история - когда разработчики работают отдельно от администраторов, которые поддерживают системы в классическом их понимании.</p>
9
<p>Патрик Дебуа, слушая<a>доклад Джона Асплоу</a>об организации работы в продуктовой разработке компании Flickr, сказал, что основная проблема - в объединении разработчиков и администраторов. В итоге из этой проблемы и пошло название DevOps - это про то, как правильно организовать продуктовую разработку внутри компании. Когда команда делает продукт, а не IT-системы, которые просто поддерживают бизнес-процессы.</p>
9
<p>Патрик Дебуа, слушая<a>доклад Джона Асплоу</a>об организации работы в продуктовой разработке компании Flickr, сказал, что основная проблема - в объединении разработчиков и администраторов. В итоге из этой проблемы и пошло название DevOps - это про то, как правильно организовать продуктовую разработку внутри компании. Когда команда делает продукт, а не IT-системы, которые просто поддерживают бизнес-процессы.</p>
10
<p>В целом я живу в понимании DevOps как набора практик по организации целиком всей разработки - и это не про сисадминов, и не про то, как Kubernetes выстраивается. Это про общее формирование подхода к продуктовой разработке. Тут ключевым моментом является формирование практики совместного сотворчества.</p>
10
<p>В целом я живу в понимании DevOps как набора практик по организации целиком всей разработки - и это не про сисадминов, и не про то, как Kubernetes выстраивается. Это про общее формирование подхода к продуктовой разработке. Тут ключевым моментом является формирование практики совместного сотворчества.</p>
11
<p>В сервисном подходе к IT это сотворчество было не обязательно - там все фокусируются просто на поддержке отдельных бизнес-функций. Сейчас же все сообщество ищет подходы в формировании творческой продуктовой разработки - в соединении производства и творчества. Для меня именно это является определением термина DevOps.</p>
11
<p>В сервисном подходе к IT это сотворчество было не обязательно - там все фокусируются просто на поддержке отдельных бизнес-функций. Сейчас же все сообщество ищет подходы в формировании творческой продуктовой разработки - в соединении производства и творчества. Для меня именно это является определением термина DevOps.</p>
12
<p><strong>Какие практики входят в DevOps?</strong></p>
12
<p><strong>Какие практики входят в DevOps?</strong></p>
13
<p>- Организация работы в команде, организация инструментов совместной работы, организация передачи опыта между разными специалистами в команде, инженерные практики по непрерывной поставке программного обеспечения. Плюс это практики observability - не мониторинг и логирование, а скорее понимание того, что происходит с процессом, и как пользователь взаимодействует с продуктом.</p>
13
<p>- Организация работы в команде, организация инструментов совместной работы, организация передачи опыта между разными специалистами в команде, инженерные практики по непрерывной поставке программного обеспечения. Плюс это практики observability - не мониторинг и логирование, а скорее понимание того, что происходит с процессом, и как пользователь взаимодействует с продуктом.</p>
14
<p><strong>Как бизнес начинает использовать эти практики?</strong></p>
14
<p><strong>Как бизнес начинает использовать эти практики?</strong></p>
15
<p>- В первую очередь компании нужно понять, что IT-направление - не сервисная история, а основная производственная функция. Нужно перевести IT из поддерживающей истории в зарабатывающую. Это первый шаг на уровне ментальности с точки зрения бизнеса. Дальше - нужно понять, каких компетенций тебе для этого не хватает, посмотреть на другие компании, которые в эту игру уже играют. Например, посмотреть на Google и Facebook - и увидеть, как они строят свои рабочие процессы, сравнить с производственными процессами в вашей компании.</p>
15
<p>- В первую очередь компании нужно понять, что IT-направление - не сервисная история, а основная производственная функция. Нужно перевести IT из поддерживающей истории в зарабатывающую. Это первый шаг на уровне ментальности с точки зрения бизнеса. Дальше - нужно понять, каких компетенций тебе для этого не хватает, посмотреть на другие компании, которые в эту игру уже играют. Например, посмотреть на Google и Facebook - и увидеть, как они строят свои рабочие процессы, сравнить с производственными процессами в вашей компании.</p>
16
<p>После этого станут видны те компетенции, которых в принципе не хватает компании и продукту, который она делает. Их придется отстраивать каждой компании индивидуально - как организован процесс поставки ПО, как организована вокруг этого команда. Это те задачи, которые каждая компания решает только самостоятельно. По сути, решения этих проблем нельзя просто взять и скопировать - такая модель пришла из сервисного подхода, который мы стараемся изменить.</p>
16
<p>После этого станут видны те компетенции, которых в принципе не хватает компании и продукту, который она делает. Их придется отстраивать каждой компании индивидуально - как организован процесс поставки ПО, как организована вокруг этого команда. Это те задачи, которые каждая компания решает только самостоятельно. По сути, решения этих проблем нельзя просто взять и скопировать - такая модель пришла из сервисного подхода, который мы стараемся изменить.</p>
17
<p>При сервисном подходе к IT компании берут лучшие практики с рынка и начинают их использовать - не задумываясь о причинах появления тех или иных решений. Внутри же продуктового подхода нужно выстраивать собственные кастомизированные процессы - искать то, что действительно нужно бизнесу, чтобы увеличивать ценность своего цифрового продукта.</p>
17
<p>При сервисном подходе к IT компании берут лучшие практики с рынка и начинают их использовать - не задумываясь о причинах появления тех или иных решений. Внутри же продуктового подхода нужно выстраивать собственные кастомизированные процессы - искать то, что действительно нужно бизнесу, чтобы увеличивать ценность своего цифрового продукта.</p>
18
<p><strong>Кто тогда такие DevOps-инженеры?</strong></p>
18
<p><strong>Кто тогда такие DevOps-инженеры?</strong></p>
19
<p>- К ним я отношусь как к временному эффекту. Мы сейчас находимся на водоразделе: моменте перехода IT из сервисной модели в продуктовую. В сервисной модели всегда такой подход, нужно закрывать функцию - для этого нужен специалист. Появилась странная штука DevOps? Не проблема, нужна роль, которая это закроет. И так появляется DevOps-инженер, который как Ops-инженер, но еще умеет что-то. Это мышление из старой модели, но уже про новые вещи. Люди еще не научились думать, как это делают настоящие продуктовые команды. Поэтому они ищут специалистов вот так - и просто не понимают до конца набор компетенций, который им нужен.</p>
19
<p>- К ним я отношусь как к временному эффекту. Мы сейчас находимся на водоразделе: моменте перехода IT из сервисной модели в продуктовую. В сервисной модели всегда такой подход, нужно закрывать функцию - для этого нужен специалист. Появилась странная штука DevOps? Не проблема, нужна роль, которая это закроет. И так появляется DevOps-инженер, который как Ops-инженер, но еще умеет что-то. Это мышление из старой модели, но уже про новые вещи. Люди еще не научились думать, как это делают настоящие продуктовые команды. Поэтому они ищут специалистов вот так - и просто не понимают до конца набор компетенций, который им нужен.</p>
20
<blockquote><h3>Читайте также</h3>
20
<blockquote><h3>Читайте также</h3>
21
<p>Как устроен функциональный диалект Лиспа Clojure и почему использующие его программисты<a>восхищаются им</a></p>
21
<p>Как устроен функциональный диалект Лиспа Clojure и почему использующие его программисты<a>восхищаются им</a></p>
22
</blockquote><p>Если посмотреть на описание вакансий DevOps-инженеров, то там всегда указываются абсолютно разные требования - это и системное администрирование, и поддержка сложных платформенных вещей, и описание платформы в виде кода, и взаимодействие с продуктовой командой в сфере доставки кода, и еще многие и многие процессы. Это очень большое количество компетенций в одном специалисте.</p>
22
</blockquote><p>Если посмотреть на описание вакансий DevOps-инженеров, то там всегда указываются абсолютно разные требования - это и системное администрирование, и поддержка сложных платформенных вещей, и описание платформы в виде кода, и взаимодействие с продуктовой командой в сфере доставки кода, и еще многие и многие процессы. Это очень большое количество компетенций в одном специалисте.</p>
23
<p>Я могу сравнить это с периодом начала интернета - тогда была позиция веб-мастера, который и почтовые сервера настраивал, и верстку на HTML делал, и продукт курировал, и дизайн создавал. Сейчас каждая компетенция ушла отдельному специалисту. Точно так же произойдет и с DevOps-инженером.</p>
23
<p>Я могу сравнить это с периодом начала интернета - тогда была позиция веб-мастера, который и почтовые сервера настраивал, и верстку на HTML делал, и продукт курировал, и дизайн создавал. Сейчас каждая компетенция ушла отдельному специалисту. Точно так же произойдет и с DevOps-инженером.</p>
24
<p>Зачастую в этом DevOps-инженере соединены все противоречия и недостатки текущей сервисной модели. Как только в компанию приходит DevOps-инженер, то у руководства сразу можно спросить - чем он будет заниматься. Окажется, что это либо фулстек веб-мастер, либо специалист с четко выраженными компетенциями - например, сисадмин. Тогда его так и нужно называть - инженер, например, по Continuous Integration. Однако пока в головах менеджеров, которые занимаются управлением в IT, это направление еще не разделилось, и они продолжают существовать в сервисной парадигме, а не думать продуктом и потребностями клиента или пользователей.</p>
24
<p>Зачастую в этом DevOps-инженере соединены все противоречия и недостатки текущей сервисной модели. Как только в компанию приходит DevOps-инженер, то у руководства сразу можно спросить - чем он будет заниматься. Окажется, что это либо фулстек веб-мастер, либо специалист с четко выраженными компетенциями - например, сисадмин. Тогда его так и нужно называть - инженер, например, по Continuous Integration. Однако пока в головах менеджеров, которые занимаются управлением в IT, это направление еще не разделилось, и они продолжают существовать в сервисной парадигме, а не думать продуктом и потребностями клиента или пользователей.</p>
25
<p>Думаю, что пройдет еще несколько лет, и DevOps-инженеры уйдут в историю, как веб-мастера. На их место придут отдельные инженеры по Continuous Integration, продакшн-инженеры, платформенные инженеры, которые работают с Kubernetes, специалисты, работающие с большими бэкенд-системами, такими как базы данных, и так далее. Так разделится эта профессия.</p>
25
<p>Думаю, что пройдет еще несколько лет, и DevOps-инженеры уйдут в историю, как веб-мастера. На их место придут отдельные инженеры по Continuous Integration, продакшн-инженеры, платформенные инженеры, которые работают с Kubernetes, специалисты, работающие с большими бэкенд-системами, такими как базы данных, и так далее. Так разделится эта профессия.</p>
26
<p><strong>Что будет с DevOps в ближайшие годы?</strong></p>
26
<p><strong>Что будет с DevOps в ближайшие годы?</strong></p>
27
<p>- Все будет хорошо. В том смысле, что будут прописываться более четкие компетенции, появятся сформированные новые профессии внутри продуктовой разработки. Появятся организационные схемы - сейчас даже продуктовую разработку описывают таким образом: есть команда, внутри которой работают несколько DevOps-инженеров. Они помогают продуктовой команде выводить фичи в прод. Но на самом деле ключевым моментом является то, что все работают вместе, вместе несут ответственность за ошибки и отвечают за весь процесс - и продуктовая команда, которая делает код, и сервисные инженеры. Платформа, на которой идет разработка - принадлежит всем. И разделение, что если код не выкатывается, то виноват какой-то определенный инженер или команда - вредит всему подходу разработки цифрового продукта и взаимодействию с клиентом.</p>
27
<p>- Все будет хорошо. В том смысле, что будут прописываться более четкие компетенции, появятся сформированные новые профессии внутри продуктовой разработки. Появятся организационные схемы - сейчас даже продуктовую разработку описывают таким образом: есть команда, внутри которой работают несколько DevOps-инженеров. Они помогают продуктовой команде выводить фичи в прод. Но на самом деле ключевым моментом является то, что все работают вместе, вместе несут ответственность за ошибки и отвечают за весь процесс - и продуктовая команда, которая делает код, и сервисные инженеры. Платформа, на которой идет разработка - принадлежит всем. И разделение, что если код не выкатывается, то виноват какой-то определенный инженер или команда - вредит всему подходу разработки цифрового продукта и взаимодействию с клиентом.</p>
28
<p>С точки зрения технологий у нас все уже есть, а вот с точки зрения культурных и организационных парадигм IT ждут серьезные перемены.</p>
28
<p>С точки зрения технологий у нас все уже есть, а вот с точки зрения культурных и организационных парадигм IT ждут серьезные перемены.</p>
29
<p><em>Важные ссылки про DevOps:</em></p>
29
<p><em>Важные ссылки про DevOps:</em></p>
30
<p>-<a>Что такое DevOps</a></p>
30
<p>-<a>Что такое DevOps</a></p>
31
<p>- Базовая книга по<a>инженерным практикам</a></p>
31
<p>- Базовая книга по<a>инженерным практикам</a></p>
32
<p>- Базовые вещи от<a>гуру сферы</a></p>
32
<p>- Базовые вещи от<a>гуру сферы</a></p>
33
<p>- Командные<a>топологии и роли</a></p>
33
<p>- Командные<a>топологии и роли</a></p>
34
<p>-<a>Все про SRE</a></p>
34
<p>-<a>Все про SRE</a></p>
35
<h2>Владимир Утратенко, Head of Technology Platform в Сравни.ру, со-организатор сообщества DevOps Moscow: Многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке</h2>
35
<h2>Владимир Утратенко, Head of Technology Platform в Сравни.ру, со-организатор сообщества DevOps Moscow: Многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке</h2>
36
<p><strong>У термина DevOps много определений. Что это такое и какую проблему он решает?</strong></p>
36
<p><strong>У термина DevOps много определений. Что это такое и какую проблему он решает?</strong></p>
37
<p>- Исторически у нас существует стена непонимания между ребятами, которые занимаются разработкой, и ребятами, которые занимаются эксплуатацией. DevOps - это как раз соединение development и operations. Соответственно, девелоперы хотели пилить фичи, поставлять свежий функционал, а ребята из эксплуатации - болели за надежность и стабильность и, соответственно, не очень любили новые фичи.</p>
37
<p>- Исторически у нас существует стена непонимания между ребятами, которые занимаются разработкой, и ребятами, которые занимаются эксплуатацией. DevOps - это как раз соединение development и operations. Соответственно, девелоперы хотели пилить фичи, поставлять свежий функционал, а ребята из эксплуатации - болели за надежность и стабильность и, соответственно, не очень любили новые фичи.</p>
38
<p>Так происходит не везде, но это достаточно распространенная картина в индустрии. В 2009 году на одной из конференции ребята из компании Flickr рассказали, что смогли подружить разработку с эксплуатацией, и в итоге деплоить свой сервис больше десяти раз в день.</p>
38
<p>Так происходит не везде, но это достаточно распространенная картина в индустрии. В 2009 году на одной из конференции ребята из компании Flickr рассказали, что смогли подружить разработку с эксплуатацией, и в итоге деплоить свой сервис больше десяти раз в день.</p>
39
<p>Буквально следом за этим Патрик Дебуа - один из идеологов DevOps-движения, собрал конференцию, на которую пришло неожиданно много людей - и из разработки, и из эксплуатации. Пришли те, у кого это тоже болело - и с тех пор пошло, что DevOps - скорее, история про то, как им работать вместе, про организационные изменения, которые для этого нужны, про софт, помогающий ускорить эти процессы. Во многом это именно про людей, культуру и то, как они делают свою работу.</p>
39
<p>Буквально следом за этим Патрик Дебуа - один из идеологов DevOps-движения, собрал конференцию, на которую пришло неожиданно много людей - и из разработки, и из эксплуатации. Пришли те, у кого это тоже болело - и с тех пор пошло, что DevOps - скорее, история про то, как им работать вместе, про организационные изменения, которые для этого нужны, про софт, помогающий ускорить эти процессы. Во многом это именно про людей, культуру и то, как они делают свою работу.</p>
40
<p>Наиболее подходящим определением будет, что DevOps - это путь разработки программного обеспечения в технологических компаниях. Именно путь - то есть, непрерывный процесс. Внедрить DevOps нельзя - его можно разве что вырастить внутри компании, стать DevOps.</p>
40
<p>Наиболее подходящим определением будет, что DevOps - это путь разработки программного обеспечения в технологических компаниях. Именно путь - то есть, непрерывный процесс. Внедрить DevOps нельзя - его можно разве что вырастить внутри компании, стать DevOps.</p>
41
<p><strong>А что такое тогда DevOps-инженер?</strong></p>
41
<p><strong>А что такое тогда DevOps-инженер?</strong></p>
42
<p>- DevOps-инженер - это исторически сложившийся HR-термин. Когда история с DevOps начала распространяться, многие компании захотели применять эти практики, но начали использовать неверный подход. Условно, приходит начальник компании к HR и говорит, что нужно внедрять DevOps, но для этого нужно найти человека, который умеет с этим работать. В итоге HR начинает искать DevOps-инженера - так термин и появился. В целом это совсем некорректно, но, несмотря на наше отношение, термин сложился, им пользуются на рынке - и просто так отмахнуться от него мы уже не можем.</p>
42
<p>- DevOps-инженер - это исторически сложившийся HR-термин. Когда история с DevOps начала распространяться, многие компании захотели применять эти практики, но начали использовать неверный подход. Условно, приходит начальник компании к HR и говорит, что нужно внедрять DevOps, но для этого нужно найти человека, который умеет с этим работать. В итоге HR начинает искать DevOps-инженера - так термин и появился. В целом это совсем некорректно, но, несмотря на наше отношение, термин сложился, им пользуются на рынке - и просто так отмахнуться от него мы уже не можем.</p>
43
<p>Люди, которых называют DevOps-инженерами, чаще всего представляют собой сисадминов - людей из эксплуатации, которые занимаются поддержкой и обслуживанием сервисов информационных систем и инфраструктуры. По сути, эта та же самая позиция сисадмина, но названная иначе - и с другой зарплатой.</p>
43
<p>Люди, которых называют DevOps-инженерами, чаще всего представляют собой сисадминов - людей из эксплуатации, которые занимаются поддержкой и обслуживанием сервисов информационных систем и инфраструктуры. По сути, эта та же самая позиция сисадмина, но названная иначе - и с другой зарплатой.</p>
44
<p><strong>То есть разницы между системным инженером и DevOps-специалистом особой быть не должно?</strong></p>
44
<p><strong>То есть разницы между системным инженером и DevOps-специалистом особой быть не должно?</strong></p>
45
<p>- И да, и нет. Существуют DevOps-евангелисты, которые несут эту практику и культуру - они помогают компаниям проводить организационные изменения. Таким образом, чтобы компания начала использовать DevOps - не нужно нанимать DevOps-инженера, бизнесу самому нужно становиться DevOps-ориентированным. Люди в компании начинают работать таким образом, чтобы сложилась эта синергия, а организационная культура должна измениться до того уровня, чтобы специалисты начали друг с другом взаимодействовать более эффективно.</p>
45
<p>- И да, и нет. Существуют DevOps-евангелисты, которые несут эту практику и культуру - они помогают компаниям проводить организационные изменения. Таким образом, чтобы компания начала использовать DevOps - не нужно нанимать DevOps-инженера, бизнесу самому нужно становиться DevOps-ориентированным. Люди в компании начинают работать таким образом, чтобы сложилась эта синергия, а организационная культура должна измениться до того уровня, чтобы специалисты начали друг с другом взаимодействовать более эффективно.</p>
46
<p>Единственные настоящие DevOps-специалисты - это DevOps-евангелисты, которые несут в себе культуру, практики и организационные изменения. А тех, кого сейчас в сфере обычно называют DevOps-инженерами - сисадмины, на которых свалили все что можно, от поддержки продакшна до построения процесса поставки и релиза программного обеспечения. При этом такие инженеры очень быстро выгорают - они не чувствуют себя комфортно на своем месте, они не занимаются какими-то конкретными вещами.</p>
46
<p>Единственные настоящие DevOps-специалисты - это DevOps-евангелисты, которые несут в себе культуру, практики и организационные изменения. А тех, кого сейчас в сфере обычно называют DevOps-инженерами - сисадмины, на которых свалили все что можно, от поддержки продакшна до построения процесса поставки и релиза программного обеспечения. При этом такие инженеры очень быстро выгорают - они не чувствуют себя комфортно на своем месте, они не занимаются какими-то конкретными вещами.</p>
47
<p><strong>Кто в компании должен внедрять DevOps?</strong></p>
47
<p><strong>Кто в компании должен внедрять DevOps?</strong></p>
48
<p>- В первую очередь руководство компании по IT и технологиям. DevOps - это вещь, которая в первую очередь идет именно с этой стороны. Конечно, иногда запросы на DevOps приходят со стороны инженеров, которых что-то не устраивает. Но без непосредственного участия людей, которые управляют разработкой и эксплуатацией, ничего не заведется. DevOps во многом основан на организационных изменениях и процессах коммуникации людей из разных департаментов. Поэтому наиболее эффективным методом внедрения DevOps является задействование людей из IT-менеджмента, чем рядовых специалистов.</p>
48
<p>- В первую очередь руководство компании по IT и технологиям. DevOps - это вещь, которая в первую очередь идет именно с этой стороны. Конечно, иногда запросы на DevOps приходят со стороны инженеров, которых что-то не устраивает. Но без непосредственного участия людей, которые управляют разработкой и эксплуатацией, ничего не заведется. DevOps во многом основан на организационных изменениях и процессах коммуникации людей из разных департаментов. Поэтому наиболее эффективным методом внедрения DevOps является задействование людей из IT-менеджмента, чем рядовых специалистов.</p>
49
<p><strong>Как технически устроен DevOps?</strong></p>
49
<p><strong>Как технически устроен DevOps?</strong></p>
50
<p>- Одна из ключевых вещей в DevOps - практики Continuous delivery и все, что с ними связано. Принципиальная разница по сравнению со стандартными подходами к эксплуатации здесь в том, что мы к любой задаче относимся как к программному решению, которое можно реализовать с помощью написания кода: не важно, это вещь, с которой работают внешние пользователи, это внутренний сервис или инфраструктура. В дополнение к этому важны архитектурные вещи, например, слабо связная архитектура, смысл которой, в первую очередь, в уменьшении количества зависимостей насколько это возможно, практики бережливого производства, вроде визуализации потока создания ценности и управления им. Кроме того, важны выполнение работы минимально возможными частями, практики мониторинга, а также культурных аспектов вроде поддержки взаимодействия между командами или продвижения идей трансформационного лидерства.</p>
50
<p>- Одна из ключевых вещей в DevOps - практики Continuous delivery и все, что с ними связано. Принципиальная разница по сравнению со стандартными подходами к эксплуатации здесь в том, что мы к любой задаче относимся как к программному решению, которое можно реализовать с помощью написания кода: не важно, это вещь, с которой работают внешние пользователи, это внутренний сервис или инфраструктура. В дополнение к этому важны архитектурные вещи, например, слабо связная архитектура, смысл которой, в первую очередь, в уменьшении количества зависимостей насколько это возможно, практики бережливого производства, вроде визуализации потока создания ценности и управления им. Кроме того, важны выполнение работы минимально возможными частями, практики мониторинга, а также культурных аспектов вроде поддержки взаимодействия между командами или продвижения идей трансформационного лидерства.</p>
51
<p><strong>Каким будет будущее DevOps?</strong></p>
51
<p><strong>Каким будет будущее DevOps?</strong></p>
52
<p>- Сейчас становится понятно, что все больше и больше бизнеса использует DevOps. Было какое-то исследование, что многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке. Это очень вероятно, учитывая, что темпы производства программного обеспечения растут и необходимы новые эффективные способы взаимодействия между участниками процесса разработки и процесса поставки ПО.</p>
52
<p>- Сейчас становится понятно, что все больше и больше бизнеса использует DevOps. Было какое-то исследование, что многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке. Это очень вероятно, учитывая, что темпы производства программного обеспечения растут и необходимы новые эффективные способы взаимодействия между участниками процесса разработки и процесса поставки ПО.</p>
53
<h2>Виталий Рыбников, Lead Site Reliability Engineer в Tinkoff.ru: Компаниям нужен DevOps чтобы выживать, расти и развиваться в современном мире</h2>
53
<h2>Виталий Рыбников, Lead Site Reliability Engineer в Tinkoff.ru: Компаниям нужен DevOps чтобы выживать, расти и развиваться в современном мире</h2>
54
<p><strong>У термина DevOps достаточно много определений. Что же всё-таки такое DevOps и какую проблему он решает?</strong></p>
54
<p><strong>У термина DevOps достаточно много определений. Что же всё-таки такое DevOps и какую проблему он решает?</strong></p>
55
<p>- Верно, определений довольно много. В настоящее время есть определённая путаница с терминологией. Да и однозначного чёткого ответа нет, каждый эксперт скажет свою интерпретацию. Хотя с самим термином "DevOps" плюс-минус всё понятно и есть на кого ссылаться. DevOps - набор практик и культурное движение, которое позволяет сократить Time-to-Market и доставлять стабильный и качественный продукт клиентам.</p>
55
<p>- Верно, определений довольно много. В настоящее время есть определённая путаница с терминологией. Да и однозначного чёткого ответа нет, каждый эксперт скажет свою интерпретацию. Хотя с самим термином "DevOps" плюс-минус всё понятно и есть на кого ссылаться. DevOps - набор практик и культурное движение, которое позволяет сократить Time-to-Market и доставлять стабильный и качественный продукт клиентам.</p>
56
<p>Зачем компаниям нужен DevOps? Чтобы выживать, расти и развиваться в современном мире. Мир меняется, и теперь уже нельзя пройти прямой путь от точки А к точке В по чёткому ТЗ. Клиенты каждый день хотят разного и нового. Точка В постоянно убегает (привет, Agile) и мы не знаем, как к ней прийти наиболее быстро. Поэтому важны итеративные маленькие шаги (частые релизы), регулярные тесты гипотез, быстрая обратная связь от клиентов и регулярная корректировка нашего курса, а также право на ошибки и эксперименты. Тогда у нас будет наибольшее число клиентов, довольных нашим продуктом. А значит, наша компания получает наибольшую прибыль и бизнес работает!</p>
56
<p>Зачем компаниям нужен DevOps? Чтобы выживать, расти и развиваться в современном мире. Мир меняется, и теперь уже нельзя пройти прямой путь от точки А к точке В по чёткому ТЗ. Клиенты каждый день хотят разного и нового. Точка В постоянно убегает (привет, Agile) и мы не знаем, как к ней прийти наиболее быстро. Поэтому важны итеративные маленькие шаги (частые релизы), регулярные тесты гипотез, быстрая обратная связь от клиентов и регулярная корректировка нашего курса, а также право на ошибки и эксперименты. Тогда у нас будет наибольшее число клиентов, довольных нашим продуктом. А значит, наша компания получает наибольшую прибыль и бизнес работает!</p>
57
<p>Всем ли это нужно? Конечно, нет. DevOps имеет смысл внедрять преимущественно<strong>технологическим компаниям</strong>, которые разрабатывают<strong>цифровой продукт</strong>и для которых<strong>важен Time-to-Market</strong>в своей нише (время от начала разработки идеи, до того момента, как её увидят пользователи).</p>
57
<p>Всем ли это нужно? Конечно, нет. DevOps имеет смысл внедрять преимущественно<strong>технологическим компаниям</strong>, которые разрабатывают<strong>цифровой продукт</strong>и для которых<strong>важен Time-to-Market</strong>в своей нише (время от начала разработки идеи, до того момента, как её увидят пользователи).</p>
58
<p>Можно подумать: "А что, собственно, не так? Почему нельзя просто взять и релизить чаще, ничего не меняя?"</p>
58
<p>Можно подумать: "А что, собственно, не так? Почему нельзя просто взять и релизить чаще, ничего не меняя?"</p>
59
<p>Ну, вот нельзя. В классической схеме без использования практик DevOps все основные стадии разработки продукта (аналитика, разработка, тестирование, эксплуатация) проходят линейно, друг за другом, что крайне медленно. Сюда же мы добавляем организационные проблемы:</p>
59
<p>Ну, вот нельзя. В классической схеме без использования практик DevOps все основные стадии разработки продукта (аналитика, разработка, тестирование, эксплуатация) проходят линейно, друг за другом, что крайне медленно. Сюда же мы добавляем организационные проблемы:</p>
60
<ul><li>изоляция между отделами, благодаря которой нет обмена информацией и необходимой глубины коммуникаций и доверия</li>
60
<ul><li>изоляция между отделами, благодаря которой нет обмена информацией и необходимой глубины коммуникаций и доверия</li>
61
<li>отсутствие ответственного за весь продукт</li>
61
<li>отсутствие ответственного за весь продукт</li>
62
<li>разные KPI и приоритеты у dev, qa и ops команд, благодаря чему каждый "тянет одеяло на себя" и делает так, как ему лучше</li>
62
<li>разные KPI и приоритеты у dev, qa и ops команд, благодаря чему каждый "тянет одеяло на себя" и делает так, как ему лучше</li>
63
<li>каждая команда изобретает свой велосипед, в котором понимает только она (крайне трудно переиспользовать опыт).</li>
63
<li>каждая команда изобретает свой велосипед, в котором понимает только она (крайне трудно переиспользовать опыт).</li>
64
</ul><p>В итоге у нас релизы раз в пару месяцев, и те периодически откатываем. Новые фичи и гипотезы доезжают до пользователей прода ещё реже. Никто постоянно не следит за продакшеном, а восстановление после сбоев затягивается на дни или недели.</p>
64
</ul><p>В итоге у нас релизы раз в пару месяцев, и те периодически откатываем. Новые фичи и гипотезы доезжают до пользователей прода ещё реже. Никто постоянно не следит за продакшеном, а восстановление после сбоев затягивается на дни или недели.</p>
65
<p>В случае же DevOps - все стадии разработки продукта идут одновременно и максимально быстро, потому что структура всех коммуникаций и разработки направлены именно на это. Корректно будет сказать, что DevOps - это не конечная чётко определённая цель, это движение, по которому идёт вся компания. Это способ разработки программного обеспечения. DevOps - это когда люди, технологии и процессы объединяются ради одной миссии - клиентоориентированности.</p>
65
<p>В случае же DevOps - все стадии разработки продукта идут одновременно и максимально быстро, потому что структура всех коммуникаций и разработки направлены именно на это. Корректно будет сказать, что DevOps - это не конечная чётко определённая цель, это движение, по которому идёт вся компания. Это способ разработки программного обеспечения. DevOps - это когда люди, технологии и процессы объединяются ради одной миссии - клиентоориентированности.</p>
66
<p>Чтобы разобраться, какие конкретно принципы, практики и подходы рекомендуются в DevOps, есть несколько фреймворков:</p>
66
<p>Чтобы разобраться, какие конкретно принципы, практики и подходы рекомендуются в DevOps, есть несколько фреймворков:</p>
67
<ul><li>Три пути: принцип потока, принцип непрерывной обратной связи, принцип непрерывного обучения и экспериментирования</li>
67
<ul><li>Три пути: принцип потока, принцип непрерывной обратной связи, принцип непрерывного обучения и экспериментирования</li>
68
<li>CALMs</li>
68
<li>CALMs</li>
69
<li>Accelerate</li>
69
<li>Accelerate</li>
70
</ul><p><strong>Чем занимается DevOps-инженер в команде?</strong></p>
70
</ul><p><strong>Чем занимается DevOps-инженер в команде?</strong></p>
71
<p>- В самой культуре и концепции DevOps, в её практиках и подходах нет такой сущности и выделенной единицы как DevOps-инженер. То есть или вся компания идёт по пути DevOps, или там и говорить не о чем. Но... есть теория, описывающая конечное состояние, а есть суровая реальность.</p>
71
<p>- В самой культуре и концепции DevOps, в её практиках и подходах нет такой сущности и выделенной единицы как DevOps-инженер. То есть или вся компания идёт по пути DevOps, или там и говорить не о чем. Но... есть теория, описывающая конечное состояние, а есть суровая реальность.</p>
72
<p>В жизни переход от "без DevOps" к "у нас DevOps" не бывает бинарным. Это длительный процесс, который в разных компаниях занимает разное время. Компания должна пройти этапы от "зарождения и прорастания идеи", к "DevOps-трансформации" и затем к финальному "непрерывному улучшению". Так вот, устоялось, что компании на первом и втором этапах называют "DevOps-инженерами" всех людей, использующих (или только начинающих) DevOps-инструменты.</p>
72
<p>В жизни переход от "без DevOps" к "у нас DevOps" не бывает бинарным. Это длительный процесс, который в разных компаниях занимает разное время. Компания должна пройти этапы от "зарождения и прорастания идеи", к "DevOps-трансформации" и затем к финальному "непрерывному улучшению". Так вот, устоялось, что компании на первом и втором этапах называют "DevOps-инженерами" всех людей, использующих (или только начинающих) DevOps-инструменты.</p>
73
<p>Их можно понять, альтернативных терминов никто не предложил. Это не то, что бы "хорошо", но это реальность. Эдакий рудимент затянувшейся трансформации в российских реалиях. Все боятся и не хотят меняться, а чем крупнее компания - тем тяжелее и длительнее процесс. Однако я не замечал, чтобы компании, достигшие финала, продолжали "грешить" DevOps-инженерами. Куда-то они всё-таки деваются по мере взросления компании.</p>
73
<p>Их можно понять, альтернативных терминов никто не предложил. Это не то, что бы "хорошо", но это реальность. Эдакий рудимент затянувшейся трансформации в российских реалиях. Все боятся и не хотят меняться, а чем крупнее компания - тем тяжелее и длительнее процесс. Однако я не замечал, чтобы компании, достигшие финала, продолжали "грешить" DevOps-инженерами. Куда-то они всё-таки деваются по мере взросления компании.</p>
74
<p>Чем занимается DevOps-инженер? Если проанализировать вакансии на hh.ru, то заниматься предстоит всеми ops-ролями сразу: сборка, деплой, CI/CD, развёртывание серверов, тюнинг ОС, поддержка приложений, поддержка баз данных, мониторинг, безопасность.</p>
74
<p>Чем занимается DevOps-инженер? Если проанализировать вакансии на hh.ru, то заниматься предстоит всеми ops-ролями сразу: сборка, деплой, CI/CD, развёртывание серверов, тюнинг ОС, поддержка приложений, поддержка баз данных, мониторинг, безопасность.</p>
75
<p>Набор ролей, которые ожидают на этой должности, варьируется от компании к компании. В маленьких компаниях, скорее всего, придётся заниматься всем и сразу. И это может быть как один человек, так и несколько, и даже целый DevOps-отдел. Неясно, что конкретно нужно, потому что нужно всё и сразу.</p>
75
<p>Набор ролей, которые ожидают на этой должности, варьируется от компании к компании. В маленьких компаниях, скорее всего, придётся заниматься всем и сразу. И это может быть как один человек, так и несколько, и даже целый DevOps-отдел. Неясно, что конкретно нужно, потому что нужно всё и сразу.</p>
76
<p>Ясность приходит позже. По мере взросления компании и смены парадигмы коммуникаций и вообще процессов, каждую роль занимает отдельный человек/люди с конкретной специализацией. И вот у нас уже появляются build-инженер, релиз-инженер, инженер платформы, DBA, Linux-инженер, SRE, специалист по безопасности и так далее.</p>
76
<p>Ясность приходит позже. По мере взросления компании и смены парадигмы коммуникаций и вообще процессов, каждую роль занимает отдельный человек/люди с конкретной специализацией. И вот у нас уже появляются build-инженер, релиз-инженер, инженер платформы, DBA, Linux-инженер, SRE, специалист по безопасности и так далее.</p>
77
<blockquote><h3>Читайте также</h3>
77
<blockquote><h3>Читайте также</h3>
78
<p>Почему нумерация должна<a>начинаться с нуля</a></p>
78
<p>Почему нумерация должна<a>начинаться с нуля</a></p>
79
</blockquote><p><strong>Может ли программист стать DevOps-инженером? Как вообще становятся DevOps?</strong></p>
79
</blockquote><p><strong>Может ли программист стать DevOps-инженером? Как вообще становятся DevOps?</strong></p>
80
<p>- Поговорим не совсем про реальность, но про идеальный случай, раз уж имеем дело с подобным собирательным образом. В идеальном случае DevOps-инженер, помимо глубокой технической экспертизы, разбирается в теме этого самого DevOps, и помогает распространять знания и практики, компетенции внутри компании (часть enabling team).</p>
80
<p>- Поговорим не совсем про реальность, но про идеальный случай, раз уж имеем дело с подобным собирательным образом. В идеальном случае DevOps-инженер, помимо глубокой технической экспертизы, разбирается в теме этого самого DevOps, и помогает распространять знания и практики, компетенции внутри компании (часть enabling team).</p>
81
<p>Стать таким персонажем может любой инженер: системный администратор, разработчик, инженер автоматизации, инженер платформы и т.д. Достаточно серьёзно углубить soft-skills, hard-skills, изучить культуру и практики.</p>
81
<p>Стать таким персонажем может любой инженер: системный администратор, разработчик, инженер автоматизации, инженер платформы и т.д. Достаточно серьёзно углубить soft-skills, hard-skills, изучить культуру и практики.</p>
82
<p>Программист в некотором роде - идеальный кандидат, так как он изначально ближе всех к продукту и процессу разработки. Ему легче всех понять новые концепции, подходы и понять боль как Dev, так и Ops. You code it, you build it, you run it, you own it.</p>
82
<p>Программист в некотором роде - идеальный кандидат, так как он изначально ближе всех к продукту и процессу разработки. Ему легче всех понять новые концепции, подходы и понять боль как Dev, так и Ops. You code it, you build it, you run it, you own it.</p>
83
<p>Как же приходят к DevOps? Это вот когда человек получил некий опыт работы в IT, затем начитался книжек, наслушался докладов, и в нём это откликается. Человек понимает, что больше нельзя жить как раньше! Хватит это терпеть! У него появляется жгучее желание сделать эту компанию лучше, изменить процессы, инструменты и подходы к работе и избавить коллег вокруг от регулярной боли и рутины!</p>
83
<p>Как же приходят к DevOps? Это вот когда человек получил некий опыт работы в IT, затем начитался книжек, наслушался докладов, и в нём это откликается. Человек понимает, что больше нельзя жить как раньше! Хватит это терпеть! У него появляется жгучее желание сделать эту компанию лучше, изменить процессы, инструменты и подходы к работе и избавить коллег вокруг от регулярной боли и рутины!</p>
84
<p>Что стоит прочитать в первую очередь:</p>
84
<p>Что стоит прочитать в первую очередь:</p>
85
<ul><li>Проект "Феникс"</li>
85
<ul><li>Проект "Феникс"</li>
86
<li>DevOps HandBook</li>
86
<li>DevOps HandBook</li>
87
<li>Accelerate</li>
87
<li>Accelerate</li>
88
</ul><p><strong>В чём разница между DevOps-инженером и системным администратором?</strong></p>
88
</ul><p><strong>В чём разница между DevOps-инженером и системным администратором?</strong></p>
89
<p>- В зарплате. Если серьёзно, могу предположить, что DevOps-инженер:</p>
89
<p>- В зарплате. Если серьёзно, могу предположить, что DevOps-инженер:</p>
90
<ol><li>Понимает, что в индустрии "что-то происходит", нужно быть в тренде и пора изучать "какой-то там DevOps"</li>
90
<ol><li>Понимает, что в индустрии "что-то происходит", нужно быть в тренде и пора изучать "какой-то там DevOps"</li>
91
<li>По сравнению с классическим сисадмином больше задумывается об автоматизации и умеет программировать</li>
91
<li>По сравнению с классическим сисадмином больше задумывается об автоматизации и умеет программировать</li>
92
<li>Начинает (ооочень медленно и потихоньку) думать о клиентах и бизнесе.</li>
92
<li>Начинает (ооочень медленно и потихоньку) думать о клиентах и бизнесе.</li>
93
</ol><p><strong>Куда расти DevOps-инженеру?</strong></p>
93
</ol><p><strong>Куда расти DevOps-инженеру?</strong></p>
94
<p>- На самом деле - куда угодно. Самый популярный вектор - в SRE. Однако можно расти и в разработчика продуктовой команды, разработчика/инженера платформенной команды, архитектора, возглавить центр-компетенции, заняться развитием внутренних сообществ или перейти в enabling team. Всё очень зависит от кругозора, желаний и конкретной ситуации в конкретной компании. Каких-то конкретных ограничений нет, просто каждая из ролей подразумевает углублённую специализацию в ту или иную сторону.</p>
94
<p>- На самом деле - куда угодно. Самый популярный вектор - в SRE. Однако можно расти и в разработчика продуктовой команды, разработчика/инженера платформенной команды, архитектора, возглавить центр-компетенции, заняться развитием внутренних сообществ или перейти в enabling team. Всё очень зависит от кругозора, желаний и конкретной ситуации в конкретной компании. Каких-то конкретных ограничений нет, просто каждая из ролей подразумевает углублённую специализацию в ту или иную сторону.</p>
95
<p><strong>Какие инструменты и технологии должен знать DevOps-инженер?</strong></p>
95
<p><strong>Какие инструменты и технологии должен знать DevOps-инженер?</strong></p>
96
<p>- Он однозначно должен знать базу и иметь хотя бы представление о многих вещах. Полноценный Ж-shape person. ОС/linux, сети, git, Docker, навыки разработки, базы данных, SQL, SDLC, CI, мониторинг и т.д. и т.п. Вот, кстати, довольно популярный универсальный "DevOps-roadmap"<a>по инструментам и технологиям для изучения</a>. А дальше нужно углубляться в конкретные инструменты под конкретные задачи, выполнения которых от тебя ожидают. Как мы помним, DevOps-инженер в разных компаниях будет заниматься абсолютно разным. Но ему точно потребуются soft-skills и навыки общения, так как общаться предстоит очень много.</p>
96
<p>- Он однозначно должен знать базу и иметь хотя бы представление о многих вещах. Полноценный Ж-shape person. ОС/linux, сети, git, Docker, навыки разработки, базы данных, SQL, SDLC, CI, мониторинг и т.д. и т.п. Вот, кстати, довольно популярный универсальный "DevOps-roadmap"<a>по инструментам и технологиям для изучения</a>. А дальше нужно углубляться в конкретные инструменты под конкретные задачи, выполнения которых от тебя ожидают. Как мы помним, DevOps-инженер в разных компаниях будет заниматься абсолютно разным. Но ему точно потребуются soft-skills и навыки общения, так как общаться предстоит очень много.</p>
97
<p>Порекомендую пару известных сайтов для подбора инструмента под конкретную сферу/задачу, так как нынче их слишком много:<a>раз</a>,<a>два</a>.</p>
97
<p>Порекомендую пару известных сайтов для подбора инструмента под конкретную сферу/задачу, так как нынче их слишком много:<a>раз</a>,<a>два</a>.</p>
98
<p><strong>Какие подходы и практики в своей работе используют DevOps-инженеры?</strong></p>
98
<p><strong>Какие подходы и практики в своей работе используют DevOps-инженеры?</strong></p>
99
<p>- Все принципы, подходы и практики трудно описать "коротко" и понятно. Перечислю основные технические практики:</p>
99
<p>- Все принципы, подходы и практики трудно описать "коротко" и понятно. Перечислю основные технические практики:</p>
100
<ul><li>Быстрое и надёжное автоматизированное тестирование</li>
100
<ul><li>Быстрое и надёжное автоматизированное тестирование</li>
101
<li>Динамические тестовые стенды</li>
101
<li>Динамические тестовые стенды</li>
102
<li>Непрерывная поставка (CI, CD, TBD)</li>
102
<li>Непрерывная поставка (CI, CD, TBD)</li>
103
<li>IaC и версионирование всего как подход</li>
103
<li>IaC и версионирование всего как подход</li>
104
<li>Непрерывный мониторинг и обратная связь</li>
104
<li>Непрерывный мониторинг и обратная связь</li>
105
<li>Использование PaaS</li>
105
<li>Использование PaaS</li>
106
<li>Кросс-функциональные команды</li>
106
<li>Кросс-функциональные команды</li>
107
<li>Слабосвязанная архитектура</li>
107
<li>Слабосвязанная архитектура</li>
108
<li>Общая ответственность всех за свои решения</li>
108
<li>Общая ответственность всех за свои решения</li>
109
<li>Распространение знаний по командам и компании</li>
109
<li>Распространение знаний по командам и компании</li>
110
<li>Привлечение команды безопасности на всех этапах SDLC</li>
110
<li>Привлечение команды безопасности на всех этапах SDLC</li>
111
<li>и другие</li>
111
<li>и другие</li>
112
</ul><p><strong>Какое будущее ждет сферу DevOps?</strong></p>
112
</ul><p><strong>Какое будущее ждет сферу DevOps?</strong></p>
113
<p>- 2020 год наглядно показал, что переход в онлайн и цифровая трансформация для многих компаний не то что неизбежны, а жизненно необходимы. А значит, и перестройка на рельсы DevOps как часть цифровой трансформации - лишь вопрос времени, и останутся и выживут те, кто это осилит.</p>
113
<p>- 2020 год наглядно показал, что переход в онлайн и цифровая трансформация для многих компаний не то что неизбежны, а жизненно необходимы. А значит, и перестройка на рельсы DevOps как часть цифровой трансформации - лишь вопрос времени, и останутся и выживут те, кто это осилит.</p>
114
<blockquote><h3>Познакомьтесь поближе с практиками DevOps</h3>
114
<blockquote><h3>Познакомьтесь поближе с практиками DevOps</h3>
115
<p>на нашем интенсиве<a>"DevOps для программистов"</a></p>
115
<p>на нашем интенсиве<a>"DevOps для программистов"</a></p>
116
</blockquote>
116
</blockquote>