Последние посты Системный Аналитик (@sys_sa) в Telegram

Посты канала Системный Аналитик

Системный Аналитик
Канал для системных аналитиков и не только: подборки полезных материалов на все случаи жизни.

Реклама и сотрудничество @radale

https://gosuslugi.ru/snet/67b0613c6411ff785396754a
16,296 подписчиков
85 фото
4 видео
Последнее обновление 11.03.2025 07:48

Похожие каналы

Business | System analyst
15,378 подписчиков
Системный сервант
2,841 подписчиков

Последний контент, опубликованный в Системный Аналитик на Telegram

Системный Аналитик

09 Jan, 10:21

13,271

БАЗА ЗНАНИЙ по системному анализу 🧠

Все посты из канала за всё время разложены по полочкам в едином месте — базе знаний 🤓

Наша цель — сделать кладезь знаний системного аналитика 🧠

Какие плюшки вас ждут:

🗂 Все знания в едином месте: кратко, ёмко, без воды и с подборками полезных материалов 🔥

🔎 Удобный поиск и навигация: все наши конспекты структурированы по группам навыков СА и есть поиск по тексту — вы не утоните в тоннах воды и часах гуглинга

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

📝 Контент на заказ бесплатно: хотите материал на конкретную тему? Любой покупатель может оставить запрос, и мы сделаем обзор с исчерпывающей подборкой материалов абсолютно бесплатно!


➡️ Приобрести вечный доступ к постоянно обновляемой Базе знаний по цене айтишниой книги можно тут: analitik.me — всего 4900 ₽

❗️После успешной оплаты нажмите кнопку Вернуться в магазин, чтобы получить ссылку на закрытый канал (он нужен для авторизации). Если случайно закрыли, ссылка придёт вам на почту.

Если нет карты РФ и по любым другим вопросам можно писать сюда: @radale

P.S. каналы @sys_sa и @lib_analyst продолжают работу в прежнем формате
Системный Аналитик

31 Dec, 11:53

14,566

🌲Подборка наших постов за💚💚💚💚

Управление требованиями
🔘Методы трассировки требований
🔘Критерии приемки (Acceptance Criteria): краткий обзор
🔘Постановка задачи на разработку: этапы, отличие от ТЗ
🔘Customer Journey Map (CJM)
🔘User Story vs Job Story

Работа с API
🔵Версионирование REST API
🔵Обеспечение идемпотентности API
🔵Способы асинхронного взаимодействия в API
🔵Работа со списками данных в REST API: сортировка, фильтрация, пагинация
🔵Знакомство со Swagger
🔵Производительность API: краткий обзор способов

Архитектура и проектирование
💩Обзор популярных нотаций моделирования
💩Способы обеспечения работы высоконагруженных систем
💩Паттерны проектирования и архитектурные паттерны
💩Event Driven Architecture: краткий обзор
💩Service Mesh
💩TOGAF. Краткий обзор
💩Паттерны асинхрона: Request-Reply, Publish-Subscribe, Point-to-Point
💩Антипаттерны проектирования ПО
💩Интеграция через файловый обмен

Базы данных и хранилища
💩Масштабирование БД. Партиционирование, шардирование и репликация
💩Шпаргалка по SQL
💩Требования ACID: Краткий обзор
💩Уровни изоляции транзакций в базах данных
💩Изолированность транзакций в БД: MVCC, блокировки
💩Хранимые процедуры и пользовательские функции в БД
💩Денормализация в БД и не только
💩Оконные функции
💩Колоночные БД, Cassandra vs PostreSQL
💩Data Warehouse (DWH)
💩OLTP и OLAP
💩ETL и ELT

Авторизация и безопасность
💩OAuth 2.0 и OpenID Connect
💩Инфраструктура открытых ключей (PKI) : краткий обзор
💩Хэширование и Шифрование
💩Кибератаки и их виды

Инструменты
🔵Camunda
🔵Grafana: Обзор и возможности
🔵Apache Kafka

Расширение IT-кругозора
◾️Как работает интернет
◾️Kanban vs Scrum: сравнение методологий
◾️Модель TCP/IP: Краткий обзор и сравнение с OSI
◾️Git. Обзор и подборка материалов
◾️Основы ООП
◾️CI/CD
◾️UX/UI
◾️SRE (Site Reliability Engineering)
◾️Веб-приложения: SPA , MPA, PWA
◾️Паттерны GRASP
◾️Синхронизация времени по NTP
◾️Тест-кейсы: как и зачем писать
◾️SQA: обеспечение качества ПО
◾️Методы оценки трудоёмкости проектов и задач

Полезные подборки
🔹Подборка публичных собеседований системных аналитиков
🔹Матрица компетенций системного аналитика
🔹Бесплатные выпуски подкаста «Аналитики у микрофона» для и про аналитиков

В ближайшие дни откроем продажи к базе знаний — веб-порталу, где будут собраны все наши посты в едином месте, с удобной навигацией и поиском. Следите за новостями.

Всех с Наступающим 🎉

#подборка
Системный Аналитик

30 Dec, 15:42

10,013

📖 Подборка книг, опубликованных в 2️⃣0️⃣2️⃣4️⃣

Системный анализ и управление требованиями

🔘Жемчужины разработки. Чему мы научились за 50 лет создания ПО от Карла Вигерса
🔘Формализация требований на практике

Архитектура и проектирование ПО

🔵Предметно-ориентированное проектирование. Самое основное от Вона Вернона
🔵Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы от Марка Ричардса и Нила Форда
🔵Распределенные системы. Паттерны проектирования от Брендана Бернса
🔵Объектно-ориентированное мышление от Мэтта Вайсфельда
🔵Приемы объектно-ориентированного проектирования. Паттерны проектирования от Э. Гаммы, Р. Хелма, Р. Джонсона, Дж. Влиссидеса
🔵Объектно-ориентированный анализ и проектирование с примерами приложений
🔵Предметно-ориентированное проектирование: паттерны, принципы и методы от Скотта Миллетта и Ника Тьюна
🔵Архитектура программного обеспечения на практике от Л. Басса, П. Клементса и Р. Кацмана
🔵Идеальная архитектура. Ведущие специалисты о красоте программных архитектур от Диомидиса Спинеллиса и Георгиоса Гусиоса

Разработка высоконагруженных систем
🔵Высоконагруженные приложения. Программирование, масштабирование, 🔵поддержка от Мартина Клеппмана
🔵Разработка высоконагруженных систем — брошюра по материалам конференции HighLoad++

Базы данных и хранилища
💩5 книг по изучению SQL
💩Распределенные данные. Алгоритмы работы современных систем хранения информации от Алекса Петрова
💩Проектирование и реализация систем управления базами данных от Эдварда Сьоре
💩Основы технологий баз данных: учебное пособие
💩Технологии проектирования баз данных от Дмитрия Осипова
💩PostgreSQL 15 изнутри от Егора Рогова

Проектирование API
💩Designing APIs with Swagger and OpenAPI

Моделирование и бизнес-процессы
💩Моделирование бизнес-процессов в нотации BPMN 2.0
💩The C4 Model for Visualising Software Architecture от Саймона Брауна
💩Свод знаний по управлению бизнес-процессами BPM CBOK 4.0
💩Построение бизнес-моделей от Александра Остервальдера

DevOps и SRE
⚫️Книги по DevOps от Джена Кима
⚫️Site Reliability Engineering. Надежность и безотказность как в Google

Agile и управление проектами
💩Подборка книг по Agile
💩Подборка книг по Scrum
💩Подборка книг по Kanban
💩Экстремальное программирование. Разработка через тестирование от Кента Бека
💩Управление проектным бизнесом от Алексея Васильева

QA
◾️Тестирование веб-API от Марка Винтерингема
◾️Agile-тестирование. Обучающий курс для всей команды от Джанеты Грегори и Лайзы Криспин

Информационная безопасность
🔘Безопасность веб-приложений от Хоффмана Эндрю
🔘Искусство быть невидимым. Как сохранить приватность в эпоху Big Data от Кевина Митник и Уильяма Л. Саймона

Пользовательский опыт и интерфейсы
🔸Не заставляйте меня думать от Стива Круга
🔸Хороший интерфейс — невидимый интерфейс от Голдена Кришны

Инструменты
💩Apache Kafka. Потоковая обработка и анализ данных
💩Pro Git от Скотта Чакона и Бена Штрауба

Личное развитие и soft skills
🔘Принцип пирамиды Минто. Золотые правила мышления, делового письма и устных выступлений от Барбары Минто
🔘Думай медленно... решай быстро от Даниэля Канемана
🔘Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию от Уильяма Детмера
🔘Искусство системного мышления от Джозефа О'Коннора и Иана Макдермотта


🔖 Сохраняйте и делитесь с коллегами!

#подборка
Системный Аналитик

28 Dec, 06:44

8,798

Жемчужины разработки. Чему мы научились за 50 лет создания ПО

✍️ Автор: Карл Вигерс
🗓 Год издания: 2024
🔤 Язык: русский
📚 Объём: 368 стр.

