Изменения

'''= Павел Грязнов. Что дженерики нам готовят''' — рассказ про дженерики в Go в сравнении с python, с примерами кода и метриками производительности. Интересно. Заодно освежил вообще эту тему.=

'''Александр Кривощеков, Яндекс-Еда. Паттерны отказоустойчивой архитектуры.''' Много конкретных шаблонов, обеспечивающих устойчивость работы сервиса Рассказ про дженерики в реальной среде, Go в которой сеть и сервисы сбоят или медленно отвечают по разным причинам. В докладе — постепенное усложнение модельного сервиса разными фичами — рейтинги, статистика, сложная и точная алгоритмика вместо легкойсравнении с python, с соответствующим усложнением применяемых шаблонов: retry, требующий для set идемпотентных идентификаторов, deadlines, rate и burst limiting, circuit breaker, rich client, dummy или pumpkin. C примерами кода и разными стратегиямиметриками производительности. Включая способы вынести такую работу с запросами с прикладного на базовый уровеньИнтересно. Хотя часть он рассказать не успелЗаодно освежил вообще эту тему.

: '''Дополнение от Александра''' по отчету. Мне самому очень жаль, что я не успел полностью уложиться в тайминги. Однако сам доклад тоже отказоустойчивый :), я уже выступал с этим ним на другой конференции, и там успел рассказать всё. Вот тут есть версия моего выступления где я рассказал и про Rich Client, и про Dummy: https://youtu.be/8GlwkWxf3hk?t=6866 (начало: 1:54:26). Там чуть проще слайдыАлександр Кривощеков, делал их в power point. Но смысл и структура рассказа почти идентичны (я чуть больше делал упор на C++). Однако можно открыть в соседнем окне новую версию слайдов с интерактивными визуализациями и самостоятельно их полистать во время моего доклада: https://presentations.superpaintman.com/highloadЯндекс-foundation/2022/1 (лучше открывать с компьютера или планшета, на телефоне может выглядеть плохо). Возможно, те кто хотели бы увидеть полную версию, найдут это полезнымЕда.Паттерны отказоустойчивой архитектуры =

Много конкретных шаблонов, обеспечивающих устойчивость работы сервиса в реальной среде, в которой сеть и сервисы сбоят или медленно отвечают по разным причинам. В докладе — постепенное усложнение модельного сервиса разными фичами — рейтинги, статистика, сложная и точная алгоритмика вместо легкой, с соответствующим усложнением применяемых шаблонов: retry, требующий для set идемпотентных идентификаторов, deadlines, rate и burst limiting, circuit breaker, rich client, dummy или pumpkin. C примерами и разными стратегиями. Включая способы вынести такую работу с запросами с прикладного на базовый уровень. Хотя часть он рассказать не успел. '''Дополнение от Александра''' по отчету. Мне самому очень жаль, что я не успел полностью уложиться в тайминги. Однако сам доклад тоже отказоустойчивый :), я уже выступал с этим ним на другой конференции, и там успел рассказать всё. Вот тут есть версия моего выступления где я рассказал и про Rich Client, и про Dummy: https://youtu.be/8GlwkWxf3hk?t=6866 (начало: 1:54:26). Там чуть проще слайды, делал их в power point. Но смысл и структура рассказа почти идентичны (я чуть больше делал упор на C++). Однако можно открыть в соседнем окне новую версию слайдов с интерактивными визуализациями и самостоятельно их полистать во время моего доклада: https://presentations.superpaintman.com/highload-foundation/2022/1 (лучше открывать с компьютера или планшета, на телефоне может выглядеть плохо). Возможно, те кто хотели бы увидеть полную версию, найдут это полезным. = Никита Старичков. 1С:Предприятие — low-code платформа для цифровизации бизнеса.''' =  Представление 1С как платформы. В целом я это себе представлял. Но мне было интересно про три варианта разработки для мобилок: платформа для своих приложений, мобильный клиент и гибридный вариант, который может работать offline и online, когда для методов размечена возможность offline-рабты, когда реальный вызов бует после восстановления связи. Правда, серверная часть должна дополнительно решать конфликты отложенных вызовов в тез случаях, когда они возникают. И я не знал про Дата акселератор — собственное in-memory СУБД для OLAP. И был анонс 1С.Элемент — платформы для создания приложений, ориентирвоанных на конечного пользователя, которую, правда, начали разрабатывать в сентябре, и пока нет даже беты. Посмотрим, что из этого получится. А еще был любопытный пример — полная автоматизация на 1С белорусско-китайского автозавода Geely, включая, судя по всему, работу с оборудованием или тесную интеграцию с управляющими программами.

