Про Highload++ 2022

Из интересных моментов на которые обратил внимание Александр:

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

Вместо обработки большого объема данных он рекомендовал воспользоваться системами парализации, такими как модуль pcntl (fork, signal), pthreads или проекты Swoole и Parallel;

Сравнивал пример использования корутин и тредов;

Продемонстрировал пример обмена данными между параллельными процессами на примере каналов (Channels) проекта parallel.

Обмен данных между паралельными процессами

Рассказал как происходит шаринг между паралельными процессами, порождённымм parallel.

Также он упомянул сложности с которыми могут столкнуться программисты долгих приложений на PHP (в контексте демона, запущенного в фоновом режиме) такие как кеширование DNS запросов на уровне FPM.

Под конец хочу добавить, что проект parallel ещё очень сырой, используйте его на свой страх и риск, Swoole на этот счёт чуть более стабилен.

Понравится: Тем кто пишет на PHP проекты сложнее чем банальный процессинг HTTP запросов.

Далее я планировал идти в зал h1 на доклад "Highload и Lowcode — единство и борьба противоположностей", но там велась речь про продукты от 1С, в которых я понимаю чуть менее, чем ничего, поэтому направился в сторону зала h5.

11:10 - h5 - СберБанк Онлайн: масштабная трансформация legacy

Докладчик: Артём Арюткин (Сбер)

В своё докладе Артём немного приоткрыл завесу тайны над тем как устроена кухня в Сбере и отметил что у них работает несколько, несвязанных друг с другом напрямую, команд, работающих над разными ИТ направлениями в Сбере.

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

Были упомянуты забавные парадоксы, типа если legacy проект на 75% переведён на новую платформу, то нагрузка на проект не только не падает, но даже растёт, так как в процессе перехода переключение подсистем происходит не сразу, а постепенно, параллельно с этим растёт и количество клиентских запросов.

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

Ещё докладчик рассказал о том, что отслеживает количество мигрировавших подсистем путём мониторинга количества клиентских запросов из legacy подсистем.

Понравится: Тех и тим лидам, а также менеджерам проектов, которые планируют отказ от legacy систем с переходом на что-то иное.

12:20 - p8 - Аспектно-ориентированное программирование в PHP: раскладываем сквозную функциональность по полочкам

Докладчик: Сергей Лебедев (VK)

В своём докладе Сергей рассказывал про принципы использования подходов АОП в приложениях, о том откуда появилось такое направление, зачем оно нужно, привёл некоторую историческую справку про развитие АОП и привёл примеры использования АОП в PHP проектах и рассказал как определить хороший ли фреймворк для работы с аннотациями (спойлер: фреймворк должен парсить аннотации перед исполнением программы, после чего класть то что получилось в кеш и уже дальше читать из кеша).

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

/**

* @Before(Auth->isAdmin(*))

**/

Данная аннотация описывает, что перед вызовом метода, идущего ниже, необходимо выполнить метод указанный в описании аннотации, проверяющий имеются ли права администратора у пользователя который указанный метод вызывает. Есть ещё такие аннотации как After, Around и так далее.

Поддержка АОП имеется во многих продуктах Java (например Spring) и почти языках для платформы JVM (исторически первое AspectJ), C# (маленький пример) и некоторых плагинах для PHP, самый любопытный из них это GoAopBundle заточенный под Symfony, но есть адаптер для Laravel.

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

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

13:30 - h1 - Как достать всё что угодно со всего интернета

Докладчик: Илья Кучумов (Яндекс)

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

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

Первым делом они запилили CSS-селектор HTML, что-то типа XPath в JSON, по нему определяется где находится цена на каком-то сайте, ибо решение в лоб (искать всё что похоже на цену) не работал, например если на анализируемом сайте имелись рекламные баннеры, которые тоже содержали цену.

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

После этого они стали изучать дерево DOM с попыткой найти закономерности в уже собранных данных и пришли в итоге к классификационной модели DSSM, которая бы определяла является ли страница товаром с ценой, и обучалась бы на селекторах собранных ранее, а в ответе генерировала css-селектор по данным типа url, title.

В последствии разработчики поняли, что не обязательно постоянно обновлять цены для всех товаров, ведь есть товары, цены которых меняются чаще чем другие (популярные категории и товары). Поэтому они реализовали ещё одну модель которая возвращала вероятность изменения цены по данным типа title, category, offer_age (время последнего запроса цены).

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

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

