Всем привет 👋! Первый пост в канале будет посвящён докладу "Сети для Golang-разработчика", прочитанному на Let's GoConf

Код из презентации можно увидеть в репозитории (Ставим звёздочки, изучаем, пробуем сами!)

Доклад получился ориентированным на прикладной уровень и на решение конкретной задачи. Но, как мы и упомянали, сеть этим не ограничивается. Если вас заинтересовала тема, то... ✍️

Предлагаю обратить внимание на следующие материалы

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

- Разбираем HTTP/2 по байтам — Автор ещё глубже заглянул в HTTP/2, подходит, если вам захотелось узнать больше о том, почему вместо запроса и ответа мы получали какие-то фреймы и зачем это всё нужно. Ещё в статье упомянут механизм, про который мы не говорили - согласование клиента и сервера о том какую версию HTTP использовать для общения

- Разбираем TLS по байтам. Кто такой этот HTTPS? — статья от того же автора. Как только мы говорим про HTTPS сразу же стоит вспомнить, что у нас будет использоваться TLS. А кто такой TLS подробно и с иллюстрациями можно узнать в статье

- linkmeup — внутренняя кухня сетевых инженеров, советую сюда заходить после прочтения СДСМ, иначе можно утонуть в непонятных терминах + обратите внимание на их подкасты

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

- RFC 2616 HTTP/1.1 — можно прочитать не только сам стандарт, но и увидеть его развитие - какой стандарт заменил, или наоборот, какие стандарты его заменили. RFC 2616 считается уже устаревшим, его разделили на несколько частей, ссылочки в Obsoleted by секции, вот по ним можно и перейти в том числе

- RFC 9113 HTTP/2 — аналогично пункту выше, только речь про вторую версию протокола. Также можно посмотреть всю историю и проверить что же там в актуальной версии

- RFC 9114 HTTP/3 — к сожалению, не успели посмотреть третью версию протокола, а ведь очень хотелось! Можно почитать тут, но помните, что стандарт - это не реализация. Если в стандарте написаны классные сложные вещи, не факт, что какие-то фичи где-то можно увидеть в проде

Во время доклада мы успели посмотреть много примеров сетевого трафика (HTTP/1.1 vs HTTP/2 vs HTTPS etc) 🌐

А что за взаимодействие на скрине мы пропустили (и никто даже не вспомнил про него 🫠)?

Пишите в комменты ваши версии! 👇или попытайтесь угадать сначала самостоятельно)

Вопрос оказался не таким простым, поэтому поясню отдельным постом 👨‍💻

Основная подсказка заключается в HTTP-ответе 101 Switching Protocols. Сначала можно предположить, что мы переходим на другую версию HTTP, к примеру, с HTTP/1.1 на HTTP/2 Cleartext. Но тогда мы бы увидели HTTP/2 фреймы, значит дело в другом 🤔

А дело в том, что Switching Protocols может быть не только про смену версии HTTP, но и про смену протокола. В нашем случае мы перешли на WebSocket! И потом мы видим обмен WebSocket-фреймами, лакмусовой бумажкой для которых является [MASKED] маркер

⬆️ Всем привет! Буду выступать 4 июня на infra.conf с докладом "Как мы незаметно перемещаем десятки петабайт данных внутри S3". Конфа классная, треков много, приходите)

Всем привет! Спасибо тем, кто пришёл вчера на доклад "Как мы незаметно перемещаем десятки петабайт данных внутри S3" infra.conf 2026

Как и обещал, делюсь дополнительными материалами, которые могут быть полезны

Про наше хранилище:

- Свой S3-server: что делать, если ваши десятки петабайт уже не лезут в коробочные объектные хранилища — лонгрид на Хабре с подробным описанием нашего объектного хранилища Lusca

- «Собственная реализация S3 поверх Ceph» — доклад Виктора Корейши про наше объектное хранилище на infra.conf 2024

Про миграции:

- Как мигрировать данные в NoSQL на примере ScyllaDB — хороший учебный курс по миграциям в ScyllaDB University. Нужно будет выбрать раздел "Migrating to ScyllaDB", где рассказывают, какие есть подходы к миграции данных. Как я и говорил, многие подходы к миграции могут быть переиспользованы в разных системах

Академические материалы:

- Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency — академическая статья, где Microsoft рассказал, как устроено их хранилище Azure (не совсем S3, но похоже). Один из немногих материалов, где большие облака поделились деталями архитектуры своего хранилища. Материал старенький, но многие концепции остались актуальны

Мои предыдущие доклады:

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

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

AI научился генерировать код быстрее, чем мы научились его понимать, и причём тут менеджмент

Раньше разработчик мог написать условные 300 строк и спокойно пройтись по ним в ревью. Сейчас можно за короткое время получить несколько тысяч строк. Но внимание, память и способность держать контекст не выросли в 10 раз. Ответственность за код всё равно остаётся на человеке, пока что.

И тут неожиданно помогает не очередной AI-гайд (которых уже миллионы, мне кажется), а теория менеджмента. Например, идея Герберта Саймона об ограниченной рациональности.

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

