devops lead что это

От «стесняшки» до «архитектора»: какими бывают DevOps и как стать одним из них

DevOps-инженеры — люди, которые создают и контролируют процессы поставки ПО от программистов к конечному потребителю. Они участвуют в разработке, тестировании и введении в эксплуатацию программного продукта, обеспечивают автоматизацию этих процессов. Их задача — вывод нового продукта на рынок как можно быстрее, минимизация количества ошибок при релизах и быстрое восстановление системы при возможных сбоях.

Александр Крылов, DevOps-инженер, поделился своим опытом и личным взглядом на профессию. Он рассказал, чем девопсы отличаются друг от друга и что нужно включить в индивидуальный график обучения, чтобы стать одним из них.

Поделился своей классификацией девопсов и рассказал, как попасть в профессию

Привет! Я Александр Крылов — Lead DevOps services в ПАО СК Росгосстрах, работаю в сфере с 2013 года. Сегодня поделюсь с вами накопленным за годы работы опытом.

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

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

Понятно, что лучше, когда есть опыт системного администрирования или разработки, это даёт на старте хороший трамплин. Но не у всех такой есть. Кроме того, DevOps — это не только технологии. Это культура взаимодействия, поэтому гибкие навыки тут тоже важны. Речь не про способность много говорить или любить тусовки, как часто воспринимают soft skills. Я считаю, что получить теоретические знания и научиться пользоваться инструментами DevOps-инженера можно на курсах, но культуру и процессы получится понять и прочувствовать, только работая в команде.

Кто такой DevOps-инженер, что он делает, сколько зарабатывает и как им стать

Какими бывают девопсы: опыт классификации специалистов

Градация среди инженеров по уровню задач, которые они решают, безусловно, есть. Это, конечно, стандартная база: junior, middle, senior. Но мои наблюдения показывают, что даже на этих уровнях различия между специалистами очень большие.

Junior

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

Middle

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

Senior DevOps

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

Профессия

Источник

От стесняшки до архитектора: какими бывают DevOps и как стать одним из них

Александр Крылов

Крылов Александр, Lead DevOps services ПАО СК Росгосстрах, гик по жизни вокалист группы Terror Inside, любитель фантастики и всего, что связано с Unix.

Понятно, что лучше, когда есть опыт системного администрирования или разработки, это даёт на старте хороший трамплин. Но не у всех такой есть. Кроме того, DevOps — это не только технологии. Это культура взаимодействия, поэтому гибкие навыки тут тоже важны. Речь не про способность много говорить или любить тусовки, как часто воспринимают soft skills. Я считаю, что на DevOps-инженера можно обучиться в части теоретических знаний и использования инструментов, но культуру и процессы можно понять и прочувствовать, только работая в команде.

Увалень, интроверт, агрессор: опыт классификации девопсов

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

Студент — имеет теорию без практики, легко обучаем.

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

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

Админ — человек из админов, со знаниями, готов развиваться в автоматизацию, разработку и коллаборацию с другими подразделениями. Чаще всего такие быстро становятся мидлами, но не всегда доходят до сеньоров.

Middle — люди, имеющие опыт, побывали джунами. Не боятся задавать вопросы, могут быть автономными, в некоторых случаях сами ставить себе задачи. Но и среди них есть градации:

Разработчик-интроверт — он может быть хорошим специалистом, иметь прекрасные hard skills, но минимальный уровень гибких навыков, а потому над ним всегда должен быть сеньор или менеджер, который будет ему помогать.

Любитель поговорить — обладает хорошими гибкими навыками и чуть выше уровня junior hard skills, на чём и выезжает. Активен, участвует во всех встречах, летучках, созвонах, сборах требований. Очень часто такие специалисты становятся менеджерами.

Проджект — человек, обладающий неплохими гибкими навыками, неплохими hard skills, умеет делать проекты «от и до». Очень близок к сеньору.

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

Ну и самое интересное — senior DevOps. Это люди, которые повидали такое на свете, о чём не стоит говорить в приличном обществе. Могут менторить, вести проекты от и до. Я общался с разными сеньорами:

Архитектор — занимается проектированием hardware и app уровнями систем, которые только начинают или планируют внедряться. За счёт опыта и сплита навыков hard и soft может один сделать проект от сотворения вселенной до продакшена.

Активист — этот в каждой бочке затычка. Он говорлив, активен, энергия бьёт ключом. Часто посещает конференции, слушает подкасты, читает разные порталы. Такие очень часто участвуют в пилотах новых продуктов, предлагают продукты для внедрения/пилотов. Входят в различные инициативные группы и комитеты, помогая выстроить процесс. Чаще всего являются лидами.

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

