Разработка Высоконагруженных Систем (Рубрика #Architecture)

Нашел на своей полке старенькую книгу издательства Олега Бунина, с которой началось мое знакомство с высоконагруженными системами. Эта книга является сборником материалов по итогам конференций HighLoad++ 2010-2011 годов, изданный в 2012 году. Официально она приписывается коллективу авторов, а Олег Бунин выступил в качестве издателя и составителя.

Книга насчитывает 400 страниц и представляет собой попытку не просто описать технические характеристики крупных систем, а изложить принципы построения архитектур самых передовых и посещаемых интернет-проектов того времени. Книга фокусируется на принципах проектирования архитектуры высоконагруженных систем и практических аспектах их реализации, опираясь на опыт реальных проектов, представленных на конференциях HighLoad++. Книга начиналась с базового учебника, который включал следующие уроки
1) Первый урок, что содержал рассказ про монолитные приложения и сервис-ориентированную архитектуру, про ремесленный и промышленный подход к разработке нагруженных приложений, про вертикальное и горизонтальное масштабирование приложений, про трехзвенную архитектуру
2) Второй урок про масштабирование фронендов, что содержал обсуждение раздачи статики, кеширования, логику на фронте/беке, масштабирование бекендов и работу со всплесками трафика, про балансировку запросов на фронтенд при помощи DNS
3) Третий урок про маштабирование бекенда, где авторы говорили про функциональное разделение бекенд сервисов для масштабирования, про горизонтальное масштабирование и важность низкой связности кода (видимо, low coupling), shared nothing подходов, layered architecture. Также тут опять шла речь про кеширование, инвалидацию и прогрева кеша
4) Четвертый урок с масштабированием во времени, где речь шла про асинхронность и отложенные вычисления, использование очередей, немного про консистентность данных. Здесь был пример проектирования ленты соцсети, где эти подходы можно было использовать
5) Пятый урок про базы данных, где авторы рассказывают про разные типы баз данных, тюнинг запросов, шардинг, репликацию, кластеризацию и денормализацию, а также про хранимые процедуры.

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

#DistributedSystems #Architecture #SystemDesign #Software #SoftwareArchitecture

Почему ваша амбициозность в Европе может обернуться одиночеством | Евгений Кот (Рубрика #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

Code of Leadership #38 - Interview with Dmitry Kotelnikov about origination platform and reliability (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Дмитрий Котельников, с которым мы обсудили origination процессы и вопросы обеспечения их надежности. Дима работает в Т-Банке уже 8 лет и все это время занимается онбордингом новых клиентов, а сейчас руководит платформой Origination, а также развивает RnD направление AI миграций и участвовал в запуске стрима Staff инженеров, о которых мы как-то говорили в выпуске с моим коллегой Лешей Тарасовым

За час мы успели обсудить следующие темы
- Знакомство с гостем
- Выбор университета и развитие навыков
- Начало карьеры и первые рабочие задачи
- Архитектурные изменения и рост компании
- Развитие инфраструктурных инструментов
- BPM и сложности бизнес-процессов
- Надежность, интеграции и инструменты мониторинга
- Структура платформы origination
- Технические аспекты и общие компоненты платформы
- Управление потребностями продуктов и вызовы платформы
- Переход от инженера к менеджеру и рекомендации для развития

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

[1/3] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #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

[2/3] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #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

Критическое мышление. Железная логика на все случаи жизни (Рубрика #Thinking)

Эта книга Никиты Непряхина и Тараса Пащенко, позиционируется как практическое руководство для подростков, стремящихся развить навыки мышления. Моя жена купила его для детишек, а я решил прочитать и оценить как детей учат анализировать информацию, отличать факты от мнений, противостоять манипуляциям и принимать обоснованные решения. Изложение очень доступное, используются примеры из повседневной жизни. В книге рассматриваются следующие темы
1. Распознавание стереотипов и когнитивных искажений. На примерах из школьной жизни объясняется, как социальные шаблоны влияют на восприятие реальности.
2. Механизмы формирования суеверий и мифов. Разбираются психологические причины веры в иррациональное, включая эффект подтверждения и склонность к упрощённым объяснениям.
3. Влияние общественного мнения на принятие решений. Анализируются случаи конформизма и группового мышления, актуальные для подростковой среды.
4. Разграничение фактов и оценочных суждений. Приводятся критерии верификации информации, такие как проверка источников и поиск доказательств.
5. Логические основы аргументации. Обсуждаются структура умозаключений, типы аргументов и распространённые логические ошибки.
6. Практика принятия решений. Предлагаются алгоритмы взвешенного выбора в условиях неопределённости, включая анализ рисков и последствий.

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

Практическую направленность книги подтверждает то, что каждая глава содержит
- Кейсы для анализа. Читателям предлагается оценить ситуации, подобные тем, с которыми они сталкиваются в школе или соцсетях.
- Упражнения-тренажёры. Например, задание на классификацию суждений («факт vs мнение») или построение логических цепочек.
- Чек-листы и алгоритмы. Готовые схемы для проверки информации, принятия решений и аргументации.

Итого, эта книга может стать хорошей стартовой точкой для развития критического мышления для читателей старше 12 лет (возвраст указан в книге). Она особенно полезна в образовательном контексте — для уроков по логике, факультативов или семейного чтения. Для углублённого изучения темы стоит дополнить её академическими источниками, но в качестве практического руководства она выполняет свою задачу на отлично.

P.S.
Я уже раньше делал подборку книг про системное и критическое мышление, многие из которых хорошо подойдут в качестве продолжения к этой книге:)

#Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership