Привет! Это команда «Автомакон». Мы ИТ-интегратор, в том числе занимаемся разработкой мобильных и web-приложений. Делаем много интересного и нужного для людей, например, строим экосистему «ВкусВилл». Но сейчас — не совсем про заказную разработку.

Коротко о статье

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

Пока не претендуем на звание «Лучший APM 2023 года», даем честное слово, что скоро его докрутим. Объективно, APM Wizard не такой крутой, как DataDog или NewRelic, но – самое главное – он доступен в России.

Если уже знаете о том, что такое APM – жмяк. Если пока нет, ниже в статье можно восполнить пробел в знаниях.

Погружение в контекст

Чтобы не прыгать с места в карьер, введем в контекст и расскажем историю. Кого-то она удивит, а других чему-то научит.

Однажды, когда наступила зима 2020 года и мы даже не догадывались, какое интересное время ждет нас впереди, начали только появляться первые признаки пандемии (помните, была такая), мобильное приложение «ВкусВилл» еще не стало лидером доставки в России, а было простым приложением с базовым набором функций: посмотреть адреса магазинов, составить список покупок, воспользоваться системой лояльности, просканировать QR-код в магазинах.

А теперь представьте, что в какой-то момент все стало невероятно падать. Коллеги точно поймут эти «веселые» ощущения [как в известном меме «This is fine»]. Помню неделю, на которой мы буквально лежали по несколько часов каждый день. В то время наша команда была еще крохой, у нас даже не было DevOps’а (честно, мы не жалуемся, просто было вот так) и мы с разработчиками проводили много времени, выгружая логи в поиске проблем производительности методов и настраивая алармы на эти проблемы.

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

Тогда мы решили, что нам нужно усилиться и получить помощь со стороны, поэтому позвали внешних консультантов – Самата Галимова и Федора Борщева (ссылки на коллег в конце статьи). Ребята подсказали огромное количество идей для Highload, но ключевое – посмотрели на наши мониторинги, покачали головой, вздохнули и предложили выбросить это все далеко и желательно навсегда и немедленно подключить APM.

(Не?)занудный текст о том, что такое APM

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

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

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

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

Зачем разработчикам использовать APM? Выделили три ключевых преимущества:

• APM позволяет оперативно выявлять и устранять проблемы производительности, что способствует улучшению пользовательского опыта и повышению удовлетворенности пользователей;

• APM помогает разработчикам оптимизировать код и ресурсы, сокращая время отклика приложения и повышая его эффективность;

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

Так было раньше: как мы работали с DataDog

DataDog мы подключили и настроили буквально за несколько недель: добавили продуктовые серверы, смотрели ошибки, которые приходили от агентов PHP и агентов инфраструктуры. Вместе с ошибками приходили трейсы, которые просматривали разработчики. Любое отклонение от показателя выполнения выше 300 мс. исправляли в тот же день.

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

Мы настроили систему работу с алармами. Для работы с ключевыми [о недоступности сервисов] подключили внешние агенты DataDog через life-checkpoint.

Кроме этого, настроили алармы на все ошибки 500+ – их получали от агентов, установленных в приложении. Отдельно выделили все инфраструктурные алармы по нагрузке SQL-серверов: превышение порогов использования процессора, памяти и других метрик.

DataDog понравился наличием очень крутых агентов, но мы столкнулись с проблемой получения только тех трейсов, которые в эти агенты были «вшиты». Например, мы не могли получить проприетарные метрики по базам данных, по Redis etc.

Одна из проблем, с которой пришлось столкнуться, заключалась в получении трейсов ошибок бэкенда. Мы получали стандартные, без возможности углубиться в теме. Например, на основе эндпоинта API не могли получить название конкретной хранимой процедуры T-SQL, которая в этом эндпоинте задействована. А в случае получения кода ответа меньше 500 не было обозначения в качестве проблемы.

Как же мы сделали для «ВкусВилл» лучшее* APM в России

Нескромно, согласен. Точнее будет так: *лучшее в России, с учетом тех конкурентов, которых мы нашли но, продукт которых не попробовали, потому что он выглядел хуже нашего.

Long story short, начало типичное: было все хорошо, а потом стало плохо, и это плохо нужно было как-то исправить.

Вот так было и у нас: в какой-то момент пропала возможность оплачивать DataDog. А, как вы понимаете, DataDog задавал тон работе, как ковер в художественном фильме «Большой Лебовски».

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

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

Мы не волшебники, а только учимся

APM Wizard уже почти, но все еще не DataDog. Резюмирую то, что у нас получилось сделать:

• Система работает с приложениями, написанными на PHP, Go, Java, Java Script (Node.js), Python, Ruby.

• OpenTelemetry для генерации span’ы из различных окружений. На балансировщике мы получаем запросы id трейса, по которому мы можем собирать все последующие SPAN из приложений, следующие дальше по цепочке. В итоге, в базу мы собираем все документы по id трейса, на котором строится Trace View.

• Коллекторы собирают span’ы, делают сортировку, готовят bulk-запросы и передают данные в ElasticSearch. Затем мы забираем данные в Grafana и Jager UI или работаем с сырыми данными через Elastic API.

• Через Grafana UI отрисовываем span’ы в зависимости от сервиса, который их генерирует. Например, в панели с ошибками показываем ошибки по признаку: типу ошибки, сервису, etc.

Сейчас в процессе довольно много вещей:

• Cделать хорошую систему алармов (со сложной системой эскалации, смс и роботизированными звонками по ночам). Используем Grafana on call. Почти вывели в прод.

• Доработать систему мониторинга трейсов. Сейчас под нагрузкой работает не так хорошо, как мы хотим.

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

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

Как можно принять участие в «магии»

Сейчас мы в активном поиске бизнеса или студии разработки, которые используют любой из поддерживаемых нами стеков, для проведения бета-тестирования. Если вы руководите такой компанией и готовы нам посодействовать в доработке российского АРМ – напишите на почту apm@automacon.ru или пройдите регистрацию на сайте.

Эволюционная цель

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

А в данной статье мы поделимся эволюционной целью, которую сформулировали для нашего продукта – APM Wizard.

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

Верим, что в IT-сообществе важную роль играет взаимопомощь. Мы стремимся создать вдохновляющую среду, в которой каждый разработчик может свободно экспериментировать и создавать приложения, веб-сервисы без ограничений. Мы готовы поддержать условных «инди» разработчиков, обеспечивая бесплатный доступ к APM Wizard. Для низконагруженных приложений с небольшим количеством хостов мониторинг останется абсолютно бесплатным как сегодня, так и в будущем. Наша миссия заключается в том, чтобы предоставить коллегам-разработчикам возможность полностью реализовать свои творческие идеи и воплотить их в функциональные приложения, не сталкиваясь с финансовыми преградами.

Открытый бета-тест

Раз вы дочитали до этого момента, уверены на 99,99%, что тема вам интересна. Если хотите попробовать созданный нашей командой APM Wizard, пройдите регистрацию на сайте.

