Давно не писал про архитектурные антипаттерны. Сегодня рассмотрим очередной - Гиперуниверсальность или когда системы получаются слишком "гибкими", чтобы быть полезными.

Очень соблазнительно построить универсальную систему, которая сможет подстраиваться под любые изменения, которые могут или гипотетически могут возникнуть в будущем. Но нередко это желание приводит к тупику, известному как гиперуниверсальность (Misapplied Genericity) — ситуация, когда система становится чрезмерно абстрактной и обобщённой. Бывает, что гиперуниверсальность порождается желанием предусмотреть все и страхом, что требования изменятся или желанием сделать сервис "на века".

Например, вместо сервиса расчета бонусов, пишется:
🔜 сервис правил
🔜 конструктор акций
🔜 интерпретатор конфигураций
🔜 язык программирования для описания бизнес-логики (DSL - domain specific language)

Почему это плохо:
📌 Обобщенная архитектура это излишнее усложнение. Усложнение = время и деньги. Если это не нужно сейчас, то вы инвестируете в тех.долг (парадоксальненько, однако, но факт)
📌 Гиперуниверсальность это всегда конфигурация. А в конфигурации сложнее разобраться, чем в коде. Порог входа для новичков - выше
📌 Гибкие системы хуже поддаются изменениям, чем специализированные. Для изменения требуется понимать все уровни абстракции, что требует больше навыка и времени, чтобы разобраться
📌 Сомнительная бизнес-ценность. Бизнесу нужен функционал, а не потенциальная возможность расширения

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

И снова про рынок труда. Помогает нам в этом опять ежемесячный отчет HH - Краткий рынок труда за май 2025.
Основное:
📌 hh индекс остался без изменений по сравнению с апрелем, все те-же 5.6 (соотношение количества активных резюме к количеству активных вакансий)
📌 Среднее число активных вакансий упало на 25% к уровню предыдущего года, а среднее число активных резюме выросло на 34%
📌 Среднее число активных вакансий и резюме снизилось на 5% по сравнению с апрелем

Если пройтись по ключевым для меня направлениям - ритейл и ИТ, то в сухом остатке имеем:
📌 В ритейле сохраняется острый дефицит кадров (hh индекс упал еще на одну десятую - 4.3)
📌 В ИТ дефицит вакансий вырос еще на 1 пункт (hh индекс 12.8 против 11.7 в прошлом месяце)
📌 Число вакансий в ИТ уменьшилось на 29% по сравнению с маем прошлого года
📌 Число соискателей увеличилось на 26% за тот же период
📌 Если в апреле число соискателей в ИТ оставалось на уровне марта, а число вакансий уменьшилось на 4%, то в мае число соискателей в ИТ уменьшилось на 3%, а число вакансий уменьшилось уже на 11%.

Резюме - нестабильность на рынке труда продолжается. Сохраняется дефицит вакансий в ИТ сфере и дефицит работников во многих других. ИТ-шное эльдорадо завершается.
От себя хочу добавить - скиловые спецы по-прежнему в цене. А вот те, кто рванул в ИТ за "длинным рублем" в условиях рынка кандидата, находятся под угрозой.
#подбор #разработка #development #управление #HR #development #рыноктруда #войтивит

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

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

Абстрактные примеры:
✔️ Ритейл. Известны компании, которые начали цифровую трансформацию с внедрения еком сайта, но не пересмотрели логистику, управление ассортиментом, клиентский сервис. Как результат - плохой клиентский путь, низкая удовлетворенность, потеря лояльности
✔️ Порталы цифровых услуг. Это не столько "оцифровка" документов, сколько выстраивание межведомственного взаимодействия, построение сквозных процессов и изменение точки зрения на получателя услуги, как на клиента
✔️ Промышленность. Датчики и устройства IoT это круто, но без адаптации производственных процессов и выстраивания системы принятия решений они не дают значимого прироста в эффективности

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

Что нужно для успешной трансформации:
🟢 KYC - поиск и определение клиента
🟢 Перестройка процессов под клиента
🟢 Обучение и вовлечение сотрудников
🟢 Готовность к изменениям на всех уровнях
🟢 Культура постоянного улучшения
🟢 И только после всего этого - выбор ИТ-инструментов.

Зафиналю - Цифровая трансформация это не "про цифру", а про способность меняться. А технологии это то, что помогает быстро и эффективно реализовывать изменения.
#разработка #цифроваятранформация #agile #development #продуктоваяразработка

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

Хэкман разработал модель пяти условий, которые определяют эффективность команды не только в плане достигнутого результата, но и по степени роста и удовлетворенности самих участников.
1️⃣ Четкая и убедительная цель. И тут почти по SMART - цель должна быть: ясной, значимой и вдохновляющей
2️⃣ Правильный состав команды - необходимые навыки и знания, готовность к совместной работе и эмоциональная зрелость, оптимально - 5-9 человек
3️⃣ Структура с четкими зонами ответственности и нормами взаимодействия, простые и эффективные рабочие процессы
4️⃣ Поддерживающая культура - компания должна помогать командам работать. Включает в себя доступ к необходимым ресурсам компании, поддержку руководства и систему поощрения
5️⃣ Развитие через обучение и наставничество. Обратная связь и рефлексия, обучение командной работе, помощь коучей, наставников и фасилитаторов

Начал он разрабатывать свою модель в 1975 году, совместно с коллегами исследуя связь между групповыми задачами, процессами и результатом. В 1983 году представил "критерии работающих команд" и далее больше 15 лет проводил исследования, которые легли в основу его книги, выпущенной в 2002 году.

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

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

Что произойдет в случае возвращения западных компаний на российский рынок? Смогут ли отечественные решения полноценно конкурировать или будут вытеснены? Может ли быть у российских AI решений своя "фишка", которая станет конкурентным преимуществом?

Я думаю да, если фокус в создании локальных AI решений будет в решении конкретных проблем на нашем рынке. Не европейских, не средних по Африке и Америке, а наших. Решения, заточенные под специфику языка, менталитета, отраслевых требований и законодательства будут выигрывать. У меня есть пример, не из мира AI, когда прекрасное решение для маркетплейсов Miracle, не могло составить конкуренцию российским "малышам" из-за своей ориентированности на европейский рынок (начиная с SaaS и хостеров и заканчивая коннекторами с логистическими компаниями).

Что пока тормозит развитие локальных AI решений:
🔵 Большинство решений остаются в статусе "полуфабрикатов" - технология есть, а полноценных продуктов с понятной бизнес-ценностью почти нет
🔵 Недостаток специалистов в области AI - не хватает подготовленных кадров
🔵 Все еще AI воспринимается как эксперимент, мало кейсов с четкой окупаемостью, поэтому бизнес не всегда готов инвестировать в технологию
🔵 Да и в целом - очень мало компаний, кто инвестирует в ИТ - как правило ИТ бюджет-это расходы, а не инвестиции

В итоге российский рынок AI сегодня находится на перепутье: есть хорошие наработки и понимание потребностей рынка, но для устойчивого роста необходимо превратить технологии в полноценные, масштабируемые продукты с доказанной экономической выгодой. Только это позволит отечественным решениям не просто удержаться, но и стать конкурентоспособными на фоне потенциальных конкурентов, используя свое главное преимущество - глубокую адаптацию под наши реалии.
#AI #ChatGPT #чтотампроchatgpt #data #данные #мнения

Недавняя шок-новость - В России разработан стандарт качества цифровой трансформации. На самом деле Минцифры, Цифровая Экономика и Роскачество начали его разработку давно. Сам стандарт датирован 2024 годом.

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

В принципе правильно, а то цифровой трансформацией сейчас называется всё и вся. Порадовал факт, что в пункте 4.2 зафиксировано, что подход построен на цикле Деминга-Шухарта - PDCA. Всего стандарт выделяет шесть основных этапов цифровой трансформации:
1️⃣ оценка и анализ текущего состояния
2️⃣ стратегическое планирование
3️⃣ определение ключевых ресурсов
4️⃣ реализация запланированных мер
5️⃣ оценка полученных результатов
6️⃣ улучшение.

