Balancing Coupling in Software Design - GoTo Book Club 2025

В недавнем интервью для GOTO 2025 Влад Хононов представил свою новую книгу "Balancing Coupling in Software Design" в беседе с Шином Брисалсом. Про книги и выступления Влада я уже как-то рассказывал раньше
- Про его книгу "Learning DDD", на которую я написал 4 кратких обзора: общий обзор DDD, DDD и микросервисы, DDD и event-driven architecture, DDD и data mesh
- Про его выступление "Сложность и модулярность две стороны одной медали" на ArchDays с частью истории про coupling еще до публикации книги (1 и 2)
А вот интервьюера я видел в первый раз, хотя Шин Брисалс тоже автор книги "Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions" (O'Reilly, 2024), который специализируется на помощи командам в проектировании, создании и эксплуатации устойчивых serverless-решений

Основными темами интервью были
- История исследования coupling в системах - здесь Влад рассказывает, как неудачный проект с микросервисами подтолкнул его к глубокому изучению принципов coupling в архитектуре ПО
- Вневременная природа проблем проектирования - несмотря на эволюцию технологий, базовые принципы проектирования и управления связями остаются неизменными на протяжении десятилетий. Влад вдохновлялся книгами 70-х годов
- Три измерения связей: интеграционная сила (knowledge sharing), дистанция и волатильность - фундаментальная модель для оценки связей между компонентами. Ниже представлены основные идеи об этих трех измерениях, хотя собеседники их прямо отдельно не проговаривали
-- Оценка силы интеграции между компонентами является ключевой, начиная от интрузивной связи (высокий обмен знаниями) до контрактной связи (низкий обмен знаниями).
-- Когда физическое расстояние между компонентами увеличивается (например, переход к микросервисам), связь должна быть сбалансирована за счет сокращения общих знаний (например, с четкими контрактами API и отсутствием прямого доступа к данным).
-- Прогнозирование и управление изменчивостью, т. е. скоростью изменений, также имеет решающее значение при проектировании для соответствующего уровня связи. Если один компонент, например устаревшая система, не должен меняться, то высокая сила интеграции или большое расстояние не являются проблемой.
- Декомпозиция проблем и оценка сложности - подходы к разбиению сложных задач и объективной оценке их сложности с учетом неопределенности
- Локальная vs глобальная сложность - как оптимизация локальной сложности отдельных компонентов может привести к увеличению глобальной сложности системы
- Модульность как противовес сложности - модульность является ключом к созданию масштабируемых и поддерживаемых систем
- Границы знаний и абстракции - как правильные абстракции создают эффективные границы знаний между компонентами
- Креативный подход к техническому писательству - использование поэзии в технической книге для лучшего донесения сложных концепций (здесь Влад рассказывает как genAI помогал ему писать стихи для этой книги)

Если обобщать, то эта книга получилась не такой легкой как "Learning DDD", но она все равно очень полезна для всех, кто стремится создавать гибкие, масштабируемые и поддерживаемые программные системы через правильное управление связями между компонентами.

#Software #Architecture #DistributedSystems #SystemDesign #Patterns #Sofware #Metrics #Management

[1/2] Head First Software Architecture (Head First. Архитектура ПО) (Рубрика #Architecture)

В отпуске я прочел книгу из серии Head First по архитектуре, которая вышла в марте прошлого года на английском, а в апреле этого уже появилась на русском в издательстве Питер. Вообще, я люблю серию "Head First" за доступное объяснение сложных тем, а архитектура софта - это определенно сложная тема:) Авторами книги были Раджу Ганди, Марк Ричардс и Нил Форд, причем двух последних я знаю хорошо - я читал их книги по архитектуре и мне показалось, что они уже исписались и я зарекся их читать. А вот Raju Gandhi был для меня новичком, но оказалось, что он уже написал несколько книг в серии "Head First" и его опыт благотворно повлиял на книгу - она мне показалась интереснее и полезнее "Fundamentals of Software Architecture" и "Software Architecture: The Hard Parts", которые писали Форд и Ричардс без Ганди:) Кстати, про обе книги я уже рассказывал: "Fundamentals ..." и "... Hard Parts".

Если же возвращаться к книге "Head First Software Architecture", то это доступное введение в основы software architecture, оформленное в визуально насыщенном стиле (аля комикс), основанном на исследованиях в области когнитивных наук, что делает ее отличной отправной точкой для разработчиков, желающих освоить архитектурное мышление.

Основная мысль книги базируется на четырех измерениях архитектуры, которые выделяют авторы

