Доклады

- Анализ проблем утилизации GPU в контексте подходов single-model и multi-model inference.
- Сравнительная оценка аппаратных и программных решений для оптимизации использования GPU.
- Глубокое понимание реализации концепции vGPU в Kubernetes и её архитектурных особенностей.
- Практические подходы к устранению дефицита CPU, возникающего при перераспределении ресурсов GPU.
- Рекомендации по эффективному управлению ресурсами GPU в контейнеризированных окружениях.

Поговорим о том как внедрить лучшие SRE практики.
Как избавиться от избыточного мониторинга, и контролировать продукт с одного экрана.
Реализация работающего маппинга в высоконагруженном приложении.

Что такое семплирование и зачем оно нужно?
Метрики и трейсы на основе семплированных данных. Бесполезная игрушка или рабочий инструмент?
Head vs Tail. Отличия и сценарии использования.
Реализация и алгоритмы head-based семплирования.
Реализация и алгоритмы tail-based семплирования. Подводные камни и способы их обхода.
Применение семплированных трейсов в разборе реальных инцидентов.

В этом докладе (похоже, что впервые на русском языке) мы поговорим о Puppet Bolt - системе оркестрации из экосистемы Puppet, но достаточно универсальной, чтобы использоваться и вне её. В первой части доклада будет дано краткое введение в Puppet Bolt. Во второй части будет представлено несколько примеров использования — как обычных, так и весьма нестандартных.

Netbox - точка истинности или стейт

Что выбрать в качестве источника правды об инфраструктуре? А если инфраструктур несколько? А еще у нас несколько разных гит и разные подходы по формированию гит репозиторием где необходимо использовать знания об инфраструктуре - тут оставлю вопрос открытым. У нас netbox и все :) анализ и выбор это отдельная тема. Оставлю на ваше самостоятельное исследование.

Netbox как инструмент по хранению знаний про железную часть инфраструктуры и про виртуальную часть. ИП адреса, кабели, серверы, стойки и прочее. Сразу есть API по работе со всем этим.


Дает ли внедрение ощущение спокойствия и точки истинности?
Система по хранению информации - Netbox
Синхронизация информации из реальной инфраструктуры в Netbox и уведомление о не соответствии.
Процесс работы с инфраструктурой - нет в Netbox нет в инфраструктуре. Создаем объект в Netbox и на основе данных из netbox создаем реальный объект инфраструктуры

Netbox дает информацию начиная с групп серверов. Выше уже другая система, Backstage - информация о продуктах, информационных системах и на каких они группах серверов работают

Какие проблемы сейчас решаем в использовании Netbox в нашей инфраструктуре
- Облако и невозможность использования ansible для создания и управления конфигурацией ВМ. Как подружить terraform и получение данных о ВМ из Netbox, да еще Netbox практически «стейт»
- Многие продукты инфраструктуры хотят в Netbox хранить свои переменные, но в Netbox нет нормальное ролевой модели
- Netbox и масштабирование нагрузки на него

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

цель данного воркшопа на базовых примерах показать настройку OIDC коннектора для инфраструктурных сервисов через кейклок
разберем основные сущности в кейклок - realms, clients, client scopes, users, roles, groups
разберем аутентификацию в графане через кейклок

Puppet остается одним из основных инструментов подхода IAC. Информации о нем в русскоязычном Интернете продолжает недоставать. Мой доклад призван восполнить некоторые пробелы, дать как вводную информацию, так и погрузиться на глубину. На примере Авито мы рассмотрим особенности администрирования инфраструктуры и обсудим наши собственные инструменты для оптимизации работы с Puppet. Доклад хорошо иллюстрирует, что не всегда важно какой инструмент вы выбираете, а как вы адаптируете его под свои нужды.

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

В этом докладе я хочу рассказать про наш опыт ускорения релизов и стандартизации этого процесса в сервисах Mail.ru и
поделиться подходами и инструментами, которые практически каждый сможет внедрить в собственные проекты.
– Почему мы за это взялись
– Как правильно организовать выкатки? Какие есть подходы и что выбрали мы
– Как устроен пайплайн: сборки образов, мерж веток, джобы, механизм раскатки, виды апрувов и другое
– Как мы следим за пайплайном: графики, алерты и нотификации
– Особенности организации пайплайнов в GitLab CI
– Результаты, которых мы достигли, и ближайшие планы по развитию
– Как внедрить себе

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