В пункте 4.3 стандарт устанавливает следующие принципы цифровой трансформации:
📌 ориентация на потребителя и клиентоориентированный подход
📌 анализ
📌 индивидуальный подход
📌 участие руководства
📌 мониторинг и аналитика
📌 гибкость и адаптивность

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

Ну и на сладкое - также выпущена Методика самооценки, где каждая организация может ответить на вопросы и понять свой уровень цифровизациии, что на мой взгляд очень полезно. Ну хотя бы чтоб не страдать иллюзиями. Но даже если вы не собираетесь в цифровую трансформацию или не собираетесь себя оценивать, то рекомендую прочитать список вопросов - там есть о чем подумать:
📌 В организации определены ключевые процессы, их интеграция между подразделениями и выявлены потребности в их оптимизации
📌 Организация адаптирует процессы в ответ на новые клиентские запросы или регуляторные изменения
📌 В организации внедрены методы управления качеством процессов
📌 Предпринимаются меры для поддержания мотивации и вовлеченности сотрудников в оптимизацию процессов
📌 ИТ-архитектура организации, ее цели и задачи соответствуют Стратегии цифровой трансформации
📌 Разработан план управления рисками, связанными с цифровыми технологиями
📌 Организован процесс управления изменениями, включая адаптацию бизнес-процессов к новым условиям и интеграцию новых решений с существующими системами

Понятно - вопросов там сильно больше, и все они даже не про цифровую трансформацию, а про современный бизнес, который уже немыслим без цифры. Как говорится - "…пойдете вы туда или нет, но он там будет…"
#разработка #цифроваятранформация #agile #development #продуктоваяразработка

Назрела необходимость завести новую рубрику - "Услышано в кулуарах". Недавно на одном из архитектурных комитетов услышал от оппонента фразу:

Вы сделали (отдельный) сервис потому, что не стали влезать в ядро системы

Если что, то для меня это прозвучало как похвала. Но я задумался, а все ли понимают, почему не надо лезть в ядро? Все ли осознают риски и принимают последствия? (*Дисклеймер - под системой здесь мы понимаем энтерпрайз систему, монолит, покупное решение)

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

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

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

Ох, обожаю я появление новых терминов. Особенно так любимых всеми ИТшниками аббревиатур из трех букв. В одном из каналов нашел ссылку на статью - "MVP vs MLP: почему минимально жизнеспособного продукта уже недостаточно в 2025 году" и очень хочу поразгонять на эту тему.

В мире стартапов назревает сдвиг: классический подход Minimum Viable Product (MVP) больше не гарантирует успеха... … на сцену выходит концепция Minimum Lovable Product (MLP): стратегия запуска, ориентированная на создание любимого продукта с первого дня.

Ну и дальше по списку - MVP уже не работает, потому что в 2025 году мало сделать просто рабочий прототип, нужно чтобы пользователи "влюбились в продукт с первого касания", поэтому MLP. Вспомнили про Эрика Риса и The Lean Startup (2011) и определили, что через 14 лет все это не работает потому, что:
✖️ Высочайшие требования к UX
✖️ Конкуренция во всех нишах
✖️ Технологии упростили создание
✖️ Первое впечатление - решающее

В общем складывается впечатление, что автор поста плохо читал или плохо понял Эрика Риса и все перепутал. По Lean Startup - MVP это про поиск. Поиск Problem - Solution Fit (соответствие решения проблеме) или Product - Market Fit (соответствие продукта рынку). А если надо сразу нарисовать почти идеальный CJM, то где во всей этой истории поиск? Такое ощущение, что стартапер должен уметь сразу безошибочно заполнить все поля на канвасе, чтобы сразу продукт получился.

На самом деле, большинство стартапов умирают гораздо раньше Lovely. И не по причине плохого CJM или плохого дизайна, а потому, что не попадают решением в проблему или своим продуктом в рынок. Мало придумать новую высокотехнологическую хрень. Надо еще найти, какую действительно насущную проблему эта хрень будет решать, а потом еще и найти рынок для ее реализации.