Главное, что можно сказать о переквалификации в DevOps — всё индивидуально.

В принципе, про любое образование и про любую карьеру можно так сказать. Вы можете тратить по восемь часов в день, бороздить просторы интернета и читать статьи по теме, но так ни к чему и не прийти за два года. А можете полгода по вечерам поработать над базой пару часов и стать неплохим джуниором. Безусловно, есть уникальные люди, которые всё схватывают на лету и являются хорошими специалистами-самоучками, но таких — малый процент.

Тут я рекомендую не искать серебряную пулю, а составить личный график саморазвития.

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

С чего начать составлять индивидуальный график

Начинать всегда следует с того, что лучше всего получается. Каждому своё, ведь кто-то силён в разработке, кто-то в аналитике или архитектуре. Начинайте изучать программы и решать проблемы, используя свои сильные стороны, постепенно наращивая и компенсируя слабые. Где-то взаимодействуя с коллегами, где-то проходя курсы или практику из community.

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

Опыт работы и понимания принципов работы Linux.

Понимание работы сетей, хотя бы на уровне сетевых протоколов и уровней TCP/IP.

Понимание принципов работы виртуализации и умение работать с ней.

Понимание работы контейнеров, умение их готовить.

Понимание разницы между монолитной и микросервисой архитектурой. Набор паттернов при построении архитектуры, анти-паттерны.

Понимание культуры и принципов взаимодействия в команде на базе agile, devops. Понимание подходов к организации разработки: kanban, scrum.

Понимание подходов CI\CD как на уровне процесса разработки, так и набора инструментов, которые этот процесс могут сопровождать, дополнять и развивать.

Понимание принципов работы с репозиторием, версионирования кода, подходов к разработке, например, стандартный gitflow.

Понимание безопасности кода, как можно использовать подходы к нему, включить в pipeline.

Подходы к тестированию кода, виды тестирования, тулзы для АТ: mock, системное, нагрузочное, регресс.

Подходы к тестированию инфраструктурного кода и автоматизации этого тестирования.

Базовые принципы и виды мониторинга, алёртинга, какие есть тулзы. Что такое LogTracing, подходы OpenTracing, OpenTelemetry.

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

И два бонуса из не совсем технической части:

Не бояться задавать вопросы и быть готовым всегда развиваться, не бояться перемен.

Системный подход к решению проблем.

В какие языки надо погружаться

Конечно, качество собственного кода на работу девопса влияет напрямую и непосредственно. Начиная от качества кода ПО, с которым работают DevOps инженеры и покрытия этого кода тестами, заканчивая кодом, который они сами пишут и покрытия его тестами, например, инфраструктурного кода или ansible. Поэтому следует самому покрывать код тестами и проверками и стремиться внедрять в pipeline автоматизированные тесты проверки исходного кода приложения. А ещё лучше иметь и то, и другое, и QG на них, чтобы, если код не соответствует правилам, его нельзя было влить в релизную ветку. Чем при этом пользоваться?

Python — модно, молодёжно, используется в машинном обучении и нейросетях, а также всевозможной автоматизации. Работать с подходами MLOps, DataOps крайне интересно, но для них нужен большой багаж знаний.

Java, Kotlin, Spring boot — мир корпоративного ПО, где много интересных технологий, микросервисов и взаимодействия со всеми участниками процесса. Лучше всего подходит для начинающих, чтобы быстро втянуться в основные технологии CI\CD и того, что есть у многих крупных компаний.

Go — ещё более модно и молодёжно, но порой сыровато, и надо скушать много известной субстанции, чтобы приготовить некоторое ПО, написанное на нём, а также выстроить цикл разработки.

C# — чистые шарпы — это тоже модно и корпоративно, но дважды подумайте, прежде чем захотите связываться с windows-стеком разработки всего, что с ним связано. Часто на нём идёт какое-либо легаси или монолит.

C# net core — несколько лучше, чем чистый C#, больше новых технологий, используется далеко не во всех компаниях, кроссплатформенный, но не забывайте, что это windows, который приготовить на linux порой бывает крайне беспощадно. Часто используется либо в смешанных системах из монолита и микросервисов, либо в микросервисах. Если у вас крепкие нервы, то вам сюда.

Ну и замкнём круги ада некоторым легаси: C, C++, plsql, Delphi. В проекты, которые используют что-то из них, вы идёте исключительно на свой страх и риск. Вы окунётесь в тонну легаси, вендерлока и страданий. Только матёрые инженеры идут в этот путь, либо любители free bsd.

