Podlodka PHP Crew

Недавно приложил руки к Techlead Crew — там не только помогал спикерам делать доклады лучше и полезнее, но и провел экспериментальный формат System Design Interview, где кандидату не нужно было изобрести велосипед с нуля, а даже совсем наоборот — как-то жить с тем, что уже едет, скрипит, интегрировано бог знает с чем, и при этом не развалить всё к чертям, а ещё как-то развивать и поддерживать. Неудивительно, ведь обсуждали межсервисное взаимодействие — ту самую вещь, которая выглядит красиво на архитектурных диаграммах, а на деле превращается в танцы под названием «Почему вендор сломал нам интеграцию?».

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

Теперь залечу ещё и на Podlodka PHP Crew, где буду вещать на тему «Performance-тюнинг PHP: от кода до инфраструктуры». Залезем под капот PHP  (совсем немного), но не будем ограничиваться магическим твиком pm.max_children и надеждой, что opcache спасёт мир. Поговорим и про то, как выжать побольше из nginx, когда RPS растет, а запускать ещё один сервис может быть накладно (не все проекты живут в k8s, вот это да!). Вместо этого — будем колдовать на Lua в nginx. Потому что если можно усложнить, зачем упрощать?) Шутка, конечно. Писать отдельный сервис, когда достаточно простые (но требующие перформанса), может быть оверкилл, а проблему нагрузки надо решать.

А еще в программе много интересного, и не только про php:

➡️ Павел Вирский (Ozon)

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

➡️ Олег Мифле (Altenar)

— покажет, как индексы в БД могут навредить, и что делать, когда «оптимизация» приводит к регрессу производительности 💥

➡️ Ярослав Тарасов (Skyeng)

— проведёт разбор оптимизации Symfony-приложения через RoadRunner: от архитектуры до конкретных замеров ⚙️

➡️ Александр Макаров (Yii, Twindo)

— расскажет о низкоуровневой оптимизации PHP: от мелких улучшений до AI, который сам оптимизирует ваш код 🧩

Приглашаю на конференцию всех, кто пришёл в разработку через PHP — в те славные времена, когда mysql_query() был нормой, а если не работало — «поставь 777, брат, и всё полетит».

Залетайте и те, кто PHP до сих пор любит и те, кто его ненавидит всем сердцем.

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

Давайте поностальгируем и признаем — php с современными фреймворками все еще чертовски удобен.

➡️ А мой промкод deeperPHP дает скидку в 500р 🥳

А с чего вы начинали свой путь в IT и с каким жутким проектом пришлось столкнуться в своей карьере?

k8s 1.33

Сегодня расскажу о самых интересных новинках в k8s 1.33, релиз которого запланирован на 23 апреля, или почему важно поддерживать актуальные версии ваших кластеров, чтобы инфраструктура была еще стабильнее (и с новыми неожиданными багами, конечно же, с которыми вы еще не встречались).

➡️ Читать — по ссылке.

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

Вспомните, что windows часто рекомендовали обновлять только с выходом service pack 2, а с sp1 или вообще без service pack были достаточно багованые релизы.

Kubernetes Мега стартовал! 🔥

Для кого этот курс:

➡️ Для DevOps-инженеров, которые хотят:
- Перевести продукты компании на K8s;
- Использовать managed K8s для деплоя openstack;
- Повысить компетенции с точки зрения развертывания и сопровождения кластеров K8s;
- Разработать планы миграции АС с OpenShift на K8s;
- Углубиться в работу Kubernetes и применять методики на практике.

➡️ Для SRE-инженеров, которые хотят уверенно создавать отказоустойчивые кластеры.

➡️ Для руководителей, которые хотят повышать отказоустойчивость продукта, автоматизировать развертывания и научиться лучше траблшутить.

➡️ Для архитекторов, которые хотят использовать все возможности k8s при проектировании платформенных решений.

Нашли себя в списке? Тогда присоединяйтесь к потоку — сделать это можно до конца недели.

Подробности — на странице курса.

Как развёртывать кластеры в условиях отсутствия интернета?

Принес вам статью моего коллеги, Георга Гаала из AEnix. Внутри — подробный ответ на популярный вопрос «можно ли запустить систему в air-gapped режиме?»

Всё, как вы любите — со ссылками, скринами и фрагментами кода.

➡️ ЧИТАТЬ НА ХАБРЕ

Собесы с алгоритмами — это лишь входной фильтр!
В BigTech рулят совсем другие навыки (и это не код).

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

➡️ А именно: системное мышление, ownership и, да-да, коммуникация.

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

🐈 Хардскиллы — это, конечно, хорошо… Но недостаточно

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

Нужно еще разруливать политику, убеждать продактов, что твоя идея — не бред сумасшедшего, защищать свои решения на code review, оценивать, как твои изменения сломают жизнь пользователям (в хорошем смысле, конечно)... В общем, скиллов нужно куда больше, чем в учебнике по вашему любимому языку.

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

Завтра мы подробнее поговорим про скиллы, необходимые, чтобы выжить в бигтехе. Stay tuned!

Собесы с алгоритмами — это лишь входной фильтр!
Часть 2

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

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

➡️ 1. Системное мышление: видеть что происходит вокруг твоего пузыря

Системное мышление — это не просто умение разбираться в коде. Это умение видеть, как этот код влияет на другие системы, как он масштабируется, как он влияет на performance, security, reliability, scalability, maintainability, observability и прочие ***bility.

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

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

➡️ 2. Ownership: твоя система — твоя ответственность

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

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

В бигтехе ownership — это как раз то, что отличает посредственного инженера от отличного. Потому что в огромных системах никто не будет стоять над тобой с кнутом и указывать, что делать. Ты сам должен быть заинтересован в том, чтобы все работало как надо. (А если не работает - ты первый побежишь это чинить в три часа ночи).

➡️ 3. Навыки коммуникации: донести свои идеи крайне важно

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

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

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

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

🐈 Вывод

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