Складывается ощущение, что автор попутал терминологию и назвал POC - MVP, а MVP - MLP. Ну или продажи MVP пошли вниз, поэтому надо срочно придумать новое название для старого термина, чтобы поднять продажи.
#гибкиеметодики #продуктоваяразработка #leanstartup #впоискахсеребрянойпули

Пришел к мысли, что надо продолжить писать свои Записки программиста, и вот что получилось:

Записки программиста. День 417.
Сегодня в ТЗ появилась новая строчка:

Приложение должно быть удобным.

Не быстрое. Не безопасное. Не стабильное. Просто, *ука, удобное.
Я почувствовал себя как в том анекдоте: "Доктор, у меня что-то болит где-то вот тут…"

Начал искать, что заказчик имел в виду.
Спросил: - А что значит "удобное"?
Ответ: - "Ну чтобы человеку приятно было... пользоваться".
Ну круто, теперь всё ясно. Надо вставить в код usePleasure() и autoUserSatisfaction(true).

Ладно, на фиг, решил перевести это на технический.
Применил поверхностные навыки глубинного интервью:
🟢Для кого удобно? (новичок, эксперт, бабушка?)
🟢На чём удобно? (телефон, планшет, холодильник?)
🟢В чём удобно? (скорость? структура? кнопки с душой?)

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

В итоге написал требования сам:

Основные сценарии (регистрация, заказ, оплата) должны занимать не более 3 шагов и проходить без ошибок у 95% пользователей по данным аналитики

Отправил заказчику. Он одобрил - "Да, да, вот теперь прям удобно"
В общем теперь каждый раз, когда вижу "удобно", сразу думаю: удобно кому, когда, и почему это опять моя проблема. В общем - если в ТЗ написано "удобное приложение" - это не требование, это из области метафизики. Будьте осторожны, там рядом обычно бродит "интуитивно понятно" и "должно просто работать".
#антипаттерны #управление #разработка #никогдатакогонебыло #шуткаюмора

В очередной раз возвращаемся к теме Микросервисной архитектуры и сегодня посмотрим на антипаттерны в которые можно попасть, когда вы заходите на проектирование микросервисов.

Поехали:
1️⃣ Монолитный образ мысли. Делаем микросервисы, как привыкли делать монолитные приложения - сильная связанность, взаимозависимости сервисов, ограниченная автономность. Забываем про нормальное масштабирование, отказоустойчивость и высокую нагрузку
2️⃣ Монолит данных. Много сервисов, а БД - одна. Возникает жёсткая связь по данным, получаем сложности с согласованностью и узкие места по производительности
3️⃣ Болтливые сервисы. Чрезмерный обмен сообщениями между сервисами приводит к перегрузке, высокой задержке и повышенному использованию ресурсов
4️⃣ Неверно определенные границы сервисов. Либо сервисов мало - мегасервисы, либо слишком много - излишняя декомпозиция и микросервисный ад. И в том, и в другом случае получаем хаос, идем решать сложности с разработкой, тестированием и выкаткой
5️⃣ Расползание сервисов. Много сервисов без четкого контроля и управления. Все бесконтрольно создают сервисы - забываем о том, чтобы хоть что-то понимать в нашей архитектуре и направлении нашего движения
6️⃣ Отсутствие agnostic подхода. Мы верим в K8S или в BareMetal или в Managed services от нашего облачного провайдера и сильно удивляемся, когда все наше решение оказывается прибито гвоздями к конкретной реализации
7️⃣ Игнорировать observability и удивляться, что система нестабильна, время восстановления растет, контроль - утрачивается

Что со всем этим делать? Если вы увидели что-то вам знакомое, значит скорее всего вам не показалось. Пока все не разъехалось в разные стороны надо остановиться, провести аудит того, что уже наделали, внедрить архитектурный надзор или контроль и уже идти дальше, стараясь не допускать нарушений. Микросервисы - классная технология, но ее надо уметь готовить и понимать, зачем именно вам она нужна? Какие ваши вопросы она решает? И все будет хорошо.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны

За последние несколько месяцев в общении с коллегами по цеху очень часто стала всплывать проблема защищенности подрядчиков. Не секрет, что мы все пользуемся подрядчиками: аутсорсинг разработки, интеграторы, DevOps'ы на подряде, поддержка 24/7 - всё это удобно, быстро и, казалось бы что могло пойти не так?