Расскажем наш подход:
- итеративное создание DRP - от частных планов систем к общему плану бизнес-услуги
- чеклист анализа системы и создание плана восстановления
- ключевое - восстановление основной функциональности, точка готовности системы
- общий план восстановления бизнес-услуги и работа с зависимостями
- планы требуют учений (бумажных и реальных)
- изменяем архитектуру систем / услуг
- доопределяем риски, их источники и признаки их реализации
- выравниваемся с требованиями регуляторов
- услуги и системы динамически изменяются - внедряем гигиену SRE команд по поддержке планов в актуальном состоянии

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

Методы управления инфраструктурой развиваются: от ручной конфигурации и bash-скриптов до подхода Infrastructure as Code (IaC), декларативного (Terraform) и библиотек описания инфраструктуры (AWS CDK, Pulumi, TFCDK). Однако сложность и объем инфраструктуры растут быстрее, чем появляются новые инструменты.

Относительно новая концепция Infrastructure from Code (IfC) создает инфраструктуру непосредственно из кода приложения, интегрируясь с ним или анализируя его для автоматического определения инфраструктуры.

В докладе мы пройдем сложный путь становления инструментов управления инфраструктурой. От обычных скриптов до IfC. И разберемся, что такое относительно новый IfC, его преимущества и недостатки, отличия от IaC и его дополнения.

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

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

Представь: ты видишь как сервисов в компании становиться больше, команд больше, логов больше. И вот уже есть инженеры, которым нужно находить и понимать логи многих сервисов. Какие у нас варианты?

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

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

Я расскажу как в прошлом году мы реализовали унифицированную работу с логами с применением "готовых правил дорожного движения" из OpenTelemetry на базе Vector.dev и Clickhouse, какой опыт мы получили и как развили это решение.

В этом докладе расскажу про DevOps сообщество Сбера, посмотрим, что поменялось по сравнению с прошлыми моими выступлениями. Какие задачи сейчас решает сообщество. Кратко расскажу про реальное применение практик Platform Engineering, Internal Developer Portal и текущие вызовы в этих условиях для Operational Enabling Teams. Как обстоятельства повлияли на органичное изменение парадигмы и переход от подхода DevOps-инженер в каждой продуктовой команде к подходу сервисные DevOps команды в Трайбе. Как Operational Enabling Teams помогли сервисным DevOps командам. И традиционно по всем затронутым темам сделаю обзор граблей на которые мы наступили, какие надежды оправдались, и какие решения привели к серьезным вызовам.

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

Что нужно, если ты хочешь учить людей техническим навыкам, например, разворачивать Kubernetes или повелевать Docker? А еще, хочешь это делать онлайн?

Ну совершенно точно нужно обеспечить ученикам комфортную, технически исправную и одинаковую среду обучения. Потому что у одного MacBook на М2, а у второго ThinkPad, который ему в наследство оставил дедушка с процессором i386. Как ты не пиши требования к оборудованию, обязательно где-то что-то будет не так.

Совершенно точно нужно помогать ученику. Ну вот пишет он "kubeadm init ..." и делает опечатку в параметре "--pod-network-
cidr": преподаватель увидит это моментально, а глаз ученика с этим будет бороться долго.

Кажется, не выглядит как работа для DevOps? Нет, выглядит.

Для каждого ученика создадим LXC-контейнер. Или виртуалку. А что удобнее? Ну, для курса по Kubernetes удобно контейнер, чтобы в нем запустить VirtualBox и создавать виртуалки, по количеству нод. А в курсе по Docker лучше дадим виртуалку и будем в нее ставить, что нужно.

Дальше к этому контейнеру мы сделаем VNC. Но он небезопасен и не очень удобен, поэтому возьмем Guacamole и завернем это в TLS. А еще поставим Epoptes, чтобы преподаватель мог быстро подключаться к ученику.