1) Architectural Characteristics
Это то, какие свойства (нефункциональные требования, атрибуты качества, архитектурные характеристики) система должна поддерживать - такие как scalability, testability, availability и др. Интересно, что я недавно разбирал whitepaper "Quality Metrics in Software Architecture" (1 и 2), где очень подробно разбирались - QualityElements - элементы качества, которые по мнению авторов этой статьи юывают трех видов
- Metric — конкретная метрика для измерения качества архитектуры
- QualityCharacteristic — глобальная характеристика качества (например, reliability, maintainability)
- QualityAttribute — атрибут качества, связанный с одной из характеристик
Авторы книги настолько не упарываются по этим -ilities, но отмечают, что архитектурные характеристики — это основа архитектуры, без которой невозможно принимать архитектурные решения или анализировать компромиссы.
2) Architectural Decisions
Это решения, оказывающие долгосрочное или значимое влияние на систему, например, выбор базы данных, количество сервисов, способы их взаимодействия. Architectural decisions задают структуру для команд разработки, определяя, например, количество сервисов и типы баз данных. Забавно, что лет 5 назад я сам рассказывал про наши архитектурные процессы в Т (Архитектура в масштабе на ArchDays 2020) и там было про RFC (request for comments) и ADR (architecture decision records)
3) Logical Components
Это функциональные строительные блоки системы и их взаимодействие. Например, в e-commerce системе это могут быть inventory management и payment processing. Logical components - это как комнаты в доме: базовые структурные элементы с определённой функцией.
4) Architectural Styles
Это общее физическое устройство и структура системы, аналогично тому, как план здания определяет структуру дома. Architectural styles можно классифицировать по
- Стилю разбиения (technical или domain partitioned)
- Модели деплоя (monolithic или distributed)

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

#Architecture #Software #Engineering #SystemDesign #DistributedSystems #Metrics #Architect

[2/2] Head First Software Architecture (Head First. Архитектура ПО) (Рубрика #Architecture)

Продолжая рассказ об этой книге о проектировании софта, стоит начать с алгоритма создания архитектуры на основе четырех измерений, который по мнению авторов выглядит примерно так
1) Определить architectural characteristics на основе требований. Важно выяснить, какие quality attributes критичны для вашей системы (performance, scalability и др.)
2) Принять architectural decisions - на основе выявленных характеристик принять решения о технологиях, паттернах и подходах
3) Определить logical components - разбить систему на функциональные блоки с учетом как раз функциональных требований, которые должны быть реализованы системой, а также архитектурных характеристик
4) Выбрать architectural style - подобрать стиль (например, microservices, layered), который поддерживает ваши характеристики, решения и компоненты
Все четыре измерения взаимосвязаны - каждое должно соответствовать остальным. Architectural style должен соответствовать выбранным характеристикам и решениям, а logical components - поддерживать характеристики и вписываться в стиль.

Структура книги выглядит следующим образом: в первых пяти главах дается введение в архитектуру и разбираются четыре измерения, описанные выше
1. Software Architecture Demystified: Let’s Get Started!
2. Architectural Characteristics: Know Your Capabilities
3. The Two Laws of Software Architecture: Everything’s a Trade-Off
4. Logical Components: The Building Blocks
5. Architectural Styles: Categorization and Philosophies

В следуюзих частях разбираются архитектурные стили, причем авторы используют схему со звездочками для каждого стиля по избранным архитектурным характеристикам, куда входят maintainability, testability, deployability, simplicity, evolvability, performance, scalability, elasticity, fault tolerance, overall cost. Эти стили примерно соответствуют тому, что было в книге "Fundamentals of Software Architecture", где я в первый раз увидел эти таблички с этими рейтингами
6. Layered Architecture: Separating Concerns
7. Modular Monoliths: Driven by the Domain
8. Microkernel Architecture: Crafting Customizations
9. Do It Yourself: The TripEZ Travel App
10. Microservices Architecture: Bit by Bit
11. Event-Driven Architecture: Asynchronous Adventures

В последней главе авторы предлагают спроектировать систему на основе выданных требований, используя алгоритм, предложенный в предыдущих главах
12. Do It Yourself: Testing Your Knowledge

Заканчивается все приложением "A. Leftovers: The Top Six Topics We Didn’t Cover", в котором авторы обсуждают интересные темы, что не влезли в основную часть книги
- Должен ли архитектор писать код
- В чем состоят обязанности архитектора
- Какие навыки, кроме технических, полезны архитектору
- Немного про построение архитектурных схем
- О глубине и широте знаний архитекторов
- О пользе архитектурных кат