Изначально эта теория применялась к менеджерам, но инженерам она тоже отлично подходит.

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

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

———
Эта же мысль объясняет не только AI.

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

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

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

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

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

Концептуальные отличия менеджерской и технической литературы

Пока готовлю для вас новые посты, хотел бы поделиться общими наблюдениями. По жизни мне приходилось читать довольно много разного материала - это были научные, индустриальные и обзорные статьи по Computer Science, статьи по биоинформатике, книжки профильные (условно "100 ошибок Go") и даже статьи по демографии (как-то электив выбрал в магистратуре) и так далее

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

Но вот со статьями по менеджменту я замечаю совершенно другой паттерн работы с материалом. Живой пример. Готовлю для вас обзор статьи "New Directions for Theories for Why Employees Stay or Leave", которая очень подробно рассказывает почему люди часто увольняются или, наоборот, годами сидят на одном и том же месте работы

Начинаю читать только введение и понимаю, что ловлю кучу инсайтов про жизнь в целом, даже не перейдя к основному материалу. К примеру, в самом начале приводится постановка проблемы, что в последние годы рекордно растёт количество добровольных увольнений (voluntary job resignations) и вместе с тем растёт количество quiet quitters (людей, которые не уходят, но которые делают минимальное количество работы). Это частично связывают с последствиями пандемии и массовым внедрением удалёнки - стал слабее контроль, упала встроенность сотрудников в компании и люди начали думать про well-being побольше

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

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

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

———

А у вас были книги/статьи/публикации, которые произвели вау-эффект? Было ли такое, что при прочтении технической литературы вы что-то поняли про жизнь в широком смысле слова?

———

P.S. Пока экспериментирую с форматами, смотрю, что вам может быть интересно. Накиньте реакций, если понравилось 🔥

Сила в междисциплинарных знаниях

Хотел поделиться личным достижением и немного порассуждать о междисциплинарности

Вчера меня награждали сразу двумя золотыми медалями олимпиады «Я - профессионал» по направлениям «Бизнес-информатика» и «Программная инженерия»

Для меня это важное достижение и хорошая валидация навыков на стыке технологий, данных и управления

А при чем тут междисциплинарные знания?

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

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

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

———

Канал новый, поэтому ваши реакции правда мотивируют писать дальше 🔥

Что не договаривают на большинстве докладов про AI

Прошло уже довольно много конференций, где добрая половина докладов была про AI. Лично я был на Saint HighLoad++ и на Arch.Meetup. Послушал довольно много докладов про AI и появилось ощущение, что есть довольно много слепых зон, которые явно не проговорили. Хотел бы обратить ваше внимание на эти вопросы

Я бы разделил доклады про AI на несколько категорий:

- Чистая техничка: про оптимизацию использования токенов, caveman, AST-индексы, использование субагентов и прочие приёмы. К этому типу докладов вопросов, в целом, нет

- Первые результаты внедрения AI в SDLC: рассказ про то, что внедрили AI и скорость разработки увеличилась на X процентов или что-то подобное. Вопросики тут уже появляются

- Питчинг будущего с AI: не просто рассказ про результаты, а попытка продать видение будущего. Тоже есть что обсудить

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

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

Часть вопросов обсудил с одним из спикеров - Иваном Поддубным, CTO в Вебпрактик и автором канала TechLead Stream. У нас получился хороший обмен мыслями, поэтому канал Ивана тоже советую к прочтению

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

Теперь перейдём к докладам, которые нам рисуют дивный новый мир будущего с AI. В воздухе есть такой лейтмотив, что AI даст возможность строить продукты с tiny teams - когда для результата не нужны будут большие команды, а будут команды по 4-5 человек (хотя для меня это не то, чтобы маленькие команды, но ладно 🙃)

Я бы тут просто отметил пару моментов, которые могут создать риски, но их могут не проговаривать. Вспомним теорию bounded rationality Г. Саймона, в постах выше я её уже упоминал. Трюк с уменьшением команд сработает только в том случае, если AI действительно сможет оставить уровень когнитивной нагрузки на разработчиков на уровне до AI-внедрения, если он будет выше, то трюк не сработает. Быстро настанут негативные последствия для команды.

И тейк про совсем дальнее будущее. Картинка через пять лет - прошёл переходный период, все компании внедрили AI в SDLC, токеномика сходится, всё прошло гладко. А конкурентное преимущество то теперь какое у отдельно взятой компании, если все бегут с одинаковой скоростью?

По теории Resource-Based View должны быть ресурсы (технические или организационные), которые дают конкурентное преимущество для отдельно взятой компании. Если этот ресурс, внедрённый AI в SDLC, есть у всех, то это уже ресурс, который перестал удовлетворять некоторым пунктам критериев VRIO (Valuable, Rare, Inimitable, Organized): он может оставаться valuable, но перестаёт быть rare и inimitable

Нужно будет искать новые VRIO-ресурсы. Что это будут за ресурсы - вопрос открытый

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

———

Вижу вашу активность, это просто пушка, спасибо всем за поддержку, двигаемся дальше 🔥