Доклады секции "Эксплуатация систем"

Что мы знаем о надежности дата-центров?

На сайте нам расскажут про то, как все круто зарезервировано, соответствует какому-нибудь TIER и аптайм за последние N лет. Откроем SLA и увидим там две девятки! Три девятки! Или даже четыре девятки! Лучше, конечно, пять девяток.

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

Давайте разберемся, что значат эти самые девятки, как они считаются, что может сломаться в ЦОДе и сколько времени может занять восстановление вашего проекта.

Как варить Nginx, чтобы не только узнать о том, что прилетел DDoS, но и выдержать его.

* Что, вообще, можно поменять в systemctl и зачем?
* Мониторинг Nginx: почему VTS — это круто, но медленно, зачем нужен angie и какие еще есть модули.
* Способы сбора access log.
* По каким ключам рейтлимитить? JA4 — что это за зверь?
* Кэш как таблетка от DDoS (но не серебряная пуля).

Доклад, который будет интересен SRE и DevOps-инженерам, бэкенд-разработчикам и техлидам. Поговорим о телеметрии: формат OpenTelemetry, Qryn и Coroot. Как внедрять, как расследовать инциденты и как сделать свою высоконагруженную систему с̶ч̶а̶с̶т̶л̶и̶в̶о̶й̶ работающей.

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

Postmortem-анализ — ключевой процесс для понимания причин сбоев и предотвращения их повторения на ИТ-ландшафте. ИТ-системы становятся сложнее за счет потребления сервисов друг друга (особенно это критично в экосистеме). Ручной анализ сбоев таких систем требует все больше времени и ресурсов и перестает соответствовать ожиданиям бизнеса: быстрое восстановление и глубокий анализ для предотвращения повторения.

В своем докладе поделюсь эволюцией этой практики у нас в компании: создание централизованного подразделения Mission Control Center, формализация подхода для экосистемы; уход от табличек Exсel/Word в пользу удобных инструментов; автоматизация простейших действий.

Все это позволило нам ускорить процесс анализа критичных инцидентов (с 4-6 часов до 1-2) за счет автоматизации рутинных действий. А введенный контроль качества проведенного анализа критичных инцидентов позволил продуктовым командам быстрее восстанавливать работу критически важных систем (на 26% год к году).

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

Техплатформа Городских сервисов обеспечивает работу Яндекс Такси, Еды, Лавки и Доставки. Для каждого из этих направлений важна стабильность и надежность. И поэтому один из ключевых аспектов проектирования дашбордов для более чем 2000 микросервисов – их роль в диагностике и расследовании инцидентов. Дашборды должны помогать оперативно выявлять проблемы и их причины, что позволяет ускорить реакцию на инциденты и минимизирует время простоя. В этом контексте важно не только предоставить пользователям данные о текущем состоянии системы, но и организовать информацию так, чтобы она помогала быстро разобраться в ситуации и найти источник проблемы.

В своем докладе я подробно остановлюсь на следующих пунктах:
1. кто и как пользуется микросервисными дашбордами;
2. как генерируются дашборды для микросервисов;
3. какие требования мы предъявляем к дашбордам;
4. как выглядит дашборд микросервиса в Городских сервисах Яндекса.

Наша команда в СберТехе разрабатывает и сопровождает СУБД Platform V DataGrid (aka Apache Ignite SberEdition), которая используется в Сбере в 200+ системах и развернута на 5000+ серверах.

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

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

Будет практика. Настоятельно рекомендуем взять ноутбук.

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

Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали, с чего начать? Приходите — покажем, расскажем и научим основополагающим вещам в этом нелегком деле!

На нашем workshop мы разберем те кирпичики, из которых построены все сети как под K8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
* набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux;
* устройство сетевых namespace в ядре linux;
* виртуальные сетевые интерфейсы: виды, особенности, применение;
* OpenVSwitch: лучший сетевой швейцарский нож.

Разработка программного обеспечения и его эксплуатация — это не только масштабирование, автоматизация и передовые технологии, но и постоянная борьба с неожиданными отказами, ошибками и нестандартными ситуациями. В этом докладе я расскажу о самых запоминающихся «граблях», на которые довелось наступить за 20 лет в IT.

Мы разберем реальные кейсы фатальных ошибок, неочевидных проблем и нестандартных решений. От DNS-кешей, которые синхронно отваливались, до неожиданного поведения автоскейлинга в критических ситуациях. Расскажу, как безобидные архитектурные решения приводили к каскадным проблемам и почему некоторые способы резервирования делают систему более хрупкой. Поговорим о конкретных кейсах и их решениях, включая забавный случай с «пугливым багом» в видеозвонках и о серьезном инциденте с простоем корпоративной инфраструктуры.

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

Мы в МТС давно поняли, что мониторинг отдельных хостов, приложений или баз данных не дает полного представления о качестве сервиса для пользователей и непрозрачен для менеджмента. Но переход к мониторингу полноценных бизнес-сценариев в масштабах 400+ продуктов оказался непростым и полным сюрпризов.

В докладе мы поговорим о том, как нам удалось описать ключевые сценарии использования наших продуктов с помощью 3500 индикаторов качества SLI и установить для них разумные целевые значения SLO. Поделимся опытом создания единого дашборда здоровья продуктов для менеджмента и собственного интерфейса для настройки расчета индикаторов на базе VictoriaMetrics и PromQL. Расскажем о том, как мы преодолели не только технические, но и организационные трудности при внедрении нашего подхода в МТС.