Июль у меня выдался... ух.
Запускали новую фичу, отменяли запуск старых фич, а ещё и болезнями накрыло.
Не удивительно, что под конец месяца я достаточно спонтанно (по своим меркам) взяла отпуск и уехала в горы и к морю к своей женской мафии ❤️.

Поэтому июль в блоге вышел несколько скомканным, но интересные посты всё же были:

📌 Больше всего сохранений было у достаточно старенькой статьи про работу Google.
Классика, которая не устаревает

📌 Не прошёл и мимо многих мой очередной факап, где я накосячила со спекой OpenAPI.


📌 Самый "мрачный пост" был про могильные камни и где в ИТ вы с ними встретитесь


📌 Ну и больше всего реакций и кулуарных обсуждений получилось вокруг Флирта безопасности (да, это именно та фича, которую мы запускали!)

А теперь, отдохнувшая и заряженная, я готова принять участие в конкурсе от System Education и поделиться парочкой новых интересных историй. Не пропустите :)

"Не знаешь, не отвечай"

Все уже сталкивались с тем, что ИИ лжёт и придумывает информацию.

Для борьбы с этим ULCamp услышала крутой совет: всегда добавлять такое пояснение к важным запросам.

Проверила. Ответы сокращаются и точнее. Необходимость в проверке это не отменяет, но проверять всякий шлак точно нужно реже.

А как вы спасаетесь от того, что ИИ лжёт и выдумывает?

#ИИ #вайбаналитика

Зачем аналитику знать про харденинг?

Недавно в моём профессиональном лексиконе появилось новое слово — харденинг. Сейчас оно как никогда актуально. Между тем, когда я начала искать что это такое, то столкнулась с таким ужасным определением:

Харденинг (hardening) — процесс повышения безопасности компьютерных систем и сетей путём уменьшения поверхности атаки и усиления защиты от потенциальных угроз.

Вам что-то понятно? Лично мне — нет. Потому что такое определение можно дать про большинство DevSecOps-практик, криптографию и многое другое из сферы ИБ.

Так что же это?
Харденинг — не про безопасность кода. Это про безопасность окружения и систем, на которых запускается ваш код. То есть касается безопасности ОС, облаков и серверов.

Дело в том, что «из коробки» большинство операционных систем, облаков и сетей имеют:

множество утилит и демонов для специфических задач,

открытые порты,

пользователей и группы с чрезмерными правами,

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

Всё это может дать злоумышленникам дополнительные возможности для атак.

Для системных администраторов, саппорта и девопсов это огромный пласт работы — выявлять такие места и сужать поверхность атаки.
Но и системные аналитики могут приложить к этому руку.

Что можем сделать мы?
🤌🏻 Правильно собрать нефункциональные требования🤌🏻
Корректная информация о портах, ключах, типах шифрования помогает правильно настроить окружения облаков и ОС.

🤌🏻 Сформировать понимание ролей и доступов🤌🏻
Кому, что и в каком объёме доступно. Нужны ли локальные учётки, под какими правами, что будет храниться или писаться в памяти.

🤌🏻 Описать границы систем🤌🏻
Что во внутренней сети, а что торчит наружу. Учитывать обмен данными в разных контурах.

🤌🏻 Подготовить метрики приёмки и набор стандартов для окружения важнейшей системы.

На что опираться при проработке?
Неофициально в России, но лучшие практики собраны в CIS Benchmarks.
Российские дополнения:
ФСТЭК № 17
Методический документ. Меры защиты информации в государственных информационных системах
Для работы с персональными данными и финсектором есть отдельные предписания.

И хотя харденинг - это вроде как «работа админов», во многих системах аналитик может помочь заложить чёткие, измеримые и реалистичные требования к окружению. А это позволит админам и девопсам выполнить работы по харденингу качественнее и быстрее.

Делитесь как у вас в команде: этим занимается только админы или аналитики тоже в теме?

