Хороших каналов по системному анализу становится всё больше, и сегодня хочу вас познакомить с каналом, который так и называется: Системный аналитик. Там множество материалов по нашей теме, вот только небольшая подборка:

🔥 Подборка материалов от телеграм-канала Системный Аналитик

📚 20 лучших книг для развития аналитика — можно скачать бесплатно

📨 Брокеры сообщений: Kafka и RabbitMQ, сравнение Kafka vs Rabbit

🏭 PlantUML с нуля

📌 Подброка бесплатных материалов базам данных и SQL

▶️ Подборка бесплатных вебинаров по основам интеграции систем

📎 Подборка материалов по изучению REST

🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений

🌐 HTTP. Что нужно знать аналитику

⚙️ Интеграция через API. Кратко

🤓 Задачник для системных аналитиков от Тинькофф

🧿 Виртуализация, контейнеризация и оркестрация

💪 Карта навыков системного аналитика

🧮 Про нефункциональные требования

🆚 Сравнение REST vs SOAP, gRPC vs REST, GraphQL vs REST

В пятницу побыл в непривычной для себя роли — ведущего круглого стола. В гостях у Самоката обсуждали требования к роли системного аналитика, грейды, матрицы компетенций и возможный рост. Получилось интересно и содержательно!

И уже есть запись: https://www.youtube.com/live/uRQuVT1xxMY?si=Xfnojsa0GGl05kHx

Вначале там выступление Анастасии Тарасовой из Самоката про аналитика как координатора кросс-доменных проектов, потом Жени Скорикова из AWG про подход к разработке нефункциональных требований (что бессмысленно просто давать какие-то значения доступности или надежности, а нужно предлагать бизнесу баланс значений и затрат на их обеспечение — ну, там у Жени целая методика).

А потом, с 2:18:50 — наш круглый стол.

Сформулировал в одной дискуссии положения про метрики API:

1⃣ Есть три уровня метрик: инфраструктурные (что с железом и каналами) , прикладные (что с запросами и ответами, токенами и т.д)
и продуктовые/бизнесовые (что с качеством данных, бизнес-процессами, клиентами).

2⃣ С точки зрения измерений, что меряем:
- производительность/ресурсы (CPU/память/IO/сеть), RPS;
- скорость/задержки (latency: среднее, максимальное, 95 перцентиль, 99 перцентиль),
- число ошибок (4xx, 5xx);
- консистентность ответов (соответствие структуры, полнота, отсутствие дублей, соответствие размера/распределения ответа ожидаемому).

Если есть кеш — число попаданий/промахов.
Если есть требования к безопасности — число [неудачных] попыток авторизации, ошибки шифрования, ошибки сертификата, число выданных токенов;
Если есть есть требования по гарантированной доставке — число перепосылок, счетчики успешных/неуспешных перепосылок.

Соответственно, настраиваем мониторинг и алерты этих показателей на выход за установленные пределы или на приближение к пределам (например, при определенном числе фейлов перепосылок за какое-то время).

Вот неплохая статья про метрики открытого API: https://www.moesif.com/blog/technical/api-metrics/API-Metrics-That-Every-Platform-Team-Should-be-Tracking/

А вот ещё одна, более техническая: https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring (не смотрите, что про Azure, там метрики универсальные).

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

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