Книга «Жемчужины разработки» от классика Карла Вигерса — это очень полезная для системных аналитиков, стремящихся улучшить свои навыки и избежать распространенных ошибок. Вигерс собрал 60 практических уроков, которые помогут научиться на чужом опыте и не наступать на грабли лишний раз.

Ключевые темы книги охватывают шесть основных аспектов успешной разработки:

1. Требования
2. Дизайн
3. Управление проектами
4. Культура и командная работа
5. Качество
6. Улучшение процессов

Для каждого из этих направлений автор предлагает:

🔘«Первые шаги», которые помогут вам проанализировать свой опыт
🔘Конкретные идеи и примеры, которые можно сразу же применить на практике

Кроме того, Вигерс предлагает «следующие шаги» для внедрения полученных знаний в ваши проекты и команды. Эти уроки основаны на реальном опыте и не могут быть получены в учебных заведениях, что делает их особенно ценными.

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

Обзор книги на Хабре

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

#проектирование #требования
Системный Аналитик

27 Dec, 08:09

8,894

Антипаттерны проектирования ПО (часть 2)

Лавина изменений (Lava Flow)

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


Незакрытые соединения (Resource Leak)

Системные ресурсы (например, память или соединения) не освобождаются после использования
ошибки в управлении ресурсами, отсутствие тестирования
открытые файловые сетевые соединения, которые не закрываются после завершения работы


Избыточная абстракция (Abstract Obsession)

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


Форма, нарушающая контракт (Leaky Abstraction)

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


Необоснованные зависимости (Unnecessary Dependencies)

Модули зависят друг от друга без веской причины
плохое планирование, отсутствие модульности
логика бизнес-слоя зависит от UI-компонентов, что затрудняет изменение интерфейса


Перекрестные зависимости (Cyclic Dependencies)

Модули зависят друг от друга, создавая циклические зависимости
недостаточное планирование, отсутствие четкой архитектуры
модуль А зависит от модуля B, который в свою очередь зависит от модуля A


Копипаст (Copy-and-Paste Programming)

Код копируется и вставляется в разных местах без модификации или рефакторинга
спешка, отсутствие времени на рефакторинг
фрагмент кода для обработки ошибок, дублированный в нескольких методах


Неразрешимая взаимозависимость (Circular Dependency)

Два или более модуля зависят друг от друга напрямую или косвенно
непродуманное разделение обязанностей, спешка при разработке
модуль управления пользователями зависит от модуля управления ролями, и наоборот


Черный ящик (Magic Numbers)

Использование в коде числовых значений без пояснения их смысла
недостаток времени на документирование, слабое проектирование
число "7", использованное для обозначения количества попыток, без объяснения причины выбора


Часть 1 👆

📎 Материалы
1. Магическое число (Magic Number)
2. Большой комок грязи
3. Антипаттерн — Золотой молоток (Golden Hammer)
4. Золотой молоток
5. Спагетти-статья о спагетти-коде
6. Автоматы против спагетти-кода
7. God object. Анализ сложных проектов
8. Антипаттерн — Божественный объект (God Object)
9. Антипаттерн — Метод копипаста (Copy and paste programming)
10. Антипаттерны проектирования: Dead End
11. Антипаттерны построения микросервисных приложений в высоконагруженных проектах
12. Что такое антипаттерны? Разбираем примеры
13. Топ-10 антипаттернов при использовании микросервисов
14. 9 анти-паттернов, о которых должен знать каждый программист


Видео
1. Худшие практики разработки и архитектуры за 12 минут
2. Антипаттерны
3. Антипаттерны (обзор нескольких)


📚 Книги
Типичные ошибки проектирования -- Эрик Аллен

#проектирование #архитектура
Системный Аналитик

27 Dec, 08:06

7,226

<BIG пост перед новогодними праздниками>

Антипаттерны проектирования ПО (часть 1)

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

Существуют ~ 20-30 известных антипаттернов, рассмотрим некоторые.

Большой комок грязи (Big Ball of Mud)

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


Код-спагетти (Spaghetti Code)

Код с многочисленными запутанными зависимостями, который сложно поддерживать и тестировать
плохая структурированность, спешка в разработке, отсутствие документации
старый проект, в котором нет модульности, а изменения в одном месте приводят к сбоям в других частях
Spaghetti Code относится к проблемам в коде на уровне отдельных компонентов / модулей, а Big Ball of Mud описывает хаос в общей архитектуре системы


Золотой молоток
(Golden Hammer)

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


Изобретение велосипеда (Reinventing the Wheel)