А все достаточно просто:
✖️ Слабая защита инфраструктуры и слабый контроль доступа на стороне самого подрядчика
✖️ Доступы по VPN в вашу инфраструктуру
✖️ Привилегированные учетки подрядчика в проде
✖️ Отсутствие логирования и мониторинга действий и доступов внутри сети
✖️ Ну и самое страшное - полное доверие к внешней команде, как к своей

В результате вы читаете о себе в новостях об инцидентах кибербезопасности и размышляете, что-же надо с этим всем делать. А делать надо следующие шаги:
📌 Пересматриваем модель доступа. Не надо подрядчику ходить туда, куда у вас даже не все мидлы и сеньеры имеют доступ. Изолируем среды, внедряем четкие правила доступа, автоматически отключаем неактивные сессии и мониторим неиспользуемые доступы
📌 Пересматриваем контракты с подрядчиками. Добавляем требования по безопасности, добавляем ответственность за инциденты, требования к регулярному аудиту
📌 Zero Trust - для всех и вся. Верифицируем каждый шаг. Многофакторка, логи, контроль подозрительной активности, сетевые политики
📌 Регулярный аудит. Кто деплоит код? Где код хранится? Кто имеет доступ к CI/CD? Контролируете ли вы все эти процессы?
📌 Фиксируем и мониторим. Все действия в лог, странные действия в алерты

Да, самая идеальная защита - это полная изоляция. Не пользуемся подрядчиками, отключаем все внешние точки входа, капсулируемся и живем без выхода наружу. В современном мире (в коммерческом) это утопия. У вас десятки точек входа, и каждая из них может выстрелить. Ваши подрядчики - часть модели угроз и относиться к ним надо соответствующе.
И, да. Безопасность - это не только про антивирус и регулярную смену пароля. Это про дисциплину и про немалую ответственность.
#итбезопасность #кибербезопасность #ИТбез #разработка

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

Такман выделял 5 этапов жизненного цикла команд:
1️⃣ Формирование (Forming). Команда собирается, участники пытаются разобраться в задачах, ролях и корпоративной культуре. Присутствует высокий уровень неопределённости и осторожности, низкий уровень инициативы. Основные риски - Непонимание окружения, целей и ожиданий. Роль лидера на этом этапе - разъяснение структуры и целей, выстраивание доверия и коммуникаций
2️⃣ Притирка (Storming). Начинают возникать конфликты - люди начинают бороться за влияние или критиковать и оспаривать процессы, роли, подходы, ответственности. Основные риски - Конфликты, снижение мотивации, текучка. Роль лидера - Модерация конфликтов и фасилитация диалогов, управление ожиданиями, установление правил работы.
3️⃣ Нормализация (Norming). Члены команды договариваются о правилах игры, появляется командная работа, формируется доверие и неформальные правила взаимодействия. Основные риски - конформизм, боязнь обратной связи, заниженные ожидания. Роль лидера - поощрение инициативы, развитие обратной связи, поддержание прозрачности
4️⃣ Эффективность (Performing). Пик эффективности команды при минимуме управления. Высокая степень автономности, адаптивности, взаимоподдержки. Основные риски - потеря гибкости, выгорание ключевых членов команды. Роль лидера - фокус на развитии и масштабировании, сопровождение команды
5️⃣ Расставание ( Adjourning). Команда завершает проект и/или расформировывается. Основные риски - снижение мотивации, стресс, потеря накопленного опыта. Роль лидера - формализация результатов, ретроспектива, сохранение экспертизы

Модель эффективна:
✔️ при формировании проектных и продуктовых команд
✔️ в проектах трансформации
✔️ для оценки готовности команд к автономной работе
✔️ как основа для развития менеджеров команд
По этой модели можно диагностировать состояние команд и менять стиль управления командами. При этом в практике возможен откат на предыдущие этапы в случае изменения состава команды, смены руководства, перевода команды на другие задачи.