Полезные ссылки

Записаться на бета-тестирование.

Как и обещали в начале статьи, делимся контактами Феди и Самата

Всем привет! Меня зовут Владимир Исабеков, в Swordfish Security я занимаюсь динамическим анализом приложений (DAST, Dynamic Application Security Testing). В этой статье мы поговорим о ключевых недостатках DAST-тестирования и рассмотрим один из способов их устранения.

Содержание:

• Недостатки DAST

• Применение инструментации на практике

• Плюсы и минусы инструментации

Недостатки DAST

DAST — это один из подходов к обеспечению безопасности веб-приложений и ПО. В основном практика используется для обнаружения уязвимостей в работающем приложении. При этом методика включает в себя взаимодействие с продуктом с помощью различных тактик и техник. Несмотря на ощутимую пользу, которую приносит DAST-анализ, у этой практики есть и недостатки, способные влиять на эффективность и точность тестирования безопасности:

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

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

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

Применение инструментации на практике

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

Теперь давайте рассмотрим вышесказанное на примере. Допустим, у нас есть Java-приложение с заранее известной уязвимостью типа XXE. Протестируем его методом DAST с помощью инструмента BurpSuite Pro и посмотрим, какие ветки кода он проанализирует. Для сбора трассы воспользуемся Open Source библиотекой JavaCodeCoverage (JaCoCo), созданной для измерения покрытия кода Java-приложений тестами. Она позволяет определить, какой процент кода был выполнен во время запуска тестов и какие строки остались неиспользованными.

JaCoCo поддерживает различные форматы отчетов, включая HTML, XML и CSV, которые могут быть использованы для оценки качества тестирования и выявления уязвимых мест в коде приложения. Отчеты JaCoCo также можно связать с популярными средствами непрерывной интеграции, такими как Jenkins, Travis CI и другими. JaCoCo позволяет инструментировать приложение различными способами. Мы воспользуемся возможностью инструментации байт-кода на лету с помощью Java-агента. Этот механизм позволяет выполнять предварительную обработку в памяти всех файлов загружаемых классов, независимо от структуры приложения.

Запустим наше приложение с агентом JaCoCo:

java -javaagent:jacocoagent.jar=port=8092,output=tcpserver -jar lab-xxe.jar

Агент JaCoCo собирает информацию о выполнении и выдает ее по запросу или при выходе из JVM. Существует три различных режима вывода данных выполнения, которые указываются в параметре output:

*file: При завершении работы данные об исполнении записываются в файл, указанный в destfile параметре;

*tcpserver: Java-агент прослушивает входящие соединения на TCP-порте, указанном в параметрах address и port. Результаты работы агента записываются в это TCP-соединение.

*tcpclient: при запуске агент подключается к TCP-порту, указанному в параметрах address и port . Результаты работы агента отправляются в это TCP-соединение.

Теперь проведем DAST-тестирование уязвимого приложения с помощью инструмента BurpSuite Pro. Результаты анализа:

Как мы видим, BurpSuite Pro не смог выявить уязвимость.

Проверим, какие строки кода он смог задействовать в ходе тестирования. Для этого воспользуемся интерфейсом командной строки JaCoCo.

java -jar jacococli.jar dump --port 8092 --destfile dump.exec

Командой dump мы запросили данные выполнения от агента JaCoCo, работающего в режиме вывода tcpserver.

Вывод на консоль

[INFO] Connecting to localhost/127.0.0.1:8092. [INFO] Writing execution data to /home/user/lab-xxe/target/dump.exec.

Для получения отчета еще раз воспользуемся интерфейсом командной строки JaCoCo.

java -jar jacococli.jar report dump.exec --classfiles /home/user/lab-xxe/target/classes --sourcefiles /home/user/lab-xxe/src/main/java --html /home/user/lab-xxe/target/tmp

Вывод на консоль

[INFO] Loading execution data file /home/user/lab-xxe/target/dump.exec. [INFO] Analyzing 3 classes.

В документации JaCoCo более подробной расписаны параметры команд, советую ее почитать.
Теперь мы можем проверить директорию tmp в каталоге сборки проекта.

В ней находится отчет об анализе покрытия кода.

Открываем ‘index.html’ в браузере. Наблюдаем результат покрытия кода тестированием BurpSuite:

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

Плюсы и минусы инструментации

Как мы увидели, инструментация приложения способна помочь в выявлении участков поверхности атаки, не охваченных в ходе DAST-тестирования. Также этот процесс в случае эксплуатации уязвимости наглядно показывает слабое место в исходных текстах. Очевидно, что 100%-ное покрытие исходных текстов DAST-тестированием не гарантирует отсутствия уязвимостей, но как метрика качества может быть вполне полезна.

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

Мы на Хабр Карьере регулярно анализируем зарплаты IT-специалистов: по полугодиям, в разрезе специализаций, квалификаций, городов, компаний, языков программирования и т.д. В этом году мы решили попробовать собрать новый срез и посмотреть на зарплатный рынок со стороны работодателя.

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

---

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

Где мы берем эти цифры

Все расчеты построены исключительно на зарплатах специалистов, которые они оставили в нашем зарплатном калькуляторе до 15 июня 2023, а также на данных из вакансий, которые были размещены на Хабр Карьере весной 2023. Чтобы данные в калькуляторе были точнее, мы специально отсекаем 1% самых высоких и 1% самых низких зарплат.

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

Про вакансии для IT-специалистов

В период с 1 марта по 31 мая 2023 на Хабр Карьере можно было откликнуться на 6 870 вакансий, из них 65,6% — с возможностью удаленной работы. Вакансий, в которых работодатель указал зарплатную вилку, было 24,5%.

Кого ищут чаще

Квалификация

Чаще всего на Хабр Карьере ищут мидлов — этой весной доля вакансий для них составляла 53,3%. 

На втором месте сеньоры — 32,5% вакансий, на третьем — лиды 9,2% вакансий. Для джунов доля вакансий составляла 3,8%. Стажеров нанимают еще реже — 1,2% вакансий.

Это данные по вакансиям, в которых работодатели указали квалификацию специалиста, которого они ищут. Без квалификации было 14% вакансий.

Специализация

Взяли все вакансии, которые компании публиковали весной 2023 и выбрали самые популярные специализации. Топ-3:

• «Разработка» — 47,2% вакансий,

• «Аналитика» — 16,5%,  

• «Тестирование» — 10,4%.

Доли вакансий по остальным специализациям смотрите в графике ниже.

Среди разработчиков самыми популярными оказались бэкендеры — для них разместили 21,6% вакансий, на втором месте фронтендеры — 6,1% вакансий. Третье место досталось разработчикам мобильных приложений — 3,9% вакансий, а на четвертом — фулстеки, доля вакансий для них — 3,6% в специализации «Разработка».

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

Наём бэкендеров

Квалификации

Самые популярные среди бэкендеров — мидлы, 48% вакансий в бэкенде были для них. Немного реже искали сеньоров — доля 39%. Для лидов и джунов в бэкенде было 11% и 2% вакансий соответственно.

