2023-10-19: конференция Up!date в составе Kazan Digital Week - интересненько

Короткая ссылка: Update-2023

Ссылки сюда (1) →

20 сентября участвовал и выступал в Казани на конференции Up!date, проходящей в рамках форума Kazan Digital Week. Отмечу, что форум - крупное событие федерального уровня, на пленаре было online-обращение от Мишустина, и выступало несколько спикеров уровня министров и замов. А Up!date - IT-конференция, которую в рамках форума организует группа Барс Груп, и помимо нее на форуме было много других секций. Аудитория форума - широкая и смешанная, много представителей власти и бизнеса, много молодежи, включая студентов и даже старших школьников. Помимо программы выступлений была большая выставка, на которую я не попал, и много секций, которые шли параллельно с Up!date. И я смог присутствовать только один день из трех.

Программа - интересная. Заметки будут состоять из двух частей, про пленарное заседание и про Up!date, параллельно с которой шло еще несколько секций, в том числе и по ИТ-тематике. Помимо программы выступлений была большая выставка, на которую я не попал. И я смог присутствовать только один день из трех, так что заметки - не полные. Говорят, там тоже было интересно.

Пленарное заседание

Как я отмечал, пленар был представительным, после приветственного обращения от Мишустина выступали: Шадаев - министр цифрофизации, Минниханов - раис Татарстана, Шпак замминистра промышленности и торговли, Баканов - замминистра транспорта, Наймушин - замдиректор департамента кинематографии и цифрового развития Минкульта, Герасимов - замминистра МЧС. Кроме них выступали представители бизнеса на уровне генеральных директоров: Нурутдинов из Таттелекома (компания Летай), Сергиенков из Headhunter, Хасьянова из Микрон, а также Уразов - гендиректор дивизиона Кадровый потенциал АСИ.

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

• Государственная программа цифровизации завершается в 2024 и не будет продляться. Ее заменит экономика данных. Это - у Шадаева и в других выступлениях.
• Управление данными вместо цифрового и проектного офиса. У Нурутдинова была интересная ссылка на Шеллинга: значимая часть никем не руководимой деятельности индивидов приводит к совокупным результатам, которые почти также хороши, как если бы вы управляли каждым оптимально. Поэтому не принимаем решения, а устанавливаем правила, элементы преобразуются из хаоса в порядок через преимущества по отдельным направлениям, которые эти правила устанавливают.
• Будет федеральное финансирование и со-инвестирование в импортозамещения для корпораций. При этом оно будет организовано так, чтобы права на софт оставались у ИТ-компаний, и решения можно было тиражировать.
• Технологический суверенитет понимается не в смысле "все делать самим", а как организация международных коопераций, в результате которых каждая из сторон получает собственный суверенитет. Это любопытная формулировка. Основания понятны: для многих высокотехнологичных изделий локальный спрос - не велик и локального рынка не хватит для окупаемости. При этом технологический суверенитет хотят многие как гарантию сохранения собственных ценностей и идентичности, так что поле для кооперации - есть.
• Идет многоплановое развитие логистики - беспилотники КАМАЗ, транспортные коридоры и стыковки мультимодальных перевозок, включая трансграничные, цифровизация и электронный документооборот вместо бумажного. Пока это - отдельные большие проекты, идут к комплексным.
• Сергиенков и Уразов много говорили про кадровый потенциал и кадровый суверенитет. Гибкая занятость, самозанятые; повысить мобильность регионов и не только в центр - регионы разные, в том числе через удаленку; цифровизация навыков; цифровое образование и интеграция бизнеса, там пока много офлайн. При этом нельзя ограничиваться классическим подходом к подготовке кадров, потому что он фокусируется на профессиональных навыках, но оставляет за рамками мотивацию, лояльность и идентичность человека. А без работы с этим хорошо подготовленные люди - уйдут. Три фокуса работы с мотивацией: талантливость - то, что человек умеет и ему интересно; применение в интересах Родины - как он может применить свои умения, у на часто по умолчанию берут западные методики из парадигмы "нет пророка в своем отечестве"; мировые вызовы - ставить задачи мирового уровня, а не повторять и догонять.

Конференция Up!date

Начну я со своего выступления Классика, user story, use case, DDD: обзор методов. Оно развивало мое весеннее выступление Требования или модели - как писать постановки (AnalystDays-2023) с фокусом на выбор конкретных методов и взаимосвязь между ними.

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

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

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

Михаил Абрамский (ИТИС). Как получить максимум от образования для карьерного развития

Это доклад о современных изменениях в ИТ-образовании, как его дает ВУЗ. Он адресован молодежи, которая была на конференции: ВУЗ по-прежнему остается ведущим способом получить образование, особенно имея ввиду работу в корпорациях. При этом ВУЗы пробуют перестроиться, чтобы соответствовать современным вызовам, и надо понимать эти изменения, не ждать продолжения классики, которая не работает.

Меняется не только ВУЗ, меняется все образование. Сейчас нельзя готовить к конкретному рабочему месте. особенно в ИТ - из за быстрого изменения технологий характеристики рабочего места размыты или отсутствуют. И профессию выбирают не на всю жизнь, а на 5-7 лет. И даже если ты продолжаешь быть в ИТ, ты занимаешься другим, это тоже смена профессии с точки зрения прежних критериев.

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

Надо учиться учиться онлайн - это планирование времени, регулярность, занятия - вовлеченность и включенная камера. И это - самостоятельно!

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

Если учитесь на не-ИТ специальностях - есть цифровые кафедры, можно туда пойти. Есть технологический студактив для внутренних разработок ВУЗов - можно там работать, получать опыт реальных проектов, которые будут использоваться. Приобщайтесь к проектам с открытом исходным кодом: делайте собственные версии, делайте запросы на изменения.

Ставьте новые задачи на обучение через вакансии: смотрим, что нравится, сверяем с собой, видим точки роста.

Разбирайтесь с ИИ. python, Jupiter, анализ данных, GPT. Избавьтесь от мифов про ИИ - он помогает, а не порабощает. Учите языки, осваивайте коммуникацию, самую разную: комментарии, запросы. Не бойтесь делиться знанием

Читайте визионеров и фантастику. Они угадывали невероятное.

Алексей Фадеев. Альтернативная ORM для .Net "LINQ to DB" и расширенные возможности работы с PostgreSQL

Linq - это реализованный в C# 3.0 в 2008 способ работать с базой данных через естественные конструкции языка. До этого для работы с базой данных использовали либо прямое выполнение SQL-операторов, либо ORM, в частности Entity framework, который позволял представить записи базы данных в виде коллекций экземпляров классов. У обоих методов были проблемы. Прямое использование SQL - под ответственность разработчика, для компилятора эти операторы - просто текстовые константы, он не знает про структуру базы данных. А ORM ограничен, вы он работает с объектами в памяти и вы не можете использовать мощь SQl-операторов для массовой обработки и даже для выбора объектов, можете сделать не все, что в SQL. Особенно в PostgreSQL и его расширениях - там много интересных конструкций.

Конечно, Entity framework тоже развивается, например. недавно сделали поддержку массивов, которые могут быть значением поля БД. Но PostgreSQL позволяет эффективный поиск по значениям таких полей за счет специального синтаксиса SQL, и это в Entity framework недоступно.

Linq to DB снял эти ограничения. Вы используете конструкции C#, а они транслируются в SQL, в том числе - с использованием индексов и других возможностей базы данных. При этом можно писать свои расширения, задействуя дополнительные появляющиеся возможности, например, поиск по индексу для значения-массива или рекурсивные запросы.

И дальше были конкретные примеры полезных функций, которые становятся доступными через расширения linq to db.

В PostgreSQL полнотекстовый поиск встроен в БД. И можно сделать поле tsvector как конкатенацию всех текстовых полей, для этого специальный оператор @@. Его нет в стандартном linq to db, но можно написать метод расширения, который это добавит - sql-реализацию через псевдоатрибут.

Встроенный полнотекстовый поиск - а нужен ли он, если есть elastic search? Он полезен, если хватает его возможностей: не надо ставить отдельную систему, не будет отставания по синхронизации данных.

Поиск в двумерном пространстве: найти бар, школу, библиотеку. Первый вариант - берем прямоугольную область, бары в ней, сортируем. Но бары расположены неравномерно. В PostgreSQL есть оператор point(x,y) и есть индекс gist, если его строим по координате, то поиск ближайших идет по индексу. Оператор <->. Расширение PostGIS - правильные расстояния на земном шаре.

JSONB - вложенные Json, преобразованные в бинарный поиск, индексируются. оператор @> - соответствие json --> - выбор по ключу. Его нет в ОРМ, но можно тоже написать расширения. И можно не только в PostgreSQL- так можно с обычными json работать.

Расширение jquery - запросы по json. jsonpath - аналогичное расширение, только это стандарт.

Агрегатная функция array_agg - собрать все значения в массив - очень круто! И есть агрегация в json - jsonb_object_agg как ключ-значение.

Мария Ревякина (БАРС Групп). Как повысить эффективность взаимодействия в команде

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

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

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

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

Решение - вести по проекту базу знаний, а не только фиксировать задачи в таск-трекере. Словарь - все сущности со всеми атрибутами, при этом названия по-русски, по-английски, таблица в БД.

Дальше был конкретный кейс, на котором показывали шаблон на разработку.