Почему важно отслеживать этапы команды? Если проигнорировать стадию Притирки, то можно недооценить риски. Если вовремя не распознать Нормализацию, то сложно будет держать устойчивый темп. А если слишком рано потребовать Эффективности, то можно получить выгорание и хаос.
#разработка #цифроваятранформация #agile #development #впоискахсеребрянойпули #мотивация

В начале месяца с удовольствием прослушал семинар Positive Technologies на тему "Остается ли в тайне ваш диалог с LLM? Как использовать большие языковые модели безопасно!". Алексей Лукацкий и его команда, как всегда, были неподражаемы.

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

Если по цифрам:
✅ 15% - рост затрат на безопасность ИИ из-за рисков, которые несет GenAI
✅ 55% сотрудников - используют в работе несанкционированные GenAI
✅ 62% атак на ИИ совершаются внутренними сотрудниками
(* исследования Gartner и Salesforce)

Ну и примеры из любимого мной сериала - "ИИ заменяет разработчика":
✖️ Код - риск содержания небезопасного кода: инъекции, уязвимости итд. и риск генерации кода на базе публичных репозиториев
✖️ API - генерация swagger - риск раскрытия закрытых методов API, некорректная документация
✖️ Автотесты - эксплойты вместо тестов
✖️ Конфиги - генерация конфигов с избыточными правами и известными уязвимостями
✖️ SQL запросы - инъекции и раскрытие схем БД

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

Как часто в разговорах с бизнесом, в технических заданиях, в брифах встречается фраза: "Сделайте так, чтобы было интуитивно понятно. Чтобы пользователь сам во всём разобрался". И вроде бы все прекрасно, если бы не одно НО - интуитивность, понятие субъективное ну или относительное.
То, что очевидно для дизайнера 25 лет может быть темной магией для пользователя 50+.
А то, что очевидно для бухгалтера в финансовой системе, может быть неочевидным для пользователя инсты. И ничего с этим не сделаешь, потому что оно НЕ конкретно, НЕ измеримо, НЕ имеет критериев успеха. А значит бесполезно.

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

И вместо "интуитивно понятно" в требованиях появляется:
✅ Пользователь должен уметь оформить заказ за ≤3 минут
✅ 90% пользователей должны пройти регистрацию без ошибок
✅ Интерфейс должен соответствовать рекомендациям Apple Human Interface Guidelines
✅ Конверсия на шаге Х - не ниже 80% после редизайна

Интуитивный интерфейс - это не набор компонент в Figma. Это гипотезы, которые нужно проверять. Если вы не хотите тестировать, значит вы не хотите знать правду о своём продукте. А если хотите - то начнете не с рисования кнопок, а с формулировки конкретных поведенческих целей. И вот тогда интерфейс действительно станет "интуитивным" - но не для дизайнера или продакта, а для реального пользователя.
#клиентскийопыт #CJM #CX #ритейл

Пару недель назад рассказывал про "ложные микросервисы" и антипаттерны в их проектировании. А сегодня давайте посмотрим на 10 важных моментов, которые должен знать о микросервисах каждый разработчик, когда заходит в микросервисную историю:

1️⃣ Начнем с API Gateway - главного маршрутизатора всего и вся. Он принимает запросы, решает, куда отправлять, имеете ли вы права на отправку и получение, отслеживает что происходит и меняет маршруты при необходимости. Если надо, API Gateway может агрегировать ответы от нескольких сервисов, кэшировать, писать логи и преобразовывать протоколы. В общем очень полезная штука

2️⃣ Service Discovery - динамический реестр всех сервисов. Основной компонент микросервисной архитектуры, обеспечивающий гибкое и эффективное динамическое взаимодействие между сервисами. Сервисы регистрируются в реестре, а реестр проверяет их работоспособность и обновляет статус сервисов

3️⃣ Circuit Breaker - выключатель цепи, который перенаправляет вызовы на другие экземпляры сервисов, при замедлении или остановке сервисов для сохранения стабильности системы, удовлетворенности клиентов и предотвращении каскадных сбоев

4️⃣ SAGA - паттерн для транзакций в архитектуре микросервисов для обеспечения согласованности данных. Каждый сервис управляет своей частью распределенной транзакции независимо, чтобы повышает гибкость и надежность системы