В итоге, если суммировать, то эта книга хороша в качестве старта для погружения в software architecture, а дальше уже можно читать и более продвинутые книги по архитектуре.

#Architecture #Software #Engineering #SystemDesign #DistributedSystems #Metrics #Architect

Весенняя распродажа в издательстве «Питер» (Рубрика #Sales)

В издательстве Питер очередная распродажа со скидками в 35% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг, половину из которых я уже прочитал, а половину нет (подробнее про эти книги можно прочитать здесь). Но с тех пор я получил еще пару книг по архитектуре
- Head First Software Architecture (Head First. Архитектура ПО) - я ее уже прочитал и рассказал про нее (книга хорошая)
- Acing the System Design Interview (System Design: пережить интервью) - я ее читаю сейчас и планирую рассказать про нее (книга хорошая)

В общем, я обычно покупаю книги издательства Питер на таких распродажах - это удобно, так как я собираю батч и покупаю его раз в квартал:)

#Sales

The 48 Laws of Power (48 Законов Власти) (Рубрика #Management)

В отпуск я взял с собой несколько бумажных книг, среди которых была и эта книга Роберта Грина "48 законов власти". В первый раз я прочитал ее порядка 20 лет назад и она показалась мне циничной и манипулятивной до невозможности:) Но я подумал, что стоит ее перечитать, ведь с тех пор я прочел "Государя" Макиавелли и Сунь-Цзы "Искусство войны". А эта книга написана в их стиле и содержит 48 "законов власти", каждый из которых сопровождается теоретическими обоснованиями и историческими примерами. Грин использует анекдоты из жизни исторических фигур, таких как Людовик XIV, Талейран, Отто фон Бисмарк, Екатерина Великая и Мао Цзэдун, чтобы проиллюстрировать практическое применение своих правил. Если бы книгу писали IT специалисты, то они бы ее назвали "48 Patterns of Laws", так как структура похожа на типичную книгу о паттернах, например, "Design Patterns", "Technology Strategy Patterns" или "Enterprise Integration Patterns". По словам самого автора, книга помогает "заглянуть в фундаментальные характеристики власти и способы ее завоевания, понимания и противостояния ей"

Все 48 законов перечислять тут мы не будем, но несколько основных вспомним
1) Никогда не затмевай господина. Мысль в том, чтобы всегда делать так, чтобы твой начальник чувствовал себя умнее и значительнее тебя.
2) Скрывай свои намерения. Мысль в том, чтобы держать людей в неведении о своих планах. Пример из мира IT - rогда Microsoft объявил, что покупает GitHub "ради поддержки open-source сообщества", никто не сказал: "Мы хотим получить данные о миллионах разработчиков и их проектах для обучения нашего ИИ-помощника Copilot". Правда, тогда и копайлота еще не было
3) Пусть другие работают за тебя, но всегда бери заслуги на себя. Пример из мира IT
- В Apple дизайн продуктов шел от Джони Айва, хотя над каждым продуктом трудятся сотни дизайнеров
- В Amazon крупные проекты были "инициативами Джеффа Безоса" и не важно кто ее придумал
4) Учись делать людей зависимыми от тебя - чтобы сохранить независимость, необходимо, чтобы в тебе нуждались и тебя желали. Примеры из мира IT
- Когда руководитель обеспечивает job-security за счет непрозрачности процессов и паутины связей.
- Когда Apple создала целую экосистему устройств. Купил iPhone? Теперь тебе нужны AirPods. Потом MacBook, потому что "они так хорошо работают вместе". А теперь Apple Watch. И iCloud+. И AppleTV+ ...
5) Добивайся того, чтобы твои достижения казались легкими. В IT-компаниях часто говорят про "запуск новой функции", не акцентируя внимания на том, что на нее могут быть потрачены сотни человеко-лет.

Надеюсь, что вы уже поняли, что "48 законов власти" - это не столько практическое руководство, сколько зеркало, отражающее тёмную сторону человеческой природы и социальных взаимодействий. Книга во многом напоминает "Вредные советы" Григория Остера - если воспринимать её буквально и следовать каждому совету, можно не только не добиться успеха, но и нажить много проблем. Многие законы Грина откровенно циничны и иногда аморальны, что признает и сам автор. Книгу часто критикуют за пропаганду манипуляций и макиавеллизма. Однако её ценность заключается не в прямом следовании советам, а в понимании механизмов власти, которые существуют в любой организации.