Участвую в конкурсе #продолжи_мысль_SE от @systems_education

Одни из самых крутых команд в мире системного анализа (Flow, NextWay, DevCrowd и автор канала "Системный сдвиг") объединились и создали опрос: "Исследование рынка системных и бизнес-аналитиков, 2025"

Цель: понять, что аналитики реально делают и используют на практике, а не очередной список из 100+ вопросов с Хабра и копипаст вакансий.

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

Присоединяйтесь. Давайте узнаем чем же занимаются аналитики в 25 году!

Владельцы котов, будьте осторожны, есть подозрение, что они саботируют разработку. Вот несколько признаков!

Во время созвона коллеги жаловались, что меня слышно прерывисто. Долго не могла понять, в чём дело… оказалось, кошка спала на пробеле!

Был важный звонок с камерами, другая кошка лезла в камеру хвостом, заставляя серьёзных людей улыбаться.

Ушла на обед, забыла заблочить экран, возвращаюсь и вместо ADR набор символов "ттттттттттттттттттттттт".

Ваши мысли:
🤔 - не понятно нужно тестить
💯 - известные диверсанты, все признаки заговора есть
👀 - глупая, они спасают от пустых созвонов и ненужных документов

В комментариях можете поделиться своими диверсантами)

Простой ликбез почему Swagger ≠ OpenAPI

У нас в команде всё, что касается документации REST API, по привычке называют «сваггер» (догадайтесь, кто виноват? 🙈).
А между тем Swagger один из инструментов, а не сама документация. Поэтому сейчас переучиваемся.

И так как виновата я, то взяла ответственность на себя и подготовила памятку для коллег с разъяснениями. Делюсь и с вами.

📌 Спецификация OpenAPI (OAS) 📌
конкретный YAML/JSON-файл или набор таких файлов, описывающий ваш API. Это источник правды для документации и автогенерации кода.
Я люблю править спеку в VS Code с набором плагинов (если нужен список дайте знать). Но можно в любом YAML-редакторе. А если JSON/YAML пока пугает попробуйте Stoplight Studio.

📌 OpenAPI-документация 📌
красивое, человекочитаемое отображение спеки, которое может быть в Swagger, но не обязательно. Мне нравится ещё Redoc.

📌 Swagger UI 📌
инструмент для отображения в браузере или в Visual Studio. Легко читать, можно даже делать запросы, но менять к нем спеку нельзя.


Путь работы: Придумываем новые эндпоинты → Описываем их в спецификации OpenAPI → Пушим изменения в репозиторий → Ревью →
CI/CD подхватывает обновления, валидирует спеку → Собирает и разворачивает документацию в Swagger UI → С ней начинают работать бэки и фронты

Если вы всё ещё зовёте всё это “сваггером” — просто пересылайте этот пост коллегам

#Swagger #OpenAPI #СистемныйАнализ

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

Ответ JSON, YAML, XSD был ошибочно поставлен, как правильный. Хотя таким не является.
Конечно же XSD никак не связан с OpenAPI

Была на лекции по архитектуре… городской архитектуре.

Слушала и понимала: у них всё как у нас.
Задача: реставрировать старое легаси, сохранив его изюминку. Но переосмыслить ещё и его применение! А сохранить нужно, потому что это дорогое сердцу, уникальное наследие. Если вы сейчас пустили слезу я вас понимаю.

Всё было хорошо продумано, спроектировано и с какого то этапа даже был бюджет. Что шло не так?
Упс, но не ожидали, что за много лет развития территории вокруг здания и особенности почв под ним будут собираться подземные воды. А именно в подвале планировали всю развязку коммуникаций, в том числе электрики.

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

Архитекторы очень хотели сделать у сада реку.. и снова не вышло. Оказалось, подземных вод мало, а они рассчитывать такое не умели.

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

Да и потребности у современных помещений другие: по энергоэффективности, освещению и прочему. И вместе со старым фундаментом легаси оно плохо уживается.

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