• Общая информация - таск, местоположение в системе, задача кратко текстом
• Модель данных - сущности и все атрибуты этой сущности
• Валидация - те проверки ,которые каждый раз проводятся системой при обновлении базы данных
• Права доступа - группируем в папки
• Интерфейс - текстовом виде: панель инструментов; форма реестра; форма окна редактирования; (поля, типы, источник в БД и т.д.)
• Функции - как работает система, что делает пользователь в формате сущность-атрибут

Шаблон разработали 6 лет назад, начали внедрять. У тех, кто ставил по шаблоны - сокращалось время на оценку и реализацию, они занимались далее. А кто по-старому - возврат в доработку, да еще обосновывать, стресс накапливается - и переходят на шаблон.

Работает для всех видов доработок. Если меняется что-то локально - то просто не все разделы шаблона заполняем. И по шаблону могут джуны.

Все работало хорошо, пока было мало задач на доработку ранее сделанного функционала. Если доработок 5-7, то появляются проблемы с инкрементальным накоплением: надо их все прочитать, чтобы понять как есть сейчас. А еще тяжело, когда много задач в одной статье при параллельной работе.

И они решили помимо описаний инкрементов собирать описание текущей реализации в том же шаблоне.

Шаблон хорошо работает на новых проектах. На старых проектах основную статью собирать долго, но подъемно, если изменения описаны по шаблону.

Плюсы:

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

Анализ показывает, что при внедрении шаблона время на постановку увеличивается на 30%, зато на 90% сокращается возврат задач, на 85% время поиска ошибки, на 85% время оценки, на 60% количество доработок, а время на документацию - на 25%. И это - очень интересная статистика. А еще уменьшилась текучесть сотрудников, у них работают по 5-6 лет.

Александр Серпичев (AXENIX) Почему не работает SRE в Enterprise?

Когда возникают проблемы с устойчивостью работы систем, то люди смотрят на передовой опыт, и обнаруживают SRE - Site reliability engineer от Google. B пробуют внедрить. Как правило, не удачно. И доклад как раз раскрывал проблемы, по которые SRE не работает в Enterprise.

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

А в случае SRE есть еще одна идея: не менять ничего в разработке, потому что разработка делает полезные фичи, поэтому пусть SRE строят рядом. То, что именно разработчики сделали софт, которые работают неустойчиво, как-то ускользает из внимания.

Типовые проблемы внедрения

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

Реально к такому результату приходим потому, что по пути делали ряд ошибок.

Команда разработчиков. И в эту команду добавляют SRE, который говорит "у меня для каждого есть задачи, чтобы продукт стал лучше". Всем, кроме менеджера все равно, они готовы, а менеджер против - потому что сроки плывут.

Что же требуется для успешного внедрения?

1. Нанимаем спеца и говорим "давай мониторинг" - сделаем сбор данных и дашборды. Из мониторинга высыпается технический долг, если он показывает проблемы.
2. Надо понимать, что практики SRE требует трудозатрат для команды. Часто работы по настройке ложатся на SRE или идут с низким приоритетом. Трудозатраты команды на адаптацию инструментов аналитики и процессов работы с ними - не учитываются. Надо аллокировать ресурсы на доступность, надо выстраивать процесс анализа мониторинга.
3. Поддержка людей, принимающих решений. Для этого им надо показать профит: что заработаем или что не потеряем. Кейс: на одном из проектов заказчика не может получить на мониторинг, потому что он приходит говорит надо 3 рубля на мониторинг. А бизнес говорит: на фига, у меня все проблемы в том году стояли 1 рубль.
4. Надо перестраивать процессы по связанным сервисам, механизмы взаимодействия с техподдержкой и эскалации. Это надо прорабатывать.

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

Простой рецепт, который решает эти проблемы.

1. Определение метрик и способов измерения
2. Стабилизация - автоматизация выполняемых задач развертывания и эксплуатации для улучшения показателей
3. Развитие культуры работы с ошибкой, работа с бюджетом ошибок
4. Эволюция - автоматизированная проверки сервисов, симуляция по прошлым post morten, масштабирование.

Часто начинают с последнего этапа, не пройдя предыдущее, не создав условия.

Как оценить зрелость команды?

• Компетенции SRE - как осознают и используют
• Метрики доступности - не просто меряем, на что она влияет
• Уровень автоматизации типовых операций - инженер или кнопка. Например, после восстановления по сбою
• Управление доступностью - по анализу инцидентов.

SRE живет в подготовленной среде - метрики, компетенции, взаимодействие. Не перешагивайте через своей уровень зрелости

И последнее - как искать людей? Главное - люди должны быть с желанием, опыт - вторичен. Но при этом у людей должно быть желание изучить чужой опыт, а не обязательно строить свое оригинальное.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 15:21, 19 октября 2023 • нет комментариев