SE materials

Accidental and essential complexity

Замечали ли вы, что сложность бывает разной по природе?

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

И другой вариант: «Ой, у нас всё сложно, оказывается, чтобы пользователи могли поднимать виртуалки по кнопке, нужно столько всего сделать. Разбираюсь пока, столько нюансов»

Заметили разницу? В одном случае это сложность, которую мы сами себе создали: не настроили процесс предоставления доступов, не написали вовремя документацию к проекту и так далее

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

В первом случае сложность привнесённая (accidental), а во втором неизбежная (essential). Процесс выдачи доступов можно было бы правильно настроить, и он бы перестал быть сложным, а вот разработка и развитие публичного облака - это сама по себе сложная задача

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

А так пост вдохновлён подкастом Бреслава и Ложечкина про сложность, советую посмотреть/послушать

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

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

Подкаст

Вопрос всегда в масштабе

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

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

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

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

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

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

———

Можете масштабировать количество реакций под постом 🔥

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

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

Тогда возникает вопрос: а как показать навыки, которые нужны тимлиду, если в роли разработчика их трудно продемонстрировать?

И тут появляется интересная тема - управление без формальных полномочий. В крупных компаниях в IC-ветке есть грейды после сеньорского уровня: Staff Engineer, Senior Staff, Principal или другие вариации. Формально на этих грейдах у человека может не быть управленческих полномочий и собственной команды. Но его индивидуальный вес настолько велик, что он ведёт крупные проекты, влияет на несколько команд или меняет техническую стратегию целого направления

Это не означает, что Staff Engineer - будущий тимлид. IC и management остаются разными карьерными ветками. Но один из способов показать готовность к роли тимлида - попробовать вести проекты без формальных полномочий. В таком кейсе проявятся многие смежные навыки: умение договариваться с соседними командами, влиять на решения, брать ответственность и доводить проекты до конца

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

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

Что тут можно сказать. Почему мы так резко перешли с обсуждения Go/JS/Python на обсуждение AI на большинстве митапов? Потому что резко изменился основной рабочий инструмент, не более того. Количество постов в духе "Я не пишу код руками N месяцев" всё растёт, вместе с этим увеличивается интерес к обсуждению AI почти на любой айти-тусовке

Просто фиксирую, выводов пока не делаю. Потому что выводы лучше делать на холодную голову, иначе получаются очень цветные, но маловероятные картинки. См. посты выше про инварианты: люди остаются людьми, bounded rationality Г. Саймона никуда не уходит

Красивый код != результат: продуктовый подход для разработчиков

Сегодня хочется поговорить про призму, через которую можно смотреть на проекты и задачи. Разработчикам, как техническим специалистам, конечно, в первую очередь интересна техника. Скорее всего, вам хочется взять какой-то большой классный проект, где будет какая-нибудь хитрая реализация, чтобы потом сказать: "А я вот такое могу делать!" Это очень важная история, классно понимать, что ты создатель игрового движка, core-компонента в банке или хранилища данных на десятки петабайт, как в моём случае

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

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

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

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

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

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

Заметьте, фактически в каждом посте я говорю про одно и то же, хотя называть это можно по-разному: междисциплинарные знания, продуктовое видение, визионерство, soft-скиллы и так далее. Концептуально - это попытка с другого ракурса посмотреть на инженерную работу. Я как разработчик пытаюсь применять это для себя и вижу положительные результаты. Думаю, вам это тоже может быть полезно

———

Если вам понравился этот пост, то делитесь им с друзьями и коллегами, это очень ценно 🫶

Подумалось, что аватарка гофера не совсем отражает тематику канала ❤️

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

А ведь первые посты были на тему доклада «Сети для Golang-разработчика». Время такое - понимай и детали реализации HTTP клиента в Go, и как свой когнитивный капаситет рассчитать при работе с 🧠

Energy management - что это за зверь такой

Как вы знаете - канал про междисциплинарные знания, потому что мы не только специалисты в области Х, но и люди, которым широта знаний помогает. Можем обсудить и S3, и современные теории менеджмента, и общие наблюдения. Так что сегодняшний пост будет заметкой на полях про time energy management

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

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

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

Рассмотрим пример. У меня была расписана неделя. В каждом слоте было что-то вставлено с 8:30 до 23:00. Я делал дела согласно этому четкому плану, время на все выделил и первое время все спокойно закрывалось, все было четко. А потом система начала сбоить, потому что нужно было в 21:00 сесть на полтора часа и провести созвон. А я понимаю, что у меня просто нет сил - и все. Побыть на созвоне я, конечно, могу, но степень моей вовлеченности может сильно упасть

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

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