Создание собственного решения для задачи, уже решенной готовыми библиотеками или фреймворками
недостаток знаний о существующих решениях
создание собственной системы логирования вместо использования, например, Log4j


Дымоход (Stovepipe System)

Набор изолированных систем, которые плохо взаимодействуют друг с другом
отсутствие координации между командами, историческое "наследие"
когда каждый отдел разрабатывает свои собственные ИТ-системы без учета интеграции с другими


Божественный объект (God Object)

Один объект, который знает слишком много или делает слишком много
недостаточное разделение ответственности, централизованное управление
класс в ООП, который содержит логику для всего приложения и отвечает за все задачи


Продолжение примеров ниже👇

#проектирование #архитектура
Системный Аналитик

26 Dec, 14:01

4,806

Позаботился о подарках для родных и близких?
Позаботься и о лучшем подарке для себя — новая работа ждёт тебя в Сбере!
Заходи на сайт rabota.sber.ru — здесь сбываются амбициозные проекты, классные коллеги и крутые возможности. 🔥
В Новый год — с новой работой в Сбере.💚
Системный Аналитик

24 Dec, 08:05

10,287

📂 Методы оценки трудоёмкости проектов и задач

Покер планирования (Planning Poker)

Оценка задач с использованием карточек с числовыми значениями (например, 1, 2, 3, 5, 8 по Фибоначчи).

Алгоритм
🟡участники получают карты с числами (например, 1, 3, 5, 8)
🟡оценивают одновременно, не показывая карты
🟡если оценки разные, обсуждают и переоценивают

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


Система корзин (Bucket System)

Задачи группируются в "ведра" по сложности, затем внутри групп задач идет их сортировка
Для оценки большого числа задач, когда точность важна, но при этом нужно сохранить эффективность.

Алгоритм
🟡разделить задачи на ведра (например, "легкие", "средние", "сложные")
🟡разместить задачи в ведра на основе их сложности
🟡уточнить оценки внутри ведра

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


Оценка по размерам футболок (T-Shirt Sizes)

Оценка по аналогии с размерами одежды (XS, S, M, L, XL), где каждый размер — относительная сложность задачи.
Быстрая и простая оценка для грубого прогнозирования.

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


Трехточечная оценка (Three-Point Estimation)

Оценка на основе трёх значений: оптимистичного, пессимистичного и наиболее вероятного.

Алгоритм
🟡определить оптимистичную, пессимистичная и наиболее вероятную оценки
🟡рассчитать среднюю: (Оптимистичная + 4*Наиболее вероятная + Пессимистичная) / 6. Итого 6 голосов.
  5ч - оптимистичная,  7ч - наиболее вероятная, и 9 - пессимистичная. Средняя оценка = (5 + 4*7 + 9)/6 = 7 часов

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


Снизу вверх (Bottom-up)

Задача сначала оценивается целиком, а затем делится на более мелкие компоненты

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

быстрый способ для общей оценки крупных проектов; удобен на ранних этапах планирования
возникновение неточностей из-за отсутствия детализации на уровне подзадач


Диаграмма сходства (Affinity Mapping)

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

Алгоритм
🟡записать задачи на карточках
🟡группировать похожие задачи 
🟡оценить группы задач

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


Выбор метода

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


📎 Материалы
1. Как оценивать проектные задачи, чтобы не слить бюджет и не убить команду: советы QA-лида
2. Agile in IT: 7 техник оценки задач
3. Гибкие методологии и 10 лучших техник оценки трудоемкости
4. Путеводитель по оценкам задач и котики

5. Planning Poker: как сделать процесс постановки задач максимально прозрачным и четким
6. Стратегия Bottom-up: как не упустить прорывные идеи и стать гибкой командой
7. T-Shirt Sizing - Agile Estimation Guide
8. Методы оценки - три точки
9. 5 шагов к созданию диаграммы близости


🌐 Инструменты
1.
PlanningPoker (eng)
2. PlanningPoker (ru)
3. PlanningPoker (ru)
4. Шаблон диаграммы сходства


Видео
1. Planning Poker: командная игра для принятия решений и брейнштормов
2. Покер планирования: что это и как его проводить?
3. Трехточечная оценка проекта. Как мы оцениваем задачи

#управление_проектами
Системный Аналитик

23 Dec, 11:47

4,300

Machine Learning и Data Science в деталях

На канале Виктора Кантора MLinside вышел подкаст с Алексеем Толстиковым, руководителем Школы анализа данных Яндекса (ШАД). Выпуск посвящён развитию в сферах машинного обучения и анализа данных
Ключевые моменты:

🔵 Что нужно рынку. Какие навыки делают ML- и DS-специалистов востребованными, и почему одних технических знаний недостаточно.
🔵 Алгоритмы и их значение. Зачем ML-инженеру понимать структуру данных и логику алгоритмов, даже если он их не применяет ежедневно.
🔵 Учёба в ШАД. Как устроена программа, почему поступить не с первого раза – нормально, и как совмещать обучение с работой.
🔵 Участие в профильных чемпионатах. Как соревнования по ML помогают в развитии.
🔵 Польза междисциплинарности. Реально ли войти в ML и DS из совершенно других областей и как помогает прошлый профессиональный опыт.

Посмотреть:
🔗YouTube

#обучение #развитие #подкасты
Системный Аналитик

17 Dec, 07:01

10,787

🔅Service Mesh

Service Mesh — архитектурный слой. Управляет сетевым взаимодействием между сервисами в распределённых системах.
Каждый сервис взаимодействует с другими через прокси (sidecar), который управляет всем трафиком между сервисами

☑️ Часто Service Mesh используют в облачных инфраструктурах - в контейнерах и Kubernetes

Основные задачи

🔵Шифрование трафика между сервисами и управление доступом на уровне соединений
🔵Сбор метрик, логов и трассировок для мониторинга взаимодействий между сервисами
🔵Балансировка нагрузки, маршрутизация запросов и отказоустойчивость на уровне сетевых вызовов
🔵Автоматическое переключение при сбоях и лимитирование запросов

Примеры решений для Service Mesh: Istio, Envoy Proxy, Linkerd2, Conduit, Consul Connect


Компоненты Service Mesh

⚙️ Data Plane

💩набор прокси-серверов (например, Envoy), которые развертываются рядом с каждым сервисом (sidecar pattern)
💩отвечает за обработку сетевого трафика между сервисами
💩прокси выполняют функции маршрутизации, шифрования, балансировки нагрузки и сбора метрик

🛡 Control Plane

💩управляет настройками Data Plane, определяет правила маршрутизации, политику безопасности и другие конфигурации
💩централизованно контролирует и управляет прокси в Data Plane
Примеры: Istio, Consul Connect


Плюсы и минусы

✈️ Централизованное управление политиками безопасности (аутентификация, авторизация, шифрование трафика)

Пример: Istio для настройки политики безопасности для взаимодействия микросервисов. Использует мутаторы и проверки на уровне прокси

✈️ Инструменты для мониторинга, сбора метрик и трассировки запросов

Пример: в Linkerd2 есть инструменты (Linkerd Dashboard) для отслеживания состояния микросервисов и анализа метрик производительности в реальном времени

✈️ Упрощает сложные сценарии маршрутизации трафика и балансировки нагрузки между сервисами

Пример: Istio для создания сложных правил маршрутизации (канареечные релизы или A/B тестирование), которые применяются к версиям сервисов без изменения их кода

✈️ Легко управлять версиями сервисов и конфигурациями -> лучше управление релизами и тестированием

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


Минусы

🧮 Для внедрения нужна сложная настройка и управление доп компонентами -> усложняет инфраструктуру

🧮 Введение прокси-сервисов в Data Plane может добавить расходы на обработку сетевого трафика -> влияет на производительность

Пример: Envoy Proxy, используемый в качестве прокси во многих Service Mesh решений, может добавить дополнительные задержки в обработку запросов

🧮 Может потребовать дополнительных вычислительных ресурсов для работы прокси и Control Plane -> увеличение стоимость эксплуатации

Пример: при развертывании Linkerd2 на большом кластере, увеличивается нагрузка на инфраструктуру из-за работы множества прокси-сервисов. Это потребует доп ресурсы

🧮 Усложняется интеграция с существующими системами и приложениями. Особенно если сервисы не были изначально спроектированы с учётом использования Service Mesh


📎 Материалы
1. Что такое service mesh простыми словами
2. Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии
3. 5 самых популярных вопросов при внедрении service mesh в корпорации на примере Istio
4. Istio Service Mesh: как упростить управление микросервисами
5. Что такое service mesh, когда внедрять, альтернативы Istio и другие ответы экспертов с АМА-сессии Слёрм по service mesh
6. Введение в Service Mesh: основные функции и преимущества
7. Большой обзор Service Mesh: часть первая | часть вторая


Видео
1. Service mesh. Знакомство с Istio и Envoy // курс «Инфраструктурная платформа на основе Kubernetes»
2. Istio Service Mesh в федеративных топологиях Kubernetes / Максим Чудновский (Сбертех)

#проектирование