Языки и фреймворки

Самые популярные языки в бэкенде у работодателей: 

• Java, 

• Python,

• PHP, 

• Golang, 

• C#, 

• C++, 

• JavaScript, 

• Kotlin.

Самые популярные фреймворки:

• Java Spring Framework, 

• Spring Boot, 

• Django,

• Laravel, 

• Symfony, 

• Node.js, 

• Yii framework,

• Ruby on Rails.

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

Вилка в вакансиях vs Зарплатный калькулятор

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

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

Java

Общие данные по бэкендерам
Вилка в вакансиях: от 186 000 ₽.
Зарплата по калькулятору: 212 000 ₽.

Мидлы
Вилка в вакансиях: от 126 000 ₽ до 136 000 ₽. 
Зарплата по калькулятору: 192 000 ₽.

Сеньоры
Вилка в вакансиях: от 229 000 ₽. 
Зарплата по калькулятору: 297 000 ₽.

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

Python

Общие данные по бэкендерам
Вилка в вакансиях: от 170 000 ₽ до 205 000 ₽.
Зарплата по калькулятору: 184 000 ₽.

Джуны
Вилка в вакансиях: от 35 000 ₽ до 68 000 ₽.
Зарплата по калькулятору: 74 000 ₽.

Мидлы
Вилка в вакансиях: от 143 000 ₽ до 160 000 ₽.
Зарплата по калькулятору: 180 000 ₽.

Сеньоры 
Вилка в вакансиях: от 221 000 ₽ до 332 000 ₽.
Зарплата по калькулятору: 275 000 ₽.

Лиды
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 350 000 ₽.

PHP

Общие данные по бэкендерам
Вилка в вакансиях: от 133 000 ₽ до 152 000 ₽.
Зарплата по калькулятору: 202 000 ₽.

Джуны
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 63 000 ₽.

Мидлы
Вилка в вакансиях: от 106 000 ₽ до 135 000 ₽.
Зарплата по калькулятору: 161 000 ₽.

Сеньоры
Вилка в вакансиях: от 213 000 ₽.
Зарплата по калькулятору: 250 000 ₽.

Лиды
Вилка в вакансиях: от 220 000 ₽.
Зарплата по калькулятору: 287 000 ₽.

Java Spring Framework

Общие данные по бэкендерам
Вилка в вакансиях: от 158 000 ₽.
Зарплата по калькулятору: 218 000 ₽.

Мидлы
Вилка в вакансиях: от 115 000 ₽ до 118 000 ₽.
Зарплата по калькулятору: 189 000 ₽.

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

Джуны в среднем получают 99 000 ₽, сеньоры — 296 000 ₽, а лиды — 336 000 ₽.

Golang

Общие данные по бэкендерам
Вилка в вакансиях: от 204 000 ₽ до 223 000 ₽.
Зарплата по калькулятору: 255 000 ₽.

Мидлы 
Вилка в вакансиях: от 140 000 ₽ до 164 000 ₽.
Зарплата по калькулятору: 228 000 ₽.

Сеньоры
Вилка в вакансиях: от 267 000 ₽.
Зарплата по калькулятору: 298 000 ₽.

Для джунов и лидов вакансий было немного, но по данным, которые специалисты оставили в нашем калькуляторе, джуны в среднем получают 125 000 ₽, а лиды — 424 000 ₽.

C#

Общие данные по бэкендерам
Вилка в вакансиях: от 163 000 ₽ до 177 000 ₽.
Зарплата по калькулятору: 213 000 ₽.

Мидлы
Вилка в вакансиях: от 143 000 ₽.
Зарплата по калькулятору: 174 000 ₽.

Сеньоры
Вилка в вакансиях: от 214 000 ₽ до 266 000 ₽.
Зарплата по калькулятору: 267 000 ₽.

Вакансий для бэкендеров в других квалификациях было недостаточно, чтобы собрать аналитику, но мы поделимся данными из нашего зарплатного калькулятора: джуны в среднем получают 90 000 ₽, а лиды — 315 000 ₽.

C++

Общие данные по бэкендерам
Вилка в вакансиях: от 223 000 ₽.
Зарплата по калькулятору: 201 000 ₽.

Мидлы
Вилка в вакансиях: от 130 000 ₽.
Зарплата по калькулятору: 181 000 ₽.

Сеньоры
Вилка в вакансиях: от 400 000 ₽.
Зарплата по калькулятору: 284 000 ₽.

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

По данным калькулятора, зарплата джунов в С++ в среднем 86 000 ₽, а лидов — 307 000 ₽.

Spring Boot

Общие данные по бэкендерам
Вилка в вакансиях: от 196 000 ₽ до 274 000 ₽.
Зарплата по калькулятору: 205 000 ₽.

Сеньоры 
Вилка в вакансиях: от 224 000 ₽ до 312 000 ₽.
Зарплата по калькулятору: 295 000 ₽.

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

Джуны-бэкендеры с владением фреймворком Spring Boot, которые поделились с нами зарплатой, получают в среднем 102 000 ₽, мидлы — 193 000 ₽, а лиды — 312 000 ₽.

Django

Общие данные по бэкендерам
Вилка в вакансиях: от 159 000 ₽ до 205 000 ₽.
Зарплата по калькулятору: 156 000 ₽.

Джуны
Вилка в вакансиях: от 44 000 ₽ до 67 000 ₽.
Зарплата по калькулятору: 61 000 ₽.

Мидлы
Вилка в вакансиях: от 149 000 ₽ до 184 000 ₽.
Зарплата по калькулятору: 159 000 ₽.

Сеньоры 
Вилка в вакансиях: от 182 000 ₽ до 334 000 ₽.
Зарплата по калькулятору: 267 000 ₽.

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

JavaScript

Общие данные по бэкендерам
Вилка в вакансиях: от 137 000 ₽ до 156 000 ₽.
Зарплата по калькулятору: 176 000 ₽.

Мидлы
Вилка в вакансиях: от 113 000 ₽ до 129 000 ₽.
Зарплата по калькулятору: 168 000 ₽.

Сеньоры
Вилка в вакансиях: от 217 000 ₽ до 242 000 ₽.
Зарплата по калькулятору: 199 000 ₽.

Для джунов и лидов с этим навыком вакансий было недостаточно, чтобы сделать выводы. 

По данным, которые специалисты оставили в нашем калькуляторе, джуны в среднем получают 70 000 ₽. Если вы лид со знанием JavaScript, поделитесь данными о своей зарплате, пожалуйста!

Laravel

Общие данные по бэкендерам
Вилка в вакансиях: от 130 000 ₽ до 150 000 ₽.
Зарплата по калькулятору: 179 000 ₽.

Мидлы
Вилка в вакансиях: от 113 000 ₽ до 140 000 ₽.
Зарплата по калькулятору: 149 000 ₽.

