6931
правка
Изменения
м
Чиатйте Читайте визионеров и фантастику. Они угадывали невероятное.
Основаня Основная проблема коммуникации между аналитиками и разработчиками - двоякая трактовка. Она дает не адекватные оценки и неверную реализацию. Они пробовали фиксить через процесс коммуникаций, но не помогает: аналитик рассказыаетрассказывает, разработчик понял и оценил, а в реализацию взял другой. он не слышал рассказа. Пробовали оценивать все задачи всей командой, но это требует очень много времени.
Разрабочик Разработчик хочет, чтобы объяснили. Аналитик хочет, чтобы было понятно сейчас, и было понятно потом, в том числе новичку. При этом доработки сделанного регулярны, надо понимать как поменять чтобы не испортить.
Нет описания правки
Меняется не только ВУЗ, меняется все образование. Сейчас нельзя готовить к конкретному рабочему месте. особенно в ИТ - из за быстрого изменения технологий характеристики рабочего места размыты или отсутствуют. И профессию выбирают не на всю жизнь, а на 5-7 лет. И даже если ты продолжаешь быть в ИТ, ты занимаешься другим, это тоже смена профессии с точки зрения прежних критериев.
Поколение Альфа - само выбирает, с делтства детства в гаджетах, клиповое мышление, отрицание норм и традиций. И образование следует за этим, пробует учить нестандартно: перевернутый класс, онлайн-курс, проектное обучение. Нестандартные домашки: создать аккаунт, снять видео, сайт, аудиозапись, интерактикная интерактивная презентация, деятельностное задание - собрать группу и что-то сделать, и так далее.
Надо учиться учиться онлайн - это планирование времени, регулярность, занятия - вовлеченность и включенная камера. И это - самостоятельно!
Если вы видtите видите свое будущее в ИТ - познакомьтесь с профессиями в ИТ, их множество. Разберитесь, что такое - ИТ-проект. Командная деятельность, гибкие методологии (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, топоявляются то появляются проблемы с инкрементальным накоплением: надо их все прочитать, чтобы понять как есть сейчас. А еще тяжело, когда много задач в одной статье при параллельной работе.
И они решили помимо описаний инкрементов собирать описание текущей реализации в том же шаблоне.
Плюсы:
* коммуникация: разработчик понимает что нужно, аналитик получает что описал
* социальная составляющая: отлаженный процесс, переходы аналтикуаналитику
* адаптация новичков
== Александр Серпичев (AXENIX) Почему не работает SRE в Enterprise? ==
Когда возникают проблемы с устойчивостью работы систем, то люди смотрят на передовой опыт, и обнаруживают SRE - Site reliability engineer от Google. B пробуют внедрить. Как правило, не удачно. И доклад как раз расуывал раскрывал проблемы, по которые SRE не работает в Enterprise.
Проблема тут не стольк5о столько в SRE как в методике, сколько в том процессе внедрения, который реализуют руководители. Их ожидания: нанять хороших спецов на рынке для адаптации практик, взать взять готовый kpi и вставить в должностную инструкцию, и по максимуму снять с себя самих задачу внедрения. Я бы сказал. что провал внедрения при таком подходе очевиден для любой методики, не зависимо от ее работоспособности.
А в случае SRE есть еще одна идея: не менять ничего в разработке, потмоу потому что разработка делает полезные фичи, поэтому пусть SRE строят рядом. То, что именно разработчики сделали софт, которые рабоитют работают неустойчиво, как-то ускользает из внимания.
Типовые проблемы внедрения
* Имплементация отдельных инструментов не дают улучшений
* К жесткой блокировке разработки нового функционала при несоблюдении показателей, что жестко соблюдается в Google, оказыаются оказываются не готовы
* Для работы SRE надо хранить и анализировать данные - на это не рассчитывали.
* Кроме продуктового бэклога начинает расти бэклог задач повышения доступности - этого тоже не ожидали.
Что же требуется для успешного внедрения?
# Нанимаем спеца и говорим "давай мониторинг" - сделаем сбор данных и дашборды. Из мониторинга высыпается технический долг, если он показывает проблемы.
# Надо понимать, что практики SRE требует трудозатрат для команды. Часто работы по настройке ложатся на SRE или идут с низким приоритетом. Трудозатраты команды на адаптацию инстументов инструментов аналитики и процессов работы с ними - не учитываются. Надо аллокировать ресурсы на доступность, надо выстраивать процесс анализа мониторинга. # Поддержка людей, принимающих решений. Для этого им надо показать профит: что заработаем или что не потеряем. Кейс: на одном из проектов заказчика не может получить на мониторинг, потмоу потому что он приходит говорит надо 3 рубля на мониторинг. А бизнес говорит: на фига, у меня все проблемы в том году стояли 1 рубль.
# Надо перестраивать процессы по связанным сервисам, механизмы взаимодействия с техподдержкой и эскалации. Это надо прорабатывать.
# Стабилизация - автоматизация выполняемых задач развертывания и эксплуатации для улучшения показателей
# Развитие культуры работы с ошибкой, работа с бюджетом ошибок
# Эволюция - автоматизированная проеверки проверки сервисов, симуляция по прошлым post morten, масштабирование.
Часто начинают с последнего этапа, не пройдя предыдущее, не создав условия.
* Компетенции SRE - как осознают и используют
* Метрики доступности - не просто меряем, на что она влияет
* Уровень автоматизации типовых операций - инженер или кнопка. НапрмиерНапример, после восстановдения восстановления по сбою
* Управление доступностью - по анализу инцидентов.
SRE живет в подготовленной среде - метрики, компетенции, взаимодействие. Не перешагивайте через своей уровен уровень зрелости
И последнее - как искать людей? Главное - люди должны быть с желанием, опыт - вторичен. Но при этмо этом у людей должно быть желание изучить чужой опыт, а не обязательно строить свое оригинальное.{{wl-publish: 2023-10-19 15:21:21 +0300 | MaksTsepkov }}