Всем привет 👋! Первый пост в канале будет посвящён докладу "Сети для 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. Пока экспериментирую с форматами, смотрю, что вам может быть интересно. Накиньте реакций, если понравилось 🔥

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

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

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

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

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

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

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

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

———

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