Сеньоры
Вилка в вакансиях: от 172 000 ₽ до 204 000 ₽.
Зарплата по калькулятору: 233 000 ₽.

Для джунов и лидов вакансий было немного, поэтому нам не удалось собрать данные о зарплатных вилках. А если говорить о зарплатах, то по данным, которые специалисты оставили в нашем калькуляторе, джуны с навыком Laravel в среднем получают 48 000 ₽, а лиды — 275 000 ₽.

Symfony

Общие данные по бэкендерам
Вилка в вакансиях: от 171 000 ₽ до 187 000 ₽.
Зарплата по калькулятору: 222 000 ₽.

Мидлы
Вилка в вакансиях: от 125 000 ₽ до 156 000 ₽.
Зарплата по калькулятору: 177 000 ₽.

Сеньоры
Вилка в вакансиях: от 249 000 ₽.
Зарплата по калькулятору: 264 000 ₽.

К сожалению, в вакансиях для лидов работодатели редко указывали зарплатную вилку, а по данным калькулятора бэкендеры со знанием Symfony получают в среднем 301 000 ₽.

По джунам данных не набралось. Если вы джун и владеете Symfony — будем рады, если вы поделитесь с нами своей зарплатой!

Node.js

Общие данные по бэкендерам
Вилка в вакансиях: от 160 000 ₽ до 192 000 ₽.
Зарплата по калькулятору: 187 000 ₽.

Мидлы
Вилка в вакансиях: от 131 000 ₽ до 144 000 ₽.
Зарплата по калькулятору: 151 000 ₽.

Сеньоры
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 270 000 ₽.

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

Yii framework

Общие данные по бэкендерам
Вилка в вакансиях: от 138 000 ₽.
Зарплата по калькулятору: 204 000 ₽.

Мидлы
Вилка в вакансиях: от 122 000 ₽.
Зарплата по калькулятору: 150 000 ₽.

Джунов, сеньоров и лидов искали реже, поэтому у нас недостаточно данных для анализа. С данными из зарплатного калькулятора ситуация аналогичная: если вы бэкендер со знанием Yii, расскажите нам, сколько вы зарабатываете.

Kotlin

Общие данные по бэкендерам
Вилка в вакансиях: от 167 000 ₽.
Зарплата по калькулятору: от 268 000 ₽.

Мидлы
Вилка в вакансиях: от 136 000 ₽.
Зарплата по калькулятору: 212 000 ₽.

Сеньоры
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 311 000 ₽.

Лиды
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 358 000 ₽.

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

Ruby on Rails

Общие данные по бэкендерам
Вилка в вакансиях: от 211 000 ₽ до 369 000 ₽.
Зарплата по калькулятору: 223 000 ₽.

Джуны
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 101 000 ₽.

Мидлы
Вилка в вакансиях: от 173 000 ₽ до 252 000 ₽.
Зарплата по калькулятору: 169 000 ₽.

Сеньоры
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 350 000 ₽.

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

Наём фронтендеров

Квалификации

Чаще всего среди фронтендеров искали мидлов — доля 52,9%. 

На втором месте по популярности сеньоры — для них было 38,8% вакансий. Джунов и лидов искали ощутимо реже — доли по 1,7% и 6,6% соответственно. 

Языки и фреймворки

Самый популярный язык во фронтенде — JavaScript.

Самые популярные фреймворки, которые работодатели хотят видеть среди навыков: 

• React,

• Vue.js,

• Angular,

• Node.js.

Вилка в вакансиях vs Зарплатный калькулятор

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

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

JavaScript

Общие данные по фронтендерам 
Вилка в вакансиях: от 153 000 ₽.
Зарплата по калькулятору: 190 000 ₽.

Мидлы
Вилка в вакансиях: от 122 000 ₽ до 164 000 ₽.
Зарплата по калькулятору: 169 000 ₽.

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

Если говорить о средних зарплатах, то по данным, которые специалисты оставили в нашем калькуляторе, джуны в среднем получают 72 000 ₽, сеньоры — 278 000 ₽, а лиды — 308 000 ₽.

React

Общие данные по фронтендерам 
Вилка в вакансиях: от 170 000 ₽ до 183 000 ₽.
Зарплата по калькулятору: 202 000 ₽.

Джуны
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 77 000 ₽.

Мидлы
Вилка в вакансиях: от 126 000 ₽ до 178 000 ₽.
Зарплата по калькулятору: 176 000 ₽.

Сеньоры
Вилка в вакансиях: от 221 000 ₽.
Зарплата по калькулятору: 295 000 ₽.

Лиды
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 318 000 ₽.

Vue.js

Общие данные по фронтендерам 
Вилка в вакансиях: от 170 000 ₽.
Зарплата по калькулятору: 167 000 ₽.

Мидлы
Вилка в вакансиях: от 132 000 ₽ до 146 000 ₽.
Зарплата по калькулятору: 142 000 ₽.

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

Если говорить о средних зарплатах, то по данным, которые специалисты оставили в нашем калькуляторе, джуны в среднем получают 73 000 ₽, сеньоры — 254 000 ₽, а лиды — 309 000 ₽.

Angular

Общие данные по фронтендерам 
Вилка в вакансиях: от 151 000 ₽.
Зарплата по калькулятору: 208 000 ₽.

Мидлы
Вилка в вакансиях: от 144 000 ₽.
Зарплата по калькулятору: 171 000 ₽.

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

Если говорить о средних зарплатах, то по данным, которые специалисты оставили в нашем калькуляторе, джуны в среднем получают 75 000 ₽, сеньоры — 292 000 ₽, а лиды — 312 000 ₽.

Node.js

Общие данные по фронтендерам 
Вилка в вакансиях: от 183 000 ₽.
Зарплата по калькулятору: 230 000 ₽.

Мидлы
Вилка в вакансиях: от 92 000 ₽ до 145 000 ₽.
Зарплата по калькулятору: 186 000 ₽.

Сеньоры
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 274 000 ₽.

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

Если вы лид или джун со знанием Node.js, расскажите нам, сколько вы зарабатываете.

Наём разработчиков мобильных приложений

Квалификации

Самые популярные разработчики мобильных приложений — мидлы и сеньоры, доли вакансий для них одинаковые — по 45,2%. Реже ищут лидов — доля 7,1%. Для джунов вакансий меньше всего: 2,5%. 

Языки и фреймворки

Самые популярные языки в мобайле:

• Kotlin,

• Swift,

• Java.

К сожалению, по фреймворкам собрать достаточно данных не удалось. 

Вилка в вакансиях vs Зарплатный калькулятор

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

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

Kotlin

Общие данные по мобильным разработчикам 
Вилка в вакансиях: от 140 000 ₽ до 203 000 ₽.
Зарплата по калькулятору: 228 000 ₽.

Мидлы
Вилка в вакансиях: от 131 000 ₽ до 190 000 ₽.
Зарплата по калькулятору: 197 000 ₽.

Сеньоры
Вилка в вакансиях: от 137 000 ₽ до 243 000 ₽.
Зарплата по калькулятору: 300 000 ₽.

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