14:40 - p7 - Апгрейд и рефакторинг PHP-проектов — теперь это просто

Докладчик: Александр Володин (Skyeng)

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

Александр продемонстрировал множество небольших примеров и интересные use cases применения данной утилиты, скажу честно я раньше не задумывался об автоматизации внесения правок в проект который зависит от некоей библиотеки внутри которой реализована поддержка Rector. С моей скромной точки зрения это решение поможет решить множество проблем и в разы ускорить процесс отказа от legacy костылей.

Кстати, Томаш Вотруба - автор проекта Rector, написал книгу The Power of Automated Refactoring в которой подробно описал как пользоваться Rector и для чего он вообще нужен.

Понравится: Профессионалам в области разработки на PHP задумывающимся об автоматизации рефакторинга.

15:50 - h1 - Приемы повышения точности геолокации телефонов на сети мобильного оператора

Докладчик: Артём Каледин (Билайн)

Мне как инженеру связи (по первому высшему образованию) было интересно послушать о том не появились ли какие-то новые механизмы геолокации пользователей.

Оказалось, что и да и нет, в докладе велось повествование о методах триангуляции мобильного телефона подключенного к сотам мобильной сети. В принципе довольна избитая тема, я о подобных решениях слышал ещё во времена когда работал в кТТК (бывший Спарк) в далёком 2012 году.

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

Понравится: Аналитикам и инженерам связи.

Дальше было время небольшого перерыва, которое огромная толпа гиков (в том числе и я) собравшихся под одной крышей посвятила обеду. Сидеть в столовой и слушать разговоры людей неподалёку было крайне интересно, как будто это мысли в моей голове, роящиеся и тут и там.

17:00 - p8 - Хождение по граблям PDO

Докладчик: Валерий Горбачев (Delivery Club)

Крайне любопытный доклад про сложности создания ORM с применением PHP PDO от разработчика принимающего активное участие в разработке проекта Yii3.

В своём докладе Валерий сравнивал ~~костыли^W~~ особенности взаимодействия с базами MySQL, PostgreSQL, MSSQL и Oracle. А также о том какие пришлось использовать хитрости для того чтобы унифицировать код ORM и добиться единообразного поведения.

Очень много было сказано про флаги PDO, для себя отметил флаг FETCH_NAMED, как-то никогда им не пользовался, если в двух словах, то он позволяет вернуть строку и таблицы которая будет содержать пары key=>value, где key это название колонки таблицы, но при этом не потеряется значение дублирующихся полей (оно будет добавлено в массив значений соответствующего ключа).

А ещё понравился рассказ про флаг FETCH_CLASS, данный флаг позволяет смапить значения сразу в атрибуты класса описывающего модель элемента, ближайшая аналогия это модели Laravel или Symfony.

Понравится: Всем кто хоть раз делал PHP приложения взаимодействующие с СУБД через драйвер PDO.

18:00 - h5 - Bare metal K8s, или Туда и обратно. История Quadcode

Докладчик: Илья Устинов (Quadcore)

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

Изначально они использовали утилиту kubespray, но в дальнейшем использовали её в качестве основы для своего решения, но и эта идея показала свою несостоятельность, поэтому они обратились к помощи утилиты kubeadmin.

Понравится: Тем кто часто разворачивает тестовые кластеры Kubernetes для обкатки каких-то своих фич.

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

Сложилось впечатление, что с отечественным ИТ не всё так плохо, как об этом пишут в некоторых недалёких СМИ и социальных сетях.

День второй (25 ноября)

На второй день решил учесть особенности московского traffic jam и попал на конференцию немного раньше чем планировал.

Был приятно удивлён количеством людей, по ощущениям их не стало сильно меньше, скорее наоборот, хотя мне казалось, что мол второй день, самые крутые доклады были рассказаны и часть народа разъедется по домам.

В планах было посетить побольше докладов про Kubernetes, так как секция про PHP интересовала меня в основном только с точки зрения бесед про зарплаты и про 12 factor app в кубере.

10:00 - h1 - Строим отказоустойчивую инфраструктуру приложения в Kubernetes. Принципы, паттерны, приёмы

Докладчик: Олег Вознесенский (Газпромбанк)

Любопытный доклад где в общих чертах было рассказано про построение отказоустойчивых систем, в частности была затронута тема того как делать отказоустойчевые решения на уровне Kubernetes (system level).