5️⃣ Loose coupling - низкая связанность - минимизация зависимостей с другими сервисами. Дает гибкость, увеличивает надежность и масштабируемость

6️⃣ High cohesion - высокая связность - отсутствие в микросервисе лишней функциональности. Сервис должен иметь четко определенную область применения и не выполнять неспецифические задачи. Дает возможность легче поддерживать и развивать код сервиса

7️⃣ Database per Service - у каждого сервиса своя база данных. Аналогично низкой связанности, только про хранение данных. Увеличивает безопасность микросервиса и данных, хранимых в нем и улучшает быстродействие

8️⃣ FaaS - Function As a Service - сочетание Serverless и Микросервисного подхода. Особенно хорош при построении Event Driven Architecture. Дает возможность переложить все управление инфрой на облачного провайдера

9️⃣ CQRS - Command Query Responsibility Segregation - разделение операций изменения и чтения данных на два независимых асинхронных потока. Улучшает производительность, масштабируемость и упрощает разработку

🔟 Sidecar pattern - вынесение доп.логики и вспомогательных функций в отдельный контейнер без изменения логики и кода основного сервиса. Хорошо применяется для логирования и прочих сервисных вещей

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

"Цифровизация - модная тема и все должны идти в цифру". Попалось мне недавно на глаза выступление Натальи Касперской на форуме ЦИПР 10 в июне этого года в Нижнем Новгороде. Особенно зашла та часть, где она рассуждает о цифровизации и ее ограничениях. Большинство сказанного совпадает с моими собственными мыслями на эту тему. Для тех, кому интересно - исходное видео по ссылке.

Итак, ограничения цифровизации:
1️⃣ Вся цифровизация построена на данных, данные подвержены рискам ИБ, риски ИБ нельзя закрыть на 100%, это невозможно. Уязвимость меряется по самому слабому звену, которым является цифровизация.

2️⃣ Оборудование и устройства все иностранного производства. Все наши данные принадлежат тому, кто произвел это устройство. Мы можем ставить любые защищенные приложения, но на платформенном уровне все данные могут быть перехвачены. Все может быть решено только полным импортозамещением, которое пока никто не знает, как сделать.

3️⃣ Электронным помощникам проще послать человека "на фиг". При полной цифровизации люди уже никуда пробиваться не смогут. А электронные помощники будут генерить классную статистику.

4️⃣ Цифровизация = электричество + интернет. Необходимые и достаточные условия. А у нас через некоторое время отключение интернета станет нормой. Если мы будем полагаться только на электронные системы, то мы рискуем оказаться безрукими слепыми и глухими котятами в момент отключения этих систем. Гигантский риск, который нельзя недооценивать.

5️⃣ ИИ - это здорово, это классно, это молодёжно, но надо понимать, что ИИ основанный на глубоких нейронных сетях это система, которая имеет ложноположительные и ложноотрицательные срабатывания. Это значит, что она "глючная" по определению. Ноль и ноль по ЛПС и ЛОС получить нельзя. Уменьшаешь одно, растет другое. Поэтому нельзя эту технологию внедрять в системы принятия ответственных решений.

6️⃣ Почему не говорят о том, что ИИ - это "черный ящик". Проблема "чёрного ящика" нейросетей заключается в сложности понимания того, как системы искусственного интеллекта обрабатывают данные и принимают решения.

Предложения:
📌 Когда мы что-то цифровизуем, мы должны иметь дубли документов на бумаге
📌 При создании любой системы цифровизации должны учитываться риски. Должны анализироваться модель угроз, возможные вектора атаки, внутренние уязвимости и должна быть составлена система защиты. Система цифровизация должна идти в комплекте с системой защиты
📌 Не надо возлагать излишних надежд на искусственный интеллект. Давайте он сначала выйдет на плато продуктивности (по кривой Гартнера).

Это взгляд человека, которые занимается новыми информационными технологиями, их использованием и защитой от них уже очень давно. Особенно приятно слышать это на крупном форуме, посвященном цифровой экономике России. Хайп пройдет и нам всем придется разгребать последствия.
#разработка #цифроваятранформация #agile #development #продуктоваяразработка