1. Анализ бизнес-потребности. Зачем нам интеграция? Какие бизнес-процессы или юскейсы она будет поддерживать?
2. Какие системы участвуют в интеграции? В каких системах есть данные, и в каких системах они в результате интеграции должны оказаться?
3. Детализированные функциональные требования: какая система в какой ситуации должна показать или использовать данные из другой системы; сделать запрос; передать данные по своей инициативе. Тут мы предварительно можем прикинуть, ну или хотя бы обсудить: кто является инициатором обмена? Синхронный или асинхронный обмен? Какой стиль интеграции мы можем использовать? (Передача файлов, общую БД, синхронные вызовы/веб-хуки/сокеты, асинхронный обмен через промежуточную среду/очередь). Какой паттерн управления обменом используем: оркестрацию или хореографию?
4. Регламент обмена данными в виде таблицы: | система источник | система приёмник | расписание или событие, по которому стартует передача | что именно передается: один объект, набор объектов, по какому признаку отфильтрованы? Какие поля объектов: все; явно перечисленные; только изменившиеся?.. Нужна ли агрегация или расчеты? | — это стараемся писать точки зрения бизнеса.
5. Количественные показатели интеграции: ожидаемая интенсивность (частота передач), ожидаемый объем (одной порции данных), это разовая передача или потоковая, перспективы роста интенсивности и объемов, число систем-клиентов - тут мы пытаемся понять, есть у нас где-то хайлоад, или всё так просто. Если какой-то показатель вылезает за миллионы или тысячи/сек., то дальше уже всё проектируем гораздо аккуратнее. Результат можно зафиксировать в виде НФТ или показателей качества, добавив требования к доступности, настраиваемости и безопасности.
6. Детальная спецификация данных. Тут нужно выявить — в каких системах в каком виде данные лежат, кто является мастер-источником для каких данных, что именно нужно передавать, какие использовать идентификаторы(!), откуда берем и как синхронизируем справочники.
7. Преобразования и мэппинги. Поняв структуры данных, описываем их преобразования и как они друг на друга маппируются. (Часто всё проектирование интеграций только к этому пункту сводится, а остальные аспекты игнорируются и реализуются как придётся, без анализа).
8. Способы взаимодействия: синхронное/асинхронное, прямое/через промежуточную очередь, оркестрация/хореография, что вообще интегрируемые системы могут, а то может там только файловый обмен возможен. Как обеспечиваем требования безопасности, нужно ли шифрование/хэширование/маскирование/обезличивание, как устроена аутентификация и проверка полномочий.
9. Детальный сценарий обмена (диаграмма последовательности + текстовый сценарий).
10. Общие требования к обработке ошибок, журналированию, мониторингу. Где-то тут, когда начинаем думать про ошибки, возникают вопросы про гарантию доставки, идемпотентность и хранение переданных ранее данных. По обработке ошибок по сути у нас два решения: а) система, обнаружившая ошибку (кстати, кто может обнаружить ошибку?), пытается её исправить; б) система оповещает людей, которые уже сами пытаются решить проблему. Эти решения не взаимоисключающие. Кроме того, нужно зафиксировать ошибку в журнале (в каком? что именно записать? и т.п.).
11. Выбираем уже окончательно стиль интеграции и конкретную технологию или решение.
12. Проходим пункты 7-10 ещё раз, фиксируя конкретные и детальные решения, связанные с выбранной технологией. Дальше уже проект интеграции дробится на требования к каждой отдельной системе, участвующей в интеграции.

Вот, кстати, отличная статья Анны Овзяк про проектирование интеграций: https://habr.com/ru/companies/alfa/articles/770184/

Там подробно, с чек-листом, расписано, как при проектировании интеграции идти от юскейсов пользователей, и как прорабатывать архитектуру интеграций при помощи модели C4.

Попал вчера аж в Центральный дом ученых на разговор про современное образование.

И вот какая там мысль проскочила (в связи с ИИ, куда же без него): формула образования — KSA, knowledge-skills-attitudes, знания-навыки-отношение (чувства, эмоции, убеждения, ценности). Причем attitude — это не soft-skills, это вообще не skills. Это то, что мотивирует человека применять тот или иной skill. (Поэтому я не очень люблю разговоры про софт-скиллы, они замещают разговор о ценностях и выборе поведения). Я про эту тройку уже как-то писал в канале — какие качества нужны аналитику.

Так вот в связи с ИИ высказывалось предположение, что знания человек может получить опосредовано — например, из книг или видео. Навык может быт натренирован частым повторением (тут дело быстрее идёт, когда тебя корректируют, но корректировать необязательно должен человек — если вам знакома зелёная сова, то она отлично с этим справляется при изучении языков), а вот сформировать ценности и убеждения в нас могут только другие люди: родители, друзья, среда, наставники в профессии. И вот эту среду ни ИИ, ни цифровые технологии нам организовать пока не могут. Поэтому цифровое обучение вполне эффективно при формировании knowledge и skills и почти не способно сформировать attitudes (т.к. не образует среды и образца поведения).

