Доклады

Кажется, что важность надежности продуктов – вещь очевидная. Ни один из владельцев продуктов не ставит цель по созданию продукта, который будет постоянно “падать”. Однако на деле оказывается, что для обеспечения надежности то времени не хватает, то компетенций. Чтобы решить эту проблему в МТС была создана платформа Operations или OpsPlatform. В докладе поделимся опытом создания платформы и как мы за пол года внедрили платформу во все MC/BC продукты экосистемы, какие эффекты получили, и что о нас думают крупнейшие продукты экосистемы.

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

Что нужно, если ты хочешь учить людей техническим навыкам, например, разворачивать 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-сервиса и как это позволило не сойти с ума и справиться с обслуживанием огромного количества кластеров. Также разберёмся в ключевых особенностях и плюсах нашего решения и посмотрим на его возможности.

Несколько лет назад я столкнулся с задачами по мониторингу киберинцидентов, нам приходилось внедрять инструменты безопасности для интеграции с Security Operations Center. Это помогло нашему проекту реагировать на угрозы безопасности на ранних стадиях и оперативно предотвращать инциденты. Постоянный рост числа подключенных устройств и сложность их взаимодействия требуют новых подходов к защите данных и предотвращению угроз.
Я уверен, что мой доклад поможет участникам глубже понять важность SOC, научиться эффективно использовать современные инструменты и технологии для мониторинга и реагирования на инциденты. Также выступление посвящена роли и значимости центров обеспечения безопасности (SOC) с применением современных методов по обеспечению кибербезопасности. Мы рассмотрим основные функции SOC, начиная с мониторинга и заканчивая реагированием на инциденты. Будет представлен анализ актуальных угроз, в том числе данные о масштабах и мотивации кибератак.
Доклад также охватит технологические вызовы, связанные с обработкой и нормализацией данных, будет рассмотрена SIEM-система Splunk.

Далеко не многие знают как ломать Kubernetes, а тем более как ломать Куб, когда его нет. В докладе я поделюсь своим опытом проведения аудита кластеров еще на стадии проектирования, когда на руках есть только Cluster API манифесты будущих Kubernetes. Подсвечу интересные моменты, что там можно найти, а чего нельзя, и конечно же расскажу как автоматизировать этот процесс.

Язык программирования Go предоставляет возможности, которые значительно оптимизируют разработку инструментов для DevSecOps и Red Team. Он отличается простотой, что облегчает его изучение и использование. Компиляция программ на Go для Windows, Mac и Linux из единого исходного кода позволяет экономить ценное время. Именно поэтому злоумышленники активно используют Go для создания современных вредоносных программ. Мы будем моделировать эти угрозы, чтобы лучше понять, как защищаться.

Hashicorp Vault является стандартом де-факто хранения чувствительных данных. Интегрируется он примерно с чем угодно и, естественно, с другим фактическим стандартом размещения нагрузки - Kubernetes.
Инструментов для интеграции Hashicorp Vault с Kubernetes существует немало и каждый обладает своими примуществами и недостатками, поэтому в докладе рассмотрим и сравним популярные инструментов доставки секретов из Hashicorp Vault:
- External Secrets Operator
- Hashicorp Vault Secrets Operator
- Hashicorp Vault Agent Injector
- Hashicorp Vault CSI Provider
- (Banzai Cloud) Bank Vaults-Vault Secrets Webhook
Для каждого из интрументов приведу пример настройки, рассмотрю как именно доставляется секрет до приложения и принцип работы инструмента. Сравню инструменты с точки зрения механизмов ротации секретов, а также удобства использования. Подсвечу ограничения инструментов.

Техписы всё время пишут не то? Как ни ставь задачу, результат всё равно будет хуже, чем минимальные ожидания? Ну и ты уже готов смириться с бесполезностью техписа? Зря! Вам просто нужно научиться говорить на одном языке и техпис станет knowlege manager на минималках.
Мой доклад о том, как это сделать и выжить.

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

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

Воркшоп: Разработка инженерных практик для крупных компаний

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

Что вас ждет:

- Обсуждение лучших практик: Узнаем, как глобальные компании адаптируют и внедряют современные подходы к разработке и эксплуатации (CI/CD, DevOps, SSDLC, API-first, cloud-native).

- Инструменты и процессы: Разберём ключевые инструменты автоматизации, мониторинга и их интеграцию в ежедневные рабочие процессы.

- DORA метрики и RED подход: Погрузимся в метрики производительности команд разработки и эксплуатации для достижения высоких бизнес-результатов.

- Практическая часть: Совместная разработка методологии внедрения практик в масштабах компании. Создадим план действий для выстраивания инженерной культуры и повышения зрелости процессов.

- Реальные кейсы: Изучим примеры компаний, успешно реализовавших переход к продвинутым инженерным практикам, и разберём их на конкретных примерах.

Для кого этот воркшоп:

- Руководители технических команд
- DevOps инженеры
- Технические лидеры и архитекторы
- Инженеры по качеству и безопасности

Результат:

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

Доклад посвящен организации канареечного деплоя при GitOps. Обсудим организацию GitOps-репозиториев, применение GitFlow, различные стратегии деплоя, интеграцию Argo Rollouts с ArgoCD и безопасное выполнение миграций.
Доклад будет полезен инженерам, работающим с Kubernetes


- Организация GitOps-репозиториев ArgoCD
- Flow CI/CD
- Стратегии деплоя
- Интеграция Argo Rollouts с АrgoCD
- Как подружить канарейку с миграциями

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

Расскажем про то, как мы решали проблему целостности собираемых docker-образов для stage и prod окружений, когда они собираются и деплоятся независимо друг от друга. Ведь когда сборка происходит независимо, есть вероятность того, что для stage и prod будут собраны разные образы с разными системными зависимостями.

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

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

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

Доклад посвящен популярному GitOps-инструменту ArgoCD, который помогает унифицировать и автоматизировать процессы развертывания приложений в Kubernetes. Обсудим различия между pull и push моделями, особенности установки и преимущества ArgoCD, а также организацию GitOps-репозиториев и использование Flow разработки. Кроме того, кратко обсудим организацию доставки секретов для такой модели.

- Сравнение pull и push моделей
- Особенности установки ArgoCD
- Преимущества
- Организация GitOps-репозиториев
- Flow CI/CD
- Организация контроля доступа
- Организация доставки сенситив данных / Секретов

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

Из доклада вы узнаете о проблемах и наших решениях автоматизации производственного конвейера на
примерах.
• Автоматизация ручных действий на всех этапах от сборки до ПРОМа.
• Автоматизация проверок Quality Gates (включая ИБ) в джобе CI.
• Реализация pipeline для разного стека на собственном движке Fulcrum с
использованием пакетного менеджера Helm и шаблонизации Synapse Service Mesh
/Prometheus.
• Особенности Jenkins CD в Enterprise, шардированное решение для него “Dream
Jenkins”(SberWorks).
• Переход из Jenkins в ArgoCD
• Реализация BlueGreen и Canary стратегии деплоя и его применимость в
зависимости от стека.
• Автоматизация ручных шагов производственного процесса с помощью сервисных
Pipeline для автоматического создания и изменения объектов релизной деятельности Jira.
• Оборачивание конвейера в «человеческий вид» с помощью оркестратора
оркестраторов DPM (SberWorks).

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

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

- В 2022 году с рынка хранилищ артефактов РФ ушли два ключевых игрока
- Мы, как и все, постарались исследовать возможность создать такое хранилище на OpenSource Nexus
- Поймали кучу граблей связанных с производительностю Nexusa и поняли, что их никак не обойти. Он вообще очень плохо подходит для больших команд, которые генерируют большую нагрузку
- Разобрались с лицензированием Nexus и поняли, что в РФ им не получится воспользоваться
- Поняли, что современное хранилище должно еще и безопасно хранить артефакты
- Приняли решение сделать свое хранилище с нуля на зарекомендовавших себя технологиях
- Релизовали хранилище артефактов, которое спобно работать в высоконагруженных системах
-Сделали это хранилище безопасным

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

Это доклад продолжение докладов про коллаборации, важность проектирования для DevOps(ов).

DevOps существует уже более 15 лет, но лишь немногие организации могут сказать, что успешно внедрили DevOps. Эксперты отмечают, что в компаниях процветают анти-паттерны DevOps, компании продолжают страдать от большого T2M, а взаимодействие Dev-Ops все так же создает сложности.
Доклад поможет компаниям-новичкам в DevOps не совершать ошибок, а остальным пересмотреть свой подход к построению DevOps. Рассмотрим типичные ошибки построения DevOps в организациях и как их решать, а так же теорию взаимодействия инженерных команд.

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

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

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

Несколько лет назад в Иви мы расформировали команды мониторинга и централизованной выгрузки релизов.
Причина: такая конфигурация имела несколько проблем.
Что мы сделали:
- функцию выгрузки релизов передали в продуктовые команды
- функцию мониторинга и 1-2 линии поддержки (сервисов) выполняем всеобщими дежурствами
...
Profit

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

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

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

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

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

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

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

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

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

Путь гипотез, проб, ошибок и ркзультатов
Проблематика больших распределенных по стране компаний.
Цели на этапе создания и контекст.
Метрики "измерения" ЦК и DevOps

Этап сообщества и создания пространства для общения + наставничество
> Результаты

Этап внутренних митапов + Выводы
> Организация PI Planning и EventStorming

Этап организации платформенной команды c шарингом участников
> Прекращение активности и мысли на счет Орг дизайна

Этап Оценок + стандартизации грейдов специалистов + Выводы
> Пересмотр подходов к оценке Senior+ специалистов

Этап трансформации проблемных продуктов + выбор новых инструментов
> предварительные выводы

Общие выводы и текущие функции ЦК
Про будущее - Технический арбитраж