Одна фраза мне хорошо запомнилась:

Лучше плохо работать, чем хорошо лежать.

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

Так же Олег ссылался на доклад, вдохновивший его, называется он Паттерны отказоустойчивой архитектуры, которой читал Александр Кривощёков из Яндекса, в нём более развёрнуто говорится про application level, настоятельно рекомендую послушать.

Особенно понравилось про:

То чтобы хелс, рединес и прочие пробы выполняли проверку бизнес логики, а не портов по отдельности;
Реализацию Retry/Timeout на уровне Ingress, чтобы клиенты в случае отказа одного или нескольких подов реплики получали данные из другого живого пода;
Kind: VirtualService от Istio, позволяющий реализовать ретраи для отдельных HTTP методов.

Понравится: Девопсам заинтересованным в обеспечении высокой отказоустойчивости своих приложений.

11:10 - h1 - Сочетание несочетаемого в Kubernetes: удобство, производительность, безопасность

Докладчик: Дмитрий Евдокимов (Luntry)

Ссылка на видео

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

Дмитрий также упоминает про парадигму Continuous Security которая должна дополнять Continuos Integration и Continuos Delivery, не знал что такое существует, но считаю что вопрос нужно будет изучить чуть поглубже.

Далее идёт разбор способов изоляции и сегментации на уровне Kubernetes, в частности:

Cluster-as-a-Service
Namespace-as-a-Service
ControlPlane-as-a-Service
Node-base Isolation

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

Примеры проектов на которые стоит обратить внимание: Cluster API, KubeSlice, Capsule, Kamaji, vCluster, Kiosk, kcp, KubePlus.

Далее речь шла про механизмы переопределения политик безопасности на примере утилит типа Kyverno и Gatekeeper они нужны для более точного управления политиками безопасности и политиками управления ресурсами.

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

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

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

Но самое интересное в таких ОС это режим Read-Only у файловой системы, это настолько очевидное и простое решение, что я даже не понимаю как оно мне не приходило в голову ранее.

В качестве примеров подобных ОС приводятся:

Данные ОС являются самыми популярными решения, но понятное дело имеются ещё многие другие решения. Кстати, хочу заметить, все указанные ОС имеют поддержку ARM64 процессоров и их потенциально можно запустить на Raspberry Pi, чем я скорее всего и буду заниматься в недалёком будущем, о чем постараюсь написать соответствующую статью.

Отдельно Дмитрий отметил операционную систему Talos, так как она позиционируется именно как Kubernetes Operation System и специальным образом заточена именно под этот стек технологий, из забавных её особенностей это Read-Only FS и полное отсутствие shell'а, то есть неподготовленный специалист даже не сможет на неё зайти.

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

Debian Slim - Просто Debian в котором нет почти ничего, кроме boottrap.
Alpine - пожалуй самая популярная минималистичная ОС для создания своих контейнеров, поговаривают что там имеются какие-то проблемы с glibc из-за которых приложения работают чуть медленнее.
Scratch - Очень любопытное решение, заставляет Docker Engine в режиме сборки игнорировать этап подключения базового образа и всю последующую работу докер выполняет в пустом окружении, удобно если нужно например создать контейнер из одного единственного статически слинкованного бинарника, написанного например на С/C++ или хитро собранного Go приложения.
Distroless - Набор очень минималистичных базовых образов от Google в которых вырезана вся операционная система кроме Runtime необходимого для запуска приложений написанных на том или ином языке программирования.

Либо создать свой собственный образ с минимальным набором возможностей:

Chainguard Images - состоит из ряда утилит, помогающих быстро и просто создать свои собственные минималистичные базовые образы.

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

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

Дальше Дмитрий чуть более развёрнуто рассказывает про Distroless, существует несколько разных вариантов образов, каждый из которых использует одни из предыдущих, например:

в static нет ничего кроме корневой файловой системы, сертификатов и списка пользователей, групп, приоритизация использования сети;
в base используется слой static в качестве основы и есть такие библиотеки как glibc, openssl;
в cc используется слой base и добавляются инструменты необходимые для работы сишных приложений, например libgcc;
Далее имеется несколько специфичных рантаймов под nodejs, java, python и так далее.