Зато сегодня в Самаре есть потрясающий филиал Третьяковки на месте старого советского здания в стиле Модернизм. И это точно того стоило.

Стоит ли сегодня то же самое делать с программами? Наверное, нет. Но кто знает, может лет через 50 тоже будут музеи "сохранения культурного наследия", объектами которого будут ИТ программы.

#легаси #архитектура #модернизм #выходнойконтент

Промт-инжиниринг: ерунда или новая грамотность?

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

Почему?

1️⃣ Для меня постановка задачи к команде разработки и к ИИ про одно и то же. В каждом случае вводишь в контекст, даёшь все вводные, объясняешь, что стоит использовать и к чему нужно прийти на выходе. Более того, это основа любого общения, где задача быть понятым. То есть в отношениях с родными, друзьями и всем окружающим миром.

Даже особенности работы с ИИ всё же есть, связанные с галлюцинациями, напоминают обычные правила коммуникации. Например:
— «Если не знаешь, не придумывай, а скажи, что не знаешь».
— «Если вводных недостаточно, задай вопросы».
— «Не отходи от изначальной темы».
— «Опирайся на проверенные источники».

2️⃣ Копаясь в базах данных промтов, я скорее видела, что просто не всем доступно в обычной жизни искусство разъясняться. А у аналитиков это уже профессиональное: если не хочешь результат “ХЗ”, то делай нормально ТЗ.

3️⃣ Часто к ИИ мы обращаемся не за уникальной сложной работой, а за рутиной. И там даже модели двухгодичной давности, бесплатные, справляются неплохо, с промтами, которые «ну такое себе». Отлично это демонстрирует доклад Алишера Умарова А последние модели уже и вовсе предугадывают контекст и требуют меньше данных на входе.

Между тем недавно я стала участником конкурса от Systems Education #продолжи_мысль_SE, и там многие писали именно про промты. Вначале я решила, что это не стоит моего внимания, но одновременно с конкурсом произошёл забавный случай:

Идёт обсуждение внедрения ИИ в одну из систем. И представители команды внедрения ИИ говорят: «Вам нужно будет нанять промт-инженера!». Мой мир переворачивается: почему серьёзные компании тратят деньги на «ерунду» в виде промт-инженеров?

Пришлось возвращаться к постам и осмыслять. Больше всего меня зацепил пост «Ментальная карта промтов для аналитика», как и сам канал Елены посвященный во многом промтам.

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

«ментальная карта промтов это способ мыслить, делегировать и усиливаться как аналитик».

«Как аналитик» здесь очень важно. Промты это возможность с помощью чужого опыта получить классное решение на рутинную и не очень задачу.

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

Практикующему системному аналитику с помощью карты можно ускорить время не только за счёт использования ИИ, но и за счёт подготовки задач для ИИ. По факту это всесторонний чек-лист аналитика.

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

А ещё такая карта подойдёт тем, кто всё же не может совладать с искусством промт-инжиниринга. По карте легко изучать, осмыслять и пробовать!

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

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

Изменилось ли моё отношение к промт-инжинирингу после поста с картой? И да, и нет, но точно стало теплее.

А ещё пост навёл меня на мысль: может оказаться, что обучение промт-инжинирингу поможет не только в работе с ИИ? Может, всё больше людей сможет лучше изъясняться друг с другом и в обычной жизни? Или наоборот, мы всё заменим ИИ, например, как заменили поздравления и нецензурные письма коллегам.)

Напоминаю, что уже завтра стартует в Самаре конференция аналитиков Поволжья SAMBA_CONF

Завтра онлайн день, а в воскресенье будет оффлайн!

Жду с нетерпением, так давно такого не было в Самаре)

Я для участников подготовила воркшоп по EventStorming, сначала хотела с другой темой выступить, но так соскучилась сама по ES в живую, что решила все же пойти по уже знакомому пути.

Промокод на скидку 20% от меня

@ANALYTICAGAIN