В чем была моя проблема? В том, что мой план не учел энергетический и когнитивный капаситет. С таким же успехом можно расписать план, в которым ты работаешь с 6:00 до 2:00 и спишь четыре часа. Потом я стал опытнее и старался таких ошибок не допускать. А если уж и вылезал за энергетический капаситет, то четко понимал причину этого, временный диапазон такого режима, цели и трейд-оффы

———

Напомню, что реакции - это диагностический инструмент вашей заинтересованности 😉

New Directions for Theories for Why Employees Stay or Leave и причём тут Рио-де-Жанейро

Много лет назад мне рассказали довольно интересную историю с очень неожиданной концовкой. Сидим на обеде с коллегой, обсуждаем какую-то фичу и в разговоре упоминается некий разработчик, пусть будет Вася. Вася когда-то начинал делать обсуждаемую фичу, но как-то не пошло. Очевидный вопрос с моей стороны - а что именно не пошло. И тут мне рассказали историю, как разработчик Вася взял отпуск, поехал в солнечную Бразилию 🇧🇷 и так ему понравился тропический климат и пальмы, что он решил не возвращаться - и уволился одним днём - по звонку в роуминге сказал, что можно его не ждать

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

Если вы общались со своими знакомыми на эту тему, то это скорее будет сборник баек: а у меня было так, а у соседа так, а я слышал, что...

Хорошо конечно, но хочется чего-то систематизированного. Недавно наткнулся на большой обзор New Directions for Theories for Why Employees Stay or Leave. И это прям алмаз - полный разбор эволюции теории текучести и удержания кадров с 1958 года по наши дни. Очень много инсайтов, 30 страниц с плотнейшим текстом на академическом английском. Хотел бы с вами поделиться инсайтами и рассмотреть историю выше через эту призму

Классические Why Employees Voluntarily Quit or Stay теории базируются на работе уже вам известного Герберта Саймона и Джеймса Марча. Они выделили две группы факторов из-за которых люди добровольно увольняются:

- PDM (perceived desirability of movement, воспринимаемая желательность ухода) - насколько человек хочет уйти

- PEM (perceived ease of movement, воспринимаемая лёгкость ухода) - насколько человек может уйти

По названию смысл понятен. Есть факторы, из-за которых человеку не очень хорошо на своём месте - PDM-факторы (неинтересные задачи, сложность, другой негатив). А есть факторы, из-за которых ему проще уйти - PEM-факторы (ситуация на рынке труда, востребованность, наличие альтернатив и т.д.)

Концепция, основанная на этих факторах, хорошо систематизировала причины ухода, с течением времени уточнялись детали. К примеру, что человеку может быть не очень на своём месте, но он видит будущие выгоды (subjective expected utilities - SEUs), к примеру, повышение - и он остаётся. Или, к примеру, что настроение в коллективе заразительно в обе стороны - если все хотят остаться, то и ты с большей вероятностью останешься. Если тебе не очень и ты делишься своими эмоциями, то и другие могут начать думать о переходе

Отлично, а как это поясняет бразильский кейс? В голову к человеку я не залезу, но давайте предположим, что раз разработчик работал много лет, то ему в целом было ок. К тому же, по комментариям коллег - был опытный специалист. Факторы PDM или PEM, кажется, не очень сильные. Как же объяснить его уход?

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

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

И такое бывает! А теория менеджмента снова показала, что у неё серьёзная научная база и ответы на все ваши вопросы уже давно есть в статьях. Рассказывайте ваши истории, будет интересно узнать ваши кейсы!

———

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

Что не договаривают на большинстве докладов про 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-ресурсы. Что это будут за ресурсы - вопрос открытый

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

———

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

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

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

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

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

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

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

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

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

———

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

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

Пока готовлю для вас новые посты, хотел бы поделиться общими наблюдениями. По жизни мне приходилось читать довольно много разного материала - это были научные, индустриальные и обзорные статьи по 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 научился генерировать код быстрее, чем мы научились его понимать, и причём тут менеджмент

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет! Спасибо тем, кто пришёл вчера на доклад "Как мы незаметно перемещаем десятки петабайт данных внутри 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 друг от друга и какие фичи мы можем использовать для решения прикладных задач. К примеру, как скачать огромный файл с нестабильной сетью и что делать, если наполовину скачанный файл обновился на сервере

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

Что вас ждёт в треке Infra на ❤️❤️❤️?

Сегодня подробнее про программу трека Infra. Знакомьтесь со спикерами и выбирайте, о чём хотели бы послушать.

❤️ — я уже зарегистрировался и жду встречу