Но возникает вопрос как отлаживать и тестировать приложения запущенные в таких контейнерах? Для этого в Kubernetes с 1.18 появилась такая фича как Ephemeral Containers, в сочетании с kubectl debug эта фича позволяет подсоединять к контейнеру другой базовый образ, например содержащий необходимый инструментарий для отладки. Если я правильно понял это работает по тому же принципу что и overlayfs2, о которой я рассказывал в одной из предыдущих своих публикаций, и файловая система с отладочными инструментами монтируется поверх Distroless образа. В качестве пример приводится Koolkits, которая имеет различные наборы инструментов для подключения к различным рантаймам.

Теперь чуть подробнее про Chainguard Images, допустим у вас имеется какой-то Distroless образ в котором есть утилита OpenSSL, есть специальные исследования, которые показывают что если запустить её в режиме шелла то можно читать и записывать в файлы произвольный код, это приводит к тому что даже в Distroless-based системе имеются потенциальные дыры в безопасности.

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

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

Далее разговор идёт про ограничения межсетевого взаимодействия, в частности речь идёт про NetworkPolicy уровня кластера, при помощи этих политик можно описать куда и каким образом можно обращаться из контейнеров. Из любопытного это замечание о том что если не использовать NetworkPolicy то сеть работает хуже (в контексте Cilium, надо будет изучить этот момент для Calico), так как на уровне кубера Allow-All это четвертый (предпоследний) уровень правил, а правила NetworkPolicy первый (самый высокий) и если использовать хоть какие-то правила ограничения трафика, то количество межсетевых задержек будет меньше.

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

Ну и в завершение Дмитрий упомянул парадигму DIE: Distribyted, Immunable, Ephemertal, то есть не сидеть и думать что всё хорошо и хацкеры не могут проникнуть, а в случае малейшего проникновения необходимо иметь возможность быстро прибить скомпроментированный контейнере или хост и быстро заменить его на другой. Тут идея про динамическое окружение, за которым взломщик не сможет угнаться даже в случае проникновения.

Понравится: Всем без исключения задумывающимся про безопасную контейнеризацию.

12:20 - p8 - PHP в облаках

Докладчик: Павел Вирский (Авито)

Мой тёзка в данном докладе разбирал принципы 12 factor app:

Необходимо использовать CDN для статики;
Выгружать пользовательские файлы в S3 бакеты или какое-то иное хранилище типа Ceph;
Для отображения картинок использовать проксики типа Imgproxy или Thumbor;
Не использовать СУБД в контейнере, а держать её на отдельном сервере, либо использовать statefull контейнеры, например храня разделы с базой на PV;
Кеш хранить в какой-нибудь отдельной базе типа Redis, сессии пользователей тоже отдельно например в Redis или MySQL;
Не использовать cron на уровне контейнера, а вместо него использовать мьютекс, например Artisan Scheduler или CronJob'ы;
Логи слать на stdout и собирать их специализированными системами заточенными под Docker;
Секреты хранить в отдельном внешнем сервисе типа Vault или в Kubernetes Secrets;
Конфигурации приложений передавать через ENV;
И так далее и тому подобное.

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

Для себя отметил рекомендацию использовать php-fpm_exporter для того чтобы понимать, что происходит с приложением в процессе работы, очень дельная идея, попробую её в скором времени.

Понравится: Тем кто только начинает свой путь в этом непростом мире контейнеризации PHP приложений.

13:30 - h3 - YDB Topic Service: надёжная и масштабируемая очередь сообщений

Докладчик: Ильдар Хисамбеев (Yandex Cloud)

Если кратко описать что такое YDB Topic Service то получится, что это практически полный аналог Apache Kafka, который позволяет без особых проблем совершить переход с решений на базе Kafka.

Разработка данного продукта началась ещё до того как в Kafka внедрили фичи, необходимые для работы сервисов Yandex Cloud, а сравнение современной версии Kafka с YDB Topics Service не проводилось. Ну то есть у меня сложилось впечатление, что переходить на решение от Яндекс имеет смысл только если вы любитель искусства ради искусства, какой-то иногй объективной причины для этого похоже что нет, но посмотрим-с что будет на какой-нибудь следующей презентации или в их ленте на Хабре, возможно их решение и правда лучше устоявшихся решений.

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

Основные фичи:

Надёжность: Сообщения не теряются, Настраиваемый FIFO-порядок, Поддержка exactly-once-семантики доставки при записи;
Масштабируемость: По throughput на запись, По числу партиций, По числу изолированных пользователей, Издержки на эксплуатацию — О(1)
Доступность: Отказы дисков, хостов — ежедневно, ДЦ — авария или регулярные учения, Переживать автоматически и без деградации по latency, Возможная геораспределённость;
Производительность: Throughput — десятки Гбайт/с, Latency < 1 с от отправки писателем до получения читателем.

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

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

Дальше ведётся речь про то как осуществляется работа множества партиций, как выполняется дедупликация и прочие моменты характерные также и для Kafka.

Во второй половине доклада слишком частно начинают упоминаться таблетки и в моём воображении начала без остановки играть мелодия "За монетку за таблеточку. Сняли нашу малолеточку." поэтому некоторое время было сложно концентрироваться на докладе :)

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

Понравится: Тем кто планирует использовать сервисы Yandex Cloud или по какой-то иной причине не может или не хочет использовать Apache Kafka.

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

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

14:40 - p8 - Что происходит на рынке труда?

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

Екатерина Фирсова (Altenar)
Григорий Богданов (Altenar)
Ильяс Салихов (RetailCRM)

Записи трансляции не было, поэтому попытаюсь тезисно пересказать услышанное:

Несмотря на кризис зарплаты у PHP разработчиков растут, особенно в Москве;
Быстрее всего зарплаты растут у специалистов уровня Senior, потому что между компаниями сейчас устроена гонка по переманиванию специалистов;
Зарплатная вилка (до уплаты налогов) PHP разработчика уровня Senior в диапазоне от 180 до 350 тысяч рублей (имеется ввиду Москва), в регионах чуть пониже, но не сильно.

Как понять какого уровня вы разработчик

Специалист 1 уровня

Техлид.

Специалист 2 уровня

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

Специалист 3 уровня

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

Специалист 4 уровня

Начинающий разработчик, джун.

Поэтому желательно в соответствии со своим квалификациями искать подходящую работу, ну и конечно же учиться, чтобы стать более крутым специалистом и получать б'ольшую зарплату :)

Понравится: Всем кому интересно понять на что стоит рассчитывать в наше непростое время разработчику на PHP.

15:50 - h5 - IT-инфраструктура после февраля 2022

Докладчик: Кирилл Малеванов (Selectel)

Очень важный доклад в котором Кирилл рефлексирует на тему того что осталось после "великого исхода" иностранных ИТ-гигантов, что осталось на "руинах" отечественного ИТ и о том какое будущее нам предстоить построить.

Кратко о текущих проблемах с точки зрения Selectel, зелёный - хорошо, желтый/оранжевый - более менее ок, красный - тяжело, темно красный - плохо.

Если в двух словах описать, не всё так плохо как это малют, да, проблемы есть и очень много где, где-то маленькие, где-то очень большие, особенно это касается разнообразного лицензионного программного обеспечения или вот например мало специалистов уровня Senior и Middle, но джунов осталось очень много и спустя год-два из большинства получатся толковые миды, а спустя ещё 2-3 года они дорастут до уровня сеньоров.

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

От себя добавлю, что с моей скромной точки зрения нас ожидает кризис, который продлится где-то 10 лет, сильнее всего в ИТ сфере он проявится в 2023-24 годах, но тут стоит сделать важное замечание, кризис этот глобальный и коснётся не только отечественного ИТ, а всей планеты в целом, поэтому для всех отечественных компаний появилась возможность очень неплохо подняться на опустевшем пространстве. Главное делать, а не поддаваться панике и впадать в уныние.

Понравится: Всем без исключения айтишникам.

17:00 - h1 - Почему видеостриминг через 15 лет возвращается с TCP на UDP

Докладчик: Максим Лапшин (Эрливидео)

Ссылка на видео

Хоть я и не специалист в области передачи видеопотока через Интернет, но как-то раз настраивал Nginx RTMP сервер для одновременного стриминга на Twitch и Youtube, в процессе настройки этого решения столкнулся с массой проблем и перечитал гору документации про различные моменты с этим связанные, так что хоть и небольшой, но экспертизой в вопросе обладаю.

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

Где-то в середине доклада речь заходит про WebRTC и мне становится понятной причины столько долгой подводки.

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

Понравится: Тем кто изучает вопросы связанные с разработкой платформы видеотрансляции.

18:00 - h4 - Побег из Шоушенка в мире сетей

Докладчик: Александр Попов (VK Cloud, VK)

Ссылка на видео