Книжный куб

Microsoft Build 2025 | Satya Nadella Opening Keynote (Рубрика #AI) На прошлой неделе Сатья Наделла, CEO Microsoft, открывал большую конференцию MS Build интересным keynote докладом, в котором подключались гости в виде Сэма Альтмана, Илона Маска и других. И вот ключевые моменты, что были в его выступлении 1. GitHub Copilot как автономный агент GitHub Copilot эволюционировал в полноценного агентного помощника, способного самостоятельно выполнять задачи разработки: от добавления новых функций и исправления ошибок до рефакторинга и генерации документации. Он использует Model Context Protocol (MCP) для взаимодействия с внешними данными и инструментами, а также поддерживает мультимодальные входные данные, включая скриншоты и макеты. 2. Azure AI Foundry: более 1900 моделей и мультиагентная оркестрация Платформа Azure AI Foundry расширена до поддержки более 1900 моделей, включая интеграцию с Grok 3 от xAI. Она предоставляет инструменты для создания и управления мультиагентными системами, позволяя разработчикам строить сложные ИИ-приложения с высокой степенью кастомизации. 3. NLWeb: открытый протокол для агентного веба Представлен NLWeb — открытый протокол, позволяющий внедрять ИИ-интерфейсы на веб-сайты с минимальным кодом. Он поддерживает подключение к различным LLM и использует MCP для взаимодействия с контентом сайта, открывая путь к созданию "агентного интернета". 4. Windows AI Foundry: локальная разработка ИИ на Windows Новая платформа Windows AI Foundry предоставляет инструменты для локальной разработки, оптимизации и развертывания ИИ-моделей на Windows и macOS. Она поддерживает интеграцию с MCP и обеспечивает доступ к системным функциям, таким как файловая система и WSL. 5. Copilot Studio и настройка агентов Copilot Studio теперь позволяет создавать и настраивать ИИ-агентов, используя внутренние данные компании. Это включает в себя настройку поведения агентов, их взаимодействие с другими системами и поддержку мультиагентных сценариев. 6. Интеграция моделей Grok от xAI в Azure Microsoft объявила о партнерстве с xAI, предоставляя доступ к моделям Grok 3 и Grok 3 mini через Azure AI Foundry. Это расширяет выбор LLM для разработчиков и снижает зависимость от OpenAI. Именно на этой новости подключался Илон:) 7. Открытие исходного кода Windows Subsystem for Linux (WSL) Microsoft открыла исходный код ключевых компонентов WSL, включая wsl.exe и wslg.exe, под лицензией MIT. Это шаг к большей прозрачности и вовлечению сообщества в развитие инструмента. 8. MCP как стандарт взаимодействия MCP становится ключевым стандартом для взаимодействия ИИ-моделей с внешними данными и инструментами. Он обеспечивает унифицированный способ подключения моделей к различным источникам данных и системам, включая Windows и Azure. 9. Microsoft Discovery: платформа для научных исследований Представлена платформа Microsoft Discovery, использующая специализированных ИИ-агентов для управления научными исследованиями — от генерации гипотез до анализа результатов. Она предназначена для ускорения научных открытий и повышения эффективности исследований. Интересно, что у Google и OpenAI уже были такие платформы 10. Фокус на мультиагентных системах и их оркестрации Microsoft делает акцент на разработке мультиагентных систем, где агенты могут взаимодействовать друг с другом для выполнения сложных задач. Copilot Studio и Azure AI Agents Service предоставляют инструменты для создания таких систем с возможностью делегирования задач между агентами. Интересно, что после этого нас порадовал и Google со своей презентацией достижений народного хозяйства на Google I/O 2025 #AI #Software #Engineering

Harnessing the Universal Geometry of Embeddings (Рубрика #Security) Буквально на днях я выступал на PHDays, рассказывая про надежность и безопасность как фундаментальную часть наших систем, отмечая новые риски от AI. Вроде модель угроз была мне относительно понятна, но вчера читая канал Сергея Николенко Sinекура (@sinecor), наткнулся на рассказ про whitepaper "Harnessing the Universal Geometry of Embeddings", в котором авторы буквально разработали метод vec2vec для трансформации векторов из одного пространства представлений (embeddings) в другое. Сергей дальше в своем посте объясняет последствия

Ничего вроде бы сверхгениального в самом методе нету, но качество результата поразительное: на рис. 3 показано, как пять почти ортогональных друг другу векторов превратились в векторы со скалярными произведениями от 0.8 до 0.95. На практике это очень много чего значит, и в основном не очень хорошее. Получается, что базы данных, которые содержат векторные представления, надо защищать так же тщательно, как исходный текст (чего никто сейчас, насколько я понимаю, не делает). В одном эксперименте они взяли эмбеддинги корпоративных email'ов Enron, перевели их в пространство известной модели (рис. 4) и смогли извлечь чувствительную информацию (имена, даты, суммы) из 80% документов.

В общем, еще один интересный вектор атаки, только уже не на базы с оригинальными данными, а на векторные базы с embeddings. Может у меня дойдут руки и я почитаю этот whitepaper в ближайшее время:) P.S. Я подписался на канал Сергея Николенко после того, как написал отзыв на книгу "Глубокое обучение. Погружение в мир нейросетей" 2018 года, соавтором который был Сергей. Суть в том, что один из подписчиков канала сказал, что у автора есть прикольный tg-канал, я проверил - канал оказался действительно интересным и теперь я его иногда почитываю. Спасибо за эту рекомендацию! #Security #AI #Software #Engineering #Database #Data

Музей АТОМ (Рубрика #PopularScience) Были в прошлые выходные с детишками в музее "АТОМ", что на ВДНХ. Я был в полном восторге - постоянные экспозиции очень красивые и атмосферные. Интересно, что сам повильон не выглядит большим, но секрет в том, что он велик не в высоту, а в глубину, где и скрывается основная экспозиция, куда входят - Глава 1. Советский атомный проект - рассказ о временах второй мировой и послевоенного времени и о том, как развивалась советская атомная отрасль, как был достигнут ядерный паритет, сохранивший мир во второй половине ХХ века - Глава 2. Время первых - 1950–1960-е годы, в которые научно-техническая революция строилась вокруг изучения атомной энергии - Глава 3. Современная атомная промышленность - рассказ про современность, где много инсталляций, иллюстрирующих принципы работы современных ядерных реакторов Интересно, что помимо серьезных экспозиций в этом павильоне есть и детское пространство, где можно побегать, поиграть в настольный тенис, настольный футбол или почитать книжку в библиотеке. В общем, самое то, чтобы пройтись с семьей и посмотреть на достижения народного хозяйства:) #PopScience #Physics #Culture #Museum

AI и Platform Engineering (Рубрика #AI) Интересное выступление Игоря Маслова, VP of Coretech & Data в Т-Банке, на открытии конференции Platform Engineering Night, про которую я уже рассказывал. Игорь открывал конференцию и рассказал о том, как AI влияет на работу инженеров и развитие инженерных платформ. Основные мысли выступления примерно следующие 1. AI как усилитель существующих платформ Сейчас нужно "обмазывать" существующие инженерные сценарии AI - от создания пайплайнов до анализа телеметрии. В этом разрезе интересно глянуть whitepaper Google "Measuring Developer Goals", чтобы посмоттреть какие основные сценарии выделяет Google (я рассказывал о нем раньше), а также девятый выпуск "Research Insights Made Simple", в котором мы с коллегой Колей Бушковым разбирали whitepaper "What Do Developers Want From AI?" от ребят из Google 2. Когнитивная нагрузка и потеря навыков Игорь отмечает, что активное использование AI приводит к потере низкоуровневых навыков, но считает это нормальной эволюцией - условно, мало кто пишет на ассемблере и большая часть инженеров его уже не понимает и это никого не смущает. Примерно также мы будем писать код с ассистентами на условной Java и часть людей без ассистентов его уже не смогут написать/прочитать:) 3. Режим "копайлота" как базовый уровень Ответственность за финальный результат остаётся за человеком, что минимизирует риски "галлюцинаций" AI-моделей. Anthropic реализует эту философию в Claude, где модель действует как ассистент, а не замена разработчика. Такой подход особенно важен в критически важных системах, таких как финансы или здравоохранение, где ошибки AI недопустимы 4. Будущее: AI как платформенная инженерия В долгосрочной перспективе AI может стать основным интерфейсом для управления инженерными процессами, устраняя необходимость в традиционных инструментах. Это направление напоминает эволюцию Kubernetes, который стал стандартом для оркестрации контейнеров, но для AI аналогичный "момент" ещё не наступил 5. Vibe Coding и персонализированный софт Генерация кода под конкретные бизнес-кейсы или индивидуальные потребности пользователей — ключевой тренд. Однако, как предупреждает Игорь, подобные системы требуют тщательной валидации, чтобы избежать проблем с поддерживаемостью кода 6. Разгрузка разработчиков от рутины 80% экспериментальной работы можно автоматизировать, освободив время для более важных задач. OpenAI's Code Interpreter позволяет итеративно решать сложные задачи программирования и анализа данных. 7. ML-платформы: гибкость и готовность к изменениям Инвестиции в ML-платформы оправданы, но требуют готовности к технологическим сдвигам. Например, переход от традиционных нейросетей к трансформерам в 2020-х потребовал полного пересмотра инфраструктуры у большого количества компаний. Спикер подчёркивает, что платформы должны сохранять модульность, чтобы адаптироваться к новым алгоритмам и аппаратным решениям 8. Отсутствие "момента Kubernetes" в AI Пока нет универсального стандарта для AI-платформ, и стоит дождаться его появления. Каждая компания развивает свои подходы: OpenAI с Agents SDK, Anthropic с фокусом на безопасность, Google с комплексными AI решениями. 9. Высокорискованная природа current AI R&D Современные AI-решения требуют больших ресурсов и подходят в основном крупным компаниям. Это подтверждается масштабными инвестициями OpenAI, Google и Microsoft в платформенные решения. 10. Постепенный подход к внедрению Рекомендация: начинать с улучшения инструментов, но пока воздержаться от сложных low-code процессов. Anthropic следует схожей философии, предоставляя мощные модели с акцентом на контролируемое внедрение. В общем, у Игоря получилось отличное выступление с основной мыслью о том, что AI-революция в платформенной инженерии неизбежна, но нужен взвешенный подход с фокусом на постепенное улучшение существующих процессов, а не радикальную замену. #Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

ЦСКА - Пари НН (Рубрика #Family) С сыном выбрались на финальный матч ЦСКА в этом сезоне РПЛ. Будем болеть за ребят, чтобы они смогли финишировать третьими, благо все в ногах футболистов ЦСКА:)

Обложка и немного иллюстраций из книги "Критическое мышление. Железная логика на все случаи жизни"

Критическое мышление. Железная логика на все случаи жизни (Рубрика #Thinking) Эта книга Никиты Непряхина и Тараса Пащенко, позиционируется как практическое руководство для подростков, стремящихся развить навыки мышления. Моя жена купила его для детишек, а я решил прочитать и оценить как детей учат анализировать информацию, отличать факты от мнений, противостоять манипуляциям и принимать обоснованные решения. Изложение очень доступное, используются примеры из повседневной жизни. В книге рассматриваются следующие темы 1. Распознавание стереотипов и когнитивных искажений. На примерах из школьной жизни объясняется, как социальные шаблоны влияют на восприятие реальности. 2. Механизмы формирования суеверий и мифов. Разбираются психологические причины веры в иррациональное, включая эффект подтверждения и склонность к упрощённым объяснениям. 3. Влияние общественного мнения на принятие решений. Анализируются случаи конформизма и группового мышления, актуальные для подростковой среды. 4. Разграничение фактов и оценочных суждений. Приводятся критерии верификации информации, такие как проверка источников и поиск доказательств. 5. Логические основы аргументации. Обсуждаются структура умозаключений, типы аргументов и распространённые логические ошибки. 6. Практика принятия решений. Предлагаются алгоритмы взвешенного выбора в условиях неопределённости, включая анализ рисков и последствий. Все эти темы разбираются в рамках отдельных историй, которые основаны на реальных ситациях: конфликт с родителями, выбор подарка, выбор профессии, магическое мышление. Это позволяет не просто читать теорию, а попробовать применить ее на практике. Авторы так прорабатывают важные концепции - Когнитивные искажения - например, эффект ореола, предвзятость подтверждения - Структура аргументации - тезис, аргументы, контраргументы - Критерии достоверности информации - проверяемость, источник, контекст. Практическую направленность книги подтверждает то, что каждая глава содержит - Кейсы для анализа. Читателям предлагается оценить ситуации, подобные тем, с которыми они сталкиваются в школе или соцсетях. - Упражнения-тренажёры. Например, задание на классификацию суждений («факт vs мнение») или построение логических цепочек. - Чек-листы и алгоритмы. Готовые схемы для проверки информации, принятия решений и аргументации. Итого, эта книга может стать хорошей стартовой точкой для развития критического мышления для читателей старше 12 лет (возвраст указан в книге). Она особенно полезна в образовательном контексте — для уроков по логике, факультативов или семейного чтения. Для углублённого изучения темы стоит дополнить её академическими источниками, но в качестве практического руководства она выполняет свою задачу на отлично. P.S. Я уже раньше делал подборку книг про системное и критическое мышление, многие из которых хорошо подойдут в качестве продолжения к этой книге:) #Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership

[3/3] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #Architecture) Интересно, что уже появилась запись вчерашнего выступления на PHDays, о котором я рассказывал в прошлых постах: 1 и 2. В общем, теперь можно не только прочитать про выступление, но и посмотреть его. Если есть комментарии или вопросы, пишите в комменты под постом, я вечером постараюсь ответитьь. #SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

[2/2] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #Architecture) Продолжая рассказ о моем выступлении на PHDays, поделюсь оставшейся частью тезисов и материалов. В прошлом посте я закончил рассказом о примерах из западных bigtech компаний, а дальше я хотел рассказать немного о том, как это устроено у нас в Т, а также дать советы как сделать у себя надежность и безопасность фундаментальной частью разработки, а не опцией:) Ну и начнем мы с того, что у нас внутри компании есть developer ecosystem, которая представлена PaaS платформой Spirit, которая состоит из большого количества составляющих. Но начать надо с принципов, которым ребята следуют при создании платформы

— Повторяемость и прозрачность жизненного цикла кода в рамках процессов поставки. Код проходит одни и те же стадии: написание, сборка, разные формы тестирования, обновление документации, выкатка в среды, контроль качества после выкатки, поддержка и вывод из эксплуатации. Важно, чтобы любой разработчик мог понять, что происходит и какие стадии процесса ему нужно пройти. — Управление кодовой базой и оценка ее качества на всех этапах. Качество кодовой базы — одна из главных характеристик технического продукта. Умение держать его на стабильно высоком уровне — показатель устойчивости и зрелости процессов разработки. — Переход к Inner Source в компании. Переиспользование кода и наработок коллег — большой плюс для компании. Это помогает уменьшить стоимость разработки и увеличить скорость поставки бизнес-фич. Платформа должна помогать шерить код быстро и безболезненно. — Ориентация на результат. Когда у разработчика есть все необходимые инструменты для управления жизненным циклом продукта, это экономит массу времени. Становится проще создавать новые фичи и чинить старые, запускать тесты и многое другое. Мы хотим, чтобы разработчики могли тратить на создание бизнес-фич 80% рабочего времени, не отвлекаясь на рутину и сложности инфраструктуры. В конечном итоге от этого выигрывают пользователи.

Составляющие платформы представлены на схеме, но если отмечать некоторые особо важные для надежности и безопасности, то это - Sage - observability платформа, использующаяся для централизованного сбора и анализа телеметрии всех сервисов компании. Sage обеспечивает прозрачность бизнес-приложений и ИТ-инфраструктуры и помогает поддерживать бесперебойность работы сервисов. - FineDog - платформа инцидент-менеджмента, которая помогает Т-Банку оперативно выявлять сбои в работе сервисов, сокращать время их устранения и предотвращать повторение одинаковых инцидентов. - Nestor - copilot для code suggest и чата внутри IDE, а также других инструментов около кода и не только. - Safeliner - это AI-ассистент по информационной безопасности для команд разработки, который может работать как внутри шагов CI/CD, так и быть интегрирован в IDE в качестве плагина. Одновремено, надо отметить, что ребята из Spirit активно работают над темой developer experience и они про это рассказывали в докладе "Почему DevEx важен при разработке IDP и как его померить" (я про него рассказывал). Это позволяет им собирать метрики инженерного опыта и определять, а что внутри платформы требует улучшений. Но это конечно здорово иметь уже зрелую платформу и выстроенные процессы вокруг надежности и безопасности, а что делать если такого в вашей компании нет? Для изменений надо - На уровне стратегии компании сделать эти вопросы приоритетными, определиться с понятными целями (и поставить их в OKR), согласовать выделение ресурсов - На уровне культуры компании сделать так, чтобы security & reliability стали общей ответственностью команд - На уровне архитектуры и проектирования учитывать эти архитектурные характеристики и использовать лучшие практики - На уровне процессов они должны быть интегрированы в pipelines (devsecops и shift left) Ну и все этим надо управлять как большим проектом изменений, используя change mgmt подходы #SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

[1/2] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #Architecture) Сегодня я выступаю на конференции Positive Hack Days в Лужниках с заявленной выше темой. А тут я напишу тезисы и дам отсылки к дополнительным источникам 1) Почему стоит обсуждать эти темы сейчас - Средняя стоимость сбоев растет и сейчас стоит порядка $300k/hour - подробнее в отчете "Hourly Cost of Downtime - ITIC 2024" (вот мой рассказ) - Средняя стоимость утечек данных растет и стоит примерно $5M/breach - подробнее в отчете "IBM Cost of a Data Breach Report 2024" (вот мой рассказ в 2 частях: 1 и 2) - Средняя сложность систем растет (облака, микросервисы, быстрые изменения) - все это приводит к тому, что надежность и безопасность обеспечивать становится сложнее 2) Почему это надо обсуждать на уровне системы и процессов (эмерджентность) - Про это очень хорошо написано в whitepaper “Developer productivity for Humans: Software Quality” от ребят из Google (я уже рассказывал о нем). Суть в том, что для получения качественного продукта надо правильно выстроить процесс (условно, хочешь хорошую колбасу на мясокомбинате, то будь добр выстроить процессы с учетом ISO 9000). Это верно и для разработки и тут мы гонимся за эмерджентными свойствами (хорошая архитектура, надежность, безопасность), то есть за теми свойствами системы в целом, которые не присутствуют ни в одном из ее отдельных компонентов, но возникают в результате взаимодействий и отношений между этими компонентами. Подробнее про эмерджентность рекомендую почитать в Wiki, а также в кинге физика Девида Дойча "The Fabric of Reality: The Science of Parallel Universes" ("Структура реальности"), о которой я писал раньше 3) Подходы к надежности и безопасности - Надежность популяризировал Google через культуру SRE - есть три ключевые книги: "SRE Book", "SRE Workbook", "Building Secure & Reliable Systems", о которых я уже тоже рассказывал - Безопасность двигалась в сторону DevSecOps и Security by Design, где первое хорошо раскрывалось в давней книге "Agile Application Security" (я уже рассказывал про нее), то второе хорошо раскрыто в whitepaper "Security by Design at Google", который я тоже разбирал. Суть всей истории, чтобы безопасность сдвигалась влево и была интегрирована в процессы разработки 4) Подходы к архитектуре и проектированию решений - ATAM (architecture tradeoff analysis method) - хороший подход к проектированию решений от Software Engineering Institute (SEI), который в том или ином виде часто используется при проектировании для снижения рисков. В этом подходе у нас есть целевые функциональные сценарии, сопутствующие им архитектурные характеристики, которые часто влияют друг на друга и нам требуется принимать решения о компромиссах между ними. Вообще, про этот подход есть хороший рассказ в книге "Software Architecture for Busy Developers", про которую я рассказывал. Кроме того для учета рисков часто используют подход с построением матрицы рисков - А для учета рисков безопасности в дизайне хорошо бы использвать threat modeling. В итоге, у нас из ATAM есть не только функциональные сценарии, что нам надо реализовать в системе, но еще есть из Threat modeling сценарии угроз, которые надо предотврать 5) Case studies от лидеров индустрии - Google - про него я много рассказывал и в контексте SRE и Secure by Design, но тут разве что добавлю их motto: "Hope is not a strategy", а также вспомню, что для проверки того, что все учтено на этапе проектирования у них есть design review процесс, про который они рассказывали в whitepaper "Improving Design Reviews at Google" (вот мой обзор) - Netflix сделал ставку на хаос (Chaos Monkey и далее), чтобы обеспечивать resilience своим системам. Подробнее можно почитать книгу "Chaos Engineering", про которую я писал - Amazon выбрала себе слоган "At Amazon, security is job zero", вот, например, раздел про культуру безопасности на сайте AWS Продолжение в следующем посте, так как в один все не влезло:) #SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

Code of Leadership #38 - Interview with Dmitry Kotelnikov about origination platform and reliability (Рубрика #Management) В очередном выпуске подкаста ко мне пришел интересный гость, Дмитрий Котельников, с которым мы обсудили origination процессы и вопросы обеспечения их надежности. Дима работает в Т-Банке уже 8 лет и все это время занимается онбордингом новых клиентов, а сейчас руководит платформой Origination, а также развивает RnD направление AI миграций и участвовал в запуске стрима Staff инженеров, о которых мы как-то говорили в выпуске с моим коллегой Лешей Тарасовым https://www.youtube.com/watch?v=f_lHUOT9Ig0 За час мы успели обсудить следующие темы - Знакомство с гостем - Выбор университета и развитие навыков - Начало карьеры и первые рабочие задачи - Архитектурные изменения и рост компании - Развитие инфраструктурных инструментов - BPM и сложности бизнес-процессов - Надежность, интеграции и инструменты мониторинга - Структура платформы origination - Технические аспекты и общие компоненты платформы - Управление потребностями продуктов и вызовы платформы - Переход от инженера к менеджеру и рекомендации для развития Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

Почему ваша амбициозность в Европе может обернуться одиночеством | Евгений Кот (Рубрика #Culture) Интересное интервью, что дал Евгений Кот Кириллу Мокевнину в рамках подкаста Кирилла. Ребята говорили о культурном коде в мире IT. Евгений много выступал на конференциях до того, как уехал в Прагу в качестве директора по инжинирингу во Wrike. Сейчас Евгений является VP of Engineering в стартапе rarible.com про NFTs, а также о ведет подкаст "Доктор Кот". Темой выпуска стали культурные различия в IT-индустрии и их влияние на карьеру разработчика. Вот основные 10 ключевых тем 1) Культурный код отличается в разных странах, поэтому важно адаптироваться к локальным культурным особенностям для успешного взаимодействия. Рекомендую почитать книгу "The Culture Map", про которую я рассказывал раньше 2) Языковой барьер и акцент — несовершенное владение языком влияет на профессиональное восприятие и нервную систему специалистов, а также способы адаптации к этой проблеме. 3) Важность софт-скиллов в разных странах — обсуждение важности "мягких навыков" в США, Европе и России, с акцентом на то, что дело не в "правильности", а в культурных особенностях. 4) Токсичность и культурные различия в IT — ребята обсудили сравнение проявлений токсичности в разных IT-культурах: в России — прямолинейность, на Западе — токсичность часто скрывается за формальностями. 5) Культурные подходы к увольнениям — В США увольнения часто происходят моментально, в то время как в Европе процесс более формализован и занимает больше времени. 6) Амбиции и работа в Европе — амбициозным специалистам бывает сложно реализоваться в Европе, где ценится стабильность и баланс работа-жизнь. 7) Принятие решений и эскалация конфликтов — ребята обсудили различные модели решения рабочих конфликтов: прямое обсуждение vs эскалация через менеджмент. 8 ) Дебаты и их важность для экспертов — тут пошла речь о культуре публичных выступлений и дебатов, которую в США развивают с детства, и как это влияет на профессиональный успех. 9) Воспитание и культурные установки — детство и воспитание в разных странах влияет на профессиональное поведение и способность к интеграции в международных командах. 10) Возрастные программисты и стигма — как отношения к возрастным разработчикам в разных странах и как с возрастом меняется отношение к программированию. Если подводить итог, то это интервью стоит посмотреть, если хочется чуть шире взглянуть на мультикультурные вопросы, которые Кирилл и Евгений рассказывают не просто теоретически, а делятся своими историями и байками из опыта работы в IT в других странах. #Culture #Management #Leadership #Engineering

Обложка книги "Разработка Высоконагруженных Систем" и немного картинок из нее. P.S. Отнес книжку на booksharing полку в нашей компании (она на 7 этаже в нашем офисе T-Space). Думаю, что она там как раритет отлично будет смотреться, а кто-то интересующийся историей ее даже сможет найти:)

Разработка Высоконагруженных Систем (Рубрика #Architecture) Нашел на своей полке старенькую книгу издательства Олега Бунина, с которой началось мое знакомство с высоконагруженными системами. Эта книга является сборником материалов по итогам конференций HighLoad++ 2010-2011 годов, изданный в 2012 году. Официально она приписывается коллективу авторов, а Олег Бунин выступил в качестве издателя и составителя. Книга насчитывает 400 страниц и представляет собой попытку не просто описать технические характеристики крупных систем, а изложить принципы построения архитектур самых передовых и посещаемых интернет-проектов того времени. Книга фокусируется на принципах проектирования архитектуры высоконагруженных систем и практических аспектах их реализации, опираясь на опыт реальных проектов, представленных на конференциях HighLoad++. Книга начиналась с базового учебника, который включал следующие уроки 1) Первый урок, что содержал рассказ про монолитные приложения и сервис-ориентированную архитектуру, про ремесленный и промышленный подход к разработке нагруженных приложений, про вертикальное и горизонтальное масштабирование приложений, про трехзвенную архитектуру 2) Второй урок про масштабирование фронендов, что содержал обсуждение раздачи статики, кеширования, логику на фронте/беке, масштабирование бекендов и работу со всплесками трафика, про балансировку запросов на фронтенд при помощи DNS 3) Третий урок про маштабирование бекенда, где авторы говорили про функциональное разделение бекенд сервисов для масштабирования, про горизонтальное масштабирование и важность низкой связности кода (видимо, low coupling), shared nothing подходов, layered architecture. Также тут опять шла речь про кеширование, инвалидацию и прогрева кеша 4) Четвертый урок с масштабированием во времени, где речь шла про асинхронность и отложенные вычисления, использование очередей, немного про консистентность данных. Здесь был пример проектирования ленты соцсети, где эти подходы можно было использовать 5) Пятый урок про базы данных, где авторы рассказывают про разные типы баз данных, тюнинг запросов, шардинг, репликацию, кластеризацию и денормализацию, а также про хранимые процедуры. В общем, в то время книга для меня была полезной, но сейчас она скорее исторический документ. А если хочется почитать чего-то актуального, то стоит взять книгу Мартина Клеппмана "Высоконагруженные приложения", особенно с учетом того, что Мартин пишет второе издание книги. #DistributedSystems #Architecture #SystemDesign #Software #SoftwareArchitecture

[2/2] Cost of a Data Breach Report 2024 (Рубрика #Security) Продолжая рассказ про отчет об утечках, хочется поделиться выводами из него - Усиление финансового давления. Рост стоимости утечек данных создает значительное финансовое давление на бизнес. Организации должны учитывать эти риски в своих финансовых моделях и бюджетах на безопасность. - Безопасность становится фактором конкурентоспособности. Поскольку компании перекладывают расходы на утечки на потребителей, инвестиции в кибербезопасность могут стать конкурентным преимуществом, позволяющим удерживать более низкие цены для клиентов. Это интересный взгляд на возврат инвестиций (ROI) в безопасность - Необходимость внедрения ИИ. Значительная экономия при использовании технологий искусственного интеллекта указывает на необходимость ускорения внедрения этих решений в процессы обеспечения безопасности. Интересно, что сейчас AI активно внедряют во все этапы SDLC (software development life cycle), так что безопасность тут не является белой вовроной - Приоритизация защиты учетных данных. Учитывая, что утечки, связанные с учетными данными, обнаруживаются и устраняются дольше всего, организациям следует уделять особое внимание защите паролей и многофакторной аутентификации. - Управление данными как часть стратегии безопасности. Проблема "теневых данных" указывает на необходимость более строгого управления данными и их классификации как неотъемлемой части стратегии кибербезопасности. В принципе, сейчас тема более качественной работы с данными является модной, так как это является пререквизитом для эффективного использования ML и AI - Замкнутый цикл киберинцидентов. Как отмечает вице-президент IBM Security Кевин Скапинец, "Бизнес оказывается в непрерывном цикле утечек, сдерживания и реагирования", что приводит к постоянным инвестициям в усиление защиты и перекладывание расходов на потребителей.

Businesses are caught in a continuous cycle of breaches, containment and fallout response. This cycle now often includes investments in strengthening security defenses and passing breach expenses on to consumers – making security the new cost of doing business.

В общем, этот отчет от IBM подтверждает, что кибербезопасность становится не просто технической необходимостью, но и важнейшим элементом бизнес-стратегии, напрямую влияющим на финансовую устойчивость и конкурентоспособность современных организаций. #Security #Software #AI #SRE #Architecture #Management

[1/2] Cost of a Data Breach Report 2024 (Рубрика #Security) Изучил интересный отчет 2024 года по утечкам данных, который был подготовлен компанией IBM в сотрудничестве с Ponemon Institute. IBM знают все, а вот пр Ponemon Institute стоит рассказать - это независимая исследовательская организация, специализирующаяся на вопросах приватности, защиты данных и информационной безопасности. Для создания отчета исследователи изучили 604 организации, пострадавшие от утечек данных в период с марта 2023 по февраль 2024 года. В исследование вошли компании из 17 отраслей в 16 странах и регионах. Масштабы рассмотренных инцидентов варьировались от 2 100 до 113 000 скомпрометированных записей. Для получения информации из первых рук аналитики Ponemon Institute провели интервью с 3 556 специалистами по безопасности и руководителями C-уровня, имевшими непосредственное отношение к инцидентам. Данному отчету можно доверять по нескольким причинам: - Это 19-й ежегодный отчет такого рода, что указывает на устоявшуюся методологию и возможность отслеживать долгосрочные тенденции. - Изучено 604 организации разных размеров и отраслей, что обеспечивает репрезентативность выборки. - IBM и Ponemon Institute используют четкую методологию для расчета стоимости утечки данных, учитывающую различные факторы, включая затраты на обнаружение утечки, уведомление пострадавших, меры реагирования и упущенную прибыль. - Хотя отчет спонсируется IBM, само исследование проводится независимо Ponemon Institute, что снижает вероятность предвзятости результатов. - Отчет включает подробное рассмотрение различных аспектов утечек данных, включая первоначальные векторы атак, время обнаружения, влияние технологий и многое другое. Основные результаты исследования 1) Рост стоимости утечек данных Средняя стоимость утечки данных в 2024 году достигла рекордной отметки в 4,88 миллиона долларов США, что на 10% больше по сравнению с прошлогодним показателем в 4,45 миллиона долларов. Это самый значительный рост с периода пандемии. Увеличение стоимости обусловлено несколькими факторами: - Рост затрат на устранение операционных простоев - Увеличение финансовых потерь из-за оттока клиентов - Повышение расходов на обеспечение работы служб поддержки клиентов - Рост сумм регуляторных штрафов 2) Влияние ИИ и автоматизации Две трети исследованных организаций сообщили о внедрении технологий искусственного интеллекта и автоматизации в своих центрах операционной безопасности, что на 10% больше по сравнению с предыдущим годом. Организации, широко использующие ИИ в процессах предотвращения угроз в среднем экономят 2,2 миллиона долларов на расходах, связанных с утечками, по сравнению с организациями, не использующими ИИ в этих процессах. 3) Жизненный цикл инцидентов Утечки, связанные с украденными учетными данными, требуют наибольшего времени для обнаружения и устранения - в среднем 292 дня. Фишинговые атаки занимают в среднем 261 день, а атаки с использованием социальной инженерии - 257 дней. 4) Типы скомпрометированных данных - Почти половина всех утечек (46%) затрагивала персональные данные клиентов, включая налоговые идентификаторы, электронные адреса, телефонные номера и адреса проживания. - На втором месте оказались записи интеллектуальной собственности (43% утечек). При этом стоимость одной скомпрометированной записи интеллектуальной собственности выросла до 173 долларов с прошлогодних 156 долларов. 5) Проблема "теневых данных" Более трети (35%) утечек затрагивали "теневые данные" - информацию, хранящуюся в неуправляемых источниках данных. Кража "теневых данных" коррелирует с увеличением стоимости утечки на 16%. 6) Бизнес-последствия Более 70% организаций сообщили о значительных или очень значительных сбоях после утечек данных. Более половины организаций перекладывают возросшие расходы на утечки на своих клиентов через повышение цен на товары и услуги. Выводы из отчета будут в следующем посте. #Security #Software #AI #SRE #Architecture #Management

Hourly Cost of Downtime - ITIC 2024 Hourly Cost of Downtime Survey Results (#SRE) В рамках подготовки к своему выступлению на конференции Positive Hack Days в Лужниках, наткнулся на короткий отчет 2024 про стоимость часа даунтайма от ITIC. Так как я первый раз услышал про эту компанию, то решил чекнуть насколько можно доверять компании, автору отчета и самому отчету - Сама компания оказалась независимой и исследовательской консалтинговой фирмой, основанной в 2002 году, которая специализируется на проведении первичных исследований по широкому спектру технологических тем для вендоров и корпоративных клиентов. - Автором исследования является Лаура ДиДио (Laura DiDio), имеющая более 25 лет опыта в сфере высоких технологий - Самому исследованию можно доверять, так как это 11 ежегодный отчет, проведенный как независимое веб-исследование, в котором приняли участие более 1000 компаний по всему миру в период с ноября 2023 по март 2024 года. Причем в исследовании принимали участие компании разных размеров: 27% составляли малые/средние предприятия (до 200 пользователей), 28% – средние предприятия (201-1000 пользователей), и 45% – крупные предприятия (более 1000 пользователей). Основные результаты исследования следующие 1) Увеличение стоимости простоев Исследование показывает, что стоимость простоев продолжает расти. Средняя стоимость одного часа простоя теперь - превышает $300k для более чем 90% средних и крупных предприятий - превышает $1mln для 41% компаний Но это средние оценки стоимости сбоев, а в худших случаях (аля при катастрофических сбоях) потери могут кратно расти. Эти цифры не включают стоимость судебных разбирательств, штрафов или гражданских или уголовных санкций, связанных с нарушениями нормативных требований. 2) Причины простоев Security и человеческие ошибки являются главными виновниками простоев. Согласно опросу, 84% респондентов назвали проблемы безопасности главной причиной простоев, за ними следуют человеческие ошибки (69%) и программные недостатки (65%). 3)Требования к доступности Данные опроса показывают, что 90% организаций теперь требуют минимальной доступности 99,99% (так называемые "четыре девятки"). Это достаточно жесткие требования, которые разраешает меньше часа недоступности в год. Выводы из результатов исследования следующие: 1) Экономические последствия в нашу эпоху взаимосвязанных систем, что работают 24 на 7 приводят к тому, что организации всех размеров не толерантны к сбоям. Простои даже на несколько минут приводят к остановке бизнеса и производительности, негативно влияют на надежность и безопасность, а также подвергают компании более высокому риску в отношении соблюдения нормативных требований, а также гражданских и даже уголовных штрафов. 2) Для регулируемых отраслей, таких как банковское дело и финансы, энергетика, правительство, здравоохранение, гостиничный бизнес, производство, СМИ и коммуникации, розничная торговля, транспорт и коммунальные услуги, необходимо учитывать потенциальные потери, связанные с судебными разбирательствами. Для отдельных организаций, чей бизнес основан на интенсивной работе с данными, таких как фондовые биржи, убытки могут исчисляться миллионами долларов в минуту. 3) Для малого и среднего бизнеса затраты на простои не настолько велики, но у них обычно нет больших бюджетов и резервных фондов своих корпоративных коллег для покрытия финансовых потерь или потенциальных судебных разбирательств, связанных с простоями. В итоге, если обобщать, то оценки из этого отчета можно использовать как начальные ориентиры для стоимости простоев. Особенно это может быть полезно, если вам надо аргументировать важность работы над надежностью ваших систем пока у вас нет точной статистической модели, которая точнее оценит стоимость простоев именно для ваших процессов и ваших систем. P.S. Если у вас есть похожие отчеты, заслуживающие изучения, то накидайте их в комментах - я их тоже внимательно изучу. #SRE #DevOps #Architecture #Software #Processes #Metrics #Engineering

От стартапа до международного бизнеса: история VictoriaMetrics и её уроки (Рубрика #Engineering) Недавно в подкасте Кирилл Мокевнин побеседовал с Александром Валялкиным, сооснователем и core-разработчиком VictoriaMetrics - одного из самых популярных инструментов для мониторинга, который успешно конкурирует с Prometheus. Я посмотрел это интервью с большим интересом и мне понравилось как Александр рассказывал о своем пути от крутого инженера к создателю своего бизнеса. Вот основные идеи этого интервью 1. Путь от разработчика к предпринимателю. Александр поделился своим опытом трансформации из программиста в основателя успешного IT-бизнеса, рассказал о первых ошибках и извлеченных уроках 2. Проблемы Prometheus и рождение VictoriaMetrics. В 2016-2017 годах команда Александра столкнулась с ограничениями Prometheus при масштабировании, что в итоге привело к идее создания собственного решения 3. Технические преимущества Go для баз данных. Go позволяет легче писать и оптимизировать базы данных, снижая порог входа и упрощая работу. Профилировщики в Go помогают точечно оптимизировать только необходимые 2% кода 4. Инженерное мышление vs бизнес-подход. Инженерное мышление часто бывает наивным, но оно - двигатель бизнеса. Автор объяснил, почему техническому специалисту важно развивать бизнес-мышление 5. Маркетинг технического продукта. Долгосрочное взаимодействие с пользователями требует не только маркетинга, но и качественного продукта. Александр рассказал, как их контент-маркетинг на Medium и Hacker News оказался эффективнее платной рекламы 6. Open Source как стратегия развития. После перевода VictoriaMetrics в Open Source проект начал активно развиваться, привлекая новых пользователей и улучшая продукт благодаря сообществу 7. Enterprise-контракты vs SaaS. Несмотря на популярность SaaS-модели среди инвесторов, Enterprise-контракты оказались более прибыльными для бизнеса VictoriaMetrics 8. Упрощение сложных технологий. Важность создания простых в использовании продуктов, которые "просто работают" из коробки. Victoria Metrics автоматически масштабируется под доступные ресурсы без сложной настройки 9. Развитие и расширение продуктовой линейки. История создания Victoria Logs - дополнительного продукта для обработки логов, который возник на основе запросов пользователей и показал лучшие результаты в бенчмарках 10. Органический рост и команда. Компания выросла до 40 сотрудников без внешних инвестиций, нанимая инженеров, уже имеющих опыт работы с их продуктом, что позволяет избегать сложных процессов найма Интервью может быть интересно тем, кто интересуется технологиями мониторинга, бизнесом на open source или созданием собственного технологического продукта. P.S. Кстати, я уже раньше рассказывал о документальном фильме про Prometheus, который тут упоминается как продукт, с которого люди мигрируют на VictoriaMetrics #Kubernetes #Film #Documentary #Software #Architecture #DistributedSystems #SRE

Обложки книг "Все формулы мира"

Все формулы мира (Рубрика #PopularScience) Прочитал с большим удовольствием эту книгу Сергея Боброва, современного российского астрофизика, популяризатоар науки,который известен своим умением объяснять сложнейшие концепции физики и математики на доступном, живом языке. Собственно, эта книга написана живым языком и является приглашением взглянуть на математику не как на скучный набор уравнений, а как на универсальный язык природы и инструмент для проникновения в самую суть физических явлений. Сергей показывает, что математические методы не только позволяют строить мосты и запускать спутники, но и лежат в основе самых смелых теорий о рождении Вселенной, черных дырах и квантовых эффектах. . Книга разделена на 4 части и приложения 1) Новый язык В первой части Бобров объясняет, почему математика - это не просто инструмент, а новый язык для описания природы. Он показывает, как идеи проходят путь от смутных, "газообразных" фантазий и философских концепций к "жидким" гипотезам и, наконец, к "кристаллам" научных теорий, выраженных в формулах. Этот процесс похож на фазовые переходы: только на стадии "кристаллизации" идея становится пригодной для строгой проверки и применения. Математика здесь выступает не только средством выражения, но и фильтром, который отделяет реализуемое от невозможного. Например, попытка перенести законы тяготения в четырехмерное пространство приводит к невозможности существования устойчивых орбит - и это ограничение накладывает сама математика, а не физический эксперимент 2) Эволюция Вторая часть посвящена эволюции идей и научных теорий. Бобров сравнивает развитие научных концепций с биологической эволюцией: случайные мутации (новые гипотезы) проходят отбор, и только самые устойчивые и приспособленные выживают. В науке, как и в природе, "отбор" - это не случайный процесс, а мощная организующая сила, формирующая из хаоса закономерный результат. При этом "ландшафт приспособленности" научных идей постоянно меняется: новое открытие в одной области может изменить требования к теориям в другой, и даже небольшое изменение "окружения" приводит к перестройке всей системы знаний .3) Метаморфозы и варианты В этой части рассматривается, как одна и та же идея может преобразовываться, порождать разные варианты и модификации в зависимости от условий и новых данных. Научные концепции, как и живые организмы, склонны к метаморфозам: меняются детали, уточняются формулировки, появляются альтернативные подходы. Бобров подчеркивает, что наука - это не статичная система, а динамичный процесс, в котором даже устоявшиеся формулы могут быть пересмотрены или заменены по мере накопления новых фактов и развития методов. 4) Предвидение Четвертая часть посвящена предсказательной силе науки. Бобров показывает, что одна из главных задач научной теории - делать количественные предсказания, которые можно проверить экспериментально. Именно формулы позволяют заглядывать за горизонт известных фактов, предсказывать новые явления и даже открывать ранее неизвестные объекты. Однако автор отмечает, что предвидение в науке всегда связано с риском: иногда теория предсказывает невозможное или сталкивается с пределами применимости математики. В таких случаях приходится либо пересматривать исходные предпосылки, либо искать новые математические инструменты. 5) Приложения В заключительной части Бобров приводит примеры из разных областей науки и техники, где математика становится ключом к решению практических задач. Здесь обсуждаются реальные кейсы из астрономии, физики, инженерии. Если суммировать, то эта небольшая научно-популярная книга отлично подходит для всех, кто хочет понять, как устроена Вселенная и причем здесь математика. #PopularScience #Cosmos #Physics #Math