Если говорить о средних зарплатах, то по данным, которые специалисты оставили в нашем калькуляторе, джуны в среднем получают 93 000 ₽, а лиды — 338 000 ₽.

Swift

Общие данные по мобильным разработчикам 
Вилка в вакансиях: от 166 000 ₽.
Зарплата по калькулятору: 263 000 ₽.

Мидлы
Вилка в вакансиях: от 129 000 ₽.
Зарплата по калькулятору: 212 000 ₽.

Сеньоры
Вилка в вакансиях: от 225 000 ₽.
Зарплата по калькулятору: 347 000 ₽.

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

Если говорить о средних зарплатах, то по данным, которые специалисты оставили в нашем калькуляторе, джуны в среднем получают 110 000 ₽, а лиды — 430 000 ₽.

Java

Общие данные по мобильным разработчикам 
Вилка в вакансиях: от 110 000 ₽ до 177 000 ₽.

Увы, работодатели здесь почти не указывали зарплатную вилку в вакансиях, поэтому мы поделимся данными по зарплатам специалистов из нашего калькулятора:

Мидлы со знанием Java в мобильной разработке получают в среднем 238 000 ₽, а сеньоры — 295 000 ₽.

Если вы джун или лид в мобильной разработке и работаете в Java, расскажите нам, сколько вы зарабатываете.

Наём фулстек разработчиков

Квалификации

Самые популярные фулстеки — мидлы, для них было больше половины вакансий (58,9%). На втором месте сеньоры — доля вакансий 29,6%. Сильно реже искали лидов и джунов — доли 7,7% и 3,6% соответственно. 

Языки и фреймворки

Самые популярные языки для фулстеков:

• JavaScript,

• PHP,

• Python,

• C#.

Самые популярные фреймворки, которые работодатели хотят видеть среди навыков: 

• React,

• Vue.js,

• Node.js,

• Laravel.

Вилка в вакансиях vs Зарплатный калькулятор

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

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

JavaScript

Общие данные по фулстекам 
Вилка в вакансиях: от 143 000 ₽ до 183 000 ₽.
Зарплата по калькулятору: 209 000 ₽.

Мидлы
Вилка в вакансиях: от 109 000 ₽ до 128 000 ₽.
Зарплата по калькулятору: 170 000 ₽.

Сеньоры
Вилка в вакансиях: от 218 000 ₽.
Зарплата по калькулятору: 273 000 ₽.

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

А если говорить о средних зарплатах, то по данным, которые специалисты оставили в нашем калькуляторе, джуны в среднем получают 114 000 ₽, а лиды — 264 000 ₽.

PHP

Общие данные по фулстекам 
Вилка в вакансиях: от 122 000 ₽ до 134 000 ₽.
Зарплата по калькулятору: 176 000 ₽.

Мидлы
Вилка в вакансиях: от 107 000 ₽ до 136 000 ₽.
Зарплата по калькулятору: 139 000 ₽.

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

Если говорить о средних зарплатах, то по данным, которые специалисты оставили в нашем калькуляторе, сеньоры в среднем получают 230 000 ₽, а лиды — 231 000 ₽.

Если вы джуниор фулстек-разработчик в PHP — расскажите, сколько вы зарабатываете!

Python

Общие данные по бэкендерам
Вилка в вакансиях: от 175 000 ₽ до 277 000 ₽.
Зарплата по калькулятору: 203 000 ₽.

Джуны
Вилка в вакансиях: от 60 000 ₽ до 80 000 ₽.
Зарплата по калькулятору: 87 000 ₽.

Мидлы
Вилка в вакансиях: от 80 000 ₽ до 152 000 ₽.
Зарплата по калькулятору: 213 000 ₽.

Сеньоры 
Вилка в вакансиях: от 243 000 ₽ до 385 000 ₽.

Лиды
Вилка в вакансиях: от 350 000 ₽ до 450 000 ₽.

Если вы сеньор или лид фулстек-разработчик в Python — расскажите нам, сколько вы зарабатываете!

React

Общие данные по фулстекам 
Вилка в вакансиях: от 173 000 ₽ до 205 000 ₽.
Зарплата по калькулятору: 249 000 ₽.

Мидлы
Вилка в вакансиях: от 133 000 ₽ до 175 000 ₽.
Зарплата по калькулятору: 217 000 ₽.

Сеньоры
Вилка в вакансиях: от 252 000 ₽.
Зарплата по калькулятору: 301 000 ₽.

Лиды
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 337 000 ₽.

Если вы джуниор фулстек-разработчик в React — расскажите нам, сколько вы зарабатываете!

Vue.js

Общие данные по фулстекам 
Вилка в вакансиях: от 118 000 ₽ до 145 000 ₽.
Зарплата по калькулятору: 184 000 ₽.

Мидлы
Вилка в вакансиях: от 100 000 ₽ до 120 000 ₽.
Зарплата по калькулятору: 146 000 ₽.

Сеньоры
Вилка в вакансиях: — (мало данных).
Зарплата по калькулятору: 257 000 ₽.

Увы, чтобы понять среднее предложение рынка для специалистов других квалификаций, у нас не набралось данных из вакансий. Аналогичная ситуация с данными из калькулятора. Если вы лид или джун фулстек в Vue.js — расскажите нам, сколько вы зарабатываете!

Node.js

Общие данные по фулстекам 
Вилка в вакансиях: от 172 000 ₽ до 230 000 ₽.
Зарплата по калькулятору: 258 000 ₽.

Мидлы
Вилка в вакансиях: от 113 000 ₽ до 147 000 ₽.
Зарплата по калькулятору: 263 000 ₽.

Сеньоры
Вилка в вакансиях: от 254 000 ₽.
Зарплата по калькулятору: 324 000 ₽.

Для лидов и джунов вакансий было мало, поэтому нам не удалось собрать достаточно данных. Та же ситуация с зарплатным калькулятором. Если вы лид или джун фулстек в Node.js — расскажите нам, сколько вы зарабатываете!

C#

Общие данные по фулстекам 
Вилка в вакансиях: от 153 000 ₽ до 167 000 ₽.
Зарплата по калькулятору: 174 000 ₽.

Мидлы
Вилка в вакансиях: от 150 000 ₽.
Зарплата по калькулятору: 149 000 ₽.

По остальным квалификациям вакансий для фулстеков на C# с указанной зарплатой было мало, поэтому расскажем, сколько получают те, кто поделился с нами зарплатой в калькуляторе. Джуны в среднем получают 74 000 ₽, сеньоры — 237 000 ₽, а лиды — 260 000 ₽.

Laravel

Общие данные по фулстекам 
Вилка в вакансиях: от 99 000 ₽ до 143 000 ₽.
Зарплата по калькулятору: 161 000 ₽.

Мидлы
Вилка в вакансиях: от 96 000 ₽ до 138 000 ₽.
Зарплата по калькулятору: 124 000 ₽.

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

Коротко о главном