По той же причине в хорошем университете кроме собственно обучения (получения знаний и навыков) должна существовать какая-то деятельность, происходящая помимо обучения, которую выполняют преподаватели, и в которую они вовлекают студентов, погружая их в среду и демонстрируя своё отношение, ценности и т.д. Если этой среды нет — то и образование будет неполным. В исследовательских университетах это, собственно, исследования. В предпринимательских — проекты и стартапы, которые запускают преподаватели(!). Ну хотя бы практика и стажировка, как минимально необходимое время для встречи с профессией в реальных условиях. Если ничего этого нет... ну, это получение знаний и тренировка навыков, но не образование.

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

Давно не писал про ChatGPT. Но и новостей особо нет, работает привычно-штатно. Бросить в него алгоритм взаимодействия, построить диаграмму последовательности — уже на автомате. Кстати, он теперь сам начал подсказывать, куда её вставить (почему-то рекомендует PlantText.com)

Из нового: попробовал составлять руководство пользователя. Отлично получается.
Что можно делать:
➡️ преобразовывать в ГОСТовскую структуру неформальное описание (например, разработчик, как смог, описал; или из требований сделать руководство).
➡️ составлять руководство на основе кода или скриншотов(!) — а вот это новое, правда, доступно только в 4 версии.

Запрос:

Я создал интернет-сайт на тему <...>. На сайте размещены статьи по разным аспектам этой темы, пользователи могут регистрироваться, проходить опросы и добавлять комментарии под статьями.

Мне нужно составить руководство модератора по следующей структуре:
1 Введение
1.1 Область применения
1.2 Краткое описание возможностей
1.3 Уровень подготовки пользователя
1.4 Перечень эксплуатационной документации
2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
2.1 Виды деятельности, функции
2.2 Программные и аппаратные требования к системе
3 ПОДГОТОВКА К РАБОТЕ
3.1 Запуск системы
4 ОПИСАНИЕ ВЫПОЛНЕНИЯ ОТДЕЛЬНЫХ ОПЕРАЦИЙ
4.1. Наименование операции
4.2 Условия выполнения операции
4.3 Подготовительные действия
4.4 Основные действия
5 АВАРИЙНЫЕ СИТУАЦИИ

Ответь мне на это сообщение словом "Понял". В следующем сообщении я дам тебе неформальное описание функций модератора (или: описание требований к функциям модератора) - приведи их к указанной выше структуре.

Генерация руководства по коду страницы:

На странице сайта есть комментарии. Вот код страницы с комментариями: <html-код, сколько влезет в промпт>
Напиши инструкцию модератора для работы с комментариями.

Результат:

4.4.9. Управление комментариями

4.4.9.1 Наименование операции: Управление комментариями.

4.4.9.2 Условия выполнения операции: Модератор имеет доступ к административной зоне сайта.

4.4.9.3 Подготовительные действия: Модератор переходит на страницу с комментариями.

4.4.9.4 Основные действия:
- Просмотр комментариев:
Модератор просматривает все комментарии на странице, обратив внимание на текст, авторов, дату и рейтинг комментариев.

- Редактирование комментариев:
Если необходимо внести изменения в комментарий, модератор выбирает соответствующий комментарий и нажимает на кнопку "Редактировать." Затем модератор вносит необходимые изменения в текст комментария и сохраняет изменения.

- Удаление комментариев:
Если какой-либо комментарий нарушает правила сайта или несет в себе ненадежную информацию, модератор выбирает этот комментарий и нажимает на кнопку "Удалить." Комментарий будет удален.

- Ответ на комментарии:
Модератор может отвечать на комментарии, нажав на ссылку "Ответить" под комментарием. После этого модератор может написать ответ в текстовом поле, и ответ будет опубликован после сохранения.

4.4.9.5 Описание блока комментариев
Блок комментариев представляет собой прямоугольную область на странице под статьей или записью.
Верхняя часть блока содержит заголовок "Комментарии" и количество комментариев (например, "2" в данном случае).

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

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