Как находить практику для обучения

DevOps, конечно, очень практическая штука. Задачи и инструменты у всех компаний разные. Но теория всё равно нужна, вариться в практике, не зная банальной терминологии и основ linux. — бессмысленно и беспощадно. Есть множество бесплатных практикумов, разборов установки тулсетов и решения проблем на YouTube, статьи на Хабре. Берите различные кейсы развёртывания систем и пробуйте. Берите репы githab и разворачивайте, настраивайте, ломайте, смотрите, что будет, лечите.

Но рано или поздно вам понадобится наставник — коллега, тимлид, который бы придумывал вам задания. Тут без практического навыка в работе либо ментора, который его имеет, дальше вы не пройдёте. Теория теорией, но практика, да ещё и в крупном enterprise — это небо и земля. Поэтому навыки и минимальный набор тулсетов развиваем на свободных, бесплатных, cloud free площадках, а остальное — либо у наставников, либо работая в этой сфере. Чем раньше вы начнёте это делать, тем лучше.

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

Когда включать в план обучения гибкие навыки

Всем всегда рекомендую начать с прикладных навыков и развития hard skills, поэтому начинаем по следующим книгам:

Уорд Брайан. Внутреннее устройство Linux.

Арнольд Роббинс. Bash — карманный справочник для системного администратора.

Лорин Хоштейн. Запускаем Ansible.

Michael Duffy. DevOps Automation Cookbook

Марко Лушка. Kubernetes в действии.

Только после этого отправляйтесь учиться проджекту, гибким навыкам, процессам:

Проект «Феникс». Как DevOps устраняет хаос и ускоряет развитие компании. Ким Дж., Бер К., Спаффорд Дж.

The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. Kim Gene, Debois Patrick, Willis John.

Теория игр. Авинаш Диксит.

Практика непрерывных апдейтов – Continius Delivery. Эбихард Вольф.

Дополнение от редакции:

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

Источник

Кто такой DevOps и когда он не нужен

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

Некоторые указывают в своем резюме DevOps, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «девопсом». Это, конечно, не так.

Несколько последних лет я занимаюсь в основном внедрением DevOps в различных компаниях. До этого более 20 лет работал на позициях от системного администратора до IT-директора. Сейчас — DevOps Lead Engineer в Playgendary.

Кто такой DevOps

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

DevOps — не специалист, которого можно нанять, не набор утилит, и не отдел разработчиков с инженерами.

DevOps — это философия и методология.

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

С появлением DevOps структура и роли специалистов остались такими же (есть девелоперы, есть инженеры), но изменились правила взаимодействия. Размылись границы между отделами.

Цели DevOps можно описать тремя пунктами:

И это только часть инструментов DevOps

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

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

Был яркий пример. На собеседование пришел молодой человек с кучей умных слов в резюме. На последних трех местах работы у него был стаж 5-6 месяцев. Из двух стартапов ушел, потому что «не взлетели». А вот насчет третьей компании сказал, что там его никто не понимает: разработчики пишут код по Windows, а директор заставляет этот код «заворачивать» в обычный Docker и встраивать в CI/CD-пайплайн. Парень много чего негативного рассказал по поводу его текущего места работы и его коллегах — так и хотелось ответить: «Так ты слона не продашь».

Потом я задал ему вопрос, который в моем списке один из первых для каждого кандидата.

— Что лично для тебя означает DevOps?
— Вообще или как я это воспринимаю?

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

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

Методология и философия DevOps

Методология бывает теоретической и практической. В нашем случае — второе. Как я упоминал выше, DevOps — это набор практик и стратегий, применяемых для достижения заявленных целей. И в каждом случае, в зависимости от бизнес-процессов компании, он может существенно отличаться. Что не делает его лучше или хуже.

Методология DevOps — лишь средство достижения поставленных целей.

Теперь о том, что такое философия DevOps. И это, наверное, самый трудный вопрос.

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

В моём ВУЗе такого предмета не было, пришлось изучать все самостоятельно по тем материалам, которые смог найти в 90-е. Тема необязательная для инженерного образования, отсюда и отсутствие формализации ответа. Но те люди, которые серьёзно погрузились в DevOps, начинают ощущать некий «дух» или «неосознанную всеобъемлющность» всех процессов компании.

Я на своем опыте постарался формализовать некоторые «постулаты» этой философии. Получилось следующее:

Что делает DevOps

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