Собрали самое интересное со всего исследования для тех, кто не любит копаться в данных. 

Бэкенд

• Джуны меньше всего зарабатывают на Laravel — 48 000 ₽, а больше всего на Go — 125 000 ₽.

• Мидлы в бэкенде получают от 149 000 в среднем, если знают Laravel, а если владеют Go, то могут получать 228 000 ₽.

• Для сеньоров самые высокие зарплаты в RoR — 350 000 ₽, а самые низкие в JavaScript — 199 000 ₽.

• Лиды больше всего получают в Golang — 424 000 ₽, а меньше с Laravel — 275 000 ₽.

Фронтенд

• Джуны-фронтендеры независимо от знания языков и фреймворков получают примерно одинаково: от 72 000 ₽ до 77 000 ₽ в среднем.

• Зарплаты мидлов во фронтенде начинаются в среднем от 142 000 ₽ на Vue.js и заканчиваются на 186 000 ₽, Node.js.

• Сеньоры фронтендеры зарабатывают от 254 000 ₽ на Vue.js до 295 000 ₽ на React.

• Зарплаты лидов в выборке варьируются в среднем от 308 000 ₽ в JavaScript до 318 000 ₽ в React.

Мобильная разработка

• Мидлы в разработке мобильных приложений больше всего получают в Java — 238 000 ₽.

• Зарплаты сеньоров в выборке начинаются от 295 000 ₽ в Java и заканчиваются на 347 000 ₽ в Swift.

• Лиды в мобайле больше всего зарабатывают в Swift — 430 000 ₽.

Фулстек

• Мидлам-фулстекам меньше всего платят с Laravel — 124 000 ₽, а со знанием Node.js они получают 263 000 ₽ в среднем.

• Для сеньоров самые высокие зарплаты у фулстеков со знанием Node.js — 324 000, низкие — в PHP — 230 000 ₽.

• Лиды-фулстеки меньше всего получают в PHP — 231 000 ₽, а больше всего на React — 337 000 ₽.

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

---

Откуда эти данные

Выборка для этого исследования — 6 870 вакансий, на которые можно было откликнуться с 1 марта по 31 мая 2023. А для данных по зарплатам мы проанализировали 8 014 зарплат из калькулятора Хабр Карьеры. 

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

Все зарплаты в исследовании — средние. При расчетах мы отсекаем 1% самых высоких и 1% самых низких зарплат, чтобы они не смазали картину. Как считаются зарплаты и как пользоваться калькулятором, мы подробно рассказали в справочной статье на сайте.

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

Обзор составлялся на основании рекомендаций: генерального директора ЕАЕ-Консалт Владислава Таболина (имеет богатый опыт управления крупными проектами, руководит компанией, продолжительное время работал инженером АСУ ТП), начальника управления 1С Марии Погореловой (постоянно руководит проектами), начальника управления систем электронного документооборота Павла Шутова (постоянно руководит проектами),  системного аналитика Михаила Шаланина (постоянно взаимодействует с PM, работал менеджером проекта 4 года). 

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

Стандарты, руководства, статьи

PMBOK (Project Management Body Of Knowledge) — это основа для любого, кто занимается управлением проектами. Большинство знакомых с темой наверняка сталкивались, а кто-то, вероятно, сертифицировался. Несмотря на это, существует множество PMов, лишь отдалённо знакомых с PMBOK и игнорирующих его в своей деятельности. В России встречаются специалисты, ограничивающиеся национальным стандартом ГОСТ Р ИСО 21500-2014, который идентичен ISO 21500:2012 «Guidance on project management», считая PMBOK избыточным сводом знаний. На наш взгляд, такая практика ошибочна. Созданный PMI свод знаний стал универсальным стандартом во всём мире. 

Менеджеры поначалу игнорирующие PMBOK, как избыточный, часто начинают обращаться к нему в моменты масштабирования и усложнения проектов, превращения проектов в программы. Это всегда хорошо отражается на работе команды, нередко позволяет сократить сроки разработки и тестирования, снизить риски. Общее мнение всех опрошенных специалистов — “Руководство по PMBOK” должна стать настольной книгой каждого менеджера проектов, свод знаний обязателен к регулярному прочтению вне зависимости от опыта и прочих компетенций менеджера. 

Своеобразной альтернативой руководству PMBOK, а вернее сказать дополнением и расшифровкой его содержания, является произведение Rita Mulcahy’s PMP Exam Prep. Эта работа поможет подготовиться к международной сертификации по управлению проектами PMP (Project Management Professional).

Помимо упомянутых выше стандартов ISO 21500:2012 «Guidance on project management» также полезно ознакомиться с ISO 21500: Project, Programme and Portfolio management – Context and Concepts, 2021 года и более поздней версией ISO 21502 Project, programme and portfolio management — Guidance on project management, 2020 года. При этом важно понимать, что описанное в стандартах не всегда подходит для конкретного проекта.

Важнейшим документом в связи с широкой распространенностью гибких методологий является руководство по SCRUM (Scrum Guide). Документ позволяет сформировать представление о том, как применить SCRUM в проекте, раскрывает сущность терминов, понятно и просто показывает, как выстраивать работу в её рамках. Руководство написано легендарными agile-методологами Кеном Шабером и Джеффом Сазерлендом, создателями SCRUM. 

Работа PM с использованием принципов Agile невозможна без понимания основополагающего документа для любой гибкой методологии, Agile-манифеста. Документ настолько краткий и ёмкий, что писать на него обзор бессмысленно, достаточно дать ссылку.

Также, среди методологических скиллов важно “уметь в Waterfall”, особенно это касается нашей отрасли — системной интеграции и промышленного программирования. Значительная часть проектов с нашей спецификой использует эту методологию и она не потеряла свою актуальность. Среди полезных материалов по теме рекомендуем статью Mondey об актуальном использовании Waterfall в 2023 году. 

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

Книги

Ли Якокка «Карьера менеджера» — концептуальный бестселлер деловой литературы, написанный в форме увлекательной автобиографии. Книга никак не связана с ИТ и между тем является превосходным наглядным пособием для руководителя, затрагивает как работу с проектами, так и операционную деятельность машиностроительной корпорации. Автор построил блестящую карьеру в компании «Форд», став её президентом, и проработал в этой должности восемь лет. В книге в доступной ироничной форме, от первого лица, описывается преодоление множества непростых ситуаций в работе со сложными проектами. Способы, описанные автором для их преодоления, легко проецируются на ИТ. Также в книге уделяется много внимания непростым отношениям между людьми в токсичном корпоративном окружении. По мнению CEO EAE-Консалт, Владислава Таболина, книга является путеводителем для любого эффективного руководителя.

