AI Dev Podcast #2: Александр Поломодов, Сергей Баранов / Архитектура в эпоху ИИ (Рубрика #Architecture)
Около месяца назад мы записывали подкаст вместе с Сергеем Барановым (основателем ArchDays) и Андреем Дмтриевым (со-основателем JUG.RU) в рамках подготовки к сегодняшней конфе AI Dev Conf. Так получилось, что дальше я уехал в отпуск и забыл поделиться с вами этим эпизодом, а он был интересным:) Речь в нем шла про то, как LLM и мультиагентные системы меняют software architecture и инженерные процессы. Обсудили двойственную природу ИИ: с одной стороны - демократизация разработки (через lovable.dev и аналоги), с другой - жесткая необходимость в инженерном фундаменте для масштабирования.
Основными темами выпуска стали
- От SOE 1.0 к SOE 2.0: как люди и агенты будут работать в связке.
- Роль архитектора: больше не "чертежник", а стратег, валидирующий варианты от ИИ и выстраивающий внутренние модели.
- Экономика: почему типовые решения уходят в автоматизацию, а ценность повторного использования компонентов взлетает до небес.
- Болевые точки: бардак с данными и онтологиями, блокирующие зависимости между сервисами и проблема контекста.
- Прогноз: как готовить платформу к "мажорной разработке" с агентами и почему локальные эксперименты с моделями станут базовым навыком архитектора.
В итоге: агенты научатся писать код, делать ревью и документацию. Но ставить цели, изобретать и управлять контекстом останется за человеком. Тех, кто не адаптируется, ждет разорение. Компании уже поняли, что просто заменить людей ИИ недостаточно - им срочно понадобились специалисты, умеющие с ним работать эффективно.
#AI4SDLC #AI #Engineering #Software #Processes #Management #Productivity
Около месяца назад мы записывали подкаст вместе с Сергеем Барановым (основателем ArchDays) и Андреем Дмтриевым (со-основателем JUG.RU) в рамках подготовки к сегодняшней конфе AI Dev Conf. Так получилось, что дальше я уехал в отпуск и забыл поделиться с вами этим эпизодом, а он был интересным:) Речь в нем шла про то, как LLM и мультиагентные системы меняют software architecture и инженерные процессы. Обсудили двойственную природу ИИ: с одной стороны - демократизация разработки (через lovable.dev и аналоги), с другой - жесткая необходимость в инженерном фундаменте для масштабирования.
Основными темами выпуска стали
- От SOE 1.0 к SOE 2.0: как люди и агенты будут работать в связке.
- Роль архитектора: больше не "чертежник", а стратег, валидирующий варианты от ИИ и выстраивающий внутренние модели.
- Экономика: почему типовые решения уходят в автоматизацию, а ценность повторного использования компонентов взлетает до небес.
- Болевые точки: бардак с данными и онтологиями, блокирующие зависимости между сервисами и проблема контекста.
- Прогноз: как готовить платформу к "мажорной разработке" с агентами и почему локальные эксперименты с моделями станут базовым навыком архитектора.
В итоге: агенты научатся писать код, делать ревью и документацию. Но ставить цели, изобретать и управлять контекстом останется за человеком. Тех, кто не адаптируется, ждет разорение. Компании уже поняли, что просто заменить людей ИИ недостаточно - им срочно понадобились специалисты, умеющие с ним работать эффективно.
#AI4SDLC #AI #Engineering #Software #Processes #Management #Productivity
YouTube
AI Dev Podcast #2: Александр Поломодов, Сергей Баранов / Архитектура в эпоху ИИ
AI Dev Conf Podcast #2: Архитектура в эпоху ИИ — от хаоса к новой инженерной реальности
Гости выпуска: Сергей Баранов (продюсер ArchDays) и Александр Поломодов (технический директор в Т-Банке).
О чем поговорили:
Как LLM и мультиагентные системы меняют софт…
Гости выпуска: Сергей Баранов (продюсер ArchDays) и Александр Поломодов (технический директор в Т-Банке).
О чем поговорили:
Как LLM и мультиагентные системы меняют софт…
🔥7❤6👍4🥱1
No Drama - Color Lama (Рубрика #Brain)
Я давно замечал, что у меня лучше работает голова, если я размышления совмещаю с физическим действием. Именно поэтому я часто провожу one-on-ones, гуляя вокруг нашего офиса. Потом у нас в офисе в каждой переговорке добавили карандаши и листочки раскраски - мне эта идея понравилась и я купил себе набор раскрасок. Я использую их теперь на некоторых онлайн встречах или просто когда надо подумать о чем-то глубоко, а руки требуется занять чем-то. В итоге, получается этакая арт-терапия, которая мне помогает фокусироваться.
К посту прикрепил несколько раскрашенных картинок, что накопились за пару лет, что я практикую эту активность.
#Thinking #Brain #Books
Я давно замечал, что у меня лучше работает голова, если я размышления совмещаю с физическим действием. Именно поэтому я часто провожу one-on-ones, гуляя вокруг нашего офиса. Потом у нас в офисе в каждой переговорке добавили карандаши и листочки раскраски - мне эта идея понравилась и я купил себе набор раскрасок. Я использую их теперь на некоторых онлайн встречах или просто когда надо подумать о чем-то глубоко, а руки требуется занять чем-то. В итоге, получается этакая арт-терапия, которая мне помогает фокусироваться.
К посту прикрепил несколько раскрашенных картинок, что накопились за пару лет, что я практикую эту активность.
#Thinking #Brain #Books
🔥27😁8❤3⚡2
Почему AI делает инфраструктуру управленческой темой (Рубрика #AI)
Пару дней назад вышла статья РБК про то, почему бизнес выбирает гибридную инфраструктуру. В этом интервью РБК от 19 мая генеральный директор Yandex Cloud Григорий Атрепьев говорит, что рынок корпоративного ПО в России по итогам 2025 года вырос до 808 млрд руб., а два главных фактора изменения рынка сейчас - информационная безопасность и искусственный интеллект.
А сегодня я весь день преподаю в рамках программы ВШЭ “ИИ-лидеры: бизнес-лаборатория для руководителей” и рассказываю менеджерам про облака, DataOps, MLOps и AIOps. И эта статья отлично попадает в главный тезис моего рассказа: AI в компании начинается не с красивой демки модели. Он начинается с инфраструктуры, данных, безопасности, эксплуатации и управленческой готовности довести пилот до промышленного внедрения.
Если возвращаться к тезисам Григория из статьи то они примерно такие
1️⃣ Искусственный интеллект и информационная безопасность - это комбо-связка. С одной стороны, компании живут в более агрессивной среде: по словам Yandex Cloud, в прошлом году они обрабатывали 103 млрд событий ежедневно в собственной SIEM-системе, в три раза больше год к году. С другой стороны, AI уже перестал быть только экспериментом: на платформе, по данным компании, создано более 18 тыс. агентов.
2️⃣ Дальше начинается самое интересное для менеджеров. AI быстро превращается в инфраструктурную задачу. Растет спрос на GPU, по исследованию Yandex Cloud и Apple Hills Digital среднегодовой темп роста этого сегмента до 2030 года оценивается в 23%. Меняются требования к ЦОД: если раньше стойка могла потреблять 5-6 кВт, то сейчас для AI-нагрузок речь идет уже о 100 кВт и выше.
3️⃣ На этом фоне гибридная инфраструктура выглядит не как компромисс “между облаком и своим железом”, а как рабочая модель зрелой компании. Публичное облако дает скорость экспериментов, быстрые пилоты и гибкое потребление ресурсов. Частный контур нужен там, где есть чувствительные данные, регуляторные ограничения, требования ИБ и уже сложившиеся корпоративные системы.
4️⃣ Но гибридность не достается бесплатно. В статье хорошо перечислены барьеры: разные инструменты и навыки, Kubernetes, API, мониторинг, синхронизация, резервное копирование, безопасность. А с AI добавляется новый слой: нужно контролировать агентов в корпоративных системах, разграничивать доступ к данным, защищать протоколы и наблюдать цепочки действий. Observability становится не только темой SRE, но и темой управления AI-рисками.
В общем, управленческий вывод такой: AI-проекты чаще ломаются не на выборе или доступе к вашей любимой модели. Они начинаю буксовать на качестве данных, доступности инфраструктуры, отсутствии сильного бизнес-спонсора, непонятной модели ответственности и неспособности превратить пилот в повторяемый процесс. Поэтому менеджерам важно понимать не только "какую нейросеть купить". Важно понимать, какой контур данных, облаков, MLOps/AIOps, ИБ, мониторинга и эксплуатации нужен, чтобы AI не остался презентацией на несколько сотрудников, а стал частью корпоративной системы.
#AI #Cloud #DataOps #MLOps #AIOps #Management #Engineering
Пару дней назад вышла статья РБК про то, почему бизнес выбирает гибридную инфраструктуру. В этом интервью РБК от 19 мая генеральный директор Yandex Cloud Григорий Атрепьев говорит, что рынок корпоративного ПО в России по итогам 2025 года вырос до 808 млрд руб., а два главных фактора изменения рынка сейчас - информационная безопасность и искусственный интеллект.
А сегодня я весь день преподаю в рамках программы ВШЭ “ИИ-лидеры: бизнес-лаборатория для руководителей” и рассказываю менеджерам про облака, DataOps, MLOps и AIOps. И эта статья отлично попадает в главный тезис моего рассказа: AI в компании начинается не с красивой демки модели. Он начинается с инфраструктуры, данных, безопасности, эксплуатации и управленческой готовности довести пилот до промышленного внедрения.
Если возвращаться к тезисам Григория из статьи то они примерно такие
1️⃣ Искусственный интеллект и информационная безопасность - это комбо-связка. С одной стороны, компании живут в более агрессивной среде: по словам Yandex Cloud, в прошлом году они обрабатывали 103 млрд событий ежедневно в собственной SIEM-системе, в три раза больше год к году. С другой стороны, AI уже перестал быть только экспериментом: на платформе, по данным компании, создано более 18 тыс. агентов.
2️⃣ Дальше начинается самое интересное для менеджеров. AI быстро превращается в инфраструктурную задачу. Растет спрос на GPU, по исследованию Yandex Cloud и Apple Hills Digital среднегодовой темп роста этого сегмента до 2030 года оценивается в 23%. Меняются требования к ЦОД: если раньше стойка могла потреблять 5-6 кВт, то сейчас для AI-нагрузок речь идет уже о 100 кВт и выше.
3️⃣ На этом фоне гибридная инфраструктура выглядит не как компромисс “между облаком и своим железом”, а как рабочая модель зрелой компании. Публичное облако дает скорость экспериментов, быстрые пилоты и гибкое потребление ресурсов. Частный контур нужен там, где есть чувствительные данные, регуляторные ограничения, требования ИБ и уже сложившиеся корпоративные системы.
4️⃣ Но гибридность не достается бесплатно. В статье хорошо перечислены барьеры: разные инструменты и навыки, Kubernetes, API, мониторинг, синхронизация, резервное копирование, безопасность. А с AI добавляется новый слой: нужно контролировать агентов в корпоративных системах, разграничивать доступ к данным, защищать протоколы и наблюдать цепочки действий. Observability становится не только темой SRE, но и темой управления AI-рисками.
В общем, управленческий вывод такой: AI-проекты чаще ломаются не на выборе или доступе к вашей любимой модели. Они начинаю буксовать на качестве данных, доступности инфраструктуры, отсутствии сильного бизнес-спонсора, непонятной модели ответственности и неспособности превратить пилот в повторяемый процесс. Поэтому менеджерам важно понимать не только "какую нейросеть купить". Важно понимать, какой контур данных, облаков, MLOps/AIOps, ИБ, мониторинга и эксплуатации нужен, чтобы AI не остался презентацией на несколько сотрудников, а стал частью корпоративной системы.
#AI #Cloud #DataOps #MLOps #AIOps #Management #Engineering
👍7❤3🔥2🥱1
Atomic Heart. Предыстория «Предприятия 3826»: как строилась советская техноутопия до сбоя (Рубрика #SciFi)
Продолжая свое погружение в мир Atomic Heart, прочитал специальное издание "Atomic Heart. Предыстория «Предприятия 3826»" Харальда Хорфа, которая отличается цветными вставками и более плотной и белой бумагой от обычного издания. Про саму игру я уже рассказывал отдельно: для меня Atomic Heart оказался не просто шутером про роботов, а погружением в советскую техноутопию, где автономные системы, централизованное управление и вера в автоматизацию в какой-то момент начинают вести себя как большая распределенная система со сбойнувшим контуром управления (control plane). Также чуть раньше этого я разбирал сборник "Atomic Heart: Далёкое светлое будущее", который показывает мир до старта игры: витрины утопии, бытовых роботов, ощущение прогресса и тот самый момент, когда ты читаешь почти лог системы прямо перед тем, как все пошло по наклонной.
Но новая книга показалась мне еще интереснее - она расскрывает всю историю от открытия полимера Сеченовым до научного рывка, роботизации, инфраструктуры Предприятия 3826 и движения к "Коллективу 2.0". Это крепкая научная фантастика, а не просто справочник с описанием основых персонажей - здесь раскрывается история о том, как большая технологическая мечта постепенно становится системой. Книга добавляет к игре не столько факты, сколько логичную историю с набором причин и следствий, в конце которых мы понимаем как мы оказались на месте майора Нечаева и понимаем кто и как сгенерировал этот сбой. Но это же означает, что книга содержит спойлеры, а значит ее стоит читать уже после прохождения игры. В игре мы уже видим последствия сбоя: агрессивных роботов, закрытые комплексы, поломанный контур управления и странное ощущение, что красивые лозунги будущего обернулись инфраструктурной катастрофой. А здесь видишь, почему люди вообще могли поверить в такую систему. Почему она выглядела не опасной, а логичной, прогрессивной и почти неизбежной.
Это, кстати, хорошо дополняет мои предыдущие мысли про Atomic Heart. Большая автономная система опасна не потому, что роботы внезапно “злые”. Она опасна, когда масштаб, централизация, доступы, цели, governance и границы ответственности становятся частью архитектуры, но к ним относятся как к второстепенным деталям. В мире Atomic Heart это выглядит красиво: наука, заводы, полимер, роботы, коллективное будущее. Но инженерно ты все время видишь вопрос: а где план Б, observability, kill switch и независимый контур контроля?
Мне кажется, что как отдельная фантастическая книга эта предыстория зайдет не всем, но она понравится тем, кому уже интересен Atomic Heart или кто хотя бы примерно понимает мир игры. Она делает мир плотнее и понятнее. После нее Предприятие 3826 воспринимается не просто как декорация для шутера, а как большой технологический проект со своей логикой, идеологией и архитектурной ценой. В общем, если вам нравится Atomic Heart, советская техноутопия, автономные роботы и истории о том, как “идеальное будущее” постепенно превращается в систему с огромным радиусом сбоя, книгу можно смело брать.
#SciFi #Games #AtomicHeart #AI #Robotics #Architecture #SystemDesign
Продолжая свое погружение в мир Atomic Heart, прочитал специальное издание "Atomic Heart. Предыстория «Предприятия 3826»" Харальда Хорфа, которая отличается цветными вставками и более плотной и белой бумагой от обычного издания. Про саму игру я уже рассказывал отдельно: для меня Atomic Heart оказался не просто шутером про роботов, а погружением в советскую техноутопию, где автономные системы, централизованное управление и вера в автоматизацию в какой-то момент начинают вести себя как большая распределенная система со сбойнувшим контуром управления (control plane). Также чуть раньше этого я разбирал сборник "Atomic Heart: Далёкое светлое будущее", который показывает мир до старта игры: витрины утопии, бытовых роботов, ощущение прогресса и тот самый момент, когда ты читаешь почти лог системы прямо перед тем, как все пошло по наклонной.
Но новая книга показалась мне еще интереснее - она расскрывает всю историю от открытия полимера Сеченовым до научного рывка, роботизации, инфраструктуры Предприятия 3826 и движения к "Коллективу 2.0". Это крепкая научная фантастика, а не просто справочник с описанием основых персонажей - здесь раскрывается история о том, как большая технологическая мечта постепенно становится системой. Книга добавляет к игре не столько факты, сколько логичную историю с набором причин и следствий, в конце которых мы понимаем как мы оказались на месте майора Нечаева и понимаем кто и как сгенерировал этот сбой. Но это же означает, что книга содержит спойлеры, а значит ее стоит читать уже после прохождения игры. В игре мы уже видим последствия сбоя: агрессивных роботов, закрытые комплексы, поломанный контур управления и странное ощущение, что красивые лозунги будущего обернулись инфраструктурной катастрофой. А здесь видишь, почему люди вообще могли поверить в такую систему. Почему она выглядела не опасной, а логичной, прогрессивной и почти неизбежной.
Это, кстати, хорошо дополняет мои предыдущие мысли про Atomic Heart. Большая автономная система опасна не потому, что роботы внезапно “злые”. Она опасна, когда масштаб, централизация, доступы, цели, governance и границы ответственности становятся частью архитектуры, но к ним относятся как к второстепенным деталям. В мире Atomic Heart это выглядит красиво: наука, заводы, полимер, роботы, коллективное будущее. Но инженерно ты все время видишь вопрос: а где план Б, observability, kill switch и независимый контур контроля?
Мне кажется, что как отдельная фантастическая книга эта предыстория зайдет не всем, но она понравится тем, кому уже интересен Atomic Heart или кто хотя бы примерно понимает мир игры. Она делает мир плотнее и понятнее. После нее Предприятие 3826 воспринимается не просто как декорация для шутера, а как большой технологический проект со своей логикой, идеологией и архитектурной ценой. В общем, если вам нравится Atomic Heart, советская техноутопия, автономные роботы и истории о том, как “идеальное будущее” постепенно превращается в систему с огромным радиусом сбоя, книгу можно смело брать.
#SciFi #Games #AtomicHeart #AI #Robotics #Architecture #SystemDesign
❤11👍7🔥6🗿1
Root Cause: Stories and Lessons from Two Decades of Backend Engineering Bugs (Рубрика #Books)
Прочитал несколько глав книги Хусейна Нассера, популярного блоггера (500к подписчиков на канале), что рассказывает про software engineering. Брался я за нее из простого интереса почитать не просто про архитектуру, базы данных и распределенные системы, а скорее про то, как все это ломается на проде. Собственно, эти истории автор и обещает в описании своей книги. Автор считает, что опыт инженера измеряется не только годами, количеством фичей или строк кода, а количеством багов, которые он смог воспроизвести, отследить до root cause и исправить. Это звучит почти банально, пока не вспоминаешь, сколько настоящего инженерного знания приходит именно из таких расследований: где-то узнал, как браузер ограничивает HTTP/1.1 connections, где-то разобрался с HPACK в HTTP/2, где-то впервые увидел, как file descriptor limit превращается в 504 Gateway Timeout.
Мне эта книга напомнила опыт, когда я сам работал с инцидентами, писал или разбирал постмортемы, а также как-то руководил секций траблшутинга для SRE-инженеров, что хотели попасть к нам в компанию и в итоге сделал пару публичных выступлений и статей (они сейчас есть на моем сайте system-design.space: описание самого подхода к интервью и пример такого интервью).
Если же возвращаться к самой книге, то я прочел несколько глав и вот о чем они
1️⃣ История про системное замедление системы.
Пользователи видят, что весь продукт стал медленным. Не один endpoint, не одна кнопка, не один сценарий, а как будто “все плохо”. В итоге расследование приводит к маленькому UI-элементу: поисковая строка показывает текст вроде “Search 550M items”, а JavaScript дергает API, который выполняет SELECT COUNT(*) по огромной таблице. Причем делает это снова и снова. В трейсе обнаруживается больше 100 тысяч таких запросов за 30 минут.
Хорошая деталь здесь в том, что простой ответ “добавим CPU базе” был бы неправильным. Да, база была перегружена по CPU. Но причина была не в том, что база “слабая”, а в том, что продуктовый UI породил бессмысленную backend-нагрузку. Настоящее исправление — не вертикально масштабировать симптом, а убрать саму необходимость считать точное число там, где пользователю достаточно приблизительного.
2️⃣ Истории про live translation system, HTTP/1.1, HTTP/2 и load balancer
И это, кажется интересная часть для архитекторов и технических руководителей. Сначала long-lived SSE-сессии упираются в браузерный лимит соединений на один host: седьмой запрос просто висит в client-side queue. Потом включение HTTP/2 решает эту проблему, но приносит другую: много маленьких запросов, TLS, frame parsing, stream state и HPACK начинают съедать CPU на backend. Потом появляется load balancer, backend переводят обратно на HTTP/1.1, статические ресурсы кэшируются, все становится лучше — пока unlimited backend connection pool не упирается в file descriptors и TCP receive window.
То есть книга хорошо показывает неприятную, но реальную картину: архитектурное улучшение редко бывает “просто улучшением”. Оно меняет профиль отказов. HTTP/2 убирает один bottleneck, но добавляет CPU overhead. Load balancer разгружает backend, но приносит новые настройки и новые default values. Увеличение лимита file descriptors помогает, но не объясняет, почему столько соединений вообще было создано.
В общем, книга действительно неплохо описывает реальность траблшутинга проблемы по всему стеку и поиск root cause проблемы. Она будет полезна инженерам, кто хочет не просто рассказывать про крутую архитектуру, но и понимать как разные компоненты могут работать друг с другом, если что-то пойдет не так. В итоге, книга напоминает скорее инженерный блог по разбору инцидентов, чем обычный академический учебник и может быть полезна еще и SRE инженерам для подготовки к тем же собеседованиям.
#Books #Engineering #Software #Architecture #Management #SRE
Прочитал несколько глав книги Хусейна Нассера, популярного блоггера (500к подписчиков на канале), что рассказывает про software engineering. Брался я за нее из простого интереса почитать не просто про архитектуру, базы данных и распределенные системы, а скорее про то, как все это ломается на проде. Собственно, эти истории автор и обещает в описании своей книги. Автор считает, что опыт инженера измеряется не только годами, количеством фичей или строк кода, а количеством багов, которые он смог воспроизвести, отследить до root cause и исправить. Это звучит почти банально, пока не вспоминаешь, сколько настоящего инженерного знания приходит именно из таких расследований: где-то узнал, как браузер ограничивает HTTP/1.1 connections, где-то разобрался с HPACK в HTTP/2, где-то впервые увидел, как file descriptor limit превращается в 504 Gateway Timeout.
Мне эта книга напомнила опыт, когда я сам работал с инцидентами, писал или разбирал постмортемы, а также как-то руководил секций траблшутинга для SRE-инженеров, что хотели попасть к нам в компанию и в итоге сделал пару публичных выступлений и статей (они сейчас есть на моем сайте system-design.space: описание самого подхода к интервью и пример такого интервью).
Если же возвращаться к самой книге, то я прочел несколько глав и вот о чем они
1️⃣ История про системное замедление системы.
Пользователи видят, что весь продукт стал медленным. Не один endpoint, не одна кнопка, не один сценарий, а как будто “все плохо”. В итоге расследование приводит к маленькому UI-элементу: поисковая строка показывает текст вроде “Search 550M items”, а JavaScript дергает API, который выполняет SELECT COUNT(*) по огромной таблице. Причем делает это снова и снова. В трейсе обнаруживается больше 100 тысяч таких запросов за 30 минут.
Хорошая деталь здесь в том, что простой ответ “добавим CPU базе” был бы неправильным. Да, база была перегружена по CPU. Но причина была не в том, что база “слабая”, а в том, что продуктовый UI породил бессмысленную backend-нагрузку. Настоящее исправление — не вертикально масштабировать симптом, а убрать саму необходимость считать точное число там, где пользователю достаточно приблизительного.
2️⃣ Истории про live translation system, HTTP/1.1, HTTP/2 и load balancer
И это, кажется интересная часть для архитекторов и технических руководителей. Сначала long-lived SSE-сессии упираются в браузерный лимит соединений на один host: седьмой запрос просто висит в client-side queue. Потом включение HTTP/2 решает эту проблему, но приносит другую: много маленьких запросов, TLS, frame parsing, stream state и HPACK начинают съедать CPU на backend. Потом появляется load balancer, backend переводят обратно на HTTP/1.1, статические ресурсы кэшируются, все становится лучше — пока unlimited backend connection pool не упирается в file descriptors и TCP receive window.
То есть книга хорошо показывает неприятную, но реальную картину: архитектурное улучшение редко бывает “просто улучшением”. Оно меняет профиль отказов. HTTP/2 убирает один bottleneck, но добавляет CPU overhead. Load balancer разгружает backend, но приносит новые настройки и новые default values. Увеличение лимита file descriptors помогает, но не объясняет, почему столько соединений вообще было создано.
В общем, книга действительно неплохо описывает реальность траблшутинга проблемы по всему стеку и поиск root cause проблемы. Она будет полезна инженерам, кто хочет не просто рассказывать про крутую архитектуру, но и понимать как разные компоненты могут работать друг с другом, если что-то пойдет не так. В итоге, книга напоминает скорее инженерный блог по разбору инцидентов, чем обычный академический учебник и может быть полезна еще и SRE инженерам для подготовки к тем же собеседованиям.
#Books #Engineering #Software #Architecture #Management #SRE
❤8👍3🔥3👎1