А теперь, мы это автоматизируем. Почему? Потому что если ты проводишь 50+ групп в год, то разворачивать тебе все эти штуки должен бездушный CI/CD-пайплайн. На чем? Конечно, на Astra Linux.

Создать кластер Kubernetes – не самая сложная задача, но что делать, если их требуются тысячи?

Расскажу о том, как мы в Сбере пришли к идее создания Managed-сервиса и как это позволило не сойти с ума и справиться с обслуживанием огромного количества кластеров. Также разберёмся в ключевых особенностях и плюсах нашего решения и посмотрим на его возможности.

Все мы пользуемся DNS, но не все автоматизируют управление. От этого появляются во внутренних (и иногда внешних, sic!) инструкциях "echo '1.2.3.4 my.demo' >> /etc/hosts".
В докладе расскажу и покажу с ready to use примерами:
- автоматизацию управления DNS-зоной через git;
- как сделать собственный no-ip сервис в закрытой сети;
- плагины CoreDNS для Kubernetes;
- собственный плагин для CoreDNS - это просто.

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

Чем дальше, тем больше мы говорим о платформах и платформенных командах. Где-то рядом с платформенными командами, в далёком космосе летает книга Team Topologies. На жестокой земле же, среди людей нам не до того: то тут, то там горит, разработчики тупят, тестировщики хотят странного, а безопасники закручивают очередную гайку. Отдел эксплуатации сидит за стеной из регламентов и отстреливается тикетами. В этой битве нет победителей, только выгоревшие. Но что если решение проблемы ближе, чем мы думаем?
В докладе расскажу как вывернуть инфраструктурный тулинг мехом наружу, перестать страдать, и понять что первые шаги к плаформе уже сделаны.

Больше 6 лет назад я с небольшой командой из пяти инженеров начал строить ИТ-платформу в Туту. Мы создавали ИТ-платформу с нуля: у нас был гринфилд, картбланш на любые решения и большой кредит доверия от руководства компании. Интерес разработчиков компании к платформе был огромным: до этого архитектура была монолитной, а мы начали создавать новый мир Kubernetes для микросервисов с новыми инструментами, технологиями, процессами и практиками. В итоге у нас получилась современная и хорошо автоматизированная ИТ-платформа, которая обеспечивает всем необходимым разработку в Туту.

Из доклада вы узнаете, какие архитектурные и технические решения мы используем в нашей ИТ-платформе в масштабе 2000 продуктовых микросервисов, 600+ пайплайн-ранов в день в 5 baremetal-кластерах и 4 разных ЦОДах. В докладе так же затронем темы: почему мы используем Tekton для пайплайнов, какие решения кардинально улучшили DX и зачем нам оператор для проверки качества сервисов и проектов.

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

Когда у тебя большая распределенная инфраструктура выдавать доступы разработчикам, лидам, аналитикам ставоится все интереснее. Конечно же у нас есть OpenVPN, Wireguard и прочие всем знакомые инструменты, но они подходят не всегда.
В рамках своего доклада я расскажу как мы Магнит Омни:
-- решили вопрос предоставления доступа для разработчиков/лидов/etc. для разных окружений
-- как мы научились выдавать консистентный доступ в разные окружения
-- как нам удалось сократить время выдачи доступов с нескольких дней до 15 минут
-- как мы автоматизировали настройку Netbird VPN и превратили его в платформенный
-- и про "факапы" я тоже расскажу

Платформы - тренд последних лет. Многие компании идут в их разработку, но положительного эффекта не наблюдают. Либо вообще выкидывают через некоторое время. Хочется порассуждать, а когда и, главное, зачем такие платформы нужны (как IDP, так и внутренние бизнесовые) и обсудить, что может привести их к провалу.

Уже давно не секрет, что в Т-Банк есть своя observability-платформа Sage.
Внутри банка, мы предоставляем сервис мониторинга, у которого ежедневно более 5000 активных пользователей(DAU).

И как это принято, у нас есть SLA с нашими пользователями,
но "как понять предоставляем ли мы сейчас услугу или нет?" - именно с этого вопроса начинатся мой рассказ о построении SLOs/SLIs для нашей платформы Sage. Метрики для метрик.