Вадим Богданов «Управление проектами. Корпоративная система — шаг за шагом» — книга одного из признанных авторитетов в области проектного менеджмента в России. По ценности, глубине и практикоориентированности сопоставима с материалами PMI. В книге даны как основы управления проектами, так и ряд лайфхаков, особенно ценных в крупных проектах. Нестареющее руководство, которое легко использовать как в ИТ, так и в других направлениях. По нашему мнению, сложно найти более полезную книгу русскоязычного автора, специально написанную для PM. Особенность книги — превосходная структура, где сначала последовательно описаны сущность и состав систем управления проектами, подготовка к её внедрению, а затем даны подробные инструкции по работе с отдельными проектами и портфелями проектов. 

Джеффри Лайкер «Дао Toyota. 14 принципов менеджмента ведущей компании мира» — книга особенно впечатлившая Павла Шутова. По его признанию — это лучшее, что можно прочитать о корпоративном управлении, в принципе, и о об управлении проектами, в частности. Книга Лайкера — подкупает возможностью применить опыт японской корпорации и фактически является методологическим руководством. О кайдзен и канбан, которые стали широко популярны благодаря успехам Toyota, многие узнали из этой книги.  PMам книга позволяет понять, как равномерно распределять проектные ресурсы и нагрузки в команде, опираться на стратегическую перспективу в принятии текущих решений, овладеть искусством бережного отношения к ресурсам проекта.

Элияху Голдратт «Цель: процесс непрерывного улучшения», одна из любимых книг Марии Погореловой. Книга затрагивает подходы проектного менеджмента и бережливого производства. Чтобы проект не стал рутиной и бесполезной работой, является важным понимание всей проектной командой, для чего он инициирован и какие выгоды получит  владелец продукта в результате реализации проекта. 

Том Демарко «Deadline» (Роман об управлении проектами) — ещё одна рекомендация Марии. В идеале, начинать с этой книги знакомство с профессией. Произведение уникально тем, что главный герой, руководитель корпорации, производящей ПО мирового уровня, каждый день фиксирует в блокноте выводы в части управления проектами. Для Марии оказался близок один из тезисов героя романа: «Для руководства нужны сердце, нутро, душа и нюх». Мария подчеркивает, что книга демонстрирует значимость эмоционального интеллекта и эффективной коммуникации при управлении проектами.

Карл Вигерс и Джой Бити «Разработка требований к программному обеспечению» — первоначально книга писалась для системных и бизнес-аналитиков, неофициально её часто называют библией аналитика. Между тем, её прочтение позволит PM лучше разбираться в формировании требований и оценивать детальность их описания на стадии их разработки. Менеджеру проекта книга позволит понять, на сколько качественно сформулированы требования и лучше оценить сроки реализации. Особое место в книге уделено формированию требований при использовании гибких методологиях управления, например, SCRUM.

Джон Яблонски «Законы UX-дизайна» — небольшая книга о важных принципах создания пользовательских интерфейсов. В первую очередь, ориентирована на дизайнеров. Для PM — это сжатый источник знаний о том, как оценить качество интерфейса не только интуитивно, но и опираясь на кратко сформулированные и четкие критерии. Тот случай, когда можно твёрдо сказать дизайнеру, что аргументы из серии “я художник — я так вижу» — не работают. Книга особенно полезна тем менеджерам проекта, которые разрабатывают web-продукты, мобильные приложения и системы со сложными полифункциональными интерфейсами, где дизайн интерфейса почти полностью определяет пользовательский опыт.

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

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

Мы находимся на пороге новой эры ODD — разработки на основе наблюдаемости. В ней на первый план выходит применение инструментария бэкенд-кода в качестве утверждений для проведения тестов и культура тестирования на основе трассировки. Используя Tracetest, бэкенд-разработчики не просто генерируют E2E-тесты из трассировок OpenTelemetry, они меняют подход к обеспечению качества и повышению скорости даже в самых сложных приложениях.

Команда VK Cloud перевела руководство по инструментам для кода и самостоятельному запуску тестов на основе трассировки. Полный исходный код из статьи можно найти на GitHub.

Настоящее: разработка через тестирование (TDD)

Самые традиционные методы тестирования подразумевают, что сначала, исходя из требований к ПО, пишется код, а потом — интеграционные или E2E-тесты, с помощью которых проверяют его работоспособность. При разработке через тестирование (TDD) разработчики создают сценарии тестирования до написания кода, чтобы обеспечить соблюдение требований к приложению. С TDD цикл разработки ПО кардинально меняется. Согласовав требования, ваша команда:

1. Добавляет тест, который считается пройденным, только если эти требования соблюдены.
2. Запускает тест и видит, что он не пройден, как, собственно, и должно быть.
3. Пишет самый простой код, при котором тест будет пройден.
4. Снова запускает тест и видит успешный результат.
5. По мере необходимости рефакторит код, чтобы повысить эффективность, удалить дублирующиеся фрагменты, разбить код на порции поменьше и так далее.

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

Сложности создания и выполнения тестов TDD в бэкенд-разработке

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

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

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

При выполнении E2E-тестов могут возникать сценарии, в которых видно, что CI/CD-пайплайн не прошел тест, но непонятно, где или почему. Часто в поисках ответа вам придется бродить по бесконечному лабиринту, особенно если вы проверяете работоспособность микросервисов.

Если вы не можете определить, где тест не пройден — между микросервисом A и B, или Y и Z, — то для разработки кода ваши сценарии тестирования оказываются бесполезными инструментами. Вы просто пытаетесь обойти вслепую загадочные препятствия.

Как добавлять бэкенд-тесты в среду TDD

Чтобы показать сложности интеграционного и E2E-тестирования в распределенных средах, возьмем в качестве простого примера проект Node.js. Чтобы просто установить инструменты тестирования, нужно добавить в базу несколько новых библиотек: Mocha, Chai и Chai HTTP. Потом для тестов сгенерировать mock-данные, которые хранятся в репозитории, то есть для тестирования увеличить в нем количество файлов и папок, еще сильнее запутав и без того сложную структуру. А потом, чтобы добавить один-единственный тест, нужно написать немаленький кусок кода:

const chai = require('chai'); const chaiHttp = require('chai-http'); chai.use(chaiHttp); const app = require('../server'); const should = chai.should(); const expect = chai.expect;  const starwarsFilmListMock = require('../mocks/starwars/film_list.json');  describe('GET /people/:id', () => {   it('should return people information for Luke Skywalker when called', done => {     const peopleId = '1';     chai       request(app)       .get('/people/' + peopleId)       .end((err, res) => {         res.should.have.status(200);         expect(res.body).to.deep.equal(starwarsLukeSkywalkerPeopleMock);         done();     });   }); });

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

Будущее: разработки на основе наблюдаемости с помощью Tracetest

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

Именно так можно обнаружить и зафиксировать опасные «неизвестные неопределенности» разработки — точки сбоев, для которых вы не могли создать тесты, потому что понятия о них не имели.

В основе ODD лежит распределенная трассировка, которая регистрирует пути HTTP-запроса при прохождении через приложения и API, работающие в облачной инфраструктуре. Каждая операция трассировки представлена как спан, к которому можно добавлять утверждения — тестируемые значения, помогающие определить, успешен спан или нет. В отличие от традиционных инструментов API, утверждения в тестировании на базе трассировки касаются ответа системы и результатов трассировки.