Ниже списка комментариев расположена форма для добавления нового комментария. Форма включает следующие элементы:
- Поля для ввода имени пользователя и email (возможно скрыты).
- Текстовое поле для написания нового комментария.
- Кнопки "Сохранить" и "Отменить" для отправки или отмены добавления комментария.

А вот это уже интересно: составление описания и инструкции пользователя по скриншоту экрана! Доступно только в платной подписке GPT 4, но зацените уровень "чтения" картинки.

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

А вот генерация интерактивных прототипов из... да из всего генерация! хоть из мокапа, хоть из диаграммы состояний

Коллеги из Systems.Education перевели одну из провокационных статей Пола Ральфа: "Иллюзия требований при разработке программного обеспечения". В свое время немало споров она вызвала.

Ральф там высказывает две философские проблемы, связанные с понятием "требование":
1) онтологическую, проблему существования: а существуют ли вообще требования в смысле "неотъемлемые свойства решения, каким бы оно ни было", то есть то, что должно быть в любом случае реализовано, при любом выбранном способе решения. Из чего следует вторая проблема:
2) эпистемологическая, познавательная: а можем ли мы быть уверены, что мы рассмотрели все возможные варианты решения? А вдруг есть решение, которое мы не учли, и в котором вообще не будет нужды в тех свойствах, которые мы зафиксировали как требования?

Ральф говорит, что, скорее всего, все варианты рассмотреть невозможно, а значит и абсолютных требований не существует. То есть, почти все требования на самом деле необязательные. И дальше у нас есть два варианта: либо перестать их называть "требованиями", либо плюнуть и признать, что то, что мы называем "требованиями" на самом деле какие-то частные проектные решения, не факт что оптимальные (и это ставит задачу отыскания оптимального решения). А слово "требование" — это профессиональный жаргонизм, означающий не то, что в обыденном языке.

А вы что думаете? Выносите ли вы для себя какие-то выводы из статьи? Это просто теория и заумный разговор о словах, не имеющий практического смысла, или поставленные вопросы как-то меняют всё понимание того, чем мы в индустрии занимаемся?

Как удалить Яндекс?

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

В этот раз на интеграциях дорогие участники спросили — а что будет, если мы попробуем удалить yandex.ru? Ну, в смысле, отправим в http запросе не GET, а DELETE? Ну и мы начали удалять всё подряд! 😂

И вот как по-разному серверы обрабатывают такой запрос:
👉🏻 yandex.ru на любой запрос отвечает: 200 OK, и выдаёт свою страницу. Получить? OK. Удалить? OK, вот вам наша страница. Запостить? OK, вот вам опять наша страница, почитайте. (Тем более, что по адресу yandex.ru сейчас отвечает dzen. Вы читайте, читайте).

👉🏻 google.com по-честному возвращает 405 Method Not Allowed и страницу с ошибкой.

👉🏻 trello.com, который мы используем для отработки вызовов API, возвращает 404 Not Found, что немного странно. По GET возвращает главную страницу, а DELETE — уже не найдено, спрятал.

И, наконец, vk.com выдаёт мою любимую 418 I'm a Teapot! Буду знать теперь, на каком примере её показать. Хотя конечно, строго говоря, в RFC 2324 и протоколе HTCPCP (Hyper Text Coffee Pot Control Protocol) никакого метода DELETE нет, а есть только BREW.

А вы как проектируете выдачу ошибок в http API?

Ну вот, в Zoom появился встроенный AI-суммаризатор разговоров, вот теперь мы всё узнаем о содержательности и смысле наших совещаний 😂😂😂

Всё по Азимову: "Лорд Дорвин за все пять дней обсуждения не сказал ни одной определенной фразы, причем вы этого и не заметили"

Следующим шагом, наверное, будет AI-модератор, чтобы человечишки всё-таки приходили к каким-то решениям :))

(Картинка из поста https://www.facebook.com/kuzmenko.kira/posts/pfbid0Fd4VRYVWqan3iiRz2Mz85JUBJBCAQBevDHJvHMdmjRQbPAkd9ZHb2uYvWtpLu2mSl)