На примере домена метрик в Sage, в своем докладе я расскажу:
* как мы измеряем надежность;
* как мы строили SLOs/SLIs;
* как мы работали с нашими клиентами, чтобы выявить их ожидания от нашей надежности;
* как выглядит наша подсистема метрик на сегодня

Доклад будет интересен как экспертам, так и людям, которые только погружаются в тему построения SLOs/SLIs

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

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

В своём докладе я поделюсь, как мы прошли путь от неэффективных и бессмысленных метрик, родившихся из попыток «угодить всем», к архитектурно обоснованным SLA, которые реально работают. Вы узнаете, почему классические SLI вроде Latency и доступности прокси могут быть пустой тратой ресурсов, и как инженерное видение помогло нам найти баланс между техническими возможностями и потребностями бизнеса.

Я расскажу, как анализ компонентов платформы позволил выстроить последовательность работы, связать это с метриками и алертами, и создать план внедрения адекватных SLA. Поговорим о непростых технических компромиссах, неожиданностях, и почему инженерные лидеры не должны бояться отказаться от "фальшивых" метрик. Этот доклад — для тех, кто хочет научиться строить SLA, которые защищают ваши системы и бизнес, а не становятся причиной бессонных ночей.

В системах с тысячами серверов отказы неизбежны: выходят из строя диски, сервера, целые дата-центры, не говоря уже о сбоях ПО.

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

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

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

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

Два извечных вопроса: кто виноват и что делать? В своем докладе я хочу рассказать про культуру без обвинений и смещение фокуса с вопроса "кто виноват?" на "что делать?"
Чаще всего виноваты именно процессы, а не люди и внедрение культуры без обвинений может сильно поднять моральный дух и сплоченность команды
Посмотрите, со всех сторон нам рассказывают про невероятный кадровый голод. Компании бьются за людей, рекрутеры и HR-специалисты строят сильный бренд, придумывают кучи плюшек, но так ли они нужны в токсичной атмосфере? И что происходит дальше, после испытательного срока?
Я порассуждаю о любви к ближнему своему, о психологии и о том как это все связано с инцидент-менеджментом

Вынесем операционные процессы сервисной команды из-за закрытых дверей.

Расскажу о процессах, которые удаляют от ситуативных реакций и фокусируют на пользе:
- Доставка ценности: Как мы подошли к организации работы с собственной поставкой, целеполаганием и синхронизацией со смежниками (разработка)
- Регулярные каденции: Почему ретро полезно в SRE команде? Как мы используем его с инцидентами и привлекаем смежников?
- Управление аварийными ситуациями: Как подготовиться к "пожару" ДО принятия сервиса на поддержку и минимизировать влияние человеческого фактора на его решение;
- Нагрузочное тестирование: Типичный инструмент для продуктовой команды - когда и зачем он полезен SRE?
- Дежурства: Стратегии организации, как построить работу с дежурствами так, чтобы команда не выгорала
- Онбординг: Когда в компании много инструментов, в команде десяток сервисов и несколько десятков контактов - новички очень дороги, поделюсь лайфхаками, как нивелировать эти проблемы
- Выхлоп из деятельности команды: ранбуки, постмортемы и другие артефакты - как организовать их полезно и нужно ли их выпускать

Я — Engineering Manager, и я из той самой касты людей, которые достают вас вопросом "Какой статус?".
Поверьте, на самом деле я не хочу его задавать. И я не хочу мешать вам работать. Давайте я расскажу вам, как сделать так, чтобы я от вас отстала.

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

Расскажу о трехлетнем опыте использования Канбан-метода в небольшой команде DevOps-инженеров. Отвечу на самый главный вопрос "Зачем?" Расскажу с чего начали, как провели воркшоп STATIK (Systems Thinking Approach to Introducing Kanban) - cистемный подход к применению Канбан-метода, какие инсайты обнаружили в ходе STATIK и чем он помог. Поделюсь возникшими трудностями на пути применения Канбан-метода в нашей команде и как их решали, чего достигли и что не получилось. Покажу какие метрики эффективности выполнения задач мы считаем и насколько помогают для этого Канбан-инструменты. Обсудим, что может помешать прозрачности работы и как работать с заказчиками, вырабатывать правила и достигать соглашений.