Почему типовые карьерные треки не работают?
Опыт построения рабочего карьерного трека в компании Cloud.ru

Многие команды разработки за 15 лет существования Kubernetes внедрили этот инструмент в production как облачный сервис или bare-metal реализацию. В нашей компании bare-metal k8s стал основой внутренней платформы для разработчиков, которая должна быть отказоустойчивой, поэтому он живёт в нескольких цодах. На докладе я поделюсь:
- Экспертизой в расселении Kubernetes в разные цоды
- С какими проблемами мы столкнулись при внедрении DevOps практик на такую архитектуру
- Как мы решали вопросы межцодной коммуникации между ресурсами внутри K8s и контроля их доступности
- Какие образом можно обеспечить доступность ресурсов при сбоях в облаке или датацентре
- Какие есть варианты для безопасной коммуникации в межцоде

Потраченные миллионы на DevOps ради всего лишь мнимого слова Time-to-Market?

Безостановчный рост бюджетов на "Не понятно что?"

Или текущие суровые реалии дерби, под названием DevOps?

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

И в рамках доклада затронем тему Platform Engineering - кровавый энтерпрайз, который будет стоить миллиарды и иметь нулевой ROI.

Предоставить пользователям аналитическую базу данных - это не просто поднять гринплам, кликхауз или купить на них подписку. На примере внедрения в платформу данных базы нового поколения Starrocks (https://www.starrocks.io) расскажу про обеспечение необходимого минимума фунционала и автоматизации для потребителей - инженеров данных, инженеров-аналитиков или разработчиков dwh.
Постараюсь ответить на вопрос - каким требования должны удовлетворять инсталляции и сами движки баз, особенно если вы как поддержка хотите спать по ночам и не вздрагивать при слове обновление, блокирующие операции ddl или отказ мощностей.
В докладе будет k8s (куда же без него в современном мире), сервисы миграций, аутентификации и авторизации, dbt как сервис - и все это приправлено щепоткой golang и gitlab-ci.

Я хочу рассказать как мы выстраивали разработку своего Linux дистрибутива для платформ на базе процессоров Эльбрус. Про выбор м/у полностью нативной средой или гибридной (Эльбрус+x86) и почему мы выбрали путь гибридной системы. Какой инструментарий мы тестировали и на чем в итоге остановились. Из каких частей строилась наша среда разработки.
Ну и конечно пару-тройку слайдов про сами Эльбрусы и чем они отличаются от привычных нам процессоров.

Современные тренды направлены на внедрение искусственного интеллекта для выполнения рутинных задач. К чему может привести страсть автоматизировать всё вокруг? Порассуждаем об этом на докладе

Для корпоративных систем телекома и не только требуется высокая доступность с неизменным качеством.
В докладе говорится о том, как в сервисах МТС применяются практики SRE, проводится параллель с практиками в Google, основываясь на Google SRE book.
Автор является CTO одной из высоконагруженных телекомовских платформ с повышенными требованиями к скорости и надежности, где четко определен SLO и существуют обязательства перед потребителями. На примере данной системы в докладе развивается мысль чем и как обосновывается достижимость SLO по доступности в 3,5 девятки. Приводится пример того, какие потребуются мероприятия и какими станут трудозатраты, если потребуется повысить доступность до 4 девяток и если более. Как это повлияет на архитектуру, инфраструктуру и команду эксплуатации. И почему подавляющему большинству сервисов в реальности не потребуется более высокого процента доступности чем 99.95.

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

1) Самый часто используемый вами тип метрики будет DistributionSummary
2) Дефолтные конфигурации регистрируют десятки готовых метрик за вас
3) Micrometer, как заявляют его разработчики, является фасадом для JVM фреймворков, но он таким не совсем является, в прочем он и не только фасад

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

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

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

Сo-pilot в разработке — тренд последних лет. Однако этот трек не единственный в ландшафте AI-оптимизации внутренних процессов в бигтехе.

Вместе c коллегами из Яндекса, VK, Т-Банк, Truffle и Авито обсудим:
1. как в целом можно замерять эффективность производственного процесса — овервью и типичные трудности;
2. как вовлечь разработчиков в использование новых инструментов, какие механики использовать для масштабирования внутри компании;
3. как можно использовать AI в разных ролях: поддержки, дизайна, аналитики, солюшн-архитектуры, тестирования;
4. когда это становится cost-effective.

Поищем общие и конфликтующие позиции, послушаем success-stories из первых рук.

Можно доклад, но круче будет собрать дискуссию и похоливарить на эту тему.

1. Краткая история метрик оценки разработки: строчки кода и прочее
2. DORA, QUANT, SPACE
3. Что делает и куда смотрит сбер.
4. Почему метрики для оценки разработки - разрушают команду
5. Как одна метрика разрушила всю команду.
6. А можно ли контролировать 800+ инженеров без метрик?
7. Почему метрики - это правильно и хорошо

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

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