Задуматься над этими "законами" стоит хотя бы для того, чтобы распознать, когда ими пользуются против вас. Книга может служить своеобразной вакциной от наивности в корпоративном мире, где за внешним лоском "плоских структур" и "открытых культур" нередко скрываются те же самые властные механизмы, что существовали при дворах королей столетия назад. Так что в следующий раз, когда вы увидите необъяснимые корпоративные решения или странные перестановки, то не удивляйтесь.

#Management #Leadership #Politics #Strategy

AI as Software Architect assistant by Avraham Poupko (Рубрика #Architecture)

Интересное выступление Авраама Пупко про то, как AI может помогать архитектору. Авраам Пупко — ведущий архитектор программных систем, руководитель стратегического планирования и продуктовой архитектуры в Toga Networks, преподаватель системного мышления и проектирования. Более 25 лет он занимается анализом, моделированием и проектированием ПО, работал как с небольшими стартапами, так и с крупными корпорациями.

В этом докладе он поднимает следующие ключевые темы и формулирует следующие тезисы
1) Роль AI как помощника, а не заменителя архитектора. AI не заменяет архитектора, а становится инструментом для повышения продуктивности и эффективности. Ключевой вызов — научиться использовать ИИ правильно, сохраняя ответственность за решения.
2) Границы возможностей AI. AI работает с языковыми моделями, а человек — с моделью мира. Архитектор должен понимать, что AI не обладает настоящим пониманием, а лишь манипулирует словами и связями между ними. Правда, сейчас есть разные гипотезы о том, а есть ли у LLM (и LMM) есть понимание модели мира или нет:)
3) Ответственность и этика. Архитектор всегда несёт ответственность за принятые решения, даже если использовал ИИ как советчика. Этические вопросы и осознанность остаются прерогативой человека.
4) Работа с неоднозначностью требований. AI помогает выявлять и анализировать неоднозначные требования, но не может полностью заменить архитектурное мышление и опыт в разрешении таких ситуаций. Тут можно почитать примеры идей в whitepaper типа "From Requirements to Architecture: An AI-Based Journey to Semi-Automatically Generate Software Architectures", про которую я писал раньше
5) Компромиссы и принятие решений. Архитектору важно уметь взвешивать плюсы и минусы разных подходов, а ИИ может помочь структурировать аргументы и рассмотреть альтернативы, но не принимает решения за человека. А пример такого подхода можно глянуть в whitepaper "A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-makingture Decision-making", про который я писал раньше
6) Коллаборация и командная работа. Архитектор работает на стыке технологий, людей и организаций. ИИ может способствовать обсуждению и анализу, но не способен заменить человеческое взаимодействие и эмпатию.
7) Метафоры и модели. AI генерирует метафоры и помогает объяснять архитектурные решения, но глубина понимания и адаптация к контексту остаётся за архитектором. Я вот тоже люблю метафоры еще со времен начала карьеры, когда я прочитал книгу Стива Макконелла "Совершенный код", про которую я уже писал раньше
8 ) Жизненный цикл принятия решений. Архитектор проходит полный цикл: сбор информации, рассмотрение вариантов, принятие решения, действие, обратная связь. AI может быть полезен на отдельных этапах, но не охватывает весь цикл. Тут мне тоже видится перспективы в том, чтобы собирать мултиагентную систему, что сможет закрыть весь цикл принятия решения и дальше архитектору надо будет только отревьювить то, что эта система наделела:)
9) Ошибки, обучение и рост. Человеческий опыт, способность учиться на ошибках и развивать интуицию — уникальные качества архитектора, недоступные AI. Спорное утверждение, особенно, если немного изучить область reinforcement learning.
10) Будущее профессии и развитие навыков. Архитектору важно быть инициативным, критически относиться к советам ИИ, развивать экспертизу и не бояться экспериментировать. Только те, кто умеет эффективно использовать ИИ, останутся востребованными.

Если подводить итоги выступления Авраама, то его мысль в том, что AI — это мощный инструмент для архитектора, но не его замена. Поэтому осваивайте ИИ, используйте его для повышения эффективности, но сохраняйте критическое мышление, ответственность и профессиональную инициативу.

#Architecture #Software #Engineering #AI #SystemDesign #SelfDevelopment #Architect

Все формулы мира (Рубрика #PopularScience)

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

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

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

#PopularScience #Cosmos #Physics #Math

От стартапа до международного бизнеса: история 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

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

[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

[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