В чем основное различие Enabling-команд и команд с "Инженерами на час". Наше видение того, какие типы команд наиболее востребованы в Enterprise. Эти типы команд взаимоисключают друг друга или можно построить что то среднее? Наш опыт построения Enabling-команды.

On-premise инсталляции K8s и похожи и непохожи на обычные облака. Базовые механизмы одни и те же, но условия эксплуатации совершенно другие. В on-premise невозможно быстро докупить ресурсы, чтобы повысить эффективность использования ресурсов надо гибко управлять тем что есть в наличии. Нам казалось что самое сложное это придумать и реализовать эффективный алгоритм перераспределения ресурсов, но оказалось что это только начало пути. В докладе подробно расскажем про все сложности которые встретились на пути запуска собственного on-premise автоскейлера.

Этот доклад – не про технологии ради технологий. Он про создание эффективного, человечного и мотивирующего онбординга, создаваемого руками разработки для того, чтобы новичок становился частью команды и впитывал ДНК компании. Я уверена, что практики, подтвержденные реальными кейсами, помогут вам переосмыслить процесс онбординга и сделают его полезным не только для новичков, но и для всей команды.

В современном мире онбординг – это не просто введение нового сотрудника в курс дела. Это ключевой этап, от которого зависит, насколько быстро и эффективно новичок (и при этом не важно, это сотрудник новый для компании или перешедший из другого подразделения) станет полноценной частью команды. Я хочу поделиться с вами методиками, которые мы успешно внедрили в нашей компании и которые могут кардинально изменить ваш подход к онбордингу. А главное, почему НУЖНО взять ответсвенность за онбординг самой команде и почему команда может находить в этом процессе ценность для себя.

Традиционно процесс онбординга требует значительных ресурсов со стороны HR-отдела. При этом эффективность онбординга напрямую влияет на интеграцию нового сотрудника в команду и его дальнейшую продуктивность.

В докладе будут рассмотрены темы: передачи ответственности команде, процессы выбора и поддержки бадди для новичка, составления плана онбординга его актуализации и геймификации (руками команды), практика self-assessment - как базисная составляющая процесса.

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

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

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

Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе!

В своих коротких, но зажигательных выступлениях спикеры поделятся настоящими историями фейлов. Без записи, без трансляции, без комплексов.

Канбан-метод — это метод для постоянного совершенствования любых сервисов, связанных с интеллектуальным трудом, таких как разработка ИТ-продуктов. Канбан-метод состоит из более 150 инструментов и практик, одним из которых является STATIK (Systems Thinking Approach to Introducing Kanban) - cистемный подход к применению Канбан-метода. STATIK помогает начать использовать Канбан-метод и выявляет многие неочевидные факты и детали Вашего сервиса. В ходе воркшопа мы разберем основные шаги STATIK и попробуем спроектировать Канбан-систему. Все практические задания и теория, как Вы догадались из названия воркшопа, будут метафорическими, и построенными на основе известного мультфильма "Кунг-фу Панда". После воркшопа Вы сможете применить STATIK в своем сервисе и начать эволюционные улучшения. Так что - вперед, мир Кунг-фу и Канбан ждет Вас!

Расскажу о нетворкинге (не путать со смол-током):
* ЗАЧЕМ?!
* что это за общение и как быть целеустремленным в любой коммуникации,
* с чего начать разговор,
* чем продолжить,
* как закончить,
* как обменяться контактами,
...произведя правильное впечатление.

Участники мастер-класса унесут с собой
* наброски рассказа о себе несколькими способами,
* понимание ЧТО, КОМУ, О ЧЁМ и КОГДА рассказывать,
* какие и кому задавать вопросы.

Astra Linux содержит ряд инструментов для обеспечения информационной безопасности, которые не всегда хорошо понимаются. Например, мандатный контроль целостности (МКЦ), который совершенно не про контрольные суммы, а про то, что даже root не всегда root. Или приносит с собой мандатный контроль доступа (МКД), который крайне непросто понимать тем, кто не занимался этим вопросом никогда.

Посмотрим на практике, что означают механизмы МКЦ и МКД, своими руками потыкаем в Astra Linux и научимся понимать, где и что нам нужно из этого использовать.