Про западный рынок труда говорить со 100% уверенностью не могу. Но вот о рынке DevOps в России знаю довольно много. Кроме сотен собеседований, за последние полтора года я участвовал в сотне технических пресейлов по услуге «Внедрение DevOps» для крупных российский компаний и банков.

В России DevOps ещё очень молодая, но уже трендовая тема. Насколько я знаю, только по Москве дефицит таких специалистов за 2019 год составил более 1000 человек. А слово Kubernetes для работодателей почти как красная тряпка для быка. Адепты этого инструмента готовы использовать его даже там, где это не нужно и экономически не выгодно. Работодатель не всегда понимает в каких случаях, что уместнее использовать, а при должном развертывании содержание кластера Kubernetes стоит в 2-3 раза дороже, чем развертывание приложения по обычной кластерной схеме. Используйте его там, где он действительно нужен.

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

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

Также DevOps-инженеру нужно время от времени использовать административный ресурс. Например, для преодоления «сопротивления среды» — когда команда не готова принять инструменты и методологию DevOps.

Разработчик должен писать только код и тесты. Для этого ему не нужен супермощный ноутбук, на котором он будет разворачивать и поддерживать локально всю инфраструктуру проекта. Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.

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

Когда DevOps не нужен

Бывают ситуации, когда DevOps не нужен. Это факт — его нужно понять и принять.

В первую очередь, это касается любых компаний (особенно малого бизнеса), когда их прибыль не зависит напрямую от наличия или отсутствия IT-продуктов, предоставляющих информационные сервисы клиентам. И здесь речь не о сайте компании, будь он статической «визиткой» или с динамическими новостными блоками и т.п.

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

Ярким примером является один известный банк. У компании нет привычных клиентских офисов, документооборот осуществляется через почту или курьеров, а множество сотрудников работает из дома. Компания перестала быть просто банком и, на мой взгляд, превратилась в IT-компанию с развитыми DevOps-технологиями.

Много других примеров и лекций можно найти в записях тематических митапов и конференций. Часть из них я посетил лично — это очень полезный опыт для тех, кто хочет развиваться в этом направлении. Вот ссылки на YouTube-каналы с хорошими лекциями и материалами по DevOps:

Если ваша компания торгует рыбой в небольшом магазинчике и единственным IT-продуктом являются две конфигурации 1С: Предприятие (Бухгалтерия и УНФ), то вряд ли есть смысл говорить о DevOps.

Если же вы работаете на крупном торговом и производственном предприятии (например, производите охотничьи ружья), то стоит задуматься. Вы можете проявить инициативу и донести своему руководству перспективы внедрения DevOps. Ну, и заодно, возглавить этот процесс. Проактивная позиция — один из важных постулатов философии DevOps.

Размер и объем годового финансового оборота не является основным критерием для определения, нужен ли вашей компании DevOps.

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

Их клиенты — это ограниченный список автомобильных дилеров. И к каждому прикреплен специалист от производителя. Весь внутренний документооборот происходит через ERP SAP. Внутренние сотрудники, по сути, являются клиентами информационной системы. Но управление этой ИС осуществляется классическими средствами управления кластерными системами. Что исключает возможность использования практик DevOps.

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

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

Основной критерий для понимания нужен ли DevOps: какое значение ваши IT-продукты имеют для компании и клиентов.

Если основной продукт компании, приносящий прибыль, это ПО — вам нужен DevOps. И не так важно, если зарабатываете реальные деньги вы с помощью других товаров. Сюда также можно отнести интернет-магазины или мобильные приложения с играми.

Любые игры существуют благодаря финансированию: прямому или косвенному со стороны игроков. В Playgendary мы разрабатываем бесплатные мобильные игры, в непосредственном создании которых участвуют более 200 человек. Как мы используем DevOps?

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

Сейчас у нас активно используется Jenkins как инструмент CI/CD pipelines для выполнения всех сборочных конвейеров с Unity и последующего деплоя в App Store и Play Market. Еще из классического набора инструментов:

Вместо заключения

Хочу закончить следующей мыслью: чтобы стать DevOps-инженером высокой квалификации, жизненно необходимо научиться живому общению с людьми.

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

И да, внедрение любого решения потребует множества обсуждений, а к концу может вообще измениться. Самостоятельно развиваясь, предлагая и осуществляя свои задумки — такой человек представляет все большую ценность как для команды, так и для работодателя. Что, в конечном счёте, отражается и на размере его ежемесячного вознаграждения или в виде дополнительных премий.

Источник