'''= Павел Лакосников из Авито. SLI/SLO/SLA в микросервисном приложении.''' Интересный разбор, что реально означают метрики отказоустойчивой работы. SLI, например, 99,99 % у AWS — это вовсе не гарантия. Это лишь целевая функция, нарушение которой трактуется как ошибка. И если нарушают сильно, то наступают последствия, например, если ошибок будет 1 % (то есть 99 вместо 99.99 — то вернут 30 %, а если 5 % ошибок (то есть 95 %) — то тогда полностью возвращают деньги за период. По сути SLI превращается в рекламную фишку высокой надежности. Дальше у нас SLO — реальная метрика, и SLA, где описаны последствия. Дальше Павел рассказывал про выбор подходящей метрики для их приложений, и работу с ними. Интересно, что у них в роли метрики выступает доступность страниц входа, и он объяснял альтернативы и причины именно такого выбора. А еще рассказывал про работу: когда у вас есть метрика, то автоматически возникает бюджет ошибок, и часть этого бюджета едят реальные ошибки, а другую часть можно потреблять в ходе экспериментов над улучшением сервиса — ведь любое улучшение может обернуться ухудшением.=

'''Дмитрий Липин и Евгений Сидоров рассказывали историю Интересный разбор, что реально означают метрики отказоустойчивой работы кризисных штабов в Яндексе после событий 24.02'''SLI, например, 99,99 % у AWS — это вовсе не гарантия. Штабов было многоЭто лишь целевая функция, они образовались добровольнонарушение которой трактуется как ошибка. И если нарушают сильно, и брали на себя работу по информированию людейто наступают последствия, формирвоали инструкции о томнапример, что делатьесли ошибок будет 1 % (то есть 99 вместо 99.99 — то вернут 30 %, а если 5 % ошибок (то есть 95 %) — то тогда полностью возвращают деньги за период. По сути SLI превращается в рекламную фишку высокой надежности. Дальше у нас SLO — реальная метрика, брейнштормили риски и вырабатывали планы действийSLA, где описаны последствия. Из любопытного — собрали Дальше Павел рассказывал про выбор подходящей метрики для их приложений, и разослали телефонную книгуработу с ними. Интересно, потому что многие сорудники сейчас общаются исключительно через мессенджерыу них в роли метрики выступает доступность страниц входа, и при отрубании инета (или конкретных мессенджеров) реально лишаются связи — а такие сценарии были возможныон объяснял альтернативы и причины именно такого выбора. А еще — готовность к возмодному росту нагрузки. Управляемое зеркалирование к себе репозиториев и переход на сборку из нихеще рассказывал про работу: когда у вас есть метрика, во многие продукты собственная сборка была заложенато автоматически возникает бюджет ошибок, но подчистили хвосты и расширили набор сохраненного локальночасть этого бюджета едят реальные ошибки, плюс выкачали тексты. И так далее. А а другую часть можно потреблять в долгую — оптимизация нагрузки, потмоу что перспективы поставки оборудования для масштабирования через железо пока туманныходе экспериментов над улучшением сервиса — ведь любое улучшение может обернуться ухудшением.

Я в ходе доклада вспомнил свою довольно старую работу, когда MS прислал компании черную метку с требованием предъявить лицензии, что в тот период ознаало возможность прихода проверяющих с последствиями. Был такой период массового обеления. Сложность была не в том, чтобы купить лицензии, а в том, чтобы реально заменить софт, минимально нарушая работу разработчиков. Довльно быстро выяснилось, что безопасно — это если выдаешь комп с новой конфигурацией, он на него переходит, проверяет, но старый при этом некоторое время сохраняется на случай отказов. И помимо сборки новой конфигурации = Дмитрий Липин и ее технологичной заливки на компы потребовалось как раз организационно обеспечить цепочку замен Евгений Сидоров рассказывали историю работы кризисных штабов в сжатые сроки без деградации характеристик комповЯндексе после событий 24.02=

'''Евгений Росинский из ivi. Генерация хайлайтов'''. Всем известны трейлеры к фильмамШтабов было много, это законченные произведения на 2-3 минуты. А хайлайт — еще корочеони образовались добровольно, 40 сек, чтобы зацепить человека. Зачем генерить? Есть страничка фильма, там статический постер. Для 20-30 фильмов руками собрали хайлайты — хайлайт в 4 раза повышает просмотры, поэтому если раскатать и брали на все — будет профит около 20М. И возникла идея порождать хайлайты автоматически. Потому что в реальном мире трейлер делают 1.5 месяца — это долго и дорого. Про решение этой задачи Евгений рассказывал. Идея: фильм состоит из сценсебя работу по информированию людей, сцены — из шотов — коротких фрагментов, в которых план съемки не меняется, на шоты можно автоматически нарезать. Будем считатьформирвоали инструкции о том, что в существующие трейлеры создатели отобрали хорошие шотыделать, обучим модель их отбиратьбрейнштормили риски и вырабатывали планы действий. Для оценки используют три кадра: первый, последний Из любопытного — собрали и середина. Еще проверяютразослали телефонную книгу, потому что граница шота совпадает с границей звукамногие сорудники сейчас общаются исключительно через мессенджеры, и отсеивают шоты по длительностипри отрубании инета (или конкретных мессенджеров) реально лишаются связи — а такие сценарии были возможны. А чтобы исключить спойлеры берут первую половину фильмаеще — готовность к возможному росту нагрузки. Дальше была куча техники — про нарезку Управляемое зеркалирование к себе репозиториев и переход на шотысборку из них, про работу с разными разрешениямиво многие продукты собственная сборка была заложена, потому что резать но подчистили хвосты и выбирать лучше по сжатому видео — оно меньшерасширили набор сохраненного локально, а монтировать хайлайт — по исходному качеству, и не переходе есть проблемы с FPS, регулярная смена хайлайтов при показе предложения, и многое другое, путь от идеи до продакшена, как обычно, имеет много нюансовплюс выкачали тексты. В целом получилось И такдалее. А в долгую — оптимизация нагрузки, потмоу что автоматические хайлайты не уступают созданным вручную, перспективы поставки оборудования для оценки использовали респондентов, набранных масштабирования через Яндекс. Толоку. Трейлеры вручную создают лучше — на более длинном ролике качество монтажа имеет значение. Метод не подходит для мультиков — у них сложнее с выделением персонажей, и для спортивных передач, но для спорта есть альтернатива — по комментариям и реакции в трансляциях выделяются ключевые моменты. В целом интересно и познавательножелезо пока туманны.

'''Алексей Коновкин из NexignЯ в ходе доклада вспомнил свою довольно старую работу, когда MS прислал компании черную метку с требованием предъявить лицензии, что в тот период означало возможность прихода проверяющих с последствиями. API Gateway'''Был такой период массового обеления. Есть много стандартныхСложность была не в том, и Мегафон выбирал. Пока выбирал — они сделали свой, вроде как прототип для осознанного выборачтобы купить лицензии, а в результате именно его и взяли в продакшн. Рассказ был про функциональные задачи API Gatewayтом, которых довольно много: хранение конфигурациичтобы реально заменить софт, версионированиеминимально нарушая работу разработчиков. Довольно быстро выяснилось, маршрутизация что безопасно — это если выдаешь комп с учетом работоспособности узловновой конфигурацией, балансировкаон на него переходит, аутентификацияпроверяет, авторизация, логгирование, преобразование запросов, защита и квотирование и так далеено старый при этом некоторое время сохраняется на случай отказов. И для каждой функции есть различные подходы, о которых рассказывали с примерами реализации в стандартных продуктах, помимо сборки новой конфигурации и о своем выборе реализации, который выступал ее технологичной заливки на компы потребовалось как пример. Доклад не был рекламой продукта, тем более, что отдельно они его не продают, а именно рассказом о функциях и вариантах реализации, уместных раз организационно обеспечить цепочку замен в зависимости от среды использования. Включая такие штуки, как token exchange, необходимый в гетерогенной среде со многими провайдерами токенов, используемыми разными системами, так что на интеграции токены надо подменятьсжатые сроки без деградации характеристик компов.

'''= Евгений Росинский из ivi. Генерация хайлайтов = Всем известны трейлеры к фильмам, это законченные произведения на 2-3 минуты. А хайлайт — еще короче, 40 сек, чтобы зацепить человека. Зачем генерить? Есть страничка фильма, там статический постер. Для 20-30 фильмов руками собрали хайлайты — хайлайт в 4 раза повышает просмотры, поэтому если раскатать на все — будет профит около 20М. И возникла идея порождать хайлайты автоматически. Потому что в реальном мире трейлер делают 1.5 месяца — это долго и дорого. Про решение этой задачи Евгений рассказывал. Идея: фильм состоит из сцен, сцены — из шотов — коротких фрагментов, в которых план съемки не меняется, на шоты можно автоматически нарезать. Будем считать, что в существующие трейлеры создатели отобрали хорошие шоты, обучим модель их отбирать. Для оценки используют три кадра: первый, последний и середина. Еще проверяют, что граница шота совпадает с границей звука, и отсеивают шоты по длительности. А чтобы исключить спойлеры берут первую половину фильма. Дальше была куча техники — про нарезку на шоты, про работу с разными разрешениями, потому что резать и выбирать лучше по сжатому видео — оно меньше, а монтировать хайлайт — по исходному качеству, и не переходе есть проблемы с FPS, регулярная смена хайлайтов при показе предложения, и многое другое, путь от идеи до продакшена, как обычно, имеет много нюансов. В целом получилось так, что автоматические хайлайты не уступают созданным вручную, для оценки использовали респондентов, набранных через Яндекс. Толоку. Трейлеры вручную создают лучше — на более длинном ролике качество монтажа имеет значение. Метод не подходит для мультиков — у них сложнее с выделением персонажей, и для спортивных передач, но для спорта есть альтернатива — по комментариям и реакции в трансляциях выделяются ключевые моменты. В целом интересно и познавательно. = Алексей Коновкин из Nexign. API Gateway = Есть много стандартных, и Мегафон выбирал. Пока выбирал — они сделали свой, вроде как прототип для осознанного выбора, а в результате именно его и взяли в продакшн. Рассказ был про функциональные задачи API Gateway, которых довольно много: хранение конфигурации, версионирование, маршрутизация с учетом работоспособности узлов, балансировка, аутентификация, авторизация, логгирование, преобразование запросов, защита и квотирование и так далее. И для каждой функции есть различные подходы, о которых рассказывали с примерами реализации в стандартных продуктах, и о своем выборе реализации, который выступал как пример. Доклад не был рекламой продукта, тем более, что отдельно они его не продают, а именно рассказом о функциях и вариантах реализации, уместных в зависимости от среды использования. Включая такие штуки, как token exchange, необходимый в гетерогенной среде со многими провайдерами токенов, используемыми разными системами, так что на интеграции токены надо подменять. = Алексей Станкевючис, Яндекс. Эволюция акторной системы'''. = Технический рассказ об организации системы акторов. Первоначально система была на разделяемой памяти, получалось сложно. И они переделывали на независимых акторов, которые обмениваются сообщениями. Акторы — однопоточные state-машины — получают сообщения, обрабатывают, отправляют другие. Хорошо переходят в параллельном и распределенном вариантах. Пример — актор надежной записи: запустил сообщения акторам для записи на конкретные диски, посчитал ответы. Система доступна под Apachе 2.0.

'''= Константин Кичинский из Касперского. Секретная карта IT-экосистемы, из которой становится понятно, к чему готовиться'''. = На этот доклад я пришел только на вторую половину, и сильно пожалел об этом. Рассматривалась карта IT-экосисстемы и различные связанные с ней риски в свете последних событий. Карту обещали опубликовать в подробном виде вместе с презентацией. Мне понравилась классификация ситуаций: помимо черного лебедя, который соответствует произошедшему нежданчику, есть еще черная ночь и черный шум.

* антиграница и червоточина — открываем api , а за границей делаем второе лицо

И еще 4 антистратегии, тоже были на слайде. Пострайтесь Постарайтесь их не делать.

'''= Владимир Озеров, Алексей Гончарук. Архитектура распределенных SQL-движков'''. = Реализация SQL для своей хранилки открывает много возможностей — интеграция, утилиты, работа пользователей. Это не надо делать с нуля, надо использовать стандартные библиотеки и решения, которых довольно много. Но для этого надо представлять архитектуру решения, о которой и был рассказ. Два этапа: планирование запроса, и его выполнение. При планировании — предсказания, есть разные подходы. При этом глобальная оптимизация делает выбор недопустимо долгим, поэтому планирование всегда разбивается на фазы, и надо получить приемлемый результат за приемлемое время. Распределенное хранение накладывает доплнительный дополнительный уровень — помимо операций считывания с диска у нас появляются операции пересылки между нодами со своей стоимостью. А выполнение идет по выработанному плану, но при этом еще и оценивает, насколько предсказания оказались реалистичными, сравнивая их с фактом, и при сильном расхождении может быть запущено перепланирование. И отдельная ветка — обратный ход на хранение. Как при односерверном варианте часто используемые небольшие таблицы могут быть предзагружены в кэш, так и в распределенном варианте какие-то небольшие таблицы могут дублироватсья дублироваться по узлам полностью, чтобы джойн можно было стрить на каждом узле.