У распределенных трассировок огромные преимущества в области ODD. Они помогают вам и вашей команде:

• Понять весь жизненный цикл HTTP-запроса при его прохождении по распределенной инфраструктуре. Видеть, успешен ли он и где конкретно происходит сбой.
• Отслеживать проблемы или создавать новые тесты, ничего не зная о системе и не создавая новый код.
• Решать проблемы производительности на уровне кода.
• Выполнять тесты на основе трассировки непосредственно в продакшне.
• Выявлять и устранять «неизвестные неопределенности» системы, которые, возможно, проскочили даже мимо сложного TDD.

Как добавить инструментарий OpenTelemetry в бэкенд-код

Платформа Tracetest интегрируется со многими хранилищами данных трассировки, такими как Jaeger, Grafana Tempo, Opensearch и SignalFX. Самый быстрый способ настроить распределенные трассировки — это добавить в базу кода SDK OpenTelemetry для конкретного языка. У популярных языков также есть auto-instrumentation, как в примере с Node.js, который мы создадим ниже.

Если у вас уже есть хранилище данных трассировки, например, Jaeger, Grafana Tempo, Opensearch или SignalFX, воспользуйтесь нашими подробными инструкциями по быстрому подключению Tracetest к экземпляру.

Например, нам нужно всего лишь несколько строк кода, чтобы добавить трассировку в проект на основе Node.js/Express:

const opentelemetry = require('@opentelemetry/sdk-node') const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node') const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http')  const sdk = new opentelemetry.NodeSDK({   traceExporter: new OTLPTraceExporter({ url: 'http://otel-collector:4318/v1/traces' }),   instrumentations: [getNodeAutoInstrumentations()], }) sdk.start() 

Этот код функционирует как оболочка для остального приложения, запуская трейсер и отправляя трассировки в коллектор OpenTelemetry, который, в свою очередь, передает их в Tracetest. Для этого нужно несколько дополнительных сервисов и конфигураций, но мы можем упаковать все в два файла Docker Compose для всей экосистемы.

В репозитории Tracetest на GitHub можно найти проект на основе Node.js/Express и примеры интеграции с другими хранилищами данных трассировки.

Чтобы быстро найти нужный пример, выполните команду:

git clone https://github.com/kubeshop/tracetest.git cd tracetest/examples/quick-start-nodejs/ docker-compose -f docker-compose.yaml -f tracetest/docker-compose.yaml up --build 

Как использовать Tracetest для ODD

Мы показали, насколько легко Tracetest интегрируется с разными хранилищами данных трассировок. Возможно, теперь вы захотите создавать тесты на их основе, формулировать утверждения и внедрять разработку на основе наблюдаемости.

В системе macOS установка Tracetest CLI происходит в один шаг:

brew install kubeshop/tracetest/tracetest 

Примечание. Дополнительную информацию можно найти на странице «Загрузки».

Мы рекомендуем в соответствии с официальной документацией установить Tracetest CLI+сервер: это поможет настроить источник данных трассировки и генерировать все файлы конфигурации, необходимые для сбора трассировок и создания новых тестов. Более подробное объяснение можно прочитать у нас в документации. Можно также прочитать статью о подключении Tracetest к OpenTelemetry Collector.

После того как вы настроили Tracetest, откройте в браузере http://localhost:11633, чтобы проверить пользовательский веб-интерфейс.

Создавайте тесты визуально

В пользовательском интерфейсе Tracetest нажмите выпадающий список Create и выберите Create New Test. Здесь мы создаем HTTP-запрос. Нажмите Next, придумайте имя и описание для теста.

В этом простом примере вы просто используете команду GET
для приложения, которое работает по адресу http://app:8080.

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

Как формулировать утверждения для каждой отдельной точки HTTP-транзакции

Перейдите на вкладку Test, нажмите Add Test Spec и сформулируйте утверждения — это фундамент, на котором строится внедрение ODD и отслеживание общего качества приложения в разных средах.

Чтобы создать утверждение на базе GET/спана нашей трассировки, выберите этот спан в представлении «граф» и нажмите Current span в модальном окне Test Spec. Или просто скопируйте селектор этого спана с помощью Tracetest Selector Language:

span[tracetest.span.type="http" name="GET /" http.target="/" http.method="GET"] 

Ниже добавьте атрибут attr:http.status_code и ожидаемое значение, то есть 200. Можно добавлять и более сложные утверждения, например, проверить, выполняется ли спан меньше чем за 500 мс. Для этого добавьте новое утверждение для  attr:http.status_code, выберите < и добавьте ожидаемое значение — 500 мс.

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

Потом нажмите Save Test Spec, после чего появляется Publish, — вот вы и создали свое первое утверждение.

Создайте YAML для теста в Tracetest

Создав спецификацию теста, нажмите на шестеренку рядом с Run Test, потом Test Definition: откроется модальное окно для просмотра и загрузки файла .yaml, который понадобится для запуска этого теста с помощью Tracetest CLI:

Загрузите файл .yaml, назовите его test-api.yaml и сохраните в корневой директории приложения, которое мы взяли для примера.

Как выполнить тест в Tracetest CLI

Конечно, можно выполнить тест в GUI, нажав кнопку Run Test. Тест будет выполнен на основе распределенной трассировки и скажет, подтвердилось ли утверждение. Автоматизация позволяет с помощью Tracetest обнаруживать регрессии, проверять SLO сервисов и делать много другого. Так что давайте продемонстрируем инструментарий CLI.

Вернитесь к терминалу и проверьте конфигурацию Tracetest CLI:

tracetest configure  [Output] Enter your Tracetest server URL [http://localhost:11633]: http://localhost:11633 

Запустите тест, используя дефиницию, которую вы создали и загрузили выше:

$ tracetest test run -d test-api.yaml -w  ✔ Example Test One (http://localhost:11633/test/ycmoH254g/run/7/test)

CLI покажет, выполнен ли тест корректно, но не покажет, пройден он или нет. Для этого кликните по ссылке в CLI output или вернитесь в Tracetest.

Тест пройден, ведь вы тестируете код состояния HTTP-запроса, который должен быть равен 200, и продолжительность должна быть гораздо меньше 500 мс.

Теперь посмотрите, как ODD и тестирование на базе трассировки помогает находить ошибки в коде, экономя вам время на написание дополнительных тестов. Добавьте  setTimeout, который не позволяет приложению выдавать ответ по крайней мере 1 000 мс.

const express = require("express") const app = express() app.get("/", (req, res) => {   setTimeout(() => {     res.send("Hello World")   }, 1000); }) app.listen(8080, () => {   console.log(`Listening for requests on http://localhost:8080`) }) 

Повторите тест в CLI, потом перейдите в Web UI. Там вы увидите, что утверждение не подтвердилось из-за setTimeout. Это значит, что продолжительность спана превышает 1 с:

Заключение

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